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

Anthropic 旗下的 Claude Code 团队正处在这场变革的最前线——其项目本身已有超过 90% 的代码由 Claude 自主编写。面对海量的代码产出，他们是如何在不牺牲系统稳定性的前提下重塑审查流程的？人类工程师的角色又该如何演进？本文系统性地复盘了 Claude Code 团队从“人肉看代码”转向“人机协同分级审查”的实战经验，涵盖自动化门禁、风险分级、审查收敛机制以及事故评测驱动的持续改进方案。无论你正在构建 AI 研发流程，还是关注工程效能的未来形态，这篇文章都值得一读。

当 Agent 产出海量代码时，你该如何进行代码审查？

在 Claude Code 团队，建立起高覆盖率和深度审查机制后，我们便开始致力于将“人类审查时间”优化至最低限度，同时确保回滚率（Reverts）和线上事故（Incidents）不上升。

作者： Addy Osmani、Morgan Westlee Lunt、Qing Wang

我们此前曾提到，Claude 编写了 Claude Code 自身约 90% 的代码。那么，面对如此巨大的代码产出量，我们究竟该如何进行审查？现在还有人会去一行行读代码吗？如果系统出现问题，又由谁来兜底排查？

本文将介绍 Claude Code 团队的代码审查流程及其演进历程。从 2026 年 6 月到 9 月，合并到 Claude Code 代码库的 Pull Request（PR）数量增加了一倍以上，而其中需要回滚的比例却下降了超过 40%。

我们并没有取消审查。但我们确实把大部分阅读代码的工作交给了机器，让人类的时间与注意力得到最大化利用，并大力投资于让“撤销错误”变得极度迅速且简单。

重新审视代码审查的目的

当 Agent 编写代码时，代码变更的数量会急剧飙升。在 Anthropic 的单体代码仓库（Monorepo）中，每天合入的变更从今年 5 月的约 2,500 次激增到了 9 月的超过 30,000 次。

Claude Code 拥有自己独立的代码仓库，与主单体仓库隔离，但也承受着巨大的吞吐压力。当交付速度如此之快时，人工逐行审查代码，即便不是不可能，也变得异常艰难。

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

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

本文主要聚焦于“发现并修复问题”，不过我们在文末也会重新探讨第二项职责。

我们认为，“是否有人读过这段代码？”并不是一个精准的度量指标，它充其量只能算是一个粗糙的代理指标；真正核心的问题应该是：“这项变更可能会带来什么风险？应该由哪道检查——无论是自动化的还是人工的——来最有效地拦截它？”

提出这个问题，也彻底改变了审查发生的时间节点。在此之前，审查是流程终点处的一道关卡：写好代码、提交 PR、然后苦等同事来看。

现在，审查是持续运行的，更像是打字时的拼写检查。绝大多数变更在提交给人类看之前，都已经至少被 Claude 审查并修复过一轮了。这可以过滤掉大部分常规错误，把团队的注意力节省下来留给更高层面的审视与质疑。

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

我们希望把人类的时间和注意力留给那些只有人类才能解决的问题，并确保其余所有检查都由自动化工具接管。以我们目前的变更节奏来看，仍然有海量的工作需要人类去处理，团队几乎每天都会遇到新颖而棘手的挑战。

人类的时间成本体现在审查的“两端”：一是大家花在代码审查上的时间，二是由于劣质代码引发故障后大家花在修复上的时间。如果削减了前者的耗时，却导致后者的耗时大幅上升，那没有任何意义。

因此，我们的目标是：让 Claude Code 多个仓库（包括 CLI、桌面与 Web 应用以及移动端应用）中的绝大多数 PR，在最多只有一个人参与闭环（这个人可以是作者本人）的前提下完成合并，同时确保回滚率和线上事故率不上升。为了衡量人类的时间消耗，我们追踪了每个 PR 的人工批准次数（中位数与第 95 百分位）、人工评论数，以及 PR 等待人工处理的时长。回滚率和事故率则是安全防线：一旦这两项指标上升，就说明我们并没有节省人类的时间，只是把时间消耗转移到了别处。

