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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/8ef079407d76d53288a3ca862bcb21af.png)


## 摘要

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

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

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

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

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/b746481ab48e2874ea4cb1bbb21c5a65.png)


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

第一层在 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 工作流文件能改构建和测试的行为，如果让它走自动审批，等于把门禁本身的钥匙交给了被门禁检查的对象。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/5db13d1dce57aaa5fd8c54dc4d4ddd70.png)


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



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

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

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

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/d72c9499d3081cdcca68bcc02af447cb.png)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

人工智能

测试

运维

Anthropic公开六层AI代码审查关卡，按风险分档决定人工介入，低风险自动放行。核心难题是Agent审查不累但噪声成本高，一PR曾触发五十多轮循环。四条收敛规则解决此问题：三轮后停、只审增量、分类修复、不重复提旧问题。

命令行工具

软件测试

单元测试

智能体

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Anthropic 的代码审查跑到五十多轮还没过：AI 审 AI 会自己卡住-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