上海交通大学与字节跳动旗下抖音集团联合研发的上交手研究成果，以预印本形式于2026年6月26日公开发布，大字动联顶级代码论文编号为 arXiv:2606.28436。节跳该研究提出了一种无需Docker容器即可高效验证代码修复正确性的用Dr也新范式，彻底改变了代码人工智能（AI）的练出训练逻辑。感兴趣的上交手研究人员可通过上述编号在arXiv平台获取完整论文及技术细节。
代码AI训练的大字动联顶级代码“阿喀琉斯之踵”：环境依赖困境
想象一所程序员培训学校，若要评估学员代码的节跳正确性，必须为每位学员单独搭建包含特定语言版本、用Dr也依赖库及测试基础设施的练出完整开发环境。若面对的上交手是私有代码库、遗留系统或缺乏测试用例的大字动联顶级代码项目，这种“一库一环境”的节跳模式不仅成本高昂，更在工程上不可行。用Dr也
这正是练出当前代码AI训练面临的核心瓶颈。目前最先进的代码AI（如自动修复GitHub Bug的智能体）高度依赖执行验证（Execution Verification）机制——即让AI生成修复代码后，在对应项目的真实环境中运行测试，以测试结果作为评判标准。然而，构建每个开源项目的独立Docker容器（隔离虚拟环境）是一项庞大的工程，自动化流水线仅能覆盖极小部分代码库。对于数量庞大的私有企业代码库和历史遗留系统，传统方法几乎完全失效。
为解决这一痛点，研究团队提出了 Dockerless系统。其核心理念在于：摆脱对特定运行环境和Docker容器的依赖，仅通过代码本身的语义分析，即可精准判断AI修复代码的正确性。
一、为何“测试环境”成为AI训练的死结？
代码AI的训练通常分为两个阶段，均需要一个可靠的“裁判”来评估修复质量：
- 监督微调（SFT）：通过大量“正确修复案例”让AI学习解题思路。
- 强化学习（RL）：通过试错机制，对成功修复给予奖励，失败给予惩罚，提升AI能力。
现有的“裁判”主要依赖执行测试：将修复代码投入项目环境运行官方测试用例。全通过则判对，有失败则判错。虽然准确率高，但代价极大：
* 覆盖率低：即便有自动化工具，仅有限比例的代码库能成功构建可用测试环境。
* 适用性窄：企业私有库、老旧遗留系统无法为AI训练专门搭建环境。
现有方法仅适用于拥有完整Docker环境和测试套件的开源项目，对真实世界中大量的“长尾”代码库无效。研究团队意识到，破局之道不在于优化环境搭建，而在于从根本上消除对环境的依赖——训练一个能像资深工程师一样，仅通过阅读代码上下文即可判断修复正确性的智能裁判。
二、现有“无环境验证器”的局限性
在Dockerless出现前，学界尝试过两类“无环境验证器”（Environment-free Verifier），但均存在明显缺陷：
- LLM直接裁判：将问题描述、参考答案和AI修复代码输入大模型进行判断。
- 缺陷：LLM仅基于文本表面信息判断，缺乏对代码仓库全局上下文的理解。如同仅看菜谱无法判断菜品火候，无法识别功能等价但写法不同的代码。
- 专用验证器模型：如SWE-Gym Verifier、R2E-Gym Verifier、OpenHands Critic等。
- 缺陷：同样依赖表面特征，不主动查阅代码仓库。
典型反例：若标准答案使用辅助变量实现逻辑，而AI使用内联三元表达式实现相同逻辑，两者功能等价但文本相似度极低。传统方法会误判AI为错误，而深入代码仓库分析调用链和边界情况才能得出正确结论。
基于此洞察，Dockerless被设计为一个主动侦查代码仓库的智能裁判。
三、Dockerless的工作原理：侦探式推理框架
Dockerless借鉴侦探破案逻辑，分为两个阶段：
1. 第一阶段：出题与调查（Investigation）
给定问题描述、参考答案（Ground Truth）和AI修复代码，Dockerless执行以下操作：
* 生成侦查问题：从问题描述和参考答案中推导2-4个关键侦查问题（如：“修复涉及哪些具体文件？”、“修改后应实现何种功能？”、“哪些测试用例能验证修复？”）。
* 子侦探并行调查为每个问题派出独立的“子智能体”（Sub-agent），通过只读命令行工具（如 find, grep, rg）在代码仓库中检索证据。
* 证据收集：每个子侦探返回基于代码证据的简短回答。
2. 第二阶段：综合判决（Verdict）
- 多模态输入：判决模型接收问题描述、参考答案、AI修复代码及所有调查问答对。
- 二进制裁决：模型输出修复正确（1）或错误（0）的判断。
- 连续评分：通过读取模型输出“1”和“0”的概率值，利用数学公式转换为0-1之间的连续置信度分数。分数越高，确信度越高。
核心优势：Dockerless不比较代码文本相似度，而是通过证据链验证修复是否真正解决了问题，类似于侦探通过物证而非外貌比对锁定真凶。
四、Dockerless的训练策略：拒绝采样与共享骨干
Dockerless采用拒绝采样（Rejection Sampling）进行训练，确保模型从正确的推理路径中学习。
- 数据收集：
- 使用强大教师模型（GLM-5）在3700个有执行标签（即拥有真实测试环境）的代码问题上运行侦查流程。
- 关键筛选：仅保留教师模型裁决与真实测试结果一致的轨迹，丢弃错误案例。这是训练过程中唯一需要测试环境的环节。
- 样本平衡：
- 控制正负样本比例上限为4:1，防止错误修复样本过多导致偏差。
- 模型架构：
- 基于 Qwen3.5-9B构建共享神经网络骨干。
- 问题生成、子侦探调查、最终判决三个子任务共用同一套参数。
- 以标准下一词预测损失为目标进行训练，最佳检查点在约150步优化后出现。
五、无环境训练流水线：SFT与RL两阶段
Dockerless作为核心裁判，支撑起完全不依赖Docker的代码AI训练流水线：
阶段一：监督微调（SFT）
- 传统做法：在真实测试环境中收集通过测试的修复轨迹。
- Dockerless做法：
- 在极简Linux基础镜像上让AI生成大量修复尝试（无需项目专属环境）。
- 使用Dockerless对每条轨迹打分。
- 数据筛选：在SWE-Rebench-v2数据集上收集16,000条轨迹，经Dockerless两次独立评估取平均分后，保留得分最高的4,000条作为训练数据。
阶段二：强化学习（RL）
- 流程：
- 以SFT阶段训练好的模型为起点。
- 对每个代码问题生成8条修复尝试。
- 使用Dockerless打分，结合 GRPO算法强化高分修复策略，弱化低分策略。
- 全程无需运行测试或Docker环境。
- 规模：共训练50步，每条修复同样经过两次独立评估取平均。
六、实验结果：性能与效率的双重验证
研究团队在三个标准测试集上评估了系统性能，指标为问题解决率（Pass@1）：
1. 验证器性能对比
在专门构建的验证器基准（776个样本）上：
* Dockerless：SWE-bench Verified分支 81.0 AUC，Multi-SWE-bench Flash分支 72.1 AUC。
* 对比开源验证器：DeepSWE Verifier分别为66.7和62.9，差距超14分。
* 对比商业大模型：GPT-5.4、GLM-5等零样本裁判最高分别为75.9和63.9，显著低于Dockerless。
2. 下游代码AI性能
以Qwen3.5-9B为基础模型，经两阶段无环境训练得到 Dockerless-RL-9B：
* SWE-bench Verified：62.0%（+2.4%）
* SWE-bench Multilingual：50.0%（+8.7%）
* SWE-bench Pro：35.2%（+2.9%）
该结果超越了所有参数量<100亿的开源代码AI专项模型，如SWE-Lego-8B（高出约20-31个百分点）。
3. 有环境 vs 无环境横向对比
- SFT阶段：Dockerless筛选的无环境模型（Dockerless-SFT-9B）与真实环境筛选模型（Env-SFT-9B）表现接近，甚至在部分指标上略优。
- RL阶段：Dockerless版本（62.0%、50.0%、35.2%）与真实测试执行版本（62.4%、51.3%、35.7%）差距极小（0.4-1.3个百分点），且显著优于DeepSWE Verifier版本（优势1.4-2.7个百分点）。
七、关键细节：调查深度与计算开销
1. 验证问题数量（K值）优化
- K=0（无调查）：AUC 78.3
- K=4（适量调查）：AUC 81.0（峰值）
- K=6/8（过度调查）：AUC回落至79.6/80.3
- 结论：生成2-4个验证问题能在准确性与计算效率间取得最佳平衡，过多问题引入冗余噪音。
2. 计算开销分析
基于7680条RL训练轨迹的耗时分解：
* AI生成修复：平均2308秒（主导耗时）。
* 奖励计算额外耗时：
* DeepSWE Verifier：+41秒（1.7%）
* 真实测试执行：+83秒（3.5%）
* Dockerless：+180秒（7.2%）
* 结论：尽管Dockerless因主动调查比简单查表慢，但其额外开销仅占总时间7.2%，处于可接受范围。整体流程瓶颈在于修复轨迹本身的运行时长，而非奖励计算。
八、案例解析：语义等价但写法迥异的修复
场景：Matplotlib库中图表偏移量文字（offsetText）颜色修复。
* 问题：应使用标签颜色（labelcolor）而非刻度颜色（tick.color）。
* 参考答案：使用辅助变量提取颜色并赋值。
* AI修复：使用内联三元表达式直接赋值。
* 结果：
* 文本相似度：0.468（低，因结构差异大）。
* DeepSWE Verifier：0.035（误判为错误）。
* Dockerless：
1. 子侦探1确认AI修复更新了X/Y轴初始化路径（一致）。
2. 子侦探2确认AI保留了“inherit”继承语义（一致）。
3. 最终评分：0.996（高度吻合真实测试结果1.0）。
九、局限性与未来展望
1. 语言差异
- 动态语言（Python, JS, Java等）：有/无环境训练差异<2.5个百分点，效果相当。
- 强编译型语言（Rust, C）：有环境训练效果高出7.0-13.3个百分点。
- 原因：Rust/C依赖编译器反馈（类型错误、链接失败）辅助调试，无环境训练缺失此信道。
- 未来方向：在无环境流水线中引入编译器反馈模拟。
2. 工程意义
Dockerless证明了代码修复正确性判断可通过智能代码库调查接近等效完成。这意味着：
* 企业私有代码库、遗留系统、无测试套件项目可受益于AI辅助。
* 训练代码AI不再需要为每个库搭建复杂测试基础设施。
* 测试执行虽仍具价值（尤其对编译型语言），但Dockerless为大多数场景提供了切实可行的替代路径。
3. 行业影响
随着无环境验证技术成熟，代码AI训练数据来源将向私有企业代码库扩展，引发关于企业代码安全与AI训练数据张力的新讨论。Dockerless为此打开了大门。
Q&A
Q1：Dockerless是什么，它解决了什么问题？
A：Dockerless是由上海交通大学与字节跳动联合研发的代码修复验证器。它解决了传统代码AI训练高度依赖Docker测试环境、无法覆盖私有或遗留代码库的工程瓶颈。通过主动调查代码仓库内容替代执行测试，Dockerless实现了零Docker依赖的代码修复验证。
Q2：Dockerless不运行测试，怎么知道代码修复是否正确？
A：Dockerless采用“侦探调查”机制：
1. 生成2-4个关键侦查问题。
2. 派出子智能体在代码仓库中利用只读命令行工具（如grep, find）检索证据。
3. 判决模型综合所有证据输出0-1的置信评分。
这种方式能识别功能等价但写法不同的修复，而非仅依赖文本相似度。
Q3：Dockerless训练的代码AI和传统方法训练的效果差多少？
A：在SWE-bench Verified、Multilingual和Pro测试集上，Dockerless-RL-9B与真实测试执行训练的模型差距仅为0.4-1.3个百分点，表现高度接近。但在Rust和C等强编译型语言上，差距约为7-13个百分点，主要源于编译器反馈信息的缺失。