Claude Code 团队：如何进行代码评审
来源：微信公众号 HiFox AI · 原文链接
代码由 AI 写得越来越快，评审会不会成为新的瓶颈？如果再让 AI 来审，谁判断它提出的问题是否值得修改，又由谁为最终上线的结果负责？
最近，Anthropic 的开发者博客发表长文，介绍 Claude Code 团队的内部代码评审实践。按团队披露的数据，从 6 月到 9 月，合并的 PR 数量增长了一倍以上，需要回滚的比例却下降了超过 40%。
这套流程里既有并行找问题、交叉核验的 Agent，也有 CI、安全检查、按风险分配的人工审批，以及发布后的监测和回滚。团队还分享了一次颇有代表性的经历：一个 PR 在一夜之间反复评审、修改了 50 多轮，最终需要作者出面叫停。
这篇文章也许能帮助正在使用 AI 编程的团队，重新审视自己的验证、评审和交付流程。
原文：How the Claude Code team does code review
链接：https://claude.dev/blog/solving-code-review-at-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 单体仓库每天合入的改动，从 5 月的约 2500 次增长到 9 月的 30000 多次。（详情可见《Anthropic 没先换掉程序员，先换掉了 Git？》）
Claude Code 使用单独的仓库，并不在这个单体仓库里，但同样承受着很大的压力。以这样的速度交付，逐行进行人工评审已经极其困难，甚至可能根本做不到。
代码评审承担两项任务：
- 在问题随代码发布之前，发现并修复它们。
- 在团队中建立共同的上下文，加深大家对代码库的理解。
本文主要讨论第一项，接近结尾时也会回到第二项。
我们认为，用“有没有人读过这些代码”来衡量评审，并不能准确反映真正需要回答的问题：这次改动可能在哪些地方出错？哪些自动检查或人工检查最适合发现这些问题？
这样的提问也改变了评审介入的时间。过去，评审位于流程末端：写完代码，创建 PR，然后等同事来看。
现在，评审会持续运行，就像写作时一直开启的拼写检查。在请人查看之前，大部分改动已经由 Claude 至少评审、修复过一轮。常见错误因此能提前被发现，团队则可以把注意力留给更高层次的问题与审查。
最稀缺的资源：人的时间与注意力
我们希望把人的时间和注意力留给只有人能解决的问题，让自动检查负责发现其余问题。以目前的改动速度，仍有大量工作需要人来完成，团队几乎每天都会遇到新的挑战。
计算人工时间时，必须把评审成本的两端都算进去：一端是人们评审代码花费的时间，另一端是修复有问题的代码所造成的后果。如果前一端省下来的时间又出现在后一端，那就没有帮助。
因此，我们的目标是：在** Claude Code 的各个仓库中，包括 CLI、桌面应用、Web 应用和移动应用，让大部分 PR 最多只需要一位人类参与者，这个人可以就是作者本人，同时不增加回滚和事故。**
为了衡量人工投入，我们会跟踪每个 PR 的人工批准次数，包括中位数和第 95 百分位数，也会统计人工评论，以及 PR 等待人来处理的时间。
回滚率和事故率为这项优化划出了边界。如果这两个指标上升，说明我们只是把人工时间转移到了别处，并没有真正节省时间。
一次代码改动的旅程
一次典型的改动，无论始于工程师的电脑，还是 Slack 中的一次 Claude 会话，都会经过多层代码评审。
大部分路径是自动化的；人的注意力会集中在风险所在的地方
一层一层地检查
每一层都会发现一些问题而忽略其他问题。很少有东西能通过所有层，其余的则由回滚处理
在请别人查看之前，先验证工作成果
如今，大量评审工作发生在 PR 创建之前。我们会给 Claude 提供实际可执行的验证手段，例如测试、构建，或者生成截图来对照设计，并要求它展示运行结果，而不是只说“完成了”。随后，让一个拥有全新上下文的子 Agent 再审一遍 diff。这两个习惯都来自我们的最佳实践指南。
许多人在创建 PR 前，还会运行几项内部 skill：一项专门寻找 bug，一项简化代码改动，还有一项检查端到端的实际行为。如果涉及 UI，也会对照设计规范检查。
Claude Code 的创建者 Boris Cherny 曾表示，为 Claude 提供验证自身工作的方法，可能是获得良好结果最重要的一件事。他估计，这能让最终结果的质量达到原来的两到三倍。他写道：
如果自动评审器反复指出同一种问题，我们会从源头处理：修改 skill，添加 lint 规则，或者更新指令文件。例如：
- CLAUDE.md 用来说明这个项目是什么。 它记录技术栈、约定、目标，以及明确不做的事情。每次评审都会加载这份文件，因此在大型代码库中，我们会让它尽量简洁，再链接到其他文档。评审器会指出违反其中约定的代码，也会指出那些让文件中某条说明不再成立的改动。
- REVIEW.md 用来说明这部分代码应该重点审什么。 它由代码负责人编写，我们还会另行检查评审器是否确实遵循了这些要求。
好的 REVIEW.md 往往很短。它会明确这个仓库中什么算失败：对文档而言，是内容失实；对配置而言，是路由出错。它会限制对细枝末节的挑剔，列明应跳过的路径，并要求评审意见提供具体文件和行号作为证据，避免仅凭名称猜测。
它也会要求摘要开头先报出问题数量。如果没有需要修改的地方，就直接说明。
每个 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 可能已经又走完了一轮。
能够阻止合并的安全评审
安全检查有独立的自动评审流程。只要 bug 评审或安全评审中仍有未解决的问题，PR 就不能合并。你需要修复问题，或者写下简短理由后关闭讨论；误报也通过这种方式处理。
如果后续提交修复了某个问题，对应的评审发现就会自动清除。
你可以使用开源的安全评审 GitHub Action，或者 /security-review 命令，搭建类似的流程。具体配置见 Claude Code 自动安全评审。
能够阻止合并的自动检查
这里包括大家熟悉的检查：lint、类型检查、各个平台的测试，以及构建。我们也介绍过如何扩展 CI 来应对这种代码量。
一个典型的 CLI PR 在交给人查看之前，可能已经运行了几十项检查。
PR 模板还会要求说明：这次改动如何测试，出了问题如何撤销。Claude 可以代为填写，但发起这项改动的人必须确认这些内容。
根据风险分配人工审批
修正文档与修改自动更新器的风险不同，需要的评审自然也不同。
风险等级由改动决定，而不是由作者决定。 一个分类器读取改动并判定风险等级。第二个分类器则进一步判断：即使当前等级没有要求，这次具体改动是否仍然需要另一个人参与？部分路径始终要求人工介入，包括负责人列出的敏感内容，以及所有 CI 工作流文件。
只有可信任的作者才能走较宽松的审批路径。 这种资格仅限仓库信任名单中的作者，主要是负责该仓库的团队成员。其他人都需要第二个人批准。
Agent 的批准也永远不能计入人工批准。自动评审可以让低风险改动通过，但无法占用明确要求由人来批准的名额。
指示 Agent 进行改动的人，需要为改动负责。 对于 Agent 编写的 PR，指挥它的人可以算作要求的评审者之一，就像这些代码由他亲手编写一样。
一次批准只覆盖某个具体提交。 如果后续出现了系统无法确认仍受原批准覆盖的新提交，例如 Agent 推送了代码，或者有人手动解决了合并冲突，就需要重新批准。
合并队列、功能开关与渐进发布
合并队列会将改动应用到最新的 main 上，再次运行全部检查。这样可以避免两个单独通过检查的 PR 合在一起后，却让主分支出问题。
新行为通常先通过功能开关向 Anthropic 员工开放。内部的高强度使用，常常能在用户遇到问题之前暴露回归。
公开发布则先进入 latest 渠道，stable 渠道稍后跟进。
尽快发现，尽快回滚
错误仍有可能漏过检查，因此最后一层关注的是尽快发现问题。关闭功能开关不需要重新部署。Claude Code 每周轮换值班人员，事故复盘则会追问：哪个环节本应该发现这个问题？
目前，识别有问题的合并仍然依赖作者、值班人员，以及回滚和事故看板。我们尚未建立能在这些指标变化时自动收紧审批要求的熔断机制。这里的工程师希望，在更多代码进入零人工参与的合并流程之前，先把这样的机制建起来。
一位同事说，放慢速度确实能降低错误率，但很大程度上只是因为所有事情都做得更少了。我们更希望加快发现和修复问题的速度。
如何让评审流程不断变好
我们的代码评审流程一直在循环改进。
每一次事故都会成为评测案例。团队收集了历史上引发事故的 PR，以及对应的后续修复和回滚，再由熟悉这些代码的工程师确认 bug 及其具体位置。评审器每天都会在这套案例集上运行。
每次事件都会使评估值增长，每位评审人员的每次更改都会针对整个评估进行评分
我们通过人们如何回应评审意见来衡量噪声。 如果允许大量非 bug 被报出来，提高 bug 检出数量并不困难，因此我们需要检查这一点。
我们会按照 PR 参与者的回应，对评审器留下的每条评论分类：对方修复了问题、指出判断错误、解释该行为是有意设计的，或者认为这件事无关紧要。
我们还会让评审器检查已知没有问题的 PR，统计它提出可能诱导人做出有害修改的意见的频率。我们明确写下的优先级是：首先发现真实 bug，其次减少评审轮数。
当作者是 Agent 时，噪声会带来更高的成本。 人可能几秒钟就略过一条小建议，Agent 却会去修改，于是多出一次提交，也多出一轮评审。
评审必须能够收敛。 一个写代码的 Agent 和一个审代码的 Agent，可能让彼此一直忙下去。曾有一个 CLI PR 在一夜之间经历了 50 多轮评审和修改，最终由作者出面叫停。
我们对评审器持续指出问题的代码运行 git blame，发现其中约 59% 在第一轮评审时就已经存在。评审器通常只是每轮又找到了一些旧 bug，很少是在发现新出现的 bug。
评审反复往返
评审器很少是在发现新 bug，更多是每一轮又找出几个旧问题。
我们自己的习惯也加剧了这种情况。因为每一轮都能再发现一点问题，我们渐渐习惯默认多跑几轮。对于高风险改动，这可能值得，但并不适用于每个 PR。
现在，团队会同时跟踪召回率和通过评审所需的轮数，并调整复审方式：
- 设置轮数上限。 三轮之后，评审器会请作者退一步，重新考虑实现方案。
- 在最初几轮之后，只复审新增 diff。
- 指出整类 bug。 让作者一次修复所有同类问题，而非只改某一行。
- 不再重复发布已经提出的问题。
评审 Agent 也会每晚扫描现有代码，帮助我们在旧 bug 于其他地方暴露之前发现它们。
合并更改后，每个内部拉取请求的审查轮次减少
哪些事情仍然需要「人」来做
为了抓住一个常规错误，把资深工程师从深度工作中打断，成本远高于执行一次自动评审。在 Anthropic，我们的工作已经转向机器不擅长的判断：
- 这件事究竟该不该做？ 包括方向、品味和范围。某个已经宣布解决评审瓶颈的团队，仍会对团队外部的改动保留人工评审，让人问一句：“我们到底该不该做这件事？”
- 高风险代码。 例如计费、自动更新器和 CI 工作流。
- 架构。 因为它确立的模式会被其他人继续沿用。
- 审读证据。 包括测试输出、实际运行的命令及返回结果、截图，以及评审器发现的问题。如果你说不清这些检查可能漏掉什么，就应该请人认真评审，不能只是匆匆点下批准。
- 对结果负责。 每一项发布的改动，都有一个人承担责任，无论代码是谁敲出来的。
人们从阅读每个差异转向了机器不擅长做出的决策
团队怎样继续理解代码库
代码评审的另一项长期职责，是在团队中传播对代码库的理解。阅读同事的 diff，能让你知道发生了什么变化，以及各个部分如何配合。
如果大部分代码阅读都交给机器，大家又该怎样学习代码？
我们没有为此建立正式流程。团队中没有人能在脑中保留 Claude Code 的完整心智模型，我们也不认为有人必须做到。
当某个人想理解代码库中的一部分时，他会请 Claude 专门针对那一部分写一份讲解。几分钟就能完成，而且反映的是当前代码的实际状态。
如果目标是更好地使用人的注意力，这比逐行阅读琐碎的 diff 更有效。单行文案改动几乎教不会你什么；而一份解释你马上要修改的模块的文档，却能让你学到很多。
默认在开放的 Slack 频道中开展工作的文化，也有助于此。别人开发的过程中，你就能看到他们正在做什么。
谁合入，谁负责
如果你合入一项小型或中型改动，后来还是出现了问题，团队通常会由你来修复。下面几项做法，让这样的惯例能够运转：
- 保持改动小。 便于评审、调试和回滚。
- 让改动可撤销。 功能开关、回滚和分阶段发布，能让大多数错误在几分钟内被撤销。
- 由影响范围决定要求。 出错代价越高的代码，需要更多人参与、更多检查。
- 让回归尽早暴露。 依靠遥测和内部使用及时发现。
- 修复责任与上下文相对应。 由你处理，是因为你掌握的信息最多；事故复盘关注的是系统，而非归咎个人。
责任也由团队共同承担。团队中的许多人在开放频道工作，任何人都能看到其他人在做什么、接手讨论，或者让 Claude 去补上某个缺口。反馈也会来自不负责那部分代码的人。
这种开放性，是我们能够保持质量的重要原因。我们因此不必在每一行代码前都设置人工关卡。
什么时候需要调整方向
Agent 大幅降低了启动一项工作的成本，因此总有一些已经开始的工作最终不该合入。
通常，频道里会有人询问为什么要做、指出此前已经作出的决定，或者提出更简单的路径。作者随后关闭 PR，或重新调整它。
由于代码编写得很快，关闭 PR 不会让人觉得损失很大。关键在于，尽早在讨论中提出不同方向，让作者及时调整；不要等 PR 已经完成，才留下一条阻止合并的评论。
你的团队怎样采用这套流程
今天，在团队中实践这些做法所需要的大多数工具与机制，已经具备。
实施流程概览
下面的图是简要概览，完整步骤还包括安全评审和事故率监测等内容，详见后面的清单。
创建 PR 之前
- 为 Agent 提供可执行的检查，并写进简短的CLAUDE.md。再配合 hooks，运行格式化工具和 lint 工具。
- 在本地运行/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 对本文的审阅。
关注 HiFox AI，及时获取 最新 AI 资讯~
欢迎使用 HiFox，一个多人与多 Agent 的协作平台，轻松指挥一堆 Agent 同时并行工作！
HiFox 是什么？
**👉 立即体验 Hifox： **https://hifox.com
