Claude Code 团队重构代码审查：机器读码替代人工，合并量翻倍且回滚率降四成

我们此前曾提到，Claude Code 自身代码中约有 90% 是由 Claude 编写的。那么，在如此庞大的产出量下，我们如何进行代码审查？还有人真正去阅读代码吗？如果出了问题，谁来兜底？

本文介绍了 Claude Code 团队的代码审查流程及其演变过程。从 6 月到 9 月，合并到 Claude Code 代码库的 Pull Request 数量翻了一倍多，而需要回滚（revert）的比例则下降了超过 40%。

我们并没有取消代码审查，而是将大部分“阅读”工作交给了机器，以优化人类的时间和注意力分配，并投入大量资源以确保错误能够快速、轻松地被撤销。

重新思考代码审查的目的

当 Agent 开始编写代码时，变更数量会迅速激增。今年，Anthropic 单体仓库（monorepo）中每日落地的变更量已从 5 月的约 2,500 次增长至 9 月的超过 30,000 次。

Claude Code 拥有独立的代码仓库，与单体仓库分离，但也面临着巨大的压力。当你以这样的速度进行交付时，逐行的人工代码审查不仅极其困难，甚至几乎不可能实现。

代码审查主要承担两项职责：

1. 在发布前发现并修复问题
2. 在团队内部建立共享上下文和对代码库的共同理解

本文主要聚焦于第一项职责——发现并修复问题，但我们会在文末重新探讨第二项职责。

我们认为，“是否有人类阅读了代码？”是一个不够精确的指标，用来衡量“这次变更可能出什么问题，以及哪种检查手段——无论是自动化的还是人工的——才是捕捉该问题的正确方式？”

提出这个问题也改变了审查发生的时机。过去，审查是流程终点的关卡：写完代码，提交 PR，然后等待同事审核。

现在，审查变成了持续运行的过程，更像是在你编写代码时的拼写检查器。大多数变更在请求人类介入之前，至少已经由 Claude 审查并修复过一次。这能捕捉绝大多数常规错误，从而将团队的注意力节省下来，用于处理更高层级的问题和深度审视。

稀缺资源：人类的时间与注意力

我们希望保留人类的时间和注意力，专门用于解决只有人类才能解决的问题，并确保自动化检查能够覆盖其余部分。按照目前的变更速率，人类仍需完成大量的工作，而且我们的团队几乎每天都会遇到新的、前所未有的挑战。

人类时间涵盖了代码审查成本的两端：人们花在审查上的时间，以及他们花在修复糟糕代码所引发问题上的时间。如果节省下来的审查时间只是转移到了修复环节，那么削减前者并无意义。

因此，我们的目标是让 Claude Code 仓库（包括 CLI、桌面和 Web 应用以及移动应用）中的大多数 Pull Request 在合并时最多只需一位人类参与审核——这位审核者可以是作者本人——同时确保回滚率和事故率不增加。为了衡量人类投入的时间，我们追踪每个 PR 的人类审批次数（中位数和第 95 百分位）、人类评论数量，以及 PR 等待人工处理的时间。回滚率和事故率是护栏指标：如果这些指标上升，说明我们并没有真正节省人类时间，而只是将其转移了。

变更的生命周期

一个典型的变更从工程师的笔记本电脑（或 Slack 中的 Claude 会话）出发，会经过多层代码审查。

图 A：Claude Code 典型变更从作者机器到用户的路径。大部分流程是自动化的；人类的注意力集中在风险所在之处。

逐层解析

分层而非单一关卡：六层检查机制，底层配有回滚方案。图 B：每一层都能捕获某些问题，但也可能遗漏其他问题。只有极少数问题能穿透所有层级，其余则由回滚机制兜底。

1. 在他人查看之前先验证工作成果

如今，大部分审查发生在 PR 创建之前。我们会给 Claude 提供可执行的内容——例如测试用例、构建命令或用于与设计稿对比的截图——并要求它展示输出结果，而不是仅仅声称“已完成”。随后，一个子代理会在新的上下文中审查差异（diff）。这两种习惯均源自我们的最佳实践指南。

在开启 PR 之前，我们许多人还会运行几个内部技能：一个用于查找 bug，一个用于简化 diff，另一个则端到端地检查行为表现。UI 变更也会对照我们的设计准则进行检查。

Claude Code 的创造者 Boris Cherny 曾表示，为 Claude 提供验证其工作成果的方法，可能是获得良好结果的最重要因素。他估计这能使最终效果提升两到三倍，并写道：“不同领域的验证方式各不相同。它可能简单到只需运行一个 bash 命令，或是运行一套测试套件，亦或是在浏览器或手机模拟器中测试应用。”

