Claude Code 团队如何做代码审查

本文来源： AI灰鲸（公众号：AI灰鲸）
原文链接： https://mp.weixin.qq.com/s/7CdewifSJ-3c2LV5xic9hQ
发布时间： 2026-10-21 07:08

作者： AI灰鲸　　发布时间： 2026-10-21 07:08

最近，Claude Code 团队公开了自己的代码审查流程。代码大量由 AI 生成以后，他们关注的是：怎样减少每次变更占用的人工时间，同时不让回滚和事故增加？这篇文章给出了从本地验证、AI 审查、风险分级到灰度发布的完整做法，也交代了误报、反复审查和团队知识共享这些容易被忽略的问题。

Claude Code 团队此前透露，Claude Code 自身约 90% 的代码由 Claude 编写。代码以这样的速度产出，审查该怎么做？还有人在读代码吗？一旦出了问题，又由谁来发现？

这篇文章介绍了该团队的代码审查流程及其演变。团队给出的数据是：从 2026 年 6 月到 9 月，Claude Code 代码库中合并的拉取请求（Pull Request，简称 PR）的数量增长到原来的两倍以上，而需要撤回的 PR 占比相对下降了超过 40%。这里下降的是回滚比例，不是减少了 40 个百分点。

他们仍然保留审查，但把大部分代码阅读交给机器，围绕人的时间和注意力优化流程，并投入大量工作，让错误能够被快速、方便地撤销。

01 · 重新思考代码审查的目的

当智能体开始写代码，变更数量会迅速增加。2026 年，Anthropic 的单体仓库（monorepo，把多个项目放在同一代码仓库中管理）每天落地的变更，从 5 月的大约 2,500 次增长到 9 月的 30,000 多次。

Claude Code 使用独立仓库，并不在这个单体仓库里，但同样面临很大的变更压力。达到这样的交付速度后，依靠人工逐行审查代码，即使不是完全做不到，也会变得极其困难。

代码审查承担两项工作：

1. 在问题发布给用户之前，发现并修复它们。
2. 让团队共享上下文，形成对代码库的共同理解。

原文主要讨论第一项，后面也会回到第二项。

在团队看来，仅问“有没有人读过这段代码”，还不能准确判断审查是否到位。他们更关注：这次变更可能在哪里出错？应该由哪种自动化检查或人工检查来发现？

这个问题也改变了审查发生的时间。过去，审查是开发末尾的一道关卡：写完代码、提交 PR，再等同事来看。现在，审查持续发生，更像写作时随时进行的拼写检查。大多数变更交给人看之前，Claude 已经至少审查并修复过一轮。这样能先处理掉大部分常规错误，让团队把注意力留给更高层次的问题和深入判断。

02 · 稀缺的是人的时间和注意力

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

计算人工成本时，需要把两笔时间一起算进去：一笔是审查代码的时间，另一笔是修复坏代码所造成损失的时间。如果省下的审查时间最后都变成了救火时间，优化就没有意义。

因此，他们希望 Claude Code 各个仓库中的大多数 PR，包括 CLI、桌面端、Web 端和移动端，都能在至多一名人类参与的情况下合并；这个人可以就是作者本人。前提是，回滚和事故不能增加。

衡量人工投入时，团队会跟踪每个 PR 的人工批准次数，包括中位数和第 95 百分位数，还会记录人工评论数量，以及 PR 等待某个人处理的时长。第 95 百分位数可以帮助观察那些需要较多人工介入的 PR，而不只看典型情况。回滚率和事故率则用来守住质量底线：如果这两个指标上升，人的工作量只是被挪到了后面。

03 · 一次变更的完整流程

一次典型变更，可能始于工程师的笔记本电脑，也可能始于 Slack 中的一次 Claude 会话。之后，它会经过多层代码审查和验证。

04 · 逐层拆解审查流程

1. 交给别人之前，先验证工作结果

