How the Claude Code team does code review

Claude Code团队如何进行代码审查 / claude.dev 博客

$

/$

工程

Claude Code团队如何进行代码审查

当代理生成代码的规模达到一定量级时，你如何进行代码审查？在Claude Code团队，当我们实现了高覆盖率和深入的审查后，我们开始优化人类审查时间的最小值，同时避免出现回滚或事故。

作者

Addy Osmani、Morgan Westlee Lunt 和 Qing Wang

分类

发布日期

2026年10月15日

阅读时间

14分钟

我们之前提到过，Claude编写了Claude Code自身约90%的代码。那么在我们如此庞大的产出规模下，如何进行代码审查？还有人阅读代码吗？如果出现问题，谁来发现？

本文将介绍Claude Code团队的代码审查流程及其演变过程。从6月到9月，合并到Claude Code代码库的拉取请求数量翻了一倍多，而需要回滚的比例下降了40%以上。

我们并没有取消代码审查。但我们将大部分阅读工作交给了机器，优化了人类的时间和注意力分配，并投入大量资源使错误的撤销变得快速且简单。

重新思考代码审查的目的

当代理编写代码时，变更数量会迅速增加。在Anthropic的单体仓库中，每天提交的变更量从5月的约2500次增加到今年9月的30000多次。

Claude Code位于独立的仓库中，与单体仓库分开，但也面临巨大压力。当以如此高速推进时，手动逐行审查代码几乎不可能完成。

代码审查承担着两项任务：

• 在代码发布前发现并修复问题
• 在团队中建立共享上下文和代码库理解

本文主要聚焦于发现和修复问题，但将在最后部分重新探讨第二项任务。

我们认为“人类是否阅读了代码？”是“这次变更可能出什么问题，以及自动化或人工检查中哪一种更适合发现它？”的不精确替代指标。

提出这个问题也改变了审查的时间点。以前，审查是流程末端的关卡：编写代码、打开拉取请求、等待同事审查。

现在，审查是持续进行的，更像是在编写时的拼写检查。大多数变更在有人审查前至少被Claude审查并修复了一次。这能捕捉到大部分常规错误，让团队的注意力集中在更高层次的问题和审查上。

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

我们希望将人类的时间和注意力保留给只有人类才能解决的问题，同时确保自动化检查能处理其余部分。按照我们当前的变更速度，人类仍有大量工作要做，团队几乎每天都会遇到新的挑战。

人类时间涵盖了审查成本的两个方面：人们花在审查上的时间，以及他们花在修复劣质代码造成的问题上的时间。如果减少前者的时间，而后者的时间只是转移到了其他地方，这并没有实际帮助。

因此，我们的目标是Claude Code仓库（CLI、桌面和网页应用以及移动应用）中的大多数拉取请求在最多一个人类参与的情况下合并，该人类可以是作者本人，且不会增加回滚或事故的数量。为了衡量人类时间，我们跟踪每个拉取请求的人类批准次数（中位数和95百分位数）、人类评论数量以及拉取请求等待某人处理的时间。回滚和事故率是关键指标：如果这些指标上升，说明我们并未节省人类时间，只是将时间转移了。

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

变更的生命周期

png

一个典型的Claude Code变更，从作者的机器到用户

FIG A 大部分流程是自动化的；人的关注点集中在风险最高的地方

分层审查

层层把关，而非单一关卡

六层检查机制，每层之下都有回滚机制

FIG B 每一层都能捕捉部分问题，但也会遗漏其他问题。很少有变更能通过所有检查层，其余的由回滚机制处理。

1. 在其他人查看之前验证工作内容

如今大多数审查在PR创建之前就已完成。我们给Claude一些可以执行的内容——比如测试、构建或与设计对比的截图——并要求它展示输出结果而非简单声明完成。随后，一个子代理会带着新的上下文审查差异内容。这些做法都源自我们的最佳实践指南。

在提交PR之前，我们中许多人还会运行一些内部技能：一个用于查找漏洞，一个用于简化差异内容，一个用于端到端验证行为。UI变更还会根据我们的设计规范进行检查。

Claude Code的创建者Boris Cherny曾表示，给予Claude验证其工作成果的方式可能是获得良好结果最重要的因素。他估计这能使最终结果提升2到3倍，并写道："每个领域的验证方式都不同。可能是运行一个bash命令，或运行测试套件，或在浏览器或手机模拟器中测试应用。"

当自动化审查器反复标记相同问题时，我们会从根源解决：在技能中修复、添加lint规则，或更新指导文件，例如：

