Claude Code团队如何做代码审查？自动化审查与风险分级实践

在 AI Agent（智能体）接管日常编程的今天，软件工程正经历一场范式转移：当 AI 能以几十甚至上百倍于人类的速度生成代码时，传统靠工程师逐行肉眼把关的代码审查（Code Review）机制，瞬间沦为最大生产力瓶颈。

Anthropic 旗下的 Claude Code 团队正处于这场变革最前线——这个项目本身已有超过 90% 的代码由 Claude 自主编写。面对海量代码产出，他们如何在不牺牲系统稳定性的前提下重塑审查流程？人类工程师的角色又该怎样演进？

本文翻译自 Claude Code 开发者团队博客文章《How the Claude Code team does code review》，系统复盘该团队从“人肉看代码”转向“人机协同分级审查”的实战经验，涵盖自动化门禁、风险分级、审查收敛机制和事故评测驱动的持续改进方案。

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

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

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

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

从 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 会话）发起，会穿过多个代码审查层级。

Claude Code 一项变更的典型生命周期

逐层深入

多层防护，而非单一关卡

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）编写，告知审查器在他们负责的代码区域中什么最重要。我们会单独检查审查器是否真正遵从这些指令。优秀规范文件通常很精炼，会明确写出该仓库中“失败/出错”的具体表现（文档仓库是“存在虚假描述”，配置仓库是“路由错误”），限制吹毛求疵的微小意见数量，列出可跳过的路径，并要求审查意见给出具体文件与代码行作为证据，而不是凭名称瞎猜。它们还会要求审查总结以问题计数开头，并在无可挑剔时直白说明无需修改。

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 代码规范、类型检查、全平台测试套件以及构建编译。一个典型 CLI PR 在人工查看前可能会先跑几十项检查。PR 模板会明确要求阐述“该变更是如何测试的”以及“如何回滚”。Claude 可以代为填写这些内容，但提出变更需求的人必须签字确认。

5. 依据风险等级进行人工审批

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

风险等级	示例	人工批准要求
低（Low）	文档、文案改动、仅内部可用的功能、置于 Feature Flag 背后的增量改动	自动化审查与安全检查全绿后，无需人工批准
中（Medium）	常规产品功能改动，以及对缓存、自动更新器或系统提示词等敏感区域的修改	需 1 人批准
高（High）	最高风险的核心代码，以及少数固定必须双人确认的特殊路径	需 2 人批准

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

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

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

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

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

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

7. 快速检测，极速回滚

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

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

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

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

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

所有线上事故如今都转化为评测基准（Eval）。 团队收集以往导致事故的历史 PR，附带向前修复提交和回滚提交，并让熟悉业务代码的工程师确认每个 Bug 的真实性质及潜伏位置。审查器每天都会对照评测集运行。

事故即评测集

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

当作者是 Agent 时，噪音的代价更加高昂。 人类可以在几秒内忽略一条吹毛求疵的小意见，但 Agent 看到意见后会老老实实去修改代码，这意味着会产生新提交并触发新一轮审查。

审查必须能够收敛（Converge）。 一个由 Agent 作者和 Agent 审查器组成的闭环，可以无止境拉扯下去。曾经有一个 CLI PR 在夜间被两方来回折腾了 50 多轮审查与修改，直到人类作者介入才强行叫停。

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

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

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

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

实现审查收敛

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

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

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

人类决策的核心边界

跨团队上下文认知共享

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

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

跨团队上下文共享示意图

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

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

“谁上线，谁负责”

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

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

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

当我们决定推倒重来时

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

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

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

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

在发起 PR 之前

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

在每个 PR 流程中

• 强制要求 CI 全绿，并在 PR 模板中加入“测试方式”“风险评估”“如何回滚”三项内容；
• 在独立代码库中先行引入 AI 审查器，对 REVIEW.md 调优打磨几周，再向更多代码库推广；
• 接入自动化安全审查，并要求合并前所有审查讨论串标记为已解决；
• 让审查力度与潜在风险动态匹配：常规改动快速审查，高危改动深度审查；
• 给审查轮数设置上限；最初几轮后，重审只针对新增增量 Diff。

审批阶段

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

合并及后续阶段

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

未来演进方向

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

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

如果你的团队也开始允许 Agent 自主发起 PR，我们很想听听你的经验：哪些检查交给了自动化？哪些环节仍必须由人类坐镇？在你看来，我们当前方案还有哪些盲区？

特别感谢 Emma Webb、Michael Segner 与 Amie Rotherham 对本文提出的宝贵审阅意见。

原文链接：How the Claude Code team does code review

如果你也在实践 AI 研发流程，欢迎到 云栈社区 分享你的审查方案与踩坑经验。