现在，大部分审查发生在 PR 创建之前。团队会给 Claude 可以实际执行的验证手段，例如测试、构建，或一张用来对照设计稿的截图，并要求它展示运行结果，不能只说“做完了”。然后，再由一个使用全新上下文的子智能体审查代码差异，也就是 diff。这里的“全新上下文”，是指审查者不带着此前写代码的对话记录来阅读改动。这两项做法都来自他们的最佳实践指南。

提交 PR 之前，许多成员还会运行几个内部技能：分别查找漏洞、简化代码差异，以及端到端检查实际行为。端到端检查关注的是完整使用流程能否跑通。涉及界面的变更，还会对照设计规范检查。

Claude Code 的创建者 Boris Cherny 曾把“让 Claude 有办法验证自己的工作”称为取得好结果时可能最重要的一件事。他估计，这能让最终结果好上两到三倍。这是他的经验判断；具体怎么验证，要看领域：可以是运行一条 Bash 命令、一套测试，也可以是在浏览器或手机模拟器中测试应用。

如果自动审查器总是指出同一类问题，团队会回到源头修改技能、增加 lint 规则，或更新指导文件。lint 是用工具自动检查代码规范及部分可疑写法。这里常用两份文件：

• CLAUDE.md

说明项目的技术栈、约定、目标，以及明确不做什么。每次审查都会加载它，因此在大型代码库中，团队会保持文件简短，把详细内容放到其他文档中再指过去。审查器既会标记违反这些约定的代码，也会指出哪些变更让文件里的某条说明过时了。

• REVIEW.md

由代码负责人编写，告诉审查器这一部分代码最应该关注什么。团队还会单独检查审查器是否真的遵守它。好的文件通常很短：说清这个仓库里“出错”意味着什么，例如文档的错误是“说错了事实”，配置的错误是“把请求路由到了错误位置”；限制细枝末节问题的数量，列出应该跳过的路径，并要求用具体文件和行号提供证据，不能仅凭名字猜测。审查摘要应先给出问题数量，没有需要修复的内容时也要直说。

2. 每个 PR 都接受 AI 审查

每个 PR 在交给人看之前，都会先经过 Claude 审查。Claude 会结合整个仓库和 PR 声明的意图阅读 diff，判断这次改动是否解决了目标问题、是否符合现有系统，以及会不会破坏其他功能。遇到漏洞修复，它还会检查是否找到了根本原因。

按照原文发布时的说明，对外提供的 Code Review for Claude Code 已在 Team 和 Enterprise 方案中正式开放；本地也可以使用 /code-review 运行较轻量的版本。

研究预览版推出后，内部 PR 中收到实质性审查意见的比例，从 16% 提高到 54%。超过 1,000 行的大多数 PR 都会被发现问题，大多数小 PR 则没有问题。管理员可以为每个仓库选择 Quick、Standard 或 Deep 三档审查深度。如果漏掉一个漏洞的代价高于多花的审查时间，Deep 就值得使用。

审查意见在交给人之前，还要经过其他智能体验证。多个智能体会并行查找漏洞，再由另一组智能体对每个发现投票。只有足够多的验证者同意问题真实存在，意见才会发出来。纯粹关于风格、诊断信息或清理代码的意见会被过滤；团队先在自己的 PR 上做过 A/B 测试，再保留这些过滤规则。

留下的问题以行内评论呈现，按严重程度排序，并标为 Important（重要）、Nit（小问题）或 Pre-existing（既有问题）。最后一种标签用于区分本来就存在的漏洞，避免把不是本次 PR 引入的问题算到作者头上。

每条意见都必须得到回应：要么修复，要么说明理由并将讨论标记为已解决。智能体经常会在夜间接手修复，所以作者回来时，PR 可能已经又经历了一轮审查。

3. 安全审查有权阻止合并

安全问题还会单独接受自动审查。无论漏洞审查还是安全审查，只要还有未关闭的问题，PR 就不能合并。作者需要修复它，或附上简短理由后关闭讨论；误报也通过这种方式处理。

