标题：Cloudflare 如何借助 AI 落实工程标准
在过去的四个月里，我们的 AI 代码审查员标记了近 25 万处偏离 Cloudflare 工程标准的地方（本文中称为“违规”），并阻止了 16,000 次合并。我们的规格评审代理在实现开始之前，已按照相同标准评估了近 600 份技术设计。这两个系统都基于 Cloudflare Codex，这是一个面向人员和代理共同构建的共享工程指南源。这篇文章解释了为什么我们构建 Codex，它如何支持工程生命周期，以及我们下一步计划做什么。
在 Codex 出现之前（我们之前在关于 AI 工程栈的文章中简要介绍过），Cloudflare 的开发者指南分散在许多地方：正式文档、仓库文件、聊天线程，以及工程师个人积累的知识。工程师们常常花费太多时间搜索指南，而不是专注于他们要解决的问题。即使找到答案，他们也并不总能判断该答案是否最新、是否权威、是否适用于自己的情况。随着 Cloudflare 的壮大，这种模式越来越难以为继。没有工程师能读完每一条标准，评审人员也无法可靠地检查每一项要求。当人员在不同团队间流动时，机构知识变得难以找回；而那些没有被持续展示或执行的标准，会导致项目之间出现偏差。我们将这整套知识重建为 Cloudflare Codex：一套受治理的工程标准，代理可以在工作现场检索并应用它们。现在，同一份指南可以为代码审查、技术设计审查、事故报告审查以及许多其他用例提供信息，而工程师可以将他们的时间和判断力集中在由此产生的结果上。
Codex 的组织与工作流
专用的 Codex 治理模型将 Codex 划分为不同的领域，覆盖我们所关心的工程领域。这些领域包括架构事项（例如前端和控制平面）、横切关注点（安全和可靠性）、特定语言（TypeScript 和 Rust）以及其他几个领域。
每个领域都有一位负责人（domain owner），负责把关文档内容、一致性和整体质量。Codex 标准采用 RFC（Request for Comments，请求评论）格式，其中的要求遵循 RFC 2119 定义的 SHOULD 和 MUST 关键字。此外，我们还要求文档在 front matter 头部携带领域、RFC 状态等元数据。
任何对相关领域有兴趣、且具备相应能力的 Cloudflare 员工，都可以按规定的结构提交合并请求（merge request）来提议一份 RFC。提案随后会经过多轮评审，评审范围逐轮扩大。领域负责人最终批准后，RFC 就成为 Codex 的一部分，发布到基于 Astro 搭建的内部站点上。
获批的 RFC 可供 Codex 客户端和代理（agent）读取，它们可以立即在代码、配置或文档中标记违反 Codex 规范的地方。不过，只有当 RFC 从「已批准」进入「已强制执行」状态后，这些工具才会依据 Codex 规范真正执行阻断。这一独立的晋升步骤，既给了团队消化新要求的时间，也兼顾了某些规范需要额外改造才能落地的情况。
下图展示了 Codex 工作流的完整步骤：
一个朴素的方案是到此为止，把整个 Codex 原样丢给大语言模型（LLM）处理。然而，我们的 RFC 数量已经超过 60 份，而且还在持续增加，整个语料库的体量会严重挤压上下文窗口，反而拉低 LLM 的效果。
为了引导模型快速定位最相关的 RFC，我们调用了一个专门构建的代理，自动提取其中的 SHOULD 和 MUST 语句，压缩成专用的 JSON 结构，并补上支持按需发现（lazy discovery）和渐进式披露（progressive disclosure）的元数据。下面这段精简摘录展示了控制面（control plane）服务 RFC 的处理结果：
每条语句都会获得一个稳定的 slug 标识符。即使对应的 RFC 后续更新，这个标识符在提取过程中也保持不变。借助它，我们可以在不同系统、不同时间点持续追踪同一条规范，这对监控、分析和异常处理至关重要。
起初，我们把这些规范条目提取到另一个更为精简的 Markdown 文件中，而不是存在 JSON 里。后来，为了便于智能体更精准地筛选所需内容，我们转向了更丰富的结构化格式。下一步，我们还计划加入更多元数据，以进一步缩小筛选范围，例如标注某条规范适用的软件开发生命周期（SDLC）阶段（如设计、实现、运行时）。请注意，这里的原文是完整段落的一部分，并非缺失，但根据规则，我将直接翻译当前可见内容。
Codex 的使用者
目前已有多个系统在日常工程工作中使用 Codex。下面三个智能体可以直观展示它的实际效果：AI 代码审查器、规范审查器和事故报告审查器。
AI 代码审查器
我们的 AI 代码审查器（已在另一篇博文中详细介绍）会从多个维度评估合并请求（merge request），其中就包括是否遵循 Codex 规范。每次审查时，智能体会检索相关的 RFC，并解析其中的 Codex 规范条目。只有当模型或协调器需要更多上下文时，它才会加载完整的 RFC 正文。大多数情况下，仅凭规范条目本身就能说明某个违规问题的原因。
规范条目中的 SHOULD 和 MUST 之分，加上 RFC 本身的状态，共同决定了审查器的回应方式。如果 RFC 还处于批准阶段，审查器给出的只是非阻塞性建议；一旦 RFC 被强制执行，任何未满足的 MUST 要求都会让审查器拒绝批准或直接阻止合并请求，具体取决于问题的严重程度。
自今年年初 Codex 上线以来，AI 代码审查器已经标记出近 23 万个违规项。其中约 1.6 万个导致批准被拒绝（即涉及强制执行 RFC 中的 MUST 条款）。
代码审查的替代方案
由于要经过协调器框架和子智能体执行，单次 AI 代码审查通常需要几分钟才能跑完。虽然这份等待往往物有所值（或者说值回 token 开销），但工程师们还是抱怨审查耗时太长，而且修复问题还得来回折腾。于是我们琢磨如何改善体验，最终拿出两个补充方案：针对那些可以机械校验、且与具体语言相关的 Codex 要求，我们提供了定制的 linter 配置包。
这些规则与 Codex 规范保持一致，能在毫秒级的时间内发现代码问题。TypeScript 是第一款获得 Codex linter 支持的语言，同时我们也统一用 oxlint（由最近加入 Cloudflare 的 VoidZero 团队维护）来执行 lint，保证性能。Rust 项目的 linter 正在开发中，之后还会补上 Go，最终覆盖 Cloudflare 最常用的几种语言。
为了省掉评审流程中的持续集成（CI）这一环，我们还支持通过命令行（CLI）在本地运行 AI 代码评审器。它复用了 CI 中的协调器功能，对自动确定的 diff 集合执行同一套（基于 OpenCode 的）代理，结果直接显示在终端里。我们相信 linter 对几乎所有开发者和代码库都有用，而 CLI 则是为偏好这种方式的工程师准备的另一种选择。
规范评审器（Spec Reviewer）
Cloudflare 的工程师在动手实现之前，通常会先写设计文档和技术规范（简称 spec）。Codex 中有相当一部分内容涉及设计、架构以及其他与技术评审相关的主题。为了在实现开始之前就发现架构层面的问题，我们构建了 spec reviewer——一个自动寻找规范文档、并对照 Codex 相关要求进行评估的代理。
Spec reviewer 运行在 Cloudflare 的开发者平台上：以 Cloudflare Worker 的形式运行，把结果和状态存在 D1 里，通过 AI Gateway 转发模型请求，并用 Cron Trigger 定时触发对新规范的扫描。它先从 Codex 中筛出与规范相关的领域和章节（语言特性、面向实现的 RFC 等会被忽略），再由几个引导提示词告诉模型如何执行评估、如何组织结果。发现的问题会按严重程度评级（SHOULD 和 MUST 等关键词会影响评级），并附上总体质量与架构方面的建议。一次评审跑完后，它会在规范文档上留下一则备注，链到自定义仪表板，评审详情可以在那里查看。
从2026年5月初开始，我们已审查了近600份不同的开放技术规格文档（spec）。再加上按需触发或规格变更触发的重新运行，截至现在，审查调用总次数已超过3,200次。在全部发现中，绝大多是“重大”（65%）或“次要”（29%）级别的问题，“严重”（critical）问题只占少数（6%）。下图展示了规格审查器界面的样貌：
我们计划把规格审查器更紧密地融入流程：直接在规格文档上发评论，让人与代理之间的对话能够影响审查评估，并标记高影响的提案，供额外的人工复核。
事故报告审查器
事故报告审查器用同样的方法来处理事故报告（postmortem，事后剖析）。除了检查报告是否完整，它还会评估报告是否清楚说明了事故经过、是否找出了促成因素、是否记录了解决方案，以及是否提出了有意义的后续行动。这些要求都写在一份专门的 Codex RFC 里。事故报告审查器与规格审查器一样，都基于同一套 Developer Platform 构建模块，这种共享架构正在成为我们 Codex 代理的通用模式。自 2026 年 5 月至今，该审查器已评估了 200 多份事故报告，找出了诸如缺少后续行动项、时间线不完整、检测信号遗漏等缺口。在这些报告中，93% 对应的是低影响、仅内部可见或提前上报的事故。对于高严重度的事故，我们已把审查器设为中心化综合审查流程的必检环节——所有发现都处理完毕之前，报告不算完成。