阿里巴巴与上海交通大学联手：让AI编程助手像老师一样越用越聪明

这项由阿里巴巴集团AI数据团队与上海交通大学EPIC实验室联合完成的研究，于2026年6月5日以预印本形式发布，论文编号为arXiv:2606.07412，感兴趣的读者可通过该编号查阅完整原文。

软件工程正在经历一场悄悄发生的革命。过去几年里，人工智能在写代码、改Bug方面的能力突飞猛进，让不少工程师既兴奋又有些忐忑。然而，训练这些"AI程序员"本身就是一件颇为头疼的事——你需要大量高质量的真实编程任务来让它们练习，而这种任务偏偏既稀少又昂贵。研究团队把这个困境形象地比作：你想培养一位优秀的厨师，却发现好食材永远不够用。

现有的解决方案通常是"人工造题"——让人或机器按照固定的模板往代码里塞Bug，再让AI去修。这就好比厨师学校只练一道菜，练来练去都是同一个配方，无论这位厨师本人已经掌握到什么程度，新作业永远和他的实际短板毫无关系。AI在哪里卡壳、哪里进步了，那些"出题机器"完全不知道，更不会据此调整出题策略。

正是为了打破这个僵局，研究团队提出了一个叫做"Socratic-SWE"的全新框架。这个名字来源于古希腊哲学家苏格拉底的教学法——苏格拉底不直接告诉学生答案，而是通过一问一答，引导学生自己发现知识边界、自行推进理解。Socratic-SWE的核心思路与此异曲同工：让AI从自己解题的过程中提炼经验，再用这些经验为自己"量身定制"下一批练习题，如此往复，螺旋式成长。

一、AI编程助手为什么"越练越停滞"

要理解这个研究解决了什么问题，先得弄清楚AI编程助手是怎么学习的。

现阶段最流行的训练方式叫做"强化学习"——简单说，就是让AI在真实的代码仓库里反复尝试修Bug，每次修完之后跑一遍测试，测试通过了就给它"加分"，失败了就"扣分"。AI在这种反复试错中慢慢学会更好的修复策略，就像一个学生在做了大量练习题之后越来越会考试。

这个过程听起来很美好，但有一个致命的瓶颈：题目从哪里来？真实的Bug修复任务数量有限，质量参差不齐，远远不够喂饱大规模训练。于是研究者们想出了"自动造题"的办法，比如随机往代码里插入错误、用语言模型改写代码逻辑等等。问题在于，这些方法造出来的题目和AI当前的能力水平完全脱节。AI已经掌握的简单修复技巧，这些题目还在反复考；AI真正卡壳的高难度问题，这些题目却根本触及不到。

更糟糕的是，每次训练结束后，AI解题过程中留下的"草稿纸"——也就是它一步步检查代码、修改文件、运行测试的完整记录，统统被扔掉了，只留下最后一个分数。那些草稿纸里其实藏着大量信息：AI在哪个步骤反复出错？哪种修复策略总是引发连锁崩溃？哪些代码结构让它束手无策？这些信息白白浪费，而下一批练习题的出炉完全不会参考这些教训。

Socratic-SWE的答案是：别丢那些草稿纸，好好读一读，然后根据草稿纸上暴露的问题，专门出针对性的新题。

二、把"草稿纸"变成"教学大纲"：技能注册表的诞生

Socratic-SWE整个流程的核心枢纽，是一个叫做"Agent Skill Registry"（智能体技能注册表）的东西。可以把它理解成一份不断更新的"错题本"，只不过这份错题本不是简单记录"第3题做错了"，而是深度分析"为什么总是在处理作用域转换的时候出差错，具体是哪一类写法触发了问题"。

这份错题本的建立分三个步骤完成。第一步，把当前的AI拿去解一批现有题目，把它解题的完整过程——每一次文件检索、每一次代码修改、每一次测试结果——全部记录下来，形成一个庞大的"解题轨迹"档案库。这些轨迹被分成两类：成功解决问题的"胜利轨迹"和以失败告终的"失败轨迹"，两类都保留，因为失败轨迹往往比成功轨迹更有教学价值。

第二步，用另一个能力更强的AI（研究中使用了Qwen3.6-27B这个270亿参数的大模型）来阅读和分析这些轨迹档案。这个分析员AI的任务是从中提炼出"规律性的行为模式"：成功轨迹里有哪些可以迁移的通用策略？失败轨迹里有哪些反复出现的错误和补救思路？每条提炼出来的技能被整理成一份结构化的小文档，包含技能名称、适用场景和具体操作步骤。