如果后续提交修复了问题，对应的问题项会自动清除。团队表示，其他开发者也可以用开源的安全审查 GitHub Action，或 /security-review 命令，搭建类似流程。相关设置方法见其《Claude Code 中的自动化安全审查》说明。

4. 自动化检查同样能阻止合并

这一层包括常规检查：lint、类型检查、各个平台的测试，以及构建。团队另有文章介绍如何为这样的变更规模扩展持续集成（CI，也就是代码提交后自动执行的构建和检查流程）。一个普通的 CLI PR，在人开始看之前，可能已经运行过几十项检查。

PR 模板还要求说明：改动是如何测试的，以及出了问题如何撤销。Claude 可以填写这些内容，但提出这次变更的人必须确认。

5. 根据风险，决定需要多少人工批准

改一处文档与修改自动更新程序，风险不同，审查要求也不同。团队采用以下分级：

• 低风险

示例：文档、文案、仅供内部使用的功能，以及由功能开关控制的新增改动
人工批准要求：自动审查和安全检查通过后，无需人工批准

• 中风险

示例：常规产品改动，以及涉及缓存、自动更新程序或系统提示词等敏感区域的改动
人工批准要求：一人批准

• 高风险

示例：风险最高的代码，以及少数始终要求两人审查的路径
人工批准要求：两人批准

风险等级由变更内容决定。一个分类器读取改动并确定等级，另一个分类器进一步判断：即使等级规则说不用增加人工，这次具体改动是否仍需要再找一个人来检查？部分路径始终需要人工，包括负责人列为敏感的路径，以及所有 CI 工作流文件。

较宽松的审批路径只适用于仓库信任名单中的作者，其中主要是负责该仓库的团队成员。其他作者都需要第二个人批准。智能体的批准也不能算作人的批准：自动化审查可以放行低风险改动，但不能替代规则明确要求的人工名额。

谁指挥智能体做了这次变更，谁就要负责。在智能体编写的 PR 中，指挥它的人可以算作所需审查者之一，和亲手写下代码时一样。

一次批准只对某个具体提交有效。如果后来出现系统无法担保的新提交，例如智能体再次推送了代码，或有人手动解决合并冲突，就必须重新批准。不能把对旧版本的认可，直接延续到已经变化的代码上。

6. 合并队列、功能开关与逐步发布

合并队列会把变更应用到最新的 main 主分支上，再重新运行全部检查。这样可以防止两个单独检查都通过的 PR，合在一起却把主分支弄坏。

新行为通常先放在功能开关后面，让 Anthropic 员工使用。功能开关可以控制某项功能是否启用，而不必把“代码已上线”和“对所有人开放”绑定在一起。团队在内部高频使用产品，常常能早于外部用户发现功能回退或其他回归问题。

公开发布时，版本先进入 latest 通道，再由 stable 通道随后跟进。

7. 尽快发现问题，尽快回滚

仍然会有错误漏过去，因此最后一层关注的是发现速度。功能开关可以直接关闭，不必重新部署。Claude Code 团队按周轮换值班人员，事故复盘时会追问：本来应该由哪一层发现这个问题？

目前，识别有问题的合并仍依赖作者、值班人员，以及回滚和事故看板。团队尚未建立一种“熔断”机制，在相关指标变差时自动收紧审批要求。工程师们希望先补上它，再让更多代码通过无需人工参与的路径合并。

有位同事的看法是，放慢速度确实会降低出错率，但很大程度上只是因为所有事情都做得更少了。团队更愿意提高发现问题和修复问题的速度。

05 · 他们如何改进审查器

代码审查流程本身也在持续迭代。

每次事故都会进入评测。团队收集曾经引发事故的 PR，连同后续修复提交和撤回记录，交给熟悉相关代码的工程师确认：漏洞是否真实存在，具体在哪里。审查器每天都会在这套用例上运行。这里的评测集，就像一套由真实事故组成的考题，用来检验审查器能否发现曾经漏掉的问题。

