克劳德（Claude）编写了克劳德代码（Claude Code）自身约90%的代码，团队如何在如此高的产出量下审查代码、还有没有人读代码、出问题谁发现？从6月到9月，合并到克劳德代码代码库的拉取请求（pull request）增加了一倍多，需要回滚的比例下降了超过40%。他们没有取消审查，而是把大部分阅读交给机器，按人类时间和注意力优化，并大力投入让撤销错误快速轻松。

我们之前说过，Claude 编写了 Claude Code 自身约 90% 的代码。那么，面对我们产出的这种规模，我们怎么做代码评审？现在还有人读代码吗？如果出了问题，又是谁发现的？

这篇文章讲的是 Claude Code 团队的代码评审流程，以及它如何演进。从 6 月到 9 月，合并到 Claude Code 代码库的 PR 数量翻了一倍多，而其中需要回滚的比例下降了超过 40%。

我们没有取消评审，而是把大部分阅读工作交给了机器，围绕人的时间和注意力做优化，并大量投入，让犯错后能快速、轻松地撤销。

重新思考代码评审的目的

当 agent 开始写代码，改动数量会迅速上升。在 Anthropic 的 monorepo 里，每天落地的改动从 5 月的约 2500 个，增加到今年 9 月的超过 30000 个。

Claude Code 独立于 monorepo，放在自己的仓库里，但也面临同样的压力。在这种发布速度下，靠人工逐行做代码评审就算不是不可能，也极其困难。

代码评审有两项职责：

1. 在改动发布前发现并修复问题
2. 在团队内建立共享上下文和对代码库的理解

这里我们主要关注发现和修复问题，但末尾会回到第二项职责。

我们认为，“有没有人读过这段代码？”并不能精确代表“这个改动可能出什么问题，以及哪种检查——自动还是人工——才适合发现它”。

换个问法也改变了评审发生的时机。以前，评审是路上的一道关卡：写完代码，开 PR，等同事看。现在，评审持续运行，更像是你写作时的拼写检查。在请人看之前，大多数改动已经被 Claude 评审并修过至少一次。这能抓住大部分常规错误，把团队的注意力留给更高层次的问题和审视。

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

我们希望把人的时间和注意力留给只有人能解决的问题，并确保其余问题由自动检查覆盖。以目前的改动速度，人依然有大量工作要做，团队几乎每天都会遇到全新挑战。

人的时间涉及评审成本的两面：花在评审上的时间，以及花在修复烂代码破坏的东西上的时间。如果只砍掉前者，而时间又在后者中冒出来，那并没有帮助。

所以我们的目标是：Claude Code 各仓库（CLI、桌面端和网页应用、移动端）里大多数 PR 最多只需要一个人在环中（可以是作者本人）就能合并，同时回滚和事故数量不增加。为了衡量人的时间，我们跟踪每个 PR 的人工批准数（中位数和 95 分位）、人工评论数，以及 PR 等人查看的时长。回滚率和事故率是护栏：如果它们上升，说明我们并没有节省人的时间，只是把时间挪了个地方。

一次改动的生命周期

一次典型改动，从工程师的笔记本（或 Slack 里的 Claude 会话）出发，会经过多层代码评审。

一次改动的生命周期

一次典型的 Claude Code 改动，从作者的机器到用户

图 A 大部分路径是自动化的；人的注意力投向风险所在。

逐层拆解

分层，而不是一道关卡

六层检查，下面还有回滚

图 B 每一层都会发现一些问题，也会漏掉一些。能穿透所有层的问题很少，剩下的交给回滚处理。

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 时，它会去找根因。公开版本——Claude Code 的代码评审功能——现在已在 Team 和 Enterprise 套餐正式可用，而 /code-review 会在本地跑一个更轻量的版本。

当我们发布研究预览时，内部 PR 收到实质性评审评论的比例从 16% 升到 54%。大多数超过 1000 行的 PR 都会有发现，而大多数小 PR 回来是干净的。管理员可以把每个仓库设为 Quick、Standard 或 Deep。在漏掉一个 bug 的代价高于额外评审时间的场景，Deep 是值得的。

