夜雨聆风Coding agents are extraordinarily good now. The gap between 4x the code and a tenth more value is the review problem.
—— Addy Osmani, Google, 2026 年 6 月
上个礼拜五下午，我打开 GitLab 看了一眼 Merge Request 列表。
12 个待 review。
其中 9 个是 Cline 写的。
我知道，因为提交人一栏写着 Cline[bot]。
如果是在一年前，12 个 MR 对我来说也就一两个小时的事。逐一 diff，提几个 comment，合进去，下班。
但那个下午我看着列表，第一次有种被淹了的感觉。
不是因为多了，而是因为：这些代码看起来都能跑，但我不敢说它们是对的。
"写得快"不等于"不用看了"
谷歌的 Addy Osmani 前两天发了一篇博客，标题就叫《Agentic Code Review》。
他给的数字很有意思：
AI coding agents 让代码产出涨了差不多 4 倍。
但交付价值——那些真正能上线、能解决问题、能活过下个迭代的代码——只多了大约 10%。
更扎心的是，review 时间涨了 441%。
你看，AI 确实写得快。但写得快不等于写得对。
等于什么？等于你从"审阅一个同事的代码"变成了"审核一个不知疲倦但经常想当然的实习生"。
这个实习生一天能写 4000 行。它还不用睡觉。你早上来，发现它半夜已经交了 3 个 MR。
代码长了，信任没跟上
InfoQ 之前有个调查，说现在大概 42% 的代码是 AI 生成的。
但另一头，96% 的开发者表示不信任 AI 生成的代码能达到生产标准。
我信这个数。
就拿我自己来说，去年我大概 70% 的代码是自己敲的。今年倒过来了——大概 60% 是 AI 写的，我只负责改和调。
表面上效率高了。但仔细算账，其实我每天花在 diff 和 debug 上的时间，比以前还多。
以前写一个 handler，我先想好逻辑，再敲代码，一边敲一边已经过了两遍脑。提交的时候基本是确定的。
现在不一样了。现在是：AI 把 handler 写好了，我得再看一遍它的逻辑，确认它没有漏掉边界情况，确认它的错误处理不是在敷衍，确认它没有发明一个不存在的包。
以前写代码是在"创作"。
现在 review 代码是在"考古"。
90% 的"待验证"
Osmani 提了一个数：大约 90% 的 AI 生成代码，带上了"待验证"的标签。
这是一个很诚实的数据。
AI 写的代码就像外卖——送过来的时候摆盘很漂亮，但你不知道后厨干不干净。你不能看一眼就说"行，端上去"。
你得住进去。
把每个 if 分支看一遍。把每个 error 返回值追一遍。把每个变量命名想一遍：它这个名字到底是什么意思，还是 AI 随便编了一个？
我以前 review 代码最快的时候，一个 MR 10 分钟，主要看逻辑有没有 bug，风格合不合理。
现在最慢的时候，一个 AI 写的 MR 能看 40 分钟。因为它什么都会，也就什么都能错。
那怎么办？不 AI 了？
也不是。
说句实话，我还是每天在用 AI 写代码。而且确实比一年前干得多。
但我慢慢摸出一些门道：
第一，只让 AI 做有明确边界的任务。
"写一个函数，输入 A 返回 B"——这个可以。
"帮我把用户模块重构了"——这个不行。太大了，AI 会以自己的方式帮你"设计"。
第二，review 的时候先看意图，再看代码。
我问自己的第一个问题不是"这段代码对不对"，而是"它想做什么"。
如果 AI 想做的事情和我预期的不一样，直接扔掉重来，比一行一行改更省时间。
第三，团队开始写"review 指南"。
不是给程序员看的，是给 AI 看的。
明确告诉 AI：什么类型的改动你可以自己提交，什么必须等人 review 完再合。这条规则本身就在帮我们节省 review 的精力。
最后说一句
阿里最近开源了一个叫 Open Code Review 的工具，Go 写的，在内部跑了两年才拿出来。3689 个 star。看来大家都意识到了同一个问题。
写代码这件事，AI 已经帮我们走完了前半段。
但后半段——review、理解、验证、决定"能不能上线"——还是得我们自己来。
而且可能比以前更累。
这不是在唱衰 AI coding。这是给它补上我们自己的那一半。
AI 写代码不贵。
review AI 写的代码，才贵。