纯文本对比：中文确实多一点#

先从最简单的开始——同样语义的句子，中英文各写一版，直接比 token 数。

1
test_cases = [
2
    {"zh": "你好，今天天气怎么样？",
3
     "en": "Hello, how is the weather today?"},
4
    {"zh": "请解释什么是机器学习中的过拟合现象...",
5
     "en": "Please explain what overfitting is in machine learning..."},
6
    # ... 更多测试用例
7
]
8

9
for case in test_cases:
10
    zh_tokens = client.messages.count_tokens(
11
        model="claude-opus-4-7",
12
        messages=[{"role": "user", "content": case["zh"]}],
13
    ).input_tokens
14
    en_tokens = client.messages.count_tokens(
15
        model="claude-opus-4-7",
16
        messages=[{"role": "user", "content": case["en"]}],
17
    ).input_tokens

跑了 5 组测试，涵盖简单问候、技术概念、代码需求、商务邮件、长篇技术文档。结果：

平均下来，中文比英文多消耗约 11% 的 token。

有个有意思的规律：文本越短，差距越大（短句 15-20%），文本越长，差距越小（段落级别只差 3%）。原因很直觉——汉字的信息密度高。11 个汉字表达的意思，英文要 32 个字符、7 个单词。虽然单个汉字占的 token 多，但汉字数量少，拉长了看基本扯平。

如果故事到这里就结束，结论应该是”中文大约贵 10-15%，看你在不在意”。

但 Claude Code 不是一个单轮文本生成器。

放进 agent 工具流：差距消失了#

Claude Code 是一个 agent。一次对话的 token 构成远不只是”你说了什么”。我模拟了一个典型的 bug 修复任务——先 ls 看项目结构，再 read_file 读代码，最后 bash 跑测试——中间夹杂着系统提示、工具定义、工具调用结果。

1
def build_conversation(user_msg: str) -> list:
2
    return [
3
        {"role": "user", "content": user_msg},
4
        # assistant 调用 bash ls
5
        {"role": "assistant", "content": [
6
            {"type": "text", "text": "Let me look at the project structure."},
7
            {"type": "tool_use", "id": "tool_1", "name": "bash",
8
             "input": {"command": "ls -R src/"}},
9
        ]},
10
        # 工具返回目录结构
11
        {"role": "user", "content": [
12
            {"type": "tool_result", "tool_use_id": "tool_1",
13
             "content": TOOL_RESULT_BASH_LS},  # 20行目录树
14
        ]},
15
        # ... 继续读文件、跑测试
16
    ]

然后同一个任务，user message 分别用中英文：

• 中文：“修一下 token.py 里的 bug，测试过不了”
• 英文：“Fix the bug in token.py, tests are failing”

结果：

用户消息本身中文比英文多 15-32%，但放到完整对话里，总成本差异只有 0.13% 到 1.03%。

为什么？

因为在我那个模拟的短对话里，系统提示 + 工具定义就占了 ~2000 tokens，是全部 ~3000 tokens 的 65%。用户那句话才 30-130 tokens，占比 1-4%。即使这 1-4% 里中文比英文贵了 30%，乘上去也就是总成本多了不到 1 个百分点。

但真实场景比这更极端#

上面那个模拟其实还低估了”用户消息无关紧要”这件事。

真实的 Claude Code 会话是 1M 上下文窗口。系统提示本身大约只占 3% 左右——远没有我那个短对话里 65% 那么夸张。但这不意味着用户消息的占比上升了，恰恰相反。

1M 的上下文窗口里，真正的 token 大户是：

• 累积的对话历史——几十轮对话，每轮都带着之前的上下文
• 工具调用结果——读一个 500 行的文件就是几千 token，跑一次测试输出又是几千
• 助手的回复——代码、解释、分析，全部累积在上下文里
• prompt caching 的前缀——系统提示和工具定义会被缓存，后续请求以 0.1x 的价格复用

你打了一句”帮我看看这个 bug”，30 个 token。然后 Claude Code 读了 3 个文件、跑了 2 次命令、改了 1 个文件、又跑了一次测试。这一轮下来，上下文里多了几万 token 的工具结果和代码内容。你那 30 个 token？不到 0.1%。

就算你用中文多花了 5 个 token，在几万 token 的海洋里，连波纹都看不到。

NOTE

Anthropic 对所有语言的 token 单价是一样的——$5/M input、$25/M output（Opus 4.7）。差异只来自 token 数量，不来自单价。

有一篇论文专门测过这事#

在写这篇的时候我搜到一篇 arXiv 论文（2604.14210），标题叫 “Mythbuster: Chinese Language Is Not More Efficient Than English in Vibe Coding”。

这篇论文的结论和我测到的裸文本数据一致：同样语义，中文的 token 数确实比英文多（论文里的数据是 2-3 倍，不同 tokenizer 差异很大）。但论文关注的是 vibe coding 场景下的端到端效率——考虑进任务完成率、代码质量、重试次数之后，语言选择对总成本的影响远小于直觉上的”中文 token 多 = 中文贵”。

另外一个有意思的数据：GIGAZINE 测了 Opus 4.7 相比 4.6 的 token 消耗变化，发现 4.7 对中日韩文字的 token 增长率反而比英文和代码低（中文 +0.5-7%，英文代码 +20-47%）。说明 Anthropic 在新版 tokenizer 里对 CJK 做了优化。

那到底该用什么语言？#

用你想的最快的那个。

如果你用中文思考问题，就用中文跟 Claude Code 说话。如果你切换到英文反而要多花 3 秒组织语言，那 3 秒的时间成本远比省下来的 0.1% token 贵。

这个结论在 1M 上下文窗口的 agent 工具流里尤其成立。你的消息只是整个上下文的一滴水。真正决定账单的是你让 agent 读了多少文件、跑了多少命令、迭代了多少轮——和你用什么语言说”帮我看看这个 bug”没有任何关系。

省钱的正确姿势不是切换语言，是写更精准的指令、减少不必要的迭代。一句精确的中文指令，比三句模糊的英文指令便宜得多。