第三步，把重复或高度相似的技能合并去重，最终形成一个简洁但信息密集的技能注册表。

这份技能注册表的意义在于，它不是凭空生成的理论知识，而是从AI自身的实际行为中蒸馏出来的经验总结，精准对应AI的真实能力边界。研究还发现，用来提炼技能的分析员AI不需要特别强大——即使用和被训练的AI同样大小的模型（90亿参数的Qwen3.5-9B）来做自我分析，最终结果也只比用270亿参数的大模型低0.6个百分点。这说明技能提炼框架本身才是关键，而不是分析工具有多厉害。

三、根据"错题本"出新题：技能引导的任务生成

有了技能注册表，下一步就是根据它来出题。出题的任务由"生成器"（Generator）承担，而生成器和解题的"求解器"（Solver）用的是同一套模型——就像一个人同时扮演老师和学生，这节课当老师出卷，下节课当学生做题。

生成器拿到一个代码仓库和一条技能说明，就开始在这个真实的代码仓库里"种Bug"：找一个合适的代码位置，引入一个有针对性的、符合那条技能所描述的弱点类型的错误，同时设计好验证方式——也就是能精准检测出这个Bug存在与否的测试用例。

但不是每道题都能直接进入训练集。每一道候选题必须通过四关严格审核，像流水线质检一样逐关把关。第一关检查格式——题目描述和验证代码是否语法正确、格式规范。第二关检查接地性——题目里提到的代码文件和函数，在这个真实仓库里是不是真的存在，不能凭空捏造。第三关检查执行稳定性——那套验证测试能不能稳定运行，多次重复结果一致，不会因为环境问题随机报错。第四关检查语义有效性——这道题确实需要修复才能通过测试，且确实存在一个合法的正确答案，不能是无解题，也不能是不修也能过的假题。只有四关全部通过，这道题才能入库成为训练材料。

这个四关过滤机制解决了一个长期困扰AI训练的问题：自动生成的题目往往质量参差不齐，有的根本跑不起来，有的无论怎么答都算对，这样的垃圾题目进入训练集只会污染模型。严格过滤保证了每一道进入训练的题目都是真实可执行、有明确答案的有效练习。

四、不只看"题目难不难"，更看"做这题有没有用"：梯度对齐奖励

通过四关审核只是"这道题有没有做的资格"，但还有另一个问题：做这道题对AI的提升有没有实际帮助？

这里研究团队引入了一个颇为精妙的评分机制，叫做"梯度对齐奖励"（Gradient-Aligned Reward）。要理解这个机制，先要明白强化学习里的"梯度"是什么。

每当AI在一道题上练习，背后的数学运算会产生一个"更新方向"——告诉模型的权重参数应该往哪个方向微调才能做得更好。这个更新方向就叫梯度。不同的题目会产生不同的更新方向：有些题目产生的更新方向让AI在更广泛的任务上变强，有些题目产生的更新方向则是偏门的，只对特定情况有帮助，甚至可能影响其他能力。

研究团队的做法是维护一套"参照题库"——一批来自BeyondSWE数据集、经过人工验证的高质量标准题。先算出AI在这批标准题上学习应该产生的"理想更新方向"，把这个方向记录下来作为基准。然后，对于每一道候选练习题，计算AI做这道题会产生什么样的"更新方向"，再看这两个方向的吻合程度。吻合得越好（用余弦相似度来衡量，就是两个方向越接近），这道题的得分就越高，越优先进入训练集。

这个设计的直觉非常简单：做有助于在标准评测上变强的题，而不是做乍看起来很难但实际上练的是偏门技巧的题。实验证明，这种设计比其他几种替代方案都要好——比纯粹选"难度适中的题"（方差奖励）高1.6个百分点，比选"最难的题"（硬度奖励）高3个百分点。更有意思的是，用余弦相似度（只看方向）比用内积（同时考虑方向和大小）还要好1个百分点，原因是内积会偏爱那些涉及大量文件的复杂修改任务，但这类任务产生的大梯度很多时候并非因为它们对模型帮助大，而只是因为任务本身复杂度高。

五、求解器怎么学习：分解式奖励的巧妙设计

入库的训练题交给求解器来练习。求解器在真实的代码沙箱环境里和仓库互动，检查文件、修改代码、运行测试，最后提交一个修复补丁。