在人评审之前，发现先由其他 agent 验证。 几个 agent 同时找 bug。然后另一组对每个发现投票，只有足够多 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. 按风险缩放的人工批准

改文档和改自动更新器风险不同，所以评审也不同。

| 风险 | 例子 | 人工批准 | | --- | --- | --- | | 低 | 文档、文案、仅内部功能、藏在 flag 后的新增改动 | 一旦自动评审和安全检查通过，不需要人批准 | | 中 | 普通产品改动，以及缓存、自动更新器或系统提示等敏感区域的改动 | 一个人 | | 高 | 最高风险代码，外加一小部分始终需要两个人的路径 | 两个人 |

风险等级由改动决定，而不是作者。 一个分类器读改动并选出它的风险等级。第二个分类器会问：即使等级说不需要，这个改动是否仍需要另一个人。有些路径始终需要人，还包括所有者列为敏感的任何东西，以及任何 CI workflow 文件。

更轻量的路径只给受信任的作者。 只有在仓库受信任名单上的作者（主要是拥有该仓库的团队）才能走更轻量的路径。其他所有人都需要第二个人批准。agent 的批准也永远不算人的批准。自动评审可以放行低风险改动，但不能填本该由人填的位子。

谁提出改动，谁就要对它负责。 在 agent 写的 PR 上，指挥 agent 的人算作所需的评审者之一，就像他们自己敲了代码一样。

一次批准只覆盖一个具体提交。 如果后来新提交是系统无法担保的，比如 agent 推的，或者有人手动解决的合并，批准就必须重新给。

6. 合并队列、flag 和渐进发布

合并队列会在把改动应用后，针对 main 重跑每一项检查，这样两个分别通过的 PR 也不会组合出坏掉的 main。新行为通常先藏在 flag 后面，只发给 Anthropic 员工，而我们大量的内部使用往往能在用户之前暴露回归。公开发布先到 latest 频道，stable 频道随后跟上。

7. 快速发现，快速回滚

有些错误还是会漏过去，所以最后一层是尽快抓住它们。flag 可以不用部署就关掉。Claude Code 有每周 on-call 轮值，事故复盘会问：这一层本该由哪一层抓到？

发现一个坏合并，仍然依赖作者和 on-call，以及回滚和事故仪表盘。我们还没有那种当这些数字变动时会自动收紧批准的断路器；这里的工程师希望在更多代码走向零人工合并之前先有这个东西。

一位同事说，放慢速度确实会降低错误率，但主要是因为你整体做得更少了。我们宁愿更快地发现和修复问题。

我们如何让评审者变得更好

我们的代码评审流程在循环里不断改进。

任何事故现在都是 eval。 团队收集了过去引发事故的 PR，连同它们的 forward-fix 和回滚，并让熟悉那段代码的工程师确认每个 bug 以及它所在的位置。评审者每天对着这个集合跑。

我们的事故就是 eval

由过去的事故和回滚构建，每天运行

图 C eval 随着每一起事故增长，评审者的每次改动都会对照整个 eval 打分。

我们通过观察人们怎么处理评论来衡量噪音。 如果你不介意标记一大堆非 bug，抓更多 bug 很容易，所以我们需要一个制衡。我们把评审者留下的每条评论，按 PR 上的人的反应分类：他们修了、说这是错的、说这是有意为之，或者觉得无所谓。我们还在已知干净的 PR 上跑评审者，统计它报告的东西会导致有人做出有害改动的频率。我们写下来的优先级是：先抓真 bug，其次减少评审轮次。

当作者是 agent 时，噪音代价更高。人几秒钟就能忽略一个 nit。agent 会去修它，这意味着又一次提交和又一轮评审。

评审必须收敛。 一个 agent 作者和一个 agent 评审者可以无限互相折腾下去。有一个 CLI PR 在一夜之间经历了五十多轮评审和修复，才被作者停下。

