六道关卡：Anthropic 如何审核 90% 由 AI 写出来的代码

一个反直觉的数字：从 6 月到 9 月，Claude Code 仓库合并的 PR 数量翻了一倍多，而「合完又被回退」的比例反而下降了 40% 以上。

他们并没有取消 code review。他们把大部分「阅读」交给了机器，把人的时间留给判断。

00 先把三个数字摆出来

讨论 AI 写代码要不要 review 之前，先看一组公开数据¹：

最后一行最容易被误读：评论比例从 16% 涨到 54%，不是审核变严了，而是审核变多了——平均每个 PR 被读的遍数上升了，但读它的是机器。

这篇是我读完 Anthropic 官方那篇文章¹、又对着「马克的技术工作坊」那期 24 分钟的视频²逐段核对后的整理。视频把整个流程切成四段：PR 前、PR 中、合并时、合并后。我沿着这条线走，但每一步都补上原文里的具体机制和数字，最后给一份能直接照抄的落地清单。

01 旧流程不是「不好」，是撑不住

传统发布流程大家都熟：写代码 → 开 PR → 等人 review → 合并 → 发布。

它成立的前提是：代码量在人的阅读带宽以内。一个中等团队，每天几十个 PR，资深工程师一天读几份 diff，还能应付。

这个前提在 2025 年之后失效了。文章里写得很直白：当每天有 3 万次变更时，"manual, line-by-line code review is incredibly difficult if not impossible"（逐行人工 review 极其困难，甚至不可能）。

于是团队被迫回答一个更根本的问题：

「有人读过这段代码吗？」是一个不精确的代理指标。 真正该问的是：这次变更可能以什么方式出错，哪一道检查——自动的，还是人的——才是拦它的正确工具？

这句话是整个流程的转折点。它把 review 从「一个必须发生的动作」重新定义成「一组按风险分配的检查」。

随之改变的是 review 的位置。 以前 review 是路的尽头的一道闸门；现在它更像写作时的拼写检查——大部分变更在被人类看到之前，已经被 Claude 自己审过、改过至少一轮。

02 PR 之前：把「我做完了」换成「这是证据」

这一段视频给了 2 分 11 秒（02:58–05:09），我认为是全片最值钱的部分。

做法只有两条，都很朴素：

第一，给 Claude 一个能跑的东西，要它展示输出，而不是声称完成。

能跑的东西可以是测试、构建，也可以是一张要和设计稿比对的截图。视频里提到，这件事的推动者是 Claude Code 的作者 Boris Cherny，他估计这一步能让最终结果好 2 到 3 倍，并说过一句很实在的话：

"Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator." （验证的形态因领域而异：可能只是跑一条 bash 命令、跑一遍测试，也可能是在浏览器或手机模拟器里把应用点一遍。）

注意这里的顺序：先有可验证的反馈回路，再谈审查质量。 没有前者，后面的 AI 审核只是在评一份没人验证过的作业。

第二，用一个全新的上下文，让另一个 agent 只看 diff。

同一段对话里的模型会为自己的选择辩护，这是上下文带来的偏差。换一个空白的 subagent 只丢给它 diff，它才像一个真正的 reviewer。

第三条隐藏规则：重复出现的问题，回到源头修。

如果自动审核老是提同一类问题，正确的动作不是每次手动忽略，而是改源头：

原文档对 REVIEW.md 的要求写得很具体，值得抄：好的是短的；说明失败长什么样（文档类"它说谎了"，配置类"它导错了"）；限制挑刺的数量；要求给出文件和行号作为证据，而不是凭变量名猜；要求结论开头先说数量，没有可修的就直说没得修。

这一条其实在说一件事：review 的提示词不是玄学，是可以被工程化沉淀的。 每一次重复出现的问题，都应该变成一个规则。

03 PR 中：CI 之后，AI 审核的三道工序

进入 PR 之后，先是常规的 CI：lint、类型检查、各平台测试、构建。红灯直接阻断合并，一个典型的 CLI PR 在被人看一眼之前可能已经跑了几十项检查。

然后是视频里那 8 分 43 秒的重头戏（05:50–14:32）——AI 审核的三个步骤。

第一步：多个 agent 并行找 bug

不是让一个模型读完整个 diff 写一段总结，而是几个 agent 同时从不同角度找。读的范围是 diff 加上整个仓库的上下文，以及这个 PR 声称要解决的问题，问三个问题：

• 它解决了它说要解决的问题吗？
• 它和系统现有设计相配吗？
• 它会不会弄坏别的地方？

如果是 bug fix，还要追根因，而不是只补表面。

第二步：由另一组 agent 给每条发现投票

这是最容易被忽略、也最关键的工序。发现本身不算数，要过票。

