这项由瑞士意大利语大学软件研究院（SEART实验室）与西班牙塞维利亚大学（SCORE实验室）联合开展的研究，以预印本形式于2026年6月15日发布在arXiv平台，编号为arXiv:2606.16827。有兴趣深入了解的读者可通过该编号查阅完整论文。
每天，全球数以百万计的程序员都在借助AI的力量写代码——GitHub Copilot帮你补全函数，ChatGPT帮你调试逻辑，这些工具用起来顺手得像个随叫随到的同事。但你有没有想过，当一家公司自己开发了一门内部专用的编程语言，这些AI助手会怎么反应？答案是：它们会一脸茫然，就像一个英语老师突然被要求讲解一本用西夏文写成的教材。
这种"语言盲区"在工业界并不罕见。许多大型企业为了适应自身业务需求，会开发专有的或特定领域的编程语言。这些语言不在GitHub上广泛流传，AI模型从来没有"见过"它们，因此也就完全不懂如何使用。研究团队将这类语言称为"零资源语言"——不是说这门语言本身没有价值，而是指AI可以学习的训练材料几乎为零。
面对这个现实问题，研究团队展开了一场颇具探索性的实验：他们选取了两门真实存在的、极其小众的新兴编程语言作为"零资源语言"的代表，系统性地测试了多种方法来"教会"AI使用这些语言，最终找到了一条既经济又高效的路径。
---
一、"语言界的三六九等"：高资源、低资源与零资源语言
要理解这项研究解决的问题，先得搞清楚编程语言界的"资源鸿沟"是怎么一回事。
把AI学习编程语言的过程类比为人类学外语。Python就像英语，全世界的书店、图书馆、网站都堆满了教材——GitHub上有超过2100万个Python项目，这些代码就是AI学习的"海量课本"。Java也差不多，将近1900万个仓库。AI模型在这样的"书海"里泡大，自然对这两门语言了如指掌。
Lua、R、Haskell这类语言则像是法语或西班牙语——材料不算丰富，但还是有几十万乃至近百万个项目可供学习。AI对它们的掌握程度参差不齐，但整体上还凑合。
然而，研究团队重点关注的"零资源语言"就完全不同了。他们选择了Gleam和MoonBit这两门语言作为研究对象。Gleam是一门强调类型安全的函数式编程语言，专为多线程可扩展性而设计，其第一个稳定版本于2024年3月才正式发布。MoonBit则是一门面向云计算和边缘计算的通用语言，编译器到2024年12月才正式对外开放。在GitHub上，Gleam仅有约2900个公开仓库，而MoonBit更是少得可怜，只有区区400个——而同样被归类为"低资源语言"的Racket，都有22200个仓库，R语言更达到98万个。换句话说，Gleam和MoonBit在AI的"眼中"几乎是透明的存在。
研究团队在2025年7月2日的统计数据显示，这两门语言的GitHub仓库数量与低资源语言之间存在至少一个数量级的差距。更关键的是，在大多数参与测试的AI模型的训练数据截止日期（2024年3月）之前，Gleam仅有560个仓库，MoonBit只有7个。这基本意味着，这些AI模型压根没有机会"学过"这两门语言。
为了确保实验的公平性和完整性，研究团队还将Racket、Julia、Haskell、Lua和R归为"低资源语言"，将Python和Java作为"高资源语言"，总共考察了九门编程语言在相同测试条件下的表现，形成了一个完整的资源梯度对照。
---
二、"三份卷子"：研究团队是如何出题考AI的
测试AI的代码生成能力，需要有具体的题目。研究团队采用了三套评测基准，并且为了让这三套题目能同等地考察所有九门语言，花费了大量时间和精力进行翻译和改编，前后耗费约340人时。
第一套题目叫HumanEval，第二套叫MBPP，这两套都是业界广泛使用的经典测试集，原本主要面向Python语言。借助MultiPL-E这一多语言翻译框架，它们已经被转换成了包括各低资源语言在内的多种版本。研究团队在此基础上，进一步将这两套题目翻译成了Gleam和MoonBit版本。最终，HumanEval包含154道题，MBPP包含355道题。
翻译过程远比听起来复杂。不同语言对同一个编程概念有不同的叫法：Python里的"Array"到了MoonBit里叫"FixedArray"，Python的"List"在MoonBit里又变成了"Array"。研究团队先让ChatGPT做初步翻译，明确告诉它所有需要做的文字替换规则，再通过自动语法检查和人工审核两道关卡来纠错。测试用例的翻译同样如此，而且由于ChatGPT对这两门小众语言知之甚少，测试代码需要大量人工修正。
第三套题目叫McEval-Hard，是研究团队从另一个大型多语言测试集McEval中精心筛选和改编而来的。McEval原本覆盖40门编程语言、约2000道题，但各语言之间的题目并不统一，难以横向比较。研究团队从中提取了"困难"级别的题目，过滤掉没有测试用例的题（35道）、在多种语言中重复出现的题（87道）以及过于依赖特定源语言特性的题，最终留下227道题，再翻译成九种语言版本。这套题目被称为McEval-Hard，是三套题目中最具挑战性的。
为了确保Gleam版本的翻译质量，研究团队甚至联系到了Gleam语言的创始人本人，请他对随机抽取的50道题进行审查。反馈结果是没有发现重大问题，主要建议是一些不影响代码功能的风格改进。这种来自语言发明者的背书，给翻译质量提供了一层可靠的保障。
---
三、"考试成绩单"：AI面对这些语言时到底表现如何
测试条件确定后，研究团队让四款主流AI模型参加了"零样本"考试——也就是不给任何参考资料、直接让AI生成代码的原始状态。参与测试的四款模型包括OpenAI的GPT-4o和o3-mini，以及阿里云的Qwen 2.5 Coder 32B Instruct和Qwen 3 32B Instruct。每款模型在每道题上独立作答10次，以考虑AI输出的随机性。
成绩的核心指标是pass@1，可以简单理解为"一次答对的概率"——如果AI生成的代码能通过所有测试用例，就算答对。
高资源语言的成绩令人满意。对于Python和Java，四款模型的pass@1得分在59%到97%之间，平均约79%。换句话说，AI在面对它们"熟悉"的语言时，十道题里能答对七八道，表现相当不错。
低资源语言的成绩参差不齐，但整体仍在可接受范围内。Racket、Julia、Haskell、Lua和R的得分在27%到87%之间，平均62%。在60种"语言×模型×测试集"的组合中，有49种的pass@1超过了50%。值得注意的是，成绩的高低并不完全由GitHub上的仓库数量决定——Lua的仓库数量明显少于R，但AI在Lua上的表现却普遍好于R。研究团队推测，这是因为Lua的语法和Python更接近，AI可以借用对Python的理解来类推Lua。
到了零资源语言，成绩就惨不忍睹了。Gleam和MoonBit的得分在0%到20%之间，平均仅9%。在最难的McEval-Hard测试集上，四款模型在这两门语言上的最高得分是o3-mini在MoonBit上的1.1%，其余几乎全部趋近于零。
有趣的是，在较简单的HumanEval和MBPP测试集上，AI在零资源语言上偶尔也能答对一些题，得分甚至能达到10%以上。原因在于，这些测试集里有很多极度简单的任务，比如"写一个计算正方体体积的函数"。这类问题只需要写出"return l * l * l"这样的函数体，而函数签名（也就是参数和返回类型的声明格式）已经在题目里给出了。MoonBit的函数签名格式恰好和Rust语言非常相似，而AI早就见过大量Rust代码，于是可以靠"迁移学习"蒙混过关。但一旦题目变难，需要真正理解语言的特性和语法，AI就彻底失去了方向。
研究团队还对所有答错的代码进行了分类分析，区分"语法错误"（代码本身就写得不符合该语言的语法规则，根本无法运行）和"语义错误"（语法没问题但逻辑不对）。对于高资源和低资源语言，语法错误的比例通常在10%以下，说明AI至少知道怎么"说话"，只是有时说错了意思。但在Gleam和MoonBit上，绝大多数错误都是语法错误——表现最好的GPT-4o有将近三分之二的失败源于语法问题，o3-mini在Gleam上这一比例甚至高达90%。这说明AI面对零资源语言时，连最基本的"开口说话"都做不到，更遑论表达正确的意思。
---
四、"补习班开课了"：研究团队尝试了哪些提升方法
确认了AI在零资源语言上的巨大短板之后，研究团队开始尝试各种"补课"方案，看看能否让这些AI模型在Gleam和MoonBit上有所长进。他们共测试了四种策略，分别对应不同的成本和复杂度。
**方法一：给AI"看例题"——少样本学习**
少样本学习（few-shot）的原理很简单：在向AI提问之前，先给它展示几个Gleam或MoonBit的代码示例，让它从例子中感受这门语言的风格和语法，然后再让它完成新的编程任务。研究团队从收集到的Gleam和MoonBit函数库中，用向量检索技术自动找出与当前任务最相关的五个示例，附在提问前面。
这个方法对四款有指令跟随能力的模型（GPT-4o、o3-mini、Qwen 2.5 Coder 32B Instruct和Qwen 3 32B Instruct）都进行了测试，结果有所改善，但幅度有限。以MoonBit为例，o3-mini在HumanEval上的pass@1从7.34%跃升至39.22%，提升非常显著；在McEval-Hard上则从1.10%升至12.20%，也算不错。Gleam方面提升相对有限。总体来看，这种方法能减少15.36%的语法错误，对简单任务帮助明显，但在面对复杂编程挑战时效果大打折扣。
**方法二：把语言文档塞给AI——检索增强生成**
检索增强生成（RAG）的思路是：把Gleam和MoonBit的官方文档全部向量化存储，每次给AI出题时，先分析这道题需要哪方面的知识，再从文档库里自动检索最相关的段落，一起塞进提问中。具体流程分三步：先让一个辅助AI生成一份解题步骤计划，再针对每个步骤生成检索查询词，最后从文档库里取出相关内容并压缩摘要，附加到最终提问中。
RAG的表现略逊于直接给代码示例的少样本学习。在12种Gleam测试场景中，有7种少样本学习优于RAG；在MoonBit的12种场景中，有8种少样本学习更好。研究团队推测，AI从具体代码示例中学习语法的效率，要高于从文字说明文档中学习。RAG只减少了8.94%的语法错误，而少样本学习减少了15.36%。
在实验过程中，研究团队还额外尝试了一种"人工手册"方案：请GPT-4.1把所有与测试题目相关的文档内容整理成一份精简的语言速查手册，在每次提问时附上这份手册。这个方案的效果介于少样本学习和微调之间，在简单测试集上表现不错，但在最难的McEval-Hard上仍然差强人意（Gleam仅1.76%，MoonBit仅6.61%）。由于手册是"量身定制"的，在真实使用场景中并不实际可行。
**方法三：让AI"刷题练习"——微调训练**
微调（fine-tuning）是一种更主动的训练方式。研究团队从GitHub上收集到的Gleam和MoonBit代码仓库中，自动提取所有带有注释说明的函数，构建成"描述→代码"配对数据集，然后用这批数据继续训练AI模型，相当于给AI补了一套针对特定语言的专项练习。
为了避免数据泄露（测试题出现在训练数据里导致"作弊"），研究团队做了严格的过滤：自动剔除所有包含与测试题同名函数的文件，并提取测试题中所有8-gram（连续8个词的片段），在训练数据中逐一检查是否有匹配。最终，Gleam获得13534个可用函数，MoonBit获得2444个。
微调使用了LoRA（低秩适应）技术，这是一种在不修改AI模型全部参数的情况下进行针对性训练的高效方法。训练在开源的Qwen 2.5 Coder 32B Instruct和Qwen 3 32B Instruct上进行，历时5轮。
结果显示，微调明显优于两种上下文学习方法。以Gleam为例，Qwen 3 32B Instruct经过微调后，在HumanEval上达到23.57%，在MBPP上达到37.32%，在McEval-Hard上达到3.88%，均显著高于少样本学习和RAG。更值得关注的是，经过微调的开源模型，在很多情况下超过了商业模型（GPT-4o、o3-mini）配合少样本学习的表现。
**方法四：从源头"重塑记忆"——持续预训练**
与微调不同，持续预训练（further pre-training）是让AI在更大量的原始代码数据上重新学习，目标是让AI真正"理解"这门语言的全貌，而不仅仅是学会根据描述生成代码。研究团队把收集到的所有Gleam和MoonBit代码文件，以及官方文档（语言概述、教程材料、语言速查表、标准库说明），全部打包成预训练数据集。
Gleam的预训练数据集共包含约2830万个词语单元（tokens），MoonBit约1370万个。相比之下，微调数据集要小得多：Gleam仅360万，MoonBit只有50万。这个数量级的差距，正是预训练效果更好的根本原因——它能利用所有可用的语言信息，而不仅限于带有描述注释的函数。
持续预训练只能施加在"基础模型"（base model）上，也就是尚未进行指令跟随训练的原始版本。对已经经过指令调优的模型（instruct model）进行持续预训练，会破坏模型已有的"听话"能力，让它忘了如何按照人类指令行事。因此，研究团队选择了Qwen 2.5 Coder 32B Base和Qwen 3 8B Base（注意：Qwen 3没有32B的基础版本，只有8B版本）进行实验。
结果令人振奋。经过持续预训练的Qwen 2.5 Coder 32B Base，在Gleam的McEval-Hard上达到12.47%，远超微调版Qwen 2.5 Coder 32B Instruct的3.04%；在MoonBit上更是达到25.86%，而对应的微调版本只有10.93%。较小的Qwen 3 8B Base在MoonBit上甚至可以与微调版32B模型相提并论：McEval-Hard分别是19.87%（预训练8B）对13.04%（微调32B）。
所有这些差异都经过了McNemar统计显著性检验（调整p值后），结果均具有统计显著性，比值比（OR）从1.89到4.24不等，表明这种差异不是偶然的。
然而，持续预训练有一个明显的短板：它训练出来的基础模型不具备"听话"的能力，无法理解人类用自然语言描述的编程需求。作为一个编程助手，如果不能理解用户的指令，那根本没有实用价值。这个问题怎么解决？
---
五、"免费移植技能"：一个巧妙的"权重差值转移"方法
研究团队在自然语言处理领域的近期研究中找到了灵感，提出了一种被称为"指令转移"的方法，用极低的成本解决了上述难题。
整个逻辑可以用一个"食谱改良"的比喻来理解。假设有一位厨师（基础模型），他掌握了最基本的烹饪技能，但不太懂得怎样按照顾客的要求来调整菜品。后来，他的徒弟（指令模型）在他的基础上专门学习了"如何理解顾客需求"，变得非常善于按照点餐描述来做菜。现在，研究团队要做的是：先给这位厨师（基础模型）专门培训了一项新技能——比如精通某种新奇食材的烹饪（零资源语言）——得到了一位掌握新食材的厨师（预训练基础模型）。接下来，为了让这位新厨师也能"听懂顾客点餐"，只需要计算出徒弟比师傅多学了哪些"服务技能"（指令模型与基础模型之间的权重差值），然后把这些技能直接"打包移植"给新厨师即可。
用学术语言表述就是：计算指令模型（Mi）和对应基础模型（Mb）之间的权重差值（△w），然后将这个差值直接加到经过预训练的新基础模型（Mbk）的权重上，得到一个既掌握目标语言又能听懂指令的综合模型（Mbk+i）。整个过程只需要用CPU做简单的矩阵运算，成本几乎可以忽略不计，与动辄需要数千GPU小时的指令精调完全不在一个量级。
研究团队在Qwen 2.5 Coder 32B和Qwen 3 8B这两对"基础模型+指令模型"上验证了这个方法。由于Qwen 3 8B Instruct是一个具有推理能力的模型，这次权重差值转移预期还能将推理能力一并注入到预训练后的基础模型中。
结果令人满意。相比单纯的持续预训练，指令转移在几乎所有情况下都带来了显著提升，平均提升约12个百分点的pass@1。提升幅度最大的案例是：Qwen 3 8B在Gleam的HumanEval测试中，从18.57%跃升至51.88%，提升了33个百分点；在McEval-Hard上则从4.36%升至22.33%。Qwen 2.5 Coder 32B在Gleam的McEval-Hard上从12.47%升至26.08%，在MoonBit上从25.86%升至32.60%。唯一没有改善的案例是Qwen 3 8B在MoonBit的McEval-Hard上（19.87% vs 19.82%），差距微乎其微且统计上不显著。
更令人惊喜的是，经过指令转移的8B小模型，在各项测试中竟然始终超过没有经过任何特殊处理的32B大模型，哪怕后者配合了少样本学习或微调等手段。这意味着聪明地运用知识迁移，其价值远超单纯地堆砌模型规模。
研究团队还注意到一个微妙的差异：对于32B大模型，指令转移同时减少了语法错误和语义错误；但对于8B小模型，指令转移虽然整体性能提升了，语法错误的数量反而有所增加（语义错误减少幅度更大）。这可能是因为小模型的参数容量有限，在获得指令跟随能力的同时，需要在某些方面做出"取舍"，语法准确度略有下降，但整体代码逻辑的正确性有所提高。
---
六、实验的严谨性与局限性
任何研究都有其边界，这项研究同样坦诚地讨论了可能影响结论可靠性的几个方面。
首先是训练数据的假设问题。研究的核心前提是AI模型在训练时没有接触过Gleam或MoonBit，但这无法被完全证实——各大AI公司并不完整公开训练数据的内容清单。不过，从Qwen系列模型的官方文档来看，这两门语言都没有被列为"支持的编程语言"，加上它们发布时间较晚，即便有所涉及也极为有限，因此这个假设的合理性较强。
其次是基准测试翻译的质量。研究团队对翻译质量做了严格的抽样审查，从3061道题中抽取了346道进行人工审核。最终发现了14道有问题的提示词（4%）和2个有问题的测试用例（0.6%），这个错误率在同类研究中属于正常水平。事实上，即使是业界广泛使用的SWE-Bench基准，也被近期研究发现存在导致评分虚高约6.4%的测试缺陷。
再者，研究使用的是函数级别的代码生成任务（给定函数描述和签名，要求补全函数体），而非更复杂的需求（如修复整个代码仓库中的缺陷）。这种简化有其合理性：对于零资源语言，连基础的函数生成都是挑战，更复杂的任务会更难评估。但实际工业场景中，开发者需要的往往不止于此。
此外，Gleam主要面向分布式系统和网络开发场景，MoonBit则定位为通用语言。测试题目来自通用编程任务，可能无法完整反映这些语言在其专属领域中的实际使用情况。研究团队计划在后续工作中针对这些语言的特定应用场景设计更贴近实战的测试题目。
---
说到底，这项研究揭示的是一个对工业界极具实际意义的现实：当你的公司使用了一门AI从未见过的编程语言，并不意味着AI对你毫无帮助，只是需要用对方法。研究团队把这个问题从"无解"变成了"有解"，而且找到的解法出乎意料地经济实惠。
研究的核心结论清晰明了：不同的补课方案，效果差异巨大。简单地给AI看几个代码示例（少样本学习）有帮助，但远远不够；让AI读文档（RAG）效果类似；真正让AI把语言"刻进脑子里"的方式，是在大量代码数据上做持续预训练；而在预训练基础上用权重差值转移来"免费移植"指令跟随能力，是目前为止效果最好、成本最低的综合方案——在最难的测试集McEval-Hard上，Gleam和MoonBit分别达到了26.08%和32.60%的pass@1，相较于最初几乎为零的基线，这是相当实质性的改进。
当然，26%和33%离"好用"还有不小的距离。研究团队本身也没有声称这是一个完美的解决方案，而是将其定位为企业自建内部AI编程助手的可行起点。毕竟，对于那些完全得不到商业AI支持的专有语言，从0到26%，本身就是一个值得认真对待的进步。
随着AI技术的持续演进，未来这套方法能达到的上限还会不断提高。更重要的是，整个研究流程和所有基准数据集都已经公开，任何有需要的机构都可以直接采用这套方法，为自己的内部编程语言"定制"一个AI助手。
---
Q&A
Q1：零资源编程语言和低资源编程语言有什么区别？
A：低资源编程语言（如Lua、R、Haskell）在GitHub上有数万到数十万个公开项目，AI训练时见过一定量的代码，表现参差但整体还算可以；而零资源编程语言（如Gleam、MoonBit）在AI训练数据截止时几乎不存在，仓库数量只有几百个，AI对其语法一无所知，面对这类语言时pass@1接近于零。
Q2：权重差值转移方法为什么不需要重新做指令微调？
A：指令微调的核心是让模型学会"按照人类自然语言的要求生成代码"，这些能力被编码在模型参数中。只要基础模型和指令模型的架构完全相同，指令模型参数减去基础模型参数得到的"差值"，就代表了指令能力的净增量。把这个差值直接加到另一个经过预训练的基础模型上，相当于把指令能力直接嫁接过去，只需要CPU做矩阵加法，不需要重新跑大规模训练。
Q3：这项研究的方法能否用于公司自研的专有编程语言？
A：理论上完全可以。只要公司能收集到足够的专有语言代码文件（哪怕是几千到几万个），以及该语言的官方文档，就可以按照论文描述的流程进行持续预训练，再配合权重差值转移注入指令能力。研究团队已经将所有基准数据、代码脚本和实验配置公开，企业可以直接参考复用。
