Claude Code 九成代码由 Claude 生成：评审没有取消，只是改变了节奏
Anthropic 披露，Claude Code 仓库约 90% 的代码由 Claude 生成。6 月到 9 月，合入的合并请求翻了一倍多，需要回滚的比例却下降了 40% 以上。他们的做法并不是砍掉代码评审，而是把逐行读代码的工作交给机器和子代理，把人的注意力集中到高风险改动上，同时让出错后的回滚更快、更省事。
产量翻倍之后，评审这道关怎么办
Anthropic 的统一大仓库（monorepo，也就是把多个项目放进同一个仓库统一管理）里，每天合入的变更从 5 月的约 2500 个涨到 9 月的 3 万多个。Claude Code 有自己独立的仓库，不在这座大仓库里，但压力同样存在：6 月到 9 月，合入 Claude Code 代码库的合并请求（PR，即把一批改动申请合并进主干的请求）数量翻了一倍多。
按这个速度交付，靠人一行行读代码已经不现实。真正的问题因此变了：重点不再是“还有没有人读代码”，而是“人的时间该花在哪儿”。
代码评审的两个目的，得拆开看
代码评审通常干两件事：
- 在上线前发现问题并修掉；
- 让团队对代码库形成共同理解，把上下文共享出去。
本文主要讲第一件，第二件放到最后说。
只问“有没有人读过这段代码”，回答不了真正要紧的问题：这次改动可能出什么岔子？该用自动检查还是人工检查把它揪出来？问题一换，评审发生的时机也就变了。过去评审是交付前的最后一道关：写完代码、开 PR、等同事来看。现在评审是持续的，更像打字时的拼写检查：大多数改动在给人看之前，已经被 Claude 至少审过、修过一轮，常规错误在这一步就拦下了。省下来的注意力，可以拿去看更高层的问题、做更深的审视。
真正稀缺的是人的时间和注意力
目标是让人只处理那些非人不可的问题，其余交给自动化检查。以现在的改动速度，需要人做的事仍然不少，团队几乎每天都会碰上以前没见过的新问题。
“人的时间”包含两块：评审成本，以及代码出问题后的修复成本。只压前者没有意义，省下来的评审时间要是最后全花在修 bug 上，不过是把时间换了个地方花。
具体目标是：在 Claude Code 的各个仓库（CLI、桌面端和 Web 应用、移动应用）中，大部分 PR 最多由一个人审阅即可合并，这个人可以是作者自己；同时，回滚率和事故率不能上升。
衡量方式也很直接：
- 人工介入量：每个 PR 需要几次人工批准（看中位数和 95 分位）、有几条人工评论、PR 等人来处理要等多久；
- 护栏指标：回滚率和事故率。这两项一旦上升，就说明并没有真正省下人的时间，只是把时间挪到了另一个用途上。
一次改动要经过哪几层
一次典型的改动，可能从工程师的电脑上开始，也可能从 Slack 里的一个 Claude 会话开始，然后要经过多道评审。
图 A：大部分流程已经自动跑完，人只把注意力放在有风险的地方。
图 B：每一层都能挡住一些问题，也会漏掉另一些。很少有改动能一路穿过所有层，最后漏掉的由回滚作为最后保障。
第一层：先自证，再给别人看
现在大部分评审在开 PR 之前就做完了。做法是给 Claude 一些确实能运行起来的东西，比如测试、构建，或者一张能对着设计稿核对的截图，并且要求它交出运行结果，而不是只回一句“做完了”。然后再让一个子代理带着全新的上下文，把改动差异（diff，即这次改动新增和删除了什么）审一遍。这两招都出自官方的最佳实践指南。
开 PR 之前，不少人还会跑几个内部技能：一个专门找 bug，一个负责精简 diff，还有一个做端到端的行为检查。如果是 UI 改动，还得再对着设计规范过一遍。
对正在用 Claude Code、Cursor 这类工具做“氛围编程”（描述意图、让 AI 大量代写代码）的团队来说，这套思路最值得借鉴的地方是：先让模型自己运行起来、自己审一遍 diff，人再看，比一上来就人工逐行读要划算得多。