多机构联手，教会AI说一门"小众编程语言"

这项由格拉茨理工大学（Graz University of Technology）、瑞士意大利大学（Università della Svizzera italiana）、法国里尔大学/Inria/CNRS、波尔多大学以及CIRAD等多家机构联合完成的研究，于2026年7月发表在arXiv预印本平台，论文编号为arXiv:2607.04939。研究聚焦于如何为一门极度"冷门"的编程语言——Pharo——打造出真正好用的AI代码补全工具。

你有没有这样的经历：用中文打字时，输入法能聪明地猜出你接下来想说什么，替你补全整句话；但换成一门小语种，比如冰岛语，输入法就彻底"失聪"了，每个字都得自己敲。程序员的世界里，同样的问题正在上演——只不过主角从语言变成了编程语言。

主流编程语言如Python、Java，AI助手用起来得心应手，甚至能替你写出整段复杂的逻辑；但对于那些"小众"编程语言，AI几乎两眼一抹黑，连最基本的语法都写错。Pharo就是这样一门小众语言，它诞生自Smalltalk家族，拥有自己独特的哲学与语法，却在AI浪潮中几乎被彻底遗忘。

这篇论文的核心故事，正是一群来自欧洲多所大学和研究机构的研究者，如何从零开始，一步步"教会"AI说Pharo这门语言，并最终做出一个小到可以在普通笔记本电脑上实时运行、快到开发者几乎感觉不到等待的智能代码补全引擎。

一、Pharo：一门被AI遗忘的编程语言

要理解这项研究的难度，需要先弄清楚Pharo为什么这么"特殊"。

AI学习编程语言，本质上和人类背单词、学语法没有太大区别——它需要看大量的例子，反复揣摩规律，才能掌握一门语言的用法。问题是，AI学编程主要靠"扫荡"GitHub这类代码托管网站上的公开项目。Python在GitHub上有约2600万个公开仓库，像是一座藏书无数的大图书馆；而Pharo呢？只有大约2000个——差距是整整四个数量级，相当于一座豪华大图书馆对比一个街边小书摊。

即便是以前被学术界认定为"资源匮乏"的编程语言，处境也比Pharo好得多。比如Lua有约62万个仓库，Julia有约8.5万个，Racket有约2.3万个，这些语言的数据量至少比Pharo多出一个数量级。换句话说，Pharo是"小众中的小众"，数据稀缺到了近乎极端的程度。

除了数据稀缺，Pharo还有两个让AI格外头疼的特性。其一是代码的存储格式。Pharo使用一种叫"Tonel"的专用格式来管理代码。这种格式混合了可运行的代码和各种元数据（比如类名、包名、分类标签等），就像一本书里把正文和出版信息、版权声明、目录混排在一起，AI在学习时很容易搞不清楚哪些是"真正要执行的代码"，哪些只是"标签和说明"。

其二是Pharo继承自Smalltalk的独特语法哲学。在绝大多数主流编程语言里，if、while、for这些控制流关键字是语言本身内置的"特殊命令"；但在Pharo里，它们只是普通的方法调用，和你自己定义的函数没有本质区别。这就好像，别的语言里"向左转""向右转"是专门的交通指令，而在Pharo里，这些动作只是某个普通导航对象的一个方法——看起来一样，但背后的逻辑完全不同。此外，Pharo的方法命名方式也很特别：参数不是统一堆在方法名后面，而是和方法名的各个部分交替出现，比如`at: aSymbol ifAbsentPut: aBlock`，读起来像英文句子，但对习惯了Python或Java的AI来说，却是陌生的"外星语法"。

正因如此，Pharo的开发环境目前只能提供最原始的"单词补全"——你打出前几个字母，系统告诉你有哪些候选词，仅此而已，根本无法像现代AI代码助手那样一次性补全整行乃至整段代码。

二、研究者的思路：像培训厨师一样培训AI

面对这个困境，研究团队制定了一套系统性的解决方案，可以用培训一位厨师来类比理解整个过程。

第一步是备菜——收集干净可用的训练数据。研究者在GitHub上搜索所有标有"Pharo"标签且使用MIT开源协议的代码仓库（选MIT协议是因为这种协议允许将代码用于训练数据）。没有明确许可证的仓库全部排除，因为在没有授权的情况下使用代码，法律风险不可忽视。这一步初步筛选出748个仓库。

接下来，研究者还要确保这些代码是"新鲜的"。他们把每个仓库都导入Pharo 10到Pharo 14这五个最新版本的开发环境，凡是无法成功载入的仓库一律淘汰；同时，只保留使用Tonel格式存储的仓库。经过这些过滤，748个仓库缩减到415个。