当我们对评审者反复标记的东西跑 git blame，大约 59% 是评审者第一轮就存在的代码。评审者很少找到新 bug，而是每轮再找出几个旧的。

这事我们自己搞砸过。我们习惯了默认跑好几轮，因为每一轮都能抓到新东西。这在有风险的改动上值得，但不该用在每个 PR 上。团队现在把“通过所需轮次”和召回率一起跟踪，并改了复审：

• 轮次上限。 三轮之后，评审者会请作者退一步，重新考虑方案。
• 只复审 diff，在头几轮之后。
• 标记 bug 的类别，让作者修掉每一个实例，而不是只修一行。
• 不重复已经贴过的发现。

评审 agent 还会每晚在现有代码上跑，帮我们在旧 bug 跑到别处之前先抓到它们。

评审收敛了

内部 PR，在收敛改动前后

图 D 收敛改动之后，每个内部 PR 的评审轮次减少了

人留在环中的位置

把一位资深工程师从深度工作中拉出来抓常规错误，代价远高于自动评审。在 Anthropic，我们的工作已经从读每一个 diff，转向机器不擅长的决定：

• 我们到底该不该做这个？ 方向、品味和范围。有一个团队宣布自己的评审瓶颈已解决，但仍为人保留了来自团队外部改动的人工评审，这样会有人问“我们真的该做这个吗？”
• 高风险代码，比如计费、自动更新器和 CI workflows。
• 架构，它会定下别人会复制的模式。
• 读证据。 测试输出、跑过的命令和它返回了什么、截图、评审者的发现。如果你说不出这些检查会漏掉什么，就要求一次真正的评审，而不是快速批准。
• 拥有结果。 每一个发布的改动，无论谁敲的代码，都有一个人负责。

人做决定的地方

五个决定留在人手里；检查跑在其他所有地方

图 E 人们从读每一个 diff，转向机器不擅长的决定

在团队内共享上下文

代码评审的第二项职责一直是传播对代码库的理解。读队友的 diff 是你了解改了什么、各部分如何咬合的方式。如果机器做了大部分阅读，人还怎么学代码？

我们对此没有正式流程。团队里没人脑子里装着 Claude Code 的完整心智模型，我们也不认为有人需要这样。当有人想理解代码库的某一部分时，他们会让 Claude 就那一部分写一份解释。这只要几分钟，而且反映代码今天的样子。

我们中有些人更进一步，让 Claude 构建一个小制品，把那部分代码可视化，并按那个人喜欢的方式来教。

如果目标是花好人的注意力，这比逐行读琐碎 diff 强。一行文案改动几乎教不了你什么。正要改动的模块的解释能教你很多。我们默认在开放 Slack 频道里工作的文化也有帮助，因为你在别人构建时就能看到他们在构建什么。

“你落地，你负责”

如果你落地一个中小型改动，结果还是出了问题，通常你来修，这是一条团队规范。有几件事让这不至于变糟：

• 改动很小，所以容易评审、调试和回滚。
• 一切可逆。 flag、回滚和分阶段发布能在几分钟内撤销大多数错误。
• 爆炸半径决定门槛。 昂贵的改动需要更多人和更多检查。
• 回归通过遥测和内部使用快速浮现。
• 这不是追责。 拥有修复意味着你上下文最多；事故复盘看的是系统。

ownership 也是共享的。团队很多人在开放频道里工作，任何人都能看到别人在构建什么，接手一条线索，或者把 Claude 指向一个缺口，反馈也来自不拥有那段代码的人。这种开放性，是质量不需要每行都设关卡也能保持高水准的重要原因。

我们何时改变方向

agent 让启动事情变得便宜，所以有些工作不该落地。通常频道里有人会问为什么，指出更早的一个决定，或者建议一条更简单的路，作者就会关掉或重塑 PR。

因为代码写起来快，关掉 PR 并不让人觉得是损失。诀窍是在讨论串里尽早提出不同方向，而不是等 PR 完成后再作为阻断性评论提出来。

你如何采用这套流程

和你的团队一起做这件事所需的大部分组件，现在已经有了。

在 PR 之前

