正在加载，请稍候
2026 年 6–9 月，Claude Code 合并 PR 翻倍而 revert 占比降超 40%。Anthropic 没砍评审，而是把它拆成七道闸门，本文拆解这套流程，并给出 3–4 人团队的最小版本。
2026 年 6 到 9 月，Claude Code 仓库合并的 PR 数量翻了一倍多，而 revert 占比下降了 40% 以上。Anthropic 的应对不是减少评审，而是把「同事互读 diff」这件事拆成机器与人分工的七道闸门。
因为吞吐量涨得比评审人手快：2026 年 6 到 9 月 Claude Code 的合并 PR 翻倍，传统的「同事互读 diff」模式在这个量级下会先崩溃——人要么变成瓶颈，要么变成敷衍放行。Anthropic 团队对成本的认识很清醒：人力时间等于评审时间加上修复坏代码的时间，只压缩一头，成本会原封不动转移到另一头。
这个瓶颈不只出现在 Anthropic 内部。我们在2026 移动端 AIcoding 落地数据里看到的是同一个错位：八成团队已经在用 AI 写代码，交付提速却并没有同步跟上——工具换了，验证环节没有跟着换。
所以 Anthropic 不追踪「评审覆盖率」这类虚荣指标，改盯两个可操作的数字：每个 PR 平均需要几个人类审批，以及等人审批的等待时间；护栏指标则是 revert 率与事故率。目标写得很克制——大多数 PR 最多一个人在环（有时只有作者本人），且事故不比以前多。
Boris Cherny 是 Claude Code 的创造者，他说过一句被反复引用的话：给 Claude 一个验证自己工作的方式，「大概是为拿到好结果最重要的一件事」，他估计这一步让最终结果提升了 2–3 倍。
七道闸门按「机器能判的交给机器、人只判风险」来分层：PR 之前的自我验证、每个 PR 必过的 AI 评审、阻塞性的安全评审、阻塞性的自动检查、基于风险分级的人工审批、合并队列，以及灰度与快速回滚。核心转变是从「这段代码有人看过吗」，变成「这个变更可能出什么问题，哪种检查最适合抓住它」。
| 闸门 | 谁在把关 | 拦什么 |
|---|---|---|
| 1. PR 之前的自我验证 | 作者 agent + 一个全新上下文的第二 agent 复看 diff | 没有证据的「已完成」声明、明显缺陷 |
| 2. 每个 PR 必过的 AI 评审 | 多个 agent 并行找 bug，verifier agent 对每条发现投票 | 实质性缺陷；发现分 Important / Nit / Pre-existing |
| 3. 安全评审（阻塞） | 独立的自动化通道 | 有未处理的安全发现就不许合并 |
| 4. 自动检查（阻塞） | lint、类型、跨平台测试、构建 | 跑不过 CI 的变更；PR 模板强制填「怎么测的」「怎么回滚」 |
| 5. 基于风险的人工审批 | 分类器定级后交给人 | 低风险（文档、文案）免人工；中风险一人；高风险两人 |
| 6. 合并队列 + 特性开关 + 灰度 | 合并队列 | 针对最新 main 重跑检查；新行为先给内部员工，再走 latest，最后进 stable |
| 7. 快速检测与回滚 | 开关 + 事故复盘 | 出事不用重新部署就能关掉；复盘必问「哪一层本该拦住它」 |
第 2 道闸门的效果最能说明问题：内部 PR 上「实质性评审意见」的占比从 16% 升到 54%，千行以上的大 PR 几乎总能查出问题。做法不是让人多看，而是让多个 agent 并行找 bug，再由 verifier agent 对每条发现投票，通过之后才发出去。
第 5 道闸门里有两条规定特别值得抄：agent 的批准永远不算人工批准；一次批准只覆盖一个 commit，有新提交就得重新审批。这两条堵的正是「AI 互相放行」这条最隐蔽的漏路。
安全评审之所以被单独设成一道阻塞闸门，是因为 agent 越权与数据外泄在 2026 年已经不是假想题——我们此前整理过一轮Agent 安全集中爆发的案例，从 Anthropic 的越权事件到多智能体暴走，共同点都是缺一道不问「功能对不对」、只问「边界有没有被越过」的独立检查。
会退化，所以 Anthropic 把评审质量做成了一个可以打分的目标：拿过去引发事故、并经专家确认的 PR 组成 eval 集，评审器每天跑分，只有分数提升的改动才被保留。噪声用两个办法度量——看人对评论的反应，以及在已知干净的 PR 上跑评审器，看它会不会误报。
这一步看上去很重，实质是把「评审质量」从主观感受变成可优化的目标函数。任何自研 AI reviewer 的团队，缺的通常都是这一层：没有 eval 集，你只能靠感觉判断它是不是变差了，而这恰恰是最容易失守的地方。
因为评审 agent 会去评论新 diff 之外的老代码：Anthropic 遇到过一个 agent 写的 CLI PR，一夜之间跑了 50 多轮评审，而 git blame 显示约 59% 被标记的代码在第一轮之前就已经存在。这是 AI 评审 AI 代码时特有的死循环——它不是抓不到问题，而是抓着旧账不放。
他们的修复分四步：三轮封顶（超过就退回来重新考虑方案）、后续轮次只看增量 diff、按 bug 类别标记而不是按单行、禁止重复发现。效果是三个数字一起变了：
更麻烦的情形是多个 agent 共处同一个仓库——我们复盘过一例三个 Claude 智能体共事一个仓库后开始互相投毒的失控事件，可见「谁能改什么、改动如何互相看见」这件事，必须在流程层而不是提示词层解决。
凡是要引入 AI reviewer 的团队，上面四步几乎可以照抄——它解决的是流程收敛，而不是模型能力。
先抄两个成本最低的动作：把反复出现的问题写进仓库约定（Anthropic 用 CLAUDE.md 记项目约定，用 REVIEW.md 写给代码主人的指引——失败长什么样、nit 上限、哪些路径直接跳过），以及给评审轮次封顶。这两件事不依赖任何自研基建，今天就能落地。
先说我们的样本口径：截至今日，蓝曜炬辉已发布的 7 个交付案例全部在 2026 年完成，团队规模清一色是 3–4 人核心团队，项目周期 2–6 周（最短的 2 周完成首版，最长的一个是产品规划 2 周 + UI 设计 1 周 + 全栈开发 3 周）。这些案例的技术栈集中在 Next.js 与 PostgreSQL（各出现 7 次）、Go（6 次）、React（3 次）；行业分布是人工智能 2 个、企业服务 2 个、教育培训 2 个、文旅消费 1 个。
这个样本说明一件事：我们的交付节奏是「两周一个首版」，不是「一天三万次变更」。所以下面这份清单是参考方案，不是已完成的落地统计——它把上面七道闸门的逻辑压到 3–4 人规模，其中的验收指标属于建议值，不是实测结果：
闸门再密，最后拍板的仍然是人。就像我们在小程序 AI 应用那篇里说过的，团队最缺的往往不是模型，而是能判断 AI 输出对不对的工程师——评审流程的价值，是把这些人的时间集中在机器判不了的地方。
如果你的团队正在推进 AI Coding 转型、需要把这套流程接进现有工程体系，可以参考我们的服务页了解交付方式。
亚马逊云科技在 2025 年 7 月 16 日首次推出 Kiro 预览版时，选的不是评审流水线，而是规范驱动开发（SDD）：把接口、数据流与约束写成结构化 spec，作为 agent 之间协同的唯一事实源，再用 spec 的版本快照替代原始对话历史做上下文锚点。它的落点不是「生成得更快」，而是「生成出来的东西可集成」。
它要解决的是被推迟的成本。InfoQ 在 2026 年 10 月 16 日的报道里把 vibe coding 的痛点拆成三条：长会话下的上下文衰减（轮次一多就忘了前面约定好的接口定义与数据结构）、决策不可追溯（为什么这一行要这么改、当时的前提是什么，事后无从查证）、从 Demo 到生产的鸿沟（原型能跑但缺需求文档、设计说明与测试覆盖，要进生产还得回头用人力补一遍）。Kiro 的产品负责人 Nikhil Swaminathan 与开发者体验副总裁 Deepak Singh 把它的定位描述为「从原型到生产」。
| 维度 | Anthropic 的七道闸门 | Kiro 的 Spec 驱动 |
|---|---|---|
| 改的是什么 | 变更进来之后的流程 | 变更进来之前的输入 |
| 核心抓手 | 仓库约定文件 + 评审器 eval 集 | 结构化 spec + spec 版本快照作上下文锚点 |
| 主要收益 | 高吞吐下的质量下限（revert 率、事故率） | 工程可审计性（生成行为绑定 spec 变更记录，可回溯） |
| 适合谁 | 已有大规模内部代码库与成熟 CI 的团队 | 交付需可追溯、要过评审与合规检查的团队 |
两条路并不冲突：闸门管的是「变更进来之后怎么拦」，spec 管的是「变更进来之前长什么样」。前者改善吞吐下的质量下限，后者改善可审计性。真要做 AI Coding 治理，两边都得有，先后顺序取决于你现在最痛的是吞吐还是追溯。
不必全部，但要分层：Anthropic 用分类器给每个变更定风险等级，低风险（文档、文案一类）免人工审批，中风险一人，高风险两人，且 agent 的批准永远不折算成人批准。这么做的前提是下面几层自动闸门足够硬，能把大部分低级问题先滤掉。
是「翻旧账」式的死循环——评审 agent 去评论新 diff 之外的老代码，轮次越滚越多却收敛不了。Anthropic 遇到过一个 agent 写的 CLI PR 一夜跑了 50 多轮评审，而 git blame 显示约 59% 被标记的代码在第一轮之前就已经存在，人力和 token 全耗在了跟本次变更无关的旧代码上。
先把约定写进仓库。Anthropic 把反复出现的问题固化成两类文件：CLAUDE.md 记项目约定，REVIEW.md 写给代码主人的评审指引——失败长什么样、nit 的上限是多少、哪些路径直接跳过、要求以文件加行号的形式给证据。这层成本几乎为零，但对 AI 评审的收敛效果最直接。
建 eval 集来量化它。用过去引发事故、并经专家确认的 PR 当考题，每天给评审器打分，只有分数提升的改动才被保留；再用「人对评论的反应」以及在干净 PR 上的误报率来度量噪声。没有 eval 集，你只能凭感觉判断评审器是否退化，而感觉通常在它已经放行了几个坏变更之后才出现。
部分适用，前提是先有可自动化的检查。国内多数团队没有 Anthropic 规模的内部 CI、特性开关与灰度体系，硬抄七层只会压垮小团队；建议从「自动检查设为阻塞」和「PR 模板强制写回滚方案」这两个最便宜、也最容易被忽略的环节起步，再逐层往上加。