然后，研究者把415个仓库按时间切分：2024年6月1日之前创建的用于训练，之后的用于测试。这个时间点的选择是有讲究的——研究所用的基础AI模型（Qwen2.5 Coder）的知识截止日期是2024年2月，选6月1日作为分界线，能最大限度地降低"AI考试前偷看了答案"的风险。最终，研究者从415个仓库中提取出387,159个Pharo方法作为原始素材。

为了处理这些代码，研究团队还专门开发了两个工具：一个是Pharo语言的词法分析器（集成进了Pygments这个通用代码高亮库），能把Pharo代码切分成有意义的最小单元；另一个是基于tree-sitter库的Pharo语法解析器，能把Pharo代码解析成抽象语法树（Abstract Syntax Tree，简称AST——你可以把它理解为代码的"骨架图"，清晰地展示出代码各个部分之间的层次关系）。这两个工具已作为开源成果公开，供未来研究者使用。

三、两阶段训练：先打地基，再装修

准备好食材后，正式的"烹饪"分两个阶段进行，这也是研究的核心技术部分。

第一阶段叫做"持续预训练"（Continued Pre-training）。现成的AI代码模型已经学过大量Python、Java等主流语言，有一定的代码理解基础；这一阶段的目标是让它在已有基础上，专门学习Pharo的语法和代码结构，就像一位已经学会做西餐的厨师，现在要系统学习中餐的基本功。

具体做法是：对387,159个Pharo方法，25%的情况下让AI从头到尾阅读完整代码；剩余75%则使用一种叫"填空题"的方式——从每个方法里随机挖掉一段代码（被挖掉的部分是一个完整的AST节点，包含3到10个词语单元），然后要求AI根据上下文把这段话补全。

之所以把"填空题"比例设这么高，是有研究依据的：让AI大量练习"看上下文补缺失部分"的任务，比单纯让它从左到右阅读代码，更能培养出适合代码补全场景的能力——因为开发者在写代码时，恰恰就是在一个已有上下文的环境里补全缺失的部分。

第二阶段叫做"监督微调"（Supervised Fine-tuning，SFT）。如果说预训练教会了AI Pharo的"书面语"，那微调就是让它学会"口语"——也就是真实开发场景下的用法。

这一阶段采用了一种叫"随机AST"（Random-AST）的掩码策略：不再只挖掉完整的语法结构块，而是从方法体里随机选一个位置开始遮盖，一直遮到当前语句的末尾。这样做模拟的是开发者在任意位置停下来、需要AI帮忙补全后续内容的真实场景。为了防止AI在学新技巧时忘记老技巧（这在机器学习里叫"灾难性遗忘"），研究者还在微调数据里混入了20%的预训练数据作为"复习材料"。最终用于微调的数据集包含324,725条训练实例。

值得一提的是，研究者选择的基础模型都支持一种叫"填空式生成"（Fill-in-the-Middle，FIM）的能力——模型不仅能看到光标左边的代码，还能同时看到光标右边的代码，利用两侧的上下文来决定中间该填什么。这对代码补全至关重要，因为很多时候你在一段已有代码的中间修改，前后都有内容。研究者选用了Qwen2.5 Coder（参数量分别为0.5B、1.5B、3B、7B）和Mellum（4B）两个模型系列，覆盖了不同规模和不同FIM策略的选择。

四、考试怎么出题：两套专门为Pharo定制的测试

训练完了要验证效果，但Pharo此前几乎没有现成的AI测试题库，研究团队不得不自己动手制作。他们最终设计了两大类测试。

第一类是方法级别的语法测试，分两套题目。第一套是把著名的Python代码生成测试集HumanEval+翻译成Pharo版本。HumanEval+原本是让AI写Python函数，研究者先用GPT-4o做初步翻译（还专门给GPT-4o提供了Pharo语法说明和翻译示例，帮它理解这门陌生语言），然后由一位有三年Smalltalk开发经验的团队成员逐题核查并修正错误，最终得到164道Pharo版题目。第二套是从Exercism平台（一个专门通过编程练习帮助开发者学习新语言的平台）收集的47道Pharo练习题，经过整理确保每道题都对应单一的参考答案方法。

两套题目合计211道，每道题都有标准答案和一组测试用例。评测方式是：随机遮盖标准答案的某一段，让AI补全，然后用测试用例验证补全后的代码是否正确运行。这也意味着评判标准相当严格——不是看AI的答案像不像，而是看代码能不能真正跑起来、通过所有测试。

遮盖方式同样有两种：AST感知遮盖（只遮盖完整的语法节点）和随机AST遮盖（从任意位置开始遮盖到语句末尾），对应不同难度和现实程度的测试场景。

第二类是仓库级别的真实场景测试，更接近开发者的日常工作。研究者从22个测试仓库里挖掘了488次真实提交记录，提取出开发者在这些提交中新增的代码，随机遮盖其中3到10个词语单元，让AI来补全。这类测试没有可运行的测试用例，只能通过对比AI的补全结果和开发者实际写的代码来评分——用的是ChrF（字符级别的文字相似度评分）和CrystalBLEU（专为代码设计的语义相似度评分）两个指标。

这类测试还有一个特别的维度：给AI的"参考资料"有多少？研究团队设计了四种不同的上下文供给方案。最简单的是"不给任何额外背景"，只给AI看需要补全的那个方法；稍多一些的是"给类签名"，提供当前类的声明和所有方法名；再多一些是"给包签名"，提供当前包里所有类的签名；最丰富的是"给关联方法"，提供同一次提交里其他被修改方法的完整代码（因为开发者在一次提交中改动的几个方法，往往在逻辑上是紧密相关的）。

为了搞清楚"关联方法"的效果到底来自额外信息量本身，还是来自信息的相关性，研究者还设计了一个对照组——从仓库里随机抽取同等数量的方法作为上下文。这个对照组的设计思路颇为严谨：如果随机方法的效果接近关联方法，说明只要给AI"更多代码看"就有用；如果差距明显，才能说明相关性才是关键。

五、成绩单揭晓：小模型如何打败大模型

测试结果在几个维度上都给出了相当清晰的答案。

在方法级别的语法测试上，专门训练后的模型表现大幅提升。以Qwen2.5 Coder 3B的专精版（3B-SFT）为例，在HumanEval+的AST感知测试上，正确率从71.48%跳升到83.73%，提升了12.25个百分点；在更接近真实场景的随机AST测试上，从44.47%提升到51.83%。对于原本基础较弱的小模型，提升幅度更加惊人——0.5B版本在Exercism随机AST测试上的正确率从9.12%飙升到27.01%，翻了将近三倍。

更值得关注的是与"大模型"的对比。研究者把训练好的小模型与两个远比它们庞大的模型放在一起比较：一个是Qwen3 Coder 480B（参数量达到4800亿，是7B专精版的约68倍），另一个是Claude 4.5 Sonnet（Anthropic公司的商业旗舰模型）。在方法级别的AST感知测试上，这两个大模型确实略占优势；但一旦切换到更贴近真实使用的随机AST测试，专精小模型就实现了逆袭——7B的专精版在HumanEval+随机AST测试上正确率为52.76%，而Qwen3 Coder 480B只有45.13%，Claude 4.5 Sonnet是51.53%，均低于7B专精版。

研究者还仔细分析了模型失败的原因，发现基础模型（没有经过Pharo专项训练）的失败有65.6%源于语法错误，17.9%是运行时异常，16.5%是逻辑错误。专项训练平均将语法错误减少了33%。这说明基础模型并非"不聪明"，它们完全有能力解决代码逻辑问题，只是不懂Pharo的语法规则。一个具体的例子是TripleSumToZero任务（检查集合中是否有三个元素之和为零），这道题在逻辑上并不难，但正确完成需要严格还原Pharo特有的括号结构和消息优先级。专精版7B模型20次测试全部通过；而所有基础模型要么写错括号，要么改变了运算顺序，导致语法错误或逻辑错误。

在仓库级别测试上，上下文质量的重要性得到了充分验证。对于训练好的专精模型，提供"关联方法"（同次提交的其他修改方法）作为上下文，能带来最显著的提升——以7B专精版为例，ChrF分数从60.05%提升到75.96%（+15.91%），CrystalBLEU从35.96%提升到58.99%（+23.03%）。而那个对照组"随机方法"虽然也有一定帮助，但效果远不如"关联方法"，证明了语义相关性才是上下文价值的核心。只提供类签名或包签名，效果非常有限，多数情况下不具备统计显著性。这个发现有实际应用价值：在IDE中，完全可以把开发者最近修改过的方法自动放入上下文，帮助AI做出更准确的补全。

在仓库级别测试中，即便是1.5B的小专精模型，配合"关联方法"上下文，也能超过参数量约320倍的Qwen3 Coder 480B。3B和7B的专精版平均领先Qwen3 Coder 480B的ChrF约7.52%、CrystalBLEU约8.63%。Claude 4.5 Sonnet在这项测试中表现最好，ChrF达到83.02%，CrystalBLEU达到70.52%；不过研究者特别指出，Claude的训练数据不透明，不能排除它"见过"测试仓库的可能性——它在没有任何上下文的情况下也能拿到很高分，这个异常表现确实有些可疑。

