停止崩溃不等于修好漏洞
当AI工具修复了一个安全漏洞，我们怎么知道它真的修好了？大多数基准测试给出的答案是：让触发漏洞的概念验证输入再跑一遍，如果程序不再崩溃，就算通过。这个标准看起来直接有效，但它可能正在系统性地高估AI的修复能力。
西北大学的研究人员Dang K Le、Wenxuan Shi和Xinyu Xing在10月7日发布的一篇预印本论文中，对当前AI漏洞修复基准测试的可靠性提出了质疑。他们构建了一个包含112个真实历史漏洞的数据集，覆盖84个开源C/C++、Go和Rust项目，每个漏洞都配备了概念验证测试、回归测试，以及最关键的一项——原始开发者修复该漏洞时添加的维护者测试。
一个补丁，两种结局
研究团队用这个数据集做了一个简单但有力的对比。他们发现，一个AI补丁可以让概念验证测试通过，却仍然无法通过维护者测试。
论文中举了一个PHP的例子。一种AI风格的补丁按照PHP维护者的方式修复了逻辑问题。另一种补丁则在输入看起来异常时直接抛出错误——这阻止了崩溃，但同时也破坏了PHP本应处理的调用。两种补丁都通过了PHP的现有测试，只有维护者为修复写的那个测试能区分它们。
研究团队测试了三代Claude模型。最新模型在大约90%的情况下能阻止崩溃，但只有约61%的情况下能通过维护者测试。这意味着，即便是他们测试过的最好的模型，也在大约四成的漏洞上未能通过开发者自己写的测试。
答案就在手边
研究还发现，AI智能体可以从测试环境中“捡”到答案。
在开启网页搜索的情况下，一个Claude Code智能体在前四次工具调用中就抓取到了上游修复提交，并在后续报告中引用了它。另一个智能体被赋予项目的完整git历史后，搜索到了更早的相关修复，几乎逐行复制了过来。在早期版本的测试框架中，一个智能体读取了指向真实补丁的配置文件，其编辑与上游修复完全一致。
研究人员指出，搜索git历史是合理的——人类开发者也会这么做。问题在于，基准测试把答案留在了触手可及的地方。
评估设计可以左右结果
论文的核心论点并非“自动补丁无效”，而是“评估设计可以实质性改变报告的性能”。研究将基准测试的隐患归为三个维度：智能体层面的提示策略和工具可用性会抬高成功率，却不提升补丁质量；框架层面的权限配置和基础设施缺陷会静默地扭曲结果；数据集层面对单一概念验证测试的依赖，无法捕捉补丁是否解决了根本原因。
研究团队审查了13个用于评估AI补丁的基准和数据集，发现为AI智能体构建的五个基准中，每一个都至少遗漏了九项隐患中的一项。
对于正在评估AI修复工具的团队，这项研究给出的建议很具体：把基准分数视为特定评估配置的证据，而不是代码审查、更广泛的测试或维护者安全标准的替代品。停止崩溃是一个有用的信号，但它不是修复完成的证明。
（智算芯能前沿网综合）
本文由智算芯能前沿网编辑整理，转载请注明出处。