企业怎样证明 AI 代码审查真的有用？Datadog 没有只统计评论数量或点赞率，而是拿历史上真正导致事故的代码改动重新测试。
这个方法被称为 incident replay harness。它的核心问题很直接：如果这条 AI 评论在当年合并前出现，事故负责人会不会因此改变决定？
这里需要先纠正一个容易产生的误解。公开案例没有说 Datadog 创建了完整的“生产数字孪生”，也没有把某次公开大故障与某个回放 PR 一一对应。OpenAI 客户案例披露的是：团队重建了曾对事故有贡献的历史 pull request，让 Codex 像参与原始审查一样重新检查，再请对应事故的工程师评估反馈价值。
从历史事故构造评测集
常见代码审查评测会植入合成 bug，或者让模型在静态代码片段上找问题。这类题便于打分，却很难覆盖生产事故常见的系统性风险：改动本身局部合理，但与其他模块、服务契约或测试盲区组合后才出问题。
Datadog 的做法包含三个关键步骤：
- 找出与历史事故相关、且当时已经通过人工审查的 PR；
- 在不把事故答案直接告诉模型的前提下，重建改动并运行 Codex 审查；
- 让熟悉事故的工程师判断反馈是否具体、可行动，以及当时是否足以影响合并决定。
OpenAI 的客户案例称，在 Datadog 检查的事故中，Codex 找到了十多个工程师认为“会产生影响”的案例，约占样本的 22%。这个数字来自供应商与客户共同发布的案例，不是独立第三方基准；公开页面也没有披露完整样本、对照工具配置或置信区间，因此不宜外推为通用检出率。
它评的不是“评论像不像人”
这套设计把评价单位从一条评论，换成了一个真实决策。公开案例列出的高价值反馈包括：
- 指出当前 diff 没有直接修改、却会受到影响的模块；
- 发现跨服务耦合处缺少测试覆盖；
- 提醒 API 契约变化可能带来的下游风险。
这些问题不排斥静态分析、单元测试或人工审查。相反，事故回放的意义是检查 AI 能否补上它们没覆盖的系统上下文。历史 PR 已经通过过人工审查，也说明这里评估的是互补价值，而不是“AI 替代 reviewer”。
普通团队如何建立最小回放集
不需要先造一个大平台。可以从近一年最有代表性的 10 至 20 个严重缺陷开始：
- 保存事故原因、关联 PR、当时可见的测试与必要仓库状态；
- 去掉会直接泄露答案的复盘结论，建立可重复运行的盲审输入；
- 固定模型版本、提示、工具权限和运行日期；
- 由事故 owner 按“正确性、可行动性、是否会改变决策”评分；
- 同时记录漏报、误报、成本和运行失败，而不只收藏成功案例；
- 把稳定发现的风险沉淀进测试、lint、规则或合并门禁。
还要防止后见之明泄漏。若模型能搜索到公开复盘、提交信息已经写明根因，或者输入中包含修复后的测试，所谓“发现事故”可能只是答案检索。可靠回放必须记录模型当时能看到什么。
真正可迁移的结论
Datadog 案例最值得借鉴的不是某个百分比，而是评测对象的变化：从模型是否会说漂亮话，转向它能否提前发现团队真实付出过代价的问题。
同样的方法也适用于运维告警、数据管道故障和安全事件。只要历史事件能还原为“当时可见的证据 + 后来的真实结果”，就能成为比合成题更贴近业务的评测资产。
参考资料
- OpenAI：Datadog uses Codex for system-level code review
- Datadog 2023 年 3 月基础设施连接事故复盘
- Datadog：Rethinking reliability
- OpenAI Codex
资料复核日期：2026-08-23。本文将公开客户案例与 Datadog 的公开事故复盘分开引用，不主张二者存在未公开的一一对应关系。