一项变更的生命周期

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

逐层深入

1. 在他人审阅之前先完成验证

如今绝大部分的审查，在 PR 真正创建出来之前就已经完成了。我们会给 Claude 提供一些可运行的验证手段——比如测试套件、构建流程或与设计稿比对的截图——并要求它直接展示执行结果，而不能只口头汇报“已完成”。随后，另一个子智能体（Subagent）会在全新的上下文环境中对 Diff（代码差异）进行审查。这两项习惯都源自我们的最佳实践指南。

在提 PR 之前，我们团队的很多人还会运行几个内部自定义技能（Skills）：一个专门找 Bug，一个用于精简优化 Diff，还有一个验证端到端行为。UI 相关的变更还会对照我们的设计准则进行检查。

Claude Code 的创造者 Boris Cherny 曾表示，给 Claude 提供一种验证自身成果的方法，或许是获得优质结果最关键的一环。他估计这一步能让最终交付成果的质量提升两到三倍，并写道：“每个领域的验证形式各有不同。它可以简单到只是一行 Bash 命令，也可以是运行整个测试套件，或者在浏览器/手机模拟器中测试应用。”

当自动化审查器反复对同类问题提出警告时，我们会在根源上解决它：直接改写审查 Skill、新增一条 Lint 规则，或者更新以下这些规范指导文件：

• CLAUDE.md：告知 Claude 该项目是什么：技术栈、编码规范、目标与非目标。每次审查都会加载此文件，因此在大型代码库中我们保持其简短，并在其中索引其他文档。审查器还会指出违反了其中约定的代码，以及导致该文件中某行内容过期的变更。
• REVIEW.md：由模块负责人（Code Owners）编写，用于告知审查器在他们负责的代码区域中到底什么才是最重要的。我们会单独检查审查器是否真正遵从了这些指令。优秀的规范文件通常很精炼，它们会明确写出该仓库中“失败/出错”的具体表现形式（对于文档仓库来说是“存在虚假描述”，对于配置仓库来说则是“路由错误”），限制吹毛求疵的微小意见数量（Cap the nits），列出可跳过的路径，并要求审查意见必须给出具体的文件与代码行作为证据，而不是凭名称瞎猜。它们还会要求审查总结以问题计数开头，并在无可挑剔时直白说明无需修改。

2. 对每个 PR 实施 AI 代码审查

在人工介入查看之前，每一个 PR 都会先接受 Claude 的审查。它会结合整个仓库的全局背景和 PR 声明的意图来阅读 Diff，并思考三个问题：这个变更是解决了它承诺的问题，还是适配了当前系统，亦或是破坏了其他模块？

如果是 Bug 修复类的变更，它会去探究根本原因。该能力的公开版本——适用于 Claude Code 的“Code Review”（代码审查功能）——现已在 Team 和 Enterprise 订阅计划中正式可用，而在本地执行 /code-review 即可运行一个更轻量的版本。

当我们在内部推出该功能的研究预览版时，获得实质性审查意见的内部 PR 比例从 16% 跃升到了 54%。

超过 1,000 行的 PR 大多数都会被找出问题，而绝大多数小型 PR 都能顺利通过。管理员可将各个仓库的审查级别设置为：快速（Quick）、标准（Standard）或深度（Deep）。在漏掉一个 Bug 的代价远超额外审查时间的场景下，“深度”模式非常值得。

审查发现的问题在呈现给人类之前，还会由其他智能体多方验证。多个 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. 依据风险等级进行人工审批

修复文档与修改自动更新器（Auto-updater）所承受的风险截然不同，因此二者面临的审查也完全不同。

风险等级由代码变更本身决定，而不是由提交人决定。分类器会通读改动内容并评估其风险层级。第二个分类器则会进一步甄别：即便初审层级显示不需要人工，该特定变更是否仍需要另加一人把关。某些关键路径始终强制要求人工介入，包括被代码负责人列为敏感区域的任何内容以及所有的 CI 工作流配置文件。

