精准调试基准：你的模型究竟在调试还是在重新生成代码？ Precise Debugging Benchmark: Is Your Model Debugging or Regenerating?

PDB 流程可以拆成 6 步：(1) 数据准备：从 BigCodeBench、LiveCodeBench、SWE-smith 取任务 $(x, C_{gt})$，按 ODC 5 大类（Assignment、Checking、Algorithm、Build/Package/Merge、Timing/Serialization）作为分类锚。(2) 单行 bug 合成：对每条 $(x, C_{gt})$ 用规则过滤「不可删」（如函数签名）和「不可改」行，再随机选 ODC 子类、选操作（insert/delete/substitute）、让 GPT-5.1-Codex/Claude-Sonnet-4.5/Gemini-2.5-Pro 等生成器 pool 中一个 LLM 改一行；每对生成 $m_1=20$ 个候选，单元测试必须失败才保留。(3) 多行 bug 合成：连续 $B\in[2,B_{max}]$ 行的块上做同样操作并对每条 bug 枚举「部分回滚是否仍 fail test」以过滤非原子情况。(4) Bug composition：对每对 $(x, C_{gt})$ 按 stride $s$（单行 $s=3$、多行 $s=5$）约束随机抽 $k\in\{2,\ldots,k_{max}\}$（单行 $k_{max}=4$、多行 $k_{max}=3$）个独立 bug 复合，每配置生成 $m_2=100$ 条后按 $m_3=5$ 子采样。(5) PDB-SINGLE 难度过滤：用 9 个评测模型在 7,591 例初稿上跑一遍，把「9 个模型中至少 7 个全对」的 1,840 例易例剔除，得到 5,751 例的最终 PDB-SINGLE。(6) PDB 评估：每个测试模型接收 (buggy code, task description, 可选 unit tests/failed attempts) 并输出 $\hat{C}$，行 diff 得到 $\hat{E}$，对每条 ground-truth 编辑 $E_i$ 用 $\text{map}$ 配对并构造伪修订 $\hat{C}_i$，按 $\text{precision}=\frac{1}{|\hat{E}|}\sum_{i=1}^{k}F_U(\hat{C}_i)\cdot|E_i|$、$\text{recall}=\frac{1}{k}\sum_{i=1}^{k}F_U(\hat{C}_i)$ 以及 $\epsilon$-relaxed 版本（$\epsilon=2$ 用于 PDB-SINGLE、$\epsilon=1$ 用于 PDB-WILD）报告 micro-averaged 结果。

技术上新颖性体现在三处。第一，bug injection 的形式化：把「修 bug」视作对行集 $E$ 的可逆操作，引入 atomicity（连续行块）与 independence（修一条不影响另一条）两个可验证的组合性质，使得从单 bug 到多 bug 的合成过程可控、可证伪、可证有效。第二，伪修订（pseudo-revision）机制：传统的 diff 评估直接拿「最终程序」做差，但 PDB 用 $\hat{C}_i = \text{apply}(E_{gt}\setminus E_i \cup \text{map}(E_i), C_b)$ 把每条 bug 隔离开评估——既解决了「多 bug 程序中只修对一条」与「全错」在 unit-test 下同分的问题，又让 recall 的定义有清晰的「每条 bug 一票」语义。第三，$\epsilon$-relaxed essential edit size 引入了一个针对「过度编辑」的纠偏步骤：通过 $\text{essential}_U(\cdot)$ 在保留语义正确性的前提下从预测段中删去冗余行，再按 $|E_i|+\epsilon$ 兜底，让 precision 不至于被「无关紧要的格式调整」和「改写半边函数」一并处罚、但也不会让「重写蒙对」逃过评估。配合 $\text{Spearman}\ \rho=0.72$ 的人工评分一致性证据，这套指标体系比单纯的 unit-test 更贴近人类对「精准修复」的理解。

