AI 写完人 Review 不过来怎么办：用 AI 治理 AI

AI 写完人 Review 不过来怎么办：用 AI 治理 AI

——「人 × Agent 协作」系列 · 第 3 篇

上一篇结尾，我们留下了一个更棘手的问题：当 AI 每天产出 4500 行代码、65 个文件的 diff，人，怎么 Review 得过来？

这一篇，正面回答它。答案出乎意料地简单，却又出乎意料地深刻：让另一层 AI 去治理这一层 AI 的产出。

但在讲我们怎么做之前，必须先承认一件让很多团队难堪的事。

一个所有团队都会撞上的死结

先还原一个真实场景。

某个工作日的早上 9 点半，staging 环境完成了一次新部署。这次部署包含 65 个文件变更、4530 行新增代码、687 行删除，触及审批流水线、模拟测试、多平台适配器、终审兜底等多个核心模块。

按照传统的代码评审流程，应该有一个或几个工程师，打开这个 MR，从第一行 diff 看到最后一行，逐文件判断：这段逻辑对不对？有没有引入回归？符合架构边界吗？对用户的影响是什么？

我们来算一下这件事的真实成本。假设一个工程师以合理的仔细程度 review 代码——不是扫一眼，而是真正读懂每一处变更的意图和后果——平均速度大约是每分钟 10 行有效 diff。4530 + 687 = 5217 行：

5217 ÷ 10 ≈ 520 分钟 ≈ 8.7 小时

也就是说，光是把这一次部署的 diff 完整 review 一遍，就需要一个工程师整整一天。而这，是每天都会发生的事。如果团队有 5 个工程师轮流 review，每个人每周要花掉将近两天在 review 上——这还不算 review 之外的开发、调试、开会、处理线上问题。

结果会怎样？ predictably，review 会变形。

第一种变形是走马观花。工程师知道自己看不完，于是只扫文件名、扫大块改动的标题、扫有没有明显的语法错误，然后点个 Approve。这种 review 等于没 review——它给了虚假的安全感。

第二种变形是只看自己熟悉的模块。工程师只认真看自己负责的那部分，其他模块草草过。结果是回归经常从没人认真看的角落冒出来。

第三种变形最危险——review 积压导致部署延迟。为了 review 得过来，团队不得不限制部署频率，从每天一次降到每周一次。但部署频率降低，每次部署的 diff 又会变大，review 负担更重，于是进一步降低频率——这是一个死亡螺旋。

这就是所有依赖 AI 大量产出代码的团队，必然会撞上的死结：AI 让代码产得更快，但人的 review 能力没有相应提升，瓶颈瞬间从"写不出来"转移到了"看不过来"。

用 AI 治理 AI：一个反直觉但必然的答案

破解这个死结的方法，乍听像个悖论：既然人 review 不过来，那就再上一层 AI，让 AI 先 review 一遍。

这不是"用 AI 给 AI 涂脂抹粉"。它的逻辑很清晰：

人 review 不过来的根本原因，不是人不够聪明，而是信息密度太高。5200 行 diff 里，真正需要人判断的可能只有 5 处——一处架构边界违规、两处潜在回归、一处 UX 退化、一处文档遗漏。但人不知道是哪 5 处，只能逐行扫描，把 99% 的注意力浪费在"这段没问题、这段也没问题"上。

如果有一层 AI，能把 5200 行 diff 预处理成"这 5 处需要你判断，这是每一处的位置、归因、后果和建议"，那么人的 review 负担就从 5200 行骤降到 5 个判断。这才是真正的提效——不是让 AI 替人判断，而是让 AI 把需要人判断的东西，从噪音里过滤出来。

这个想法听起来简单，但我们最早试过的朴素方案失败了。第一版做法是把整个 diff 丢给一个 AI，让它"列出所有问题"。结果它每次都能列出十几个"问题"——但其中大半是过度敏感的推测（"这里可能影响性能""这段命名不够清晰"），少数真问题反而被淹没。人拿到这样一份"什么都说有问题"的报告，信也不是、不信也不是，最后还是得自己重看一遍 diff。这个失败让我们意识到：问题不在 AI 评得不准，而在它没有区分"确定的问题"和"可能的疑点"，也没有告诉人"哪些我看过、判断没问题"。

