1Password 在 8 月 6 日发布的 FLAWED 报告里甩出一个刺眼的数字：AI 代码修复的干净修复率只有 26%。这个数字随后被反复引用，成了"智能体还搞不定真实安全补丁"的现成证据。Trail of Bits 不认，回应写得很硬——问题不在模型，在这份基准自己身上。
他们的判断是：四项实验设计选择叠加起来，把 26% 这个数字彻底带偏了。你拿它当能力上限，等于拿一把刻度错位的尺子量身高。四项选择看着零散，其实落在三个地方——递到智能体手里的提示词、它被允许使用的工具、以及不同试验之间的运行口径。
26% 是怎么被一步步做出来的
先把 1Password 的论点摆出来。FLAWED 报告的核心主张是：把真实的漏洞修复任务丢给编码智能体，绝大多数情况下它交不出干净的结果，26% 就是这么算出来的。Trail of Bits 没有去争"模型到底行不行"，而是把实验设置拆开看，发现每一处选择都在往低处压分数。
提示词里埋着 22% 的定向误导
最扎眼的一条是提示词。整个数据集里有 22% 的样本，提示词本身就带着明确指令，要求智能体去应用一个错误的修复方案。这测的不是模型能不能修 bug，而是模型听不听话。真实工作流里没人会先递上一份写好的错误答案，再指望你自己把它推翻。把这类样本算进分母，干净修复率当然往下掉，而且掉得毫无道理。
三分之一以上的试验，连编译都不让跑
执行环境更让人想不通。36% 的试验里，智能体被禁止运行编译或测试。编译是工程师手边最便宜的一道反馈——写错了，编译器第一个告诉你。把这道反馈关掉，等于让修理工蒙着眼睛拧螺丝，再回过头怪他拧不正。这不是推理能力的问题，是任务设计人为制造的信息缺失。
推理档位不同，分数就没法横向比
还有一项是推理档位。不同试验跑在不同的推理强度设置上，听着技术性很强，后果很实在：同一个模型在不同档位下的表现差距，有时比不同模型之间的差距还大。一份想回答"AI 能不能修安全漏洞"的基准，不该在"模型思考多久"这种变量上留自由度。变量按不住，结论就站不直。
Trail of Bits 不只挑错，还自己下了场
批评一份基准容易，拿出替代证据难。这次两边都做了。他们除了指出 FLAWED 的口径问题，还端出自己的对照数据，试图回答一个更根本的问题：假设 26% 不可信，那真实世界里修安全漏洞的及格线大概画在哪里。
人类修 bug 也没那么神
他们给出的参照之一，是人类工程师在同类任务上的失败率。这组数据的杀伤力在于它动摇了一个默认前提——如果人类交出的不合格结果同样不少，那 26% 衡量的就不是 AI 的特质，而是任务本身的难度。把"AI 只有 26%"直接翻译成"AI 不行"，中间跳过了太多步骤。
开源仓库的合并记录，是另一种真相
另一个参照来自开源项目的合并数据。真实的 pull request 里，多少补丁最终被合入，多少被驳回或反复返工，这是不带实验温度的野外记录。把它摆在受控实验结果旁边，差别立刻显形：一份被刻意设置了障碍的评测，和真实协作流程中的通过率，本来就不是同一件事。
对照的意义在于口径一致
要说清楚的是，Trail of Bits 做对照不是为了证明"AI 很行"。他们真正想说的是：任何修复成功率，如果不交代分母是什么、失败如何定义、环境提供了多少信息，就只是一个孤零零的百分数。同一个模型，换个任务集、换个判定标准，从 20% 到 70% 都能跑得出来。26% 的问题不在于它错，而在于它无法解释。
安全补丁评测，天生就难打分
把矛头只指向 1Password 也不公平。安全领域的 AI 评测本来就难做，难到很多人宁可绕过去。
智能体不是黑盒，但很多人当它是
评测一个 编码智能体，和评测一个只会吐 token 的模型完全是两码事。它要读仓库、要跑命令、要在多轮交互里自己找回正确路径。这类系统对初始条件极度敏感：给它一条错误提示，它会顺着走；不给它编译器，它只能靠猜。把这种系统硬塞进"输入—输出"的评分框架，测出来的东西必然失真。
"修好了"这件事本身没有共识
更麻烦的是判定标准。一个安全补丁算不算干净，可以有好几种解释——能编译、测试通过、漏洞真的被堵上、没有引入新缺陷、风格符合项目惯例。这几条之间会互相打架。功能修对了却留下旁路，测试全绿但漏洞还在，这种补丁在真实代码评审里天天出现。基准如果只挑其中一个维度下手，结论的适用范围就得跟着收窄。
发布方的立场，也是一层变量
然后是发布方的问题。厂商做基准，天然带着自己的问题意识。1Password 想搞清楚 AI 能不能接手安全修复，这个动机完全正当，但动机正当不等于方法严谨。当一份基准同时在挑战"AI 很强"的主流叙事，又出自一家有安全产品线的公司，外界引用时更该多看两眼方法学，而不是直接抄数字。
下次再看到这类数字，先问这几个问题
读方法学比读结论划算
26% 这个案例给出的教训简单到有点无聊：看到任何 AI 能力数字，先去翻实验设置。提示词怎么写的，工具权限给到什么程度，失败如何判定，不同试验之间有没有变量漂移。这几件事问完，数字的可信度基本就有谱了。跳过这一步直接引用，你引用的其实是别人的实验设计，不是模型的能力。
厂商自评的结构性偏见绕不开
还有一层得认下来：大量基准来自有产品的公司。这不是原罪，但读者要清楚它意味着什么。好消息是这类批评现在来得越来越快——报告 8 月发布，Trail of Bits 的反驳没拖太久。基准被公开拆解，本身就是这个领域还在自我纠错的证据。真正值得担心的从来不是某个数字被推翻，而是没人愿意花力气去推翻它。