• CLAUDE.md 告诉Claude项目信息：技术栈、惯例、目标和非目标。每次审查都会加载该文件，因此在大型代码库中我们会保持其简短，并指向其他文档。审查器也会标记违反该文件惯例的代码，以及使其中某条信息过时的变更。

• REVIEW.md 由代码负责人编写，告诉审查者他们代码部分的关键点。我们会单独检查审查者是否实际遵循该文件。优秀的REVIEW.md文件都很简洁。它们会说明该仓库中失败的表现形式（文档中是"内容不真实"，配置中是"路由错误"），限制琐碎问题，列出可跳过的路径，并要求提供文件和行号作为证据而非仅凭名称猜测。它们还会要求提供以数量开头的摘要，并在确实无需修改时明确说明。

2. 每个Pull Request的AI审查

每个Pull Request在人工审查前都会经过Claude的审查。它会对比整个仓库和PR声明的意图，提出问题：该变更是否解决了问题、符合系统设计，或破坏了其他部分？

对于错误修复，它会寻找根本原因。公开版本Code Review for Claude Code现已在Team和Enterprise计划中全面上线，而/code-review命令会在本地运行轻量版。

在推出研究预览版时，内部PR获得实质性审查意见的比例从16%提升至54%。大多数超过1000行的PR都会发现问题，而大多数小型PR都能一次性通过审查。管理员可将每个仓库设置为Quick、Standard或Deep模式。在单个遗漏的错误成本高于额外审查时间的情况下，Deep模式是值得的。

发现内容会在人工审核前由其他代理进行验证。多个代理会同时查找漏洞，随后由独立小组对每个发现进行投票，只有足够多的代理确认其真实性时才会发布。仅涉及样式、诊断或清理的发现会被过滤掉。我们在保留这些过滤规则前，已在自己的PR上进行了A/B测试。剩余内容会以按严重性排序的内联评论形式呈现，每个评论会标记为Important（重要）、Nit（小问题）或Pre-existing（原有问题），这样PR未引入的漏洞不会被误认为是作者的过错。

每个发现都必须得到回应。要么修复问题，要么以原因说明关闭讨论。通常代理会在夜间自动完成修复，因此作者返回时PR可能已经经历了另一轮审核。

3. 可能阻止的安全部门审查

安全审查也有独立的自动化流程。只要漏洞审查或安全审查中存在未解决的发现，PR就无法合并。您需要要么修复问题，要么以简短原因关闭讨论，这是清除误报的标准方式。

如果后续提交解决了问题，发现会自动清除。您可以使用开源安全审查GitHub Action或/security-review命令实现相同功能。相关设置请参阅Claude Code中的自动化安全审查部分。

4. 可能阻止的自动化检查

常规流程包括：代码规范检查、类型检查、所有平台的测试以及构建。（我们在此处曾讨论过如何扩展CI以应对这种规模。）一个典型的CLI拉取请求在人工查看前可能需要运行数十项检查。PR模板会询问更改是如何测试的以及如何撤销更改。Claude可以自动填写这些内容，但提出更改请求的人需要对此负责。

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

文档修复和自动更新器更改具有不同风险等级，因此需要不同的审查流程。

| 风险等级 | 示例 | 人工审批要求 | |---------|------|-------------| | 低风险 | 文档、复制文本、仅限内部的功能、启用标志后的增量更改 | 自动审查和安全检查通过后无需人工审批 | | 中风险 | 常规产品更改、缓存、自动更新器或系统提示等敏感区域的更改 | 需要1人审批 | | 高风险 | 最高风险代码，以及始终需要两人审批的特定路径 | 需要2人审批 |

变更本身设定风险等级，而非作者。分类器会分析变更并确定其风险等级。第二个分类器会判断即使该等级不强制要求，特定变更是否仍需要额外人员审批。某些路径始终需要人工审批，包括所有者标记为敏感的路径以及任何CI工作流文件。

只有受信任的作者才能获得低风险路径。仓库信任列表中的作者（通常是所属团队成员）可获得低风险路径。其他所有人必须由第二人审批。代理的审批永远不计入人工审批。自动化审查可以清除低风险变更，但无法替代需要人工审批的环节。

提出变更的人需对变更负责。对于代理撰写的PR，指导代理的人会被视为必要审查者之一，与自己编写代码时的审查要求相同。

每个审批仅针对特定提交。如果系统无法验证的新提交出现（如代理推送或人工解决的合并），必须重新获得审批。

