Claude Code 团队如何做代码审查

代码写得越来越快，逐行审查却跟不上了。Anthropic 的 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 在这篇文章中，公开了 Claude Code 团队从提交前验证到分级审批、灰度发布和回滚的完整流程。以下为全文翻译，文中的“我们”指原作者及其团队。

面对 Agent 带来的产码量，该怎样审查代码？在 Claude Code 团队，实现高覆盖率和深度审查之后，我们开始优化另一个目标：在不增加回滚或事故的前提下，尽可能减少人工审查时间。

我们之前提过，Claude Code 自身的代码，大约90%由 Claude 编写。那么，面对这样的产码量，我们究竟怎么审查代码？还有人在读代码吗？真出了问题，又由谁来发现？

这篇文章会介绍 Claude Code 团队的代码审查流程，以及它是怎样演变的。从6月到9月，Claude Code 代码库合入的拉取请求（PR）数量增长了一倍多，而需要回滚的PR占比下降了40%以上。

我们没有取消审查。但我们确实把大部分阅读工作交给了机器，围绕人的时间和注意力优化流程，也在出错后快速、轻松地撤回变更这件事上投入了大量精力。

重新思考代码审查的目的

当 Agent 开始写代码，变更量会迅速增加。在 Anthropic 的 monorepo 中，今年每天合入的变更从5月的约2500项，增长到了9月的3万多项。

Claude Code 使用独立于 monorepo 的代码库，但同样面临很大的压力。交付速度达到这个程度，人工逐行审查代码即使不是不可能，也已经极其困难。

代码审查承担着两项工作：

1. 在问题上线之前发现并修复它们。

2. 让团队共享背景信息，并增进对代码库的理解。

本文主要讨论如何发现和修复问题，临近结尾时再回到第二项工作。

我们认为，“有没有人读过这段代码”，并不能准确代替真正该问的问题：“这次变更可能出什么问题，又该由哪项检查——自动检查还是人工检查——来发现它？”

换一种问法，也改变了审查发生的时间。以前，审查是流程末尾的一道关卡：写代码，开PR，然后等同事来看。

现在，审查持续进行，更像写作时同步运行的拼写检查。在请人来看之前，大多数变更已经至少经过一轮 Claude 的审查和修复。这能发现大部分常规错误，让团队把注意力留给更高层次的问题和检查。

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

我们希望把人的时间和注意力留给只有人才能解决的问题，其他问题则确保由自动检查发现。以目前的变更速度，人仍有大量工作要做，团队几乎每天都会遇到新的挑战。

人的时间，涵盖了审查成本的两端：既包括审查代码的时间，也包括修复糟糕代码引发的问题所花的时间。如果前一头省下来的时间全花到了后一头，那就没有意义。

因此，我们的目标是：Claude Code 各个代码库——CLI、桌面端和网页端，以及移动端——中的大多数PR，最多只需要一个人参与就能合入，这个人也可以是作者本人，同时不增加回滚或事故。为了衡量人的时间，我们会跟踪每个PR的人工批准次数，包括中位数和95分位数、人工评论数量，以及PR等待人工处理的时长。回滚率和事故率是护栏：如果它们上升了，我们就没有节省人的时间，只是把时间转移到了别处。

一次变更的完整历程

一项典型变更，从工程师的笔记本电脑上开始，或者从 Slack 里的一段 Claude 会话开始，会经过多层代码审查。

逐层来看

1. 在别人来看之前，先验证工作结果

现在，大部分审查发生在PR创建之前。我们会给 Claude 一种它能实际运行的验证方式，比如测试、构建，或者用来和设计稿对比的截图，要求它展示输出，而不是只说“做完了”。然后，再让一个子 Agent 在全新上下文中审查 diff。这两种做法都来自我们的最佳实践指南。

创建PR之前，我们很多人还会运行几项内部 Skill：有的专门找bug，有的简化 diff，还有的端到端检查行为。涉及UI的变更，还会对照设计规范检查。

Claude Code 的创建者 Boris Cherny 曾说，给 Claude 一种验证自己工作的方式，可能是获得好结果最重要的一件事。他估计，这能让最终结果好上两到三倍。他写道：“不同领域的验证方式也不同。它可能简单到只需运行一条 bash 命令，也可能是运行一套测试，或是在浏览器、手机模拟器中测试应用。”

如果自动审查器总是指出同一类问题，我们就从源头解决：修改 Skill，增加 lint 规则，或者更新这些指导文件：

• CLAUDE.md

   告诉 Claude 这个项目是什么：技术栈、约定、目标，以及明确不做什么。每次审查都会加载它，所以在大型代码库里，我们会让它保持简短，再从这里链接到其他文档。审查器还会指出违反其中约定的代码，以及让文件中某条说明过时的变更。

