当AI只会"说普通话"却不懂"方言"：GigaCode团队打造全球首个12语言编程评测基准，揭开大模型代码能力的真实面目

这项由GigaCode与亚德克斯数据分析学院应用人工智能研究所联合开展的研究，发表于2026年的国际学习表征会议（ICLR 2026），论文编号为arXiv:2606.20517，发表时间为2026年6月18日。

全球有数以亿计的软件开发者，他们每天用Python、Java、C++、Rust等五花八门的编程语言写代码。这就好像人类社会存在汉语、英语、法语、阿拉伯语等各种自然语言一样，编程世界同样是多语言并存的。近年来，各大科技公司争相推出能帮人写代码的人工智能助手，这些助手的厉害程度让人咋舌——它们似乎能解决各种复杂的算法问题、自动补全代码、甚至独立完成整个模块的开发。

然而，一个被忽视已久的问题悄然浮出水面：我们平时用来衡量这些AI写代码能力的考卷，几乎清一色只考Python这一门语言。这就好比你要招聘一个翻译，考试却只考英译中，完全不测法语、德语或日语的水平，然后理所当然地认为英译中高分的人，在其他语言上一定也同样出色。这个假设靠谱吗？

GigaCode的研究团队决定用数据来回答这个问题。他们构建了一个名为Multi-LCB的全新评测基准，将目前最权威的Python代码评测平台LiveCodeBench（简称LCB）扩展到12种编程语言，然后用这把新尺子重新丈量了24个当前最先进的AI大语言模型。结果令人大开眼界：许多在Python考试中光芒万丈的模型，一旦换到其他语言，成绩急剧缩水；而某些模型的"偏科"程度之严重，简直像是只会说普通话却完全不通方言的"单语者"。

一、一把只量"身高"的尺子：现有评测体系的根本缺陷

在理解这项研究之前，先来说说"评测基准"是什么。评测基准就是考卷，是用来测量AI写代码能力的标准化测试。目前业界最流行的几张考卷，包括HumanEval、MBPP和APPS，都有一个共同特点：它们只考Python。

LiveCodeBench在这些老牌考卷的基础上做了重大改进。它从LeetCode、AtCoder和Codeforces这三个顶级编程竞赛平台持续抓取新题目，并按照题目发布日期进行过滤。这个设计解决了一个棘手的问题：AI模型在训练时可能已经"见过"那些老题目，就像学生提前拿到了考卷，成绩自然虚高。通过只使用模型训练结束之后发布的新题目，LiveCodeBench能更准确地测量AI的真实能力，而不是死记硬背的能力。正因如此，LiveCodeBench迅速成为业界公认的权威标准，谷歌、DeepSeek等顶尖机构都用它来评估自家模型的代码能力。

但LCB有一个根本性的局限：它只考Python。在现实的软件工程世界中，Python当然重要，但C++用于游戏引擎和高性能计算，Java支撑着全球大多数企业级系统，JavaScript和TypeScript主宰着Web前端开发，Rust正在成为系统编程的新宠，Go是云计算基础设施的核心语言。一个只会Python的AI，在这个多语言的真实世界里能走多远？

GigaCode团队意识到，仅凭Python成绩来判断一个AI模型的综合编程能力，就像只凭一个人的跑步速度来评价他是否是一位全能运动员。跑步很重要，但游泳、举重、体操呢？Multi-LCB的诞生，正是为了给这场评测加上那些缺失的项目。

二、12门语言的大考：Multi-LCB是如何炼成的

要把只面向Python的考卷扩展到12种语言，听起来简单，实际上暗藏玄机。研究团队面临的第一道难关，就是题目格式的问题。

LCB包含来自三个平台的题目，而这三个平台的题目格式截然不同。AtCoder和Codeforces的题目使用"标准输入输出"格式，简单说就是程序从键盘读数据，把答案打印到屏幕上——这种格式本身就是语言无关的，任何编程语言都能轻松应对。但LeetCode的题目是"函数式"格式，它要求你实现一个特定的函数，由测试系统来调用这个函数——问题在于，Python的函数定义方式和Java、Rust、C#截然不同，同一道题在不同语言里需要完全不同的函数模板，维护起来极为繁琐且容易出错。

研究团队设计了一套自动转换流水线，把所有LeetCode的函数式题目统一转换成标准输入输出格式。举个例子，LeetCode原题可能是给你一个列表enemyEnergies和一个数字currentEnergy，让你实现一个计算最大得分的函数。转换之后，这道题就变成了：程序从键盘读入"3 2 2"（代表列表）和"2"（代表currentEnergy），然后打印出"3"（答案）。这种格式对任何编程语言都一视同仁，完美解决了跨语言兼容性的问题。

转换流水线还负责处理不同维度的数据：标量（单个数字或字符串）、一维数组（数字列表）和二维数组（矩阵）都有对应的标准化格式，确保每道题的输入输出方式在所有12种语言中完全一致。研究团队还手工检查了约500道题，确认没有任何题目包含Python特有的逻辑，所有题目都是语言无关的——这得益于LeetCode、AtCoder、Codeforces这些平台本身就支持多种语言，题目设计时就刻意避免了语言依赖性。

至于12种语言的选择，研究团队综合考量了三个维度：在GitHub、Stack Overflow、RedMonk和TIOBE等权威排行榜上的流行度，有成熟包管理器支持的稳定执行环境，以及编程范式的多样性。最终入选的12种语言涵盖了编译型（C++、Rust、Go、Java、C#、Scala、Kotlin）、解释型（Python、Ruby、PHP）和转译型（TypeScript编译为JavaScript）三大类，覆盖了静态类型和动态类型两种类型系统，以及手动内存管理、所有权机制和垃圾回收三种内存管理模型。这12种语言的组合，像一幅完整的编程语言生态全景图，而非随意拼凑的样本。

在评测环境方面，每种语言都在独立的沙箱容器中运行，配备了各自对应的编译器或解释器，例如C++使用GCC 14.3.0，Rust使用1.88.0版本，Java使用OpenJDK 8。每道题的执行时间上限为6秒，内存上限为4GB，且完全断网，确保结果的确定性和公平性。所有实验在配备16块NVIDIA H100 80GB显卡的集群上运行，算力保障充分。

三、让AI"答卷"：评测协议的设计细节

测量AI写代码能力，最公平的方式是什么？研究团队沿用了LiveCodeBench的零样本提示策略——就是直接把题目扔给AI，不给任何示例答案，让它凭自身能力作答，就像闭卷考试一样。

每道题的提示词由三部分组成。第一部分是系统指令，告诉AI它的角色，比如"你是一个Python专家程序员"或者"你是一个C++专家程序员"，根据当前考察的目标语言动态切换。第二部分是完整的题目描述，包含自然语言表述的问题和输入输出样例。第三部分是代码占位符，明确标示代码应该写在哪里，并指定代码块的语言标签（如"```python"、"```cpp"、"```java"）。

AI生成的代码会被实际编译并运行，与题目的标准答案进行比对。一道题只有在不报错、不超时、且所有测试用例（包括隐藏测试用例）都通过的情况下，才算做对。主要评测指标是Pass@1，意思是第一次生成的代码直接通过的比率，这个指标反映了AI在实际使用中的可靠性。每道题重复测试10次，取平均值，以减少随机性的影响。采样温度设为0.2，这是一个相对保守的设置，让AI的输出更稳定可预测，更接近真实使用场景。

研究团队还测试了0.6和1.0两种更高的温度设置，并分别统计了Pass@5（5次尝试中至少一次通过的比率）和Pass@10（10次尝试中至少一次通过的比率），提供更全面的性能画像。从实验结果来看，这些不同设置下的排名基本稳定，说明核心结论具有很强的鲁棒性，不随参数变化而改变。

四、24个顶级AI的成绩单：谁是真正的全才

研究团队选取了24个当前最具代表性的大语言模型参加这场12语言大考，参评阵容涵盖了从70亿到6850亿参数不等的各种规模，既有专门为代码训练的专业模型，也有面向通用任务的综合模型，既有普通指令微调版本，也有专门强化了"思维链推理"能力的推理增强版本。代表性选手包括GPT-OSS-120B（Medium）、Qwen3-235B-A22B-Thinking-2507、DeepSeek-R1-0528、OpenReasoning-Nemotron-32B等。

主要实验聚焦于2025年2月至2025年5月之间发布的新题目，这个时间窗口确保所有参评模型都处于"训练数据截止日期"之后，最大程度排除了"见过题目"的干扰。

成绩单上最显眼的发现是：没有任何一个模型在12种语言上都表现均衡。排名第一的GPT-OSS-120B（Medium）以平均67.8%的Pass@1位居榜首，而且它的成绩分布相当均匀，Python得71.1%，C++得72.3%，Go得69.9%，Rust得70.5%，跨语言波动不超过20个百分点。Qwen3-235B-A22B-Thinking-2507凭借Python的74.0%高分紧随其后，但它的Go只有56.7%，Rust只有47.7%，Ruby只有49.4%，与Python的差距高达二三十个百分点。

DeepSeek-R1-0528同样呈现出有趣的画像：Python得66.3%，但Scala得62.3%，Ruby得62.4%，Go得55.0%。相比Qwen3-235B系列，DeepSeek-R1在非Python语言上的下滑幅度更小，展现出更好的跨语言泛化能力。

排名中段的模型开始呈现明显分化。Qwen3-30B-A3B-Thinking-2507在Python上得64.0%，但Go骤降到44.1%，Rust只有51.7%，Ruby只有42.1%，平均分53.2%，落后于Python成绩约10个百分点以上。

最戏剧性的案例是OpenReasoning-Nemotron-32B和OpenCodeReasoning-Nemotron-1.1-32B这两个模型。它们的Python成绩分别高达64.4%和56.0%，在24个模型中排名相当靠前。然而，一旦切换到其他语言，成绩急剧崩塌——Go只有11.5%和9.9%，TypeScript只有10.5%和4.9%，Rust更是只有2.8%和1.1%，几乎等于完全不会。这两个模型的平均分分别只有22.7%和19.8%，与其Python成绩相差超过40个百分点，堪称"Python单科状元、其他科目不及格"的典型案例。

从语言维度来分析，Python在所有语言中平均得分最高，达到0.482（即48.2%）。Java和C++紧随其后，大约在0.44左右。C#、Ruby、PHP、Go、Rust、Kotlin以及JavaScript/TypeScript构成中间层，平均在0.33到0.39之间。Scala始终垫底，平均分低于0.29。这个梯队格局在几乎所有参评模型上都保持稳定，说明是系统性规律而非偶然现象。

五、Python神话的破灭：数据揭示的三个核心发现

仔细审视这份成绩单，研究团队发现了三个相互关联的重要规律，它们共同勾勒出当前AI编程能力的真实格局。

第一个发现是Python过拟合现象。几乎所有参评模型在Python上的得分都显著高于其他语言平均分，而且这种优势在推理增强型模型上尤为突出。研究团队绘制了一张散点图，横轴是每个模型在12种语言上的平均分，纵轴是该模型的Python单科分，几乎所有数据点都分布在"Python成绩 > 平均成绩"的对角线上方，清晰地显示出系统性的Python偏向。这强烈暗示当前主流模型的训练数据和强化学习信号严重偏向Python，非Python语言的训练覆盖明显不足。

第二个发现是Python成绩不是可靠的跨语言代理指标。研究团队发现，在Python上更强的模型，并不总能在其他语言上保持领先。以具体数字为例，GPT-OSS-120B（Medium）的Python分（71.1%）低于Qwen3-235B-A22B-Thinking-2507（74.0%），但GPT-OSS-120B在Go（69.9% vs 56.7%）、JavaScript（70.5% vs 67.0%）、TypeScript（70.3% vs 62.5%）、Rust（70.5% vs 47.7%）、Ruby（70.2% vs 49.4%）和Kotlin（71.0% vs 67.7%）上都大幅领先。同样，DeepSeek-R1-0528的Python分低于Qwen3-235B，但在Rust（63.1% vs 47.7%）、Ruby（62.4% vs 49.4%）和Scala（62.3% vs 57.6%）上都更强。这意味着，如果你需要一个能写Rust代码的AI助手，光看它的Python分是不够的，你必须直接测试它的Rust能力。

第三个发现是语言特异性污染的存在。研究团队进行了时间维度的分析，追踪模型在不同月份发布题目上的成绩变化。结果发现，所有模型在早期月份（即训练截止日期之前发布的题目）的成绩显著高于后期月份，而且成绩下降呈现出阶梯状——在接近模型训练截止日期的那个月前后，成绩出现明显的断崖式下滑，然后在更新的题目上维持在一个较低的稳定水平。这个模式强烈暗示，模型的高分部分来自于在训练数据中"见过"类似题目，而非真正的泛化推理能力。通过将评测窗口限定在2025年2月之后，研究团队尽量排除了这种"作弊"效应，确保测量的是真实能力。

六、与LiveCodeBench原版的比对：确认新考卷的公平性

在展示Multi-LCB的发现之前，研究团队首先需要证明一件事：这套新的多语言评测体系对于Python来说，和原版LiveCodeBench的结果是否一致？如果同一个模型用Multi-LCB测Python得了80分，而LCB原版给它打了50分，那说明Multi-LCB改变了题目难度或测试方式，结果就没有可比性了。

研究团队对比了16个模型在Multi-LCB Python子集和LCB官方排行榜上的成绩，结果相当令人放心。绝大多数模型的两套成绩偏差在3个百分点以内，最大偏差为8.6个百分点（Qwen3-8B的Thinking模式）。Qwen3-235B-A22B-Thinking-2507在Multi-LCB上得了74.0%，LCB官方是74.1%，几乎完美吻合。DeepSeek-R1-0528在Multi-LCB上得66.3%，LCB官方是68.7%，差异在可接受范围内。更重要的是，即使有些模型存在数个百分点的绝对分差，各模型之间的排名顺序基本保持一致。

这个比对结果有两重意义：它证明了Multi-LCB的Python测试部分忠实还原了LCB的评测标准，任何额外的挑战都来自于真实的跨语言泛化要求，而非测试设计本身引入的偏差；同时也说明，不同模型之间的小幅成绩差异可能源于正常的随机性和评测方式的细微差异，研究团队的10次平均处理已经将这种随机性降到了合理范围内。

七、编译耗时与错误类型：深入解剖失败的根源

Multi-LCB不仅提供了通过率数据，还记录了每道题每种语言的错误类型和运行时间，这让研究团队能够深入分析AI失败的根本原因，而不仅仅是知道"它答错了"。

从运行时间来看，不同语言的评测耗时差异悬殊。Ruby平均需要17分37秒才能跑完1050道题，Python需要11分38秒，Go需要12分36秒；而Kotlin只需3分14秒，PHP只需3分29秒，JavaScript只需3分44秒。这种差异主要反映了各语言工具链的编译开销和运行时效率，对评测基准的运营成本有直接影响。平均每种语言每个模型需要约8分50秒，12种语言合计约106小时的总计算时间。

从错误类型来看，研究团队发现了几个一致的规律。答案错误（Wrong Answer）是所有语言和所有模型中最常见的失败类型，这说明主要的瓶颈在于算法逻辑的正确性，而非代码语法或格式问题。换句话说，AI写错代码主要是因为没想清楚算法，而不是因为不会用某种语言的语法。

编译型语言（C++、Java、Rust、Go）比Python出现更多的编译错误和类型错误。Python因为是动态类型语言，很多类型问题在运行时才暴露，或者根本不会触发；但C++、Java、Rust等静态类型语言要求代码在编译阶段就类型完全正确，AI生成的代码更容易在编译阶段就被拒之门外。Rust的情况尤为特殊，因为它独特的所有权和借用检查机制让语法约束更加严格，即便是人类程序员也需要专门学习才能驾驭，对AI来说更是一大挑战。

Java、C#和Go比Python出现更多的运行时异常。这些语言在标准输入输出的处理上比Python更繁琐——Python的输入解析可以一行搞定，而Java可能需要Scanner对象，C#需要Console.ReadLine()，稍有不慎就会出现空指针异常或格式解析错误。这支持了Multi-LCB部分测量的是"在不同语言环境下正确处理输入输出的能力"这一诠释，虽然这与核心算法能力有所区别。

规模较小的模型（70亿至140亿参数）还会出现较多的"空代码"错误，即根本没有生成有效代码，而300亿参数以上的模型几乎不会出现这种情况，说明模型规模对基本代码生成能力有显著影响。

八、平台难度与时间趋势：竞赛题目的生态全景

Multi-LCB继承了LCB的三平台结构，研究团队对不同平台和不同难度级别的表现进行了深入分析。在整个数据集的1055道题中，LeetCode贡献了444道（42.1%），AtCoder贡献了602道（57.1%），Codeforces只有9道（0.9%）。从难度分布来看，简单题322道（30.5%），中等题383道（36.3%），困难题350道（33.2%），三档均衡分布，整体难度不低。

平台分析显示，不同模型在LeetCode和AtCoder上的表现存在有趣的差异。LeetCode的题目风格偏向数据结构和算法面试题，而AtCoder的题目更注重纯算法竞赛，对数学推理能力要求更高。有些模型在LeetCode的结构化题目上表现更好，另一些在AtCoder的竞赛风格题目上更为出色，这反映了训练数据来源的不同侧重。

难度维度的分析最为直观：所有模型在简单题上都能取得较高分数（大多数顶级模型在各语言的简单题上超过90%），在中等题上分数适中，而在困难题上成绩急剧下滑——很多模型的困难题通过率不足30%，甚至接近于零。这说明当前AI在解决高难度算法问题上仍然存在根本性的瓶颈，并非在所有题目上都接近人类水平。

时间趋势分析则揭示了另一个令人深思的规律：从2023年到2025年，所有模型在所有语言上的成绩都呈现出逐渐下滑的趋势，顶级模型从约80%的Pass@1跌落到约60%。这种趋势的成因可能是双重的：一方面，越晚发布的题目越可能在训练数据中找不到类似问题，污染效应减弱；另一方面，竞赛平台本身也在持续推出更难的题目以保持竞争性。两种因素叠加，共同造成了这个下滑趋势。

九、这项研究的意义与局限

Multi-LCB为AI编程能力评测领域提供了一个重要的新维度。在此之前，研究者和用户只能通过Python成绩来估算一个模型的综合编程能力，这个估算是粗糙且可能失真的。现在，有了跨12种语言的统一基准，可以更全面、更公平地比较不同模型的能力。

从应用角度看，这意味着未来选择AI编程助手时，应该根据你实际使用的编程语言来评估模型，而不是直接套用Python排行榜。如果你主要用Rust做系统开发，那么应该优先考虑在Rust上表现稳定的模型（如GPT-OSS-120B系列和DeepSeek-R1-0528），而不是Python冠军Qwen3-235B-A22B-Thinking-2507。

从AI研究角度看，这份成绩单为模型训练提供了明确的改进方向：现有的推理增强训练严重偏重Python，要构建真正的多语言编程AI，需要系统性地增加对非Python语言的训练覆盖，特别是在强化学习的奖励信号设计上，应该更均衡地体现各种语言的正确性。

然而，研究团队也坦诚地指出了这项工作的几个重要局限。首先，12种语言仍然不够全面，Swift、Haskell、R、Julia等重要语言并未被纳入。其次，所有题目来自竞赛平台，属于算法题，与真实软件工程中的API集成、代码调试、遗留代码维护等场景存在差距。再次，严格的标准输入输出格式可能让一些模型在语法不熟悉的情况下失分，这部分失分反映的是格式适应能力而非纯算法能力，两者难以完全分离。此外，评测只涵盖了开源模型，GPT-4、Claude、Gemini等闭源模型并未参与，这让成绩单不够完整。最后，尽管通过日期过滤来控制污染，训练数据中可能仍存在与题目模式相似的内容，彻底排除污染在技术上极为困难。

对于未来，研究团队计划扩展支持Swift、Haskell、R和Julia，纳入闭源模型进行评测，并将Multi-LCB的技术框架应用于LiveCodeBench Pro等其他需要格式转换的评测基准，推动整个领域的多语言评测基础设施建设。

说到底，Multi-LCB这项工作做的事情并不复杂，却极为重要：它用12倍的语言维度，照出了AI编程助手们那些藏在Python光环背后的真实面目。当一个AI模型在Python题目上拿到高分，我们自然会感到满意，但在真实的工程世界里，你不能只用Python解决所有问题，就像你不能只靠普通话走遍全球一样。知道哪些AI在多语言上表现均衡，哪些是名副其实的"Python单科冠军"，对于工程师选择合适工具有着切实的指导价值。这份来自GigaCode和亚德克斯团队的研究，让这个问题有了数据支撑的答案。有兴趣深入研究的读者，可以通过arXiv编号2606.20517查阅完整论文，或访问论文中提供的GitHub代码仓库（Multi-LCB/Multi-LCB）获取完整的评测代码和数据。

Q&A

Q1：Multi-LCB和LiveCodeBench有什么区别？

A：LiveCodeBench只测Python一种语言，是目前业界最权威的Python代码能力评测标准。Multi-LCB是在LiveCodeBench基础上构建的扩展版，将同样的题目集扩展到Python、C++、Java、Go、JavaScript、TypeScript、C#、Rust、Ruby、PHP、Kotlin和Scala共12种编程语言，让研究者能直接比较同一个模型在不同语言上的真实能力差异，而不是靠Python成绩来推算。

Q2：为什么顶级AI在Python上很厉害，换成Rust或Go就大幅下滑？

A：主要原因是训练数据严重倾斜。互联网上Python代码的数量远超其他语言，AI在训练时接触到的Python代码样本多得多，因此对Python的语法规则、常用模式和解题思路记忆得更深。相比之下，Rust和Go的代码资源少得多，加上这些语言本身的语法限制更严格（比如Rust的所有权机制），AI生成符合要求的代码更容易出错。

Q3：普通程序员怎么根据Multi-LCB的结果选择AI编程助手？

A：关键是对应自己主要使用的编程语言去看具体成绩，而非只看综合排名或Python分数。比如主要做Rust系统开发的程序员，应优先选择Rust单项成绩高的GPT-OSS-120B或DeepSeek-R1-0528，而不是Python总分最高的Qwen3-235B-Thinking系列，因为后者的Rust成绩只有47.7%，远低于前者的70%左右。Multi-LCB的详细成绩表按语言逐一列出了所有模型的表现，直接查表选择最适合自己使用场景的模型即可。