当自动化审查者反复标记同一类问题时，我们从源头解决： 通过优化技能、添加 lint 规则，或更新指令文件，例如：

• CLAUDE.md 向 Claude 说明项目概况：技术栈、规范约定、目标与非目标。每次代码审查都会加载该文件，因此在大型代码库中我们保持其简洁，并从中指向其他文档。审查者还会标记违反其中规范的代码，以及导致其中某行内容过时的变更。
• REVIEW.md 由代码所有者编写，告知审查者在其负责的部分中哪些事项至关重要。我们会单独检查审查者是否确实遵循了这些要求。优秀的 REVIEW.md 通常很简短。它们会说明该仓库中的失败表现（对于文档而言是“存在虚假陈述”，对于配置而言是“路由错误”），限制琐碎建议的数量，列出需要跳过的路径，并要求提供文件和行号作为证据，而不是仅凭名称猜测。此外，它们还要求摘要以问题数量开头，并在无需修复时明确说明这一点。

2. 每个 Pull Request 上的 AI 代码审查

每个人工智能辅助的 Pull Request 在人工查看之前都会经过 Claude 审查。它会结合整个代码库和 PR 声明的意图来阅读差异，并询问：该变更是否解决了其问题、是否符合系统设计，或者是否破坏了其他部分？

对于 Bug 修复，它会寻找根本原因。公开版本 Code Review for Claude Code 现已在 Team 和 Enterprise 计划中正式可用，而 /code-review 则在本地运行一个轻量级版本。

当我们推出研究预览版时，内部 PR 中获得实质性审查评论的比例从 16% 上升到了 54%。大多数超过 1,000 行的 PR 都会收到发现的问题，而大多数小型 PR 则顺利通过。管理员将每个仓库设置为 Quick、Standard 或 Deep 模式。当遗漏一个 Bug 的成本高于额外审查时间时，Deep 模式是值得的。

在人类审查之前，发现项会由其他 Agent 进行验证。 多个 Agent 同时查找 Bug。然后，另一组 Agent 对每个发现项进行投票，只有足够多的 Agent 认为它是真实问题时才会发布。仅涉及风格、诊断信息或清理工作的发现项会被丢弃。我们在保留这些过滤器之前，先在自己的 PR 上进行了 A/B 测试。剩下的内容会以按严重程度排序的内联评论形式显示。每个评论都标记为 Important、Nit 或 Pre-existing，这样 PR 未引入的 Bug 就不会看起来像是作者的责任。

每个发现项都必须得到回应。 你要么修复它，要么给出理由来解决该讨论线程。通常，Agent 会在夜间接手修复工作，因此作者回来时会发现 PR 已经经历了另一轮处理。

3. 可阻断的安全审查

安全审查同样有自动化流程。只要 Bug 审查或安全审查中仍有未解决的发现，PR 就无法合并。你需要修复问题，或者用简短的理由关闭该讨论线程——这也是清除误报的方式。

如果后续提交已修复该问题，相关发现会自动清除。你也可以通过开源的安全审查 GitHub Action 或 /security-review 命令实现同样的效果。配置方法详见 Claude Code 中的自动安全审查。

4. 阻断性自动化检查

常规检查包括：lint、类型检查、各平台测试以及构建。（我们曾撰文介绍如何为如此大规模的代码库扩展 CI，点击此处。）一个典型的 CLI PR 在人工介入前可能会运行数十项检查。PR 模板要求说明变更的测试方式及回滚方案。Claude 可以填写这些内容，但必须由提出变更需求的人员最终确认。

5. 按风险分级的人工审批

文档修复与自动更新器变更的风险不同，因此所需的审查级别也不同。

风险等级由变更内容决定，而非作者。 分类器会读取变更内容并确定其风险等级。第二个分类器则会判断：即使当前风险等级不要求，该特定变更是否仍需额外人员审核。某些路径始终需要人工审核，包括所有者标记为敏感的文件以及任何 CI workflow 文件。

只有受信任的作者才能享受简化流程。 只有列入仓库受信任名单的作者（通常是负责该仓库的团队）才能使用简化路径。其他所有人均需第二人审批。此外，AI Agent 的批准不能替代人类审批。自动化审查可以放行低风险变更，但无法填补必须有人类参与的审批名额。

谁触发了变更，谁就要为此负责。 在由 Agent 编写的 PR 中，指挥该 Agent 的人被视为必要审核者之一，这与他们亲自编写代码的情况相同。

一次批准仅针对特定的 commit。 如果出现了系统无法验证的新 commit（例如 Agent 的推送或人工解决的合并冲突），则必须重新进行批准。

6. 合并队列、功能开关与渐进式发布

