上交大与字节跳动联手：不用Docker也能训练出顶级代码AI：这项技术彻底打破了必须有测试环境的枷锁

这项由上海交通大学与字节跳动旗下抖音集团联合推出的研究，以预印本形式于2026年6月26日公开发布，论文编号为arXiv:2606.28436。有兴趣深入了解的读者可通过该编号在arXiv平台查阅完整论文。

代码AI的"阿喀琉斯之踵"

假设你开了一家专门培训程序员的学校，每当你想测试学员写的代码是否正确，都必须给每位学员单独搭建一套完整的开发环境——安装特定版本的编程语言、配置专属的依赖库、搭建运行测试的基础设施。不仅如此，还要给每一家委托方公司的每一套代码库单独建造一个"测试工厂"。这不但耗时耗力，更关键的是，如果委托方公司的代码库是私有的、遗留的，甚至根本没有完整的测试用例，这条路就完全走不通了。

这正是当前训练代码人工智能（AI）所面临的核心困境。现在最先进的代码AI，比如能够自动修复GitHub上真实软件Bug的智能体，其训练过程高度依赖一种叫做"执行验证"的机制——也就是让AI写出修复代码后，真的在对应的项目环境里跑一遍测试，用测试通不通来判断AI写得好不好。这个机制的问题在于，每个开源项目都需要一套独立的Docker容器（可以理解成一个隔离的虚拟计算机环境），其中包含精确匹配的软件依赖、测试脚本和运行工具。构建这些环境本身就是一项庞大的工程，即便是最先进的自动化流水线，也只能覆盖候选代码库中的一小部分。而那些私有企业代码库、历史遗留系统，则几乎完全无法通过这种方式来训练AI。

正是为了解决这个痛点，上交大与抖音集团的研究团队提出了一个名为**Dockerless**的系统。这个名字直接点明了它的核心主张：不需要Docker，不需要任何特定的运行环境，照样能判断一段AI修复代码写得对不对。

一、为什么"有没有测试环境"是个大问题

在深入了解Dockerless之前，有必要先弄清楚，为什么"测试环境"这件事这么重要，以至于整个AI训练都绕不开它。

训练代码AI的流程，就像是在培训一位新程序员。首先，你要给AI看大量"好的修复案例"，让它学习怎么解决Bug，这个阶段叫做监督微调（SFT）。然后，你让AI自己去尝试修复真实问题，对于它修复成功的给予奖励，失败的给予惩罚，让AI在反复试错中越来越厉害，这个阶段叫做强化学习（RL）。无论是哪个阶段，你都需要一个裁判——一个能可靠判断"AI这次修的对不对"的机制。

现在最靠谱的裁判就是执行测试：把AI写的修复代码塞进对应的项目环境里，运行官方测试用例，测试全过了就算修对了，有测试失败就算修错了。这个裁判很准，但代价极高。研究人员发现，即便有自动化工具帮忙，也只有有限比例的代码库能成功搭起可用的测试环境。更现实的问题是，企业内部的私有代码库、二十年前的遗留系统，根本就不可能为AI训练专门搭建一套这样的环境。

换言之，现有的代码AI训练方法，只适用于那些恰好有完整Docker环境和测试套件的开源项目，这是一个相当窄的范围。对于真实世界里数量更多的"长尾"代码库，这套体系完全失效。

研究团队意识到，这个问题的解法不在于如何更高效地搭建环境，而在于从根本上绕开对环境的依赖。关键突破口是：能不能训练出一个足够聪明的"裁判"，只通过阅读代码本身，就能判断一个修复是否正确——就像一位经验丰富的资深工程师，不需要跑测试，光看代码就能知道这个改法对不对？

二、已有的"不跑测试"的判断方法为什么不够用

在Dockerless出现之前，学界已经有人尝试过不依赖测试环境来打分，这类方法统称为"无环境验证器"（environment-free verifier）。现有的方法大致分为两类，但都存在明显局限。