只有被列入仓库受信任名单的作者才能走轻量审批通道，这通常是该模块的归属团队成员。其余人员提交的代码则必须有第二个人批准。另外，Agent 的批准绝不能等同于人类的批准。自动化审查可以放行低风险变更，但它绝对无法替代对人类审批名额的要求。

谁发起了这个变更，谁就必须对其负责。对于 Agent 编写的 PR，指导该 Agent 的人类工程师将被列为必需的审查人之一，其责任等同于他亲自手写了这些代码。

一次批准仅对应特定的某一次 Commit。如果在批准后合入了系统无法担保的新提交（例如 Agent 的后续推送或有人手动解决的合并冲突），必须重新进行人工审批。

6. 合并队列、功能开关与分阶段灰度发布

合并队列（Merge Queue）会将每次变更与最新的主分支（main）代码结合重新运行所有检查，因此两个各自单独通过测试但存在潜在冲突的 PR，绝不会在合并后搞崩主干。新功能通常会先置于 Feature Flag 背后推给 Anthropic 内部员工使用，我们自身的高频使用往往能在用户感知之前暴露回退缺陷（Regressions）。公开发布时，代码会先推送到 latest（先行体验通道），而 stable（稳定通道）则保持滞后跟进。

7. 快速检测，极速回滚

百密终有一疏，错误总会溜过防线，因此最后一道防线在于“极速发现并阻断”。功能开关无需重新发版即可瞬间关闭。Claude Code 实行每周轮值（On-call），每次故障复盘时都会倒查：这本该在哪个防护层级被拦截下来？

发现糟糕的合并目前依然依赖于作者、值班人员以及回滚/事故监控大盘。我们尚未引入熔断机制（即当回滚或报警指标异动时自动收紧审批权限）；团队工程师们希望在推动更多代码走向“零人工合并”之前，先把这套断路保护落地。

一位同事曾指出：放慢交付速度确实能降低错误率，但这主要是因为你产出的总量变少了。我们宁愿在“发现问题并修复问题”上变得更快。

我们如何让审查器越变越聪明

我们的代码审查流程始终处于闭环迭代升级之中。

所有的线上事故如今都转化为了评测基准（Eval）。

团队收集了以往导致事故的历史 PR，附带它们当时的向前修复（Fix-forwards）提交和回滚提交，并让熟悉该业务代码的工程师确认每个 Bug 的真实性质及其潜伏位置。审查器每天都会对照这个评测集运行一次。

我们通过观察人类对评论的处理行为来衡量审查“噪音”。

如果你不介意误报一堆无害代码，想要抓出更多 Bug 是很容易的，因此我们需要制衡这一倾向。我们会对审查器留下的每一条评论进行分类统计，观察 PR 参与者的应对态度：是修复了它？指出该意见是错误的？解释该行为是特意设计的？还是认为此问题无关紧要？我们还会把审查器放到已知完全正确的干净 PR 上运行，统计它以多高频率提出误导他人做出有害改动的假警报。我们白纸黑字写明的原则是：优先捕捉真实 Bug，其次才是削减审查轮数。

当作者是 Agent 时，噪音的代价更加高昂。

人类可以在几秒钟内忽略掉一条吹毛求疵的小意见（Nit），但 Agent 看到意见后会老老实实去修改代码，这意味着会产生新的提交并触发新一轮的审查。

审查必须能够收敛（Converge）。

一个由 Agent 担任的作者和一个由 Agent 担任的审查器，彼此交互纠缠起来可以永无止境地拉扯下去。曾经有一个 CLI PR 在夜间被两方来回折腾了 50 多轮审查与修改，直到人类作者介入才强行叫停。

当我们用 git blame 溯源审查器反复提出的那些意见时，发现其中约 59% 的代码从审查器第一轮跑完时就一直存在。审查器很少是在发现新的 Bug，而是在每轮拉扯中陆陆续续挖掘出更多陈年旧账。

我们自己也推波助澜了这种恶性循环——我们以前默认执行多轮审查，因为每次通过确实能挑出点新东西。这在极高风险的改动上是值得的，但绝不适用于每一个 PR。目前团队将“通过所需轮数（Rounds-to-pass）”与“召回率（Recall）”一同纳入指标监控，并对二次审查（Re-review）进行了如下改革：