合并队列会在应用变更后，针对 main 分支重新运行所有检查，从而确保两个单独通过的 PR 不会组合导致 main 分支损坏。新功能通常先通过功能开关向 Anthropic 内部员工发布，我们的高频使用往往能在用户发现之前暴露回归问题。公开发布首先推送到 latest 通道，随后 stable 通道跟进。

7. 快速检测，快速回滚

某些错误仍会漏网，因此最后一道防线旨在快速捕获它们。关闭功能开关无需部署。Claude Code 设有每周值班轮换机制，事故复盘会追问哪一层本应拦截该问题。

发现糟糕的合并仍然依赖于作者和值班人员，以及回滚和事故仪表盘。目前我们尚未建立当这些指标波动时自动收紧审批权限的熔断机制；但在更多代码转向零人工合并之前，这里的工程师希望拥有此类机制。

一位同事指出，放慢速度确实能降低错误率，但这主要是因为整体工作量减少了。我们更倾向于提升发现问题和修复问题的速度。

如何提升审核者的能力

我们的代码审查流程处于持续改进的闭环中。

任何事故现在都转化为评估用例（Eval）。 团队收集了过去引发事故的 PR，包括其向前修复方案和回滚记录，并由熟悉相关代码的工程师确认每个 Bug 及其所在位置。审核器每天针对该集合运行测试。

我们的事故即为评估用例 基于过往事故和回滚构建，每日运行 图 C 随着每次事故的发生，评估集不断扩充；对审核器的每一次改动都会基于整个评估集进行评分。

我们通过观察人们对评论的处理方式来衡量噪声。 如果不介意标记大量非 bug，那么更容易发现更多 bug，因此我们需要对此加以控制。我们将评审者留下的每条评论按 PR 作者的反应进行分类：修复了问题、指出评论有误、说明该行为是有意为之，或认为无关紧要。我们还会让评审者在已知干净的 PR 上运行，并统计它报告可能导致有害更改的问题的频率。我们的首要目标（已明确记录）是优先捕获真实 bug，其次才是减少评审轮次。

当作者是智能体时，噪声的代价更高。人类可以几秒钟内忽略一个吹毛求疵的意见。而智能体会去修复它，这意味着又一次提交和又一轮评审。

评审必须收敛。 智能体作者和智能体评审者可能会无限期地相互纠缠。有一个 CLI PR 在一夜之间经历了超过五十轮的评审和修复，直到其作者叫停为止。

当我们对评审者反复标记的内容进行 git blame 分析时发现，约 59% 的代码自评审者首次检查以来就已存在。评审者很少发现新 bug，而是在每一轮中找出一些旧的 bug。

我们自己加剧了这一问题。由于每次检查都能发现新问题，我们习惯了默认运行多轮评审。这在高风险变更中可能是值得的，但并非适用于每个 PR。团队现在将“通过所需轮次”与召回率一同跟踪，并调整了重新评审策略：

• 设置轮次上限。 三轮之后，评审者会要求作者退后一步，重新考虑方案。
• 在前几轮之后仅针对 diff 进行重新评审。
• 标记 bug 类别， 以便作者修复所有实例，而不是只改一行代码。
• 不再重复 已经发布过的发现。

评审智能体还会在夜间扫描现有代码，帮助我们在旧 bug 在其他地方显现之前将其捕获。

收敛式评审内部拉取请求，在实施收敛性更改前后的对比图 D实施收敛性更改后，每个内部拉取请求的评审轮次减少

人类仍在关键环节介入

将资深工程师从深度工作中拉出来处理常规错误，其成本远高于自动化评审。在 Anthropic，我们的工作重心已从阅读每一个 diff 转向那些机器不擅长的决策环节：

• 我们到底该不该做这件事？ 方向、品味和范围。有一个团队声称其代码审查瓶颈已解决，但仍对来自团队外部的变更保留人工审查，以便有人能问出“我们真的需要做这个吗？”
• 高风险代码，例如计费系统、自动更新程序和 CI 工作流。
• 架构，即那些会被其他人效仿的模式。
• 审视证据。 测试输出、执行的命令及其返回结果、截图、审查者的发现。如果你无法说明检查机制会遗漏什么，那就请求一次真正的审查，而不是快速批准。
• 对结果负责。 无论谁敲下了代码，都有一个人要对每一个发布的变更负责。

由人做出决策的领域：五项关键决策仍由人类掌控；其余环节则运行自动化检查。图 E 人们从阅读每一个 diff 转向处理机器不擅长的决策任务

在团队间共享上下文

代码审查的第二项职责一直是传播对代码库的理解。阅读同事的 diff 是你了解发生了什么变化以及各部分如何衔接的方式。如果机器承担了大部分阅读工作，人们该如何学习代码？