第一类是直接用大型语言模型（LLM）来当裁判。把问题描述、参考答案（正确的修复代码）和AI生成的修复代码一起喂给一个大模型，让它判断AI的修复是对是错。这种方法的问题在于，大模型裁判只能看到代码文本本身，对整个代码仓库的上下文一无所知。就好比让一个从未进过厨房的人，只看着一份菜谱来判断一道菜做得好不好——光看文字描述，根本没法知道灶台火候、食材状态的真实情况。

第二类是训练专门的验证器模型。一些团队尝试训练一个专门用于判断代码修复好坏的模型，比如SWE-Gym Verifier、R2E-Gym Verifier、OpenHands Critic和DeepSWE Verifier等。这些模型同样存在相似的局限：打分时只依赖表面信息，不会主动去查阅代码仓库。

这里有一个非常典型的反例可以说明问题所在：假设一道题的"标准答案"是用辅助变量的方式实现了某个逻辑，而AI的答案是用内联三元表达式实现了完全一样的逻辑，两种写法功能等价，但代码外观截然不同。单纯比对代码文本，两者相似度极低，表面层面的评分方法会误判AI的答案是错的。但如果能深入查阅代码仓库，确认两种写法在实际调用链和边界情况处理上效果一致，才能作出正确判断。

研究团队正是基于这一洞察，设计了Dockerless：一个会主动"侦查"代码仓库的智能裁判。

三、Dockerless是怎么工作的：一个会问问题的侦探

理解Dockerless的工作方式，可以用侦探破案的框架来类比。当一名优秀侦探需要判断某人是否是嫌疑人时，不会只盯着嫌疑人的面部特征反复比对，而是会主动出去调查：去案发现场勘察、查阅相关档案、访问目击证人、收集物证。收集到足够的线索后，再综合所有证据作出判断。

Dockerless的工作方式与此如出一辙，分为两个阶段。

第一阶段是"出题调查"。给定一个软件问题描述、一个参考答案（正确的修复代码）和一个待判断的AI修复代码，Dockerless首先会从问题描述和参考答案中，推导出2到4个"侦查问题"。这些问题是有针对性的，例如："修复应该发生在代码仓库的哪个具体位置？"、"修改后的代码应该实现什么功能？"、"什么样的测试或断言能证明修复是正确的？"、"仓库中还有哪些地方可能因为这次修改而被影响？"推导出问题之后，Dockerless会为每个问题单独派出一个"子侦探"（sub-agent），这些子侦探并行工作，各自通过只读的命令行工具（比如文件查找命令find、文本搜索工具grep和rg等）在代码仓库里翻查线索，每个子侦探最终会返回一段有代码证据支撑的简短回答。

第二阶段是"综合判决"。在所有子侦探返回调查结果后，Dockerless把问题描述、参考答案、待判断的AI修复代码，以及所有问答对，一并交给最终的判决模型。判决模型综合所有证据，输出一个二进制的裁决：1代表这个修复是正确的，0代表不正确。为了得到一个更精细的连续评分（而非简单的对错二选一），研究团队巧妙地读取模型输出"1"和"0"这两个词的概率值，用一个简单的数学公式将其转换为0到1之间的连续分数。分数越高，说明Dockerless越确信这个修复是正确的。

这个设计的精妙之处在于，Dockerless不是在比较AI的答案和标准答案有多像，而是在用证据验证AI的答案是否真的解决了问题。这就像侦探不是在问"嫌疑人的长相和目击者描述有多像"，而是在问"现有的全部证据能不能指向这个人就是真凶"。

四、Dockerless是怎么被训练出来的

有了这个架构设计，下一个问题是：怎么让Dockerless学会这套侦查和判断的能力？

训练过程采用了一种叫"拒绝采样"（rejection sampling）的方法，可以理解为"留优去劣的示范学习"。研究团队使用一个强大的教师模型（GLM-5）作为初始侦探，在3700个有执行标签的代码问题上运行这套问题生成和调查判决流程。所谓"有执行标签"，就是说这些问题有真实的测试环境，能跑测试，能得到确定的对错结论——这是训练数据收集阶段唯一需要用到测试环境的地方。

