仅仅让 AI 阅读内部开发规则，并不能执行标准。需要将文档划分为“建议”和“阻断”状态，并为每条规则赋予可追踪的 ID，AI 审查才能成为运营系统，而不是个人意见。
Cloudflare 打造的与其说是 AI 审查器，不如说是“规则总账”
Cloudflare 在 2026 年 8 月发布的案例中表示，其 AI 代码审查器在四个月内标记了约 25 万项工程标准违规，并阻止了 1.6 万次合并。使用相同标准的规范审查器在实现前审查了约 600 个技术设计。 这个规模很引人注目，但更重要的并不是用了哪个模型，而是先建立了供人员和多个智能体共同参照的单一规则总账。
此前，指导信息分散在正式文档、仓库文件、聊天记录和负责人的记忆中。很难判断找到的内容是否最新、是否具有权威性，以及是否适用于当前工作。Cloudflare 将这些内容迁移到名为“Engineering Codex”的受管标准仓库中。架构、安全性、可靠性、TypeScript、Rust 等每个领域都有负责人；员工通过合并请求提出 RFC，经过多个阶段的审查后，由负责人最终批准。
标准措辞使用 RFC 2119 中的 MUST 和 SHOULD。在 RFC 2119 中，MUST 是绝对要求；SHOULD 是在存在合理理由时，充分考虑影响后可以偏离的建议。该文档还提醒，只有在互操作性或防止危害确有必要时，才应谨慎使用这类强制性措辞。 换言之，把所有最佳实践都升级为 MUST 并不会让标准更强，反而容易滥用阻断理由并失去信任。
好的规则不仅包含答案，也包含适用条件。
与“编写 OpenAPI”相比，“对外暴露的请求和响应模式必须使用 OpenAPI 编写文档”更容易进行机械判定。请将适用对象、要求级别、依据、例外批准人和原文链接作为一组来管理。
关键在于将批准与执行分开的两个开关
Cloudflare 的 RFC 获批后不会立刻阻止合并。在 approved 状态下，违规会显示为非阻断建议；只有经过单独升级进入 enforced 后，MUST 违规才会被阻断。这种结构分别留出了团队接受新规则的时间，以及验证自动判定准确性的时间。
| 状态 | 审查行为 | 应检查的运营指标 |
|---|---|---|
| 草案 | 负责人和利益相关方审查措辞与范围 | 模糊条件、重复规则、例外路径 |
| 已批准 | AI 提出建议，但允许合并 | 误报率、修复接受率、重复问题 |
| 执行中 | 仅阻断已验证的 MUST 违规 | 解除阻断时间、例外率、绕过尝试 |
| 已废弃 | 停止新的判定，但保留历史记录 | 替代规则关联、现有例外清理 |
这种方法也很适合代码托管平台的实际执行机制。GitHub 的受保护分支仅当必需状态检查成功、已跳过或处于中立状态时才允许合并，并且还可以限制为只信任特定 GitHub App 创建的检查结果。 如果将 AI 审查结果接入阻断关卡，规则设计还必须包含“谁能够以何种权限记录成功状态”。
相反，如果连 SHOULD 和个人偏好都阻断，审查就会变慢。Google 的公开代码审查指南也建议，与其要求完美代码，不如在变更明显改善整个代码库健康度时予以批准。它建议将已文档化的风格指南作为权威，并明确标注细微意见并非强制要求。 AI 也是如此。界面必须清晰区分有依据的必改项、建议和参考意见，开发者才不会将每句话都误认为阻断命令。
25 万次检测并不等于 25 万次质量改进。
Cloudflare 公开的数据是其自身的运营统计，而非独立评估结果。其并未另行给出相同违规的重复情况、误报，或开发者接受的比例。除检测数量外，还应同时查看每条规则的接受率、例外率、解除阻断时间和复发率。
不要将长文档整体输入；请将“检索索引”与原文分离
Cloudflare Codex 已有 60 多个 RFC，难以每次都将全部文档放入模型上下文。因此，单独的智能体会将 MUST 和 SHOULD 语句提取为 JSON，并附加 RFC 编号、领域、状态、章节和原文链接等元数据。审查器先搜索这个压缩索引，只有在判断需要额外上下文时才加载 RFC 全文。
每条语句都带有稳定的 slug，即使 RFC 被修改也能保持不变。有了这个 ID，便可按时间段比较同一规则的检测量和误报，并关联例外批准和废弃历史。如果 AI 只说“这不利于安全”，那只是意见；如果它记录“违反 SEC-API-014，依据为原文第 3.2 节”，这就成为可复现、可提出异议的判定。
将规则与执行代码分离的思路并不只适用于 AI。Open Policy Agent 的设计是以声明式代码编写策略，并由应用程序发送结构化 JSON 输入来获取判定。它将策略决策与实际执行分开，可用于 CI/CD、API 网关、Kubernetes 等场景。 能够可靠进行机械判定的项目应交给 linter 或策略引擎，只有需要上下文判断的架构与文档质量才留给 AI，这样更快也更易审计。
Cloudflare 也选择了同样的分层。可机械验证的语言规则由自定义 linter 在毫秒级呈现；AI 审查器则查找相关 RFC，并评估是否构成上下文中的违规。它还允许在 CI 之前通过本地 CLI 运行相同审查，从而缩短反馈距离。 Cloudflare 表示，在其内部 AI 工程栈中，AI 会审查所有标准 CI 仓库的合并请求，并在每项判定中引用具体的 Codex 规则 ID。
本周从一个小仓库开始的四个步骤
只收集 10 条反复出现的审查意见
查看最近 30 个 PR 或 MR，筛选出至少重复两次的意见。为每一项记录 rule_id、适用路径、要求级别、依据链接、负责人和例外批准人。排除“写得整洁些”这类没有判定条件的句子。
先划分 linter 与 AI 的边界
能通过 AST、正则表达式或模式可靠捕获的规则，应交给 ESLint、oxlint、Semgrep、OPA 等确定性检查。只有需要阅读设计意图或文档上下文的规则才保留在 AI 队列中。指定一个主检查器，避免两个工具重复报告同一违规。
以警告模式观察两周
在 AI 结果中输出规则 ID、严重程度、依据、问题位置、置信度和原文链接，但不要阻止合并。让开发者选择“接受、误报或申请例外”之一，并记录每条规则的接受率。如果样本较少，应以最小判定数量而不只是时间作为标准。
仅将已验证的 MUST 升级为必需检查
仅将安全、数据丢失、兼容性等违规成本高且误报足够低的项目接入分支保护的必需状态检查。为例外设置到期日和批准人，并制定运营条件：若解除阻断时间或例外率激增，则自动退回警告模式。
请将最终批准责任保留给规则负责人和代码负责人。AI 是在工作当下查找相关指导的执行接口，而不是自行决定哪些规则适合组织的权威。
如果想进一步深入
How Cloudflare enforces engineering standards using AI — 介绍 Codex 的 RFC 生命周期、JSON 索引，以及代码、规范和事故报告审查构成的核心案例。 blog.cloudflare.com
The AI engineering stack we built internally — on the platform we ship — 可了解仓库上下文、多智能体审查与 Codex 如何在实际开发栈中连接。 blog.cloudflare.com
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — 可确认 MUST、SHOULD、MAY 的准确含义，以及使用强制性要求措辞的标准。 rfc-editor.org
About protected branches — 用于将必需状态检查、批准、对话解决和合并队列配置为实际仓库关卡的官方文档。 docs.github.com
Open Policy Agent (OPA) — 介绍将结构化输入与声明式策略分离，并在 CI/CD 和基础设施中执行的策略即代码方法。 openpolicyagent.org
The Standard of Code Review — 整理了区分应阻断的质量问题与完美主义、个人偏好的代码审查原则。 google.github.io
