为什么你的AI写代码，遇到非英语就变笨？
一个日本开发者的日常难题：AI也会踩的语言坑
你见过 AI 用英语写代码又快又准，算法题、接口调用、脚手架生成样样精通。但如果你是一个日本开发者，要把混着日文汉字、假名、表情符号和彩色转义码的日志塞进 40 列宽的终端，让 AI 来写对齐函数，它大概率会翻车。
坑在哪里？比如 Unicode 里的变体选择符不占显示宽度，但 Python 的 len() 会把它算进去；又比如 NFKC 归一化会把两个长得一模一样的”神”字合并，悄悄改了原文内容。这些都是日本开发者日常踩惯了的坑，但 AI 得自己意识到问题存在，不能等用户一条条说清楚 [1]。
再举个例子：捷克语排版里，单字母介词（k、s、v、z 等）绝对不能留在行尾，数字和单位、章节号和数字、头衔和姓名之间必须用非断空格。题目只给你几个示例，测试却考全套规则——专门抓那些”死记样本、不会推理”的解法 [1]。
这些问题有个共同点：它们的难度不来自通用编程复杂度，而来自语言、地区和文化的特性，在英语编程世界里根本没有直接对应物。你英语写得再溜，遇到土耳其语的”I/i”大小写转换、德语复合词的税率判断，一样抓瞎。这就是我们今天要聊的「多语言编码能力」——它不是”把题目翻译成英语”就能解决的问题。
测了10种语言300道题：最强模型也刚过及格线
为了系统测量这种能力，研究者构建了一个叫 Terminal-Bench-LILT 的多语言智能体编码基准 [1]。这个基准有点特别：它收录了 300 道真实编码题，覆盖阿拉伯语、捷克语、德语、西班牙语、印地语、日语、韩语、塞尔维亚语、土耳其语和中文共 10 种语言，每种语言 30 题 [1]。
题目怎么来的？全由母语程序员从自己真实遇到的问题出发撰写，先写母语指令再配英文翻译。关键是：locale 相关的要求隐含在题目里，不直接点明——比如不会告诉你”请考虑捷克语断行规则”，而是直接给你一段文本和期望输出，模拟真实用户提需求的场景 [1]。每道题还有确定性验证器，包含样本用例和未见用例防止过拟合 [1]。
测了 6 个前沿模型（GPT、Gemini、Claude 的多个版本），结果有点出乎意料：最强的模型总通过率也只有 63.1%，刚过及格线 [1]。很多题目没有任何模型能解出来 [1]。
更反直觉的发现还在后面：
第一，模型在不同语言上的表现差异很大。所有模型在印地语和德语上得分最低，大约只有 50%–53% [1]。这和我们通常以为的”语言使用人口越多模型越强”不完全对应。
第二，多语言编码能力和通用编码排名并不一致。也就是说，一个模型在通用编程基准上排第一，在多语言场景下未必还是第一 [1]。这说明多语言编码是一条独立的、被低估的能力轴。
第三，也是最有意思的一点：把题目从母语翻译成英语，对通过率的影响居然很小，最多不超过 7 个百分点，9 种配置中有 6 种小于 5 个百分点 [1]。真正难的不是看懂外语题目，而是处理外语数据和当地规则——比如土耳其语的大小写转换，你把题目翻译成英语再思考也没用，数据本身就是土耳其语的 [1]。
另外，开启推理模式对部分模型有显著提升，但对另一些模型效果不明显；而且德语和印地语的部分题目，即使开了推理，通过率仍然是 0% [1]。
当然，这个结论有它的边界：只覆盖了 10 种语言，限定在终端/命令行编码场景，文化类题目也只涉及普通成年人应知的常识 [1]。但它已经足够说明问题——我们的 AI 在英语世界里看起来很强，一旦走出英语舒适区，差距比想象中大得多。
「语言税」的真相：是天生复杂，还是人为偏见？
为什么非英语场景下模型表现差？一个常被提到的原因是「分词税」（tokenization tax）：同样的内容，非英语语言会被切成更多的 token。因为注意力机制的计算量和序列长度的平方成正比，token 多就意味着更贵、更慢、还可能更不准。
但这个”税”到底有多少是语言本身的信息差异导致的，又有多少是分词器设计的人为产物？另一篇论文给了我们一本清晰的成本账本 [2]。
研究者把分词层看作信源编码，用信息论里的香农下限（每单位内容最少需要多少 token）作为基准，把观测到的超额 token 拆成了三部分：可移除的编码冗余、残差编码松弛（训练不足导致）、内在内容差异 [2]。
结果非常有说服力：
用主流的生产级分词器，印度语言的 token 数是英语的 4.8–8.9 倍；换算成注意力计算成本，卡纳达语最高可达英语的 79 倍 [2]。但这大部分不是因为语言本身信息多。
怎么证明？研究者只用了 1012 句泰卢固语，训练了一个专门匹配该文字系统的 BPE 分词器，就把 8 倍多的 token 税降到了不到 3 倍，消掉了中位数 64% 的额外成本 [2]。要知道，这还只是用了 1000 多句话训练的小词汇表分词器，是一个非常保守的下限 [2]。
那语言本身的信息差异到底有多大？用公平的 LZMA 压缩算法测（避免 UTF-8 字节数的偏见），印度语言的内在内容只比英语多 2%–6% [2]。打个比方：同样大小的箱子，英语装的东西和印度语几乎一样多，只是英语的箱子标签贴得少，印度语的箱子被贴了一堆冗余标签。
当然，实际情况比这个比喻更复杂。论文也明确说了，他们只衡量了计算和内存成本，没有说 token 减少了模型质量就一定会提升 [2]。一个合理的猜测是，匹配码的词汇表远小于生产分词器，词汇表增大带来的计算开销也会抵消一部分收益。但核心结论很清楚：我们以为的”语言天生复杂”，大部分其实是英语主导的分词器带来的人为偏见。
从英语单语到全球开发者：编码评测的进化之路
Terminal-Bench-LILT 不是第一个关注多语言编码的基准，但它把这件事推到了一个新的深度。要理解它的位置，我们得看看编码评测这些年是怎么进化的。
最早的编码基准主要是单题算法题，比如 LeetCode 风格的题目，测的是”能不能写出正确的函数”。后来大家发现，真实软件开发不是做算法题，而是要处理多文件、有依赖关系的项目。于是出现了 HackerRank-ASTRA 这样的基准，用多文件项目问题来评测，还引入了 32 次运行的一致性评估——毕竟真实开发里，代码不能时灵时不灵 [6]。
再后来，人们开始意识到语言的问题。比如 IndicEval-XL 基准专门针对 6 种印度语言，覆盖 12 种编程语言，填补了印度次大陆的评测空白——要知道印度语言的使用者加起来占全球人口的约 14% [7]。还有研究关注多语言代码注释，发现 LLM 生成的注释在不同语言间差异很大，而且现有的自动评估指标根本靠不住，没法可靠区分正确和错误的注释 [8]。
而 Terminal-Bench-LILT 又往前走了一步：它不只是把英语题目翻译成别的语言，而是从母语开发者的真实问题出发，专门找那些英语世界里不存在的问题 [1]。它测的也不是”用中文描述的算法题能不能做对”，而是”遇到日语终端对齐、捷克语断行规则这种母语开发者天天碰的坑，模型能不能自己识别并解决” [1]。
从单题到项目，从英语到多语言，从”翻译题目”到”原生问题”——编码评测的进化，本质上是在不断逼近真实世界里全球开发者的真实需求。
差距之外：我们离真正的多语言编程智能体还有多远？
看到这里你可能会问：差距这么大，到底该怎么补？
先说清楚我们现在知道什么、不知道什么。
从评测端看，Terminal-Bench-LILT 只是一个起点。它只覆盖了 10 种语言，而且主要是终端场景，不含 GUI、大型仓库协作等更复杂的场景 [1]。作者自己也承认，低分只代表测量缺口，不代表对某语言或其使用者的评判 [1]。全球有几千种语言，我们现在测的只是冰山一角。
从技术端看，分词层面的”语言税”大部分是可消除的——只要给不同文字系统设计更合理的分词器，就能消掉三分之二的额外成本 [2]。但这只是成本问题，不是能力问题。token 少了不代表模型就一定能理解土耳其语的大小写规则、捷克语的断行习惯。
真正的难点在于语言、文化和地区相关的知识与推理能力。Terminal-Bench-LILT 里的题目，很多不是不会写代码，而是根本没意识到有这个坑——比如 NFKC 归一化会改原文、单字母介词不能在行尾 [1]。这些知识散落在各个语言社区的日常实践里，英语主导的训练数据里本来就少，模型自然学不到。
那可能的方向有哪些？
一个方向是更好的工具调用和检索。很多 locale 相关的知识是可以查的，比如 Unicode 标准、各国排版规范。如果智能体能主动搜索相关知识，而不是全靠参数里记的那点东西，表现应该会好很多。Terminal-Bench-LILT 的作者也提到，专业知识可以通过检索补全 [1]——不过目前的实验还没测带网页搜索的智能体。
另一个方向是更均衡的训练数据和分词设计。既然分词税大部分是人为的，那从分词器入手优化就是性价比很高的一步 [2]。训练数据里也需要更多非英语的真实编程场景，而不只是把英语文档翻译过去。
还有一个更深层的问题：我们到底需要什么样的多语言编程智能体？ 是一个懂所有语言规则的”全能选手”，还是一个能快速适应当地语言和文化的”学习型选手”？是让模型参数里装下全世界的 locale 知识，还是让它学会查文档、问用户、主动确认？
这些问题现在还没有答案。但有一点是确定的：当我们谈论”AI 写代码的能力”时，不能只看英语世界的表现。全球有数十亿非英语开发者，他们遇到的问题，才是 AI 真正走向普适的试金石。
如果你只记住一件事
多语言编码是一条独立于通用编码的能力轴，目前模型在这上面的差距，很大程度源于评测和训练长期以英语为中心——分词税约三分之二是人为冗余，而我们才刚刚开始认真测量这条能力轴。
参考文献
- Terminal-Bench-LILT: Multilingual Agentic Coding Benchmark Grounded in Language, Region, and Culture（arXiv、2026、全文精读）
- Removable and Irreducible: A Token-Cost Ledger for the Multilingual Tokenization Tax（arXiv、2026、全文精读）
- Triggering Chain-of-Thought via Latent Feature Interventions in Large Language Models（arXiv、2026、全文精读）
- ExpertIVS: Sociological Expert Driven Individual Value Simulation in Large Language Models（arXiv、2026、全文精读）
- World models of environment, agent and joint agent-environment systems（arXiv、2026、全文精读）
- HackerRank-ASTRA: Evaluating Correctness & Consistency of Large Language Models on cross-domain multi-file project problems（ArXiv.org、2025、仅摘要）
- IndicEval-XL: Bridging Linguistic Diversity in Code Generation Across Indic Languages（ArXiv.org、2025、仅摘要）
- A Qualitative Investigation into LLM-Generated Multilingual Code Comments and Automatic Evaluation Metrics（2025、仅摘要）