评分方式同样精心设计，避免了只用"通过/不通过"这种粗暴的二元判断。研究团队把修复质量分解成三个维度：第一个维度是全面修复得分——所有原本失败的测试都通过了，同时所有原本通过的测试没有因为修改而崩溃，这是最高奖励，权重0.5；第二个维度是部分修复率——修好了多大比例的失败测试，权重0.3；第三个维度是回归防护率——有多大比例的原本正常功能没有被修复操作意外破坏，权重0.2。

这种分解式评分的意义在于，真实的软件修复很少非黑即白。一个修复方案可能修好了七成的问题，同时没有引发新问题，这比修好了一点点但破坏了一堆功能的方案要好得多。二元奖励无法区分这些情况，求解器就无从知道自己的方向是对还是错。分解式奖励则能给出更细腻的信号，让学习过程更高效。

具体的训练算法也做了适配，采用了GDPO（组奖励解耦归一化策略优化）方法。简单说，就是三个维度分别在各自的组内做归一化处理，避免它们之间的数值量级差异互相干扰，然后再合并成一个综合优势值来指导模型更新。

六、实验结果：三轮迭代，四个榜单全面领先

研究团队在四个权威基准测试上验证了Socratic-SWE的效果，并与五种当时最先进的自我进化方法做了公平对比——所有方法使用完全相同的模型（Qwen3.5-9B，90亿参数）、相同的代码执行工具（mini-swe-agent）和相同的训练预算（每轮12000道题，共三轮，总计36000道题）。

基础模型在四个榜单上的初始成绩分别是：SWE-bench Verified（500道经人工验证的真实GitHub问题）42.60%，SWE-bench Lite（300道筛选题）29.67%，SWE-bench Pro（731道企业级复杂任务）17.24%，Terminal-Bench 2.0（沙箱终端操作任务）10.11%。

五种对比方法中，R-Zero用多数投票作为奖励，短暂提升后反而下降到基础模型以下，说明投票式奖励对于需要局部正确的代码修复任务太过粗糙。SPIRAL和Absolute-Zero在第二轮达到峰值后第三轮开始退步，暴露出缺乏执行验证时自我博弈容易陷入"刷分"死局的问题。Socratic-Zero尽管用了一个3970亿参数的超级大教师模型来指导出题，却在第三轮略有下滑，说明外部教师的理解终究有天花板，而且信息在层层传递中有损耗。SSR（自我博弈SWE强化学习）是最强的对比基线，三轮下来在Verified榜单上提升了4.40个百分点，但增长速度逐渐放缓。

Socratic-SWE三轮结束后的成绩是：SWE-bench Verified 50.40%（+7.80），SWE-bench Lite 36.67%（+7.00），SWE-bench Pro 22.85%（+5.61），Terminal-Bench 2.0 14.61%（+4.50）。不仅每个榜单的绝对成绩最高，而且增长幅度在三轮之间持续加速，没有出现其他方法那种先快后慢的疲态。

研究团队还把训练延长到五轮，观察长期趋势。Socratic-SWE在第四轮仍然上升到51.60%，第五轮达到52.00%才趋于平稳；而SSR到第五轮只达到48.00%。两个方法最终都会饱和，原因是固定的仓库池子里的新信息被逐渐榨干，技能注册表越来越难找到新的盲点可以攻克。但Socratic-SWE饱和得更晚、饱和点更高，说明它从同等数量的数据中提取了更多有价值的训练信号。

Terminal-Bench 2.0的结果格外值得关注，因为这个测试考察的是完全不同类型的任务——在命令行沙箱里完成文件操作、环境配置、命令链式执行等偏向系统操作的任务，和代码仓库修复有明显区别。Socratic-SWE在这个榜单上提升了4.50个百分点，而大多数对比方法几乎没有提升，SSR也只提升了2.25个百分点。这表明从解题轨迹中提炼出来的技能不只是"修Bug技巧"，而是更通用的智能体行为能力，能够跨任务类型迁移。

七、消融实验：每个零件都不多余

为了弄清楚Socratic-SWE的哪些设计真正起了作用，研究团队做了一系列"拆零件"实验，在第三轮训练结束时分别测试去掉某个部件会发生什么。

去掉技能注册表——也就是让生成器随机出题，不再参考从轨迹里提炼出来的技能——Verified成绩从50.40%跌到46.20%，下降了4.20个百分点。这是所有消融实验里最大的一次跌幅，说明"根据AI自身弱点定向出题"是整个框架最核心的价值所在。

