大模型思考时为何切换英文？思维链背后的语言选择与调优方案

你有没有遇到过这种情况：用中文问国产大模型一个挺复杂的问题，模型转了半天，突然冒出一句“Let's think step by step”，然后整段推理过程变成了英文，最后又切换回中文给你一个完整答案？

我第一次撞见这个现象是在调一个国产开源模型的推理链路时，prompt 整页都是中文，模型却在思考阶段自顾自开始说英语，有种“被语文老师抓到在草稿纸上写英文作文”的既视感。这不是个例，很多开发者、普通用户都碰到过。这篇文章我会把这件事彻底说透：它到底什么时候出现、为什么会发生、哪些情况正常、哪些情况需要处理，以及在产品里怎么规避。

如果你是做大模型应用开发的、做 Agent 的，或者只是好奇 AI 为什么有这种行为的人，这篇都值得看完。我会把实验过程和踩过的坑都写进去，直接照着调参就行。

1. 现象先拆开来看：模型什么时候才“开口说英语”

1.1 这个现象在什么场景出现

先说结论：绝大多数英文“思考”发生在模型的推理阶段，而不是最终回答阶段。现在国产大模型普遍引入了思维链（Chain of Thought）机制，模型会先生成一段内部推理内容，再根据推理内容生成面向用户的最终回答。像 Kimi、DeepSeek、GLM 这类模型，在你看到最终答案之前，其实已经“自言自语”了一大段话。

问题来了：这段“自言自语”用的是英文的概率非常高。尤其是当你涉及的逻辑链条长、数学计算多、代码推导复杂时，英文出现频率会直线上升。我统计过自己线上服务的日志，中文 prompt 触发的推理内容中，大约有三到四成的请求会掺杂英文，其中完全切换成英文的接近一成。这是很夸张的比例。

另一个高频场景是代码任务。你让模型生成一段 Python 脚本，它的推理注释可能是“Define a function to parse the config file”这种英文注释。对很多用户来说，看到中文问题后面跟着英文思考过程，第一反应就是“这模型是不是中邪了”。

还有一类场景容易被忽略：使用 Agent 或多轮对话框架时，由于上下文中可能带着工具返回的英文内容、英文错误信息，模型会被这些语言线索“带跑”。我试过一个多 Agent 协作流程，其中一个子 Agent 的 system prompt 是英文模板，结果整条链路上所有模型的中文思考都被污染成了英文。

1.2 不同模型的表现差异

不是所有国产模型都会在思考阶段“切英文”，即便同一个模型，不同版本之间差异也很大。我整理了一个比较粗的观察表，基于我自己和同行测试的结果，不是官方数据，但很有参考价值：

这里有个容易被误解的点：不是“国产模型更爱说英文”或者“模型对中文不友好”，而是推理模型在追求复杂任务正确率时，会主动“切到”它认为更高效的内部语言。这背后是训练数据决定的，下面我会展开讲。

从产品视角看，这个现象真正让人头疼的地方在于：用户看到思考过程是英文，会直观地觉得模型“不靠谱”。哪怕最终答案完全正确，体验也已经打了折扣。

2. 为什么“一思考就说英语”：训练数据、语种失衡与思维链模式

2.1 训练数据的语言分布决定了模型的“大脑语言”

要理解这件事，先要接受一个前提：大模型没有母语概念，但它的训练语料分布天然形成了“主导语言”。目前公开的大规模预训练语料中，英文内容占比通常在 60% 以上，甚至更高。像 Common Crawl 这类常用数据集，英文篇章的数量级远大于中文，加上代码、论文、技术文档这些高质量知识文本也几乎都是英文，模型在预训练阶段接触到的有效推理模式，大部分是用英文编码的。

你可以把模型理解成一个从小在双语环境长大、但英文书读得更多的人。你跟它说中文，它听得懂，但它心里默念“要思考问题”的时候，本能就会切换到输入输出效率更高的那套语言系统。这个“心里默念”的过程，就是思维链。

