你有没有想过这样一个问题：如果把一个AI扔进GitHub的代码海洋里，不给它任何指导、不告诉它该做什么，它能自己学会写代码吗？

听起来像科幻小说的情节，但Meta FAIR的研究团队真的这么干了。更神奇的是，他们发现AI不仅学会了，而且学得比用传统方法训练的AI还要好。

现在，来自Meta FAIR、Meta TBD Lab、伊利诺伊大学香槟分校(UIUC)以及卡内基梅隆大学(CMU)的研究团队想把这个思路用在写代码上。

研究团队在两个业内公认的代码修复难题测试集上验证了这个方法。结果让人眼前一亮：这个会自己跟自己玩的AI，表现居然超过了那些用人类精心整理的数据训练出来的AI。这意味着什么？意味着AI可能找到了一条不依赖人类知识的成长路径。当AI不再依赖人类经验时

考虑这样一个场景：你想训练一个能帮程序员修复代码错误的AI助手。传统的做法是什么？收集GitHub上成千上万的问题报告、对应的修复补丁、测试用例，然后让AI学习这些人类留下的经验。这就像让一个学徒通过阅读前辈的工作日志来学习手艺。

但这种方法存在一个根本性的限制：AI永远只能学到人类已经知道的东西。如果人类在某些领域还没有遇到过的问题，或者还没有想出的解决方案，AI就无从学起。更关键的是，那些被精心整理的训练数据——带有详细描述的问题报告、精准的测试用例——都需要大量的人工标注和筛选。随着AI能力的提升，这种依赖人类知识的方式可能成为进一步发展的瓶颈。

研究团队受到了AlphaGo和AlphaZero的启发。你可能还记得，AlphaZero仅仅通过知道围棋、国际象棋和日本将棋的基本规则，就通过自己和自己下棋，最终达到了超越人类顶尖棋手的水平。关键在于，它不需要学习任何人类棋谱，完全是通过探索游戏规则的各种可能性来提升自己。

那么，能不能把这个思路应用到软件开发上呢？研究团队提出的Self-play SWE-RL（简称SSR）系统就是对这个问题的初步回答。他们设计了一个系统，让同一个AI模型扮演两个角色：一个是"搞破坏者"，专门往代码里引入各种错误；另一个是"修复者"，负责找出并修复这些错误。通过这种自我对弈的方式，AI可以不断生成新的挑战，并从解决这些挑战的过程中学习。

一场AI与自己的游戏

整个系统的运作方式可以用一个比喻来理解：设想一个学习烹饪的学徒，他既要学会做出好菜，也要学会品尝和评判菜品的好坏。在这个系统中，AI就像这样一个学徒，但它面对的不是食材和炉灶，而是代码仓库。

系统的输入极其简洁：只需要一个包含了源代码和依赖项的Docker镜像。注意，这里不需要任何问题描述、测试用例或者运行测试的命令——所有这些通常需要人工准备的信息都不需要。AI需要自己去探索这个代码仓库，理解它的结构，发现如何运行测试，然后开始它的"游戏"。

当AI扮演"搞破坏者"角色时，它的任务是精心设计一个软件缺陷。这不是简单地把某个变量改个名字那么简单。它需要创建一个完整的"缺陷工件包"，这个包里包含了五个关键文件：

第一个是bug_inject.diff，这是一个补丁文件，记录了AI对代码做了哪些修改来引入缺陷。第二个是test_weaken.diff，这个文件记录了AI如何削弱或移除了某些测试，让这个缺陷能够"躲过"现有测试的检查——就像一个小偷不仅要潜入房间，还要想办法避开报警器。第三个是test_.sh，这是一个运行测试的脚本。第四个是test_files.txt，列出了需要重置到原始状态的测试文件。最后是test_parser.py，这是一个解析测试结果的Python脚本，能把测试输出转换成结构化的JSON格式，清楚地标明每个测试是通过还是失败。

为了让"搞破坏者"生成的缺陷有价值而不是随机破坏，研究团队设计了两种策略。第一种是"移除导向"策略：AI被指示去删除代码库中的某些重要代码块或文件，但要确保项目仍然能够运行，只是功能上出现了问题。这迫使"修复者"必须从一个残缺的代码库中重建丢失的功能。第二种是"历史感知"策略：AI可以查看代码仓库的Git历史记录，找出过去的某些改进或修复，然后有选择性地撤销这些改动。这种方式生成的缺陷往往更加真实，因为它们模拟了实际开发中可能出现的回归错误。

