Codex 按域划分，每个域有一个负责人

Codex 是一套有人治理的工程规范集合，Agent 可以在需要的时候取出来、用在当下这件事上。同一份规范，现在能同时喂给代码审查、技术设计审查、事故报告审查这些场景。

它按域切开，每个域覆盖一块工程领域：架构类的（比如前端、控制平面）、横切各处的（安全、可靠性）、具体语言的（TypeScript、Rust），还有其他若干块。每个域有一个域主，对自己那批文档的内容、一致性和整体质量负责。

规矩怎么写：RFC 格式，用 SHOULD 和 MUST 分轻重

Codex 的规范用 RFC 格式写。RFC 是从互联网标准圈来的一种写法：一份提案公开征求意见、多轮修改、最后定稿成为大家遵守的东西。

要求只用两个关键词：SHOULD 和 MUST，定义直接沿用 RFC 2119，这是一份真实存在的互联网标准文档，专门规定这几个词在技术规范里的严格含义。

文档开头还要有一段 front matter 元信息，就是最前面一小段用来描述这份文档本身的内容，写清它属于哪个域、当前是什么状态，这段是给机器读的。

谁能提规矩？任何一个有兴趣、在这个领域有能力的 Cloudflare 员工，都可以按规定的结构提一个 merge request。提案要过好几轮反馈，参与评审的人越来越多，最后由域主拍板批准，这份 RFC 才进 Codex，并发布到一个用 Astro 搭的内部站点上。

规范从提案到能拦下代码合并的五个步骤

规矩写好了不等于就能拦人。从一份提案到真的能挡住别人的代码，中间有五步。

Cloudflare 官方工作流图。五个阶段从左到右：撰写、自动检查、治理、已批准、已强制。图的副标题点出了这套设计的关键，「RFC 和它的机器可读规则走同一个评审流程」。来源：blog.cloudflare.com。

为什么要多加「显式提升」这一步

Cloudflare 给的理由有两条，都很实在：一是给团队时间去消化新要求；二是有些情况下，「让它真能拦住」这件事本身还需要额外的工程工作。

还有一处值得单独拎出来。工作流图的副标题写着「RFC 和它的机器可读规则走同一个评审流程」，人读的那份文档和机器读的那份 JSON，是一起写、一起审、一起合入的。这样两者就不会各自漂移：不会出现文档改了但机器规则还是老的，也不会出现机器在按一条谁都没审过的规矩拦人。

60 多份规范怎么压缩成模型读得进的 JSON

Cloudflare 已经有 60 多份 RFC，而且还在涨。一个偷懒的做法是把整个 Codex 原样喂给大模型，但他们明确写了这样做的后果：这个体量会给上下文窗口很大压力，还会拖坏模型的输出质量。

他们的解法是派一个专门的 Agent，自动把 SHOULD 和 MUST 语句抽出来，压缩成一个专用的 JSON 结构，再加上一批支持「懒发现」和渐进披露的元数据。

抽出来的东西长这样（JSON 是一种给机器读的数据格式，用大括号和字段名把信息一条条列清楚）：

