Claude Code 团队如何进行代码审查：七个步骤，不设熔断机制

2026年10月15日，Claude Code 团队发布了自己关于如何审查代码的说明，这是一篇阅读时长十四分钟、署名 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 的工程文章。文章开头不久就出现了一句话，解释了为什么有人会去搜索这件事：Claude 编写了 Claude Code 自身约 90% 的代码。这篇文章不是在为这个数字辩护，而是在描述：在它变得可承受之前，其底层必须存在的那套机制；而值得细读的部分，恰恰是仍然缺失的那些。

大多数总结都止步于两个头条数字：2026年6月至9月间，合并到 Claude Code 代码库的拉取请求数量增长了一倍多，而不得不回滚的比例下降了40%以上。这两项数据都来自团队自身，也都可能由多种不同的安排造成，包括人们所假设的那种——评审被悄悄取消了。文章说并非如此。他们把大部分阅读工作交给了机器，围绕人类的时间与注意力进行优化，并投入于让错误能够快速、轻松地撤销。其余一切都只是具体做法的细节。

为什么审查一开始就成了瓶颈

压力并非来自政策决定，而是来自数量。文章称，在 Anthropic 的 monorepo 中，每天落地的变更量从 5 月的约 2,500 项增加到 2026 年 9 月的超过 30,000 项。Claude Code 位于自己的代码库中，与该 monorepo 分开，但它也承受着同样的压力，只是规模较小。

事已至此，帖子承认，逐行人工审查即便并非不可能，也极其困难。那里没有人声称人工阅读每一处差异是不必要的。他们是在说，阅读每一处差异已经无法扩展，而“是否有真人读过代码”从来都只是对真正重要问题的不精确替代指标：这项改动可能出什么问题，而哪一种检查——自动的还是人工的——才是抓住它的正确方式。

一旦这样表述，关卡的位置就变了。评审不再是道路尽头的一扇门，而变成持续进行的环节，更像你写作时的拼写检查。大多数更改在有人查看之前，已经由 Claude 阅读并修复。

他们针对什么进行了优化，以及什么算作失败

既定目标是：Claude Code 各代码仓库（文章将其描述为 CLI、桌面端和 Web 应用以及移动应用）中的大多数拉取请求，在最多只有一名人类参与（且该人可以是作者本人）的情况下完成合并，同时不增加回滚或事故。第三个条件正是使它成为真正目标、而非削减成本举措的原因。

他们从账本两端衡量人的时间：人们花在审查上的时间，以及花在修复坏代码所破坏的东西上的时间。如果成本在第二项上重新出现，削减第一项就无济于事，团队也直接这么说。因此，追踪的数字是每个拉取请求的人工批准次数（以中位数和95百分位报告）、人工评论数，以及拉取请求等待某个人的时长。回滚率和事故率位于这一切之下，作为护栏：如果这些上升，人的时间就没有被节省，只是被转移了。

审查成本指标孤立来看很容易被钻空子；一个什么都批准的审查者能画出漂亮的批准耗时图表。护栏才是防止图表说谎的关键。

七个步骤，而非一道关卡

这篇文章把一次典型变更的路径展开为七个编号步骤。每一层都会发现一些问题，也会漏掉另一些问题，而且较便宜的检查会先于较昂贵的检查运行。

• 在创建拉取请求之前进行验证。Claude 会运行测试、构建和 linter，第二个智能体会在全新的上下文中审查差异。许多工程师还会运行内部技能：一个查找 bug，一个简化差异，一个端到端检查行为。Claude Code 的创建者 Boris Cherny 曾表示，让 Claude 能够验证自己的工作，可能是取得良好结果最重要的一件事，并估计这能让最终结果提升两到三倍。

• 每个拉取请求都有 AI 审查。Claude 的审查会将代码差异与整个仓库以及拉取请求所声明的意图进行对照阅读。多个智能体会并行查找缺陷，然后由另一组智能体对每个发现进行投票，只有在足够多智能体认为确有其事时才会发布。关于风格、诊断或清理的发现会被丢弃。保留下来的内容会以行内评论的形式出现，并标记为“重要”、“小问题”或“既有问题”。在该研究预览版发布时，获得实质性审查评论的内部拉取请求比例从 16% 提升到了 54%。管理员可将每个仓库设置为“快速”、“标准”或“深度”。