• REVIEW.md

   由代码负责人编写，告诉审查器，他们负责的这部分代码有哪些要紧的事。我们还会单独检查审查器有没有真正遵守它。好的 REVIEW.md 都很短：说明这个仓库里什么算失败，比如文档的失败是“说错了”，配置的失败是“路由错了”；限制细枝末节的意见数量；列出应跳过的路径；要求指出具体文件和行号作为证据，而不是凭名字猜测。它还会要求摘要先报数量，没有需要修复的问题时就直说。

2. 每个PR都经过AI审查

每个PR在交给人看之前，都会先经过 Claude 审查。它会结合整个仓库和PR声明的意图来阅读 diff，判断：这项变更有没有解决它要解决的问题，是否适合现有系统，会不会弄坏别的东西？

对于bug修复，它会追查根因。公开版 Code Review for Claude Code 目前已面向 Team 和 Enterprise 套餐正式开放，/code-review 则可以在本地运行一个轻量版本。

我们推出研究预览版后，内部PR获得实质性审查意见的比例从16%上升到了54%。超过1000行的大多数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工作流文件。

较轻量的流程只向可信作者开放。具体说，只有进入该仓库可信名单的作者才能使用，主要是负责这个仓库的团队。其他人都需要第二个人批准。Agent 的批准也绝不算人工批准。自动审查可以让低风险变更通过，但不能替代一个明确要求由人完成的批准名额。

谁发起了这次变更，谁就要为它负责。对于 Agent 编写的PR，指挥 Agent 的那个人算作所需审查者中的一人，就和代码是他亲手敲出来的一样。

一次批准只覆盖某个具体提交。如果后续又加入了系统无法保证可信的新提交，比如 Agent 的推送，或是有人手工解决冲突后的合并，就必须重新批准。

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

合并队列会把变更应用到 main 上，再运行全部检查，避免两个各自通过的PR合在一起却把 main 弄坏。新行为通常会先放在功能开关后面，交给 Anthropic 员工使用。我们内部的大量使用，经常能在用户遇到回归问题之前先发现它们。公开发布时，先进入 latest 渠道，stable 渠道稍后跟进。

7. 快速发现，快速回滚

总会有一些错误漏过去，因此最后一层的任务是尽快发现。功能开关不需要重新部署就能关闭。Claude Code 采用每周轮换的值班制度，事故复盘时会追问：本来应该由哪一层发现这个问题？

发现一次有问题的合入，目前仍然依赖作者、值班人员，以及回滚和事故看板。我们还没有这样的熔断机制：当这些指标变化时，自动收紧批准要求。在让更多代码进入零人工合入之前，这里的工程师希望先把它建起来。

有位同事说，放慢速度确实会降低错误率，但主要原因是你把所有事情都做少了。我们更愿意加快发现和修复问题的速度。

我们怎样改进审查器

我们的代码审查流程，一直在循环中改进。

现在，每次事故都会变成一道评测题。团队收集了过去引发事故的PR，以及后续的修复提交和回滚记录，再请熟悉相关代码的工程师确认每个bug及其具体位置。审查器每天都会在这组案例上运行。

我们通过观察人怎样处理评论，来衡量噪声。如果不介意同时报出大量并不存在的bug，发现更多bug其实很容易，所以必须约束这一点。对于审查器留下的每条评论，我们会根据PR处理者的回应分类：修复了、认为意见错误、说明这是有意设计的行为，或者判断它并不重要。我们也会让审查器检查已知没有问题的PR，统计它有多少次报出了可能诱导人做出有害修改的意见。我们写下来的优先顺序是：先发现真正的bug，再减少审查轮数。

当作者是 Agent 时，噪声的成本更高。人几秒钟就能忽略一个小毛病，Agent 却会去修，于是又多了一次提交和一轮审查。

审查必须能够收敛。写代码的 Agent 和审代码的 Agent，可以让彼此一直忙下去。曾有一个CLI PR，在一夜之间经历了50多轮审查和修复，最后还是作者出手叫停。

我们对审查器反复指出的代码运行 git blame，发现其中约59%从第一轮审查时就已经存在了。审查器很少是在发现新bug，它只是每一轮又找出了几个原有的bug。

我们自己也让问题变得更糟。因为每轮都能发现新东西，我们已经习惯了默认多跑几轮。对高风险变更，这样做可能值得，但不是每个PR都值得。团队现在会同时跟踪通过审查所需的轮数和召回率，并调整了复审方式：

• 限制轮数。经过三轮后，审查器会请作者退后一步，重新考虑整体做法。

• 最初几轮之后，复审只看新增的 diff。

• 指出bug所属的类别，让作者修复所有同类问题，而不只是某一行。

• 已经发过的发现，不重复提出。

审查 Agent 每晚也会检查现有代码，帮助我们在旧bug于其他地方暴露之前发现它们。

哪些地方仍然需要人

让一位正在深入工作的资深工程师停下来，去找一个常规错误，成本远高于一次自动审查。在 Anthropic，我们的工作已经从阅读每一份 diff，转向机器不擅长的决策：