每个生成的缺陷工件都要经过严格的"一致性验证"。系统会检查多个方面：测试文件必须存在于原始仓库中；测试解析器必须能够正确工作；在原始代码上运行测试必须全部通过；引入缺陷后必须有足够数量的测试失败；削弱测试后，部分失败的测试应该变为通过。系统甚至采用了"反向变异测试"的技术：对于缺陷补丁中修改的每个文件，系统会单独恢复这个文件，然后运行测试。如果恢复某个文件能让至少一个失败的测试通过，说明这个文件的修改确实导致了缺陷；否则，验证就会失败。这确保了每个被修改的文件都是必要的，不存在无关的改动。

通过验证的缺陷会被交给"修复者"角色。但"修复者"看到的不是人类语言描述的问题报告，而是test_weaken.diff的反向补丁——也就是说，它看到的是一组新增或修改的测试要求，需要让这些测试通过。"修复者"会在一个被修改过的代码库中工作，这个代码库已经应用了缺陷补丁和测试削弱补丁，并且Git历史被清空以防止作弊。"修复者"通过推理和使用工具（如Bash命令和代码编辑器）来生成修复补丁。

这里引入了一个有趣的概念：高阶缺陷。当"修复者"在第一次尝试中没能成功修复某个缺陷时，它的失败尝试会被收集起来，在原始缺陷的基础上再应用这个失败的补丁，形成一个更复杂的"高阶缺陷"。这就像一个学徒在修理一个坏掉的机器时，不小心又弄坏了另一个部件，现在他需要同时修复两个问题。这种高阶缺陷使得训练分布更加丰富，让AI接触到更复杂、更接近真实开发场景的多步骤问题。

奖励机制：如何引导AI走向正确方向

在这个自我对弈的游戏中，如何判断AI做得好还是不好？研究团队设计了两套奖励机制，分别针对"搞破坏者"和"修复者"。

对于"修复者"，规则相对简单：如果生成的修复补丁能让所有测试通过（包括那些原本就应该通过的测试和因缺陷而失败的测试），就获得+1的奖励；否则获得-1的惩罚。这是一个明确的二元奖励，类似于考试要么及格要么不及格。

"搞破坏者"的奖励设计则更加微妙。它的核心目标是生成具有"理想难度"的缺陷——既不能太简单让"修复者"轻松解决，也不能太难以至于根本无法解决。系统引入了一个"解决率"的概念，即"修复者"在多次尝试中成功修复这个缺陷的比例。假设"修复者"对每个缺陷尝试8次，如果有2次成功，解决率就是25%。

奖励函数是这样设计的：如果缺陷没有通过一致性验证，"搞破坏者"得到-1.0的惩罚——这是最严重的失败。如果缺陷通过了验证，但解决率要么是0（完全无法解决）要么是1（太容易解决），"搞破坏者"会得到-0.8的惩罚。这是因为这两种极端情况都不能提供有效的学习信号。如果解决率在0和1之间，"搞破坏者"的奖励是1-(1+0.8)×解决率。这意味着解决率越低（但不为零），奖励越高，最大奖励接近1，出现在解决率刚好高于0的时候。

这种设计创造了一种对抗性的压力："修复者"希望解决率尽可能高（这样能获得更多正向奖励），而"搞破坏者"希望解决率尽可能低但不为零（这样能获得更高奖励）。这种对抗推动"搞破坏者"去生成那些恰好位于"修复者"当前能力边界的缺陷，既有挑战性又不至于完全无法解决。随着"修复者"能力的提升，"搞破坏者"也需要生成更复杂的缺陷来维持理想的解决率。

值得注意的是，虽然奖励函数在解决率为0或1时都给予惩罚，但-0.8的惩罚比完全失败的-1.0要轻。这样设计的用意是，即使在这些极端情况下，"搞破坏者"仍然能收到一些信息性的梯度信号，帮助它学习如何更好地校准缺陷难度。研究团队在论文的附录中通过数学分析表明，当使用一组样本（比如8次尝试）来估计解决率时，这个奖励函数会引导"搞破坏者"瞄准大约20%的目标解决率，在当前的参数设置下。