6. 合并队列、标志与渐进发布

合并队列会重新运行所有针对main分支的检查，应用更改后。因此，两个单独通过的PR不会合并成一个损坏的main分支。新功能通常会通过一个开关首先向Anthropic员工发布，而我们频繁的使用往往会在用户之前暴露回归问题。公开发布会先推送到最新通道，稳定通道则会滞后。

7. 快速检测，快速回滚

一些错误仍可能通过审核，因此最后一道防线是快速发现它们。开关可以在不部署的情况下关闭。Claude Code每周都有值班轮换，事故回顾会询问哪一层本应发现该问题。

发现不良合并仍依赖于作者、值班人员以及回滚和事故仪表板。我们尚未实现当这些指标变化时收紧审批的熔断器；这里的工程师希望在更多代码转向零人工合并之前实现它们。

一位同事表示，放慢速度确实会降低错误率，但主要是因为你做的事情更少了。我们更希望提高发现和修复问题的速度。

我们如何让审查者变得更好

我们的代码审查流程在循环中持续改进。

任何事故现在都会被评估。团队收集了过去引发事故的PR，包括其修复方案和回滚记录，并让熟悉这些代码的工程师确认每个错误的位置。审查者每天都会针对这些案例运行。

我们的事故就是评估

基于过去的事故和回滚，每天运行一次

图C 评估随着每次事故增长，审查者的每次变更都会与所有历史记录进行评分。

我们通过观察人们如何处理评论来衡量噪音。如果你不介意标记大量非错误，就很容易发现更多错误，因此我们需要对此进行限制。我们根据PR作者对审查者评论的回应方式对每条评论进行排序：他们修复了问题、指出错误、说明行为是故意的，或认为无关紧要。我们还会在已知干净的PR上运行审查者，并统计其报告可能导致有害更改的频率。我们明确的优先级是：首先发现真实错误，其次减少审查轮次。

当作者是代理时，噪音成本更高。一个人可以在几秒钟内忽略一个细节。代理会修复它，这意味着另一个提交和另一轮审查。

审查必须达成一致。代理作者和代理审查者可能无限期地互相消耗。一个CLI PR在作者停止之前，经历了超过五十轮的审查和修复。

当我们对审查者反复标记的代码运行git blame时，约59%的代码自审查者首次运行以来就存在。审查者很少发现新错误，而是每轮发现少量旧错误。

我们自己让情况变得更糟。我们习惯了默认运行多轮审查，因为每轮都能发现新问题。这在高风险更改中可能有价值，但不适合每个PR。团队现在将轮次与召回率一起跟踪，并调整了重新审查：

• 轮次上限。三轮后，审查者要求作者退后并重新考虑方案。

• 首几次运行后仅对比差异的重新审查。

• 标记错误类型，让作者修复所有实例，而非单行代码。

• 不重复已发布的发现。

审查代理还会在夜间对现有代码运行，帮助我们在错误出现在其他地方之前发现旧错误。

达成一致的审查

内部拉取请求，在达成一致前后对比

/think

FIG D 汇聚改进后内部拉取请求的评审轮次减少

人类持续参与的关键环节

将资深工程师从深度工作中抽离出来检查常规错误的成本，远高于自动化评审。在Anthropic，我们的工作重点已从阅读每一份差异转移到机器难以判断的决策上：

• 是否应该构建这个功能？方向、品味和范围。有一个团队声称解决了评审瓶颈，但仍保留对团队外变更的人工评审，因此总有人会问"我们甚至应该做这件事吗？"

• 高风险代码，如计费系统、自动更新器和持续集成工作流程。

• 设定他人会效仿的架构模式。

• 阅读证据。测试输出、执行的命令及其返回结果、截图、评审员的发现。如果你无法说明检查可能遗漏的内容，请要求真实评审而非快速批准。

• 承担结果。每个上线变更都必须有专人负责，无论谁编写了代码。

人类决策的领域

五类决策保留给人类，其余检查流程全面覆盖

FIG E 人类从阅读每份差异转向机器难以判断的决策领域

跨团队上下文共享

代码评审的第二个职责始终是传播代码库理解。阅读同事的差异是了解变更内容和模块衔接方式的主要途径。如果机器完成大部分阅读，谁来学习代码？

我们没有正式的流程。团队中没有人能完整记住Claude Code的全部架构，我们认为也没必要。当有人想理解代码库某部分时，他们会要求Claude为该模块专门撰写解释文档。这只需几分钟，且能反映当前代码状态。