教师模型在每个问题上跑完整套流程后，会给出一个裁决。研究团队只保留那些裁决结论与真实测试结果一致的轨迹，也就是"教师判对了的案例"，丢弃那些判错了的。这个筛选过程确保了训练数据的质量——Dockerless只从正确的推理过程中学习，而不是从"凑巧说对了"的偶然案例中学习。

为了防止正负样本比例严重失衡（错误修复的案例通常比正确修复的多得多），研究团队还将负样本与正样本的比例上限控制在4:1。最终的训练数据覆盖了3700个独立问题，每个训练案例都包含一段问题生成轨迹、若干子侦探的调查轨迹，以及一段最终判决轨迹。整个Dockerless系统使用一个共享的神经网络骨干（基于Qwen3.5-9B模型）统一训练，问题生成、子侦探调查、最终判决三个子任务共用同一套参数。训练在验证集上以标准的下一词预测损失为目标，最佳检查点在约150步优化后出现。

五、用Dockerless训练代码AI：两个阶段的完整流水线

Dockerless训练好之后，就可以作为核心裁判，支撑起一套完全不依赖Docker环境的代码AI训练流水线。这套流水线分为两个阶段，对应代码AI训练的两个标准步骤。

第一阶段对应监督微调。传统做法是让AI在带有测试环境的项目上跑，收集那些测试通过的修复轨迹作为训练数据，用这些"高质量案例"来教AI。新做法是：让AI在一个极简的Linux基础镜像上运行，完全不搭建任何项目专属环境，收集大批量的修复尝试轨迹，然后用Dockerless对每个轨迹的最终修复代码打分，只保留得分最高的那一批，用这批轨迹来训练AI。

具体来说，研究团队在SWE-Rebench-v2这个数据集上，用这种方式收集了16000条修复轨迹，然后让Dockerless对所有轨迹打分，只取得分最高的4000条作为最终训练数据。每条轨迹会经过2次独立的Dockerless评估，取平均分作为最终得分，以提升评分稳定性。

第二阶段对应强化学习。以第一阶段训练好的模型为起点，对于每个代码问题，让AI生成一组8条修复尝试，用Dockerless对每条修复打分，然后用一种叫GRPO的算法，将得分高的修复对应的策略方向强化，得分低的方向弱化。整个过程中同样完全不需要运行测试，也不需要任何项目专属的Docker环境。强化学习阶段总共训练了50步，每条修复同样经过2次独立的Dockerless评估取平均。

六、实验结果：数字说明了什么

研究团队在三个标准测试集上评估了整套系统，分别是SWE-bench Verified（英文Python代码库测试集）、SWE-bench Multilingual（多语言代码库测试集）和SWE-bench Pro（更难的长周期任务测试集）。评估指标是"问题解决率"，也就是AI正确修复了多少百分比的真实软件问题。

从验证器性能来看，Dockerless在专门构建的验证器评估基准上（776个样本，来自SWE-bench Verified的500个和Multi-SWE-bench Flash的276个），在SWE-bench Verified分支上达到了81.0的AUC分数（AUC是衡量分类器判别能力的指标，满分100），在Multi-SWE-bench Flash分支上达到了72.1分。对比一下其他方法的表现：最好的开源训练验证器DeepSWE Verifier在两个分支上分别只有66.7和62.9分，差距超过14分；GPT-5.4、GLM-5等顶级商业大模型零样本作裁判，在两个分支上的最高分别是75.9和63.9，同样明显低于Dockerless。

从下游代码AI性能来看，以Qwen3.5-9B为基础模型，经过两阶段完全无环境训练后得到的Dockerless-RL-9B模型，在三个测试集上分别达到了62.0%、50.0%和35.2%的问题解决率，比基础模型分别提升了2.4、8.7和2.9个百分点。这个结果超越了所有同等规模（参数量低于100亿）的开源代码AI专项模型：比SWE-Lego-8B高出约20.8、31.0和19.1个百分点，比SWE-Gym-7B和SWE-Dev-7B的差距则更为悬殊。

