Anthropic 的代码审查跑到五十多轮还没过：AI 审 AI 会自己卡住

一句话定位：这不是"AI 审得好不好"，而是"两个 Agent 互相审，会不会把对方拖死"——被测对象是审查循环能不能收敛，不是某条意见对不对。同样的收敛规则可迁移到自动修复循环、告警去重、多轮评审、机器人客服转人工等任何"自动化会自己叫停自己"的场景。

摘要

Anthropic 的 Claude Code 团队在 2026 年 10 月 15 日公开了他们的代码审查流程：六层关卡，按风险分档决定要不要人批，低风险改动通过自动审查后可以免人审。同时公开了一个反面案例——一个 PR 在一夜之间经历了五十多轮审查和修复，作者手动叫停。这篇讲的是 AI 审查自身会失效在哪里，以及四条收敛规则为什么能解决它。

一个命令行工具的 PR，一夜之间走过了五十多轮审查和修复，最后是作者自己手动停下来的。

这不是审查不严格，是审查太严格而且不会累。Anthropic 的 Claude Code 团队在 2026 年 10 月 15 日的工程博客里写下了这件事，作者是 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang。同一篇文章的核心判断是：到了这个代码量级，逐行人工审查已经不现实，但审查不能取消，只能改变由谁来做、按什么顺序做。

如果你在搭建研发流程里的质量门禁，这篇要解决的问题很具体：当审查的执行者从人变成 Agent，失效模式也换了。 人审的典型失效是漏看，Agent 审的典型失效是不停地看。两种失效需要的门禁设计完全不同。

六层关卡，前三层都在人看到之前

官方把一次改动的路径拆成六层，我把它们按"人是否介入"重新排了一下，差别比原图的顺序更直观。

第一层在 PR 创建之前。Claude 跑测试、完成构建，涉及界面的改动还要截图对照设计稿；然后派一个使用全新上下文的子智能体审查 diff，它没参与写代码。原文对这一步的要求很硬：要让 Claude 把执行的命令和输出摆出来，光回复一句"测试全部通过"不算数。

这一层最值得抄的不是"用子智能体复查"，而是"要求出示证据"。同一件事，让 Agent 说"我测过了"和让它贴上命令与输出，是两种完全不同的可信度。前者是自我报告，后者是可复核记录。原文在另一处也强调了这个逻辑：给 Claude 一个能验证自己的办法。

第二层是 PR 上的 AI 审查。多个 Agent 并行找 bug，另一组对每个发现投票，票数够了才贴到 PR 上；只涉及代码风格、诊断信息或清理的意见直接过滤掉。原文给出的效果数据是：这套审查上线研究预览时，获得实质性审查评论的内部 PR 占比从 16% 升到 54%。

这个数字经常被误读成"bug 发现率提高了 38 个百分点"。它其实衡量的是评论覆盖率——原来很多 PR 根本没拿到有实质内容的评审意见，现在拿到了。评论变多既可能意味着覆盖更全面，也可能意味着噪声更多，原文没有给后续的采纳率或误报率。

第三层是安全审查，单独一遍。原文的规则是：只要 bug 审查或安全审查留下的发现没关闭，PR 就合不进去，要么修掉，要么写明理由关掉线程（这也是清除误报的方式）。

第四层是常规 CI：lint、类型检查、各平台测试、构建。原文提到一个细节很有画面感：一个普通的命令行改动，在任何一个人看它之前，可能就要跑几十项检查。

到这里为止，人还没出现。这四层的共同点是：它们都是可以自动判定的。能自动判定的东西没有必要让人来看，这句话说起来简单，但很多团队的门禁恰恰是把可自动判定的检查排在了人工评审之后，白白消耗评审者的注意力。

第五层：改动本身决定要几个人批

这是全篇设计上最值得细看的一层。原文的三条规则是：

改动的风险定档，不是作者的名气定档。 一个分类器读改动并给出风险档，第二个分类器再判断即使档位不需要人，这次改动是否仍需要额外一个人批。

只有可信作者能走轻通道。 原文的表述是，只有仓库可信名单上的作者能走较轻的路径；Agent 的批准永远不能算作人的批准；自动审查可以放行低风险改动，但填不上需要人的那个名额。

提需求的人对改动负责。 在 Agent 写的 PR 上，指挥 Agent 干活的人本身就算一名必须的审查者。