这个思路也不是我们独创的。Cloudflare 在公开博客里描述了几乎一模一样的架构：他们用多达 7 个专业 AI agent 并行 review 每一个 MR——Code Quality、Security、Performance、Documentation、 Release Management、Engineering Codex、AGENTS.md——再由一个 Coordinator agent 统一编排，去重、改判、过滤推测性的噪音[^cf-arch]。过去 30 天，这套系统覆盖了 5169 个仓库、48095 个 MR，而工程师只在 0.6% 的情况下需要 override[^cf-arch]。

我们的做法和 Cloudflare 同源，但落地形态不同。下面拆开讲。

三份报告：把 diff 压缩成可判断的颗粒

每天 9 点半，小布会跑一个"产品架构与 UX 增量评审"的自动化。它的输入是 staging 上一次部署到这次部署之间的 commit range，输出是三份 Markdown 报告。

这三份报告的设计，本身就是一套信息分层的方法论。让我用一次真实的部署来展示。

那次部署的 diff 是：65 个文件、4530 行新增、687 行删除。小布没有直接把 diff 丢给人，而是产出了三份文档：

第一份：diff.md——机器抽取的变更清单。 这份报告回答的是"改了什么"。它按模块归类，列出每个模块的关键变更：哪个 contract 新增了字段、哪个 service 增加了什么逻辑、哪个组件改了什么交互。它不包含判断，只有事实抽取。

比如它会写："模拟测试批次新增 requestSummary / resultSummary 字段，进入前后端契约；多平台 simulation executor 补齐查询与结果摘要；合思无结果详情改为展示平台真实查询条件。"

这份报告的价值在于：它把 5200 行 diff 压缩成了几十条结构化的事实陈述。人扫一遍，10 分钟就能建立"这次部署整体在干什么"的认知。

第二份：focus.md——用户可感知的影响面。 这份报告回答的是"对用户意味着什么"。它从用户视角出发，描述这次部署会改变哪些用户能看到的入口、哪些流程会受影响、有哪些正向改进、有哪些约束和边界态。

这份报告的价值在于：它把代码变更翻译成了产品语言。很多时候，代码本身没错，但它对用户的影响是负向的——比如一个空态分支没处理好，导致按钮点了没反应。这种问题在 diff.md 里看不出来，但在 focus.md 里会暴露。

第三份：review.md——这才是真正要给人判断的东西。 这份报告回答的是"哪里有问题，严重程度如何，该怎么办"。它是整个体系的核心，采用了一套分级门禁的结构。

让我展示一次真实的 review.md 是怎么写的。某次部署后，小布产出了这样一份审查：

结论：本次 staging 有新部署代码。总体结论：不建议把某定时任务页直接扩大给更多管理员使用；对主线 AI 审核没有发现阻断级问题。

上线拦截报告：

结论	数量	说明
🔴 拦截整改	0	未发现阻断主路径的问题
🟠 强烈建议	1	定时任务配置以裸 JSON 编辑，易把配置错误延后暴露
🟡 建议优化	2	运行详情过度暴露底层 payload；某开关语义不足

然后，每一条 finding 都有固定的结构：基准（依据哪条产品原则）→ 位置（精确到文件和行号）→ 问题（具体描述）→ 证据（引用代码或记忆文件）→ 产品后果（对用户的真实影响）→ 修复建议（可执行的整改方向）→ 归因（是新增问题还是回归）。

以那条 🟠 为例：

位置：scheduled-tasks/page.tsx:488、:493、:1122

问题：定时任务是"什么时间、用哪个系统、按什么条件自动提交"的产品概念，但当前编辑入口只给管理员一个完整 JSON textarea。保存时只解析 JSON 语法，其它业务不变量没有被 schema 化。管理员可以保存一个语法正确但语义错误的配置，直到下一次运行才失败。

产品后果：用户把"每日报销抓取时间"这类配置改坏时，页面即时反馈仍是"已更新"；真正错误推迟到运行时，排查成本更高，也让用户误以为系统不稳定。