更值得关注的是横向对比。研究团队特意设计了一组受控实验，来分离SFT阶段和RL阶段各自的贡献，并与使用真实测试环境的对照组比较。

在SFT阶段，"用真实Docker环境筛选轨迹训练的模型"（Env-SFT-9B）在三个测试集上分别达到60.0%、48.3%和33.9%，而"用Dockerless筛选无环境轨迹训练的模型"（Dockerless-SFT-9B）则是60.6%、47.7%和35.3%。两者表现非常接近，有时无环境版本甚至略胜一筹。

在RL阶段，以相同的SFT模型为起点，分别尝试了三种奖励来源：用Dockerless打分的无环境版本（Dockerless-RL-9B）、用DeepSWE Verifier打分的无环境版本、以及用真实测试执行打分的有环境版本（Test-Execution RL）。结果显示，使用真实测试执行的版本（62.4%、51.3%、35.7%）仍然略好于Dockerless版本（62.0%、50.0%、35.2%），差距约在0.4到1.3个百分点之间，属于非常微小的差异。而Dockerless版本则以1.4到2.7个百分点的优势明显胜过DeepSWE Verifier版本。

七、细节中的魔鬼：验证问题数量和计算开销

研究团队还仔细研究了一个实用问题：子侦探应该调查多少个问题，才能让Dockerless的性能最优？

对验证问题数量K从0到8逐一测试的结果揭示了一个清晰的规律：K等于0时（完全不调查，直接判断），AUC为78.3分；K从1增加到4时，AUC稳步提升，在K等于4时达到最高的81.0分；K继续增加到6和8时，AUC反而下滑到79.6和80.3，出现了波动。这说明，适量的调查问题能切实帮助裁判作出更准确的判断，但问题太多之后，新增的调查结果往往是冗余甚至带来噪音的，边际收益递减。因此，最终Dockerless在推理时设定生成2到4个验证问题，在准确性和计算效率之间取得平衡。

在计算开销方面，研究团队以7680条强化学习训练轨迹为样本，分析了三种奖励来源下每条轨迹的耗时分解。结果显示，AI生成修复轨迹本身平均耗时约2308秒，是整个流程的绝对主体。相比之下，奖励计算的额外耗时为：DeepSWE Verifier增加41秒（约1.7%），真实测试执行增加83秒（约3.5%），Dockerless增加180秒（约7.2%）。虽然Dockerless因为需要主动调查代码库，比简单查表的方法慢一些，但其额外开销仅占总时间的7.2%，属于可以接受的范围。此外，从总耗时的分布图来看，三种奖励来源的总耗时分布几乎完全重叠，都呈现出以2400到3000秒为主体的单峰分布，并有向硬超时方向延伸的长尾。这说明整个流程的瓶颈是那些运行缓慢、接近超时的修复轨迹，而非奖励计算本身。

八、一个真实案例：同样的逻辑，不同的写法

论文中展示的一个真实案例，生动说明了Dockerless的核心价值。这是一个来自matplotlib（Python数据可视化库）的Bug修复任务，问题是：图表偏移量文字（offsetText）的颜色，应该使用标签颜色（labelcolor），而不是刻度颜色（tick.color）。

参考答案（正确修复）的写法是：先用辅助变量提取正确颜色，再将辅助变量赋值给offsetText。AI生成的候选修复则是：直接用内联三元条件表达式，在赋值时就完成颜色逻辑的判断。两种写法语义完全等价，但代码结构差异明显。

文本相似度比较的结果是0.468分（满分1.0），大幅偏低，因为两段代码的字面形式差异很大。DeepSWE Verifier给出的分数只有0.035，几乎直接判定为错误修复。而Dockerless派出两个子侦探分别调查了两个问题。第一个子侦探确认了AI的修复确实同时更新了XAxis和YAxis两个初始化路径，这与标准修复一致。第二个子侦探确认了AI的修复正确保留了"inherit"继承语义——当labelcolor设置为"inherit"时回退到tick color，否则使用显式设置的labelcolor颜色。基于这两条来自代码库的实证线索，Dockerless给出了0.996的高分，与真实测试执行结果（正确，满分1.0）高度吻合。