实验：AI能自我提升到什么程度？

研究团队选择了Code World Model（简称CWM）作为基础模型，这是一个拥有320亿参数的大型语言模型，专门针对代码生成任务进行了优化。关键的是，他们使用的是CWM的预训练检查点，即在应用强化学习之前的版本，这样可以公平地评估不同学习策略的效果。整个训练过程在512块NVIDIA H100 GPU上进行，其中64块用于模型训练，448块用于生成训练数据（称为"rollouts"）。训练持续了150个全局步骤，大约处理了25亿个token。

为了验证SSR的效果，研究团队在两个广泛使用的基准测试上进行了评估。第一个是SWE-bench Verified，包含了500个经过人工验证的真实软件问题，都来自GitHub上的实际项目。第二个是SWE-Bench Pro，包含731个公开的软件问题，这些问题更加复杂，更接近企业级的实际任务。关键的是，这两个基准测试中的问题都是用自然语言描述的，而SSR在训练过程中从未见过自然语言的问题描述——它只见过测试补丁。这使得评估结果特别能说明问题：AI确实学会了修复代码的通用能力，而不只是记住了训练数据。

研究团队设置了一个"人类数据基线"来进行对比。这个基线使用完全相同的模型和训练设置，唯一的区别是它能够访问人类编写的问题描述、测试用例和测试命令——就像传统的训练方法一样。实验结果相当令人振奋：在SWE-bench Verified上，基础模型（未经任何强化学习）的解决率是41.0%；经过人类数据基线训练后，解决率提升到49.0%；而使用SSR训练后，解决率达到了51.4%。在更难的SWE-Bench Pro上，差距更加明显：基础模型21.1%，人类数据基线25.3%，SSR达到28.9%。

这些数字背后的含义值得细细品味。SSR在SWE-bench Verified上比基础模型提升了10.4个百分点，在SWE-Bench Pro上提升了7.8个百分点。更重要的是，SSR在整个训练过程中始终优于人类数据基线，尽管它从未接触过任何人类标注的问题描述或测试用例。这表明，通过自我对弈生成的训练任务可能比人类精心整理的数据提供了更丰富、更有效的学习信号。

研究团队还进行了一系列消融实验来理解系统各个组件的作用。他们比较了三种变体：只训练"搞破坏者"（injection-only）、只训练"修复者"（repair-only）、以及完整的自我对弈（self-play）。结果显示，完整的自我对弈效果最好。只训练"搞破坏者"会导致性能下降，因为它没有从任何修复尝试中学习。只训练"修复者"虽然使用了早期自我对弈收集的缺陷数据，但效果也不如完整的自我对弈，因为它缺少了随着"修复者"能力提升而不断演化的任务分布。这说明持续的、在线的缺陷生成和修复过程对于持续改进至关重要。

关于不同的缺陷注入策略，研究团队比较了三种方法：直接注入（没有详细指导）、仅移除代码、以及移除代码与历史感知的混合策略。实验发现，直接注入的效果最差，因为它倾向于产生表面的单行修改（比如把某个变量从0改成1），这种缺陷提供的学习信号很弱。仅移除代码的策略效果更好，因为它迫使"修复者"重建丢失的功能，从而加深对代码库结构的理解。而混合策略（随机在移除和历史感知之间选择）效果最好，因为它利用了Git历史中的真实变更，生成了更多样化和更真实的缺陷模式。

研究团队还测试了一个简化版的奖励函数，它不考虑"修复者"的解决率反馈，只根据缺陷是否通过一致性验证给出二元奖励（+1或-1）。有趣的是，这个简化版本与包含解决率反馈的完整版本相比，效果差异很小。研究团队推测这是因为解决率反馈本身比较弱、带有噪音且不够明确——对于"搞破坏者"来说，很难从一个单一的噪声数字中学习影响解决率的众多因素。相比之下，"修复者"的目标更加明确（提高解决率），因此更容易从反馈中学习。

理论分析：为什么自我对弈可能遇到瓶颈

尽管实验结果令人鼓舞，研究团队也清醒地认识到这种自我对弈方法存在一些理论上的局限。他们在论文中进行了深入的数学分析，指出"搞破坏者"理论上存在几种"占优策略"，这些策略可以让它获得最大奖励，但却会阻止"修复者"学到有用的东西，从而让整个自我对弈停止进步。

