AI 写 90% 代码，谁来审？

有个 CLI 的 PR，agent 作者和 agent reviewer 一晚上来回改了 50 多轮，最后是作者自己叫停的 😂

这是 Claude Code 团队 10 月 15 日那篇 code review 博客里的一个细节，作者是 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang。背景是 Claude Code 自己的代码，大约 90% 是 Claude 写的；Anthropic 的 monorepo（全公司共用的大仓库）每天落地的 change，5 月大约 2,500 个，9 月超过 30,000 个，四个月涨了 12 倍多。

量涨成这样，Claude Code 仓库 6 到 9 月的 merged PR 翻了一倍多，需要 revert（合并后又撤回）的比例反而降了 40% 以上。看的人少了，错也少了。

一晚 50 轮，后来怎么收住的？

他们对 reviewer 反复标出来的东西跑了一遍 git blame，大约 59% 在 reviewer 第一轮看的时候就已经在那儿了。它很少发现新 bug，每一轮只是多挖出几个老的。

原文还有一句说得很准。人看到一个 nit（无关紧要的小意见），几秒钟就划过去了；agent 不会，它会老老实实去修，修完就是一个新 commit，又触发一轮 review。他们也承认这里有自己的锅，之前习惯了默认跑好几轮，因为每轮总能再抓到点东西。

后来改了四处。3 轮之后，reviewer 请作者退一步，重新考虑方案。 前几轮之后只 review 新的 diff；按 bug 的类别报，让作者把同类问题一次修完；已经贴过的 finding 不再重复贴。

改完以后，一轮就通过的 PR 从 65% 涨到 78%；要 5 轮以上的从 8.9% 降到 1.5%，大约是原来的六分之一；平均 review 次数从 2.08 降到 1.32，少了三成多。

两个 agent 对着跑，自己是停不下来的，总得在某个地方定一个点，要么停，要么把人拉进来。他们选了 3，为什么是 3，文章没解释，只说多轮 review 放在高风险的 change 上可能值得，每个 PR 都这么跑就不划算了。我就当它是个 magic number。

机器到底读了几层？

一个 change 从写完到用户手里要过 7 层：PR 之前的自我验证，每个 PR 都跑的 AI review，能 block merge 的 security review，必需的 CI（每次提交都自动跑的 lint、类型检查、测试和构建），按风险分级的人工 approval，merge queue 加 feature flag（不用重新部署就能关掉的功能开关）加渐进发布，最后是快速发现、快速 rollback。

可以把它想成一摞带洞的奶酪片，这是我的比喻。原文图 B 的说法是，每一层都会抓住一些问题、漏掉一些，能穿过所有层的很少，剩下的交给 rollback。每一片都有洞，叠起来，洞就很难对齐。

AI review 那片做得挺厚。多个 agent 同时找 bug，再由另一组 agent 对每条 finding 投票，够多的认同它是真问题才贴出来，只关于 style 或清理的直接丢掉。research preview 上线后，内部 PR 拿到实质性 review comment 的比例从 16% 到了 54%，大约 3.4 倍。每条 finding 都得回应，要么修，要么写理由关掉。

他们给自己定的目标也写得很直白：大部分 PR 最多一个人参与就能 merge，这个人可以就是作者，前提是 revert 和 incident（线上事故）不能涨。要是涨了，人的时间其实没省下来，只是挪到了事后修 bug 上。

提 PR 之前，谁先审？

写代码的是 Claude，先审一遍的也是一个新开的 Claude。

PR 还没开，Claude 得先跑 tests、build，或者拿截图去对设计稿。光说一句“做完了”不算，要把输出摆出来。 然后再起一个 subagent，在 fresh context 里 review 这份 diff。这一步写进了他们的 best practices。

fresh context 就是一个没看过前面过程的新会话。写代码的那个 session 已经顺着自己的思路走进去了，它觉得对的地方，让它再看一遍，多半还是觉得对。换一个干净的会话，只给 diff 和意图，相当于找了个没参加讨论的同事来看。

Claude Code 的创建者 Boris Cherny 说，给 Claude 一个验证自己工作的办法，大概是拿到好结果最重要的一件事，他估计能让结果好两到三倍。

