SWE-at-Scale：把真实修复经验反向变成可扩展的编程测试题

导语

随着编程代理的能力不断提升，如何公平、稳定地评估它们，正在成为软件工程智能化发展的关键问题。真实世界中的 issue 虽然最具价值，但受限于项目实际的缺陷发生频率；与此同时，人工整理任务又需要大量时间。单纯依靠大模型预训练知识和启发式提示来“编造”Bug，则容易生成看似合理、却缺乏真实故障机制的测试题。

上海交通大学团队提出的 SWE-at-Scale，尝试从另一个方向解决这一问题：不直接凭空创造缺陷，而是研究真实项目曾经如何修复缺陷，再把修复过程反向转化为缺陷生成信号。

核心方法：从修复中学习如何制造问题

一项历史修复通常包含比表面代码变化更多的信息。它可能暗示 Bug 如何形成、哪些条件会触发故障，以及开发者最终采取了什么方式消除问题。SWE-at-Scale 的关键洞见是，修复监督不仅可以训练模型“如何改对”，也可以通过逆向处理，帮助模型学习“如何在合理上下文中引入错”。

其流程可以概括为：

• 从真实软件项目的历史 Bug 修复中提取缺陷模式；
• 将修复操作反转，形成面向 Bug 注入的监督信号；
• 把学习到的模式迁移到新的代码上下文；
• 反复采样并执行生成结果，构造带有验证条件的 SWE 任务；
• 用不同缺陷类型扩大同一代码样本的测试覆盖范围。

这使生成任务不再只是修改几行代码或添加一个表面错误，而是尽量保留真实软件故障所具有的因果关系和开发语境。

为什么同一份代码也值得反复生成

论文特别强调，SWE-at-Scale 能够从单一代码上下文中生成不同类型的 Bug，而且在每个文件上持续增加生成次数时，缺陷多样性仍能保持增长，实验观察甚至覆盖到每个文件 200 次生成。这一特点对于评估编程代理很重要：一个代理不能只记住某类固定模式，而需要应对不同触发条件、错误表现和修复路径。

根据论文摘要，实验显示，SWE-at-Scale 生成的任务相比现有合成方法更加多样、更加贴近真实软件问题，也能给当前编码代理带来更大的挑战。不过，素材未提供具体基准名称、模型成绩或任务数量，因此这些结论应理解为论文层面的总体实验判断，而非对某个系统的精确排名。

意义与局限

SWE-at-Scale 的价值在于把有限的真实修复记录转化为可重复利用的任务生成资源。对于编码代理研究者，它可以扩充训练后评估和压力测试中的问题类型；对于软件工程基准构建者，它提供了一种比纯提示式合成更有数据依据的路线。

但合成任务是否始终保留真实项目的复杂性，仍取决于修复数据质量、缺陷注入是否成功，以及生成结果能否被可靠执行和验证。未来，如何控制任务难度、避免生成模式重复，并确认代理解决的是实际问题而非数据痕迹，仍是这类方法需要持续回答的问题。

总体而言，SWE-at-Scale 把“修复 Bug”和“制造可测试的 Bug”连接起来，为规模化评估编码代理提供了一个具有现实软件依据的思路。

来源：Hugging Face Daily Papers