• 给你的 agent 它能跑的检查，写在一个简短的 CLAUDE.md 里，再加上跑格式化和 lint 的 hooks。
• 本地跑 /code-review 和 /security-review，或者让一个全新上下文的子 agent 来评审。
• 加一个 REVIEW.md，并把重复的评审评论挪进去。

在每个 PR 上

• 要求 CI，并在 PR 模板里加上“测试”、“风险”和“如何回滚”。
• 加一个 AI 评审者（Claude Code 的代码评审功能，或 Claude Code GitHub Action），先在一个仓库上试用，调几周 REVIEW.md，再推广。
• 加自动安全评审，并要求合并前解决每一个评审讨论串。
• 让评审力度匹配风险：常规改动快速过，漏掉 bug 很贵的地方就深挖（代码评审里的 Quick、Standard 或 Deep）。
• 给评审轮次设上限；头几轮之后，只复审新的 diff。

批准

• 把风险等级写下来，由改动决定而不是作者；开始严格些，有了证据再放松。
• 更轻量的批准路径只留给你信任的作者。
• 用 CODEOWNERS 和分支保护，让 auth、计费、CI 和发布 workflow，以及安装程序始终需要人。
• 绝不让 bot 的批准替代所需的人工批准；在新提交上驳回批准。

合并及之后

• 使用合并队列、feature flag、先内部使用、分阶段发布和一步回滚。
• 把事故和回滚变成 eval 集，并在评审者的 prompt、工具或模型变化时重新打分。
• 衡量人的时间，以回滚率和事故率作为护栏。

它要去向何方

代码评审的公告说过，批准 PR 仍然由人来做；产品贴的是发现，不是批准。我们自己的仓库走得更远，让所有者决定哪些低风险改动可以仅凭自动检查合并，而且这条线还在移动。

当评审漏掉什么时，我们会问模型面前缺了什么，并把修复放进 CLAUDE.md、一个 skill 或一项新检查。目标没变：每个改动花更少的人力时间，回滚不比从前多。

如果你的团队让 agent 开 PR，我们想知道你们自动化了哪些检查，哪些仍然需要人，以及你们觉得我们哪里错了。

多数人对文中“人工智能编写九成代码、每日合并三万次改动且低风险改动无需人工评审”的叙述强烈怀疑，争论主轴集中在质量回归、安全评审可靠性与指标是否失真。少数人则认可“自动评审＋特性开关＋人工批准发布”的模型，并补充了代理评审、意图校准与功能监控的实践经验。

怀疑“九成代码由 Claude 编写”“每日三万次改动”等说法本身

• 不少人对“Claude 编写 90% 代码”和每日合并三万次改动感到震惊或难以置信，质疑这是里程碑叙事疲劳、进入平台期，或根本不可能；有人翻出半年前推特称已达 100%，也有人反问一个终端界面是否真需要如此海量的拉取请求。（较多人） > 我有点意外他们到现在会说 Claude 写了九成代码，是懒得再报新里程碑，还是已经到平台期了？（@hyperpape）

质疑高强度自动化正在牺牲代码质量与产品体验

• 相似意见指出，仓库里约三分之一是既往行为的随机回归，命令行工具每次更新都带来新缺陷，桌面端界面按钮位置频繁乱变，滚动、思维链/命令展示、插件配置等卡顿问题长期未修；有人直接反问每天三万次提交还能不能叫评审。（较多人） > 这解释了那个有五千个问题的 GitHub 仓库，其中约三分之一是既往行为的随机回归。（@crooked-v）

认为人工评审与人类上下文理解不可替代

• 手动逐行评审仍能发现冗余、重复与过度复杂架构；让模型写解读并不能让人自信评估复杂差异改动，而且对改动含义的先验又被同一个已批准它的系统循环过滤，评审因此丧失独立性。文章被批评没有足够重视“人通过亲手熟悉代码建立心智模型”这一环，所谓“系统验证自身”其实更像搜索，搜索质量只决定临时调出的知识，而非真正建立系统整体心智模型。（较多人） > 让模型写解读并不能让你自信评估复杂差异改动，而且你对改动含义的先验，又通过同一个已评审并批准它的系统循环了一遍。（@RGS1811）

