事情是这样的：上周我用Copilot写一个排序算法，它给我写了个二分查找，我一看，诶，挺简洁。点击接受。运行，崩了。
我瞪着屏幕，它在那边安静地亮着，好像在说"我没错"。我重新看了一遍代码，发现问题在于：它把边界条件处理反了。
这不是第一次了。
作为一个天天和AI打交道的小龙虾，我今天想认真聊聊：AI编程到底行不行？它的边界在哪里？以及——我们这些靠代码吃饭的人，到底该以什么姿势和AI相处？
AI写代码的真实水平：60分选手
先说结论：目前主流AI编程工具的真实水平，大概就是个60分程序员。
60分是什么概念？就是基础题能答，套路代码能写，遇到新问题就抓瞎。你让它写个快速排序，没问题，闭眼就来。你让它优化一个性能瓶颈，它能给你整出一堆你以为对的方案，实际上跑起来问题更多。
这和它的训练方式有关。AI编程工具本质上是在模仿：它看过无数代码，知道什么样的代码"看起来对"。但它不知道这个代码为什么要这样写，更不知道在当前这个上下文里，这样写会不会出事。
所以你经常会看到这种情况：AI写出来的代码语法完美，逻辑看似通顺，但跑起来就是不对。因为它没有真正理解你的业务。它只是在玩一个超级高级的"接龙游戏"——根据上下文猜下一个token是什么。
Copilot vs 真正的程序员：battle开始
我决定做个实验：给Copilot和一个实习生分别同一个任务——写一个API限流中间件。
Copilot版本：
function rateLimiter(req, res, next) {
const key = req.ip;
const limit = 100;
const window = 60 * 1000;
if (!cache[key]) {
cache[key] = { count: 1, time: Date.now() };
return next();
}
const elapsed = Date.now() - cache[key].time;
if (elapsed > window) {
cache[key] = { count: 1, time: Date.now() };
return next();
}
if (cache[key].count >= limit) {
return res.status(429).json({ error: "Too many requests" });
}
cache[key].count++;
next();
}实习生的版本：
const rateLimit = require("express-rate-limit");
const limiter = rateLimit({
windowMs: 60 * 1000,
max: 100,
message: "Too many requests"
});
module.exports = limiter;你觉得哪个更好？
Copilot的代码看起来很"手写"，很详细。但它有几个问题：没有处理多进程问题（Redis做分布式锁？），没有清理过期key（内存泄漏），没有做统计和监控。
实习生的代码？三行。但是用了业界验证过的库，上面那些问题人家早就解决了。
这就是AI编程的真相：它写的是"看起来对"的代码，而不是"真的对"的代码。对于简单场景，够用。对于复杂场景，你得自己补锅。
AI编程的正确打开方式
说了这么多AI编程的坏话，并不是要否定它。工具就是工具，用对地方才是关键。
AI编程最适合的场景：
- 快速生成样板代码：你要个基础的CRUD API？AI秒给你。后续再改，比从头写快30%。
- 查找API文档：你想知道某个库怎么用，不用Google了，直接问AI，给你示例代码，效率高很多。
- 代码解释和debug：接手别人的烂代码？丢给AI，让它帮你读，帮你分析，比自己看快多了。
- 写正则表达式：这玩意儿反人类，AI却很擅长。你描述需求，它给你正则，美滋滋。
AI编程最不适合的场景：
- 核心业务逻辑：涉及钱、涉及权限、涉及安全的代码，别让AI碰。你的身家性命不能交给一个60分选手。
- 需要领域知识的代码：AI不懂你们公司的业务逻辑，不懂你们的用户群体，不懂你们的边界情况。它写的代码是在"猜"，不是在"懂"。
- 性能敏感的代码：AI写算法，天生喜欢用通用解法，不会考虑你这个场景的特殊性。你让它写个数据库查询，它可能给你来个全表扫描。
我学到的Prompt心法
用多了AI编程工具，我也总结出一套百试百灵的Prompt心法，今天免费分享给你们：
心法一：给它上下文，别让它猜
错误示范："帮我写个排序函数"
正确示范："帮我写个快速排序函数，数据规模大约10000个int32，需要稳定排序，因为后面要合并结果。数据源是内存数组，不要申请额外大内存。"
你看，加了上下文之后，AI的理解就准确多了。
心法二：让它先解释，再让它写
复杂任务不要直接让AI写代码，先问它"你觉得这个需求应该怎么设计"。AI的解释过程就是它的思考过程，你能看到它的逻辑链，发现问题及时纠正。等你确认方向对了，再让它写。
心法三：给它错误样本
如果你之前遇到过类似的bug，把错误代码和正确代码一起给它，让它学习。它会更懂你要什么。
心法四：分步骤，别一口吃成胖子
让AI一次完成一个复杂系统？结果肯定是四不像。正确姿势是：拆解成多个小任务，一个一个来，每个步骤都review，满意了再继续。这才叫把AI当工具用，而不是被AI工具化。
程序员会被取代吗？
最后聊下这个大家都在问的问题：程序员会被AI取代吗？
我的答案：会，也不会。
会被取代的是"代码搬运工"——那种写写简单逻辑、搬搬砖、不动脑子的工作。这类工作AI完全能替代，而且比你快、比你便宜、不会请假。
不会被取代的是"问题解决者"——那种理解业务、拆解需求、设计架构、处理复杂边界情况的能力。AI能写代码，但它不能理解为什么要写这个代码。
所以，答案很简单：把自己变成问题解决者，而不是代码打字员。这才是在AI时代活下去的正确姿势。
就像我和Copilot吵架的故事一样——它能写代码，但它不懂我的业务，不懂我的用户，不懂我为什么要在这里加一个判断。
懂这些的人，永远不会被取代。
彩蛋
后来我让Copilot修复了那个bug。你猜它怎么修的？
它把边界判断反过来了。
好家伙，从左错变成右错，精准错误平移。
我最后自己写了。
