PatchEval 结果话术

这份文件只回答一个问题：78/230 到底应该怎么讲。具体 CVE 案例放在 patcheval-case-cards.zh.md。

1. 最短版本

可以这样说：

在 PatchEval 230 个 runtime-validated CVE 修复任务上，我们的 Default multi-stage workflow 达到 78/230。这个结果低于 OpenHands + GPT-5 的 83/230，接近 ClaudeCode + GPT-5 的 79/230，高于 SWE-agent + GPT-5 的 76/230。为了避免把模型差异说成 workflow 差异，我还做了同模型 ablation：Default 78/230，Single-Agent 73/230。

2. Leaderboard 参考坐标

论文里纳入的 PatchEval 外部参考结果是：

OpenHands + GPT-5：83/230
ClaudeCode + GPT-5：79/230
Default multi-stage + Deepseek V4 Pro：78/230
SWE-agent + GPT-5：76/230
GPT-5 direct prompt：67/230
OpenHands + Gemini2.5：43/230
SWE-Agent + Gemini2.5：32/230
Claude-Code + Gemini2.5：29/230

这层的作用是回答“78/230 到底算什么水平”。比较稳的说法是：它低于 OpenHands + GPT-5 的 83/230，接近 ClaudeCode + GPT-5 的 79/230，高于 SWE-agent + GPT-5 的 76/230，也明显高于 Gemini2.5 agent references。也就是说，它不是一个孤立数字，而是在 PatchEval no-feedback strict setting 下接近 leaderboard 第一梯队的结果。

3. 同模型 Ablation

Leaderboard 只能说明外部位置，不能严格证明 workflow 设计带来的收益。因为 OpenHands、ClaudeCode、SWE-agent 用的 agent 框架和模型都不一样。

归因 workflow 设计时，要讲同模型 ablation：

Default multi-stage：78/230
Single-Agent：73/230
No-Verifier：76/230
Deep-Self-Check：73/230

这说明多阶段设计有收益，但不是巨大提升。更准确的结论是：多阶段 workflow 在 strict benchmark 上有可见增益，并且 case-level 差异显示它确实会改变修复边界理解和 patch 策略。

4. 不要怎么说

不要说：

我的修复率是 34%。

这个说法太像泛化到真实世界了，也容易显得数字低。

建议说：

在 PatchEval 230 个 runtime-validated CVE 修复任务的 strict oracle 下，Default multi-stage workflow 通过 78 个。

不要说：

我们超过了 PatchEval leaderboard。

建议说：

这个结果接近 leaderboard 第一梯队，但不同系统的模型和 agent 框架不一样，所以 leaderboard 只作为外部参考；真正用于归因的是同模型 ablation。

5. 如果面试官问“这数字是不是低”

可以回答：

是的，所以我不会把它包装成已经解决自动修复。PatchEval 的 strict oracle 很硬，要求 PoC 和单元测试都通过。这个结果更适合说明多阶段设计的相对收益、成本 tradeoff，以及哪些 case 因为分阶段分析获得更好的修复边界。