Anthropic 的代码审查：把阅读交给机器，把人留给判断

三、一个变更的生命周期：七层，不是一道门

原文用一张纵向流程图展示了完整路径。把七个层折成一张表来看，各层的分工与失败模式更清楚：

层	位置	由谁执行	拦截什么
1. 工作先自证	PR 出现之前	Claude 加一个全新上下文的子智能体	「说做完了但其实没跑过」这类最常见的问题
2. 必需 CI	每个 PR	lint、类型检查、全平台测试、构建与打包	编译不过、测试红、跨平台回归
3. Claude 代码审查	每个 PR	多个智能体并行找 bug，另一组投票验证	逻辑错误、不符合系统设计、意图没达成
4. 安全审查	每个 PR	独立的一轮自动化审查	漏洞、不安全的数据处理
5. 人工审批	按风险分级	0 人、1 人或 2 人	机器不擅长判断的问题
6. 合并队列与标志开关	合并时	队列对最新 main 重跑全部检查	两个各自通过的 PR 合在一起把 main 弄坏
7. 快速发现与回滚	合并之后	标志开关、值班、仪表盘	前六层都没拦住的问题

值得强调的是第 6 层存在的理由：合并队列会把每项检查在「最新 main 加上这个变更」的条件下重跑一遍。单独测试都通过的两个 PR，合起来可能弄坏 main，这是流水线式审查的经典漏洞。另外新行为通常先藏在标志开关后面给 Anthropic 员工自己用，他们自己的重度使用往往比用户更早暴露回归。

四、逐层拆解：三个最值得抄的作业

第 1 层：在 PR 出现之前就完成大部分审查

这是整篇里最反直觉的一层：大部分审查现在发生在 PR 不存在的时候。做法是给 Claude 一些它能运行的东西——测试、构建，或者一张可以对照设计稿的截图——然后要求它展示输出，而不是宣称自己做完了。之后一个子智能体以全新上下文审查这个 diff。

Claude Code 的创建者 Boris Cherny 把「给 Claude 一个验证自己工作的方式」称为拿到好结果的最重要的单一因素，他估计这让最终结果好两到三倍。他还写过一句值得贴在墙上的话：验证的样子因领域而异，可能只是跑一条 bash 命令、跑一遍测试套件，或者在浏览器和手机模拟器里把 app 用一遍。

这一层还有一条容易被漏掉的机制：当自动审查者反复标记同一个问题时，他们在源头修——改进技能、加一条 lint 规则、或者更新教学文件。这里有两份关键文件：

• CLAUDE.md 告诉 Claude 这个项目是什么：技术栈、约定、目标与非目标。每次审查都会加载它，所以在大代码库里要短，从它指向其他文档。审查者还会标记破坏其中约定的代码，以及让其中某行过时的变更。
• REVIEW.md 由代码所有者撰写，告诉审查者他们那部分代码里什么要紧。好的 REVIEW.md 很短：说清那个仓库里的失败长什么样（文档仓库是「它撒谎」，配置仓库是「它把路由指错」），给 nit 设上限，列出要跳过的路径，要求给出文件与行号作为证据而不是凭名字猜，并要求摘要以计数开头、没东西可修时直说。

换句话说，他们把「审查者的行为」本身当作可工程化的资产在维护，而不是每次重新提示一遍。

第 2 层：并行找 bug 加投票验证

每个 PR 在人看之前都会先得到一轮 Claude 审查。它读 diff，对照整个仓库和 PR 陈述的意图，问三个问题：这个变更是解决了自己的问题、适配了这个系统，还是弄坏了别的地方？修 bug 时它追根因。

真正有设计感的是验证机制：若干个智能体同时找 bug，然后另一组独立的智能体对每一条发现投票，只有足够多的投票认为它真实，这条发现才会被贴出来。纯风格、诊断信息、清理类的发现直接丢弃。这些过滤器在他们自己的 PR 上做过 A/B 测试才保留。幸存者以行内评论的形式按严重度排序，每条标注 Important、Nit 或 Pre-existing——最后这个标注很重要，它让一个不是这个 PR 引入的 bug 看起来不像作者的错。

两个数字可以说明这套的成熟度：研究预览上线时，内部 PR 拿到实质性审查评论的比例从 16% 升到 54%；超过 1,000 行的 PR 大多数会拿到发现，而小 PR 大多数干净返回。管理员可以把每个仓库设为 Quick、Standard 或 Deep 三档，Deep 用在「漏一个 bug 的代价高于多花审查时间」的地方。

第 5 层：风险分级，而不是按人分级

人工审批是整套设计里唯一还由人拍板的地方，而他们的做法是把它也变成一道可计算的关卡：一个分类器读变更、定风险档，第二个分类器再问一句「这个特定变更即使在它的档位下不需要别人，是否仍需要另一个人」。风险由变更本身决定，不是由作者决定。

