在一项新研究中，Claude Opus 4.7 有 90.2% 案例能阻止给定漏洞利用，但只有 60.7% 补丁通过上游开发者编写的测试。29.5 个百分点的差距才是关键：压住一个崩溃，并不证明修复保留了维护者要求的行为。
西北大学研究者 Dang K Le、Wenxuan Shi 和 Xinyu Xing 于 10 月 7 日报告了这项基准可靠性研究，涵盖 84 个开源项目、112 个 C、C++、Go 与 Rust 历史缺陷。它是特定 Claude 与智能体配置的预印本结果，不是所有自动修补或生产安全工作的普遍失败率。
模型更强，评分差距仍在
受控运行在相同案例上使用 OpenCode，分别搭配 Sonnet 4.0、Sonnet 4.5 和 Opus 4.7。智能体获得构建和测试指令，但最初不提供 PoC 正文。PoC 是展示已报告故障的输入或操作步骤。
Sonnet 4.0 的 PoC 通过率为 77.7%，开发者测试为 43.8%；Sonnet 4.5 为 84.8% 与 48.2%；Opus 4.7 为 90.2% 与 60.7%。Opus 两项都确有进步，但其通过 PoC 的补丁仍有 32.7% 未通过开发者测试，即约三次表面成功就有一次不合格，公开评分分析强调了这一点。
Opus 的旧回归测试通过率也有 94.6%，却不能消除开发者测试的落差。旧套件检验已有例子，真实修复时新增的测试则可能编码此前遗漏的缺陷附近行为。
研究者从上游修复提交重建单元或集成测试，在智能体生成补丁之后应用。评价对象是行为，而非与历史补丁文字相似；不同实现也可通过。完整解决需依次过四关：构建、多次运行中阻止 PoC、既有回归测试，以及新增开发者测试。
PHP 案例：崩溃可能以错误方式消失
PHP 的历史 range() 缺陷会错误分类混合输入，把非字符串按字符串访问。直接拒绝混合类型可以阻止崩溃，并保住许多旧测试，却也拒绝 PHP 本应强制转换的合法数字与字符串组合。
上游修复纠正分类逻辑并保留合法行为；开发者新增的相邻有效输入测试，将正确修复与过度限制的绕行方案区分。只看崩溃的评分器会同样奖励两者。
这种防护可作为应急缓解，却未必完整修复。自动程序修复早已知道测试过拟合：补丁符合可观察样例而非底层要求。安全情境下，它可能隐藏症状、留下其他路径，甚至带来让审查减少的虚假信心。
维护者测试是更好代理，不等于全部验收。它未穷尽性能、兼容性、可读性与架构。合理替代方案也可能有意改变未记录行为，因此历史测试失败意味着需要检查的不一致，而非自动判定危险。
指令会改变测出来的能力
给详细构建与测试命令，Sonnet 4.0 的 PoC 通过率为 77.7%，不给则 74.1%；开发者测试从 41.1% 升至 43.8%。只看 C/C++，指令让 PoC 从 72% 升至 92%，开发者测试却仅从 28% 到 36%。
文档是正当帮助，人类工程师也受益。但不披露信息预算，就不能安全比较两套基准。Go/Rust 往往有可预期命令，C/C++ 则有更多构建系统、标志与封装。准备帮助可能在真正评估修复质量前就改变得分。
PoC 表达方式也重要。62 个 Go 案例中，展示源码级 PoC 让崩溃测试从 69.4% 升至 95.2%，开发者测试仅从 41.9% 到 48.4%。可读测试框架暴露 API 与调用结构，更容易让模型对准可见测试。
25 个 C/C++ 案例中，展示不透明二进制或文本输入，PoC 仍为 92%、开发者测试仍为 36%。两者都可以说“提供 PoC”，但一个暴露可执行意图，另一个仍需推断输入意义，信息条件并不相同。
搜索与基础设施能双向扭曲评分
历史任务通常已有公开问题、公告与修复。论文记录，一次智能体通过网页工具找到上游补丁，另一次从未清理 Git 历史找到旧修复。补丁成功，却不能干净衡量独立推理。
生产开发查网页和历史很合理；只有当基准宣称无辅助推理时才构成污染。若明确评价检索与工具使用，可以允许。历史修复可能已被模型记忆，也限制绝对得分解释。
框架错误则可能掩盖正确成果或暴露隐藏答案。权限、超时和测试文件冲突可能阻止构建、惩罚慢项目或错判补丁。完整运行中，个别框架问题影响约 5%—32% 案例，有时超过排行榜差距。
所以得分属于模型、智能体框架、提示、工具、源码包装、限制和评分流程的整体。受控实验用 OpenCode 与 Claude，案例研究还包括 Claude Code 与 Sonnet 4.5，不能把这些框架视为可互换。
相关研究说明为何需要多重测试
PVBench覆盖 20 个项目、209 个案例，超过 40% 通过基础检查的补丁未通过来自开发者修复的附加测试。数据与设计不同，所以支持整体疑虑，不提供直接可比的 Claude 失败率。
PatchBench发现，11 个智能体的 PoC 单项评分平均把解决率放大 1.83 倍。安全重放、单元与输出检查后，最强智能体从原始 PoC 超过 97% 的通过率，降至综合验证约解决一半任务。
PatchBench 还选择修复点位于崩溃栈之外的漏洞，并移植到变化的代码库情境，降低回忆历史补丁的价值。这针对记忆污染，而非假设每次成功都是新推理。
伯克利的 CyberGym-E2E包含 139 项目、920 漏洞，联测发现、复现与修补。告知目标漏洞时，最佳配置修复约 80%；必须先发现时端到端结果更低，也观察到只在崩溃位置加防护的浅层补丁。
研究模型、任务和定义不同，不能拼成同一排名。Cyber Index 方法也把流程扩展至审计、发现、复现及不破坏合法行为的修补。共同问题是“成功比例”究竟包括什么。
更强判据仍不等于生产证明
西北样本要求可复现构建与上游有意义测试，112 个缺陷有多样性，但不能代表所有生产漏洞。公开历史可能进入训练。这影响绝对值，却不能抹掉控制提示或判据后观察到的基准敏感性。
生产可用项目测试、静态分析、模糊测试、代码审查与分阶段发布提高安全；也可能因测试不全、行为未记录和依赖缺失更难。整理过的基准或单个通过 PoC，都不证明可以无人发布。
下一步应同时披露 PoC 与开发者意图测试，说明工具和网络权限、清理历史、超时与分阶段失败，并跟踪维护者接受、修改或拒绝的生产候选。其他攻击路径和新引入弱点也重要，不能用文字匹配历史补丁代替行为验证。
可检索工程知识库能保存提示、工具轨迹、补丁和验证结果，帮助跨项目学习，但不能让补丁自动正确。研究支持的结论是：Opus 4.7 确有进步，但崩溃单项评分比开发者行为对齐成功高 29.5 个百分点。生成修复仍是候选，需要独立证据证明安全性质与合法行为。