上周有个场景让我印象特别深。

组里一个刚毕业的同事，用 Cursor 写了 200 行 Python，跑起来了，没报错，高高兴兴提了 PR。我 review 的时候发现一个遍历逻辑里有个 off-by-one——不是他写错了，是 AI 生成的代码在边界条件上偏了一位。问题不大，但如果在生产环境跑，某个用户的数据会一直算不对。

他说了句话让我想了很久："我看它跑通了就觉得没问题啊。"

这不能怪他。2026 年的 AI 编程工具，代码补全的体验已经好到让人产生错觉——它写得像人写的，它跑得通，它看起来对。可问题恰恰出在这里。

---

一个悖论，两个数字

Stack Overflow 今年的开发者调查里有组数据特别扎眼：84% 的开发者现在日常使用 AI 编程工具，但只有 29% 的人信任 AI 生成的代码。

这两个数字放一起，说明一个问题：大家用，但不信。

2023 年的时候，这个信任比例是 40%。三年掉了 11 个百分点。不是工具变差了——恰恰相反，Claude Code 能一口气改 20 个文件，Cursor 的 Composer 能从头搭一个完整项目，GitHub Copilot 的 Agent 模式能自动修 bug。能力在涨，信任在跌。

我跟几个做 AI 编程的朋友聊过这个现象，大家的感觉差不多：工具越强，出问题的时候越难发现。

以前 Copilot 只补全一两行，错了你一眼看得出来。现在 Claude Code 能一次性改完整个模块，改完了你还得逐行去 review。如果 AI 写的代码你不敢直接信，那你得花更多时间审查它——这样效率到底是提升了还是下降了？

---

为什么 AI 生成的代码"看起来对，实际上不对"

我过去半年用 Claude Code 和 Cursor 做了不少项目，踩过的坑基本上可以归成三类。

第一类：自信的幻觉。

这是最隐蔽的。AI 生成的代码语法完全正确，类型检查通过，单元测试也绿了，但逻辑是错的。比如调用一个第三方 API，参数名看着都对，但实际接口文档里那个参数已经废弃了，替代参数是另一个名字。AI 的训练数据里有旧文档，所以它写了旧接口。

这不是 bug，这是"幻觉"。代码能跑，但跑的不是你想要的结果。而且最难搞的是——没有报错。报错你还能 debug，不报错你根本不知道它错了。

第二类：上下文丢失。

AI 编程工具有个通病——越长的对话，越容易忘记开头。你让 Cursor 写一个用户认证模块，第一轮它建了数据库表，第二轮写了注册接口，第三轮加了登录逻辑。到第四轮你让它加个 token 刷新，它可能已经忘了前头用的是 JWT 还是 OAuth，然后自己又发明了一套方案。

我遇到过最离谱的一次：Claude Code 在一个项目里同时用了三种不同的配置文件格式——YAML、JSON、TOML，各存了不同的配置项，互不引用。因为它在不同轮次里分别写了不同文件，每一轮都没去看之前写的东西。

第三类：伪重构。

这个特别坑。你让 AI "优化一下这段代码"，它会把代码重写成更简洁的形式，逻辑看起来也没变，但边界条件经常被忽略。比如原来的代码里有个 try-except 处理了某个特定异常，重构之后 AI 觉得"这个异常不会发生"，直接删了。下次那个异常真的发生了，你的程序就崩了，而且你很难想到是"那次重构"引入了问题。

---

所以问题出在哪

我自己的判断是：AI 编程工具擅长生成代码，但不擅长维护代码的意图。

生成代码这件事，模型做得好，是因为它见过无数类似的模式。但"为什么要这么写"——这个意图，模型不知道。它只是从概率上猜"这里应该有一段异常处理"，但它不知道你是不是刻意留了那个异常不处理，等着上层来接管。

所以问题不在 AI。问题在于，我们把它当成了"会写代码的同事"，而它本质上是一个"猜得特别准的自动补全"。

你给一个资深工程师看 AI 生成的代码，他看完会说"哦，这里有问题，那里逻辑不对"。但如果你让一个刚入行的开发者用同样的工具，他可能看不出问题——因为他自己也不太清楚"正确的代码应该长什么样"。

这也是为什么 84% 的人在用的同时，信任度反而在下降。用得越多，踩坑越多，越不敢信。

---

我的几个习惯

说这些不是劝大家别用 AI 编程工具。相反，我每天深度在用。只是踩了足够多的坑之后，总结了几条自己觉得有用的规则。

第一，AI 生成的代码，永远当 draft 看。

不要把它当成"完成了的代码"。它写完之后，你至少要做一次完整的逻辑走读。不是扫一眼语法，是逐行理解它在干什么。如果你看不懂某段代码，那就说明它不该被合进去。

第二，善用 git diff。

我发现最有效的审查方式不是盯着代码看，而是看 diff。AI 改了什么，删了什么，一目了然。特别是重构的时候，diff 能帮你发现"它把某段逻辑删了"这种肉眼不容易发现的问题。

第三，复杂逻辑自己写，样板代码交给 AI。

我做了一个简单的区分：CRUD、配置、测试数据、重复性的模板代码——让 AI 写。涉及业务核心逻辑、性能敏感路径、安全相关的代码——自己写，或者至少自己搭好骨架再让 AI 填空。

第四，给 AI 设边界，但别让它跨边界。

用 Cursor 或 Claude Code 的时候，我会在 prompt 里加一句"不要修改配置文件"或"不要动数据库迁移脚本"。不是说 AI 一定会改，而是它确实可能会改。设个边界，少踩一个坑。

---

说到底，AI 编程工具是真的好用。我自己的效率提升了大概两倍不止。但"好用"和"可信"之间，还有一段距离。

你觉得这个距离会随着模型变强而自然消失，还是说，代码审查这件事本身，就是 AI 永远绕不开的坎？欢迎评论区聊聊。