AI 修补基准忽视真实质量，研究揭示重大差距

西北大学的研究团队在 112 个真实漏洞上对代码生成代理进行了系统评估，这些漏洞分布在 84 个开源项目中，项目使用的语言包括 C/C++、Go 和 Rust。数据集的构建兼顾了两类测试：一类是最初的概念验证（PoC）触发的崩溃场景，另一类是项目维护者额外提供的回归测试，用以检验修补后的代码在更广泛的功能路径上是否仍然保持正确。

最引人注目的结果出现在 Claude Opus 4.7 模型上。该模型在大约 90% 的案例中成功阻止了崩溃，但在仅有 61% 的情况下能够通过维护者提供的完整测试套件，这一数字揭示了防止崩溃与实现真正功能正确性之间存在显著差距。

仅看崩溃的基准为何误导

传统的修补基准往往把只要阻止崩溃就算成功，视其为概念验证的达标。这种单一维度的评估方式忽视了开发者在代码库中加入的更深层次的验证步骤，这些步骤旨在确保修补不仅消除了异常，还符合原始设计意图且不引入新的回归错误。

在西北大学的实验中，大约三分之一的 Claude Opus 4.7 修补在消除崩溃后未能通过维护者的对齐测试——约有四成的修补看似有效，却未能满足完整的开发者检查标准。

基准设计中的偏差来源

arXiv 上的论文《On the Reliability of LLM‑Based Vulnerability Patching Benchmarks》系统指出了基准设计中的三类偏差：第一类是代理层面的因素，例如提示的编写方式和所使用的辅助工具；第二类是评估框架的问题，包括权限配置错误、基础设施缺陷以及超时处理机制的不当；第三类是数据集层面的缺陷，尤其是仅使用单一 PoC 测试而未能捕获漏洞的根本原因。

该研究的作者同样使用了相同的 112 条漏洞集，但额外加入了用于判断修补是否符合原始设计原则的回归测试和开发者自定义测试。他们的分析证实，即使是最新的模型也难以通过这些额外的测试，仅比基线表现略有提升。

明确指令的影响

西北大学的研究者报告称，当向 AI 明确说明如何构建和测试代码时，模型在 C/C++ 漏洞上的成功率提升了约 20 个百分点。这一提升并未改变底层模型的结构，凸显了提示工程和测试驱动指引在提升修补质量方面的关键作用。

两项独立研究均一致认为，基准分数对评估选择极为敏感。访问 Git 历史、数据集中的预加载响应或超时计数方式的细微差别，都可能人为抬高或压低报告的性能指标。

• 检查维护者测试是否计入评分
• 确认代理是否能访问互联网或 Git 历史
• 记录用于构建与测试指令的完整提示
• 了解超时和流水线错误的计数方式

基于上述发现，研究团队建议对任何 AI 修复工具的报告数字进行上述四项标准的审查。缺乏这种审慎的评估，组织可能会采纳看似光鲜却难以提供可靠、向上兼容补丁的解决方案。

对于中文使用的企业而言，关键结论十分明确：高崩溃防护率并不等同于补丁能够通过完整的开发者测试套件。决策者应要求基准方法包含维护者编写的回归测试，披露任何外部数据访问，并对提示设计和超时处理保持透明。

只有在上述条件得到满足的情况下，AI 生成的补丁才能安全地集成到生产代码库中，避免因隐藏缺陷而导致的二次安全风险。

本报告的所有数据均来源于 2026 年 10 月 12 日发布的 Help Net Security 文章以及同月 7 日在 arXiv 上公开的预印本，确保信息的时效性和可追溯性。