截至 2026-07-09T06:32:58Z UTC，中文编码提示里真正值得纳入 AI-China 观察的信号，并非中文字符天生比英文词便宜这一类传播性说法。更有操作价值的信号是：提示语言已经成为 coding agent 的评测变量；只有在它能降低每个成功任务的预期成本时，这个变量才有实际意义。[1]
这个区分很小，却改变了整条论证。一个中文提示在人类读者眼里很紧凑，经过 tokenizer 碎片化、多轮工具调用、reasoning 输出、失败补丁与重试之后，成本仍会升高。英文提示即便显得冗长，只要模型理解可靠性较高，总成本也会更低。对于 coding agent，账单落在整轮循环上：读取 issue、检索仓库、检查文件、编辑代码、运行测试、从失败中恢复，然后再次尝试。
2026 年 4 月论文 "Chinese Language Is Not More Efficient Than English in Vibe Coding" 的价值，在于它把讨论从字符数直觉推进到可运行的基准测试边界内。[1] 它给出的结果范围更窄，也更有用：在测试设置中，中文提示没有带来系统性的成本效率收益，模型选择对结果的影响超过提示语言。
评测边界
论文测试了采用分层随机抽样选出的 50 SWE-bench Lite instances，英文 issue 描述由一名双语软件工程师专业翻译成中文。任务设置属于软件修复，区别于泛化聊天：每个模型都要处理仓库问题，并产出可由官方 SWE-bench harness 评估的补丁。[1][2]
agent 边界很重要。实验使用 MiniSWEAgent，这是一个有意保持简洁的 coding-agent 脚手架；每次运行设有 1,500-step limit 和 2-hour time budget。模型调用走 OpenRouter，覆盖三组模型家族：MiniMax-2.7、GPT-5.4-mini 和 GLM-5。token 用量来自 API 日志；在可得情况下，记录拆分为 prompt、completion 与 reasoning token。[1][3]
这些细节把有用的基准札记和提示轶事分开。单独一个中文 issue 陈述只覆盖入口部分。完整工作负载是整次 agent run，可衡量的输出落在 evaluator 下解决任务的补丁上，漂亮回答不在评估目标内。SWE-bench 在这里仍是相关底座，原因正在于它要求模型解决来自真实仓库的软件 issue，而不止产出看起来合理的代码片段。[2]
数字真正说明了什么
最醒目的结果是，"Chinese is cheaper" 这条说法没有撑过测试循环。对 MiniMax-2.7 而言，中文提示消耗的 prompt token 是英文提示的 1.28x。对 GPT-5.4-mini 而言，中文为 1.09x。对 GLM-5 而言，中文 prompt token 略低，为英文水平的 0.98x。[1]
这个跨度给出第一条教训。中国开发的模型不能被视为同一类。在这项实验里，MiniMax 与 GLM 在 prompt-token 成本上走向相反，这说明 tokenizer 词表、训练混合比例和 reasoning mode 对成本的影响超过语言标签。采购者无法仅凭“中文模型”或“中文提示”推断 token 账单会下降。
第二条教训分量更重：在三组被测模型家族中，中文提示的成功率都低于英文提示。论文报告中，MiniMax-2.7 的英文解决率为 66.0%，中文为 61.5%；GPT-5.4-mini 为 36.0% 对 26.1%；GLM-5 为 64.6% 对 55.1%。[1] 作者对有限样本规模保持谨慎，并说明部分条件下可评估的中文实例数量会因 API 错误、补丁截断或空补丁而变化。[1] 但这个方向已经足以约束那条说法。
因此，合适的经济单位应从每个提示的输入 token 转向每个已解决 issue 的成本。如果中文省下少量 token，却降低了产出通过补丁的概率，重试倍数会抹掉表面节省。如果中文增加 prompt token，同时降低解决率，这笔交易会在两端受损。论文的主要贡献在于把失败尝试计入成本，指标内部也要容纳这些小麻烦。[1]
为什么字符密度会误导判断
流行捷径混淆了三层。中文在字符层面可以具有较高语义密度。tokenizer 对中文的压缩效率因模型而异。模型在不同提示语言下也会以不同方式推理、调用工具和写代码。这三层不会合并成一条简单规则。
这也是该结果对 AI-China 报道有意义的原因。中国 AI 厂商常常宣传广泛语言支持、长上下文能力、低 token 价格和 coding-agent 强项。这些主张在限定条件下可以成立，但部署问题仍要单独回答：系统能否以更低总成本解决更多中文软件工作？一张 model card 若只给英语编码榜单、中文 MMLU-style 得分和价格表，回答不了这个问题。
这个基准还指向一条本地产品经验。中文 agent 工作包含翻译，也包含翻译之外的混合工作表面。中文开发者会用中文写 bug report，但仓库、stack traces、package names、comments、linked issues、test output 和 API docs 很多时候主要是英文。这样的混合环境更接近真实工作。它要求模型在语言边界之间保留技术意图，同时避免过度检索、误译 identifiers 或丢失 acceptance criteria。
更广的多语言 agent 图景
Ren 等人的结果符合多语言 agent 评测中的更广模式。MAPS benchmark 把 agentic tasks 扩展到十一种语言，包括中文，并报告了性能和安全行为随任务类型、输入组合而下降的情况。[4] MAPS 关注的核心并非 coding-prompt 成本，但它支持同一个操作性观点：非英语输入会超出英语输入的外观变体范围，并会改变 agent 可靠性。
还有另一条部分竞争的思路：先在本地用预处理器把用户指令翻译或重写成更便宜、结构更清晰的英文提示，再交给云端 agent 运行。Cross-Lingual Token Arbitrage 提出的就是这类边缘侧 middleware：用本地模型把非英语或 code-switched prompts 改写成紧凑的结构化英文，并加上 fallback guards。[5] 它的设置不同于 Ren 等人的 SWE-bench Lite 测试，直接头对头比较会错置问题。两篇论文放在一起，设计空间就清楚了。
一条路线要求前沿 coding agent 在用户工作语言中真正可靠。另一条路线是在本地保留用户意图，再把云端 agent 路由到它处理起来成本最低的语言和结构。相比“Chinese characters are dense, therefore Chinese prompts save money”这样的说法，二者都把问题放回 agent 系统和成本评测。
后续观察点
第一项观察是更大规模复现。4 月论文明确说明其证据仍属初步：50 个 SWE-bench Lite 实例、三组模型家族和一个 agent 脚手架，还不足以永久裁定中文 coding-agent 经济性。[1] 更强的后续研究应覆盖更多仓库、更多 harness、多种中文提示风格、原生中文 issue 陈述而不只是翻译文本，以及带置信区间的重复运行。
第二项观察是模型级报告。如果 MiniMax、GLM、Qwen、DeepSeek、Kimi、ERNIE 和其他与中国相关的模型家族要声称已为中文用户准备好 coding-agent 能力，有用表格除了 leaderboard score，还应列出指定 harness 下的逐语言解决率、prompt token、reasoning token、wall-clock time、retry count，以及每个通过补丁的预期成本。
第三项观察是混合语言评测。真实中文软件团队常常在混合表面工作：中文产品需求、英文库文档、英文 stack traces、中文内部注释，以及绝不能翻译的代码 identifiers。只翻译可见 issue 陈述的基准测试可以作为起点；完整部署环境还包括更多语言交叉面。
反证条件很直接。如果更大规模、独立复现的测试显示，中文提示在中国开发的 coding models 和现实混合语言仓库中，能以更低预期成本带来相同或更高解决率，那么当前审慎解读就会削弱。在那之前，中文提示套利应被视为基准测试问题，不能当成捷径。agent 必须通过测试。
Sources
- Simiao Ren, Xingyu Shen, Yuchen Zhou, Dennis Ng, and Ankit Raj, "Chinese Language Is Not More Efficient Than English in Vibe Coding: A Preliminary Study on Token Cost and Problem-Solving Rate," arXiv:2604.14210（2026 年 4 月 6 日提交；SWE-bench Lite 设置、MiniMax/GPT/GLM 结果、token 统计和局限）。
- SWE-bench，官方 GitHub repository（真实 GitHub issue-resolution tasks 的 benchmark framework，以及 evaluation harness 语境）。
- SWE-agent，
mini-swe-agentGitHub repository（与实验 agent 边界和 SWE-bench-style repair loop 相关的最小 coding-agent scaffold）。 - Omer Hofman et al., "MAPS: A Multilingual Benchmark for Agent Performance and Security," arXiv:2505.15935（覆盖 GAIA、SWE-Bench、MATH 和安全任务的多语言 agent benchmark，包含中文变体）。
- Mehmet Utku Colak, "Cross-Lingual Token Arbitrage: Optimizing Code Agent Context Windows via Local LLM Preprocessing," arXiv:2606.03618（面向非英语/code-switched coding-agent prompts 的边缘侧翻译与结构化 prompt rewriting proposal）。
- Wikimedia Commons, "File:Keyboard with fingers.jpg"（本文封面所用双手在中文/CJK 标识键盘上打字真实照片的来源页面）。