第一种是"完全占优策略"。如果"搞破坏者"有足够的自由度来设置问题，它可以设计出这样的缺陷：无论"修复者"做什么，这个缺陷的解决率都会维持在理想的目标值（比如20%左右）。最简单的方式是修改测试本身，加入一个随机失败的测试：如果随机数小于20%就通过，否则失败。即使要求测试必须是确定性的，"搞破坏者"也可以使用"修复者"生成的代码的哈希值作为伪随机数的种子，这样对于不同的修复尝试会得到不同但确定的结果。甚至在测试固定的情况下，"搞破坏者"也可以在代码中添加类似的随机失败逻辑，然后把整个代码库混淆到"修复者"无法理解的程度。在这种情况下，"修复者"根本无法提升自己的能力。

第二种是"隧道视野策略"。即使"搞破坏者"的行动空间有限，它仍然可以专注于某个特定的参数来控制难度，而不去覆盖我们希望"修复者"学习的多样性。比如说，如果长乘法对"修复者"来说很有挑战，"搞破坏者"就可以只通过调整乘法操作数的长度来控制难度。即使"修复者"在学习，它也不可能学会处理无限长的乘法，因此会停滞在某个理想的准确率上，让"搞破坏者"达到最优状态。在软件工程的场景中，"搞破坏者"可以用递增的混淆程度来隐藏某一特定类型的缺陷，或者把多个中等难度的挑战串联起来，通过调整链的长度来达到理想难度，而不去覆盖这个狭窄通道之外的多样化挑战。

研究团队还讨论了自然语言在这个过程中的角色。他们引用了外交游戏研究的发现：在学习与人类合作时，纯粹的自我对弈不再能保证找到在与人类互动时表现良好的策略。这可以从"最后通牒博弈"中清楚地看出：理论上的最优策略是接受任何正数的提议，但人类的行为中包含了公平和自尊等因素，与纯理性的最优策略大相径庭。学习解决人类问题和修复人类代码中的错误，本质上是与人类合作的一个例子。在任何需要沟通的特定游戏中，都存在许多足够用的语言，其中许多比自然语言更高效，因为它们可以专门针对这个特定场景。虽然深度自我对弈可以提升沟通技巧，但很难保持并改进其人类自然语言的质量。

基于这些分析，研究团队提出了几个缓解措施。第一，"搞破坏者"应该根植于大规模且多样化的真实世界数据，比如所有的代码仓库或文档，目标是能够根植于真实数据并受其启发，熟练地提出自然且多样化的挑战。第二，不要让"搞破坏者"过度偏离初始的基于指令的策略，确保自我对弈不会达到"隧道视野"策略。"搞破坏者"仍然可以学习通过一致性检查的技能和一些难度校准能力。第三，不要试图在没有持续接触当前人类自然语言的情况下，通过自我对弈来提升自然语言技能。但从自我对弈中获得技术技能和代码世界模型的知识是可取且可行的。

局限与未来方向

研究团队对自己工作的局限性有着清醒的认识。首先，当前的设计在任务规范提示中提供了完整的测试要求，这可能使AI发展出"奖励黑客"行为——也就是针对特定测试进行过度优化，而不是真正具备修复缺陷的能力。虽然在当前的实验中没有观察到这种现象，但未来的版本应该探索将缺陷工件划分为公开测试和私有测试。

其次，当前框架完全依赖单元测试作为验证手段，但这只代表了真实软件工程活动的一个子集。更高层次的抽象，比如目标描述，可能是验证软件正确性的更可扩展方式。此外，实验只使用了单一的模型配置同时扮演两个角色，未来应该探索更大的混合专家模型，并考虑为每个角色使用独立的策略。

研究团队也坦诚分享了一些失败的尝试。他们曾试图在自我对弈中合成自然语言的问题描述，但生成的问题描述质量不稳定——往往直接复制测试补丁、逻辑不连贯、或者塌缩到相同的模式。他们认为这是由于32B参数的基础模型的自然语言能力有限，以及不透明的奖励信号无法有效促进质量或多样性。他们也尝试过针对特定代码仓库进行专门训练，但效果并没有超过在更多不重叠的仓库上训练的方案，可能是因为23个仓库提供的问题解决模式多样性不足。此外，尽管采用了一些先进的训练技术，他们仍然观察到扩大训练规模时的不稳定性，表现为输出乱码。这种不稳定性可能源于次优的超参数设置、长时间轨迹的内在挑战、模型预训练动态以及自我对弈学习的基本属性。解决这种不稳定性对于理解自我对弈如何扩展以及释放其全部潜力至关重要。

