这项由加拿大滑铁卢大学、英属哥伦比亚大学、NVIDIA、Verdent AI和Vector研究院联合开展的研究以预印本形式于2026年7月14日发布论文编号为arXiv:2607.12463。有兴趣深入了解的读者可通过该编号在arXiv平台查询完整论文。在AI写代码这件事上最难的其实不是从零开始写而是出错之后能不能自己修。当一个AI编程助手在真实的代码仓库里工作时它的日子并不好过。它需要先查看文件再尝试修改然后运行测试——测试失败了报错信息扑面而来它得读懂这些错误判断是哪里出了问题然后再次修改。这个行动→收到反馈→继续的循环对AI来说是个真正的挑战。主流的代码语言模型在训练时基本上是按照从左到右、从上到下的方式阅读代码它们对先做一件事收到外部结果再继续这种节奏本质上缺乏感知。研究团队注意到了一个有趣的规律AI助手在执行任务时经历的行动→收到工具返回结果→基于结果继续这个三步循环和普通代码里一个函数调用的结构几乎一模一样。当你写了一行 result process(data)这里发生的事情是调用前的代码设定了意图和参数process 函数被调用函数内部做了一些你在外部看不到的计算把结果返回给你然后你用这个结果继续往下写。这四个步骤——背景、行动、外部计算的返回结果、后续处理——和AI助手执行任务的四个步骤是结构上完全相同的。既然如此能不能利用互联网上海量存在的普通代码来训练AI理解这种行动-反馈-继续的逻辑呢这就是这项研究的核心思路。**一、问题所在现有训练方式留下了一个缺口**要理解这项研究在填补什么空白先来看看AI编程助手是怎么被训练出来的。整个流程大致分两个阶段。第一阶段叫预训练是把模型暴露在海量代码面前让它像背课文一样学会预测下一个词是什么。这个阶段的训练用的是互联网上能找到的所有代码规模巨大但方式很简单——从左到右一个接一个地预测。第二阶段叫智能体后训练是专门针对修复真实代码bug这类任务准备一批AI执行任务的完整轨迹行动记录来训练模型。这个阶段是最近几年让AI代码修复能力大幅提升的关键。R2E-Gym、SWE-Smith、SWE-Lego这些知名的训练框架都属于这类方法。两个阶段之间存在一个空档模型在第一阶段培养了阅读代码的基本能力但这种从左到右的训练方式天然地只让模型练习了往前看没有好好练习收到外部结果之后怎么继续。第二阶段的任务轨迹数据虽然很有针对性但数量有限且很贵——需要大量人工或AI来生成这些轨迹。研究团队的想法是在两个阶段中间插入一个中间训练阶段利用更廉价、更大量的普通代码来建立一种惯性让模型在真正接触任务训练之前就已经养成了根据前后文推断中间缺失内容的思维方式。这种填空训练方法学术上叫填中间FIMFill-in-the-Middle。它的基本操作是把一段代码的中间部分遮住让模型根据前面的代码和后面的代码把中间这部分补出来。这和完形填空非常相似只不过不是一个词而是一整段代码逻辑。问题在于之前的代码模型虽然也用过这种填空训练但那些训练都是随机挖一段出来填就像随机撕掉一本书的某几页有时撕掉的是一个完整的故事情节有时撕掉的只是一句话中间的几个字参差不齐对培养理解函数调用结构这种具体能力帮助有限。**二、核心创新按照函数来挖而不是随机挖**研究团队设计的方法叫函数感知填中间中间训练。关键区别在于它不随机挖一段代码而是有针对性地挖掉一整个函数的函数体让模型根据调用这个函数的代码、被这个函数调用的其他函数、以及函数本身的签名和文档来推断这个函数应该怎么写。这个挖法之所以重要是因为一个函数就是一个完整的外部计算单元——它收到参数做一些调用者看不见的内部工作返回结果。这和AI助手调用工具比如执行终端命令、搜索文件时的情形完全类似AI看到命令返回了什么要根据这个返回结果决定下一步怎么做。为了选出值得挖掉的函数研究团队设计了一套双重评分体系。可以把它理解成在一栋楼里选哪个房间做示范单位房间得有足够的内容展示不能太简单但参观者进来之前能从门口的标牌、周围房间的布局推断出里面大概是什么样子不能完全不可推断。评估值不值得挖用的第一个指标叫复杂度分衡量的是这个函数本身有多少内容。计算方式综合了三个维度代码行数越长越复杂、圈复杂度代码里有多少if/for/while这样的分支分支越多逻辑越复杂、以及最深嵌套层数if里面套for里面再套if这样的层叠有多深。这三个维度各有权重综合成一个0到2之间的分数。第二个指标叫可推断分衡量的是周围代码有多少线索可以帮助推断出这个函数该怎么写。线索来源有五种调用这个函数时传入了什么参数越具体越好、这个函数内部调用了哪些同文件里的其他函数越多说明逻辑越有迹可循、函数名和参数的类型注解有多描述性名字越清楚越容易猜、有没有文档字符串有说明更好推断、以及这个函数在类里有多少兄弟方法共享状态兄弟越多上下文越丰富。最终的选取分数是把复杂度和可推断性用类似调和平均数的方式结合起来——要求两者都不能太低。一个函数如果很复杂但完全不可推断或者很容易推断但太过简单都不是好的训练材料。此外还有一个难度惩罚如果一个函数复杂度远超可推断性说明即使给了全部上下文也很难推断出来这种函数会被降权因为让模型去猜一个连人类都猜不出来的答案只会产生噪音。除了单个函数研究团队还设计了多函数组合的挖法同时挖掉2到3个有相互调用关系或同属一个类的函数。这是因为真实的代码修复任务经常需要同时修改多个相关函数这类训练样本能帮助模型练习跨函数的逻辑推理。两个函数的组合大约占训练数据的15%三个函数的组合占5%其余80%是单函数。**三、用AI来生成思考过程**光有挖空填补还不够。研究团队注意到真实的AI助手在修代码时通常是先思考输出一段分析再动手写代码。如果训练数据里只有代码本身模型就只练了动手没练先想清楚再动手。所以在构建训练样本时研究团队引入了一个额外步骤对于每一个被挖空的函数先让另一个强大的AI谷歌的Gemini 3 Flash只看前后代码不看被遮住的函数体生成一段推理过程说明这个函数应该做什么然后再给出对应的实现代码。之后用另一轮Gemini 3 Flash对这个生成的推理过程代码实现配对进行质量审核评分维度包括这个函数从上下文推断出来是否合理可行如果依赖完全无法从代码中感知的外部知识就标记为不可行、代码的正确性、可执行性、API使用是否恰当、可读性和完整性。只有通过审核的样本才进入训练数据。被遮住的真实函数体只用于审核不出现在训练目标中。模型学到的是看到前缀和后缀先输出一段推理再写出实现。这样构建的训练样本格式是[前缀代码] [后缀代码] [推理过程] [函数体代码]。前两块是输入后两块是模型需要生成的目标。**四、数据从哪里来**研究团队从GitHub上精心挑选了968个Python代码仓库作为中间训练的数据来源。最初考察的候选库大约有2000个经过手动质量筛查后缩减。所有与SWE-Bench用于评估AI修复真实GitHub Issue能力的标准测试集来源仓库有重叠的都被移除每个仓库只保留了在SWE-Bench测试集基准提交时间节点之前的代码确保不存在测试数据泄露。最终筛出大约78000个符合条件的Python文件从中生成了约40万条填空训练样本合计约26亿个token使用Qwen2.5-Coder的分词标准计算。其中单函数样本约32万条双函数组合约6万条三函数组合约2万条。每个样本的函数体平均长度约为34行代码。这40万条样本全部配备了Gemini 3 Flash生成的推理过程。这968个仓库覆盖了10个类别从头实现的项目、领域专用工具、算法库、科学计算、小型框架、可视化与游戏、教育类项目、编译器、数据处理和网络安全都有涉及许可证方面超过80%是MIT、Apache 2.0或BSD等宽松许可其余也均允许至少用于非商业研究。**五、训练流程中间插了一个阶段**具体的训练方式是先取已经经过指令微调的基础模型研究中用了Qwen2.5-Coder-7B-Instruct、Qwen2.5-Coder-14B-Instruct和Qwen3-8B在这26亿token的填空数据上做一轮中间训练训练目标只是推理过程加函数体这个部分前缀和后缀不参与损失计算。训练使用模型原生的填空特殊符号打包到模型的原生最大上下文长度跑一个epoch。这个中间训练阶段用的超参数学习率1e-5余弦学习率计划预热比例10%权重衰减0.05每设备批量大小1梯度累积16步等效全局批量128序列长度32768混合精度bf16。中间训练完成后再正常接上智能体后训练阶段R2E-Gym、SWE-Smith或SWE-Lego和没有中间训练的基准对比。之所以不直接评估只做了中间训练的模型是因为填空训练之后模型的指令跟随能力会下降没法公平地和经过完整指令微调的基准比较。所有公布的数字都是完整流程中间训练加后训练结束后的表现。**六、测试结果每个配置都在变好**研究在三个维度验证了这个方法的有效性。第一个维度是不同模型规模。在Qwen2.5-Coder-7B-Instruct上中间训练加R2E-Gym后训练在SWE-Bench-Verified上提升了2.8个百分点在SWE-Bench-Lite上提升了3.67个百分点。在14B的版本上同样的流程带来了3.0和4.0个百分点的提升。这说明更大的预训练模型并没有自然地吸收这种结构性偏置中间训练带来的改进在两个规模上都实实在在地存在。第二个维度是不同的后训练流程。在同一个7B基础模型上换用SWE-Smith代替R2E-Gym作为后训练框架中间训练在SWE-Bench-Verified上的提升高达5.3个百分点虽然在Lite上只提升了0.5个百分点说明具体数字取决于后训练流程和评测集的组合但方向上始终是正向的。第三个维度是不同的基础模型家族。换成Qwen3-8B加上SWE-Lego后训练中间训练在SWE-Bench-Verified上提升了3.2个百分点在Lite上提升了5.4个百分点。由于这里同时换了基础模型和后训练框架研究团队谨慎地说这只能说明方法不局限于Qwen2.5-Coder加R2E-Gym的特定组合而不是对所有模型家族的普适性保证。**七、意外收获通用能力的保留**智能体后训练有一个代价通常不被人提起专攻代码修复任务之后模型在其他方面的能力往往会大幅退步。研究团队专门测试了14B模型在六个额外基准上的表现结果令人警醒。只做R2E-Gym后训练不加中间训练模型在LiveCodeBench纯代码生成能力测试上比原始指令模型下降了13.1个百分点在BFCL函数调用能力测试上下降了7.4个百分点在FullStackBench-EN上下降了6.08个百分点在τ-bench模拟真实场景的工具使用测试上下降了2.3个百分点。六个基准平均下来后训练之后模型失去了4.81个百分点的综合能力。这是为了SWE-Bench成绩支付的隐性代价。加入中间训练之后情况发生了显著变化。LiveCodeBench回升了11.1个百分点OJBench竞赛编程测试回升了1.94个百分点仅距原始指令模型0.46个百分点FullStackBench-EN回升了0.53个百分点τ-bench回升了3.9个百分点BFCL回升了2.4个百分点Terminal-Bench 2.0回升了1.25个百分点。六个基准的综合平均从16.04上升到19.56同时SWE-Bench的增益也得到了保留。更有意思的是τ-bench和BFCL的提升。这两个测试里没有任何Python代码编辑相关的内容而中间训练的语料库里也完全没有工具使用相关的训练数据。两者的提升只能解释为函数调用结构和工具调用结构在某种深层次上是等价的中间训练建立的接收外部返回结果并继续的认知惯性通用地改善了模型处理任何行动-反馈-继续循环的能力。**八、逐一拆解每个设计决策贡献了多少**为了验证每个设计决策是否真的有用研究团队在7B模型上做了三组对照实验每组控制其他变量只改变一个因素使用20万条样本的固定预算以确保可比性。这些实验的绝对数字低于主实验因为数据量更少但组内的相对大小是可比较的。第一组对照是加不加推理过程有多大用。完全不加推理过程只做填空结构训练平均分比基准提升1.18个百分点。换成让被训练的模型自己生成推理过程而非用Gemini提升增加到1.68个百分点的回收。用Gemini生成的推理过程总提升是2.43个百分点。也就是说填空结构本身贡献了大约一半的改进推理过程提供了额外的增益但Gemini相比模型自身推理的额外贡献只有0.75个百分点。这说明这个方法不仅仅是一个蒸馏Gemini的方案填空结构本身就在干实事。第二组对照是怎么选函数有多重要。随机挖函数只比基准提升了0.78个百分点让Gemini来判断挖哪个函数提升到了1.88个百分点只用程序依赖图关系来筛选有调用关系的函数更倾向被选提升到了1.68个百分点加上复杂度过滤或可推断性过滤各自有额外改进两者都用效果最好达到2.43个百分点。这说明函数选择的质量是决定中间训练效果的关键变量而且复杂度和可推断性提供了互补的不同维度信息。第三组对照是同时挖多个函数有没有用。只挖单个函数提升2.43个百分点。加入15%的双函数组合样本提升到2.73个百分点。加入5%的三函数组合替换同等比例的单函数提升到2.53个百分点。同时加入双函数和三函数80%/15%/5%的组合也就是主实验中用的配方提升到2.93个百分点。多函数组合在帮助那些金标答案需要同时修改多个函数的任务上效果更明显但三个函数同时挖的边际收益因为可推断性大幅下降而受到限制。**九、深入轨迹模型到底学到了什么**为了理解改进从哪里来研究团队分析了14B模型在SWE-Bench-Verified上的行为轨迹。研究团队定义了一个叫从错误中恢复的指标一条轨迹被认为包含负面观察如果在执行过程中任何工具的输出匹配了错误模式Python异常回溯、未执行替换、shell错误等恢复率是指在包含负面观察的轨迹中最终仍然成功提交了有效修复的比例。基准模型只有R2E-Gym后训练有88.8%的轨迹碰到了负面观察加了中间训练的模型这个比例是91.8%——也就是说两者看到的错误数量基本相当。但基准模型的恢复率是24.8%加了中间训练的是28.8%高出了整整4个百分点相对提升16%。加了中间训练的模型还表现出更倾向迭代验证的工作风格在成功解决的任务上平均编辑操作次数从3.3次上升到7.4次平均轨迹步骤数从15.1步增加到23.6步。代价是碰到步骤上限的轨迹比例从7%上升到45%但这些超步主要发生在未解决的任务上在已解决的任务上额外的步骤都转化成了更正确的修复。按照金标答案的补丁类型来分层分析结果进一步验证了研究的核心假设。在341个只需要修改单个函数的任务上中间训练的提升是2.1个百分点而在88个需要同时修改同一文件里多个函数的任务上提升高达9.1个百分点是单函数任务的4倍多。这正好对应了中间训练的内容——多函数组合填空训练让模型更擅长跨函数的逻辑推理。在71个需要跨文件修改的任务上两个模型的表现几乎一样约11.3%没有差异。研究团队解释说他们的填空训练是在单个文件内部进行的跨文件协调能力没有被直接训练所以在这类任务上没有体现出优势。失败模式的分布也有明显变化。基准模型平均每轮评估有约11条轨迹以空补丁结束AI完全没有提交任何修改就放弃了加了中间训练之后这个数字下降到约1条基本消失。定位错误提交了修改但没修改对文件轻微减少131条降到约126条补丁错误改了对文件但测试还是没过基本不变约227条。所以增加的15个成功解决的任务主要来源是那些AI放弃了但其实有希望的案例。研究团队的解释是在填空训练中模型总是被要求在前缀和后缀之间生成一个非空的内容。这种必须生成内容的惯性在后训练之后存活了下来让模型不容易放弃、不容易直接交空卷。**十、说说局限性**研究团队在论文中明确指出了四个边界。首先整个训练语料库和测试基准都是Python。跨语言的迁移能力没有被直接测试Java、C、Rust能不能受益还不知道。FullStackBench-EN的间接证据显示对多语言编码有一定帮助但不够直接。其次默认配方依赖Gemini 3 Flash生成推理过程。虽然消融实验表明模型自身生成的推理过程可以回收大部分收益但对于想要完全开源复现的团队来说需要一个同等能力的开源教师模型这不是随手可得的。第三在非Qwen2.5-Coder模型上的验证只有一个配置Qwen3-8B加SWE-Lego而且这个配置同时换了基础模型和后训练框架。所以只能说方法不局限于特定组合但不能说它在所有模型家族上都保证有效。第四整个方法建立在代码有良好模块化结构的假设上。如果是单体脚本、自动生成的代码或Jupyter Notebook这种没有清晰函数边界的代码选函数的流程就找不到足够的候选目标这个场景没有被系统研究。说到底这项研究提供的是一个可以在现有训练流水线里插入的额外步骤不需要修改后训练框架本身只需要在进入后训练之前多跑一轮中间训练。代价是额外的计算研究团队完整复现整套实验大约需要5760个GPU小时在8张H100上跑约30天换来的是在代码修复任务上稳定的3到5个百分点的提升以及对通用代码和工具使用能力的大幅保留——这种修了一件事顺带修了另外几件事的结果在AI训练里并不常见。归根结底这项研究的出发点来自一个朴素的观察AI修代码时需要的那种看懂工具返回了什么然后继续的能力其实在普通代码里到处都是只是之前的训练方式没有把这个结构显式地暴露给模型。通过按照函数边界来挖空填补配合推理过程的训练再放在任务训练之前的正确时间节点上这种现成的信号就被有效地利用起来了。有兴趣深入了解细节的读者可以通过arXiv编号2607.12463查阅原始论文研究团队的代码和数据集也已在GitHub的TIGER-AI-Lab/FIM-Midtraining仓库公开发布。---QAQ1SWE-Bench是什么用它来测试AI修代码能力靠谱吗ASWE-Bench是一个用真实GitHub Issue来测试AI代码修复能力的标准测试集分为Verified500个经人工验证的问题和Lite300个问题两个版本。测试题目都是从真实开源项目里抽取的有标准的参考修复方案评判方式是提交的修改能不能让原来失败的测试通过。这是目前业界公认的衡量AI代码智能体能力的主要基准之一被普遍认为比合成测试更能反映真实能力。Q2函数感知填中间中间训练需要多少计算资源普通研究团队能复现吗A研究团队使用8张NVIDIA H100 80GB显卡组成的单节点服务器完整复现所有实验三个基础模型的中间训练、三套后训练框架及其对应的中间训练版本、消融实验和多轮评估大约需要5760个GPU小时折合约30天。数据生成阶段还调用了Gemini 3 Flash的API来生成推理过程这部分有额外的API费用。代码和数据集已在GitHub开放感兴趣的团队可以选择性地复现部分实验而非全套计算成本会相应降低。Q3为什么只做SWE-Bench成绩好的后训练模型在普通代码生成测试上反而变差了A这是专项后训练的常见副作用本质是过度专业化。后训练用的数据都是AI修复GitHub Issue的完整行动轨迹模型学习的是在真实代码仓库里查文件、定位问题、做修改、看测试结果这套特定工作流。这种分布的数据反复训练会让模型的参数逐渐向这个窄分布倾斜挤压掉一部分通用代码能力和工具调用能力。中间训练建立的函数调用结构惯性在某种程度上充当了通用能力的锚点所以加入中间训练之后专项能力提升的同时通用能力的退化也得到了部分抑制。