• 这件事到底该不该做？这是方向、判断力和范围的问题。一个宣布已经解决审查瓶颈的团队，仍然保留了对团队外部变更的人工审查，让人来问一句：“我们真的该做这件事吗？”

• 高风险代码，例如计费、自动更新器和CI工作流。

• 会成为他人模仿范式的架构。

• 阅读证据。测试输出、实际运行的命令及其返回结果、截图，以及审查器的发现。如果你说不清这些检查会漏掉什么，就应该请人认真审查，而不是匆匆点个批准。

• 为结果负责。每一项上线的变更，都要有一个人承担责任，无论代码是谁写的。

怎样在团队中共享对代码的理解

代码审查的第二项工作，一直是传播对代码库的理解。阅读队友的 diff，你才能知道改了什么、各部分怎样配合。如果大部分阅读都交给了机器，大家又该怎么理解代码？

我们并没有为这件事设定正式流程。团队里没有人脑中装着 Claude Code 的完整模型，我们也不认为谁需要做到这一点。想了解代码库的某个部分时，大家就让 Claude 专门针对那一块写一份解释。只需几分钟，而且反映的是代码现在的样子。

有些人还会更进一步，让 Claude 做一个小型可视化作品，把这部分代码画出来，按自己喜欢的学习方式来讲解。

如果目标是把人的注意力用好，这比逐行阅读琐碎的 diff 更有价值。一行文案修改，几乎教不会你什么；一份针对你即将修改的模块的解释，却能教会你很多。我们默认在开放 Slack 频道里工作的文化也有帮助，因为在别人构建东西的过程中，你就能看到他们正在做什么。

“谁合入，谁负责”

如果你合入了一项小型或中型变更，结果还是出了问题，通常由你来修，这是团队的惯例。有几件事可以避免它变成坏事：

• 变更保持小规模，方便审查、调试和回滚。

• 所有东西都可以撤回。功能开关、回滚和分阶段发布，能在几分钟内撤销大多数错误。

• 要求高低由影响范围决定。出错代价高的代码，需要更多人、更多检查。

• 通过遥测和内部使用，迅速发现回归问题。

• 这不是追责甩锅。让你负责修复，是因为你最了解上下文；事故复盘则着眼于系统。

责任也是共享的。团队里很多人在开放频道中工作，任何人都能看到其他人在做什么，接过一段讨论，或让 Claude 去补一个缺口；反馈也会来自并不负责这块代码的人。这种开放性，是我们不必对每一行代码都设置关卡，却仍能维持高质量的重要原因。

当我们改变方向时

Agent 让启动一件事的成本变低了，因此有些工作根本不应该合入。通常，频道里会有人追问为什么要做，指出之前的决定，或者建议一条更简单的路线；随后，作者会关闭PR，或者重新调整它。

因为代码写起来很快，关闭PR也不太会让人觉得损失了什么。关键是早点在讨论中提出不同方向，而不是等PR已经做完，再留下一条阻止合入的评论。

你的团队可以怎样采用这套流程

要在你的团队里做到这些，大部分组件现在就已经有了。

创建PR之前

• 为 Agent 提供可以实际运行的检查，把它们列在简短的 CLAUDE.md 中，再用 hook 运行格式化工具和 linter。

• 在本地运行 /code-review 和 /security-review，或者让一个使用全新上下文的子 Agent 来审查。

• 增加 REVIEW.md，把反复出现的审查意见写进去。

每个PR都要做的事

• 将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 的发布介绍说，是否批准一个PR，仍由人决定；产品只提出发现，不做批准。我们自己的代码库走得更远一些，由负责人决定哪些低风险变更仅凭自动检查就能合入，而这条边界还在不断移动。

每当审查漏掉一个问题，我们就会追问：模型当时缺少哪些信息？然后把补救办法写进 CLAUDE.md、某项 Skill 或一项新检查中。目标没有改变：每项变更少花一些人的时间，回滚却不能比以前更多。

如果你的团队也让 Agent 创建PR，我们很想听听：你们已经自动化了哪些检查，哪些仍然需要人，以及你觉得我们有哪些地方想错了。

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

参考链接

• 原文：https://claude.dev/blog/solving-code-review-at-anthropic/

• Anthropic的源码管理系统重构：https://www.anthropic.com/engineering/redesigning-source-control

• Claude Code最佳实践：https://code.claude.com/docs/en/best-practices

• Boris Cherny谈如何让Claude验证自己的工作：https://x.com/bcherny/status/2007179861115511237

• Claude Code代码审查文档：https://code.claude.com/docs/en/code-review

• Code Review发布介绍：https://claude.com/resources/articles/code-review

• Claude Code自动安全审查：https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code

• Anthropic如何扩展测试影响分析：https://claude.com/resources/articles/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic