大语言模型编程：中文提示词真的更省Token吗？

1. 项目概述与核心问题拆解

最近在开发者社区和社交媒体上，一个观点流传甚广：在利用大语言模型（LLM）进行“氛围编程”（Vibe Coding）时，使用中文提示词（Prompt）比英文更节省Token，据说能降低高达40%的API调用成本。这个说法听起来很有吸引力，毕竟对于需要频繁调用模型API的开发者来说，Token消耗直接关系到真金白银。作为一个长期混迹于AI工程化一线的人，我最初听到这个说法时也心头一动——如果简单切换一下提示词语言就能省下一大笔钱，何乐而不为？

但多年的经验告诉我，在AI领域，尤其是涉及模型底层行为时，许多“听起来很美”的传言往往经不起实证的推敲。这个关于中文效率的论断，其核心逻辑在于：汉字是表意文字，信息密度高，理论上能用更少的字符表达相同的内容，从而可能转化为更少的Token。然而，LLM处理文本并非基于字符，而是基于其分词器（Tokenizer）划分的Token。分词器的词汇表设计，尤其是其对中英文子词单元的分配策略，才是决定最终Token数量的关键。一个为英文语料优化的分词器，在处理中文时，可能会将一个汉字拆分成多个Token，反而导致效率降低。

因此，我们决定对这个流行观点进行一次“祛魅”。我们选择了SWE-bench Lite这个在业界公认能体现实战软件工程能力的基准测试集，它包含从Django、Matplotlib等真实开源项目中提取的Bug修复任务，要求模型理解问题描述、定位相关代码并生成能通过测试的补丁。这比简单的代码补全任务更能反映LLM在复杂、真实场景下的推理和生成能力。我们的研究问题很直接：在基于LLM的代码推理任务中，提示词语言（英文 vs. 中文）的选择，是否真的能显著影响Token消耗和任务解决率？如果会，哪种语言实际上更高效？

2. 实验设计与方法详述

为了得到可靠结论，我们的实验设计力求严谨和可复现。整个流程可以拆解为几个关键环节，每个环节的选择都经过了深思熟虑。

2.1 基准测试与任务选取

我们选用SWE-bench Lite的300个任务子集。这个基准测试的价值在于其“真实性”：任务来源于真实的GitHub Issue和Pull Request，解决它们需要模型具备代码理解、上下文关联和精确生成的能力，而非简单的模式匹配。由于进行大规模智能体（Agent）测试的Token成本极高（每个任务可能涉及上千次API调用），在计算资源的限制下，我们采用了分层随机抽样（种子设为42），最终选取了50个任务实例。这些实例覆盖了12个不同的代码仓库，其中Django占比较高，这反映了其在开源社区中的活跃度和问题的复杂性，也使得我们的样本更具代表性。

2.2 模型与分词器选择策略

模型的选择是本次实验的核心变量之一。我们并非追求模型数量，而是有意选择了在架构和分词器设计上具有代表性的三个模型家族，以观察不同设计哲学下的语言效应：

1. GPT-5.4-mini (通过OpenRouter访问)：代表以英文语料为主导进行训练的模型家族。其使用的cl100k_base分词器是典型的为英文优化的分词器，我们预期它对中文的处理效率可能较低。
2. MiniMax-2.7 (通过OpenRouter访问)：国内开发的模型，其分词器词汇表很可能包含了对CJK（中日韩）字符的专门优化。我们想验证，针对中文优化的模型是否在处理中文提示时展现出Token效率优势。
3. GLM-5 (通过OpenRouter访问)：另一个国内主流模型，同样预期对中文有良好支持。特别的是，GLM-5支持显式的思维链（Chain-of-Thought）推理模式，这允许我们观察推理过程本身的Token消耗是否受语言影响。

所有模型均通过OpenRouter API调用，确保了计费、Token统计和交互接口的一致性，避免了不同平台API差异带来的干扰。

2.3 提示词处理与实验流程

为了保证对比的公平性，英文任务描述由一位具备领域知识的双语软件工程师专业地翻译成中文，并严格保持了技术术语和问题描述结构的准确性。这样，两个语言版本的提示词在语义上是完全等价的，唯一的变量就是语言本身。

实验分为两个阶段：