• 安全审查。 单独的一轮自动化检查。只要任一审查中有未解决的发现，拉取请求就不能合并；你要么修复它，要么附上简短理由关闭该讨论串。同一项检查以开源的安全审查 GitHub Action 或 /security-review 命令的形式公开可用。

• 会阻塞的自动化检查。Lint、类型检查、各平台上的测试，以及构建。

• 人工审批，按风险分级。分类器会读取变更并设定层级，而不是由作者设定。这一步在下方有单独的一节，因为大部分有意思的设计都在这里。

• 合并队列、功能开关与渐进式发布。 队列会在应用变更后，针对 main 重新运行每一项检查，因此两个各自通过的拉取请求不会合并成损坏的 main。新行为会先通过功能开关向 Anthropic 员工发布，然后发布到 latest 渠道，stable 渠道随后跟进。

• 快速检测与回滚。功能开关无需部署即可关闭，每周有值班轮换，事故复盘会追问本应由哪一层发现该问题。有些错误仍会漏过，因此最后一层的作用是尽快发现它们，而不是阻止它们。

该变更设定的是层级，而不是作者

文档修复和自动更新程序变更带来的风险并不相同，因此它们不会得到相同的审查。文章中的表格分为三个层级，每个层级只回答一个问题：在合并之前，需要多少人（如果有的话）批准这项变更。

低涵盖文档、文案、仅限内部使用的功能以及功能开关后的增量变更；一旦自动审查和安全检查通过，就无需人工。中涵盖普通产品变更以及缓存、自动更新器和系统提示等敏感领域，需要一个人。高涵盖风险最高的代码以及一小部分始终需要两个人的路径。

分类器只是设计的一半。第二个分类器会判断：即使某项变更的层级显示不需要，它是否仍需另一个人参与。有些路径无论层级如何都始终需要人：所有者列为敏感的任何内容，以及任何 CI 工作流文件。只有位于仓库信任列表上的作者——主要是所属团队——才能走更轻量的路径；其他所有人都需要第二个人。代理的批准永远不能算作人的批准，因此自动化审查可以放行低风险变更，但无法填补需要人类的名额。谁发起了这项变更，谁就要对它负责。而且一次批准只覆盖一个特定提交，所以新提交——包括代理推送或手动解决的合并——都需要再次获得批准。

有两个细节值得借鉴，即使你从不构建分类器。等级来自变更本身，而不是作者；信任则是叠加在其上的另一道更窄的门槛。并且，批准绑定到某次提交，而不是某个拉取请求，这堵上了评审系统中最常见的漏洞：在分支早期获得的绿色对勾，被用在了没人看过的代码上。

审核员会以自身发生的事件为鉴接受培训

这是大多数文章都会略过的部分，而它恰恰解释了为什么这种安排能够持续奏效，而不是逐渐走样。

团队收集了过去引发事故的拉取请求，以及这些请求的后续修复和回滚，并让熟悉那段代码的工程师确认每个 bug 及其所在位置。这个集合现在成了一个评估集。评审器每天都会针对它运行。当其提示词、工具或模型发生变化时，改动必须能通过整个集合的检验：分数上升就保留，否则就丢弃。他们的失败变成了本应捕捉这些失败之物的测试套件。

这与调校 linter 是两种不同的姿态，后者依据固定规则集来评判。这个审查器则是依据此代码库已经出问题的具体方式来评判的，所以每当哪里出了问题，评估集就会增长。在我们读过的 Anthropic 发布的任何内容中，都没有出现它的分数，而且文章也没有声称该审查器已经完成。

尚未构建的层

这就是让这篇文章可信的坦白之处。以上所有内容描述的是一个能发现并逆转错误的系统，而不是一个能察觉自身错误率变化的系统。该团队目前还没有这样的熔断机制：当回滚或事故数量变化时，它能自动收紧审批；那里的工程师希望在更多代码转向零人工合并之前先拥有这些机制。