修复建议：短期把关键字段拆成受控编辑区，高级 JSON 放进折叠区；后端不应继续只接受 catchall(json)，需要定义稳定业务 schema。

请注意这份报告做对了什么：

1. 它没有泛泛而谈"建议优化用户体验"——它精确到行号、精确到后果、精确到修复方向。
2. 它区分了"阻断"和"建议"——🔴 会拦截部署，🟠 强烈建议但可以上，🟡 只是优化项。
3. 它还列出了"正向取舍 / Not Findings"——明确写出哪些变更看起来可疑但其实是合理的，避免人误判。

为什么不直接用一个 AI review？

讲到这里，你可能会问：既然一个 AI 就能 review，为什么要拆成三份报告、还搞分级？

因为单一 AI review 有三个致命问题，而我们的设计正是为了绕开它们。

问题一：单一 AI 容易"什么都想说"。 如果把 5200 行 diff 直接丢给一个 AI 让它"找问题"，它倾向于找出一堆问题来证明自己认真工作了——其中大量是推测性的、过度敏感的、甚至误报的。Cloudflare 的 Coordinator agent 专门有一道工序就是"过滤掉推测性的警告"。我们的做法是让 review.md 必须包含"正向取舍 / Not Findings"这一节——强制 AI 说明哪些它看过但判断为合理，这反向约束了它乱报。

问题二：单一 AI 不区分严重程度，人无法分流。 如果 AI 列出 20 个"问题"而不分级，人还是得逐个看。分级门禁的意义在于：人原则上只看 🔴 和 🟠，🟡 可以批量延后。这把人的注意力进一步聚焦——从"看所有问题"压缩到"看阻断和强烈建议"。在我们实践里，绝大多数部署的 🔴 都是 0，🟠 通常是 0-2 条。也就是说，人每天真正需要认真判断的，常常只有一两个问题。

问题三：单一 AI 把事实和判断混在一起。 这正是为什么我们要拆成三份报告。diff.md 是事实（改了什么），focus.md 是影响（对用户意味着什么），review.md 才是判断（哪里有问题）。分开之后，人可以交叉验证：如果 review.md 说某处有回归，人可以立刻翻到 diff.md 看那处的实际代码，翻到 focus.md 看那处对用户的影响——三份报告互相印证，判断的可靠性远高于一份大杂烩。

Cloudflare 的分级，我们的分级

我们的做法和 Cloudflare 高度同源，但有两处有趣的差异，值得对比。

差异一：Cloudflare 按 diff 大小分级，我们按问题严重程度分级。

Cloudflare 在 agent 跑起来之前，会先对 MR 做一次风险分级：

• Trivial（≤10 行、≤20 文件）：只跑 Coordinator + 一个通用 reviewer，连模型都降配省 token。
• Lite（≤100 行）：跑 Coordinator + Code Quality + Documentation 等。
• Full（>100 行或触及安全敏感文件）：所有专业 agent 全上。

这是一种输入侧的分级——根据工作量决定投入多少 AI 算力。

我们的分级是输出侧的——不管 diff 多大，都跑完整评审，但把输出分成 🔴🟠🟡 三级，决定人需要投入多少注意力。两者其实可以叠加：Cloudflare 的做法优化的是 AI 成本，我们的做法优化的是人的注意力。在 AI 算力越来越便宜的今天，优化人的注意力是更值得做的事。

差异二：Cloudflare 偏向 approve，我们偏向"标注而非阻断"。

Cloudflare 明确写了一条原则："bias toward approval"——只要不是 critical 或生产安全风险，哪怕有一个 warning，也只标 approved_with_comments 而不阻断合并。万一真的紧急，工程师评论一句 break glass，系统强制放行，不管 AI 发现了什么。那条 0.6% 的 override 率，正是这套"宽松 + 兜底"哲学的成果。

我们的哲学一致，但落地更细。我们不阻断合并（那是人的决定），但我们会把每一条 finding 都追溯到一条产品基准——比如"基准五：异常反馈的告知、安抚、指引"。这意味着，AI 不是在凭感觉说"这里可能有问题"，而是在对照一套显式的、团队共识的产品原则做判断。当人说"这条 🟠 我不认同"时，讨论的不是"AI 对还是我对"，而是"这条产品基准在这个场景下该怎么用"——这让 override 变成了一次产品原则的校准，而不是一次权力的拉锯。

