Cloudflare 如何用 AI 执行工程标准
背景：工程规范分散带来的问题
过去四个月，Cloudflare 的 AI 代码评审器标记了近 25 万个偏离工程标准的情况，并阻止了 16,000 次合并。其技术方案评审 Agent 也在实现开始前，依据同一套标准评审了接近 600 份技术设计。
这些系统背后依赖的是 Cloudflare Codex：一套面向人类工程师和 AI Agent 的共享工程规范体系。
在 Codex 之前，Cloudflare 的开发指导分散在正式文档、仓库文件、聊天记录以及个人经验中。工程师常常需要花时间寻找规范，即便找到了，也不一定能判断这些内容是否仍然有效、权威，或适用于当前场景。
随着组织规模扩大，这种模式越来越难以维持：
- 没有工程师能读完所有标准；
- 评审者也无法可靠检查每一项要求；
- 人员流动会导致机构知识难以传承；
- 规范如果不能被持续暴露和执行，不同项目之间就会逐渐出现偏差。
Cloudflare 因此将这套知识重建为 Codex：一组受治理的工程标准，Agent 可以在工作发生的具体环节检索并应用它们。
Codex 的组织方式
Codex 被划分为多个领域，覆盖 Cloudflare 关注的工程主题，包括：
- 架构相关领域，例如前端、控制平面；
- 跨领域关注点，例如安全性、可靠性；
- 具体编程语言，例如 TypeScript、Rust；
- 其他工程实践领域。
每个领域由一名负责人维护，负责相关文档的内容、统一性和整体质量。
Codex 的标准采用 RFC 格式。要求使用 RFC 2119 中定义的 SHOULD 和 MUST 关键词。每份 RFC 还需要包含前置信息，用来记录领域、RFC 状态等元数据。
具备相关兴趣和领域能力的员工可以通过合并请求提交 RFC 提案。提案会经过多轮反馈，并由越来越广泛的评审者参与审阅。领域负责人最终批准后，RFC 会成为 Codex 的一部分，并发布到内部站点。
从“批准”到“强制执行”
Codex 中的 RFC 获批后，相关客户端和 Agent 就可以立即消费这些标准，并在代码、配置或文档中标记违反规范的情况。
但系统不会马上基于这些标准进行阻断。只有当 RFC 从 approved 状态进一步提升到 enforced 状态后，Agent 才会依据其中的要求执行阻断。
这种分阶段机制给团队留下了吸收新要求的时间，也适应了某些标准在强制执行前还需要额外工程支持的情况。
为什么不直接把全部规范塞给大模型
一种简单做法是把整个 Codex 原样提供给大语言模型。但 Cloudflare 已经积累了 60 多份 RFC，且数量还在增长。直接把所有内容放进上下文窗口，会对模型上下文容量造成压力，并影响结果质量。
为此，Cloudflare 使用专门的 Agent 自动提取并压缩 RFC 中的 SHOULD 和 MUST 语句，将其整理成专门的 JSON 结构，并补充元数据，以支持懒加载发现和渐进式披露。
每条规范语句都会获得一个稳定的 slug 标识符。即便对应 RFC 更新，标识符也会保持不变。这让同一条规范可以跨系统长期追踪，有助于监控、分析和例外处理。
Cloudflare 最初曾把这些语句提取为更简洁的 Markdown 文件，后来迁移到更丰富的结构化格式，使 Agent 能更准确地筛选所需内容。后续计划还包括加入更多元数据，例如某条规范适用于软件开发生命周期中的哪个阶段：设计、实现或运行时。
Codex 的三个主要使用场景
Cloudflare 已经在日常工程流程中使用 Codex。文中重点介绍了三个 Agent：AI 代码评审器、技术方案评审器和事故报告评审器。
1. AI 代码评审器
AI 代码评审器会从多个维度评估合并请求，其中包括是否符合 Codex。
每次评审时，Agent 会检索相关 RFC，并解析 Codex 中的规范语句。只有当模型或协调器需要更多上下文时，才会加载完整 RFC 正文。多数情况下，提取出的规范语句已经足以解释发现的问题。
SHOULD、MUST 的区别，以及 RFC 当前状态，会决定评审器如何响应：
- 来自已批准 RFC 的发现是非阻断建议；
- 当 RFC 已进入强制执行状态时，未满足的
MUST要求会导致评审器拒绝批准，或根据严重程度阻止合并。
自 Codex 启用以来，AI 代码评审器已经标记接近 230,000 个违规情况。其中近 16,000 个导致审批被保留，这些问题对应的是已强制执行 RFC 中的 MUST 语句。
2. 代码评审的补充方式
一次 AI 代码评审通常需要几分钟，因为它涉及协调器框架和多个子 Agent 执行。虽然这种等待通常有价值，但工程师也反馈了延迟和修复反馈周期变长的问题。
Cloudflare 因此增加了两种补充方式：
-
自定义 linter 配置包
对于可以机械化验证的语言级 Codex 要求，Cloudflare 提供与 Codex 规范对齐的自定义 linter 配置包，让问题可以在毫秒级暴露。TypeScript 是首个获得 Codex linter 支持的语言，并标准化使用 oxlint。Rust 项目的 linter 正在开发中，Go 也计划随后支持，以覆盖 Cloudflare 最常用的语言。 -
本地 CLI 运行 AI 代码评审器
为减少 CI 环节带来的等待，Cloudflare 支持通过命令行在本地运行 AI 代码评审器。该工具匹配 CI 中的协调器功能，基于自动确定的 diff 集合运行同样的 Agent，并在终端中展示结果。
Cloudflare 认为 linter 对几乎所有开发者和代码库都有帮助，而 CLI 更适合偏好本地工作流的工程师。
3. 技术方案评审器
Cloudflare 工程师在实现前通常会撰写设计文档和技术规格。Codex 中有相当一部分内容与设计、架构和技术评审相关。为了在实现开始前发现架构问题，Cloudflare 构建了技术方案评审器。
该 Agent 会发现技术规格文档，并根据相关 Codex 要求进行评估。
其运行在 Cloudflare Developer Platform 上：
- 使用 Cloudflare Worker 执行；
- 使用 D1 存储结果和状态；
- 通过 AI Gateway 路由模型请求；
- 通过 Cron Trigger 扫描新的技术规格。
评审器会先按与技术规格相关的领域和章节过滤 Codex，例如排除语言特性和偏实现层面的 RFC。随后，多个提示词会指导模型如何评估并组织结果。
评审发现会按严重程度评级，评级受到 SHOULD 和 MUST 关键词影响，同时也包括通用质量建议和架构建议。评审完成后，系统会在规格文档中留下备注，并链接到自定义仪表盘以查看详情。
自 2026 年 5 月初以来，接近 600 份唯一的开放技术规格被评审。包括按需触发或因文档变更触发的重复评审在内，Cloudflare 跟踪到超过 3,200 次评审调用。绝大多数发现为“major”（65%）或“minor”（29%），而“critical”占少数（6%）。
Cloudflare 计划进一步集成技术方案评审器，例如直接在规格文档上发表评论、嵌入人与 Agent 的对话以影响评估，以及将高影响提案标记给人工进行额外评审。
4. 事故报告评审器
事故报告评审器将同样的方法应用于事故报告，也就是 postmortem。
除了检查报告是否完整，它还会评估报告是否清楚解释了发生了什么、识别了促成因素、记录了解决方案，并提出有意义的后续行动。这些期望由一份专门的 Codex RFC 定义。
事故报告评审器使用与技术方案评审器相同的 Developer Platform 构建模块。这种共享架构正在成为 Cloudflare Codex Agent 的常见模式。
自 2026 年 5 月以来，该评审器已经评估了 200 多份事故报告，并发现了一些缺口，例如：
- 缺少后续行动项；
- 时间线不完整；
- 遗漏检测信号。
在这些报告中，93% 涉及低影响、仅内部影响或预防性声明的事故。对于高严重级别事故，Cloudflare 已将该评审器作为集中审查流程中的强制环节；所有发现被处理前，报告不会被视为完成。
后续方向
Codex 已经支持代码、技术设计和事故报告的 Agent 评审。Cloudflare 计划将这种模式扩展到整个软件开发生命周期，让 Agent 在设计、实现和运营阶段持续、一致地暴露问题。
更长期的目标是让 Agent 不仅识别问题，也能以越来越高的自主性提出修复方案。不过，工程师仍然负责审查和批准这些变更。
Cloudflare 还在将 Codex 扩展到工程以外的领域。产品、安全、合规、信任与安全等团队开始加入自己的标准，使 Agent 能够根据超出设计和实现范围的要求来评估工作。