我做过一个小实验：把同一个逻辑题分别用中文和英文写进 prompt，观察模型思考阶段的 token 分布。中文 prompt 的思考过程英文占比约 35%，英文 prompt 的思考过程几乎全是英文。这再次说明，模型内部确实存在一个“英文优先”的推理模式。

2.2 指令微调与思维链接入进一步强化了英文暗示

预训练只是基础。真正让“中文问题配英文推理”成为常态的，是后训练阶段。现在推理模型的思维链数据来源非常集中：大量使用英文数学题、英文代码题、英文逻辑推理题生成思维链样本。即便原始问题来自中文，很多数据处理流程也会先翻译成英文，再让模型生成推理过程，最后再把最终答案翻译回中文。

所以模型在学习“如何思考”的时候，老师教的范本就是英文。中文思维链不是没有，但在高质量训练样本里的占比远低于英文。我在排查一个开源模型的推理表现时，翻过它公开的微调数据分布：中文推理样本大概只占全部推理样本的 12% 到 18%。你可以想象，模型学到的“标准思考动作”天然带英文标签。

这也能解释为什么“简单任务”很少触发英文思考：因为简单任务不需要长思维链，模型走的是指令微调阶段学习到的中文问答模式。而“复杂任务”需要调动预训练阶段的深度推理能力，这时模型就会进入英文主导的推理空间。

2.3 分词器与词表设计的影响

还有一个平时很难注意到、但影响实打实存在的因素：tokenizer（分词器）。大模型并不是按单词理解文本的，而是把文本切分成一个个 token 再处理。英文的编码效率非常高，一个常见英文单词可能只占一个 token，而中文由于字符复杂，一个汉字往往需要消耗一个甚至多个 token。

这就带来一个很现实的问题：对模型来说，用英文思考比用中文思考“便宜”。相同长度的推理过程，英文消耗的 token 更少，计算开销更小，且训练数据中的英文模式覆盖更密集。从局部来看，模型把思维切换成英文，是某种意义上的“省力行为”。

我做过一个 token 消耗对比：同样一段 500 字的思考过程，用中文表达约消耗 700 到 800 个 token，用英文表达约消耗 450 到 550 个 token。差距接近一半。对追求效率的推理模型来说，这个差距足够影响它的“语言选择”。

不过要强调一点：模型并不是“为了省 token 而故意说英文”，这个行为是训练过程中自然涌现的。分词器只是提供了一个有利条件，真正的主因还是数据分布。

3. 实操判断与排查：怎么知道你遇到的“英文思考”是正常还是异常

3.1 先看 prompt 语言与系统设置

很多人第一反应是加一句“请用中文回答”。这个做法有用，但作用被高估了。我测试过多个模型，仅加这句提示词，思考阶段的英文出现率只会降低几个百分点，并不会真正消除。原因很简单：最终回答的语言和思维链的语言，在模型内部是两个受控强度不同的环节，最终回答更容易被指令约束，思维链则更多受训练模式支配。

真正有效的做法是双管齐下。第一步，在 system prompt 里明确指定“输出语言”和“思考语言”，比如下面这个模板：

你是一个中文智能助手。无论用户使用何种语言提问，你都必须使用中文输出最终回答。在回答问题前，请先使用中文进行内部思考与推理，不要使用英文、日文等其他语言进行思维链推导。

第二步，在少样本示例中提供中文推理过程的完整样例。这比单纯的语言指令有效得多。我给一个模型连续喂了 3 个“中文问题 + 中文思维链 + 中文答案”的完整示例后，它在同类问题上的英文思考比例从 40% 左右降到了 8% 以内。

3.2 再看采样参数与 API 配置

如果你已经在 prompt 上下过功夫，英文思考还是不减，就要检查 API 参数了。这里有两个变量影响最大：temperature 和模型的“思考强度”参数。