• 轮数硬性封顶： 经过三轮之后，审查器会主动要求作者跳出局部、重新审视当前的实现方案；
• 后续仅针对 Diff 审查： 在最初几轮过后，后续审查严格仅针对新增的增量 Diff，不再扫全量；
• 指出同类通病（Class of bug）： 要求作者一次性修改所有同类问题，而非单单修复某一行；
• 禁止重复提出已发布的审查意见。

此外，审查 Agent 每天夜间都会扫描存量代码，帮助我们在旧 Bug 蔓延到其他地方之前尽早将它们挖出来。

人类必须留在闭环中的核心领域

为了抓一个常规低级错误而把高级工程师从深度心流中抽离出来，其代价远高于自动化审查的开销。在 Anthropic，我们的工作重心已经从“通读每一行 Diff”转向了机器所不擅长的决策领域：

• 我们到底该不该做这个需求？方向把控、产品品味与范围界定。一个自称彻底解决了审查瓶颈的团队，仍然严格保留了对团队外部提交变更的人工审查，这样才有人能守住那道灵魂拷问：“我们真的有必要做这个吗？”
• 高危敏感代码：例如计费系统、自动更新程序以及 CI 核心工作流。
• 架构演进：可能会被其他模块竞相效仿的核心模式与架构设计。
• 研读验证凭据：审阅测试输出日志、实际执行的命令及返回结果、界面截图、审查器的最终意见等。如果你无法明确说出当前自动化检查可能会漏掉什么，那就老老实实发起一次全面的人工深度审查，切忌草率批准。
• 对结果全权负责：无论代码最初是由谁或由什么生成的，每一个合入发布的变更都必须有对应的人类承担全责。

跨团队上下文认知共享

代码审查的第二项核心职责历来是“在团队中同步并传播对代码库的理解”。阅读队友提交的代码 Diff，正是你学习新改动、理解各模块如何严丝合缝拼装在一起的关键途径。如果大部分阅读工作都被机器取代，大家又该如何熟悉和掌握代码？

我们在这方面并没有死板的正式流程。团队中没有任何人能够在脑海中保留一份 Claude Code 整个系统的全景思维模型，而且我们认为任何人也都没必要这么做。当某位工程师想要理解代码库的某个特定部分时，他们会直接要求 Claude 针对那一部分切片生成详细解读。这只需几分钟，且能准确反映代码截至今天的最新原貌。

我们中的一些人甚至更进一步：让 Claude 直接构建一个轻量级的交互式小组件（Artifact），将该部分代码可视化，并按照该工程师偏好的方式来讲解。

如果目标是把人类的注意力用在刀刃上，这种方式远胜于逐行死磕无聊的 Diff。一行文案的改动几乎无法带给你任何收获；但一份关于你即将动手模块的深度讲解文档，却能让你收益良多。此外，我们团队默认在公开透明的 Slack 频道中办公，这种文化也带来了巨大帮助——别人在构建什么，你在他们编码的过程中就能尽收眼底。

“谁上线，谁负责”（You Land It, You Own It）

如果你合并了一项小型或中型变更，而后续仍然引发了问题，按照团队规范，通常由你负责排查修复。以下几点保障了这一机制不会演变成灾难：

• 变更粒度细小：因此极易审查、易于调试、易于回滚；
• 一切皆可撤销：功能开关、即时回滚与分阶段灰度发布，能在几分钟内抹平绝大多数错误；
• 由爆炸半径（Blast radius）决定门槛：牵扯昂贵的关键代码，会匹配更多的人力和更严密的检查；
• 回退缺陷能快速暴露：遥测监控和内部员工狗粮机制（Internal use）能第一时间捕获异常；
• 对事不对人（免责文化）：由你负责跟进修复是因为你具备最全的上下文；故障复盘关注的是系统与机制本身的缺陷，而非责怪个人。