1. 补丁生成阶段：使用MiniSWEAgent框架，让模型以智能体的方式与每个SWE-bench实例交互。我们为每个任务设置了1500步的迭代上限和2小时的超时限制，模拟一个有一定耐心的调试过程。
2. 评估阶段：使用官方的SWE-bench评估工具，将模型生成的补丁应用到原始代码库中，并运行测试套件。只有完全通过所有测试的补丁才被认定为“解决”。我们记录每个任务的最终状态（解决/未解决），以及从OpenRouter日志中获取的详细Token消耗数据（包括提示Token、补全Token和推理Token）。

注意：这里有一个关键的实验细节。由于中文提示可能更长（分词后Token更多），在迭代步数限制下，一些中文任务可能在达到步数上限前就因上下文长度耗尽而提前终止，生成空补丁或截断补丁。这些实例在计算解决率时会被排除。这在MiniMax-2.7的中文任务中尤为明显（50个英文任务全评估，39个中文任务可评估）。这可能会引入轻微的偏差，如果被排除的任务普遍更难，那么中文组的解决率可能被略微高估。在解读结果时需要考虑这一点。

3. 核心结果：效率神话的破灭

经过对三个模型在50个任务上的测试，我们得到了清晰且有些反直觉的数据。下面这个表格汇总了最核心的发现：

表1：各模型在英/中文提示下的性能与Token消耗对比

3.1 任务解决率：中文并未带来优势

首先看最重要的指标——解决率。这是衡量模型能否真正完成任务的根本。

• 性能差距主要在于模型，而非语言：表现最好的MiniMax-2.7（英文66.0%）和最差的GPT-5.4-mini（英文36.0%）之间，解决率差距高达30个百分点。相比之下，同一模型下中英文的解决率差异要小得多（4.5到9.9个百分点）。这强烈地表明，模型本身的能力是决定任务成功与否的首要因素，语言选择带来的影响是次要的。
• 中文提示的解决率普遍更低：一个明确的趋势是，在所有三个测试的模型中，中文提示的解决率都低于英文提示。虽然对于MiniMax-2.7，4.5个百分点的差异可能在统计误差范围内，但对于GPT-5.4-mini和GLM-5，近10个百分点的差距则更具指示性。这意味着，仅仅为了潜在的Token节省而切换到中文，可能会以牺牲任务成功率为代价。

3.2 Token消耗分析：模型依赖，结论不一

接下来看Token消耗，这是成本的核心。

• 神话的片面性：社交媒体的说法认为中文“更省Token”，我们的数据表明这并非普遍真理。Token效率高度依赖于模型的分词器设计。
  • MiniMax-2.7：中文提示消耗的Token比英文多出28%(ZH/EN比率1.28x)。这与“中文更高效”的说法完全相反。
  • GPT-5.4-mini：中文提示的Token消耗比英文多9%(1.09x)。
  • GLM-5：这是唯一一个中文Token消耗略低于英文的模型，比率为0.98x，即节省了约2%的Token。

这个结果直接驳斥了“中文天生更Token高效”的简单叙事。效率与否，不取决于语言本身，而取决于模型训练时分词器词汇表是如何分配的。为英文优化的分词器（如GPT系列使用的）在处理中文时，往往因为需要将汉字拆解为多个子词Token而处于劣势。

3.3 综合成本效率：引入“单次成功期望成本”

单独比较Token数量或解决率都是片面的。在实际部署中，我们关心的是成功完成一个任务需要花费多少成本。这就需要引入一个更合理的指标：期望单次成功成本。

其计算公式为：C_eff = (平均每次尝试的Token成本) / (解决率)

这个公式的精妙之处在于，它包含了失败尝试的成本。即使一种语言每次尝试消耗的Token略少，但如果它的成功率低，你需要多次重试才能成功一次，那么总成本反而会更高。

以GPT-5.4-mini为例：

• 中文提示的Token开销只比英文高9%（1.09x），但解决率却低了近10个百分点（从36.0%降至26.1%）。
• 代入公式计算，中文提示的期望单次成功成本会比英文高出不少，因为更低的成功率极大地放大了每次尝试的Token成本。

将这个逻辑应用到所有模型上，我们发现：在我们的测试中，没有任何一个模型-语言组合显示出中文在综合成本效率上的系统性优势。对于MiniMax-2.7，中文在Token消耗和解决率上都是劣势，成本更高。对于GLM-5，中文在Token上的微小节省（2%）被解决率上的较大下降（9.5个百分点）部分抵消。成本效率的优化，首要考虑因素应该是模型选择和任务本身，语言选择只是一个二阶因素，其效果（正或负）和大小完全取决于你使用的具体模型。