反对让模型写文档与低风险改动完全免人工评审

• 文档、文案、内部功能、带开关的增量改动在自动检查变绿后竟无需人工评审，让大语言模型写文档却没人读被认为是疯狂的；有人问测试质量如何在如此频繁提交下维持，得到的回答是“很糟，命令行工具每次更新都带新缺陷”。（较多人） > 让大语言模型写文档却连读都不读，怎么能有人接受？这纯属疯狂。（@koolba）

认为自动安全评审可能被误用，且未防提示注入

• 安全发现若被随意标为误报而关闭，可能一边降低回滚率一边引入更多漏洞；关键发现不应绕过应用安全人员。更关键的是，配套的 claude-code-security-review 自述“未针对提示注入攻击加固”，对人工智能安全评审控制来说是重大局限。（少数人） > 希望只有低风险误报能这样关闭，关键发现被当作误报绕过应用安全团队，就可能在改善回滚率的同时引入更多漏洞；而该动作自述未防提示注入，是重大局限。（@vavkamil）

批评用“回滚/事故数”当目标是在玩弄指标，而非保证质量

• 文章把目标定为“更少人工时间、且回滚不多于以往”，于是有人指出这像古德哈特定律：一旦把回滚和事故少当成指标去优化，它就未必再是质量的代理指标；真正直接的度量可能是收入，但外界看不到。（少数人） > 把“回滚更少、事故更少”从测量结果变成优化目标，这难道不是古德哈特定律吗？它还能算是好指标吗？（@ativzzz）

批评这是不计成本地消耗词元，而非可持续工程

• 有人称 Anthropic 解决一切问题的方法就是消耗更多词元，文章应该从需要考虑模型调用成本的人视角重写；也有人调侃该去投资他们烧词元所用的云，反映出社区对成本与词元消耗的强烈印象。（较多人） > 这家严重亏损的人工智能公司就这样讲它如何把代码和评审流程的词元消耗拉满，作者真该从要考虑模型使用成本的人的角度看看。（@YmFzZTY0ZGFkZHk）

认可“自动评审＋特性开关＋人工发布把关”的流程

• 有读者总结文中的模式其实是：一切改动都经自动评审并以特性开关隐藏，最终发布仍需人工批准，认为这是个好模型；也有人觉得文章很有帮助，并已把担心从“代码是否正确”转向“如何识别功能与监控功能”。（较多人） > 一切都通过自动评审并放在特性开关后发布，然后需要人工批准才能上线，这是个好模型。（@foolfoolz）

有价值的补充

• 实践者分享了自己的代理评审公式：先写测试、日志并与运行中的应用交互以确保代码符合意图；让智能体重读项目里的全部用户消息来重新推导意图，即便上万条消息也只要几分钟；用常驻项目的任务清单文档记录反馈，并在实施前后各评审一次，总体是“评审智能体＋测试＋用户消息日志”。（@visarga）
• 有读者用 Pangram 检测发现文章多个段落被判定为 100% 人工智能撰写；也有人从行文风格推测，所谓“Anthropic 员工禁止用人工智能写对外沟通”的规则看来并不成立。（@typesanitizer、@mk12）
• 关于自动化代码评审的落地选型：有人询问大家现在用什么自动代码评审工具，提到 Claude Code 评审曾标价每次 15–25 美元，被吐槽离谱且文档中已删去，并比较 CodeRabbit、Greptile 等后仍各有不满，倾向用 GitHub 网络钩子自建智能体触发代码评审命令。（@rileymichael）
• 功能监控的新问题：当代码缺陷不再是主要痛点后，有读者用智能体检查录屏来监控新功能，提出真正好功能仍需 20–30 次迭代来设计用户流，难题转向如何把使用模式翻译成功能、并以最低摩擦呈现，同时希望有高效运行监控器而不浪费词元的最佳实践。（@jwpapi）