几条 agent 同时找 bug，然后由另外一组 agent 对每条发现投票；只有足够多的人认为它是真的，才会被发出来。

为什么必须这样？因为单个模型的假阳性率高得离谱，而假阳性的成本在 AI 时代变了——见下一节。

第三步：排序、打标、去噪

过了票的发现，也不是平等地砸给作者：

• 按严重程度排序；
• 打三个标签：Important（重要）、Nit（吹毛求疵）、Pre-existing（本来就有的，不是这个 PR 引入的）；
• 纯风格、纯诊断、纯清理类的发现直接被丢掉。

最后那条「Pre-existing 标签」是个很小的设计，但很人性：它避免了「一个存在两年的 bug 被记在这个无辜的 PR 头上」。文章说得很清楚：这些过滤器他们是先在自己的 PR 上 A/B 测过才留下的。

一个必须配套的规则

每一条发现都必须被回应：要么修，要么带着理由 resolve。

没有这条，AI 审核就会退化成"评论区刷屏"，作者学会无视它。

效果数据¹：分级由仓库管理员设置（Quick / Standard / Deep），在1,000 行以上的 PR 上大多数都会有发现，而小的 PR 大多数干干净净回来。这个分布本身是健康的——审核的注意力没有被小改动吃掉。

04 最反直觉的一节：让审核「收敛」

视频里这一段占了 7 分多钟（07:16–14:32），是全片最不像"AI 宣传"、最像工程实录的部分。因为它讲的是这套系统怎么把自己搞坏，又是怎么修回来的。

问题：噪声在 agent 时代变贵了

噪声在老流程里没那么贵：人看到一条无意义的评论，两秒钟就划过去了。

但当作者也是 agent 时，成本结构变了：agent 不会"划过去"，它会老老实实去改，于是多一个 commit、多一轮 review、多一轮 CI。一条废话评论，换来一次完整的流水线。

文章里有个极端例子：

一个 CLI 的 PR，一夜之间跑了 50 多轮 review 和修复，最后是作者手动叫停的。

诊断：审核者并没有在找新 bug

团队后来对"审核者反复标记的东西"做了 git blame，结果很刺眼：

大约 59% 是被标记的代码，从第一轮审核时就已经在那里了。

也就是说，审核者并没有每轮发现新问题，它只是每轮多翻出一点旧问题。而团队自己也承认把他们坑了：

我们习惯性地默认跑好几轮，因为每一轮确实还能抓到点新东西。这在一次高风险变更上值得，但不是每个 PR 都值得。

四个改进

结果

这组数字值得多看一眼：减少轮次不是降低标准，而是让审核真正收敛。 一个会无限自我反驳的审核者，等于没有审核者。

闭环：把事故变成回归测试

这一段是我认为整套系统里最有工程味的设计：

1. 把所有造成过事故或回退的历史 PR 收集起来；
2. 让熟悉那块代码的工程师确认「bug 是什么、在哪」；
3. 入库成一个评测集，每天跑一遍 reviewer；
4. 任何对 reviewer 的改动（提示词、工具、模型）必须让分数上升才保留，否则丢弃。

同时他们用「人怎么处置这条评论」来量化噪声：修了 / 说它是错的 / 说这是有意为之 / 觉得无所谓。也拿已知干净的 PR 去跑 reviewer，数它误报了多少。

优先级是写下来的：先保证抓到真 bug，其次才是减少 review 轮次。

这套「事故即评测集」的做法，跟任何一个严肃做 ML 系统的团队该做的事一模一样。区别只是他们把 harness 用在了自己的开发流程上。

05 安全审核，和按风险分配的人

安全是一道独立的关，而且能阻断

不是"顺便看一眼权限"，而是独立的一遍自动审核。规则很清楚：

PR 不能合并，只要 bug 审核或安全审核里还有任何一条发现是打开状态。 要么修掉，要么带一句简短理由关掉线程（这就是清掉误报的方式）。

而且后续 commit 真的修好了，发现会自动消掉——不需要人去手动关。

人的审批跟着风险走，而不是跟着作者走

三级，由分类器根据变更内容判定：

有几个细节决定了这套东西能不能真的跑起来：

• 分级由变更决定，不由作者决定。 第二个分类器还会单独判断「这次变更是否即使分级说不用、也仍然需要一个人」。
• 某些路径永远要人：code owner 标记为敏感的、以及所有 CI workflow 文件。
• 只有可信作者能走轻路径（主要是拥有这个仓库的团队）；其他人一律需要第二个人。
• agent 的批准永远不算人的批准。 自动化可以清掉一个低风险变更，但不能顶替一个本该由人占的位子。
• 谁提的需求，谁就是签字的人。 agent 写的 PR 里，指挥 agent 的那个人算作必需的 reviewer 之一——跟亲手写代码一样担责。
• 一次批准只对一个 commit 有效。 后面来了系统无法背书的 commit（agent 推的、手解的合并），批准要重新给。