{
  "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 更新时这个标识符不变。

为什么这件事重要？因为同一条规矩会被好几个系统引用，代码审查器报了它、监控在统计它触发了多少次、某个团队申请了针对它的例外。如果规矩的编号跟着文档改动漂来漂去，这些引用就全断了。有了稳定 slug，同一条规矩才能跨系统、跨时间被追踪。

还有一段演进值得记下来：他们一开始抽出来的是一个更简洁的 Markdown 文件，后来才改成结构更丰富的 JSON。换的原因是 Agent 需要更精确地过滤自己要用的内容。接下来还打算加更多元数据，比如标注这条规矩适用于软件生命周期的哪个阶段，设计、实现，还是运行时。

三个 Agent 用同一份 Codex：审代码、审设计、审事故报告

规矩变成数据之后，能吃它的地方就多了。目前有三个 Agent 在日常工作里用 Codex。

一、AI 代码审查器

每次审查，它先取回 RFC、解析出 Codex statements，只有在模型或协调器需要更多上下文时，才去加载完整的 RFC 正文。大多数情况下，光是那些 statements 就够解释清楚一处违规了。

它怎么反应，由两件事共同决定：这条要求是 SHOULD 还是 MUST，以及这份 RFC 处在什么状态。

数据：Codex 建立以来，AI 代码审查器标出了接近 23 万处违规，其中将近 1.6 万处导致批准被扣住，也就是撞上了已强制 RFC 的 MUST 条款。

二、spec 审查器：在写代码之前抓架构错误

Cloudflare 的工程师在动手实现之前会写设计文档和技术规格，简称 spec，就是方案书：打算怎么做、为什么这么做、有哪些取舍。Codex 里有相当一部分内容正是关于设计和架构的。

spec 审查器会自己去发现新的 spec，然后拿相关的 Codex 要求去评估它。它跑在什么上面挺有意思，全是 Cloudflare 卖给客户的那些产品：

流程是这样：先按域和章节过滤 Codex，只留跟设计相关的（比如讲语言特性、偏实现细节的 RFC 就不看了）；几段引导提示词告诉模型怎么做评估、怎么组织结果；报出来的问题按严重程度打分，分数受 SHOULD 和 MUST 影响，同时还会给一般性的质量和架构建议。跑完在 spec 文档上留一条备注，链到一个自定义看板去看细节。

spec 审查器的界面。顶部一排筛选器：最近评审时间（7 天／30 天／90 天）、严重程度（Critical+／Major+／全部）、搜索、团队、是否已解决。被评审的这份 spec 叫「Temporal Resiliency for Platform Workflow Automation」，编号 RM-24741，标着「1 处违规 / 4 条笔记」，最后评审时间 2026 年 7 月 25 日。意见分两大块，架构笔记（再分 ARCHITECTURE / SCALE / OPEN QUESTIONS 三档）和 Codex 违规。来源：blog.cloudflare.com。

这张截图值得多看两眼，因为它回答了一个关键问题：Agent 报出来的意见到底有多具体。

那条标红的 critical 架构意见说：这份 spec 没有定义多集群部署下的命名空间策略，然后列了四个具体该补的问题，命名空间是在两个集群之间复制、还是各集群独有；某个命名空间里的工作流能不能在两个集群都跑；故障切换时命名空间的隔离怎么维持；两地同名的命名空间，是同一个逻辑命名空间还是各自独立的。最后点明这会影响工作流隔离、多租户和故障切换行为。

下面那条 Codex 违规挂在 RFC-013「依赖故障行为未定义」上，MAJOR 级：这份 spec 说 worker 可以在两个集群之间故障转移，但没定义集群故障时的架构行为，缺的五点是，worker 在自己那个集群不可用时是 fail-open 还是 fail-closed；什么触发切换（自动还是手动）；worker 怎么发现并连上备用集群；切换对运行中的工作流是否透明、还是需要重启；集群不可用时飞行中的工作流会怎样。它还引用了文档页评论里同事提出的复制延迟担忧，作为「这里确实需要明确的故障模式设计决策」的佐证。

每条意见右侧还有「Recurring」标签（这个问题反复出现过）和「Feedback」按钮。

接下来他们打算把 spec 审查器接得更紧：把意见直接评论到 spec 文档上、把人和 Agent 的对话嵌进去让它能反过来影响评审结论、把高影响的提案标出来交给人额外审一遍。

三、事故报告审查器

同一套路数用在事故报告上（也叫复盘报告，postmortem，线上出事之后写的那份：发生了什么、为什么会发生、怎么解决的、以后怎么防）。

除了检查报告完不完整，它还评估这份报告有没有讲清楚发生了什么、有没有指出促成因素、有没有记录解决过程、有没有提出有意义的后续行动。这些期望写在一份专门的 Codex RFC 里，连「一份合格的事故报告长什么样」本身，都变成了一条可以被机器检查的规矩。

它用的是跟 spec 审查器同一批开发者平台组件，这个共享架构正在成为 Codex 系 Agent 的通用模式。

2026 年 5 月以来，它评估了 200 多份事故报告，找出的缺口包括漏掉的后续行动项、不完整的时间线、遗漏的检测信号。这些报告里 93% 覆盖的是低影响、仅限内部或者预防性声明的事故。对高严重度事故，走这个审查器是强制的，属于中央审查流程的一部分，所有问题处理完之前，报告不算完成。

另外两条更快的检查路径：linter 和本地命令行

跑起来之后，工程师开始抱怨慢。

一次完整的 AI 代码审查通常要几分钟，因为中间有协调器框架和子 Agent 在跑。Cloudflare 在这里写得很坦率：这笔钱（或者说 token）常常花得值，但工程师确实在反映两件事，一是等待的延迟，二是改完问题还得再跑一轮的来回成本。

于是他们补了两条路。

Cloudflare 接下来的计划，和几处对不上的数字

他们给的路线图有三条：

几处我核出来的口径问题

三处，都不影响主线，但引用数字时值得知道：

一句来自他们自己的总结

Cloudflare 在另一篇讲内部 AI 工程栈的博文里，有一段话，分量比上面任何一个数字都重：

这些零件单拿出来都不算新鲜。很多公司都有服务目录、都发过审查机器人、都发布过工程规范。区别在于接线方式。

Cloudflare《我们的内部 AI 工程栈》，本站译

同一篇还给了整套体系的采纳数据：从启动这件事到研发团队 93% 采纳，用了不到一年；2026 年 2 月 5 日到 4 月 15 日期间，活跃用户 3683 人，占公司 60%。

对开发和技术管理的三条启示

把这套东西拆完，有三条经验是脱离 Cloudflare 这个具体场景也成立的。

Codex 按域切开（前端、控制平面、安全、可靠性、TypeScript、Rust……），每个域有一位域主负责内容和质量。规矩用 RFC 格式写，要求只用两个词：MUST 是必须做到，SHOULD 是应该做到、有正当理由可以不做，定义直接沿用 RFC 2119，一份真实存在的互联网标准文档。

规模是下一堵墙：已经有 60 多份 RFC 还在涨，整份喂给模型会把上下文（模型一次能读进去的量）撑满，输出质量跟着掉。他们的解法是派一个 Agent 把这些语句抽出来压成 JSON。

规矩写好了不等于能拦人。从一份提案到真的挡住别人的代码，中间五步；人读的那份文档和机器读的那份 JSON 全程一起走，一起写、一起审、一起合入，所以两边不会各自漂移。

同一份 Codex 现在喂给三个 Agent，分别盯代码、设计文档和事故报告。

跑起来之后工程师抱怨慢，于是同一条规矩多了两条更快的查法。

四个月，三个 Agent 跑出来的量。

以上数字均出自 Cloudflare 官方博客自述，没有第三方核验。