团队通过观察人们如何处理评论，衡量审查噪声。如果容忍把大量正常代码也报成问题，发现更多漏洞并不难，所以必须同时约束误报。每条审查评论都会按 PR 相关人员的反应分类：确实修复了、认为审查器判断错误、说明这是有意设计的行为，或决定该问题不重要。

他们还会让审查器检查那些已知没有问题的 PR，统计它有多大概率给出可能诱使人做出有害修改的意见。团队把优先级明确写了下来：先保证发现真实漏洞，再减少审查轮次。

当作者是智能体时，噪声的代价更高。人可能几秒钟就能略过一个无关紧要的小建议，智能体却可能真的去改，于是又增加一次提交，再触发一轮审查。

审查必须能够收敛，也就是逐渐达到可以结束的状态。负责写代码的智能体与负责审查的智能体，可能无休止地给对方找事做。团队曾有一个 CLI PR，一夜之间经历了超过 50 轮审查和修复，直到作者介入才停下来。

他们用 git blame 追溯审查器反复标记的代码，发现其中约 59% 在第一轮审查时就已经存在。git blame 可以查看每一行代码最后由哪次提交修改。这说明审查器很少是在发现后续修改新引入的漏洞，而是每一轮又找出几个原先就存在的问题。

团队自己的习惯也加重了问题：既然每轮都能发现新东西，就默认多跑几轮。高风险改动可能值得这样做，但没必要让每个 PR 都经历同样的过程。因此，他们开始同时跟踪通过审查所需的轮次和召回率。召回率衡量的是，真实存在的问题中有多少被审查器发现。复审流程也作了调整：

• 设置轮次上限：三轮之后，审查器会请作者暂停下来，重新考虑整体做法。
• 前几轮之后，只复审新产生的代码差异。
• 指出问题所属的类别，让作者一次修复所有同类情况，而不只改某一行。
• 已经发过的问题不再重复提出。

审查智能体还会每晚检查已有代码，尽量在老漏洞出现在别处之前把它们发现出来。

06 · 哪些事情仍然需要人来判断

把一位正在专注工作的资深工程师叫出来，让他找一个常规错误，代价远高于一次自动审查。在 Anthropic，人的工作逐渐从阅读每一份 diff，转向机器不擅长的判断：

• 这件事到底该不该做？这涉及方向、品位和范围。某个团队即使宣布解决了审查瓶颈，仍然保留对团队外部提交的人工审查，好让有人能够问一句：“这件事有必要做吗？”
• 高风险代码，例如计费、自动更新程序和 CI 工作流。
• 架构设计，因为它会确立后来者继续沿用的模式。
• 读懂验证证据，包括测试输出、运行的命令及返回结果、截图，以及审查器的发现。如果说不清这些检查可能漏掉什么，就应该请人认真审查，而不是迅速点一下批准。
• 对结果负责。无论代码由谁敲出来，每一次发布都必须有具体的人承担责任。

07 · 团队如何共享对代码的理解

代码审查一直还有另一项职责：让团队了解代码库。阅读同事的 diff，可以知道哪里变了，各部分又如何配合。如果大部分阅读交给机器，人该如何理解代码？

团队目前没有正式流程。没有哪个成员能在脑中装下 Claude Code 的完整模型，他们也不认为有这个必要。有人想了解代码库中的某一部分，就让 Claude 针对那一小块写一份讲解。几分钟就能完成，而且讲的是代码当前的实际状态。

有些成员还会更进一步，让 Claude 制作一个小型可视化作品，将这部分代码画出来，并按照自己偏好的学习方式讲解。

如果目的是把人的注意力用好，这比逐行阅读琐碎 diff 更有效。改了一行文案，几乎教不了读者什么；针对马上要修改的模块写一份讲解，却能帮助理解很多东西。团队默认在公开的 Slack 频道中协作，这也有助于共享上下文：其他人正在做什么，大家在工作进行时就能看见。

08 · 谁把变更合进去，谁负责

如果合并的是一项小型或中型改动，后来却出了问题，通常由推动这次变更的人负责修复，这是团队的惯例。它能够运作，依赖几个条件：

