AI 코드 리뷰가 1만6천 번 머지를 막았다 — 규칙보다 먼저 설계할 ‘집행 상태’ 대표 이미지

docs.github.com

AI 代码审查阻止了 1.6 万次合并——首先需要“执行状态”

AI 审查的权威不来自模型，而来自规则 ID 和执行状态。开发

How Cloudflare enforces engineering standards using AI

The AI engineering stack we built internally — on the platform we ship

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels

如果一条 AI 审查意见开始阻止合并

起初，AI 代码审查相当令人安心。它能找出人们遗漏的内部规则，还会附上依据文档。但一旦把这些意见接入必需检查，误读上下文的判断也会变成真正的合并阻止。开发者可能会先寻找绕过检查的方法，而不是遵守规则。

Cloudflare 并没有只靠模型性能来解决这个问题。它将工程标准作为 RFC 管理，并将文档已获批准的状态与可用于自动阻止的状态分开。已批准的规则先显示为非阻止性建议，只有已单独进入执行状态的 RFC 中未满足的 MUST 才会用于暂缓批准或阻止合并。

这个案例值得借鉴的并不是庞大的 AI 审查系统，而是一种运营结构：每条规则都应附带要求级别、稳定 ID、适用范围、原文和执行状态，以便追踪并提出异议。

在解读 1.6 万之前，先看统计范围

Cloudflare 在 2026 年 8 月发布文章的开头表示，其 AI 代码审查员在此前四个月标记了近 25 万项标准偏离，并阻止了 1.6 万次合并。但在详细章节中，它又表示自引入 Codex 以来标记了约 23 万项问题，并在约 1.6 万项变更中暂缓批准。两项统计的起始日期和纳入范围是否相同尚未公开，因此不应将它们合并解读为一个精确的绩效数字。

检测数量不等于质量改进数量。

合并请求的总数或唯一数量、对同一变更的重复判断、误报率以及开发者接受修复的比例均未公开。这个案例与其说是证明 AI 审查准确度，不如说是展示了将大量判断接入开发流程时所需的执行结构。

规格审查数据也应以同样方式看待。从 2026 年 5 月初到文章发布时，Cloudflare 的 AI 规格审查员审查了约 600 份处于公开状态的唯一规格，并运行了超过 3,200 次，其中包括修改后的重新运行。发现项的严重性构成为 major 65%、minor 29%、critical 6%，但发现项总数并未公开，这一比例也不代表准确度或实际缺陷预防率。

批准与执行是两个不同的开关

在 Cloudflare Codex 中，当 RFC 变为 approved 后，AI 审查员可以提示相关违规，但结果是非阻止性的。只有 RFC 在单独的阶段被提升为 enforced 后，未满足的 MUST 才会按严重程度导致暂缓批准或阻止。谁批准提升，以及需要多高的误报率或多长的观察期，均未公开。

规则状态	AI 审查行为	团队需要另行决定的事项
approved	有依据的非阻止性建议	适用范围和反复出现的例外
enforced	将未满足的 MUST 用于暂缓批准或阻止	提升权限、异议和解除阻止路径

MUST 和 SHOULD 也不是相同的指令。RFC 2119 中，MUST 是绝对要求；SHOULD 则表示在特定情况下可能有合理的偏离理由，但必须充分理解并认真权衡其影响。强制性表述应仅在确实为互操作性或防止伤害所需时谨慎使用。将所有最佳实践都改为 MUST 并不会增强执行力，反而可能只是增加阻止理由。

Google 的公开代码审查指南也优先考虑代码库的持续改进而非完美，并建议将不重要的意见标记为可选。 AI 审查界面也应明确区分必需修改与建议，避免所有意见都变成事实上的阻止命令。

稳定的规则 ID 比冗长的规则集更重要

Cloudflare 有超过 60 份 RFC，因此不会每次都把全文放进模型。单独的代理会将 MUST 和 SHOULD 语句提取为 JSON，并附上 RFC 编号、标题、状态、领域、章节、要求级别和原文链接。审查员先搜索这个压缩索引，只有需要更多上下文时才加载 RFC 全文。

