mylogs.cn

规范没人读，AI 一口气揪出 23 万处违规

2026 年 8 月 5 日

发布于

过去四个月，Cloudflare 的 AI 代码审查器标记了近 23 万处不符合公司工程规范的写法，其中近 1.6 万处严重到直接拦下了合并请求。另一个专门审设计文档的智能体，则在代码动工之前评估了将近 600 份技术方案。

支撑这两套系统的是同一样东西：Cloudflare Codex——一套同时写给人和智能体看的工程规范。

问题不是没规范，是规范找不着

在 Codex 之前，Cloudflare 的开发指引散落在各处：正式文档、代码仓库里的说明文件、聊天记录，以及资深工程师脑子里的经验。工程师花在找规矩上的时间，常常超过花在解决问题上的时间。更糟的是，就算翻到了某条说法，也未必能判断它是否还有效、是否权威、是否适用于眼下的情况。

公司规模越大，这套模式越撑不住。没有哪个工程师能读完所有规范，评审者也不可能逐条核对每项要求。人员在团队之间流动，沉淀下来的经验越来越难被找回，而那些没被持续提示和执行的指引，最终导致各个项目各行其是。

Cloudflare 的做法是把这些知识重建成 Codex：一套有治理机制的工程规范，智能体可以在工程师干活的当下，把相关条款调取出来并应用。

规范怎么写，又怎么生效

Codex 按领域切分，涵盖架构类（例如前端、控制平面）、横切关注点（安全、可靠性）、具体语言（TypeScript、Rust）等方向，每个领域设一名负责人，对内容、一致性和整体质量负责。

规范采用 RFC（征求意见稿）格式撰写，要求用 RFC 2119 定义的 SHOULD（建议）与 MUST（必须）关键字表述，并在文件头部保留领域、状态等元数据。任何员工只要对某个领域有兴趣和相应能力，都可以按规定结构提交合并请求发起一份 RFC，经过多轮逐步扩大范围的评审，最后由领域负责人拍板，纳入 Codex 并发布到内部站点。

关键设计在于两段式生效。RFC 进入「已批准」状态后，智能体就会开始标记违规，但只提示、不拦截；只有当它被显式提升到「已强制」状态，MUST 类要求才真正具备拦下合并的效力。这个额外的推进步骤给了团队消化新要求的时间，也照顾了那些在执行层面还需要额外准备的情况。

还有一个绕不开的工程问题：Codex 已经积累了 60 多份 RFC 且仍在增加，如果原封不动全部喂给大模型，光是语料体量就会挤爆上下文窗口，反而拉低输出质量。Cloudflare 的解法是用一个专门的智能体，自动把所有 SHOULD 和 MUST 语句抽取压缩成 JSON 结构，并附上支持惰性发现和渐进披露的元数据。每条语句都有一个稳定的标识符，即便所属 RFC 被修订也不会变化——这让同一条要求能够在不同系统间被长期追踪，对监控、分析和例外处理都是必需的。团队最初把语句抽成更简洁的 Markdown 文件，后来才换成结构化程度更高的 JSON，好让智能体能更精准地筛选自己需要的内容。

三个正在用它的地方

目前有三个智能体在日常工作中消费 Codex。

第一个是 AI 代码审查器。它从多个维度评估合并请求，Codex 合规性是其中之一。每次审查时，它先取出相关 RFC 并解析其中的语句，只有在模型或协调器需要更多上下文时才加载 RFC 全文——多数情况下，抽取出的语句已足够解释一处违规。SHOULD 与 MUST 的区别加上 RFC 的状态，共同决定审查器的反应：来自「已批准」RFC 的发现只是不阻塞的建议；一旦 RFC 进入「已强制」状态，未满足的 MUST 要求会让审查器拒绝批准或直接拦下合并，具体取决于严重程度。自今年年初 Codex 建立以来，这个审查器累计标记了近 23 万处违规，其中近 1.6 万处导致合并未获批准。

它也有明显的体验短板：受协调器框架和子智能体执行的拖累，跑完一轮通常要几分钟，工程师抱怨等待时间和返工带来的额外往返。Cloudflare 为此补了两条路。对那些可以机械校验的语言类要求，提供与 Codex 规范对齐的定制 linter（静态检查工具）配置包，毫秒级出结果；TypeScript 率先支持，并统一使用 oxlint——其维护团队 VoidZero 近期已加入 Cloudflare，Rust 版本正在开发，Go 随后跟进。此外，AI 代码审查器现在也可以通过命令行在本地运行，功能与持续集成环境中的协调器一致，结果直接打在终端里。

第二个是设计文档审查器，面向工程师在动手前撰写的技术方案。它跑在 Cloudflare Worker 上，结果和状态存进 D1 数据库，模型请求走 AI Gateway，由定时触发器发起扫描。运行时它先按领域和章节过滤 Codex，把语言特性、实现细节一类与设计无关的 RFC 排除在外，再依据严重程度对发现分级。自 2026 年 5 月初以来，它已审查近 600 份独立的开放设计文档，算上按需重跑和文档变更触发的重跑，累计调用超过 3200 次。绝大多数发现属于「重要」（65%）或「次要」（29%）级别，「严重」级别只占 6%。

第三个是事故报告审查器，把同一套方法用在事故复盘上。除了检查报告是否完整，它还评估报告有没有讲清楚发生了什么、有没有识别出促成因素、有没有记录处置过程、有没有提出有意义的后续行动项。自 2026 年 5 月以来，它已评估 200 多份事故报告，指出过遗漏后续行动项、时间线不完整、漏记检测信号等问题。这些报告中有 93% 对应的是低影响、仅限内部或预防性声明的事故；对于高危事故，这道审查已被设为强制流程的一部分，所有发现被处理完毕之前，报告不算完成。