PR 翻倍、回退下降 40%：Claude Code 团队怎么审代码

团队开始让 Agent 写代码之后，最先失去弹性的，往往不是生成环节，而是 PR 审查。

代码一下子多了，reviewer 还是那几个人。于是大家很容易回到一种熟悉但无效的姿势：盯着 diff，一行一行往下翻，试图用更多人工阅读把风险压住。可当改动的数量先翻倍，人的注意力不会跟着扩容。它只会更快被耗在格式、命名和已经被测试覆盖的小问题上。

Anthropic 刚公开了 Claude Code 团队自己的做法。官方说，Claude 已经编写了 Claude Code 自身约 90％ 的代码；从 6 月到 9 月，团队合并的 PR 数量增长超过一倍，需要回退的比例下降超过 40％。这个数字来自他们的生产流程，不是某个演示里的漂亮截图。官方原文在这里。

我更在意的不是「他们用了多少 Agent」，而是他们把代码审查的问题改写了：不再问「这段代码有没有被人看过」，而是问「这次改动可能坏在哪里，哪个检查最适合抓住它」。

这两个问法，听着只差一点，团队的工作分配会完全不一样。

审查不该只发生在 PR 的末端

传统流程把 code review 放在终点：写完，开 PR，等同事腾出时间，逐行找问题。Agent 参与开发后，这个终点会越来越拥堵。

Claude Code 团队把审查往前挪了。PR 还没创建之前，作者就要让 Agent 跑测试、构建，或拿截图对照设计；不是写一句「已经完成」，而是把运行结果交出来。随后再让一个带着新上下文的 Agent 看 diff，避免同一个对话一直替自己背书。

这其实是在给「完成」加一个很朴素的定义：能复现、能检查、能看见证据。测试、构建、lint、类型检查和跨平台验证都应该是合并前的常规层，而不是 reviewer 临时想起来才补的作业。

团队的完整流程还把代码审查、安全审查、CI、合并队列、feature flag 和回退连在一起。前面的检查负责尽早发现问题，后面的发布与回退负责承认问题总会漏过。质量不是一扇门，是几层不同用途的网。

图：本文根据 Anthropic 公开流程绘制。自动检查尽量覆盖重复工作；人只在风险分流点做决定。

先让机器读，再决定谁必须读

这里最容易被误解成「以后不用人 review 了」。官方的做法恰好相反：低风险改动可以放轻，风险越高，人越不能缺席。

他们把批准层级按改动划分，而不是按作者划分。文档、文案、内部功能或受 flag 保护的增量改动，自动检查和安全检查都通过后，可以走更轻的路径。一般产品改动，以及缓存、自动更新器、系统提示词这类敏感区域，需要一个人批准。账单、CI 工作流和少数高风险路径，则要求两个人。

这里有两个很值得抄下来的边界。

第一，Agent 的「批准」不能填补本来要求人类批准的位置。Agent 可以找问题、复核发现、给出测试证据；对是否接受风险这件事，签字的人仍然得是人。

第二，谁让 Agent 做出这次改动，谁就不能把责任交给生成工具。Anthropic 的规则是，指挥 Agent 产出代码的人，和亲手写代码的作者一样，要对结果负责。这个约束很重要。否则团队会收获一堆「代码不是我写的」的 PR，而没人真的拥有上线后的后果。

如果你们已经在 GitHub PR 上接了自动 reviewer，先别急着给每个仓库都开最高档。更稳的起步是挑一个可控仓库，在模板里固定写三件事：测试跑了什么、风险在哪里、坏了怎么撤。然后让规则按风险逐步加重，而不是把每个改动都塞进同一条慢队列。

Agent 和 Agent 也会互相消耗

人类 reviewer 看到一条无关紧要的评论，通常几秒钟就能判断跳过。Agent 不会。它会修，推一个新 commit，再触发一轮检查。审查者又会对新的 diff 继续挑问题。两个勤奋的系统凑在一起，能把一个小改动做成永动机。