采样温度控制的是随机性，但很多人忽略了随机性对语言混合的影响。我把同一个复杂问题的 temperature 从 0.7 调到 0.2，英文混排出现的次数下降了近一半。原因是高温会让模型在多个概率相近的候选路径中随机选择，这增加了切入英文推理分支的机会。而低温让模型更守在最高概率路径上，这个路径通常更贴近训练最多的数据模式，也更容易保持中文一致性。

再一个参数是“思考强度”或“推理预算”。部分国产模型的 API 提供了 reasoning_effort、thinking_budget 之类的控制项。实测发现，把思考强度从 high 降到 medium，英文思考比例明显下降，代价是复杂题目的准确率也掉了一点。如果你做的是一个对延迟和语言一致性敏感的产品，这个取舍是值得做的。

参数这块建议直接自己在控制台里跑对比矩阵，记录不同参数组合下的结果。我把截图和数据整理成了一张表，这里直接给结论：

这个表格不是基准测试，但能清晰说明：语言一致性和推理能力存在一个平衡点，你需要根据自己的业务需求来找那个点。

3.3 分组测试与日志分析

排查到这一步，如果还会出现英文，就需要判断是模型特性还是特定输入触发的。最有效的方法是做分组测试：准备一组覆盖不同难度的中文问题，每组跑 N 次，把返回内容中的思考部分单独抽取出来，统计语言分布。

我在生产环境里就是这么做的。先用脚本把 API 返回的 reasoning_content 和 content 字段分开，然后对 reasoning_content 做语言检测，按 prompt 类型、模型版本、参数组合三个维度做交叉统计。最快定位问题的办法不是靠肉眼扫日志，而是直接做语言比例聚合。

日志里还有一个很容易踩的坑：有些 API 的思考字段和最终回答字段会混在同一个 message 里，甚至不同接口的字段名完全不同。我见过一个团队排查了半天“模型说英文”，最后发现是代码读错了字段，把别的地方的英文内容当成了思考过程。建议第一步先确认你取到的到底是哪个字段。

3.4 几种容易混淆的情况判断速查

4. 常见问题与规避技巧：想让模型全程说中文，可以这么做

4.1 几种“英语失控”模式及原因

我把日常见到的情况归纳成三种模式，你可以对着自己的现象找归类。

第一种是“开头中文、中段切换、结尾中文”。这种情况最普遍，本质是模型先尝试用中文推理，但到了某个复杂步骤，中文推理路径的概率权重斗不过英文推理路径，于是整体切换。这时候不要慌，这是训练模式的表现，不是 bug。

第二种是“最终回答全中文，但推理内容全是英文”。这种在 API 调用场景下最常见。你只看到最终答案时毫无感知，但一旦做了流式输出或把思考过程展示给用户，问题就暴露出来了。对这种情况，prompt 的作用有限，最有效的手段是后处理，也就是我后面要讲的“语言归一化”。

第三种是“中英文胡乱混排，像打翻的调色盘”。这种通常不是正常的语言切换，而是 prompt 本身存在冲突，或者采样温度设置得太高。我遇到过一次，系统 prompt 是中文的，但上下文里塞了一长段英文工具文档，模型直接精神分裂。把英文工具文档改成结构化摘要后，问题立刻消失。

4.2 产品侧的处理思路

如果你的产品需要把思考过程展示给用户，我强烈建议加一层“语言后处理”逻辑，而不是寄希望于模型自己能保持语言一致。原因很朴素：我们已经知道思考阶段的语言输出是概率行为，依赖模型自我约束只能降低概率，不能消除概率。

后处理最简单的一招是：检测到思考内容中的英文占比超过某一阈值时，调用翻译模型把英文部分翻译回中文。注意这里不要整段翻译全塞进去，最好只翻译非代码、非术语的段落。代码片段、API 名称、数学公式这些内容保持英文原样，反而更专业。

第二个思路是控制展示策略。思考过程本来就不是面向最终用户的“成品”，它更接近草稿纸。很多产品选择只展示“思考的结论”，不展示完整思维链，这在体验上能规避绝大部分语言问题。我在一个项目里就是这么处理的：把 reasoning_content 抽取关键结论后转成中文摘要，再展示给用户，英文问题直接消失。