06 合并与上线：把「不可逆」变成「可逆」

这一步视频给了 3 分 30 秒（15:49–18:16），两件事：

合并队列（merge queue）。 队列会在最新的 main 上、带上你的改动重跑一遍所有检查。这样可以避免那个经典事故：两个 PR 单独看都能过，合在一起就坏。

上线三层缓冲：

1. 开关（flag）后面，先给自己人用。Anthropic 员工的大量使用，往往比用户更早暴露回归；
2. 分批发布：latest 渠道先走，stable 渠道跟在后面；
3. 快速观察，快速回退：开关不用发版就能关；构建坏了直接 revert；每周 on-call 轮值；事故复盘问的是「哪一层本该拦住它」。

文章还老实承认了一个缺口：

我们目前还没有「当回退率/事故率上升时，自动收紧审批」的断路器。团队里有人想要，尤其要在更多代码走向零人工合并之前。

对「慢一点是不是更稳」的问题，一位同事的回答被引用如下：慢下来确实会降低错误率，但那主要是因为你什么都没做那么多。他们宁愿练「更快发现和修复」。

07 那么人还剩下什么？

这一节对应视频 20:30 那段。原文列了五件事，我认为这是全篇最该被抄走的部分：

1. 决定要不要做。 方向、品味、范围。有个团队宣布自己"解决了 review 瓶颈"，但仍然保留了对外部提交的人工审查——因为总得有人问一句「这事我们真的该做吗」。
2. 审高风险代码。 计费、自动更新器、CI 工作流。
3. 审会形成范式的架构。 别人会照着抄的那种。
4. 读证据。 测试输出、跑的命令和返回、截图、审核者的发现。「如果你说不出这些检查会漏掉什么，就该要求一次真正的 review，而不是快速点个通过。」
5. 对结果负责。 每一个上线的变更都有人担责，不管是谁敲的。

还有一条文化层面的说明值得注意：机器读走了大部分代码，那新人怎么理解代码库？Anthropic 的答案是没人需要把整个代码库装进脑子里，想懂哪块就让 Claude 生成那一块的讲解，甚至生成一个可视化的教程——"几分钟，而且反映的是今天的代码"。

如果目标是让人的注意力花得值，这比逐行读一个改了一行文案的 diff 强太多。

08 如果你想在自己的项目里照抄：最小集

原文末尾给了一份清单，我按"投入产出比"重排了一下，前四项当天就能做完：

两条容易被忽略但很关键的：

• 风险分级要写下来，而且由变更决定。 一开始定严格，有证据了再放松。
• 永远不要让 bot 的批准顶替一个本来该由人给的批准，并且在新 commit 上作废旧批准。

09 我的判断

看完整个流程，我最大的感受是：它讨论的根本不是"AI 靠不靠谱"，而是"审核该往哪儿放"。

三个可以带走的结论：

第一，review 的稀缺资源是人的注意力，不是代码行数。 传统流程把所有变更都当作等价物，一律上前门排队；这套流程承认了变更之间风险差着两个数量级，于是把"有没有人读过"换成"这次变更最可能在哪儿出错、哪个工具拦得住"。

第二，可逆性比事前把关更划算。 开关、合并队列、分批发布、一键回退——这四样东西加起来，比多一道人工审批能挡住更多事故，而且不花人的时间。文章里那句「我们宁愿把发现和修复变快」就是这个意思。

第三，也是我最想强调的：审核者必须能收敛。 那个"50 轮"的例子说明，一个只会不断发现问题的审核系统，会在 agent 时代自己把自己拖死。他们把"一轮通过率"和"平均轮次"当成一等指标来优化——这和大多数团队只盯着"发现了多少 bug"是完全不同的取向。

至于那篇被反复引用的数字——90% 的代码是 Claude 自己写的——它真正说明的不是模型多强，而是：当写代码变便宜之后，贵的东西会立刻暴露出来。 这次暴露的是审核带宽，下次可能是别的。

参考

1. Addy Osmani, Morgan Westlee Lunt, Qing Wang. How the Claude Code team does code review. claude.dev Blog, 2026-10-15. https://claude.dev/blog/solving-code-review-at-anthropic/
2. 马克的技术工作坊.《从写代码到上线，一套保证产品质量的全流程》. 抖音, 2026-10-26，时长 24:34. https://v.douyin.com/yPrhc280NVU/
3. Anthropic. Code Review for Claude Code / /code-review、/security-review 命令与 GitHub Action 文档。
4. Boris Cherny 关于 verification 的表述，转引自文献 1。