这项由华为加拿大研究院、女王大学、曼尼托巴大学以及康考迪亚大学联合完成的研究，以预印本形式发布于2026年7月29日，论文编号为arXiv:2607.27146，预计将在2027年AAAI会议上正式亮相。有兴趣深入了解的读者可以通过该编号在arXiv平台查询完整论文。
**一个让人头疼的问题**
假设你现在需要找一位程序员，让他从零开始写一个功能完整的命令行工具——不给他任何现成代码，只给他一份功能说明文档和一个已经编译好的可执行程序供参考。他看不到源代码，不知道别人怎么实现的，只能通过反复运行这个参考程序来摸索它的行为规律，然后自己重新写一遍。
这个任务有多难？哪怕是世界上最先进的AI编程模型，在这类任务上的完整成功率也低得可怜——甚至不足1%。这就是一个名为ProgramBench的测试基准所揭示的现实：AI在"从头造程序"这件事上，还远远没有达到实用水平。
然而，上述联合研究团队提出了一套名为MindForge的方法，通过一系列精心设计的训练技术，将一个270亿参数的"小"模型（Qwen3.6-27B）的ProgramBench得分从37.98%一路推高到49.51%——这个数字已经超越了参数量是它数倍乃至数十倍的大型前沿模型，例如DeepSeek V4 Pro（1.6万亿参数）和Claude Opus 4.7（参数量未公开披露，但规模远大于27B）。更令人在意的是，这种能力提升并非仅仅局限于训练任务本身，而是蔓延到了七个完全不同的软件工程测试场景，覆盖了从修复代码错误到跨语言翻译的广泛领域。
**一、"从零造程序"究竟难在哪里**
理解MindForge的价值之前，先要理解为什么"从头写程序"这件事如此困难。
现有的AI编程助手，绝大多数都是在"修缮旧房子"而非"从地基开始建新房"。它们面对的任务通常是：给你一个已有的代码库，里面有一个bug，你去找到它、修复它。或者：在一个现成的框架上，加一个新功能。这类任务有个天然的"脚手架"——现有代码告诉AI整体结构是什么样的，AI只需要在这个框架内做局部调整就行了。
"从头造程序"则完全不同。AI需要独立完成软件开发的完整生命周期：先通过反复运行参考程序来搞清楚它究竟能做什么（规格推断阶段）；再决定用什么语言、什么架构来实现它（设计阶段）；然后从第一行代码开始写起（实现阶段）；写完之后运行，发现不对劲，自己找原因（错误定位阶段）；找到原因后修改（修复阶段）；再测试、再修改，循环往复，直到最终产出一个能通过测试的可执行文件。
这个过程之所以难，是因为AI在每个阶段都可能犯错，而且早期犯的错会导致后期越来越难以纠正。更关键的是，现有的训练数据根本没有覆盖这种完整的开发过程。市面上大量的AI编程训练数据，都是围绕"改bug"或"加功能"这类局部任务收集的，几乎没有端到端的完整程序开发轨迹。
这正是MindForge要解决的核心问题。
**二、MindForge是怎么工作的：打造"无源码训练场"**
MindForge的核心思路，可以用一个类比来理解：你想训练一位厨师，但你不能直接给他菜谱。你给他的只是一道已经做好的菜，以及一份食材清单，让他通过品尝、观察、反复试做，最终复现出这道菜。
在技术层面，MindForge首先需要建立大量这样的"训练厨房"——也就是无源码的可执行程序环境。研究团队从GitHub上专门收集命令行工具程序的"精选列表"社区出发，初步筛选出2235个候选代码仓库，然后让一个"探索智能体"逐一审查这些程序，判断它们是否适合作为训练环境。
判断标准相当严苛：这个程序必须是自包含的命令行工具（不能依赖互联网连接、不能需要特殊硬件、不能依赖外部在线服务）；它的行为必须可以被明确验证；它在本地就能完成有意义的工作。经过这轮筛选，1206个程序通过初审，其中1002个成功完成了编译打包。
接下来是构建阶段的精华：研究团队让一个"构建智能体"为每个通过初审的程序生成一份构建脚本，这份脚本必须在一个干净的、从未被任何人动过的环境中独立运行，成功编译出可执行文件。然后，系统会在另一个全新的沙箱环境中重新执行这份脚本，验证构建结果是否一致（行为等价性检验）。任何不一致的构建都会被丢弃，确保每个训练环境都是可复现的。
最后还有一道"无源码检验"：研究团队会扫描最终生成的可执行文件，确保它的字节内容和字符串中没有残留任何原始源代码的痕迹。如果发现泄漏，就重新构建。只有通过全部检验的程序，才会被打包成一个Docker镜像——里面只有编译好的参考可执行文件和公开文档，完全没有源代码。
经过这整套流程，研究团队最终建立了562个有效的无源码训练环境，覆盖六种编译型编程语言：Go语言占最大比例（231个，41.1%），其次是Rust（212个，37.7%），接着是C语言（87个，15.5%），C++（29个，5.2%），还有少量Swift和TypeScript程序。这些程序全部来自与ProgramBench测试集不重叠的代码仓库，从根本上排除了"考前偷看答案"的可能性。
**三、收集训练轨迹：让"老师"在训练场里真实演练**
有了训练场地，下一步是收集高质量的训练示例。研究团队选用了GLM-5.2作为"教师模型"——一个在ProgramBench上得分64.60%的高水平模型，放到562个无源码环境中，让它像真实开发者一样工作：看文档、运行参考程序感受它的行为、设计实现方案、写代码、调试、再测试，直到产出一个能通过编译的可执行文件。
整个过程被完整记录下来，形成"开发轨迹"。研究团队只保留那些教师模型最终成功产出可执行文件并主动发出"任务完成"信号的轨迹，过滤掉那些中途崩溃、超时或陷入死循环的尝试。这个过滤逻辑很合理：你想从老师那里学的，是成功的做法，而不是失败的尝试。
最终收集到1001条完整的开发轨迹。这些轨迹的规模令人印象深刻：平均每条轨迹包含181.6个对话回合、约177,000个token，最长的一条包含477个回合、272,000个token。相比之下，现有的大多数编程训练数据，95%都在32,000个token以内——MindForge的轨迹长度是它们的好几倍，真正覆盖了长程开发过程。
研究团队还用自动化工具分析了这1001条轨迹都包含哪些开发阶段。结果显示，几乎所有轨迹都包含规格探索（99.1%）和代码实现（99.7%），87.1%的轨迹包含明确的架构设计思考，59.4%的轨迹包含错误定位行为，62.6%包含错误修复行为，83.7%包含验证步骤，64.2%包含对已有实现的精化和优化。换句话说，这些轨迹不是重复展示单一技能的枯燥练习，而是覆盖完整软件开发生命周期的丰富学习材料。
**四、轨迹净化：去除噪音，留下精华**
收集到的原始轨迹并非完美无缺。一个强大的教师模型在长达数百回合的自主运行中，难免会犯错、遭遇环境故障，或者出现前后不一致的表述。直接用这些原始轨迹训练学生模型，等于让学生连老师的笔误和说错的话都一起学进去了。
为了解决这个问题，研究团队设计了两套轨迹净化机制。
第一套叫做"基础设施噪声恢复"：有时候不是教师模型犯错，而是运行环境本身出了问题（比如API调用失败、沙箱崩溃）。这时候一条正在进行中的轨迹会被迫中断。如果直接丢弃，就浪费了前面所有的推理计算成本。研究团队的解决方案是"倒带重播"：回到最后一个健康的状态点，在一个全新的干净环境中重新执行之前所有的工具调用步骤（注意：这一步不需要再次调用教师模型，只是机械地重放操作），然后从中断点继续让教师模型往下走。这样既保住了之前的工作成果，又避免了重复推理的巨额成本。
第二套叫做"推理重写机制"：当教师模型在某一步产生了格式错误的工具调用时，这个错误步骤和随之而来的报错信息会被删除。但问题在于，教师模型往往会在后续的推理中提到这个错误（比如"刚才那一步失败了，我接下来要换个方法"）。一旦错误步骤被删除，后续的这段"反思"就变成了无头苍蝇——它在回应一个已经不存在的东西，逻辑上完全断裂。
解决方法是：识别出这些"孤儿推理"段落，用GLM-5.2来重写它们，让它们与清理后的轨迹语境保持连贯。关键的约束是：重写只能修改推理文字，不能改动任何工具调用和环境响应——这些代表教师模型真实行动的记录必须保持原样，修改的只是用于串联上下文的"旁白"部分。每次重写结果还会经过安全检查，确保没有引入新的不一致内容。
**五、训练结果：小模型的逆袭**
用这1001条经过净化的完整开发轨迹（最终因长度限制去掉28条，使用973条）对Qwen3.6-27B进行微调后，得到的模型被命名为MindForge-27B。
在ProgramBench的200个测试任务上，MindForge-27B的平均测试通过率从37.98%跃升到49.51%，绝对提升11.53个百分点，相对提升30.4%。更具体地说，在200个测试任务中，MindForge-27B在152个任务上得分严格高于基础模型，只在43个任务上得分较低，5个任务持平。这种广泛、均匀的提升，而不是少数任务的异常高分拉动，说明训练真正产生了系统性的能力提升。
从横向比较来看，这个成绩意味着什么？MindForge-27B（49.51%）超越了Sonnet 4.6（47.97%）、DeepSeek V4 Pro（47.80%，参数量1.6万亿），与Claude Opus 4.7（51.38%）和GLM-5.1（50.90%）处于同一水平。而这些模型的参数规模，是MindForge-27B的数十倍乃至数百倍。
当然，与教师模型GLM-5.2（64.60%）以及GPT-5.5（56.50%）等顶尖前沿模型相比，MindForge-27B还有明显差距。但考虑到它只有270亿参数，并且只用了1001条训练轨迹，这个结果已经相当出色。
**六、能力真的泛化了吗：七个陌生战场的考验**
一个模型在训练数据相关的测试上表现好，并不能证明它真正"学会了"软件工程。真正的考验，是把它放到训练时完全没有见过的任务类型上，看它是否还能表现出色。
研究团队为此准备了七个独立的评测基准，涵盖完全不同的软件工程场景。在这七个场景中，MindForge-27B全部超越了它的基础模型Qwen3.6-27B，这一点本身就很难得。
最戏剧性的提升来自RepoZero-C2Rust任务：这是一个要求把C语言程序翻译成Rust语言的任务，完全通过率从47.00%飙升到78.00%，提升了31个百分点。DeepSWE是一组全新设计的、真实的长程工程任务，得分从1.76%升至15.92%，虽然绝对值不高，但倍数意义上提升了整整9倍。NL2Repo-Bench测试的是从自然语言描述直接生成整个代码仓库的能力，在提供测试用例辅助的设置下，得分从61.27%提升到71.97%（+10.70个百分点）；在不提供测试用例的更难设置下，从18.92%提升到23.48%（+4.56个百分点）。
与此同时，在传统的代码修复任务上，MindForge-27B同样取得了一致的提升：SWE-bench Verified（标准版代码修复基准）从68.80%提升到73.84%（+5.04个百分点）；SWE-bench Pro（更难的企业级代码修复任务）从45.41%提升到51.34%（+5.93个百分点）；SWE-bench Multilingual（跨语言代码修复）从62.55%提升到67.77%（+5.22个百分点）；FeatBench（从自然语言描述实现新功能）从50.10%提升到55.05%（+4.94个百分点）。
所有这些提升，经过严格的统计检验（配对Wilcoxon检验和精确McNemar检验，并使用Holm方法校正多重比较）后，全部达到统计显著性（Holm校正p值均低于0.05）。这意味着这些提升不是偶然的随机波动，而是真实存在的能力跃升。
**七、行为的变化：模型是怎么变得更好的**
数字背后，模型的行为到底发生了什么变化？研究团队通过详细分析ProgramBench测试中各模型的操作轨迹，给出了一幅相当清晰的图景。
从操作规模来看，MindForge-27B在每个任务上的投入大幅增加：平均对话回合数从344.0增加到735.7，工具调用次数从174.4增加到373.0，消耗的token总量从20.3亿增加到116.4亿（整个200题测试集合计），是基础模型的5.7倍。更值得一提的是，MindForge-27B的工具调用量甚至超过了教师模型GLM-5.2（平均186.6次），说明学生不是简单地模仿老师的操作量，而是发展出了更为彻底的探索风格。
单纯操作多并不等于有效——你要看的是错误率。MindForge-27B的每次命令失败率从基础模型的10.98%下降到9.35%，这意味着尽管操作总量翻倍，但单次操作的可靠性反而提高了。更长的轨迹、更低的错误率，这种组合说明额外的操作是有效的深度探索，而非无谓的重复。
研究团队还测量了两个"行为转化率"指标，用来衡量模型是否能够将推理和错误分析转化为实际的代码修改。具体来说：一是"推理后立即编辑"的比例，即模型做完推理之后，紧接着就修改代码的频率；二是"失败恢复后立即编辑"的比例，即遇到报错之后，紧接着就动手修复代码的频率。
基础模型在这两个指标上分别只有27.8%和31.8%——也就是说，它推理了但没有行动，或者遭遇了报错却没有立即去修复，这种情况发生得相当频繁。研究团队在论文中给出了一个具体的案例：基础模型已经正确诊断出了一个函数的问题所在，明确表示需要修改它，但接下来的29个连续操作中，有16次是在对同一个参考程序重复运行同一条命令，反复得到完全相同的输出，而那个它自己说要修复的函数，直到30个操作后才终于被打开修改。这种"诊断了但不行动"的模式，正是基础模型在长程任务中效率低下的根本原因。
MindForge-27B在这两个转化率指标上几乎翻倍：推理后立即编辑的比例达到50.1%，失败恢复后立即编辑的比例达到48.8%。这让它与教师模型GLM-5.2（61.4% / 64.0%）和前沿模型GPT-5.5-high（67.3% / 70.4%）之间的差距大幅缩小，而与基础模型相比则有了质的跨越。
研究团队还构建了每个程序的覆盖率镜像（为200个ProgramBench测试程序重新编译了带覆盖率插桩的版本），用来测量各模型在尝试复现程序之前，究竟有多彻底地探索了参考程序的行为。平均来看，MindForge-27B覆盖了参考实现代码的58.39%，而基础模型只有49.34%（中位数分别为66.47%和52.14%，差距更为明显）。在200个测试案例中，MindForge-27B在154个案例上取得了严格更高的覆盖率，只在11个案例上落后。探索得更深入、更全面，这是MindForge-27B能产出更好实现的行为基础。
**八、整个流程的工程细节**
为了完整呈现MindForge的技术实现，有必要介绍一些关键的工程参数。
整个环境构建流程由三个智能体串联完成，都运行在Qwen3.5-397B-A17B这个模型上，通过mini-swe-agent框架与沙箱环境交互，部署在Kubernetes集群上。探索智能体（Offline Screening）只读取源代码和文档，从不执行任何构建操作，是最廉价的过滤层。构建智能体（Build Discovery）在有网络访问权限的沙箱中工作，可以下载依赖包，但其生成的构建脚本必须在没有任何预装依赖的干净环境中独立运行。两个智能体都采用"先提议后验证"的模式：在沙箱内有一个即时验证器给出反馈，沙箱外还有一个宿主端验证器做最终裁决，防止沙箱内的智能体"自我批改试卷"。
模型训练使用MS-Swift框架配合Megatron后端，训练设置为序列打包（减少填充浪费）、微批大小1、全局批大小96、训练8个epoch。优化器为AdamW（β?=0.9, β?=0.98，权重衰减0.04），学习率从4×10??热身后按余弦调度衰减至4×10??，梯度裁剪最大范数1.0。训练损失只计算在助手生成的推理、自然语言和工具调用token上，系统消息、用户消息和工具输出都被遮罩，不参与梯度更新。训练和推理均使用bfloat16精度，推理时上下文窗口设置为512K token并开启推理模式。
在污染分析方面，研究团队将562个训练环境的代码仓库与所有评测基准的仓库进行了逐一比对，发现只有5个仓库重叠（覆盖17个评测实例），其中3个来自DeepSWE，14个来自SWE-bench Multilingual。对于这17个实例，基础模型和MindForge-27B的通过率几乎一致（DeepSWE重叠部分两个模型都是0/3，SWE-bench Multilingual重叠部分基础模型11/14，MindForge-27B 12/14，只有一个实例从失败变为通过）。更重要的是，训练任务和评测任务的性质根本不同：训练中程序是看不见源代码、从头复现的；而这些评测任务是在现有源代码上解决具体问题。研究团队认为污染风险可以忽略不计。
**归根结底，MindForge说明了什么**
回到最开始的问题：为什么从头写一个程序比修改现有代码要难那么多？因为它要求AI具备一种完整的工程直觉——不只是"这里有个bug，改掉它"的局部修复能力，而是"我需要理解这个程序想做什么，然后设计一套方案，一行行实现它，遇到问题自己诊断解决"的全局掌控能力。
MindForge的贡献，在于它提供了一条让小模型习得这种全局掌控能力的可行路径。关键不在于用了多少数据（1001条轨迹，放到现在的AI训练规模里算是非常少的），而在于数据的质量和覆盖面：每一条轨迹都是一次完整的从头到尾的开发过程，包含了真实工程中才会出现的各种挑战——规格不明确、初始设计有缺陷、编译报错、测试不通过、反复迭代直到成功。
这对AI能力的发展方向有着实际的启示意义。当前AI编程工具的瓶颈，可能并不是参数量不够大，而是训练数据的视野太窄——总是在修修补补，从未经历过从无到有的完整创造过程。MindForge的实验结果表明，如果让模型接触到足够多的完整开发轨迹，即便模型规模不大，也能在这条轴线上产生实质性的能力跃升。
当然，MindForge-27B距离真正胜任复杂程序开发还有相当距离。教师模型GLM-5.2在ProgramBench上还有64.60%对49.51%的明显优势，而最顶尖的模型（如Kimi K3，77.80%；GPT-5.6 Sol，77.60%）还在更高处。而且ProgramBench本身测试的是相对规范的命令行工具复现，真实世界的软件工程远比这复杂。对于"为什么全程序开发训练会让模型在截然不同的任务（如SWE-bench代码修复）上也变强"这个问题，目前也只有行为层面的观察，还缺乏深层的理论解释。
但这项研究至少回答了一个有意义的问题：用完整的开发生命周期轨迹来训练模型，比起只用局部修改任务的数据，确实能培养出更强、更通用的软件工程能力。这条路，值得继续走下去。有兴趣深入研究细节的读者，可以通过arXiv编号2607.27146查阅完整论文，该论文将相关代码、环境、轨迹以及MindForge-27B模型权重一并开源。
Q&A
Q1：MindForge训练的模型在编程能力上达到了什么水平？
A：MindForge-27B在ProgramBench基准测试上的平均通过率达到49.51%，超越了参数量是它数十倍的DeepSeek V4 Pro（47.80%），与Claude Opus 4.7（51.38%）处于同一水平。在七个额外的软件工程测试场景中也全部超越了基础模型，包括代码修复、功能实现和跨语言程序翻译等任务。
Q2：MindForge只用了1001条训练数据为什么效果这么好？
A：关键在于数据质量而非数量。MindForge的1001条训练轨迹每一条都是一次完整的程序开发过程，平均长达181.6个对话回合，覆盖从规格推断、架构设计到调试修复的全部阶段。99.1%的轨迹包含规格探索，87.1%包含设计思考，而传统编程训练数据只覆盖局部修改任务，视野窄、深度浅，MindForge的轨迹提供了真实工程中的完整决策过程。
Q3：ProgramBench是什么类型的测试，为什么顶级AI在上面得分这么低？
A：ProgramBench要求AI仅凭一个编译好的参考程序和文档，从零开始重新实现该程序，不提供任何源代码。它包含200个真实的开源命令行工具（如FFmpeg、SQLite），要求AI独立完成规格推断、架构设计、实现、调试的完整开发过程。由于现有AI主要在代码修改任务上训练，缺乏端到端开发经验，即便是GPT-5.5这类前沿模型也只能完整解决不到1%的任务。