展望未来，研究团队提出了几个有前景的研究方向。第一是通过"播种"技术控制缺陷注入的分布，向"搞破坏者"提供上下文信息（如目标代码片段或特定文件）来引导生成过程走向多样性。第二是合成复杂的多步骤软件任务，比如主版本迁移或从头构建新的软件栈。第三是为长时间跨度的软件智能体开发更高效的训练范式，因为现实世界的软件项目（比如构建一个生产级的强化学习代码库）需要跨越数月的迭代开发，涉及数千个相互依赖的决策，而且无法仅通过单元测试来完全验证。

至顶AI实验室洞见

这项研究的意义在哪里？它标志着一个新方向的开端：训练能够超越人类能力的软件开发AI系统。传统的方法就像让学生只看教科书和作业答案来学习，学生永远不会超过教科书的作者。而自我对弈的方法更像是给学生提供了一个实验室和研究工具，让他们自己去探索、去发现、去创造新知识。

当然，这只是起步阶段。正如研究团队反复强调的，这是"迈向超智能软件智能体的第一步"。当前系统还存在许多局限性，比如完全依赖测试验证、可能的奖励黑客行为、训练的不稳定性等等。而且，理论分析表明，如果让自我对弈进行得太久太深入，可能会遇到一些根本性的问题，比如"搞破坏者"学会了钻空子而不是提出真正有价值的挑战。

但实验结果确实展示了这个方向的潜力。一个AI系统，仅仅通过接触原始的代码仓库，没有任何人类标注的问题描述或测试用例，就能够学会修复复杂的软件缺陷，而且学习效果超过了使用人类精心整理数据的传统方法。这暗示了一条路径：AI智能体可以从真实世界的软件仓库中自主积累大量学习经验，最终形成超越人类能力的系统——这些系统能够更深入地理解系统是如何构建的，解决全新的挑战，甚至从零开始自主创建新软件。

对于普通开发者来说，这项研究可能预示着软件开发工具的未来形态。你可以期待未来的AI助手不只是根据已有的模式来建议代码，而是真正理解代码库的深层结构，能够应对从未见过的问题类型，甚至在某些方面的理解超过人类程序员。对于软件行业来说，这可能意味着开发效率的又一次飞跃，以及解决当前难以处理的复杂软件工程问题的新方法。

论文地址：

https://arxiv.org/pdf/2512.18552

END

本文来自至顶AI实验室，一个专注于探索生成式AI前沿技术及其应用的实验室。致力于推动生成式AI在各个领域的创新与突破，挖掘其潜在的应用场景，为企业和个人提供切实可行的解决方案。

Q&A

Q1：Self-play SWE-RL（SSR）是如何工作的？

A：SSR让同一个AI模型扮演两个角色：一个是"搞破坏者"，专门往代码里引入各种错误并创建包含五个文件的缺陷工件包；另一个是"修复者"，负责找出并修复这些错误。通过这种自我对弈的方式，AI可以不断生成新的挑战，并从解决这些挑战的过程中学习，而不需要依赖人类标注的问题描述或测试用例。

Q2：SSR与传统的AI训练方法相比有什么优势？

A：传统方法需要大量人类标注的训练数据，如问题描述、测试用例等，AI只能学到人类已知的知识。SSR只需要原始代码仓库，通过自我对弈生成训练任务。实验表明，SSR在SWE-bench Verified上比基础模型提升了10.4个百分点，在SWE-Bench Pro上提升了7.8个百分点，而且始终优于使用人类数据的基线方法。

Q3：SSR目前存在哪些主要局限性？

A：主要局限包括：完全依赖单元测试验证，可能使AI针对特定测试过度优化；只使用单一模型配置；可能出现训练不稳定的情况；理论分析表明过度的自我对弈可能导致"搞破坏者"学会钻空子而不是提出真正有价值的挑战。此外，研究团队尝试生成自然语言问题描述时遇到了质量问题。