Cloudflare 如何通过人工智能执行工程标准
在过去的四个月里，我们的 [AI 代码审查工具](https://blog.cloudflare.com/ai-code-review/) 标记了近25万次违反 Cloudflare 工程标准（在本文中我们将称这些为“违规”），并阻止了 16,000 次合并请求。我们的规范审查代理在实施开始前已经评估了近 600 个技术设计，确保它们符合相同标准。这两个系统都基于 Cloudflare Codex，这是为人员和代理构建的共享工程指导来源。本文将阐述我们为何构建 Codex，它如何支持工程生命周期，以及我们的下一步计划。
在 Codex 之前（我们在 [之前的文章](https://blog.cloudflare.com/internal-ai-engineering-stack/) 中简要介绍了我们的 AI 工程堆栈），Cloudflare 的开发者指导散落在很多地方：正式文档、代码库文件、聊天记录，以及各个工程师的积累知识。工程师们常常花费太多时间去寻找指导，而不是专注于他们要解决的问题。即使找到了解答，他们也不总能判断该信息是否最新、权威或适用于他们的具体情境。
随着 Cloudflare 的发展，这种模式越来越难以维持。没有一位工程师能够阅读所有标准，而审查人员也无法可靠地检查每一个要求。随着人员在团队之间流动，机构知识变得越来越难以恢复，而未能始终如一地显现或得以执行的指导导致了项目之间的偏差。
我们将这些知识重新构建为 Cloudflare Codex：一套治理的工程标准，代理可以在工作时提取和应用。现在，这些指导能在代码审查、技术设计审查、事件报告审查等多个用例中提供支持，让工程师专注于得到的发现。
## Codex 组织和工作流程
一个专门的 Codex 治理模型将 Codex 划分为不同领域，涵盖我们关心的工程领域。这些领域包括架构事务（例如，前端和控制平面）、跨领域关注点（安全性和可靠性）、特定语言（TypeScript 和 Rust）以及其他几个领域。每个领域都有一个负责人，负责他们所监督的文档的内容、一致性和总体质量。
Codex 标准使用请求评审（RFC）格式。要求使用定义在 [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) 中的 SHOULD 和 MUST 关键字。我们还期望会有一个前置头部用于包含诸如领域和 RFC 状态等元数据。任何对该领域有关键兴趣和能力的 Cloudflare 员工都可以通过遵循规定结构的合并请求提出 RFC。然后，该提案需经过几轮反馈，来自日益广泛的审查人员组。最终，经过领域负责人批准后，RFC成为 Codex 的一部分并在一个 [Astro](https://astro.build/) 支持的内部网站上发布。
经过批准的 RFC 可以被 Codex 客户和代理使用，后者可以立即开始标记代码、配置或文档中的 Codex 违规行为。然而，它们仅在 RFC 从 approved 状态变为 enforced 时，才会基于 Codex 声明进行封锁。这一独立的晋升步骤为团队提供了时间来吸收新要求，并适应那些需要额外工作的强制情况。
以下图表展示了 Codex 工作流程中的步骤：
一个简单的过程可能会在此处结束，并将整个 Codex 像原样那样提供给大型语言模型（LLM）。然而，考虑到我们已经拥有的 RFC 数量（超过60个且仍在增加），这样的语料量会给上下文窗口带来极大压力，并对 LLM 的结果产生负面影响。为帮助模型引导到最相关的 RFC，我们调用了一个专门构建的代理，自动提取并压缩 SHOULD 和 MUST 语句为专用 JSON 结构，并使用支持懒惰发现和渐进披露的元数据进行增强。以下是我们控制平面服务 RFC 的结果的节选：
每个声明都获得一个稳定的 slug 标识符，即使在提取过程中其 RFC 被更新，该标识符也保持不变。此标识符使我们能够在不同系统之间跟踪相同的声明，这对于监测、分析和例外处理至关重要。
最初，我们将声明提取到另一个更简洁的 Markdown 文件中，而非 JSON。随着时间的推移，我们转向了一种更丰富的结构化格式，以便代理能够更准确地过滤所需内容。我们计划包括额外的元数据以实现更紧密的范围限制，例如指示声明适用的软件开发生命周期（SDLC）阶段（例如，设计、实施、运行时）。
## Codex 消费者
几个系统已经在日常的工程工作中使用 Codex。有三个代理展示了 Codex 在实践中的运作：我们的 AI 代码审查工具、规范审查工具，以及事件报告审查工具。
### AI 代码审查工具
我们的 AI 代码审查代理在 [一篇独立的博客文章](https://blog.cloudflare.com/ai-code-review/) 中进行了详细介绍，它从多个维度评估合并请求，包括 Codex 合规性。
对于每次审查，该代理都会检索 RFC 并解析 Codex 声明。仅在模型或协调员需要额外上下文时，它才会加载完整的 RFC 主体。在大多数情况下，这些声明提供了足够的信息来解释报告的违规行为。
SHOULD 和 MUST 之间的区别，加上 RFC 的状态，决定了审查者的响应方式。来自被批准的 RFC 的发现是非阻塞性建议。一旦 RFC 被强制执行，未满足的 MUST 要求会导致审查者拒绝批准或阻止合并请求，具体取决于严重性。
自今年年初 Codex 建立以来，AI 代码审查工具已经标记了近 230,000 次违规。其中，几乎 16,000 次导致批准被拒绝（即，它们涉及强制性 RFC 中的 MUST 声明）。
### 代码审查替代方案
一次 AI 代码审查通常需要几分钟才能完成，原因在于协调员框架和子代理执行。尽管等待通常很值得（无论是金钱还是代币），但工程师们对延迟和额外的整改轮次表达了不满。我们探索了如何改善这一体验，并提出了两个额外的选项：
1. 对于可以机械验证的语言特定 Codex 要求，我们提供自定义的 linting 配置包。这些与我们的 Codex 规范对齐，并使问题能够在数毫秒内被提出。TypeScript 是第一个获得 Codex linter 支持的语言，同时也标准化使用由 [VoidZero 团队](https://blog.cloudflare.com/voidzero-joins-cloudflare/) 维护的 oxlint 进行高效的 linting 执行。Rust 项目的 linter 当前在开发中，Go 语言也将在未来跟进，以完成 Cloudflare 最常用语言的覆盖。
2. 为了削减审查周期中的持续集成（CI）环节，我们使得可以通过命令行接口（CLI）在本地运行 AI 代码审查工具。它匹配 CI 的协调员功能，并在自动确定的 diff 集上运行相同的 （[OpenCode](https://opencode.ai/) 为基础）代理，结果在终端呈现。
我们认为 linting 工具对几乎每个开发者和代码库都会有帮助，而 CLI 对于那些青睐它的工程师则仍然是可选的替代方案。
### 规范审查工具
Cloudflare 的工程师们常常在实施之前撰写设计文档和技术规范（简称为<em>specs</em>）。Codex 的一个重要子集涉及设计、架构和与技术审查相关的其他主题。为了在实施开始之前捕捉架构错误，我们构建了<em>规范审查工具</em>，一个发现规范并根据相关的 Codex 要求进行评估的代理。
规范审查工具运行在开发者平台上：它作为一个 Cloudflare Worker 执行，将其结果和状态存储在 D1 中，通过 AI 网关路由模型请求，并通过 Cron 触发器启动对新规范的扫描。它首先根据涉及规范的领域和部分过滤 Codex（例如，语言特征和以实施为中心的 RFC 将被忽略）。有几个指导提示指示模型如何进行评估并构建结果。发现根据严重性进行评级（受 SHOULD 和 MUST 关键字的影响），并包含一般质量和架构建议。在每次审查完成后，会在规范文档中留下一个链接到自定义仪表板的备注，审查详情可以在此查看。
自 2026 年 5 月以来，几乎 600 个不同的开放规范已被审查。包括根据需求或规范变更触发的重新审查，我们迄今跟踪了超过 3,200 次审查调用。绝大多数发现的严重性为 “重大”（65%）或“轻微”（29%），而“关键”发现则占少数（6%）。
以下图像展示了规范审查工具用户界面的样子：
我们计划通过直接在规范文档上发布评论、嵌入可以影响审查评估的人工-代理对话，以及标记高影响提案以进行额外人工审查，使规范审查工具的整合更为紧密。
### 事件报告审查工具
<em>事件报告审查工具</em> 采取相同的方法处理事件报告（也称为事后总结）。除了检查每份报告是否完整外，它还评估该报告是否清晰地解释了所发生的事情、识别因素、记录解决方案并提出有意义的后续行动。这些期望在一份专门的 Codex RFC 中进行了定义。
事件报告审查工具使用与规范审查工具相同的开发者平台构建模块。这一共享架构正逐渐成为我们的 Codex 代理的通用模式。
自 2026 年 5 月以来，审查工具已评估了超过 200 份事件报告，并识别出如缺少后续行动项、不完整的时间线和遗漏的检测信号等缺口。在这些报告中，93%的案例涉及低影响、仅限内部或提前声明的事件。对于高严重性事件，我们已将审查工具设为强制性，作为我们全面中央审查流程的一部分，并且报告在所有发现得到解决之前不会被视为完整。
## 未来工作
Codex 已经支持审查代码、技术设计和事件报告的代理。我们计划在整个 SDLC 中扩展这一模型，使代理能够在设计、实施和运营的一致性中发现问题。长期目标是让代理能够自主识别问题并提出修复建议，同时保持工程师负责审查和批准这些变更。
我们还在超越工程的范围扩展 Codex。产品、安全、合规和信任与安全团队开始添加他们自己的标准，允许代理评估工作与设计和实施以外的考量之间的关系。
在许多工程工作流中，基于 Codex 的代理帮助我们更早地发现问题并更一致地应用标准。我们发现 AI 在工程师工作时提供正确的指导最为有效，并计划在整个 Cloudflare 持续延伸这一做法。
如您对构建这样的系统感兴趣，欢迎加入我们的 [工程团队招聘](https://www.cloudflare.com/careers)。
---
原文链接：[点击查看](https://blog.cloudflare.com/engineering-standards-enforcement/)
在 Codex 之前（我们在 [之前的文章](https://blog.cloudflare.com/internal-ai-engineering-stack/) 中简要介绍了我们的 AI 工程堆栈），Cloudflare 的开发者指导散落在很多地方：正式文档、代码库文件、聊天记录，以及各个工程师的积累知识。工程师们常常花费太多时间去寻找指导，而不是专注于他们要解决的问题。即使找到了解答，他们也不总能判断该信息是否最新、权威或适用于他们的具体情境。
随着 Cloudflare 的发展，这种模式越来越难以维持。没有一位工程师能够阅读所有标准，而审查人员也无法可靠地检查每一个要求。随着人员在团队之间流动，机构知识变得越来越难以恢复，而未能始终如一地显现或得以执行的指导导致了项目之间的偏差。
我们将这些知识重新构建为 Cloudflare Codex：一套治理的工程标准，代理可以在工作时提取和应用。现在，这些指导能在代码审查、技术设计审查、事件报告审查等多个用例中提供支持，让工程师专注于得到的发现。
## Codex 组织和工作流程
一个专门的 Codex 治理模型将 Codex 划分为不同领域，涵盖我们关心的工程领域。这些领域包括架构事务（例如，前端和控制平面）、跨领域关注点（安全性和可靠性）、特定语言（TypeScript 和 Rust）以及其他几个领域。每个领域都有一个负责人，负责他们所监督的文档的内容、一致性和总体质量。
Codex 标准使用请求评审（RFC）格式。要求使用定义在 [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) 中的 SHOULD 和 MUST 关键字。我们还期望会有一个前置头部用于包含诸如领域和 RFC 状态等元数据。任何对该领域有关键兴趣和能力的 Cloudflare 员工都可以通过遵循规定结构的合并请求提出 RFC。然后，该提案需经过几轮反馈，来自日益广泛的审查人员组。最终，经过领域负责人批准后，RFC成为 Codex 的一部分并在一个 [Astro](https://astro.build/) 支持的内部网站上发布。
经过批准的 RFC 可以被 Codex 客户和代理使用，后者可以立即开始标记代码、配置或文档中的 Codex 违规行为。然而，它们仅在 RFC 从 approved 状态变为 enforced 时，才会基于 Codex 声明进行封锁。这一独立的晋升步骤为团队提供了时间来吸收新要求，并适应那些需要额外工作的强制情况。
以下图表展示了 Codex 工作流程中的步骤：
一个简单的过程可能会在此处结束，并将整个 Codex 像原样那样提供给大型语言模型（LLM）。然而，考虑到我们已经拥有的 RFC 数量（超过60个且仍在增加），这样的语料量会给上下文窗口带来极大压力，并对 LLM 的结果产生负面影响。为帮助模型引导到最相关的 RFC，我们调用了一个专门构建的代理，自动提取并压缩 SHOULD 和 MUST 语句为专用 JSON 结构，并使用支持懒惰发现和渐进披露的元数据进行增强。以下是我们控制平面服务 RFC 的结果的节选：
每个声明都获得一个稳定的 slug 标识符，即使在提取过程中其 RFC 被更新，该标识符也保持不变。此标识符使我们能够在不同系统之间跟踪相同的声明，这对于监测、分析和例外处理至关重要。
最初，我们将声明提取到另一个更简洁的 Markdown 文件中，而非 JSON。随着时间的推移，我们转向了一种更丰富的结构化格式，以便代理能够更准确地过滤所需内容。我们计划包括额外的元数据以实现更紧密的范围限制，例如指示声明适用的软件开发生命周期（SDLC）阶段（例如，设计、实施、运行时）。
## Codex 消费者
几个系统已经在日常的工程工作中使用 Codex。有三个代理展示了 Codex 在实践中的运作：我们的 AI 代码审查工具、规范审查工具，以及事件报告审查工具。
### AI 代码审查工具
我们的 AI 代码审查代理在 [一篇独立的博客文章](https://blog.cloudflare.com/ai-code-review/) 中进行了详细介绍，它从多个维度评估合并请求，包括 Codex 合规性。
对于每次审查，该代理都会检索 RFC 并解析 Codex 声明。仅在模型或协调员需要额外上下文时，它才会加载完整的 RFC 主体。在大多数情况下，这些声明提供了足够的信息来解释报告的违规行为。
SHOULD 和 MUST 之间的区别，加上 RFC 的状态，决定了审查者的响应方式。来自被批准的 RFC 的发现是非阻塞性建议。一旦 RFC 被强制执行，未满足的 MUST 要求会导致审查者拒绝批准或阻止合并请求，具体取决于严重性。
自今年年初 Codex 建立以来，AI 代码审查工具已经标记了近 230,000 次违规。其中，几乎 16,000 次导致批准被拒绝（即，它们涉及强制性 RFC 中的 MUST 声明）。
### 代码审查替代方案
一次 AI 代码审查通常需要几分钟才能完成，原因在于协调员框架和子代理执行。尽管等待通常很值得（无论是金钱还是代币），但工程师们对延迟和额外的整改轮次表达了不满。我们探索了如何改善这一体验，并提出了两个额外的选项：
1. 对于可以机械验证的语言特定 Codex 要求，我们提供自定义的 linting 配置包。这些与我们的 Codex 规范对齐，并使问题能够在数毫秒内被提出。TypeScript 是第一个获得 Codex linter 支持的语言，同时也标准化使用由 [VoidZero 团队](https://blog.cloudflare.com/voidzero-joins-cloudflare/) 维护的 oxlint 进行高效的 linting 执行。Rust 项目的 linter 当前在开发中，Go 语言也将在未来跟进，以完成 Cloudflare 最常用语言的覆盖。
2. 为了削减审查周期中的持续集成（CI）环节，我们使得可以通过命令行接口（CLI）在本地运行 AI 代码审查工具。它匹配 CI 的协调员功能，并在自动确定的 diff 集上运行相同的 （[OpenCode](https://opencode.ai/) 为基础）代理，结果在终端呈现。
我们认为 linting 工具对几乎每个开发者和代码库都会有帮助，而 CLI 对于那些青睐它的工程师则仍然是可选的替代方案。
### 规范审查工具
Cloudflare 的工程师们常常在实施之前撰写设计文档和技术规范（简称为<em>specs</em>）。Codex 的一个重要子集涉及设计、架构和与技术审查相关的其他主题。为了在实施开始之前捕捉架构错误，我们构建了<em>规范审查工具</em>，一个发现规范并根据相关的 Codex 要求进行评估的代理。
规范审查工具运行在开发者平台上：它作为一个 Cloudflare Worker 执行，将其结果和状态存储在 D1 中，通过 AI 网关路由模型请求，并通过 Cron 触发器启动对新规范的扫描。它首先根据涉及规范的领域和部分过滤 Codex（例如，语言特征和以实施为中心的 RFC 将被忽略）。有几个指导提示指示模型如何进行评估并构建结果。发现根据严重性进行评级（受 SHOULD 和 MUST 关键字的影响），并包含一般质量和架构建议。在每次审查完成后，会在规范文档中留下一个链接到自定义仪表板的备注，审查详情可以在此查看。
自 2026 年 5 月以来，几乎 600 个不同的开放规范已被审查。包括根据需求或规范变更触发的重新审查，我们迄今跟踪了超过 3,200 次审查调用。绝大多数发现的严重性为 “重大”（65%）或“轻微”（29%），而“关键”发现则占少数（6%）。
以下图像展示了规范审查工具用户界面的样子：
我们计划通过直接在规范文档上发布评论、嵌入可以影响审查评估的人工-代理对话，以及标记高影响提案以进行额外人工审查，使规范审查工具的整合更为紧密。
### 事件报告审查工具
<em>事件报告审查工具</em> 采取相同的方法处理事件报告（也称为事后总结）。除了检查每份报告是否完整外，它还评估该报告是否清晰地解释了所发生的事情、识别因素、记录解决方案并提出有意义的后续行动。这些期望在一份专门的 Codex RFC 中进行了定义。
事件报告审查工具使用与规范审查工具相同的开发者平台构建模块。这一共享架构正逐渐成为我们的 Codex 代理的通用模式。
自 2026 年 5 月以来，审查工具已评估了超过 200 份事件报告，并识别出如缺少后续行动项、不完整的时间线和遗漏的检测信号等缺口。在这些报告中，93%的案例涉及低影响、仅限内部或提前声明的事件。对于高严重性事件，我们已将审查工具设为强制性，作为我们全面中央审查流程的一部分，并且报告在所有发现得到解决之前不会被视为完整。
## 未来工作
Codex 已经支持审查代码、技术设计和事件报告的代理。我们计划在整个 SDLC 中扩展这一模型，使代理能够在设计、实施和运营的一致性中发现问题。长期目标是让代理能够自主识别问题并提出修复建议，同时保持工程师负责审查和批准这些变更。
我们还在超越工程的范围扩展 Codex。产品、安全、合规和信任与安全团队开始添加他们自己的标准，允许代理评估工作与设计和实施以外的考量之间的关系。
在许多工程工作流中，基于 Codex 的代理帮助我们更早地发现问题并更一致地应用标准。我们发现 AI 在工程师工作时提供正确的指导最为有效，并计划在整个 Cloudflare 持续延伸这一做法。
如您对构建这样的系统感兴趣，欢迎加入我们的 [工程团队招聘](https://www.cloudflare.com/careers)。
---
原文链接：[点击查看](https://blog.cloudflare.com/engineering-standards-enforcement/)
评论
暂无评论。