共享环境：让 AI review 有"现场"

这一篇还有一个细节没讲，但它至关重要：小布的 review 不是对着 diff 空谈的，他能进入真实的运行环境。

Cloudflare 在博客里提到一个关键设计：他们的 review 系统有一个本地插件，工程师可以在自己的工作树上跑 /fullreview，"用的是和 CI 里完全一样的 agents 和 prompts，只是跑在你的笔记本上而不是 CI 里"[^cf-arch]。这意味着 AI review 和人看到的是同一个现场。

我们的做法更进一步——小布 review 的对象是已经在 staging 上跑起来的真实部署。他不是在看一段静态代码猜它会怎样，而是：先请求 staging 的 readiness 接口拿到当前部署的 commit SHA，解析成 git 历史，算出和上次评审之间的增量 range，然后对着这个已经在真实环境里运行的版本来评审。

这个区别是根本性的。对着 diff 评审，AI 只能猜"这可能会出问题"；对着运行中的环境评审，AI 能确认"这确实出了问题，因为我能看到行为"。 共享环境的细节，我们会留到第 5 篇展开，但它的价值在这里已经显现：让 AI review 从"纸上谈兵"变成"现场勘查"。

Review 这件事，被重新定义了

让我把这一篇的核心收束成一句话：

Review 不再是人看代码，而是 AI 把全量 diff 预处理成"几个需要人判断的头部问题"，人只做最后拍板。

这套做法带来了三个根本性的改变：

1. 人的 review 负担从"全量 diff"压缩到"几个判断"——从 5200 行降到每天一两处。
2. 判断的可靠性反而提升——因为三份报告交叉验证，每条 finding 都追溯到产品基准，比人凭记忆和直觉扫 diff 更稳。
3. 部署频率可以恢复——review 不再是瓶颈，团队可以重新回到每天甚至每次 push 都部署的节奏。

但这套体系能运转，有一个隐含的前提：那个负责 review 的 AI，必须是可信的、可控的、不会越权的。 这就引出了第 4 篇的问题：

当 AI 既能写代码、又能 review、还能自己创建工单、@ 人的时候，谁来管控这个 AI？整个流程的主导权，到底在谁手里？

这是本系列第 4 篇的主题：AI 队员、自动化、人——三者组成的管控三角。我们会讲清楚一条铁律——AI 处理不了的事，必须显式转人工，绝不能静默吞掉——以及它为什么是这套协作模式不至于失控的最后一道闸。

下篇见。

脚注

[^cf-arch]: Cloudflare 工程博客《Orchestrating AI Code Review at scale》（2026-04 发布）。本文引用的 Cloudflare 细节均出自该文：

- **7 个专业 agent**（Code Quality / Security / Performance / Documentation / Release Management / Engineering Codex / 仓库 AI 指令文件）+ Coordinator 编排，负责去重、改判、过滤推测性警告。
- **输入侧风险分级**：Trivial（≤10 行 / ≤20 文件）/ Lite（≤100 行）/ Full（>100 行或触及安全敏感文件），Trivial 档降配模型省 token。
- **偏向 approve 原则**：仅 critical 或生产安全风险阻断合并，否则标记 `approved_with_comments`；`break glass` 评论可强制放行。
- **本地插件**：提供 `/fullreview` 本地命令，官方原文为 "the exact same agents and prompts, just running on your laptop instead of in CI"。
- **运行数据**（2026-03-10 至 04-09，共 30 天）：覆盖 5,169 仓库、48,095 个 MR、131,246 次 review；break glass 288 次（0.6%）；中位时长 3 分 39 秒；平均成本约 1.19 美元。

链接：https://blog.cloudflare.com/ai-code-review/

一句话结论

Review 不再是人看代码，而是 AI 把全量 diff 预处理成分级（🔴🟠🟡）的头部问题；人只做最后拍板。这既化解了"看不过来"的死结，又让判断反而更可靠。