代码写得越快，审查越要重新设计：Anthropic 的实践与启示#

AI 编程让一个问题变得越来越具体：如果代码的产量增长了一个数量级，团队还要为每一处改动安排同样多的人工阅读吗？

真正难的不是给代码增加一道审批，而是解释清楚：这次改动有哪些风险，什么证据能支持上线，出了问题谁来处理。

Anthropic 的 Claude Code 团队最近分享了一篇文章，讨论他们如何应对这个变化。本文是基于原文的中文解读，先概述其中的关键观察，再给出面向工程团队的分析与建议；并非全文逐句翻译。

原文提供了什么信息

2026 年 10 月 15 日，Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 发表了 《How the Claude Code team does code review》。文中报告：6 月至 9 月，Claude Code 代码库合并的 PR 数量增长超过一倍，需要回滚的占比下降超过 40%。这些是团队自身的观察，不能据此断言某项措施单独带来了结果。

他们把大量代码阅读交给自动化，让人工介入随风险调整，并用回滚和事故情况约束效率目标。另一条经验是让 AI 审查及时收敛，避免作者与审查者反复修改、迟迟无法结束。上线后，改动依然有明确的人类责任人。

这组实践值得讨论的地方，是它把审查放回了完整的交付系统中。下面是由此展开的分析与落地建议。

1. 先把“审查通过”变成一个能解释的结论#

很多团队的 PR 页面里都有一个绿色勾选，但勾选背后的含义并不一致：有人核对了业务逻辑，有人只看了代码风格，有人确认测试通过，也有人只是相信作者。

当改动数量增长，这种含糊会放大。团队需要能回答三个具体问题：

• 这次改动希望改变什么行为？
• 哪些证据说明它实现了目标？
• 哪些重要风险仍然没有被验证？

例如，“修复重复扣款”不能只靠一个函数的单元测试。它至少涉及重试、并发、幂等和外部支付结果的处理。审查者首先需要知道验证覆盖了哪些情形，才能判断还应该看什么。

一个实用的改进，是要求 PR 用几句话写清行为变化，并附上与之对应的验证结果。这样，阅读代码有了问题导向，批准也有了可追溯的依据。

2. 用两条轴判断风险：影响范围与恢复难度#

下面这个矩阵是本文的建议，可以用来讨论人工审查投入。

这里最容易被忽略的是数据变化。代码可以回滚，已经发送的通知、已经扣除的款项、已经覆盖的用户数据，却未必能跟着恢复。

因此，“有回滚按钮”只是起点。评审还要区分代码恢复、配置恢复和业务补偿。三者的成本可能相差很大。

3. 让 AI 提供可以核验的问题#

AI 审查的价值取决于它提出的问题能否帮助人做决定。

“这里可能有并发问题”很难直接处理。更有用的反馈应该包含触发条件、执行路径和后果，例如：

两个请求同时读取到相同余额后，都可能通过余额检查；后续写入没有原子约束，因此存在重复消费的可能。建议检查并发请求下的实际结果。

这是一个用于说明反馈质量的假设案例，并非原文中的事故。

团队可以要求审查反馈回答四件事：问题发生在哪里，什么输入或时序会触发，为什么现有保护不足，怎样验证判断。对于无法提供这些信息的评论，可以先补充证据，再决定是否修改。

这样做也能减少无效劳动。模糊的建议容易引出大范围重构，明确的故障条件更容易导向小而准确的修复。

4. 给反复审查设置“继续的理由”#

自动化降低了发起下一轮审查的成本，却没有让下一轮变得免费。每次修改都会带来新的差异、验证成本和理解负担。

一个可操作的规则是：每次追加审查，都写清它要解决的未决问题。

如果修复了一个边界条件，下一轮就验证这个边界条件及其影响。如果出现了新的失败证据，再扩大检查范围。如果只是偏好发生变化，则应先判断它是否值得阻塞当前交付。

对于长期无法收敛的 PR，也可以暂时停止局部打补丁，重新检查需求是否混合了多个目标、改动是否过大、测试是否无法表达预期行为。

审查完成需要一个标准：关键问题已经得到回答，剩余风险有人理解并承担。单纯增加轮数无法替代这个标准。

5. 衡量效率时，把修复成本一起算进去#

只看“从创建 PR 到合并用了多久”，很容易奖励仓促上线。

可以把一次改动消耗的人力粗略记为：

总人力投入 = 审查时间 + 等待与沟通时间 + 上线后排障与修复时间

这个表达式是一个管理视角，并不是精确的财务模型。它提醒团队：节省下来的阅读时间，如果又花在事故排查里，收益可能只是表面上的。

实践中，可以同时记录人工投入、上线后的修复工作，以及用户受到的影响。再按改动类型观察，而不是把文案修改和支付逻辑混在同一个平均数里。

小样本尤其需要谨慎。一周没有事故，不足以证明流程已经成熟；一次严重事故，也值得检查是否暴露了某类系统性盲区。

6. 从一个边界清晰的试点开始#

如果想调整现有评审方式，可以先选择一个业务边界清楚、验证条件较好的模块。

第一步，回看这个模块近期出现过的真实缺陷，识别反复发生的问题。第二步，把这些问题变成可执行的检查，或证据要求明确的审查问题。第三步，记录试点前后人工投入与上线质量，再决定是否扩大范围。

试点还应该提前写下停止条件。例如出现特定严重程度的缺陷，或者连续多次遗漏同一类问题，就恢复更严格的人工介入，并修正检查方式。

同时，为每次改动指定能解释需求、理解风险并协调修复的人。AI 可以承担越来越多的实现和检查工作，团队依然需要知道：当判断出错时，由谁把事情处理好。

原文：How the Claude Code team does code review，作者 Addy Osmani、Morgan Westlee Lunt、Qing Wang，发表于 2026 年 10 月 15 日。本文的风险矩阵、示例和试点建议为延伸分析，不代表 Anthropic 官方流程或承诺。