4. 深度剖析：Tokenizer是决定性因素

为了深入探究现象背后的原因，我们剥离了任务执行过程，单独测试了不同分词器对纯文本（即SWE-bench的任务描述本身）的编码效率。我们选取了5个有代表性的分词器，对23个任务的英/中文描述进行了Token计数分析。

表2：不同分词器下的中英文Token比率与字符效率

这个对照实验揭示了两个关键事实：

1. 分词器设计决定Token效率：GLM的分词器在训练时包含了大量中文数据，因此它对中文的压缩效率最高，中文Token数仅为英文的92.3%。相反，为英文优化的Llama/GPT的cl100k_base分词器，处理中文时需要多出15%的Token。Qwen和Mistral处于中间状态。这证明，是分词器的词汇表分配策略，而非汉语本身的属性，决定了哪种语言在Token层面更“高效”。

2. 字符密度与Token压缩的混淆：在所有分词器上，中文的“字符/Token”值（1.96-2.72）都低于英文（2.69-3.72）。这说明在字符层面，中文确实更“稠密”，每个字符承载的信息更多。然而，社交媒体上的流行观点错误地将这种“字符层面的信息密度”等同于“Token层面的压缩效率”。实际上，由于分词器会将中文汉字拆成更小的单元，其Token级别的压缩效率可能反而更低。我们的实验清晰地将这两个概念区分开来：前者是书写系统的特性，后者是模型工程的设计选择。

实操心得：如果你主要使用中文工作，选择像GLM、Qwen这类对CJK文本有优化分词器的模型，确实能在输入阶段获得更好的Token效率。但切记，这仅仅是输入文本的压缩效率，不包含模型推理和输出阶段的消耗，更不保证最终的任务成功率。

5. 对开发者的实践启示与避坑指南

基于以上研究，给正在或计划使用LLM进行编程辅助的开发者一些直接的建议：

1. 不要盲目为了“省Token”而切换中文提示：我们的数据显示，预期的40%成本节省并不存在，反而可能因为解决率下降而导致综合成本上升。除非你经过对自己特定工作流和所用模型的严格测试，证实中文确实更优，否则优先使用英文提示是更稳妥的选择，尤其是在使用国际主流模型时。

2. 模型选择远重于语言把戏：MiniMax-2.7和GPT-5.4-mini之间高达30个百分点的解决率差距，远超任何语言效应。在优化成本效率时，把你的首要精力放在选择和测试最适合你任务的模型上，这带来的收益比纠结提示词语言要大一个数量级。

3. 理解你的工具链：清楚你所用模型的分词器特性。如果你大量使用中文，可以考虑优先测试那些对中文有原生支持或优化分词器的模型（如GLM、DeepSeek、Qwen等系列）。但请记住，就像我们的实验所示，即使是对中文友好的模型，其中文提示的任务解决率也可能略低于英文。

4. 关注综合成本，而非单一指标：不要只盯着输入Token数。一个更全面的成本评估应该考虑“期望单次成功成本”，它同时包含了Token消耗和任务成功率。有时，一个每次尝试消耗更多Token但成功率更高的模型/语言组合，总体成本反而更低。

5. 小心上下文长度陷阱：如我们的实验所示，中文提示可能因为Token化后更长，更快地耗尽模型的上下文窗口，导致任务在达到迭代步数限制前就提前失败。在设置智能体或长对话任务时，需要为中文提示预留更多的上下文空间，或相应调整迭代策略。

6. 进行小规模验证：在将任何“最佳实践”大规模应用于生产环境前，务必针对你自己的典型任务进行小规模A/B测试。我们的结论基于SWE-bench的特定任务集，你的具体任务（如代码补全、文档生成、脚本编写）可能表现出不同的特性。用数据说话，而不是传言。

这项研究的意义在于，它用实证数据驱散了一个在社区中广泛传播但缺乏验证的技术迷思。在AI工程实践中，这种看似微小的选择背后，往往隐藏着复杂的系统交互。盲目跟随潮流不如深入理解自己工具的工作原理。最终，提升效率没有银弹，有的只是对技术细节的审慎考量和基于数据的持续优化。