设想这样一个场景：如果你打算训练一个能够自动修复Bug的AI，第一步往往就是让它运行测试，验证修改是否正确。这听起来合情合理，但实际操作起来远比想象中复杂。

以代码训练中最关键的环节为例——每个需要AI试错的开源项目，都必须配备一套独立的Docker环境，精确到依赖库的版本、测试脚本以及运行工具。别说是企业内部的私有代码库，就算是有些年头的老项目，光是搭建环境这件事就足以让大多数人望而却步。

这个瓶颈，正是上海交通大学和字节跳动抖音集团团队在2026年6月发布的一项新研究arXiv:2606.28436试图解决的关键问题。论文的核心成果是一个名为Dockerless的系统——名字直截了当：不要Docker，无需特定运行环境，照样能判断AI生成的代码修复是否有效。

为什么“测试环境”始终是一个绕不开的难题

在深入探讨Dockerless的实现方式之前，必须先弄清楚一个前提：训练代码AI为何总是离不开测试环境？

训练一个“代码AI修复专家”大致分为两个阶段。第一步是让AI学习大量正确的修复案例，这被称为监督微调（Supervised Fine-Tuning），相当于为AI夯实基础。第二步是让AI自主尝试修复真实Bug，修对了给予奖励，修错了加以惩罚，这就是强化学习（Reinforcement Learning），让AI在实际试错中不断进步。

无论哪个阶段，都需要一个可靠的裁判来判定“这次修改是否正确”。目前最可靠的裁判就是让AI的修复结果实际跑一遍测试——通过即为正确，失败则为错误。但问题随之而来：要运行测试，就必须搭建环境。每个项目、每个依赖库、每个遗留系统都需单独构建。即便有自动化工具辅助，能覆盖的代码库范围依然相当有限。

换句话说，现有的训练方法只对那些恰好拥有完整Docker环境和测试套件的开源项目比较友好。而对于数量更为庞大的企业私有代码、二十年前的遗留系统，这套方案基本行不通。

研究团队意识到，不能继续沿着这条老路走下去。与其耗费大量精力搭建环境，不如想办法绕开环境本身。关键问题变成了：能否训练出一个足够聪明的“裁判”，让它仅通过阅读代码本身就能判断一个修复是否正确？就像一位资深工程师，不需要实际运行测试，光看代码就能判断修改是否合理——这个想法，正是Dockerless的出发点。

已有的“不跑测试”判断方法为何不够理想

在Dockerless出现之前，已经有人尝试过不依赖测试环境的方案，这类方法统称为“无环境验证器”。但这些方法都存在明显的短板。

第一类，直接使用大语言模型作为裁判。把问题描述、标准答案、AI的修复代码一并输入大模型，让它判断对错。但问题是，大模型只能看到代码文本，对整个代码仓库的上下文一无所知。这好比让一个从未进过厨房的人，仅凭菜谱来判断一道菜的成败——只靠文字描述，根本无法掌握火候、食材状态这些真实细节。

第二类，训练专门的验证器模型。例如SWE-Gym Verifier、R2E-Gym Verifier、OpenHands Critic、DeepSWE Verifier等。这些模型同样存在固有局限：打分时仅依赖表面信息，不会主动查阅代码仓库。

这里有一个典型的反例。假设标准答案是用辅助变量实现某个逻辑，而AI的答案采用了内联三元表达式，两种写法功能完全一致，但外观迥异。单纯比较文本，相似度会很低，表面层次的评分方法就会误判AI的答案为错误。但如果能深入查阅代码仓库，确认两种写法在实际调用中效果一致，才能得出正确判断。

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

Dockerless的工作原理：一个会主动提问的侦探

理解Dockerless的工作流程，可以用侦探破案来类比。一名优秀的侦探不会只盯着嫌疑人的照片反复比对，而是会主动前往现场勘查、查阅档案、访问证人、收集物证。当线索足够充分后，再综合判断。

Dockerless的工作方式同样分为两步。

第一阶段：生成调查问题

给定一个软件问题描述、一个标准参考答案、以及一个待判断的AI修复代码，Dockerless会先从问题和参考答案中推导出2到4个侦查问题。例如：“修复应该发生在代码仓库的哪个部分？”“修改后的代码应该实现什么功能？”“什么样的测试或断言能证明修复是正确的？”“仓库中还有哪些地方可能被这次修改影响？”

推导出问题后，Dockerless为每个问题单独分配一个“子侦探”，这些子侦探并行工作，各自使用只读的命令行工具（如文件查找命令find、文本搜索工具grep和rg等）在代码仓库中翻查线索。每个子侦探最终会返回一段包含代码证据的简短回答。

第二阶段：综合判决

在所有子侦探返回调查结果后，Dockerless将问题描述、参考答案、待判断的AI修复代码，以及所有问答对，一并交给最终的判决模型。判决模型综合所有证据，输出一个二进制裁决：1代表正确，0代表不正确。

为了获得更精细的连续评分，研究团队还巧妙地读取了模型输出“1”和“0”的概率值，用一个简单的公式将其转换为0到1之间的连续分数。分数越高，表明Dockerless越确信修复是正确的。

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

Dockerless的训练方法

有了这个架构设计，接下来核心问题就是：如何让Dockerless学会这套侦查与判断能力？

训练过程采用了“拒绝采样”方法，可以理解为“择优录取”。研究团队用一个强大的教师模型（GLM-5）作为初始侦探，在3700个拥有执行标签的代码问题上运行完整流程。所谓“有执行标签”，是指这些问题具备真实的测试环境，能通过运行测试得到确定的对错结论——这是数据收集阶段唯一需要利用测试环境的地方。

教师模型在每个问题上运行完整流程后，会给出一个裁决。研究团队只保留那些裁决结论与真实测试结果一致的轨迹，丢弃那些判断错误的。这一筛选过程确保了训练数据的质量：Dockerless只从正确的推理过程中学习，而不是从“运气好说对了”的案例里学。

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

利用Dockerless训练代码AI：两个阶段的完整流程

Dockerless训练完成后，便作为核心裁判，支撑起一套完全无需Docker环境的代码AI训练流水线。该流水线分为两个阶段，对应代码AI训练的标准步骤。

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

具体来说，研究团队在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和Multi-SWE-bench Flash）上，在SWE-bench Verified分支取得了81.0的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环境筛选轨迹训练的模型”在三个测试集上分别为60.0%、48.3%和33.9%，而“用Dockerless筛选无环境轨迹训练的模型”则为60.6%、47.7%和35.3%。两者表现非常接近，有时无环境版本甚至略胜一筹。

在RL阶段，以相同的SFT模型为起点，分别尝试三种奖励来源：用Dockerless打分的无环境版本、用DeepSWE Verifier打分的无环境版本、以及用真实测试执行打分的有环境版本。结果显示，使用真实测试执行的版本（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的Bug修复任务，问题是：图表偏移量文字的颜色应当使用标签颜色，而不是刻度颜色。

参考答案的写法是用辅助变量提取正确颜色，再赋值给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个百分点，这被认为是编译器反馈信息缺失所致。