风险档	典型例子	需要几人审批
低	文档、文案、仅内部可见的功能、标志开关后的加法式变更	自动化审查与安全检查全绿后，无需人
中	普通产品变更，以及敏感区域的变更：缓存、自动更新器、系统提示词	1 人
高	风险最高的代码，加上一小撮永远需要两人的路径	2 人

四条补充规则值得逐条记下来：只有受信任作者能走轻量路径（主要是拥有该仓库的团队），其他所有人都需要第二个人；智能体的审批永远不算一个人的——自动化审查可以清掉一个低风险变更，但不能填上一个要求人签字的格子；在智能体写的 PR 上，指挥智能体的人算作必需审查者之一，跟他自己敲了这些代码一样；审批只覆盖某一个特定提交，如果之后落了系统无法背书的新提交（比如智能体的推送或人工解决的合并冲突），审批必须重新给。

五、让审查者变得更好：事故就是评测集

如果说前面是流程，这一节讲的是流程本身如何被迭代，也是全文最有迁移价值的部分。

团队把过去引发事故的 PR、它们的向前修复和回滚都收集起来，让了解那些代码的工程师逐个确认 bug 确实存在、以及它当时住在哪里。审查者每天对着这个集合跑一遍。于是每一次事故都让评测集长大一分，而审查者（它的提示词、工具或模型）的任何改动，都要对着全部案例重新计分——分涨了才留，不涨就丢。

这套东西把「审查者好不好」从主观感受变成了可回归的工程指标。它和机器学习里的评测集是同一个思想，只是被用在了审查策略本身上。

噪声怎么量：看人对评论做了什么

只追召回是不够的——想多抓 bug 太容易了，只要不介意标出一大堆非 bug。所以他们的反制措施是按人对每条评论的实际反应排序：他修了它、他说这是错的、他说这个行为是有意的、或者他觉得无所谓。他们还会把审查者跑到已知干净的 PR 上，数它多久会报出一个「会害人做出有害改动」的东西。

白纸黑字写下来的优先级是：先抓真 bug，再砍审查轮次。这个排序值得注意，它意味着他们接受为了召回牺牲一部分效率，但不接受反过来。

而噪声在作者是智能体时代价更高：一个人几秒钟就能挥掉一个 nit，智能体会把它修掉——于是多一个提交、多一轮审查。这一句是理解后面「收敛」问题的钥匙。

六、收敛问题：全文最重要的发现

这是我读完全文后认为最值得单独拎出来的部分，因为它记录了一个真实的失败，而且这个失败模式只会在智能体同时当作者和审查者时出现。

智能体作者和智能体审查者可以把彼此无限期地耗下去。有一个 CLI PR 在一夜之间经历了五十多轮审查与修复，最后是它的作者主动叫停的。当他们用 git blame 去查审查者反复标记的到底是什么，发现约 59% 的代码从审查者第一遍起就在那里。审查者很少在找新 bug，它只是每轮又多找出几个老的。

更诚实的是下一句：这个局面有一部分是他们自己造成的。因为团队已经习惯了默认多跑几轮——每跑一遍总能抓到点什么。这在风险高的变更上是值得的，但没必要每个 PR 都这么干。

他们的修法是四条，每一条都对应上面诊断出的一个病因：

• 轮次上限。三轮之后，审查者要求作者退回来重新考虑整体做法，而不是继续在细节上打转。
• 前几轮之后只复审 diff。新增的那部分，而不是整个文件。
• 标记 bug 的类别，而不是那一行。让作者修掉全部实例，避免同一类问题逐条消耗轮次。
• 不重复已贴出的发现。

指标	改造前	改造后
一轮审查加修复即通过	65%	78%
需要五轮或更多	8.9%	1.5%
平均审查轮次	2.08	1.32

需要五轮以上的 PR 降到一个半百分点，这个量级的变化说明「多跑几轮总没坏处」的直觉错得相当厉害。另外他们还让审查智能体每晚巡检存量代码，在老 bug 跑到别处之前先抓出来。

七、人留在哪里：五类决策

把高级工程师从深度工作里拽出来抓一个常规错误，代价远高于一轮自动审查。Anthropic 的岗位内容已经从「读每一个 diff」变成机器干不好的决策：

• 该不该做这件事。方向、品味与范围。有个团队宣布自己的审查瓶颈已解决，但仍保留对外部来的变更做人工审查，为的是有人问一句「我们到底该不该做这个」。
• 风险代码。计费、自动更新器、CI 工作流。
• 架构。会立下别人效仿的模式的那些改动。
• 阅读证据。测试输出、跑过的那条命令及其返回、一张截图、审查者的发现。原文给了一个很好的自检：如果你说不出这些检查会漏掉什么，就该去要一次真正的审查，而不是快速点个批准。
• 拥有结果。每一个上线的变更都有一个人负责，不管代码是谁敲的。

八、被放弃的那件事：代码上下文怎么传

