Claude 写了90%的代码，那谁来做 code review？Anthropic 的答案是：大部分 PR 最多一个人过目

前几天 Anthropic 刚讲完他们怎么重造 git，昨天 Claude Code 团队又发了一篇姊妹篇，回答下一个问题：代码是 agent 写的，review 谁来做？

背景数字先摆出来。Claude Code 自己的代码约 90% 是 Claude 写的。6 月到 9 月，合并进代码库的 PR 数量翻了一倍多，需要回滚的比例反而降了 40% 以上。

质量没塌，review 却不可能逐行人工看，他们怎么做到的？这篇 14 分钟的博文把整套流程拆开了。我读完觉得最有价值的不是某个工具，而是他们重新定义了 review 的目标：把"人读过代码吗"换成"这个变更会出什么问题，哪道检查（自动或人工）最适合抓住它"。

以及一个明确的北极星指标：大部分 PR 合并时最多一个人在环里（这个人可以就是作者本人），同时回滚率和事故率不许上升。人力的节省不看"少看了多少代码"，看每个 PR 的中位和 P95 人工审批数、人工评论数、等人时长。回滚和事故是护栏，护栏动了，说明你不是省了人力，只是把成本挪了个地方。

一、一个变更的一生：从作者机器到用户手里

先看全景。一个典型变更要过的关卡，从写代码那一刻就开始了：

▲ 全流程图。圆圈是自动化，菱形是"按风险分级的人工决策"，回旋箭头是事后恢复（图源：claude.dev 原文，下同）

注意这张图里最反直觉的一点：整条链路里只有"风险分级审批"一个环节是人工的，其他全自动。review 不再是终点的大门，而是像拼写检查一样全程伴随。大多数变更在请人看之前，已经被 Claude 审过并修过至少一轮了。

二、为什么是"层"，而不是"门"

他们的哲学一句话能说清：没有一道检查是完美的，所以叠六层，每层拦住一部分漏掉一部分，能连穿六层的问题少之又少，真漏过去的靠快速回滚兜底。

▲ 六层检查：验证、强制 CI、AI 评审、安全评审、人工审批、合并队列+开关，底下是快速回滚

逐层拆开：

第 0 层，PR 之前就验证。给 Claude 一个能跑的东西（测试、构建、和设计稿对比的截图），让它拿输出证明自己做完了，而不是听它说"做完了"。然后另一个全新上下文的 subagent 审 diff。Claude Code 的创造者 Boris Cherny 说过，让 Claude 能验证自己的工作大概是最重要的一件事，他估计这能让最终结果好两到三倍。

AI 评审跑在每个 PR 上。多个 agent 并行找 bug，另一组 agent 对每个发现投票，票数不够就不发。纯风格、诊断、清理类的发现直接丢弃。留下来的按严重度排序，打上 Important / Nit / Pre-existing 标签，免得一个旧账看起来像 PR 作者闯的祸。而且每个发现必须有下文：要么修，要么给理由关闭。经常一个 agent 连夜就把修复做了，作者第二天回来看到的是一个又过了一轮的 PR。

效果如何？研究预览版上线后，内部 PR 获得实质性评审意见的比例从 16% 涨到 54%。超过 1000 行的 PR 大多会被抓到问题，小 PR 大多是干净的。

安全评审单独一道，也能卡合并。bug 评审或安全评审有任何未关闭的发现，PR 就不许合。误报就用一句理由关掉线程。后续的 commit 修掉了问题，发现会自动清除。

人工审批按风险分级。这部分设计得很细，值得展开：

分级器读变更内容来定级，不是看作者面子。低风险（文档、文案、开关后的新增功能）：自动评审和安全检查全绿就能合，不需要人。中风险（普通产品变更、缓存、自动更新器、系统提示词）：一个人。高风险和一小批敏感路径：两个人。发起变更的人对结果负责，agent 写的 PR 也算在他头上；agent 的"批准"永远不算数；批准只对特定 commit 有效，来了新 commit 就得重新批。

合并之后还没完。合并队列把检查在最新 main 上再跑一遍，防止两个各自通过的 PR 合体出事。新功能先开 flag 给 Anthropic 员工用，公发先走 latest 频道，stable 殿后。出了问题，flag 不用部署就能关，构建坏了直接回滚。

三、评审器自己也要被评审：事故就是 eval

这段是我觉得全文方法论含量最高的部分。