九、无环境训练的边界：哪些语言还是差了点

当然，没有任何方法是万能的。研究团队通过细致的分语言分析，诚实地指出了无环境训练方法的局限边界。

在Python、Go、JavaScript、Java、PHP、Ruby这几门高使用量语言上，有环境训练与无环境训练的效果差异普遍在正负2.5个百分点以内，两者基本旗鼓相当。然而在Rust和C这两门语言上，有环境训练的效果分别高出约7.0和13.3个百分点，差距相当显著。

研究团队分析，这个差距的根本原因在于：Rust和C都是强编译型语言，编译器本身就是一个非常强力的调试助手。在有环境的条件下，AI修复代码时能实时看到编译器报出的类型错误、链接失败等信息，这些信息极大地帮助AI在多轮尝试中收敛到正确答案。而在无环境的条件下，AI只能从源代码本身推断这些信息，缺失了这一信道。研究团队指出，这个差距的解法可能不是收集更多有环境的训练数据，而是想办法在无环境流水线中引入某种形式的编译器反馈模拟，这被留作未来工作。

说到底，Dockerless这项研究做到的事情是：证明了一件以前被认为必须依赖测试执行的任务——判断代码修复的正确性——可以通过智能的代码库调查来接近等效地完成。这个结论在工程实践上的意义相当深远。企业里庞大的私有代码仓库、年久失修的遗留系统、没有完整测试套件的开源项目，都可能因此受益于高质量的AI辅助。训练一个好的代码AI，不再必须先为每个代码库搭建一套复杂的测试基础设施。

当然，这并不意味着测试执行从此变得不重要。真实的测试环境在某些场景下仍然提供了无可替代的精确信号，尤其是编译型语言的强编译器反馈。但Dockerless为那些无法依赖测试环境的大多数场景，提供了一条切实可行的替代路径。

对于关心AI辅助编程未来发展的读者来说，一个值得思考的问题是：随着这类无环境验证技术的成熟，代码AI的训练数据来源会如何演变？私有企业代码库是否会成为下一批大规模训练语料？企业代码安全与AI训练数据之间的张力，将会如何影响这项技术的实际落地？这些问题目前尚无定论，但Dockerless的工作无疑推开了这扇大门的一条缝。对这项研究感兴趣的读者，可通过arXiv编号2606.28436查阅完整论文，原文包含了完整的提示词模板、训练超参数配置以及更详细的消融实验结果。

---

Q&A

Q1：Dockerless是什么，它解决了什么问题？

A：Dockerless是由上海交通大学与字节跳动联合研发的代码修复验证器，它能在不搭建任何项目专属Docker测试环境的情况下，判断AI生成的代码修复是否正确。传统方法需要为每个代码库单独配置测试环境，耗时费力且无法覆盖私有或遗留代码库，Dockerless通过主动调查代码仓库内容来替代执行测试，绕开了这一工程瓶颈。

Q2：Dockerless不运行测试，怎么知道代码修复是否正确？

A：Dockerless采用"侦探调查"式的工作方式：先从问题描述中生成2到4个关键侦查问题，再为每个问题派出一个独立的子智能体，在代码仓库中用只读命令行工具查找证据，最后将收集到的所有问答证据交给判决模型综合分析，输出一个0到1之间的置信评分。这种方式让它能识别出功能等价但写法不同的修复，而不是简单比较代码文字相似度。

Q3：Dockerless训练的代码AI和传统方法训练的效果差多少？

A：在SWE-bench Verified、Multilingual和Pro三个标准测试集上，用Dockerless完全无环境流水线训练的Dockerless-RL-9B模型，与用真实测试执行训练的对照模型相比，差距约在0.4到1.3个百分点之间，表现非常接近。但在Rust和C这类强编译型语言上差距更明显，约7到13个百分点，这被认为是编译器反馈信息缺失所致。