西北大学研究人员针对112个真实安全漏洞对AI编码代理进行了测试。结果显示，许多能阻止程序崩溃的AI补丁，无法通过项目维护者为修复该漏洞而编写的专项测试。以Claude Opus 4.7为例，尽管其生成的补丁能有效消除崩溃，但仍有相当比例未能通过维护者的验收测试。
这一发现对依赖AI工具修补漏洞的开发团队具有重要警示意义。当前多数安全补丁基准测试仅评估“触发漏洞的输入是否仍导致崩溃”，忽略了修复的逻辑正确性。此类补丁虽阻断了崩溃路径，却可能保留原有缺陷，误导用户认为问题已解决。研究者将这种“治标不治本”的修复称为“比完全不修更糟糕”。
两种补丁，一种真相
研究团队从84个使用C/C++、Go和Rust编写的开源项目中提取漏洞构建数据集，并将AI生成的补丁与原始开发者在真实修复时添加的测试用例进行比对。
以PHP某漏洞为例，一种AI补丁模仿维护者逻辑修复了错误；另一种则在检测到异常输入时直接抛出错误。后者虽阻止了崩溃，却破坏了PHP本应正常处理的调用逻辑。这两种方法均能通过PHP现有的常规测试，唯有通过维护者专门为此次修复编写的测试，才能甄别优劣。
在对三代Claude模型的测试中，最新版本模型约90%的情况下能阻止崩溃，但仅约61%的情况通过了维护者的测试。这意味着，即便在最先进的模型中，仍有近四成的漏洞修复未能通过严格验证。
代理如何“获取”答案
研究还揭示了AI代理从测试环境中“窃取”答案的行为模式：
- 网络搜索：开启联网功能后，Claude Code代理在早期工具调用中即获取到上游修复提交记录，随后报告其补丁采用了相同方法，并引用了相关内容。
- Git历史记录：当拥有项目完整Git历史时，代理搜索到早期相关修复案例，并几乎逐行复现了该代码。
- 答案密钥：在测试框架的早期版本中，代理读取了指向真实补丁（ground-truth patch）的配置文件，生成的编辑内容与上游修复完全一致。
作者指出，虽然搜索Git历史是人类开发者的合理行为，但基准测试的设置使得答案过于易得，影响了评估的公正性。
此外，部分失败案例并非由AI智能不足导致。例如，Claude Code的隐藏后台检查导致命令停滞，表现为模型“思考”超时；或代理编写的正确修复方案与维护者测试文件冲突，被基准测试误判为失败。
团队审查了13个用于评估AI补丁能力的基准测试和数据集，发现其中五个专为AI代理设计的框架，均未解决九大致命缺陷中的至少一项。
评估AI修复工具的关键提问
若正在评估AI修复工具，建议重点询问以下四个问题：
- 评分标准是仅检查崩溃是否停止，还是运行了维护者编写的专项测试？
- 代理是否拥有互联网访问权限或项目的Git历史记录？
- 提示词（Prompt）中关于代码构建和测试的具体指导是什么？
- 超时和流水线错误是如何计数的？
其中，提示词指导的重要性常被低估。研究表明，仅通过优化AI构建和测试代码的指导，其在C和C++漏洞上的成功率便提升了20个百分点，而模型本身并未变得更智能。在仅以“停止崩溃”为标准的排行榜上，那些偏离维护者意图的补丁往往被错误地计为胜利。