正在加载，请稍候
26% 干净修复率里，混着故意要求写错的提示与禁止编译的试验。拆解 Trail of Bits 的四点反驳，给出企业读 AI 补丁基准的三个口径与 5 项检查表。
2026 年 8 月 6 日，1Password 发布 FLAWED 报告，头条数字是「模型只有 26% 的补丁被判定为干净修复」。9 月 15 日，Trail of Bits 发布长文逐项反驳，并在同一篇里公开了自己咨询业务与 Patch the Planet 项目的人与智能体补丁质量数据。两边都摆出了代码和数据，分歧不在立场，在方法学。
先把事实和判断分开，否则很容易把「我不认同你的口径」读成「你的数据是假的」。下面关于 FLAWED 报告内容的描述来自对方回应文的转述，我们未逐页核对原报告。
| 维度 | FLAWED 报告（8 月 6 日） | Trail of Bits 回应（9 月 15 日） |
|---|---|---|
| 核心数字 | 干净修复率 26% | 剔除禁止测试与故意写错的试验后，86%（2,634 / 3,067）拦住了给定利用 |
| 样本 | 六枚修复难度较高的漏洞 | 逐枚干净修复率跨度 3% 至 60%，均值高度依赖选题 |
| 试验条件 | 含禁止编译与运行的评测模式 | 该模式占全部数据 36% |
| 提示词 | 含两条要求应用错误修复的提示 | 该两条占全部数据 22% |
| 人类对照 | 未提供 | 2,265 枚漏洞首次修复失败率 12.5%（95% 置信区间 10.5%–14.5%） |
报告选中的六枚漏洞，是因为其修复足够复杂才入选。复核后发现，逐枚看，干净修复率从 3% 到 60% 不等。这意味着 26% 这个均值对「选了哪六枚」极度敏感——换一批漏洞，数字可以大幅移动。这不是造假，是抽样偏差。
两条提示词明确要求智能体应用错误的修复方案，它们占全部数据的 22%。把「被要求写错」的试验与正常修复试验混在一起求平均，得到的比例部分取决于研究者有多频繁地给出错误建议。
有一种评测模式不允许智能体构建或运行代码，占数据量 36%。把它和「能跑测试并根据结果迭代」的试验合并统计，等于让蒙着眼的人和睁着眼的人跑同一场计时赛。
一个模型跑在 medium 档，另一个跑在 high 档——都是工具默认值。两个模型都没在其最高可用档位上测过，报告也没有测量提高档位对结果的影响。档位不同、结论合并，模型之间的对比就失去了可比性。
回应文另外列出若干评分问题，其中几条研究者 Davi Ottenheimer 也公开指出过：
把这几条放在一起看，26% 更像「一套特定约束下的失败记录」，而不是对补丁能力的测量。
技术负责人真正要回答的不是「模型强不强」，而是「把这类工具放进交付流程，我的复核成本会变成多少」。单一百分比答不了这个问题，至少要拆成三个可分别度量的指标。
| 口径 | 定义 | Trail of Bits 披露的可参照数据 |
|---|---|---|
| 可编译率 | 补丁能否在目标仓库完成构建与现有测试 | 原评测含 36% 禁止构建与运行的试验，该口径无法从 26% 中分离 |
| 回归通过率 | 合入后是否引入新的功能、构建或性能缺陷 | 回扫约 33,500 个后续提交：至少 10 个功能缺陷、4 个构建/测试/发布自动化缺陷、1 个性能缺陷，未发现可利用的安全漏洞 |
| 人工复核成本 | 维护者接受前需要的安全相关返工量 | 186 个 PR 中 126 个被合入（67.7%）；其中 91 个（72.2%）无需安全相关修改，33 个（26.2%）需要 |
第三个口径里的 72.2% 值得单独看。它更接近「工程师带队 + 智能体执行 + 维护者把关」的真实流水线，而不是「让模型写完就算完」的裸测。未合入的 60 个 PR 的处置分布也说明问题：36 个（60.0%）被其他工作取代或重新实现，14 个（23.3%）出于政策、流程、范围或维护原因，只有 4 个（6.7%）被明确以技术理由拒绝。
还有一个不该跳过的案例。在 freenginx 那枚内存安全缺陷上，智能体写的补丁和人类维护者自己提交的另一版修复，都漏掉了「请求提前结束时的清理路径」，引入了同一个崩溃。两个作者，一个是人、一个是智能体，在同一枚漏洞上犯了同一个错。差异不在「人还是机器」，而在合并前有没有人跑到那条不常走的路径。
蓝曜炬辉的工程团队给企业做交付评审流程时也踩过类似的坑：一开始把某类基准的百分比直接当结论写进技术选型备忘，后来发现样本口径、跑测条件、评审模型三件事都没对齐，同一个百分比换个前提就换了方向。现在只把基准当「发现问题的入口」——真正进决策的是在自己仓库上跑出来的三次复现：可编译、回归、人工复核耗时。这套口径在已交付案例里有更完整的落地记录。
有用，但要读成「在刻意设置的困难条件下的下限信号」。难题、错误指令、禁止编译三条约束叠加，26% 更像压力测试结果。回应方重算出的 86%（2,634 / 3,067 拦住给定利用）对应的是「允许跑测试、不给错误指令」的条件。两个数字各自对应一种工况，不能互相替代。
目前没有可直接对比的公开数据。回应文明确说明，其人类基线（2,265 枚漏洞、首次修复失败 12.5%）与智能体评测的任务和工作条件并不相同，不能直接比较。它同时给了一个更有说服力的现象：同一枚 freenginx 缺陷上，人和智能体各自独立写出的修复犯了同一个错。要回答谁更可靠，必须先对齐任务、约束和判定口径。
它是 Trail of Bits 与 OpenAI 在 2026 年 6 月发起的开源安全修补协作项目，产出的是真实开源仓库的 PR，不是合成评测集。截至 2026 年 9 月 14 日，其数据集中 186 个 PR 已被维护者合入或关闭。它更接近工程流水线的实测记录，不能直接当基准用，但提供了少见的合入后回归数据。
不建议找单一替代品。更实际的做法是在自己仓库上建三层内测：可编译率（补丁能否通过构建与现有测试）、回归通过率（合入后 30 至 90 天的缺陷回溯）、人工复核成本（每次接受所需返工时）。这三项跑三个月，比任何公开榜单的百分比都更能决定要不要扩量。
需要把上面这套评审清单落到具体交付流程里的团队，可以翻我们的技术博客看同类口径的历史复盘，或者直接联系蓝曜炬辉的工程团队做一次流程对照。