我们没有为此设立正式流程。团队中没有人需要在脑海中维护 Claude Code 的完整心智模型，我们认为也没必要这样做。当某人想要理解代码库的某个部分时，他们会要求 Claude 为那个特定切片编写一份解释文档。这只需几分钟，并且反映的是当前的代码状态。

我们中的一些人会更进一步，让 Claude 构建一个小工件来可视化该部分代码，并以那个人喜欢的学习方式教授它。

如果目标是高效利用人类的注意力，那么这种方式远胜于逐行阅读琐碎的 diff。一行文案修改几乎教不了你什么，而一份关于你即将修改模块的解释性文档则能让你获益良多。我们默认在开放的 Slack 频道中工作的文化也大有裨益，因为你能实时看到其他人正在构建什么。

“谁合并，谁负责”

如果你合并了一个小型或中型变更，但之后仍出现了问题，团队规范通常要求由你来修复。以下几点能确保这一机制不会失控：

• 变更粒度小，因此易于审查、调试和回滚。
• 一切皆可逆。 功能开关（Flags）、回滚（Reverts）和分阶段发布能在几分钟内撤销大多数错误。
• 爆炸半径决定标准。 高成本代码需要更多人员参与和更严格的检查。
• 回归问题通过遥测数据和内部使用快速暴露。
• 这不是追责。 承担修复责任意味着你拥有最完整的上下文；事故复盘关注的是系统本身。

所有权也是共享的。团队大部分工作在开放频道中进行，任何人都可以看到他人的构建进展、接手讨论线索，或让 Claude 去填补空白，反馈也来自那些并不直接拥有该代码的人。这种开放性是我们在不对每一行代码设置关卡的情况下保持高质量的关键因素之一。

当我们改变方向时

Agent 使得启动新任务的成本极低，因此有些工作不应被合并。通常，频道中的某人会询问原因，指出之前的决策，或建议更简单的路径，随后作者会关闭或重构 PR。

由于代码编写速度很快，关闭 PR 并不会让人感觉是一种损失。关键在于尽早在线程中提出不同的方向，而不是在已完成的 PR 上留下阻塞性评论。

如何采用此流程

如今，与你的团队实施此流程所需的大部分要素都已具备。

在 Pull Request 之前

• 为你的 agent 提供可运行的检查项，列在一个简短的 CLAUDE.md 中，并配置运行格式化工具和 linter 的钩子（hooks）。
• 在本地运行 /code-review 和 /security-review，或使用具有全新上下文的 subagent 进行审查。
• 添加一个 REVIEW.md，并将重复出现的审查意见移入其中。

在每个 Pull Request 中

• 要求 CI，并在 PR 模板中添加“测试”、“风险”和“如何回滚”字段。
• 在一个代码仓库中引入 AI 审查员（Code Review for Claude Code 或 Claude Code GitHub Action），调整 REVIEW.md 配置数周后，再逐步扩大应用范围。
• 添加自动化安全审查，并要求在合并前解决所有审查线程中的问题。
• 根据风险匹配审查力度：对常规变更进行快速检查，对遗漏 bug 代价高昂的变更进行深入审查（在 Code Review 中分为 Quick、Standard 或 Deep）。
• 限制审查轮次；在前几轮之后，仅对新产生的 diff 进行重新审查。

批准

• 记录风险等级，依据变更内容而非作者设定；初期从严，随后根据证据逐步放宽。
• 为值得信任的作者保留更轻量的审批路径。
• 使用 CODEOWNERS 和分支保护规则，确保身份验证、计费、CI 和发布工作流以及安装程序始终需要人工审核。
• 绝不允许机器人的批准替代必需的人工批准；在新提交出现时撤销之前的批准。

合并及后续

• 使用合并队列、功能标志、内部优先试用、分阶段发布和一键回滚机制。
• 将事故和回滚转化为评估集，并在审查员的提示词、工具或模型发生变更时重新评分。
• 衡量人工耗时，并将回滚率和事故率作为护栏指标。

未来方向

Code Review 的公告指出，批准拉取请求仍由人类决定；该产品只发布发现项，不直接批准。我们自己的代码仓库走得更远，允许负责人决定哪些低风险变更仅凭自动化检查即可合并，这条界限仍在不断移动。

当审查遗漏某些问题时，我们会询问模型当时缺少什么上下文信息，并将修复方案纳入 CLAUDE.md、技能或新的检查项中。目标从未改变：减少每次变更所需的人工时间，且不增加回滚次数。

如果你的团队允许智能体发起拉取请求，我们希望了解你们已自动化了哪些检查，哪些仍需人工介入，以及你认为我们有哪些不足之处。

感谢 Emma Webb、Michael Segner 和 Amie Rotherham 的审阅。