先看证据
评审不再只发生在合并之前
Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 在 Anthropic 的文章《Claude Code 团队如何进行代码评审》中，介绍了 Claude Code 团队应对代理带来提交量增长的一套评审流程。它面向的不是“怎样让每个 PR 都多一个读者”，而是怎样在改动快速增加时，仍能发现问题并把人工检查留给需要判断的地方。
这一区别改变了评审在开发中的位置。传统流程常把评审放在末尾：代码写完、PR 打开，然后等同事逐行查看；Anthropic 描述的做法则让 Claude 在开发过程中反复检查和修正，多数改动在请求人工查看前已经过至少一轮代理评审。评审由一道合并前的关卡，变成开发中的持续检查。
先问风险，再决定谁来检查
这套流程的核心问题不是“有没有人读过代码”，而是“改动可能出什么问题，哪种检查最适合发现它”。开发者先给 Claude 可执行的验证手段，例如测试、构建或界面截图，再让处于不同上下文的子代理检查代码差异。团队还使用查错、精简改动和端到端检查等内部技能，并把反复出现的评审意见写入项目指引或规则。
PR 阶段也不是把差异交给一个代理，然后照单全收。Claude 会结合整个代码库和 PR 意图检查改动，由多个代理寻找问题，再由另一组代理判断发现是否成立；风格意见和一般清理建议会被筛掉，保留下来的发现按严重程度呈现。团队要求发现项得到修复或由作者说明理由后才能关闭，这让评审结果不只是评论列表，也成为需要回应的控制点。
吞吐量的增长，不能直接证明因果
Anthropic 报告的数字说明了流程面对的规模变化：其单体仓库每日落地改动从 2026 年 5 月约 2,500 条，增至 9 月超过 30,000 条。Claude Code 仓库在 2026 年 6 月至 9 月合并的 PR 数量增加一倍以上；同期，需要回滚的 PR 占比下降超过 40%。团队还称，内部 PR 获得“实质性评审意见”的比例，在功能研究预览推出后从 16% 升至 54%。
这些指标提供了值得追问的信号，却不是一组完整的因果证明。文章没有给出“实质性意见”的计算口径或样本规模，也没有提供 PR 风险构成、回滚绝对数量或独立审计结果；回滚占比下降因此不能单独归因于评审流程。文章另称，多数超过 1,000 行的 PR 会收到发现项，多数小型 PR 则没有，但没有披露具体比例。约 59% 的评审意见指向首次检查时已经存在的代码，这提醒团队：代理发现的问题不一定由这次改动引入。
机器筛错不等于机器承担责任
自动评审处理常规问题，并不意味着人工审批可以一并取消。Anthropic 描述的把关方式会按改动风险分层：低风险改动在自动检查通过后可以不要求人工审批，中风险通常需要一人，高风险通常需要两人；独立安全审查，以及 lint、类型检查、测试和构建仍在流程之中。代理的审批不能代替规定的人类审批。
人工职责也不只是给机器的结论盖章。作者将方向与范围、敏感代码、架构模式、验证证据和最终上线责任留给人类判断。代码评审同时承担团队理解代码库的作用，这一功能不会因为常规错误被自动发现而自然保留下来。让 Claude 按需解释模块可以补充理解，但材料没有证明它能替代同伴评审带来的共同认知。
把评审代理当作控制面，而非裁判
Anthropic 还把评审流程本身纳入改进循环：团队将过去导致事故的 PR、后续修复和回滚整理成评测集，定期测试评审器，并跟踪意见是被修复、被判定不成立，还是被认为无关。反复出现的问题可以沉淀为规则；评审意见也需要被检查，而不应仅因来自代理就自动获得权威性。
团队曾遇到一个 CLI PR 一夜经历超过 50 轮评审与修复的情况，因此把三轮设为上限，超过后要求作者重新考虑方案。这个细节揭示了自动化的另一种成本：评审器和作者可能陷入反复循环，更多轮次不必然带来更可靠的结果。对高提交量团队，可借鉴的是先提供可执行的验证证据，再按风险决定人工审批，并用事故案例建立可回归的评测；不能直接照搬的是 Anthropic 的效果数字或审批阈值。最终判断仍应看本团队是否能证明检查有效、发现可追溯，而且责任没有被“代理看过”这句话稀释。