他们把历史上引发过事故的 PR 连同修复和回滚收集起来，让熟悉那段代码的工程师确认每个 bug 真实存在、定位在哪，做成一个 eval 集。评审器每天在这个集子上跑分，改提示词、换工具、换模型，涨分才留，不涨就回退。每出一次新事故，集子就多一个案例。

噪音怎么管？盯人对评论的反应：修了、说错了、说行为是有意的、还是无所谓。再把评审器放到已知干净的 PR 上跑，数它误报多少。他们写下来的一条优先级是：先抓真 bug，再减评审轮次。

为什么要专门管噪音？原文一句话点破：作者是人的时候，一个 nit 瞟一眼就挥掉了；作者是 agent 的时候，它会真的去修，于是又产生一个 commit、又触发一轮评审。AI 时代，误报的成本翻倍了。

四、一个写、一个审，会无限循环下去

真实事故：一个 CLI 的 PR，agent 作者和 agent 评审互相折腾了一整夜，50 多轮，最后被作者手动叫停。

他们追查了一下评审器到底在报什么，对标记的代码跑 git blame，发现约 59% 是评审器第一轮就在那儿的旧代码。它不是每轮发现新 bug，是每轮从旧账里再翻出来几个。团队自己也有责任：他们习惯了默认多跑几轮，反正每轮都有新发现。

改进措施四条：三轮封顶，到顶就让作者退一步重新想方案；头几轮之后只复审新 diff；发现的是一类 bug 就修一类，不许只改一行；已发过的发现不许重复发。

▲ 收敛改造前后：一轮通过 65%→78%，五轮以上 8.9%→1.5%，平均轮次 2.08→1.32

五、人还在环里，只是换了位置

把一个资深工程师从心流里拽出来抓一个低级错误，代价比自动评审高得多。所以人的位置挪到了机器不擅长的五件事上：

▲ 五个决策留在人手里：要不要做、高风险代码、架构范式、读证据、为结果负责

该不该做这个需求（方向、品味、范围）；高风险代码（计费、自动更新器、CI 工作流）；会被别人抄的架构范式；读证据而不是读代码（测试输出、跑了什么命令、截图、评审发现）；以及为结果负责，谁按的合并谁兜底。

原文还有句很实在的提醒：如果你说不清这些检查会漏掉什么，那就别快速批准，要一次真正的评审。

六、机器做了大部分阅读，人怎么学代码？

Code review 有两个职能：拦 bug，以及在团队里传播对代码库的理解。第二个职能怎么办？

他们的答案挺激进的：没人需要在大脑里维护整个 Claude Code 的完整心智模型。想理解某块代码，让 Claude 给这一片写一篇讲解，几分钟，反映的是今天的代码。有人更进一步，让 Claude 做一个可视化的小 artifact，按自己喜欢的学习方式教。

▲ 逐行读一行文案改动几乎学不到东西；给你要改的模块写一篇讲解，学到很多

配套文化也跟上了："You land it, you own it"，你合入的你修，但不是追责文化，事故复盘看的是系统哪一层该拦住。变更都小、都可逆、回归靠遥测和内部重度使用快速浮出。还有默认在公开 Slack 频道工作，别人能看到你在造什么，反馈可以来自不拥有这段代码的人。

七、我的几点想法

第一，这篇和前几天那篇 Scion 要连起来读。Scion 解决的是"代码太多 git 扛不住"，这篇解决的是"代码太多人看不过来"。一个管存储和分发，一个管质量闸门，合起来就是 agent 规模软件开发的完整基础设施图景。下一篇该轮到 CI 了，原文已经埋了伏笔。

第二，"评审必须收敛"这条对所有用 agent 的人都成立。两个 agent 互相挑错可以无限循环，这不只是工程问题，是所有 agentic 工作流的通病。三轮封顶、只审新 diff、按类不按行，这三条可以直接抄。

第三，最值得抄作业的是度量框架：目标是"最少人工时间不抬升回滚率"，而不是"自动化率"。很多团队做 AI 提效汇报时爱讲后者，前者才是生意。

第四，人类评审的五块保留地，本质是"品味 + 责任"。机器能写出能跑的代码，但"该不该造"和"出了问题谁扛"，目前还是得人来。这个边界会移动，但移动的方向是清楚的：人往更上游走。

参考：claude.dev Blog, "How the Claude Code team does code review", 2026-10-15。文中数据与图表来自原文，图片版权归 Anthropic 所有。