保留技能注册表但把自动提炼换成人工编写的技能分类——Verified成绩跌到48.00%，下降2.40个百分点。手工编写的技能分类通常是高层次的抽象描述，无法捕捉到AI实际行为中那些细碎但关键的模式，比如"先用grep搜索再编辑文件"这种AI自己摸索出来的特定操作习惯，这种信息只存在于真实轨迹里，人工总结很难触及。

把GDPO替换回更基础的GRPO训练算法——Verified成绩跌到48.60%，下降1.80个百分点。这证明了分解式奖励对于处理"部分修好"这种中间状态确实更有效，粗糙的二元奖励会让模型丢失大量有用信号。

八、成本到底高不高：额外开销只有8.4%

梯度对齐这个机制听起来很精妙，但一个自然的疑问是：计算这些梯度要多花多少时间和资源？研究团队给出了详细的时间账单。

在8块A100-80G显卡的配置下，每轮训练总计耗时约15小时。其中生成器出题加验证占4.2小时，求解器解题加执行反馈占7.8小时，模型权重更新占1.7小时。梯度对齐的两个步骤——计算基准梯度方向（在100道验证题上各跑8次，共800次推理）占0.5小时，对每道候选题打分占0.8小时——加起来总共1.3小时，只占整体训练时间的8.4%。

而且打分步骤并不完全是额外成本，因为在做第四关语义验证的时候，AI已经在候选题上跑过若干次推理了，这些推理结果可以直接复用来估算梯度，不需要重新跑。三轮训练合计额外消耗约3.9小时的计算时间，相当于45小时总预算的不到9%。对比之下，Socratic-SWE比直接把所有验证通过的题都扔进去训练的SSR方法高出3.40个百分点，说明这8.4%的额外开销换来了显著的效率提升。

说到底，Socratic-SWE做的事情用一句话可以概括：把AI自己留下的"草稿纸"变成它下一堂课的"教案"。这个听起来简单的想法，背后其实解决了AI训练领域一个长期被忽视的浪费问题——我们花了大量算力让AI解题，却把解题过程中最有价值的信息直接扔掉了。

从结果来看，这个方向的潜力相当可观。Socratic-SWE用和对手完全相同的算力预算，在所有四个测试上都取得了最好的成绩，而且增长势头在三轮之后依然比对手更强劲。更值得关注的是Terminal-Bench 2.0上的迁移效果，表明这套从代码修复任务里提炼出来的经验，能够延伸到更广泛的计算机操作场景，这对于打造真正通用的AI编程助手来说是一个好信号。

当然，这项研究也清醒地指出了自身的局限：如果仓库池子固定不变，技能注册表总有一天会把所有盲点都覆盖掉，到那时成长就会停滞。下一步需要研究的方向包括如何持续引入新仓库、如何把一个领域学到的技能迁移到另一个领域，以及如何在没有可靠测试的代码库上运用类似思路。

归根结底，这项研究给了一个让AI助手真正"越用越聪明"的实现路径，而不只是堆砌更多固定训练数据。有兴趣深入了解技术细节的读者，可以通过arXiv编号2606.07412找到完整论文。

---

Q&A

Q1：Socratic-SWE框架中的技能注册表是怎么建立的？

A：技能注册表的建立分三步：先让AI在现有题目上解题，记录完整解题过程；再用另一个分析模型阅读这些记录，从成功轨迹里提炼可用策略，从失败轨迹里总结错误规律；最后把相似的技能合并去重，形成一份精简的经验文档。这份文档直接来自AI自身行为，精准对应它的真实能力边界。

Q2：Socratic-SWE的梯度对齐奖励和普通的"选难度适中的题"有什么区别？

A：普通的难度筛选假设"难度适中的题"就等于"有学习价值的题"，但在软件修复领域很多难题只是因为涉及冷僻知识而显得难，做了对提升通用能力没什么帮助。梯度对齐奖励直接衡量"做这道题会让AI往对的方向进步多少"，与一批人工验证的标准题的学习方向越接近，这道题的优先级越高，从而把"有没有用"和"难不难"区分开来。

Q3：Socratic-SWE在Terminal-Bench 2.0上的提升说明了什么？

A：Terminal-Bench 2.0考察的是命令行操作、文件管理等系统任务，和代码仓库修复有明显差别。Socratic-SWE在这个榜单上提升了4.50个百分点，远超其他大多数方法，说明从代码修复轨迹里提炼出来的技能不只是具体的修Bug技巧，而是更通用的智能体行为能力，能够跨任务类型迁移应用。