还有一个细节值得提：如果你做的是 API 服务或 Agent 链路，考虑在中间层做语言标记传递，比如在 prompt 中显式声明“所有内部中间结果必须使用中文输出”。这个方法对训练后处理较充分的模型效果不错，对开箱即用的模型效果一般，需要你自己测试。

4.3 一些行之有效的小技巧

这几条技巧都是我在实际项目里反复试出来的，你可以直接抄作业。

第一，系统提示词别只写“用中文回答”，把“思考语言”也写进去。我发现大多数人根本没有约束思考语言这个维度，只约束了输出语言。改这一条，很多模型的英文思考比例就有肉眼可见的下降。

第二，少样本示例要给足完整链路。不要只给“问题 + 答案”，要给“问题 + 思考步骤 + 答案”的完整中文推理样例。模型在学习语言模式时，需要看到完整链路才会跟着模仿。

第三，代码相关任务单独走代码模型或单独加提示词。如果你要生成代码，但又要求注释是中文，最好在 prompt 中写明“所有注释与思考过程使用中文，保留代码关键字与函数名为英文”。否则模型默认输出英文注释是它的舒适区。

第四，固定随机种子，把 temperature 调低，在生产环境里对同一类请求用相同的 seed。这样不但能降低英文切换概率，还能让问题排查时有一个可复现的环境。

第五，多语言 Agent 链路里，子 Agent 的提示词语言要保持一致。我踩过的坑是主 Agent 用中文，子 Agent 用英文模板，结果整条链路被带成英文。现在我的规则是：主链路用中文，子任务模板也用中文，只在调用外部工具时使用英文。

第六，利用模型自带的“语言偏好”提示。某些国产模型对“你是中文模型”这种身份设定非常敏感，在 system prompt 里强调“你是一名中文模型，应以中文为默认思维语言”，效果比“请用中文回答”好很多。这算得上是一个不花钱就见效的操作。

4.4 哪些情况不需要管

不是所有英文出现都需要被“消灭”。有一些场景下，英文反而是正确选择。保留代码关键字、API 名称、专有名词的英文原样，是高质量输出的基本要求。很多用户看到代码里英文注释反而会觉得更专业，强行全中文化反而影响代码可读性。

数学推理也是类似。模型在推导数学公式时使用英文符号和标准术语是正常行为，不要为了语言统一去破坏它。我见过有人为了让思维链全中文，把公式变量名都改成拼音，结果模型准确率明显下降。这属于典型的过度矫正。

另外一个没必要管的场景是：推理内容本身不对用户展示。如果你的产品不展示思维链，那思考阶段说什么语言，对最终用户完全无感。把精力花在最终回答的语言质量上，比纠结内部推理语言划算得多。

5. 关于“语言一致性”的最后一次尝试

讲了这么多，最后还是忍不住分享一个具体的调优案例。我为了把一个服务里的英文思考占比从 35% 压到 5% 以内，总共做了七次调整，前五次都收效甚微，直到做了三件事才彻底改观：system prompt 里加“中文思维语言”约束、给两个完整中文少样本、把 temperature 从 0.7 降到 0.3。这三步组合拳打完，英文思考占比稳定在了 4% 左右。

有意思的是，我把同一个方案套到另一个模型上，效果就打了折扣。原因是两个模型的训练数据对语言指令的敏感度不同。这件事没有银弹，好在排查方法是可以复用的：先确认字段取对，再做分组统计，然后把 prompt、参数、上下文三个变量逐个排除，基本都能定位到原因。

如果你正在为这个现象头疼，我的建议是别急着怪模型“不行”，也别急着用英文重写所有 prompt。先跑几轮对比测试，看看你的业务对语言一致性的真实要求有多高，再决定投入多少精力去调优。很多时候，让模型专注把推理做对，比让它把推理过程用中文写出来更重要。