部分人更进一步，要求Claude构建可视化工具来展示代码模块，并以该人偏好的方式教学。

如果目标是合理分配人类注意力，这种方式比逐行阅读琐碎差异更高效。一行复制变更几乎无法提供有用信息，而即将修改模块的解释文档则能带来大量收获。我们默认在开放Slack频道工作的文化也有帮助，因为你能实时看到他人正在构建的内容。

"你上线它，你就要负责它"

如果你上线了小或中型变更但出现问题，团队惯例是你要负责修复。几个因素防止这种情况失控：

• 变更规模小，便于评审、调试和回滚。

• 所有变更均可逆。通过标志位、回滚和分阶段发布，多数错误可在几分钟内撤销。

• 爆炸半径设定标准。高成本代码会触发更多人参与和更严格检查。

• 通过遥测数据和内部使用，回归问题能快速暴露。

• 不追究责任。修复问题需要最了解上下文的人来处理，事故复盘会分析系统本身。

所有权也是共享的。团队大部分成员在开放频道工作，任何人都能看到他人正在构建的内容，可以接续讨论线程，或让Claude指出代码空白。反馈也经常来自不拥有代码的人。这种开放性是保证质量不依赖每行代码设置关卡的重要因素。

当我们改变方向时

智能体使启动新项目变得容易，因此有些工作不应上线。通常频道中有人会询问原因，指出早期决策或建议更简单的路径，作者就会关闭或调整PR。

由于编写代码的速度很快，关闭这个PR并不觉得是损失。关键在于在PR完成之前，尽早地在讨论中提出不同的方向，而不是作为对已完成PR的阻碍性评论。

如何在团队中采用此流程

今天，你团队中大部分实现此流程所需的组件已经存在。

在拉取请求之前

• 为你的代理提供它可以运行的检查项，列在简短的CLAUDE.md文件中，并添加运行格式化工具和代码检查工具的钩子。
• 本地运行/code-review和/security-review，或使用fresh-context子代理进行审查。
• 添加REVIEW.md文件，将重复的审查意见集中到其中。

在每个拉取请求中

• 要求运行CI，并在PR模板中添加"Testing"（测试）、"Risk"（风险）和"How to revert"（如何回滚）字段。
• 在一个仓库中添加AI审查者（Claude Code的代码审查或Claude Code GitHub Action），调整REVIEW.md文件几周后逐步推广。
• 添加自动化安全审查，并要求所有审查线程在合并前必须解决。
• 根据风险匹配审查力度：对常规变更进行快速检查，对遗漏漏洞代价高昂的变更进行深度检查（代码审查中的Quick、Standard或Deep模式）。
• 限制审查轮次；在前几次之后，仅重新审查新修改的部分。

审批

• 记录风险等级，根据变更内容而非作者设定；从严格开始，根据证据逐步放宽。
• 为信任的作者保留更简化的审批路径。
• 使用CODEOWNERS和分支保护机制，确保认证、计费、CI和发布流程以及安装程序始终需要人工参与。
• 永远不要让机器人的审批替代必要的人工审批；对新提交的代码要驳回之前的审批意见。

合并和之后

• 使用合并队列、特性开关、内部先行使用、分阶段发布和一步回滚。
• 将事件和回滚转化为评估数据集，并在提示、工具或模型发生变更时重新评估审查者。
• 用回滚和事件率作为衡量人工时间的指标。

未来方向

代码审查的公告中提到，批准拉取请求仍然是人工判断；产品会发布发现结果，而不是直接批准。我们自己的仓库更进一步，允许仓库所有者决定哪些低风险变更可以仅通过自动化检查合并，而这条界限会持续向前推进。

当审查遗漏某些内容时，我们会分析模型当时没有看到什么，并将修复方案写入CLAUDE.md文件、技能或新的检查项中。目标始终如一：减少每次变更所需的人工时间，且回滚次数不超过之前水平。

如果你的团队允许代理创建拉取请求，我们很乐意了解你自动化了哪些检查项、哪些仍需要人工参与，以及你认为我们哪里理解有误。

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

相关文章

ALL

AGENTS

PLAYBOOKS

SKILLS

TUTORIALS

2026年10月8日

构建有效的代理自动化

9

2026年10月6日

Claude Code在云端：云会话实战指南

18

2026年10月1日

Claude Code插件入门

11

2026年9月28日

使用Claude自动化评估设计和爬坡

12

使用Claude Sonnet 5.5构建

加载更多