真正取而代之的是人的察觉。开关无需部署即可关闭，每周的值班轮换负责盯守，事故复盘会追问本应由哪一层发现该问题。一位同事的话，对任何计划类似推广的人来说都是最有用的：放慢速度确实能降低错误率，但主要还是因为你把每件事都做得更少了。团队宁愿更快地发现和解决问题，也不愿更慢地制造问题。

带着这一点再读一遍那七个步骤。其中六个决定一项变更是否继续推进。第七个是一套事后留意的习惯。系统并没有把结果回接到关卡上的反馈回路，而构建这套系统的人自己也这么说。

《评论》的第二项任务，文章基本上将其搁置一旁

这篇文章明确指出，代码审查有两项工作：在发布前发现并修复问题，以及在团队中建立共享上下文。文章重点讨论第一项，随后又以异常坦诚的回答回到第二项：对此没有正式流程，没有人会在脑中保留 Claude Code 的完整心智模型，而且他们认为也不需要有人这样做。想了解代码库的某一部分？直接让 Claude 针对那一部分做讲解。

有两个指令文件承载着过去只存在于评审者头脑中的上下文。CLAUDE.md 告诉 Claude 这个项目是什么、技术栈、约定、目标与非目标，并且刻意保持简短。REVIEW.md 由代码所有者撰写，说明在他们负责的那部分代码中，失败是什么样子、应跳过哪些路径，并要求给出文件和行号，而不是凭猜测下结论。

责任单独成一条：你合入它，你就负责它。合入一个小型或中型变更后出了问题，默认规范就是由你来修复。这之所以可行，是因为变更很小，因为功能开关和回滚能在几分钟内撤销大多数错误，也因为影响范围决定了一项变更需要多少检查。它是在审批规则之上叠加的规范，而不是对审批规则的替代。

路由器适合用在哪里，又不适合用在哪里

上面的流水线是一条模型调用流水线：一个审查代理读取针对整个仓库的差异，多个缺陷搜寻代理并行运行，一个小组对每个发现进行投票，一次安全审查，以及审查器每天针对不断增长的评估集重新运行。这首先是一个路由问题，然后才是审查问题，因为某个提供商下午状态不佳不应该阻塞合并队列。

OrcaRouter 是一个兼容 OpenAI 的端点，用一个密钥即可调用 200 多个模型，支持跨提供商自动故障转移，并且零加价，即按提供商的标价原样透传。运行自己版本这条流水线的团队只需维护一个计费关系，并在评审者质量发生变化时，在一个地方切换模型，而这正是每日评估旨在检测的内容。

这个边界很重要。我们托管模型。我们不托管 Claude Code，也不为 Claude Code 运行 Code Review，并且我们无法访问本文所讨论的那条流水线。Code Review for Claude Code 是 Anthropic 的产品，已在 Team 和 Enterprise 套餐中正式提供，另有一个更轻量的版本以 /code-review 的形式在本地可用。如果你想要的是那条流水线，它就在那里；而在你自己团队的那套版本里，路由器属于管道层面的决策，而不是评审层面的决策。

规模更小的团队实际上能复制什么

把评审规则写在评审者能读到的地方：为项目写一份简短的 CLAUDE.md，为每个领域写一份 REVIEW.md，在其中明确指出失败是什么样子，并要求给出文件和行号，而不是靠猜。把风险等级写下来，让它们成为变更本身的属性，而不是作者的属性；一开始从严，只有凭证据才放宽。限制自动评审可以批准的范围，绝不能让智能体的批准等同于人的批准。把批准绑定到提交。运行合并队列。把事故和回滚转化为测试用例，并在每次改动评审器时重新给它评分，因为未经衡量的评审器不过是营销做得更好的 linter。

那就关注护栏，而不是审批时间。团队自己的表述为你提供了检验任何正在考虑的评审流程变更的方法：回滚率和事故率是保持住了，还是时间只是从评审者转移到了事后清理的人身上？这个问题用大多数团队已经拥有的数据就能回答，也能区分出真正变快的流程和只在一个季度里看起来更快的流程。