独立看，PDB 仍有几个可改进的具体场景。弱点 1：precision 指标对「无关紧要的格式调整」过于严格——例如 Figure 11 显示模型在修对 bug 后加了防御性 `if not os.path.isfile(...)` 守卫（9.8% 的 pass-but-imprecise 案例），这种修改在工程实践中甚至是被鼓励的，但被 precision 视为 spurious。改进方向是引入「语义保留编辑器（semantic-preserving equivalence class）」，把 $F_U$ 之外再用 LLM-as-a-judge 判「编辑是否改动了可观察行为」，给出 layered precision。弱点 2：recall 在多 bug 程序上把 1.65% 的数据因 bug 互相耦合而错记（图 17），且 20% 的情况是「同一 bug 存在多种最小正确解」（Figure 16）。改进方向是允许多参考 ground-truth edit sets 或在评估时枚举所有最小修正集。弱点 3：atomic bug 注入完全依赖 LLM，受限于生成器本身的「想象空间」，从 Figure 9 看 8/9 模型在 Build/Package/Merge 类上的 recall 异常高 10–20 个百分点（可能因为 Stack Overflow 模板可被记忆），这会让「难」例偏科。改进方向是为每类 ODC 维护人工构造的种子库（类似 SWE-smith）做 calibration，或在每个 ODC 类别上强制注入分布平衡。弱点 4：当前所有指标都是 micro-averaged，未给出 per-task 或 per-bug-count 的方差；论文承认数据集在 bug 数量上仍可能不平衡。

作者在 §7 提出的方向包括：(i) 把 PDB 接入 SFT/RL 后训练流程作为 precision-aware reward signal，测试是否能用「让 edit 越短越好」的方式训练出 Claude-Sonnet-4.5 那种 pass+precision 双高模型；(ii) 借由「任何新 frontier LLM 都能作为 bug 注入器」的 plug-and-play 性质，让 PDB 基准随模型前沿一起滚动，避免再被预训练数据覆盖。我个人可延伸的方向还有：(a) 把 PDB 框架扩展到多语言（Java/JS/Rust），复用 ODC 体系但替换子类别库；(b) 把「bad case taxonomy」（Figures 11–19 中的 redundant guard、over-edit、complete rewrite、regressive repair 等）作为下游调试 agent 的 failure-mode 诊断工具，用在 Claude-Code/Aider/SWE-Agent 这类产品的内部回归测试中；(c) 把 edit-level precision 用作「自我改进循环」中的 reward：在 self-distillation 阶段，只采样 precision>τ 的修复作为新训练数据，从而把「会精准改 bug」内化为模型的 default 行为。

PDB 的开源程度较高、复现门槛中等。论文公布了 Dataset 链接、Webpage、Code 仓库、Leaderboard 四件套，作者明确说明 PDB 框架 plug-and-play——研究者用 4 个 frontier 模型（GPT-5.1-Codex、Claude-Sonnet-4.5、Gemini-2.5-Pro、Claude-Opus-4.7）作为 bug 注入器 pool，把 BigCodeBench（Apache 2.0）、LiveCodeBench（MIT+CC-BY-4.0）、SWE-smith 的源程序转换为 5,751+484=6,235 条评测。论文中所有 prompt 模板（minimal / freeform、single-shot / iterative / agentic 共 6+ 变体）都在 Appendix E 完整给出，包含外部 API 调用格式与 system prompt，可以直接套用。算力门槛方面，主实验需 9 个模型 × 5,751 例 × 平均 1k token 输出 × 温度 1.0 的 API 调用，按 2026 年 4 月定价粗估在数千美元量级；如果只想用 3 个 generator + 5 个被测模型复现 Table 1，预算可压到 1k 美元以内。代码层面因为 $\text{map}(\cdot)$、$\text{essential}_U(\cdot)$ 等子程序在 Appendix C 给出了伪代码，复现难度中等——主要风险在于 LLM API 的 reproducibility（同一 prompt 同一温度下未必 100% 复现 unit 分数），以及 Python 测试执行环境（BigCodeBench 依赖较多 API 库，pip install 阶段易卡）。