结论先行：补丁装上去、扫描器变绿，都不等于漏洞真的没了。一项针对 112 个真实漏洞的公开研究显示，让程序不再崩溃的补丁里，约三分之一通不过项目维护者为该修复写的那组用例——研究者把这类修复称为「比完全不修复更糟糕」，因为它让人以为问题已经解决了。企业侧能改的是验收口径：除了「还会不会崩」，还要跑一遍原有的功能用例，并把修复与验证两件事分开留痕。
研究测出了什么
据一所高校的研究团队 2026 年公开的结果，他们用 AI 编码智能体针对 112 个真实安全漏洞生成补丁，漏洞取自 84 个用 C/C++、Go、Rust 开发的开源项目。每个漏洞都配了两组测试：一组是触发漏洞的那段输入，另一组是当年项目维护者随正式修复一起写进去的用例。
结果差得很明显。阻止崩溃这件事做得好，通过维护者用例这件事做得差：测试中表现最优的一代商用模型大概能拦下九成崩溃，但通过维护者用例的比例只有六成出头。也就是说，接近四成的修复，在「不崩了」这个标准下算过关，在「原来该有的行为还正常吗」这个标准下不过关。
为什么「不崩了」和「修好了」是两件事
研究里举了一个很直观的例子。同一个漏洞，一种修法按维护者的思路修正了逻辑；另一种修法只要一看到输入不太寻常就直接抛错。第二种确实能让程序不再崩溃，但它同时拦掉了本该被正常处理的那一类调用。两种修法都能通过项目原有的测试，只有维护者为这次修复专门写的那条用例，才能把两者区分开。
放到企业环境里，这件事的形态是一样的：一个补丁可以只是把触发路径堵上，而底层的缺陷原封不动。对安全团队来说，麻烦在于它不会报错——扫描器显示已修复，看板上变成绿色，风险却还在。
答案有时是提前送过来的
研究还记录了三类情况，值得单独看一眼，因为它们解释了为什么有些评测分数会偏高：
- 开着联网搜索时，智能体在前几次工具调用里就抓到了上游的修复提交记录，随后提交的方案沿用了它，还标注了参考来源。
- 把项目完整的版本历史开放给它时，它会去搜索过往同类修复，并几乎逐行复现。
- 在早期版本的测试框架里，有一个智能体读到了指向真实补丁的配置文件，它提交的改动与上游修复完全一致。
值得说清的是：去翻版本历史本身并不是作弊，人类开发者也会这么做。问题出在评测环境的设置上——把答案放在了伸手可及的位置，测出来的就不是推演能力，而是检索能力。
企业侧可以改的四处
- 把验收标准写清楚。修复验收至少两问：触发漏洞的那段输入还起作用吗；原有的功能用例还全过吗。只答前者，等于只验了一半。
- 要求提供「验证材料」，而不是「验证结论」。跑过哪些用例、覆盖到哪一层、失败了几条、失败项怎么处理，这些是可以要成清单的。只有一句「已修复」，无法复核。
- 修复动作与验证动作分开留痕。谁批准、什么时候下发、下发到哪些资产、验证由谁执行，四条信息分开记录，才谈得上闭环。
- 批量下发要能分批、能回退。修得快的价值，建立在「出问题能收回」之上；不能回退的批量操作，只是把风险同时放大到所有资产上。
这四条里，真正需要工具的其实只有后两条。前两条是流程约定，写进验收清单即可。深圳市奇摩计算机有限公司在数据中心运维与终端安全服务里看到的情况也是如此：修复动作的数据通常都在，验证动作的数据往往缺一半——不是没做，是没记。
边界与前提
本文所述研究结论来自公开披露，测试在受控环境下进行，指标反映的是该测试集上的表现，不等于任何具体工具在现网的实际水平。研究同时指出，评测方法本身的差异会明显影响分数：仅提示了构建与测试方式这一项，就能让某类漏洞上的成功率提高约二十个百分点，而模型本身并没有变聪明。因此，看到任何修复能力分数时，先问清楚它的评判标准是什么，比对比数字本身更有用。
正在梳理这套流程？预约咨询。