文章开头承诺过要回到审查的第二个职责——在团队里传播对代码库的理解。他们的答案是全文最激进的一段：没有正式流程。团队里没有人能在脑子里装下 Claude Code 的完整模型，而且他们认为没人需要装下。

当有人想理解代码库的某一块，他让 Claude 给那一块写一份解释器，几分钟出稿，反映的是代码今天的样子。有些人更进一步，让 Claude 做一个小可视化工件，按他喜欢的学习方式讲给他听。他们的论证很直白：如果目标是花好人的注意力，这胜过逐行读无关紧要的 diff——改一行文案几乎教不了你任何东西，而一份「你即将修改的那个模块」的解释器教得了你很多。

默认在公开 Slack 频道里工作的文化也帮了忙：你在别人构建的同时就看见他们在造什么。

九、「你落地，你拥有」与改方向

落地一个小或中等变更后如果还是出了问题，团队规范是你通常得去修它。这条规范没有变糟糕，靠四件事兜底：变更足够小所以好审查好调试好回滚；一切都可逆（标志开关、回滚、分级发布几分钟内撤销大多数错误）；爆炸半径决定门槛，贵的代码配更多人和更多检查；回归通过遥测和内部使用快速浮出水面。原文特别强调这不是追责——拥有修复权意味着你手里上下文最全，而事故复盘看的是系统。

智能体让「开始一件事」变得极便宜，于是有些工作压根不该落地。他们的做法是在频道里有人问一句为什么、指着一个早先的决定、或者建议一条更简单的路，作者就关掉或重塑 PR。由于代码写起来快，关掉 PR 也不会让人觉得是损失。诀窍是在帖子里早点提出不同方向，而不是等 PR 做完了再发一条阻塞性评论。

十、怎么照抄：一份清单

原文给了一份相当具体的采纳路径，基本今天就能动手：

• PR 之前：给智能体可运行的检查并写进一份简短的 CLAUDE.md；用 hook 跑格式化与 lint；本地跑 /code-review 与 /security-review，或用全新上下文的子智能体审；加一份 REVIEW.md，并把反复出现的审查评论挪进去。
• 每个 PR：要求 CI；PR 模板里加「测试情况」「风险」「怎么回滚」三项；先在一个仓库上 AI 审查者、调几周 REVIEW.md 再铺开；加自动安全审查，要求所有审查线程合并前解决；审查投入与风险匹配；设轮次上限，前几轮之后只复审新 diff。
• 审批：把风险档写下来，由变更而非作者决定，先严后松；轻量路径只留给受信任作者；用 CODEOWNERS 与分支保护，让认证、计费、CI 与发布工作流、安装包永远需要人；绝不让机器人的批准替代一个必需的人；新提交落下时作废旧批准。
• 合并与之后：用合并队列、功能标志、内部先用、分级发布与一步回滚；把事故与回滚变成评测集，审查者的提示词、工具或模型一变就重新计分；度量人的时间，用回滚率与事故率当护栏。

十一、去向何方，以及几句批评

产品的态度留了一道口子：Code Review 的公告说批准 PR 仍是人的决定，产品只贴发现、不给批准。但他们自己的仓库走得更远——允许所有者决定哪些低风险变更仅凭自动化检查合并，而且这条线在持续移动。当一次审查漏了东西，他们问的是「模型当时眼前缺了什么」，然后把补救写进 CLAUDE.md、一个技能或一条新检查。

最后是几句必须说的批评，因为这是一篇工具供应商的第一方博客：

• 所有数字都是自报的。PR 翻倍、回滚降四成、16%→54%、65%→78%、平均 2.08→1.32 轮，全部来自 Anthropic 自己的仓库与仪表盘，没有第三方复现，也无法外部审计。作为供应商博客这很正常，但引用时应当标注口径。
• 最强的几个数字有不可复制的成分。他们同时拥有模型、产品、审查者和那个单体仓库；「受信任作者走轻量路径」和「指挥智能体的人算审查者」都依赖一个彼此深度信任的小团队。搬到普通公司时，这几条最有效的规则可能最先失效。
• 缺口是承认了的，但还没补。他们还没有「熔断器」——在回滚与事故数字异动时自动收紧审批的机制。工程师们希望在更多代码走向零人合并之前把这东西做出来。换句话说，这套系统目前仍依赖值班的人盯着仪表盘，而不是自动降级。
• 收敛问题的解法是流程补丁，不是根治。轮次上限、只复审 diff、不重复贴发现，都是在约束一个仍然可能打转的循环。59% 这个数字说明审查者反复盯的是存量代码，那么「审查者对自己的历史发现做去重与优先级管理」显然还有工程空间。

尽管有这些保留，这篇博客仍然是我今年读到的关于「智能体时代的软件工程」最实的一份材料。它没有把 AI 审查讲成银弹，而是给出了一条可度量的中间路线：把机器能读的交给机器，把人读不好的留给人，并且永远用回滚率和事故率验证自己有没有真的省下时间。最后这一句，可能是整篇文章里最该被抄走的一句话。