💬 NLP

Chinese Language Is Not More Efficient Than English in Vibe Coding: A Preliminary Study on Token Cost and Problem-Solving Rate

这项针对 SWE-bench Lite 基准的实证研究表明，中文提示在 LLM 编程任务中并未展现出预期的 Token 成本优势，且其任务解决成功率普遍低于英文，因此开发者不应仅为了节省成本或提升性能而切换至中文提示。

原作者： Simiao Ren (Tsang), Xingyu Shen (Tsang), Yuchen Zhou (Tsang), Dennis (Tsang), Ng, Ankit Raj

发布于 2026-04-17

📖 1 分钟阅读☕ 轻松阅读

原作者： Simiao Ren (Tsang), Xingyu Shen (Tsang), Yuchen Zhou (Tsang), Dennis (Tsang), Ng, Ankit Raj

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文就像是一场**“语言效率大揭秘”**，专门为了打破一个在程序员圈子里流传很广的“谣言”：

谣言： “用中文写提示词（Prompt）比用英文更省 Token（计费单位），能帮公司省下 40% 的 API 费用，所以‘氛围编程’（Vibe Coding）应该全转中文！”

作者们（来自 Scam.ai 的研究团队）决定不靠猜，而是像**“科学侦探”**一样，亲自下场做实验，看看这个说法到底是真是假。

以下是用大白话和生动的比喻为你解读的核心发现：

1. 核心结论：谣言 busted（被粉碎了）

简单说：用中文写代码提示词，并没有你想象中那么省钱，甚至可能更贵、效果更差。

这就好比你听说“用方言点菜比普通话点菜更便宜”，结果去饭店一试，发现不仅没便宜，老板还因为听不懂方言多收了你服务费，甚至因为沟通不畅，菜还做错了。

2. 实验是怎么做的？（侦探的办案过程）

任务： 他们找了一个叫 SWE-bench 的“考场”，里面有 50 道真实的软件修复题（比如：这个 Python 代码有个 Bug，请修好它）。
选手： 他们找了 3 个不同的 AI 模型（MiniMax、GPT、GLM），让它们分别用英文和中文去解题。
计分： 不仅看谁做对了（成功率），还看谁花的钱少（Token 消耗量）。

3. 三大惊人发现

发现一：中文并没有“天生省字”

比喻： 想象 Token 是**“快递包裹”**。

谣言逻辑： 中文一个字顶英文一个词，所以中文写的信更短，快递费更便宜。
现实情况： AI 的“打包员”（Tokenizer）并不懂中文的“字义”，它只懂怎么切分。
- 对于某些 AI（比如 GPT 系列），它的打包员是**“英语特供版”**。你给它一个中文“猫”，它可能得拆成 3 个碎片（3 个包裹）才能装下；而英文"cat"直接就是一个包裹。结果：中文反而更费包裹（Token）！
- 对于另一些 AI（比如 GLM），它的打包员是**“中文特供版”**，这时候中文确实能省点包裹。
- 结论： 省不省钱，全看 AI 的“打包员”是哪种，跟语言本身没关系。

发现二：成功率才是“隐形杀手”

比喻： 想象你在**“抓娃娃机”**前。

假设用中文抓，每次只花 1 块钱（Token 少），但成功率只有 20%。
假设用英文抓，每次花 1.1 块钱（Token 多一点点），但成功率有 40%。
算笔账： 为了抓到 1 个娃娃，用中文你可能要投币 5 次（5 块钱），用英文只要投币 2.5 次（2.75 块钱）。
结论： 虽然中文单次看起来便宜，但因为**“做不对”（成功率低），导致你需要反复重试，最后总花费反而更高**。论文发现，用中文提示词时，AI 修好 Bug 的概率普遍比英文低。

发现三：选对模型比选对语言重要一万倍

比喻： 这就像**“选赛车手”比“选赛车颜色”重要**。

不管你是开红色车（英文）还是蓝色车（中文），如果车手是个新手（模型能力差），你跑不过职业车手。
论文发现，不同 AI 模型之间的能力差距（30% 的成功率差距），远远大于语言带来的那点微小差异。
建议： 别纠结是用中文还是英文，换个更强的 AI 模型，省下的钱和效果提升才是实实在在的。

