Cloudflare 如何利用 AI 执行工程标准
在过去的四个月里，我们的 AI 代码审查器 标记了近 25 万次偏离 Cloudflare 工程标准的行为（在本文中我们称之为“违规”），并阻止了 16,000 次合并。我们的规范审查代理在实施开始前，已根据相同的标准评估了近 600 份技术设计。这两个系统都源自 Cloudflare Codex，这是一个为人类和代理构建的共享工程指导来源。本文解释了为什么我们构建 Codex，它如何支持工程生命周期，以及我们下一步的计划。
在 Codex（我们在 上一篇关于 AI 工程栈的文章 中简要介绍过）之前，Cloudflare 的开发人员指导分散在许多地方：正式文档、仓库文件、聊天线程以及个别工程师积累的知识。工程师们常常花费过多时间搜索指导，而不是专注于他们试图解决的问题。即使找到答案，他们也未必能判断其是否最新、权威或适用于他们的情境。
随着 Cloudflare 的发展，这种模式越来越难以维持。没有工程师能阅读所有标准，审查者也无法可靠地检查每项要求。当人员在不同团队之间流动时，机构知识变得更难恢复，而未能持续展示或执行的指导导致项目之间出现偏差。
我们将这些知识重建为 Cloudflare Codex：一套受治理的工程标准，代理可以在工作点检索和应用。现在，同样的指导可以用于代码审查、技术设计审查、事件报告审查以及许多其他用例，而工程师可以将时间和判断力集中在由此产生的发现上。
Codex 的组织与工作流程
一个专门的 Codex 治理模型将 Codex 划分为不同的领域，涵盖我们关心的工程领域。这些包括架构问题（例如，前端和控制平面）、横切关注点（安全性和可靠性）、特定语言（TypeScript 和 Rust）以及其他几个领域。每个领域由一名负责人领导，负责其监督文档的内容、一致性和整体质量。
Codex 标准采用请求评论（RFC）格式。要求使用 RFC 2119 定义的 SHOULD 和 MUST 关键字。我们还期望在 front matter 头部包含元数据，如领域和 RFC 状态。任何有兴趣且具备领域能力的 Cloudflare 员工都可以通过遵循规定结构的合并请求提出 RFC。然后，提案会经过几轮来自越来越广泛的审查者的反馈。一旦领域负责人最终批准，RFC 就成为 Codex 的一部分，并发布到
__Astro__已批准的RFC可被Codex客户端和代理使用，它们随后可能开始在代码、配置或文档中标记Codex违规。然而，只有在RFC从已批准状态转移到已强制执行生命周期状态后，它们才会基于Codex声明进行阻止。这一单独的提升步骤使团队有时间吸收新要求，并适应需要额外工作的强制执行情况。
下图说明了Codex工作流程中的步骤：
一个简单的流程可以止步于此，并将整个Codex原样提供给大型语言模型（LLM）。然而，鉴于我们已有的RFC数量不断增加（60多个且还在增加），语料库的规模会给上下文窗口带来很大压力，并对LLM结果产生负面影响。为了帮助模型找到最相关的RFC，我们调用一个专门构建的代理，自动提取和压缩SHOULD和MUST语句，放入专用的JSON结构中，并添加支持延迟发现和渐进式披露的元数据。以下节选展示了我们控制平面服务RFC的结果：
{
"rfc": 14,
"title": "控制平面服务",
"status": "已批准",
"domain": "控制平面",
"statements": [
{
"slug": "use-quicksilver-for-edge-configuration-propagation",
"section": ["提案", "基础设施"],
"level": "应该",
"text": "如果需要将系统或客户配置传播到边缘，请通过发件箱模式使用 Quicksilver",
"href": "/rfcs/014-control-plane-services/#infrastructure"
},
{
"slug": "api-schemas-must-be-documented-in-openapi-spec",
"section": ["提案", "API 网关"],
"level": "必须",
"text": "API 请求和响应模式必须使用 OpenAPI 规范进行文档化",
"href": "/rfcs/014-control-plane-services/#api-gateway"
}
]
}
每条语句都会获得一个稳定的 slug 标识符，该标识符在提取过程中保持不变，即使其 RFC 更新也是如此。该标识符使我们能够跨不同系统随时间跟踪同一条语句，这对于监控、分析和异常处理至关重要。
最初，我们将语句提取到另一个更简洁的 Markdown 文件中，而不是 JSON。随着时间的推移，我们转向更丰富的结构化格式，以便代理能够更准确地过滤所需内容。我们计划添加额外的元数据以实现更精确的范围界定，例如语句适用的软件开发生命周期（SDLC）阶段的指示符（例如，设计、实现、运行时）。
Codex 消费者
多个系统已经在日常工程工作中使用 Codex。三个代理展示了 Codex 的实际工作方式：我们的 AI 代码审查器、规范审查器和事件报告审查器。
AI 代码审查器
我们的 AI 代码审查代理，在单独的一篇博客文章中介绍，从多个维度评估合并请求，包括 Codex 合规性。
对于每次审查，代理检索 RFC 并解析 Codex 语句。仅当模型或协调器需要额外上下文时，它才加载完整的 RFC 正文。在大多数情况下，语句提供了足够的信息来解释报告的违规行为。
SHOULD 和 MUST 之间的区别，以及 RFC 的状态，决定了审查器的响应方式。来自已批准 RFC 的发现是非阻塞性建议。一旦 RFC 被强制执行，未满足的 MUST 要求会导致审查器拒绝批准或阻止合并请求，具体取决于严重程度。
自今年早些时候 Codex 推出以来，AI 代码审查器已标记了近 230,000 个违规行为。其中，近 16,000 个导致批准被拒绝（即，它们涉及已强制执行 RFC 上的 MUST 语句）。
代码审查替代方案
由于协调器框架和子代理执行，单次 AI 代码审查器运行通常需要几分钟才能完成。尽管等待通常物有所值（或令牌），但工程师们一直在抱怨延迟和修复发现所需的额外往返。我们研究了如何改进体验，并提出了两个额外的选项：
- 对于可以通过机械方式验证的特定语言 Codex 要求，我们提供自定义 linter 配置包。这些与我们的 Codex 规范保持一致，并能在毫秒内发现问题。TypeScript 是第一个获得 Codex linter 支持的语言，同时标准化了 oxlint（由 VoidZero 团队维护，该团队最近加入了 Cloudflare）以实现高性能的 linter 执行。Rust 项目的 linter 目前正在开发中，Go 最终将跟进，以覆盖 Cloudflare 最常用的语言。
- 为了从审查周期中消除持续集成（CI）环节，我们通过命令行界面（CLI）支持在本地运行 AI 代码审查器。它匹配 CI 中的协调器功能，并针对自动确定的差异集运行相同的（基于 OpenCode 的）代理，结果在终端中呈现。
我们相信 linter 对几乎每个开发者和代码库都有用，而 CLI 仍然是喜欢它的工程师的可选替代方案。
规范审查器
Cloudflare 的工程师在实施之前通常会撰写设计文档和技术规范（简称 specs）。Codex 中有很大一部分涉及设计、架构以及与技术评审相关的其他主题。为了在实施开始之前发现架构错误，我们构建了 规范审查器，这是一个能够发现规范并根据相关 Codex 要求对其进行评估的代理。
规范审查器在开发者平台上运行：它作为 Cloudflare Worker 运行，将其结果和状态存储在 D1 中，通过 AI Gateway 路由模型请求，并通过 Cron 触发器启动对新规范的扫描。它首先按与规范相关的领域和章节过滤 Codex（例如，忽略语言特性和面向实现的 RFC）。几个指导性提示指示模型如何运行评估并构建结果。发现的问题根据严重性（受 SHOULD 和 MUST 关键字影响）进行评级，并包含一般质量和架构建议。审查运行完成后，会在规范文档上留下一条注释，链接到可查看审查详细信息的自定义仪表板。
自 2026 年 5 月初以来，已审查了近 600 份独特的开放规范。包括按需或规范变更触发的重新运行，迄今为止我们跟踪了超过 3,200 次审查调用。绝大多数发现的问题严重性为“主要”（65%）或“次要”（29%），“严重”发现占少数（6%）。
下图展示了规范审查器 UI 的外观：
我们计划通过直接在规范文档上发布评论、嵌入可能影响审查评估的人机对话，以及标记高影响提案以供额外人工审查，来更紧密地集成规范审查器。
事件报告审查器
事件报告审查器 将相同的方法应用于事件报告（也称为事后分析）。除了检查每份报告是否完整外，它还评估报告是否清楚解释了发生的事情、识别了促成因素、记录了解决方案，并提出了有意义的后续行动。这些期望在专门的 Codex RFC 中定义。
事件报告审查器使用与规范审查器相同的开发者平台构建块。这种共享架构正成为我们 Codex 代理的常见模式。
自 2026 年 5 月以来，该审查器已评估了 200 多份事件报告，并识别出诸如缺少后续行动项、时间线不完整以及遗漏检测信号等差距。在这些报告中，93% 涵盖的事件是低影响、仅内部或预先声明的事件。对于高严重性事件，我们已将审查器作为我们全面中央审查流程的一部分强制执行，并且在所有发现的问题得到解决之前，报告不被视为完整。
未来工作
Codex 已经支持审查代码、技术设计和事件报告的代理。我们计划在整个 SDLC 中扩展该模型，使代理能够在设计、实施和运维中一致地发现问题。长期目标是让代理能够识别问题并以越来越高的自主性提出修复建议，而工程师仍负责审查和批准这些更改。
我们也在将 Codex 扩展到工程领域之外。产品、安全、合规以及信任与安全团队正在开始添加他们自己的标准，使代理能够针对超出设计和实现本身的考量来评估工作。
在许多工程工作流程中，由 Codex 支持的代理帮助我们更早地发现问题，并更一致地应用标准。我们发现，当 AI 在工作点将正确的指导带给工程师时最为有用，并计划继续在 Cloudflare 推广这种方法。
如果您有兴趣构建这样的系统，我们的
工程团队正在招聘。