我自己做飞书待办回路的时候也碰到过类似的事。上线之后才发现少开了一个读附件的权限，过了 4 轮代码评审都没人发现，因为没人真的调过一次接口。

reviewer 老是标同一类问题的话，他们会回到源头去修：改 skill，加一条 lint rule，或者更新 CLAUDE.md、REVIEW.md。REVIEW.md 由 code owner 来写，好的那种都很短，写清楚这块代码出问题时是什么样子，限制 nit 的数量，要求 reviewer 给出文件和行号当证据，别光看名字就猜。

审查的 AI 漏了怎么办？

漏掉的会变成考题。他们把过去引发过 incident 的 PR 收集起来，连同后来的 fix-forward 和 revert，请熟悉那块代码的工程师一个个确认 bug 是什么、在哪儿。这样攒出来一个 eval set，也就是一套固定考题，reviewer 每天考一遍。之后改 prompt、换工具、换模型，都要在这套考题上重新打分。

每出一次 incident，考题集就多一道题。

模型做完一步要能看到对错，再决定下一步怎么走，不然它只会在自己的想象里越走越远，这也是 ReAct 那套思路。agent 写代码也一样。incident 能出现，说明这个问题穿过了所有奶酪片，一路漏到了用户手里。顺着它往回追，查清楚是哪一片的洞没堵上，修掉，下次就会好一点。

噪音他们也在量。reviewer 留的每条评论，都看作者最后怎么处理的：修了，说它错了，说这是故意的，还是觉得无所谓。另外拿已知没问题的 PR 去跑，数一数它有多少次会把人往错误的方向带。

我 9 月读 Amazon 那份 Agent 指南时发过一条，说评分器本身也需要被评估，这里算是看到了一个落地的做法。

哪些事还得人来定？

要几个人批，看改动本身，不看是谁写的。 一个 classifier 读 change 定风险等级：Low 不需要人，自动 review 和 security 检查都过了就行；Medium 1 人；High 2 人。轻的路径只给 trusted list 上的作者。agent 的 approval 永远不算人的，谁 prompt 了这个 change，谁就算一个 reviewer。

剩下留给人的有 5 件：该不该做，也就是方向、taste 和 scope；billing、auto-updater、CI workflow 这类高风险代码；会被别人照着抄的架构；读懂证据；对结果负责。

改方向那一节我挺有共鸣。agent 把开工的成本压得很低，所以有些工作本来就不该 land。代码写得快，PR 关掉也不觉得亏。他们的建议是早点在 thread 里提出不同的方向，别等 PR 写完了再挂一个 blocking comment。代码便宜了，可是该不该做、往哪个方向做，还是得人在动手之前想清楚。

他们自己承认还没做完什么？

还没有 circuit breaker，也就是 revert 和 incident 数字一动就自动收紧审批的机制。 现在靠的是作者、on-call 和看板去发现，团队里的工程师希望先有这个，再让更多代码走 zero-human merge。

另一件是团队之间怎么共享对代码的理解。以前读同事的 diff，本身就是在学这块代码；现在大部分 diff 都是机器在读，这件事没有正式流程。他们目前的办法是，想了解哪一块，就让 Claude 现写一份 explainer。

今天就能做的 4 件事

原文最后有一份落地清单，我挑了今天就能动手的 4 条：

1. 在一份短的 CLAUDE.md 里写清楚 agent 能跑哪些检查，再加上跑 formatter 和 linter 的 hooks。

2. 提 PR 之前，本地跑 /code-review 和 /security-review，或者让一个 fresh context 的 subagent 审一遍。

3. PR 模板加上 Testing、Risk 和 How to revert 三栏。

4. 给 review 轮数封顶，前几轮之后只审新的 diff。

原文最后问了一个问题，我也想知道：如果你们团队也让 agent 提 PR，哪些检查已经自动化了，哪些还必须人看？

配图为我按原文内容重绘的中文版。

🔗 链接

• 原文（Claude Code 团队博客，2026-10-15）：Solving code review at Anthropic

---

首发于 X（2026-10-17）：原文