4. 为什么会有这个谣言？（三个误区）

作者指出，大家把三个概念搞混了：

信息密度（字面意思）： 中文确实字少意赅（比如“你好”vs"Hello"），但这只是**“字符”**层面的。
分词机制（实际打包）： AI 不是按“字”算的，是按“词块”算的。很多英文优化的 AI，把中文切碎，反而更费钱。
啰嗦程度（输出长度）： 有人觉得中文思考过程短，但代码生成需要精准，中文不一定短，而且如果因为语言不通导致代码写错，重试的成本才是大头。

5. 给开发者的“避坑指南”

如果你正在考虑为了省钱把提示词全改成中文，请听作者一句劝：

别为了省 Token 改语言： 这就像为了省几块钱油费，把车开进泥坑里，最后修车的钱更多。
关注模型选择： 选一个对中文支持好、能力强的模型（比如专门优化过中文的 GLM 或 MiniMax），比单纯改语言有用得多。
看总账： 真正的成本是 （单次 Token 成本 × 重试次数）。如果中文导致 AI 经常“翻车”，那总成本绝对不低。

一句话总结：
“中文提示词更省钱”是个美丽的误会。在 AI 编程的世界里，选对“大脑”（模型）比选对“嘴巴”（语言）重要得多。别为了省那点 Token，把代码修好的机会给弄丢了。

1. 研究背景与问题 (Problem)

社会传言：社交媒体和开发者论坛上流传一种说法，认为在大型语言模型（LLM）进行代码生成任务（即“氛围编程”，Vibe Coding）时，使用中文提示词（Prompts）比英文更高效。传言声称中文提示词能减少高达 40% 的 Token 消耗，从而显著降低 API 成本。
核心误区：该传言混淆了三个概念：
1. 信息密度：中文单字在语义上确实比英文单词更紧凑。
2. Tokenizer 分配：基于英文训练的 Tokenizer 可能会将中文字符切分成多个 Token，导致实际 Token 数增加。
3. 推理冗长度：不同语言下的思维链（Chain-of-Thought）输出长度差异。
研究动机：缺乏针对特定领域（如软件工程调试）的严谨实证研究。现有的研究多关注通用推理或机器翻译后的对比，未控制模型架构和 Token 限制等混淆因素。
核心问题：提示词语言的选择（英文 vs. 中文）是否显著影响 LLM 代码推理任务中的 Token 成本和问题解决率？哪种语言实际上更高效？

2. 方法论 (Methodology)

**基准测试 **(Benchmark)：
- 选用 SWE-bench Lite，这是一个包含真实世界软件工程项目（如 Django, matplotlib, scikit-learn 等）Bug 修复任务的基准。
- 样本选择：通过分层随机采样选取了 50 个实例。每个任务包含自然语言描述的 Bug 报告、相关代码库以及必须通过的测试用例。
- 任务目标：模型需理解 Bug、定位代码并生成能通过测试的补丁（Patch）。
实验设计：
- 两阶段评估：
  1. 补丁生成：使用 MiniSWEAgent 框架，分别用英文和中文提示词与模型交互（限制 1500 步迭代，2 小时预算）。
  2. 结果评估：将生成的补丁应用到原始代码库，运行测试套件以确定是否修复成功。
- 模型选择：选取了三种具有不同架构和 Tokenizer 策略的模型家族：
  1. MiniMax-2.7：中文开发模型，可能针对 CJK 字符有优化。
  2. GPT-5.4-mini：英文主导训练的模型（OpenAI），作为对比组。
  3. GLM-5：中文开发模型，具有显式的思维链（CoT）推理模式。
- 提示词处理：由具备领域专业知识的双语软件工程师将英文任务描述专业翻译为中文，保留技术术语和结构，确保语义等价。
指标追踪：
- 通过 OpenRouter API 记录详细的 Token 消耗（Prompt, Completion, Reasoning tokens）及成本。
- 定义**有效成本 **(Cost Efficiency)： $C_{eff} = \frac{\text{平均每次尝试的 Token 成本}}{\text{解决率}}$ 。该指标综合考虑了 Token 消耗和任务成功率（失败重试的成本）。