第三点是我认为最该被抄进流程的一条。它解决的是一个很实际的空转问题：Agent 写的代码，如果责任落在"Agent"这个并不存在的责任人身上，那出了事就没有人复盘，也没有人从错误里学到东西。把责任绑到"下指令的人"身上，这个闭环才成立。

原文还给了两个容易被忽略的约束：审批只覆盖一个具体的提交，如果有系统无法为其担保的新提交进来，审批必须重新给出；有些路径永远需要人，包括代码所有者标记为敏感的路径，以及所有 CI 工作流文件。

第二条约束的道理很清楚。CI 工作流文件能改构建和测试的行为，如果让它走自动审批，等于把门禁本身的钥匙交给了被门禁检查的对象。

为什么审查会自己卡住：噪声的成本结构变了

回到那个五十多轮的 PR。原文的分析很直接：人和 Agent 之间，噪声的成本不一样。原文的表述是，当作者是 Agent 时，噪声代价更高——人可以一秒钟忽略一个小毛病，而 Agent 会老老实实去修，于是又一个提交、又一轮审查。

这句话里藏着一条容易被忽略的经济学。同一条无关紧要的意见，对人是零成本（忽略），对 Agent 是正成本（修复 + 重新触发全部门禁 + 产生新 diff + 引入新风险）。审查轮次越多，这个成本被放大得越厉害。

团队用 git blame 回查了审查器反复标记的内容，发现约 59% 是审查器第一轮就已经存在的老代码。原文的结论很干脆：审查器很少在找新 bug，它只是在每一轮多挖出几个旧问题。

这条发现值得记住，因为它推翻了"多审几轮总能多发现问题"的直觉。在增量改动上，多轮审查的边际收益会迅速下降；而被反复触发的旧问题会把评审注意力全部吃掉。

四条收敛规则就是针对这个结构设计的：三轮之后，审查器提示作者退一步重新考虑方案；前几轮之后只审新增改动；标出缺陷的类别，让作者一次修完同类问题而不是修一行；已经提过的问题不再重复。

这四条里，我认为最有效的是第二条和第四条。只审增量把审查范围收窄到"这次改了什么"，不提重复意见把噪声直接归零。第一条是保底：三轮不过，说明方案本身有问题，继续修下去只是把错误修得更精致。

一条被误传的数字，和它背后的教训

写这篇之前我核对过一个流传很广的数据：很多转述说收敛规则上线后，一轮审查通过的占比从 65% 升到 78%，需要五轮以上的从 8.9% 降到 1.5%，平均审查次数从 2.08 降到 1.32。

这三个数字在官方原文里找不到。原文对应的图只有一句说明：收敛改动之后，每个内部 PR 的审查轮次减少了，没有给出具体数值。

我不能确认那组数字的真实来源，所以这篇里没有采用。这件事本身是个提醒：AI 质量相关的数据在传播过程中会被具体化。 一个"减少了"的描述，经过几次转述会变成三个精确到小数点后两位的数字，而且读起来毫无破绽。做质量报告的人对此应该格外警惕——你引用别人报告里的数字时，最好回到原始出处看一眼它到底写了什么。

兜底：官方自己承认的那个反例

原文没有把六层关卡说成万无一失。它引了一个自家的反例：2026 年 3 月 26 日上线的一项优化，本意是会话闲置超过一小时后清理一次旧的推理记录；一个 bug 让它在恢复对话后的每一轮都在清理。结果是模型变得健忘、开始重复、使用工具出现反常，直到 4 月 10 日才修复。

官方的复盘承认，这个改动穿过了多轮人工和自动审查，单元测试、端到端测试、内部试用都没有拦住。

这组事实对做门禁的人最有价值。它说明多层的自动检查有一个共同盲区：它们检查的是"这次改动是否符合预期"，而不是"运行一段时间之后行为是否符合预期"。前者是静态判定，后者需要长时间的行为观测。清理逻辑每轮都执行，每一轮单独看都无误，只有把连续几轮连起来看才暴露。

所以我在任何门禁方案里都会加一条时间维度的检查：关键功能在长会话、多轮交互下跑一段固定的时间步，比对行为指标（重复率、工具调用模式、上下文召回）随轮次的漂移。这条不是 CI 能做的，需要独立的监控任务。

原文也写了尚未完成的部分：目前还没有在指标恶化时自动收紧审批的熔断机制，工程师希望先补上这道保险，再让更多改动走零人审批。这句话的分量不轻——他们在扩大自动化范围之前，先承认闸门还差一道。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。