当 AI 代理参与写代码、修改规格说明，甚至整理事故报告时，真正困难的问题通常不是“它能不能生成代码”，而是“它是否始终遵守团队的工程标准”。Cloudflare 的做法是建立一个由结构化工程规范组成的 Cloudflare Codex，再让 AI 代理在开发生命周期中消费这些规范，并通过代理审查自动检查一致性。
这种思路的关键，不是把一份长篇指南丢给模型，而是把工程决策整理成可引用、可检查、可演进的规则。
把工程标准变成 AI 能消费的知识
传统工程规范经常存在于 wiki、会议纪要和资深工程师的经验中。人可以通过上下文理解这些内容，AI 代理却需要更明确的输入：适用范围、强制要求、例外条件，以及可验证的结果。
一个适合代理消费的标准，至少可以包含以下字段：
- 规则标识：方便在代码审查或事故报告中引用。
- 适用范围：明确哪些仓库、服务或文件类型需要遵守。
- 规范内容：用短句描述必须满足的条件。
- 验证方式：说明应运行什么检查，或应该寻找什么证据。
- 例外与豁免：避免代理把合理的特殊情况判定为错误。
- 版本和负责人：让规范可以被维护，而不是变成过时的静态文档。
例如，可以用 YAML 表达一条 API 变更规范。下面的格式是一个可改造的实践示例，不代表某个具体团队的内部格式：
id: api-compatibility-001
version: 1
scope:
- "services/**/openapi.yaml"
- "services/**/src/**"
rule: "公开 API 的破坏性变更必须包含迁移说明和兼容性评估。"
checks:
- "比较当前版本与基线版本的 OpenAPI 定义。"
- "确认删除字段、收紧校验或改变响应结构时存在迁移文档。"
- "在 pull request 中引用相关 RFC。"
exceptions:
- "仅限内部环境且未被外部客户端调用的接口。"
owners:
- platform-api
结构化之后，规则就不只是供人阅读的说明，也可以成为审查代理的输入和 CI 的配置来源。
用 RFC 记录可审查的工程决策
代码规范解决的是“应该怎样实现”，RFC 则解决“为什么这样设计”。两者结合后，AI 代理不仅能检查代码风格，还能判断实现是否偏离了已经批准的设计。
一份实用的 RFC 不必很长，但应该让审查者找到几个关键答案：
- 要解决什么问题，哪些问题明确不在范围内？
- 方案会影响哪些服务、接口、数据和运维流程？
- 失败模式是什么，如何回滚或降级？
- 哪些指标能够证明方案正常工作？
- 哪些工程标准适用于这次变更？
可以把 RFC 和代理审查组合成一个简单的检查流程：
#!/usr/bin/env bash
set -euo pipefail
rfc_file="${1:?usage: ./check-change.sh path/to/rfc.md}"
# 这些检查可以替换成团队已有的 lint、OpenAPI diff 或 AI review 命令。
rg -q '^## (Problem|问题)' "$rfc_file" || {
echo "RFC is missing a problem section" >&2
exit 1
}
rg -q '^## (Rollback|回滚)' "$rfc_file" || {
echo "RFC is missing a rollback section" >&2
exit 1
}
printf 'RFC structure check passed: %s\n' "$rfc_file"
在真实项目中，脚本可以继续调用 OpenAPI 差异工具、单元测试和代理审查服务。重要的是让每项检查都产生可追踪的结果，而不是只在聊天窗口中给出一句“看起来没问题”。
代理审查覆盖开发生命周期
工程标准的价值不应只体现在 pull request 阶段。只要不同阶段共享同一套规范，团队就能减少“代码符合要求，但规格和事故记录没有同步”的情况。
可以将代理放在这些位置：
- 需求和 RFC 阶段：检查目标是否清晰，风险和回滚方案是否完整。
- 代码变更阶段：检查实现、测试、接口兼容性和安全要求。
- 发布阶段：核对变更说明、监控指标和部署步骤。
- 事故复盘阶段：检查时间线、影响范围、根因和后续行动是否完整。
代理输出也应采用结构化格式，便于合并到审查系统或持续集成流程。例如：
{
"standard_id": "api-compatibility-001",
"status": "needs-human-review",
"findings": [
{
"severity": "high",
"file": "services/orders/openapi.yaml",
"message": "响应字段 order.status 的枚举值发生变化，但 RFC 中没有迁移说明。"
}
],
"evidence": [
"基线版本包含值: pending, paid, cancelled",
"当前版本删除了 pending"
]
}
这里的 needs-human-review 很重要。治理系统不应把所有判断都伪装成确定答案。对高风险变更，代理负责发现证据和提出问题，人负责接受、修改或批准例外。
采用时要控制哪些风险
把规范交给 AI 并不会自动产生可靠治理。规则质量、上下文质量和验证机制都会影响结果。
避免规范过于宽泛。“代码必须高质量”无法直接验证。应该改成“新增外部 API 必须包含错误响应示例，并通过兼容性检查”。
避免只依赖模型判断。格式检查、静态分析、测试和 API diff 等确定性工具应优先运行；代理适合补充跨文件、跨文档的语义审查。
保留人工豁免流程。确实存在例外时，应要求提交理由、负责人和有效期，而不是通过修改提示词来绕过规则。
让规范可版本化。规则发生变化时，要能知道哪些项目采用了新版本，哪些审查结论仍基于旧版本。
记录证据而非只记录结论。审查结果应引用文件、行号、测试输出或 RFC 段落。这样开发者才能快速复核，也方便在误报时改进规则。
一份可落地的起步清单
可以从少量高价值规则开始，而不是一次性覆盖所有工程实践：
- 选择一个容易出错且影响较大的领域，例如 API 兼容性或数据迁移。
- 为每条规则定义范围、验证方式、例外和负责人。
- 把相关设计决策迁移到结构化 RFC 中。
- 让代理输出规则 ID、状态、证据和发现项。
- 先以建议模式运行，收集误报和漏报，再逐步启用阻断。
- 每隔一段时间复查规则，删除已经失效的要求。
Cloudflare Codex 所体现的核心方向，是把工程标准从分散的文档变成 AI 代理能够持续使用的治理层。真正值得借鉴的不是某个特定工具名称，而是这套组合：结构化规范负责表达约束，RFC 负责保留决策背景，确定性工具负责验证事实，代理负责连接代码、文档和运行记录。这样，AI 才能在团队既有工程文化中工作，而不是成为一套独立运行的代码生成器。