六、速度够快吗？能装进笔记本吗？

再好的补全模型，如果慢得像蜗牛爬，开发者也不会用。研究者对专精模型进行了实际速度测试。

对于7B模型，他们采用Q4_K_M量化方案（通过llama.cpp工具实现）——这就像把一个体积庞大的行李箱压缩打包，让它更容易携带。量化之后，7B模型的内存占用从14.19GB骤降到4.36GB（压缩约70%），而代码补全正确率仅下降0.61%，几乎可以忽略不计。4.36GB的内存需求，对近年出厂的笔记本电脑来说完全可以接受。

在Apple M3 Max芯片上，3B专精版平均补全延迟约0.725秒，量化后的7B版本约1.332秒。在更新的Apple M4 Max上，3B版约0.620秒，7B版约1.327秒。在配备AMD RX 7800XT独立显卡（这是一款面向游戏玩家的消费级显卡，约4000元人民币左右）的机器上，3B版约0.495秒，7B版约0.534秒。

对于代码补全来说，业界公认"感觉流畅"的响应时间门槛是1秒以内。3B专精版在所有测试平台上都达标；7B专精版在苹果芯片的CPU上略超1秒，但在独立显卡上完全达标。考虑到研究者并未使用任何"提示词缓存"等专业加速技巧，实际部署时还有进一步优化的空间。

七、这条路为什么这么难走，以及它对其他语言的启示

研究团队在论文中坦诚地记录了整个过程的工程难度。

教会一个AI说Pharo，并不只是"找来数据、点击训练"这么简单。研究者需要深入了解Pharo的生态，才能识别哪些数据可以合法使用、哪些格式需要特殊处理；需要从零开发词法分析器和语法解析器；需要设计符合Pharo特点的训练策略；需要翻译或收集评测题目，并搭建自动测试框架。这些"工程基础设施"的建设工作，花费的时间和精力远超模型训练本身。

然而从另一个角度看，这些工具和基准一旦建好，就成为了宝贵的公共财富。未来每次有更好的基础模型出现，只需重新跑一遍训练流程，不用再从头打基础。

对于其他小众编程语言来说，这个经验同样适用。无论面对哪门语言，关键的共同步骤是：能解析代码（有词法分析器和语法解析器）、能从合法来源收集数据、能设计语言特定的训练目标、能建立可执行或可量化的评测基准。Pharo的极端小众性使它成为一个"压力测试"——连这么难的情况都能做到，其他语言理论上更有希望。

归根结底，这项研究证明的事情很简单：数据少不等于没希望，规模小不等于能力差。一个经过精心调教、专门训练的小模型，在特定语言上打败体量是它数百倍的通用大模型，不是偶然，而是专业化的力量。对于无数使用小众编程语言的开发者来说，这意味着他们也有机会用上真正好用的AI代码助手，而不必永远仰望那些为主流语言用户打造的工具。这或许是这项研究最值得关注的地方。

研究团队目前正在将这套模型集成进Pharo的IDE，让开发者能实际体验AI补全的效果。对于这一切是如何实现的完整技术细节，感兴趣的读者可以通过论文编号arXiv:2607.04939查阅原始论文。

Q&A

Q1：Pharo编程语言为什么AI代码补全那么难做？

A：Pharo在GitHub上只有约2000个公开仓库，而Python有约2600万个，数据量差了四个数量级。加上Pharo使用特殊的Tonel代码存储格式（混合了代码和元数据），以及继承自Smalltalk的独特语法（比如if、while不是关键字而是普通方法调用），这三重挑战叠加在一起，导致通用AI模型几乎完全不懂Pharo语法，补全准确率极低。

Q2：小模型怎么能打败比自己大几百倍的通用大模型？

A：核心原因是"专业化"。通用大模型虽然参数多、见过的代码多，但Pharo的训练数据极少，它们对Pharo语法的掌握程度很有限。经过专项训练的小模型则大量"刷题"练习Pharo语法，在Pharo这个垂直领域的准确率大幅超越通用大模型，就像专科医生在特定病症上往往比全科医生更有把握。

Q3：Pharo专精模型能在普通电脑上用吗？

A：可以。研究者对7B规模的专精模型进行了4位量化压缩，内存占用从14GB降到4.36GB，在配有游戏级显卡（如AMD RX 7800XT）的电脑上补全延迟约0.534秒；在苹果M3/M4 Max笔记本上，3B版本延迟约0.6到0.7秒，均接近或达到代码补全所需的实时响应标准。