过去四个月里，我们的 AI 代码审查器标记了近 25 万处偏离 Cloudflare 工程标准的情况（本文称之为“违规”），并拦截了 16,000 次合并。我们的规格审查智能体在实施开始之前，依据同样的标准评估了近 600 份技术设计。这两套系统都取材于 Cloudflare Codex，这是一套为人和智能体共同打造的、共享的工程指南来源。本文将说明我们为什么构建 Codex、它如何支撑工程生命周期，以及我们接下来的计划。
在有 Codex 之前（我们曾在之前一篇关于 AI 工程技术栈的文章中简要介绍过它），Cloudflare 的开发者指引散落在许多地方：正式文档、代码仓库中的文件、聊天记录，以及工程师个人积累的知识。工程师常常花太多时间去查找指引，而不是专注于要解决的问题。即便找到了答案，他们也未必能判断它是否是最新的、是否具有权威性、是否适用于自己的情况。
随着 Cloudflare 的成长，这种模式越来越难以维系。没有哪位工程师能读完每一条标准，审查者也无法可靠地检查每一项要求。人员在团队间流动时，机构知识更难找回；而指引如果没有被一致地呈现或执行，就会导致各项目之间出现偏差。
我们把这批知识重建为 Cloudflare Codex：一套受治理的工程标准，智能体可以在工作现场检索并应用。同样的指引现在可以用于代码审查、技术设计审查、事故报告审查以及许多其他场景，而工程师则把时间和判断力集中在由此产生的审查发现上。
Codex 的组织与工作流
专门的 Codex 治理模型把 Codex 划分为若干领域，涵盖我们关心的各个工程方向。这些方向包括架构类议题（例如前端和控制平面）、横切关注点（安全与可靠性）、特定语言（TypeScript 和 Rust）以及其他若干领域。每个领域由一位负责人主导，负责其所管辖文档的内容、一致性和整体质量。
Codex 标准采用征求意见稿（Request for Comments，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": "Control Plane Services",
"status": "approved",
"domain": "control-plane",
"statements": [
{
"slug": "use-quicksilver-for-edge-configuration-propagation",
"section": ["Proposal", "Infrastructure"],
"level": "SHOULD",
"text": "If you need to propagate system or customer configuration to the edge, use Quicksilver via the outbox pattern",
"href": "/rfcs/014-control-plane-services/#infrastructure"
},
{
"slug": "api-schemas-must-be-documented-in-openapi-spec",
"section": ["Proposal", "API Gateway"],
"level": "MUST",
"text": "API request and response schemas MUST be documented using an OpenAPI spec",
"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 代码审查器单次运行通常需要几分钟才能完成。尽管这段等待往往很值得花这些钱（或 token），工程师们还是指出了延迟，以及修复审查发现时多出来的一轮往返。我们研究了如何改善这一体验，并提出了两个额外的选项：
- 对于可以机械验证的、针对特定语言的 Codex 要求，我们提供自定义的 linter 配置包。它们与我们的 Codex 规范保持一致，能够在毫秒级内暴露问题。TypeScript 是第一个获得 Codex linter 支持的语言，同时我们也统一采用 oxlint（由最近加入 Cloudflare 的 VoidZero 团队维护）来获得高性能的 linter 执行。Rust 项目的 linter 目前正在开发中，Go 最终也会跟进，从而覆盖 Cloudflare 最常用的几种语言。
- 为了把持续集成（CI）环节从审查周期中去掉，我们让 AI 代码审查器可以通过命令行界面（CLI）在本地运行。它与 CI 中的协调器功能一致，针对自动确定的差异集运行同样的（基于 OpenCode 的）智能体，并在终端中呈现结果。
我们相信，几乎每位开发者和每个代码库都会觉得这些 linter 有用，而 CLI 仍是供偏好它的工程师选用的可选方案。
规格审查器
Cloudflare 的工程师在实施之前，经常编写设计文档和技术规格（简称规格，即 spec）。Codex 中有相当一部分内容涉及设计、架构以及与技术评审相关的其他主题。为了在实施开始之前发现架构错误，我们构建了规格审查器，这是一个能发现规格文档并依据相关 Codex 要求对其进行评估的智能体。
规格审查器运行在开发者平台上：它以 Cloudflare Worker 的形式运行，将结果和状态存储在 D1 中，通过 AI Gateway 路由模型请求，并通过 Cron Trigger 启动对新规格的扫描。它首先按与规格相关的领域和章节筛选 Codex（例如，语言特性和侧重实现的 RFC 会被忽略）。若干引导性提示词告诉模型如何进行评估以及如何组织结果。审查发现会按严重程度评级（受 SHOULD 和 MUST 关键字影响），并包含通用质量和架构方面的建议。审查运行完成后，会在规格文档上留下一条备注，链接到一个自定义仪表盘，可在其中查看审查详情。
自 2026 年 5 月初以来，已审查了近 600 份不重复的开放规格。算上按需触发或因规格变更而触发的重新运行，截至目前我们共记录了 3,200 多次审查调用。绝大多数审查发现的严重程度为“major”（65%）或“minor”（29%），“critical”级别的发现占少数（6%）。
下图展示了规格审查器界面的大致样子：
我们计划更紧密地集成规格审查器：直接在规格文档上发表评论，嵌入可影响审查评估的人机对话，并将影响重大的提案标记出来，交由人工进一步审查。
事故报告审查器
事故报告审查器把同样的方法用于事故报告（也称复盘，postmortem）。除了检查每份报告是否完整，它还会评估报告是否清楚说明了发生了什么、是否找出了促成因素、是否记录了解决过程，以及是否提出了有意义的后续行动。这些期望都定义在一份专门的 Codex RFC 中。
事故报告审查器使用与规格审查器相同的开发者平台构件。这种共享架构正在成为我们 Codex 智能体的通用模式。
自 2026 年 5 月以来，该审查器已评估了 200 多份事故报告，并发现了缺少后续行动项、时间线不完整、遗漏检测信号等缺口。这些报告中，93% 涉及的事故是低影响的、仅限内部的，或是预防性宣告的。对于高严重性事故，我们已将该审查器设为全面集中审查流程中的必经环节，在所有发现都得到处理之前，报告不会被视为完成。
未来工作
Codex 已经支持审查代码、技术设计和事故报告的智能体。我们计划把这一模式扩展到整个 SDLC，让智能体能在设计、实现和运维各阶段一致地发现问题。更长远的目标是，智能体在发现问题的同时，能以越来越高的自主性提出修复方案，而工程师仍负责审查并批准这些变更。
我们也在把 Codex 扩展到工程之外。产品、安全、合规以及信任与安全团队开始加入他们自己的标准，使智能体能够依据不仅限于设计和实现的各类考量来评估工作。
在多个工程工作流中，由 Codex 支撑的智能体帮助我们更早发现问题，并更一致地应用标准。我们发现，当 AI 在工作现场把恰当的指引送到工程师面前时最为有用，我们也计划在 Cloudflare 内继续推广这一做法。
如果你有兴趣构建这类系统，我们的工程团队正在招聘。