信息技术 / 云基础设施
Cloudflare：依据内部标准用AI评审代码和设计文档
- 企业
- Cloudflare
- 国家
- 美国
- 实施阶段
- 运营中
- 资料发布
- 日期依据
- 资料发布的时间，可能与启用日期不同。
- 依据核验方式
- 阅读原文正文
业务问题
Cloudflare把工程标准作为一组名为Codex的RFC来管理。要求用RFC 2119定义的SHOULD和MUST关键字书写。原文表示，现有RFC已超过60个并持续增加，若把整个Codex原样送入大语言模型，会给上下文窗口带来很大压力并损害结果。由人工在所有merge request和设计文档中找出全部标准违规，也因数量太大而困难。
使用的技术与数据
该公司没有整体送入Codex，而是构建了只挑选与评审对象相关的RFC的结构。AI代码评审读取merge request并标出标准违规，已批准RFC的问题只作提示而不阻拦，强制执行的RFC中的MUST违规则会导致暂缓批准。TypeScript最先获得Codex linter支持，并为执行速度统一到oxlint。Rust正在开发中，Go随后。设计文档评审运行在Developer Platform上。它作为Cloudflare Worker运行，把结果和状态保存在D1中，通过AI Gateway转发模型请求，并借助Cron Trigger启动对新文档的扫描。事故报告评审查找后续行动项缺失、时间线不完整、检测信号遗漏等不足。开发者还可以在基于OpenCode的工具中通过CLI在自己的环境运行同样的评审。
成果
该公司表示，自今年初启动Codex以来，AI代码评审已标出近23万条标准违规，其中近1.6万条导致暂缓批准。该公司说明，设计文档评审自2026年5月初以来评审了近600份不同的公开设计文档，若计入因文档变更或按需触发的重跑，评审执行次数超过3,200次。该公司表示，问题的严重程度中major占65%、minor占29%，critical最少，占6%。该公司表示，事故报告评审自2026年5月以来查看了200多份报告，其中93%涉及影响较小、仅限内部或提前声明的事故。
局限与待解问题
原文给出了标出的违规数量和暂缓批准的数量，但没有给出误报比例或开发者接受问题的比例。也没有给出引入评审工具后事故数量变化的数据。
来源
- How Cloudflare enforces engineering standards using AIblog.cloudflare.com, 查阅
本案例根据公开资料整理，并非 ATF Works 客户的成果。