PreciseCoder：让代码模型少改代码，也更会找 bug

导语

对于代码模型来说，单元测试是一个直接而便宜的强化学习信号：程序最终通过测试，模型就获得奖励。但“结果正确”并不等于“修改合理”。一个模型可能通过大范围重写、碰巧绕过测试，甚至修改原本没有问题的代码来获得同样的分数。PreciseCoder 关注的正是这一被最终通过率掩盖的问题：模型是否准确定位了 bug，并以尽可能小的改动完成修复。

单元测试奖励的盲区

论文分析发现，仅依赖单元测试进行后训练，会带来两类倾向。第一，模型更容易扩大编辑范围，不只修改导致失败的代码行；第二，在面对本来正确的程序时，模型可能仍然“发现”并修改并不存在的 bug。对于真实软件工程而言，这种行为会增加回归风险，也会让代码审查、合并和后续维护变得更困难。

这说明，测试通过率并不能完整衡量代码修复质量。它回答的是“程序现在能否通过给定测试”，却没有回答“模型是否改对了地方”“补丁是否足够小”以及“修改是否忠实于原始问题”。

PreciseCoder 如何处理

PreciseCoder 在传统单元测试奖励之外，引入了一个面向语义验证和局部编辑的信号。直观来看，模型不仅要让程序通过测试，还要证明自己的修改与 bug 位置和修复目标相匹配。训练目标因此从单一的结果导向，扩展为结果、定位与编辑范围的共同约束。

论文在 4B、9B 和 27B 模型上进行实验，报告称该方法将平均编辑行数从 7—15 行降至约 3 行，同时保持与仅使用单元测试训练相当的通过率。换言之，模型并非通过牺牲修复成功率来换取谨慎，而是在相近成功率下减少了不必要的改动。

核心发现

• 更小的补丁不必以更低通过率为代价。 局部编辑信号帮助模型在保持测试表现的同时收缩修改范围。
• 训练分布可以更有限。 模型只用单行 bug 进行训练，仍被报告能够迁移到仓库级程序修复，并以更小补丁解决更多问题。
• 推理过程具有迁移价值。 研究称，将 9B PreciseCoder 模型的推理轨迹提供给 GPT-5.6 Sol、Qwen3.8-Max 等更强模型后，后者的编辑精度提升了 4.6—12.4 个百分点，且不需要额外训练。
• 奖励会改变思考方式。 对思维轨迹的语言分析显示，新的奖励鼓励模型逐行分析、明确指出可疑代码行，并围绕 bug 建立较为一致的假设。

意义与局限

PreciseCoder 的价值不只是让代码模型“修得更准”，也在于重新定义了自动修复的评价标准：通过测试是底线，定位准确、改动克制和语义一致同样重要。对于代码代理和仓库级软件工程任务，较小的补丁通常意味着更低的审查成本、更小的回归风险，以及更容易被开发者接受的修改。

不过，现有素材主要呈现论文摘要和项目页面信息，尚未提供数据集构成、语义验证机制的完整实现细节，或不同任务上的逐项实验结果。因此，这些结论应理解为论文报告的研究发现，而不是对所有代码修复场景的普遍保证。后续仍需要观察该奖励在复杂、多文件依赖和测试覆盖不足的项目中的表现。

来源：Hugging Face Daily Papers