3. 主要贡献 (Key Contributions)

系统性对比：在相同的任务实例上，首次对三种不同 LLM 家族的英文与中文提示词进行了严格的 Token 消耗和解决率对比。
API 级 Token 分析：区分了 Prompt、Completion 和 Reasoning Token，并引入了“有效成本”概念，而非仅看单次尝试的 Token 数。
归因分析：证明了观察到的性能差异主要源于模型架构（Tokenizer 设计、训练数据分布、推理模式），而非语言本身的固有属性。

4. 关键结果 (Key Results)

A. 解决率 (Resolution Rates)

中文并未带来性能提升，反而普遍略低：
- MiniMax-2.7：英文 66.0% vs 中文 61.5%（差距 4.5%）。
- GPT-5.4-mini：英文 36.0% vs 中文 26.1%（差距 9.9%）。
- GLM-5：英文 64.6% vs 中文 55.1%（差距 9.5%）。
结论：在所有测试模型中，中文提示词的成功率均低于或等于英文。模型选择对性能的影响（约 30% 的差距）远大于语言选择的影响。

B. Token 成本分析 (Token Cost Analysis)

模型依赖性：中文是否更省 Token 完全取决于模型：
- MiniMax-2.7：中文消耗更多 Token（是英文的 1.28 倍）。
- GPT-5.4-mini：中文消耗略多（是英文的 1.09 倍）。
- GLM-5：中文消耗略少（是英文的 0.98 倍），这是唯一观察到中文 Token 更少的情况，但幅度极小。
**有效成本 **(Effective Cost)：
- 即使 GLM-5 在中文下 Token 略少，但由于其解决率下降了 9.5%，导致有效成本反而上升。
- 对于 MiniMax 和 GPT，中文不仅 Token 更多，且解决率更低，导致有效成本大幅增加。
- 核心发现：重试频率（由解决率决定）是放大成本的主导因素。单纯追求输入 Token 压缩而忽视成功率，会导致总成本增加。

C. Tokenizer 效率验证

通过在不同 Tokenizer（GLM, Qwen, Mistral, Llama, GPT）上测试，发现：
- 英文主导的 Tokenizer（如 GPT/Llama）：中文 Token 化效率低，每字符 Token 数更多（ZH/EN 比率 > 1.0）。
- 中文原生/优化的 Tokenizer（如 GLM）：中文 Token 化效率高，甚至优于英文（ZH/EN 比率 < 1.0）。
- 字符密度 vs. Token 效率：虽然中文在字符层面更密集，但这并不直接转化为 Token 层面的效率，后者完全由 Tokenizer 的词表设计决定。

5. 意义与结论 (Significance & Conclusion)

辟谣结论：社交媒体关于“中文提示词能节省 30-40% 成本”的说法是错误的。
主要发现：
1. 语言效应微弱且模型相关：中文在某些模型上 Token 更少，但在其他模型上更多；且普遍伴随着解决率的轻微下降。
2. 模型选择优于语言选择：模型本身的性能差异（约 30%）远超语言带来的任何微小影响。
3. 概念混淆：传言混淆了“字符信息密度”和"Tokenizer 压缩效率”。效率取决于 Tokenizer 的设计，而非语言本身的属性。
对开发者的建议：
- 不要为了省钱切换语言：切换到中文进行“氛围编程”不太可能带来预期的成本节省，反而可能因解决率下降导致总成本上升。
- 优先优化模型选择：成本效益优化的重点应放在选择性能更强、Tokenizer 与目标语言匹配的模型上，而不是切换提示词语言。
- 关注有效成本：在评估成本时，必须将任务成功率（重试成本）纳入考量，而不仅仅是单次调用的 Token 数。

总结：该研究通过严谨的实证数据打破了“中文提示词更高效”的迷思，指出在 LLM 代码生成任务中，模型架构和 Tokenizer 设计才是决定成本和性能的关键因素，语言选择并非成本优化的有效杠杆。