与此同时，所有权也是共享的。团队大部分成员都在开放频道工作，任何人都能随时围观他人搭建的成果、参与讨论，或者指挥 Claude 补全薄弱环节；许多建设性的反馈往往来自非该模块所有者的同事。这种透明开放，正是我们在不搞“逐行严防死守”的前提下依然能守住高质量红线的关键基石。

当我们决定推倒重来时

Agent 让“开启一个项目/写出一段代码”的成本变得极度低廉，因此很多工作成果其实根本不应该合入主干。通常只要群里有人随口质疑为什么这样做、指引大家参考更早的决策，或者建议一条更轻巧的路径，作者就会果断关闭或彻底重塑这个 PR。

由于代码写起来极快，直接关闭 PR 并不会让人觉得是一种沉没成本的损失。关键的诀窍在于：尽早在讨论串中提出不同的战略方向，而不是在代码全部写完后生成的 PR 下方留下一堆阻断合并的挑剔意见。

你该如何在团队中落地这套流程

实现这套方案所需的大部分拼图，在今天都已经触手可及。

在发起 PR 之前

• 为你的 Agent 提供可独立运行的检查手段，将其清晰罗列在一份简明扼要的 CLAUDE.md 中，并配置好能自动运行代码格式化工具与代码检查器的钩子（Hooks）；
• 在本地运行 /code-review 与 /security-review，或者发起一次全新独立上下文的子智能体审查；
• 新增一份 REVIEW.md，把过往反复出现的人工审查意见归纳沉淀进去。

在每个 PR 流程中

• 强制要求 CI 全绿，并在你的 PR 模板中加入“测试方式（Testing）”、“风险评估（Risk）”以及“如何回滚（How to revert）”三项内容；
• 在某个独立代码库中先行引入 AI 审查器（例如 Code Review for Claude Code 或 Claude Code GitHub Action），对 REVIEW.md 调优打磨几周，随后再向更多代码库推广；
• 接入自动化安全审查，并强制要求合并前必须把所有审查讨论串标记为已解决；
• 让审查力度与潜在风险动态匹配：对常规改动执行快速审查，对漏检代价高昂的高危改动执行深度审查（在 Code Review 中对应 Quick、Standard 或 Deep 档位）；
• 给审查轮数设置上限；在最初几轮过后，后续重审仅针对新增的增量 Diff。

审批阶段

• 制定并明确风险等级，评级应依据代码变更本身而非提交作者来界定；前期不妨定得严格一些，后续结合实证数据再逐步放宽；
• 为受信任的作者保留更快捷轻量的审批通道；
• 善用 CODEOWNERS（代码所有者机制）与分支保护规则，确保认证授权、计费、CI 与发布工作流以及安装脚本始终必须有人类把关审批；
• 绝不允许机器人的批准冲抵人类专员的批准名额；一旦检测到新的 Commit，立即作废重置已有的人工批准。

合并及后续阶段

• 采用合并队列、功能开关（Feature Flags）、内部全员试用先行、分阶段灰度发布以及一键快速回滚机制；
• 将历史事故和回滚案例转化为标准化评测集，每当审查器的提示词、工具链或底层模型发生升级变动时，对照全量案例重新跑分评测；
• 持续度量人类被占用的审查时间，并以回滚率与事故发生率作为底线安全防线。

未来演进方向

在 Code Review 的官方发布公告中曾明确声明：批准 PR 最终仍然是一项属于人类的决断；产品输出的是“审查意见（Findings）”，而非“放行审批（Approvals）”。然而 Anthropic 自己的代码库走得更远：我们允许代码库负责人自主决定哪些低风险的改动可以纯粹基于自动化检查通过即行合并，而且这条分界线正在随着信任的建立不断向前推移。

每当自动化审查漏掉了某个缺陷，我们首先会倒查：模型在审查时缺失了什么上下文？随后将弥补措施固化进 CLAUDE.md、新增一个检测 Skill 或者补上一道自动化检查机制。我们的终极目标始终坚定不移：让每次变更所耗费的人类精力越来越少，同时保证代码回滚率绝不高于以往。