Anthropic 在内部就碰到过这样的情况：一条 CLI PR 一夜间经历了 50 多轮审查和修复。回头用 git blame 看，审查器反复标出的内容里，约 59％ 在第一次审查时已经存在。它不是持续发现新 bug，而是在不同轮次里不断重新发现旧问题。

他们后来给流程加了收敛条件：三轮后要求作者退一步重看方案；前几轮后只复审新增 diff；指出一类缺陷时要求一次改完，不要只修评论落点那一行；已经发布过的发现不再重复贴出。

图：官方公开数据。调整后，一轮审查加修复就通过的比例从 65％ 升至 78％；需要五轮或以上的比例从 8.9％ 降至 1.5％。平均通过轮数也从 2.08 降到 1.32。

这个细节很有意思。很多团队评估自动审查时，只会问「它抓到了多少问题」。但抓得越多不一定越好。误报、重复发现和没有边界的复审，都会把作者和 reviewer 推进更多循环。

更接近生产现实的指标，应该同时看三件事：真实缺陷是否被发现、人工等待是否减少、回退和事故有没有变多。少一个都不完整。只看前两项，容易把风险藏到上线后；只看事故指标，又很难知道流程究竟是在帮忙，还是单纯让大家变慢。

人的时间应该留给五种判断

当机器已经能稳定读取大量 diff，人不会突然变得没用。只是人最稀缺的能力，不该继续浪费在扫描一行复制粘贴的改动上。

Anthropic 把人保留在五个地方：这件事是否值得做；高风险代码；会成为团队新范式的架构；测试输出、命令结果、截图和审查结论是否真的说明问题；以及对上线结果负责。

其中最不容易自动化的一项，可能是第一项：这件事到底要不要做。Agent 让开启一个方向变得很便宜，也让一个并不值得的方向更容易被快速做完整。好的 reviewer 不是等到 PR 写完才说「这里有问题」，而是在事情还没滚大时问一句：目标是什么，为什么要这样做，有没有更小的路径。

另一个容易被忽略的是架构。局部实现是否通过测试，机器可以做得越来越好；但一个抽象会不会变成未来几十个模块都要复制的模式，需要结合产品方向、团队维护能力和历史包袱来判断。这类判断没有必要装作可以一次性自动化。把它明确留给人，反而让自动化更可信。

不读每个 diff，不等于放弃理解代码

代码审查还有一层老价值：让团队成员知道系统正在怎么变。过去大家靠读同事的 PR 获得这份上下文。可在海量微小改动里，逐行阅读既慢，也未必真的教会你关键模块。

Claude Code 团队的选择是按需请求解释：当你要改某个模块时，让 Agent 围绕那一块生成解释或可视化。它不保证每个人脑中都有一份完整代码库地图，但能让需要做决定的人快速得到当前代码的局部模型。

这比「所有人都读完所有人提交的 diff」诚实得多。前者承认注意力有限，并把注意力投到将要发生的改动上；后者看起来严谨，常常只剩一串匆忙点下的 approve。

可以从一个小仓库开始

这套流程不适合一夜搬进所有仓库。Anthropic 的规模、工具和事故数据都不是每个团队马上具备的条件。真正能直接带走的，是它的顺序。

先给 Agent 可运行的验证手段，把项目约束写进短小的 CLAUDE.md，把反复出现的 review 评论沉淀进 REVIEW.md。再选一个仓库接入自动审查，观察几周：它究竟抓到了哪些真实问题，哪些评论被证明无用，哪些改动最容易进入反复修复。

等这些数据出来，再谈放宽低风险路径。高风险目录继续用 CODEOWNERS、分支保护和人工批准守住；发布侧保留合并队列、灰度、监控和一键回退。出了事故也别只把它当作一次复盘，把案例加入评测集，下一次审查器改提示词、工具或模型时都重新跑一遍。Claude Code 的公开代码审查文档和自动化安全审查说明已经把不少接入动作写得很清楚。

AI 写代码不是把 review 删除键按下去。它更像逼团队终于把一件老问题说清楚：哪些检查可以交给机器，哪些决定必须由人承担，以及当两者都出错时，谁能最快把系统拉回来。

你们团队的 PR 审查里，最耗人、却最难被自动检查替代的那一步是什么？