• 变更保持小规模，便于审查、调试和撤回。
• 尽量让一切可撤销。功能开关、代码撤回和分阶段发布，能在几分钟内纠正大多数错误。
• 用影响范围决定要求。出错代价高的代码，需要更多人和更多检查。
• 通过遥测和内部使用，尽快发现回归问题。遥测就是收集软件运行时的状态和行为数据。
• 修复责任并不等于追责。让某个人负责修复，是因为他掌握最多上下文；事故复盘关注的是系统哪里出了问题。

责任也由团队共同承担。很多成员在公开频道工作，任何人都可以了解其他人正在做什么、接上某个讨论，或让 Claude 去补一个缺口。反馈也会来自并不直接负责这段代码的人。团队认为，这种开放协作，是不必逐行设卡也能维持质量的重要原因。

09 · 需要改变方向时怎么办

智能体降低了启动一项工作的成本，因此有些已经开始写的代码，最终并不应该合并。通常，频道里会有人追问目的、指出以前作过的决定，或建议更简单的路径。作者随后关闭 PR，或调整它的内容。

因为代码写得快，关闭 PR 也不会让人觉得损失很大。团队建议尽早在讨论中提出不同方向，不要等 PR 已经完成，再通过阻塞合并的评论提出。

10 · 其他团队如何采用这套流程

按作者的说法，搭建类似流程所需的大部分组件已经具备，可以从下面这些做法开始。

提交 PR 之前

• 给智能体提供它能运行的检查，并写进简短的 CLAUDE.md；再配上自动运行格式化工具和 lint 的钩子。
• 在本地运行 /code-review 和 /security-review，或让一个使用全新上下文的子智能体审查。
• 添加 REVIEW.md，把反复出现的审查意见沉淀进去。

每个 PR 都执行

• 将 CI 设为必过项，在 PR 模板中加入“测试方式”“风险”和“如何撤销”。
• 先在一个仓库接入 AI 审查器，例如 Code Review for Claude Code 或 Claude Code GitHub Action。用几周时间调整 REVIEW.md，再扩大使用范围。
• 增加自动安全审查，要求合并前解决所有审查讨论。
• 让审查投入匹配风险：常规改动快速检查；漏掉漏洞代价高的改动深入检查。Code Review 中对应 Quick、Standard、Deep 三档。
• 限制审查轮次；前几轮之后，只复审新增的 diff。

人工批准规则

• 写清风险等级，按变更内容划分，不按作者身份划分。先执行严格规则，再依据证据逐步放宽。
• 较宽松的审批路径只开放给信任的作者。
• 使用 CODEOWNERS 和分支保护，确保身份验证、计费、CI 与发布工作流，以及安装程序始终需要人工检查。CODEOWNERS 用来声明哪些人负责哪些文件或目录。
• 不让机器人的批准替代规则要求的人工批准；有新提交时，撤销旧批准。

合并及合并之后

• 使用合并队列、功能开关、内部先用、分阶段发布，以及一步回滚。
• 把事故和回滚沉淀为评测集。只要审查器的提示词、工具或模型发生变化，就重新评分。
• 衡量人的时间投入，同时用回滚率和事故率约束优化方向。

11 · 接下来会往哪里走

Code Review 的发布公告曾说明，是否批准 PR 仍由人决定；产品负责提出发现的问题，不会代替人给出批准。Anthropic 自己的仓库则走得更远：代码负责人可以决定，哪些低风险改动只依靠自动化检查就能合并。这个边界仍在调整。

如果审查漏掉了问题，团队会追问：模型当时缺少什么信息？随后，把相应改进写进 CLAUDE.md、某个技能，或一项新检查。目标始终是减少每次变更耗费的人工时间，同时不让回滚变多。

作者也邀请那些已经允许智能体提交 PR 的团队分享经验：哪些检查已经自动化，哪些还需要人，以及这套做法还有哪些不妥之处。

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

本文转载自微信公众号「AI灰鲸」，仅供学习交流使用。