这项由上海交通大学与字节跳动旗下抖音集团联合完成的科研成果，于2026年6月26日以预印本形式公开，编号为arXiv:2606.28436。若希望了解技术细节，可前往arXiv平台直接检索该编号，全文均可免费查阅。

先抛出核心痛点：假设你经营一家程序员培训机构。每次验证学员编写的代码是否正确，都必须为每位学员单独搭建一套完整的开发环境——安装特定版本的语言运行时、配置专属依赖库、准备测试基础设施。更进一步，还需为每个委托合作方的每套代码仓库都构建一个“测试工厂”。这不仅耗时费力，更关键的是，当委托方的代码仓库属于私有项目、长期未维护甚至根本没有像样的测试用例时，这条路完全走不通。

这恰恰卡住了当前代码智能体（AI）训练的命脉。如今那些能自动修复GitHub真实软件缺陷的智能体，在训练阶段极度依赖一种名为“执行验证”的机制——让AI输出修复代码后，在项目环境中实际运行测试，依据测试通过与否来打分。此机制的问题是：每个开源项目都需一个独立的Docker容器，内部精确匹配依赖库、测试脚本及运行工具。光是搭建这些环境就已是一项巨大工程，即便采用最先进的自动化流水线，也只能覆盖候选代码库中的极小部分。至于企业内部的私有代码仓库、或二十年前遗留的老项目，根本不可能用这种方式训练AI。

为攻克这一难题，上交大与抖音团队研发了一套名为Dockerless的系统。顾名思义：无需Docker，无需任何特殊运行环境，照样能准确判断AI修复的代码是否正确。

一、为什么“测试环境缺失”是核心障碍

在深入介绍Dockerless之前，有必要先理解“测试环境”为何如此关键，以至于整个AI训练流程都无法绕开它。

训练代码AI的过程类似于培养一名新程序员。首先给AI大量“优质修复案例”供其学习规律，这称为监督微调（SFT）。随后让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将问题描述、参考答案、待评判的修复代码以及所有问答对，一并交给最终判决模型。判决模型综合所有证据，输出一个二进制裁决：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在一个极简的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分支达到了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”继承语义。基于这两条来自代码库的实证线索，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个百分点，这被认为是编译器反馈信息缺失所致。