每条要求语句都带有稳定的 slug，即使 RFC 被修改后也能保持不变。这样多个系统可以持续追踪同一规则的判断、分析和例外。Cloudflare 的内部 AI 工程栈也说明，审查判断会引用具体的 Codex 规则 ID。

规则记录不是判定书，而是证据的地址。

与其说“API 文档不充分”，不如说明哪份文档的哪一节适用于哪项变更，让负责人能够重新核对同一依据。不过，Cloudflare 公开的 JSON 是简化示例，不应视为完整的外部配置架构。

现在就试试：创建一条非阻止性规则记录

尚未找到面向外部组织的 Cloudflare Engineering Codex 及其内部审查 CLI 的公开安装和认证流程。因此，第一次实践不是安装 Cloudflare 工具，而是仅用当前团队文档和编辑器，将一条重复出现的审查意见转为可追踪记录。

确认准备材料和访问权限。 请准备可在浏览器中打开的当前开发标准的准确章节链接、最近 PR 或 MR 中反复出现的一条审查意见、规则所属领域和文档状态，以及用于保存 JSON 的内部文档或仓库。不需要单独的 Cloudflare 账户、安装或认证；只需具备打开内部原文和保存记录的权限。
在原文中确认要求级别。 将审查意见与相应标准中的准确句子进行比对。依据 RFC 2119 对 MUST 和 SHOULD 的定义，将其分类为必须遵守的绝对要求，或允许合理例外的建议。如果找不到当前有效的原文或准确章节，请将其排除在自动判断候选之外。

将以下输入保存到自己的文档中。 这是编辑部参考 Cloudflare 公开字段制作的审查示例，并不是在 Cloudflare 上运行的配置文件。

{ "rfc": "TEAM-API-001", "title": "API schema documentation", "status": "approved", "domain": "api-platform", "statements": [ { "slug": "api-schemas-must-be-documented", "section": ["API", "Schema"], "level": "MUST", "text": "外部请求和响应架构必须记录在团队的 API 规范中。", "href": "https://internal.example/standards/api#schema" } ]
}

直接比对原文与记录。 确认 href 是否打开准确章节，text 是否没有扩大或缩小原文的适用对象，以及 level 是否与原文一致。将 slug 设为不与其他规则重叠的固定标识符，以便后续关联判断和例外。
确认成功状态。 当状态、领域、稳定 slug、原文章节、要求级别、要求语句和直接链接均已具备，并且含义与原文一致时，就得到了第一个结果。请将 status 保持为 approved。在这个阶段不要阻止 PR 或 MR。

接入实际阻止还需要规则读取判定器、仓库权限、结果格式、提升权限和恢复路径。不得将公开资料中没有的观察期或误报率当作 Cloudflare 的官方提升标准。

阻止之前，请分开检查职责与平台权限

对于从相同输入总能得出相同答案的规则，没有必要交给 AI。Cloudflare 为可机械验证的语言特定要求提供自定义 linter，并为 TypeScript 使用 oxlint。需要阅读上下文的违规由 AI 审查员处理，并通过内部 CLI 在本地运行相同审查流程。不过，该 CLI 的外部安装命令和认证方式尚未公开。

如果将自有判定器接入 GitHub 的必需状态检查，还会适用单独的平台规则。根据 GitHub 官方文档，required check 必须处于 successful、skipped 或 neutral 状态才能合并，并且可以将更新状态的预期来源限制为特定 GitHub App。这不是复现基于 GitLab 的 Cloudflare 内部实现的流程，而是在 GitHub 上可用的单独实现示例。

在提升为阻止前，至少应确定谁批准提升、在哪里可以对判断提出异议，以及谁能解除错误阻止。让 AI 审查值得信任的不是更强硬的措辞，而是能够说明哪些规则目前只是建议，哪些规则才拥有阻止权限的状态。