Claude 突然用英文回复的原因与解决办法——三种类型与对症的对策

明明用中文提问，Claude 却用英文回答。而且一旦变成这样，就很难再变回来——。

这不是你的错觉。Claude Code 的官方仓库里反复出现同样的报告，研究也已经证实，在请求与回复跨语言的条件下，即便是最强的模型，也无法始终如一地用指定的语言回答。更重要的是，原因并不只有一个。按发生的方式可以分成三种类型，每种类型管用的对策也各不相同。

本文先帮你判断自己碰上的是哪一种，再按类型给出解决办法。最后，把 2026年9月开始出现报告的“长会话里输出本身出现崩坏”这个问题，按已经确认和尚未确认的部分分开梳理。

1. 先分清——变成英文的三种类型

“变成了英文”这个结果看起来一样，但按什么时候、在什么之后切换的，可以分成不同类型。请回想一下切换之前你正在做什么。

类型1和类型2几乎人人都会遇到，而且两者都能用同一个设置在很大程度上防住。类型3目前报告还很少，只有在中文、日语、韩语这样的东亚语言之间发生的例子，对策也还不明确。下面依次来看。

2. 研究早已证实的“语言混淆”

AI 用与指定不同的语言回答，这种现象在研究领域被称为“语言混淆（language confusion）”。在自然语言处理国际会议 EMNLP 2024 上发表的 Marchisio 等人的论文，构建了一套覆盖 15 种语言的评测集来测量这一现象，并对主流模型做了比较。

结论很明确，论文写道“即便是最强的模型，在跨语言的条件下也无法始终如一地用正确的语言回答”。这里的“跨语言”，指的是请求用英文写，却要求用另一种语言回答的条件。

数值为回复的每一行都是正确语言的比例（按行计算的通过率）。来源：Marchisio 等人《Understanding and Mitigating Language Confusion in LLMs》（EMNLP 2024）表3

不同语言之间的差距也很大，Llama 3 70B Instruct 在跨语言条件下，中文只有 4.3%，日语只有 1.4%，都格外低。论文还指出，以英文为中心做指令微调的模型更容易混淆语言，请求越复杂、温度设置越高，情况越糟。混淆分两种：一种是整行变成另一种语言，另一种是中文句子里只混进一个英文单词。开头图中那句 check 后面跟着一个日语短语的回复，正好介于两者之间。

在 Claude Code 里干活，往往就很接近这种“跨语言条件”。因为即使你用中文提出请求，它读的代码、命令的输出、报错信息大多是英文。工作推进得越多，上下文里英文所占的比例就越大。

3. 类型1：活干得越多，英文越是一点点渗进来

这是最常见的类型。报告 #32181（2026年3月，Claude Code 2.1.71，Opus）用三个阶段记录了这种转移过程，也就是开头那张图。报告者写道“代码越多的工作，越会按比例滑向英文”，并表示与压缩、计划模式都无关，只是正常干活就会发生。

还有一点很重要：Claude 自己并没有察觉到语言的切换。既然没有察觉，它也就不会主动切回原来的语言。

这份报告以“不计划处理”关闭。也就是说，这不是等修复就能解决的问题，需要使用者自己动手应对。

4. 类型2：一压缩完就退回英文

会话变长之后，Claude Code 会把之前的往来内容做成摘要，腾出上下文空间。这就是压缩（机制在《Claude Code 的 /compact 该定期手动执行吗》里有详细说明）。

报告 #59299（2026年5月，Claude Code 2.1.141）写道，一段用西班牙语进行的会话在压缩之后立刻退回了英文。报告者表示“从来没有正常工作过”，这份报告同样以“不计划处理”关闭。

为什么会这样，读一读官方文档的“压缩后留下什么”就明白了。

来源：摘自 Claude Code 官方文档《What survives compaction》中与语言指示相关的行

如果只是在对话中途说了一句“请用中文回答”，这句话就落在被摘要的那一侧。要是摘要里没有保留“之前一直在用中文交流”这一点，下一条回复就可能退回英文。

反过来，写进系统提示词的指示不受压缩影响。下面 §6 的设置之所以扛得住压缩，靠的就是这个机制。

5. 类型3：不是英文，而是变成了别的语言

这是一种有点特别的类型。在报告 #46846（2026年4月，Sonnet 4.6，VS Code 扩展）中，CLAUDE.md 里明明写着“始终用台湾的繁体中文回答，不要使用日语、韩语和简体中文”，Claude 却用日语和韩语作了回答。指定的正是中文，结果却偏到了邻近的语言——对用中文使用 Claude 的读者来说，这是格外值得留意的一种类型。

报告者写下的特征有三点。

• 发生在像 git、gh 这样返回英文输出的命令之后
• 即使在 CLAUDE.md 和自动记忆里都写上，换个会话还会再次发生
• 用日语道歉后说“我用正确的语言重写”，结果重写的内容也是日语

据报告，代码库里只有繁体中文和英文，哪里都没有日语或韩语的素材。看起来像是想要离开英文，却滑向了与指定语言相近的东亚语言，但这只是从报告内容能读出的推测，原因并未得到确认。

由此能说的是这样一个事实：只写在 CLAUDE.md 里的指示，有时并不会被遵守。CLAUDE.md 在压缩后也会被重新读取，可既然仍有语言崩掉的例子，与下面的设置搭配使用更稳妥。

6. 最管用的对策——language 设置

Claude Code 有一个固定回复语言的设置，叫 language。根据官方更新日志，它是在 2.1.0 中加入的。只要在设置文件里加一行即可。

{
  "language": "simplified chinese"
}

官方设置参考说明的机制有以下三点。

• 写下的值会原样进入系统提示词，成为“始终用该语言回复”的指示。所以正如 §4 所见，压缩之后依然有效。也正因为值会原样变成指示，想要简体中文的回复时，与其只写 chinese，不如像上面这样写得更具体，写成 simplified chinese——这是从官方描述的机制推出的做法，并不保证这样写就一定会用简体回答
• 语言名没有固定的列表，只要是 Claude 能读懂的语言名都可以。相应地，值不会被校验，拼错了也不会报错，而是带着错误原样交给 Claude
• 同一个值还会用于语音输入的语言，以及自动生成的会话名称的语言。语音输入那边有支持语言的列表

写在哪个文件里，决定了生效的范围。

来源：Claude Code 官方文档《Settings files and precedence》

不过，它并不是万能的。

• 界面上的元素仍是英文。根据报告 #77976（2026年7月，2.1.211），这个设置能切换成你的语言的，是 Claude 的回复和 Claude 向你提问时的措辞。请求允许执行工具的对话框和按钮仍然是英文
• 对类型3是否有效尚未确认。上面的 #46846 是在 CLAUDE.md 里指定语言的例子，使用 language 设置时是否还会变成别的语言，目前没有找到相关报告

如果搞不清设置写在哪里、谁的优先级更高，可以在 Claude Code 里打开 /config 查看当前的设置。

7. 聊天版 Claude 与 ChatGPT 的情况

在浏览器或应用里使用的聊天版 Claude，没有专门用来固定回复语言的设置。官方帮助在说明如何切换界面语言之后写道：“即使更改语言设置，Claude 也会用你使用的语言与你对话”。

ChatGPT 的设计也差不多。OpenAI 官方帮助介绍的语言设置，是检测浏览器或手机的语言，让界面显示语言与之一致，并没有写它能固定回复的语言。

不过，两者都有对所有对话生效的指示栏。Claude 是设置页面中面向整个账户的指示（官方帮助），ChatGPT 是 Custom instructions 功能（官方帮助）。在这里写上“请始终用简体中文回答”，就省去了每次都写的麻烦。不过它只是一条指示，并不是固定语言的机制，所以遇到下面这种场合，最好在请求里也写明。

聊天版里最容易变成英文的，是贴进一段英文让它总结或翻译的时候。这正是 §2 所说的“跨语言条件”，所以在请求的末尾写明“请用中文回答”最为可靠。

这些输入框在哪里、能写多少字以及怎样写才有效，请参阅ChatGPT、Claude 和 Gemini 自定义指令的文章。

8. 【2026年9月，尚未确认】长会话里输出本身出现崩坏

从这里开始，是官方尚未承认原因、仍在进行中的事情。下面用标签区分可信程度。

✅ 9月13日和14日，出现了两份相似的报告

报告 #94016（9月13日）发生在桌面版的 Code 标签页中，使用 Opus 5，是一段用日语往来 100 多轮的长会话。被缓存的输入约 88 万 token。回复进行到一半时对话格式崩坏，Claude 自己编造了虚构的“用户提问”和“自己的回答”，随后把设置好的输出风格的指示文本约 7,400 字打印到了屏幕上。这一切都发生在同一条回复里，并非来自外部的攻击。

报告 #94218（9月14日，Claude Code 2.1.270，VS Code 扩展）是一段使用 Opus 5、持续了 6 个多小时的会话。编造虚构的用户发言并顺着它继续对话、内部字符串出现在正文里、捏造没有执行过的工具结果——在这些崩坏之中，还记录了对一段全程用日语进行的对话，用英文作了回复。

截至本文撰写时，两者都没有官方回应，仍未解决。类似的崩坏以前也出现过，工具调用以文字形式输出的例子，在《Claude Code 的“court”+invoke 标签泄露》中有介绍。

🟡 共同点是“Opus 5、日语、极长的会话”

两份报告的共同点是Opus 5、日语，以及上下文极端地长。值得注意的是，9月3日的 Claude Code 2.1.260 中，拥有 100 万 token 上下文的 Opus 和 Fable，其自动压缩改为直到“接近上限”才会触发（更新日志中写明）。

结果就是，会话更容易在膨胀到接近 90 万 token 的状态下长时间持续。报告中的 88 万 token 也落在这个区间。不过，还没有人证实这一改动就是崩坏的原因。能说的仅限于时间点和上下文量有所重合。

作为参考，笔者也统计了手头的记录。9月12日至14日期间，笔者用日语向 Claude Code（Opus 5）提出请求，把返回的 60 字以上的回复，按当时的上下文量分组。

来源：笔者环境中的 Claude Code 会话记录（1 人，3 天）。统计对象全部是用日语提出的请求；在去掉代码后的字符中，日语占比不足 8% 的回复计为“英文”。不足 20 万 token 的一组样本太少，不能用来断定趋势

超过 20 万 token 左右之后，英文回复大约占到一成，但这只是一个人的环境、短短 3 天的数据。它只能算是反映与会话长度关系的材料之一，除此之外没有更多意义。

🔴 原因，以及 Anthropic 是否会修复

崩坏的原因、与 2.1.260 改动的关系、修复计划，都没有官方回应，目前不明。

现在能做的应对

• 不要把上下文一直拖到接近 100 万 token。按照官方文档，像 /autocompact 500k 这样传入 token 数，就能把自动压缩的触发位置提前。在告一段落的地方开一个新会话也是办法（查看上下文里装了什么，请参阅《Claude Code 的上下文到底被什么吃掉了》）
• 一旦回复里混进虚构的用户发言或陌生的内部字符串，就结束那个会话。#94218 记录了在崩坏的上下文上继续得越久、崩得越厉害的经过
• language 设置还是要加上。它对一点点变成英文的类型1有效。不过，能否防住输出格式本身崩坏的问题，目前不明

总结

• AI 用与指定不同的语言回答，是研究也已证实的普遍弱点，并非 Claude 独有的问题
• 本文提到的 Claude Code 报告中，有 2 份以“不计划处理”关闭，需要使用者自己预防
• 最管用的是 language 设置。它写进系统提示词，所以压缩之后依然保留
• 聊天版 Claude 和 ChatGPT 没有专门固定回复语言的设置，所以要写进对所有对话生效的指示栏，贴英文文章时也在请求里写明语言

FAQ

Q1. language 设置的值，该写“simplified chinese”还是“简体中文”？

根据官方参考文档，没有固定的列表，只要是 Claude 能读懂的语言名都可以，因为值会原样进入系统提示词。不过值不会被校验，拼错了也不会报错。语音输入的语言也使用同一个值，而那边有支持语言的列表，所以和官方示例一样用英文语言名，写成 "simplified chinese" 比较稳妥。

Q2. 已经设置了，还是有部分内容是英文。

有两种可能。一种是界面上的元素，工具的许可对话框和按钮不在这个设置的范围之内。另一种是 §8 所说的长会话中的崩坏，这可能是与设置无关的另一个问题。如果上下文已经超过几十万 token，请在新会话里再试一次。

Q3. 在 CLAUDE.md 里写“始终用简体中文回答”，和这个有什么不同？

两者在压缩之后都会继续生效，但进入的方式不同。language 设置进入系统提示词，而项目根目录的 CLAUDE.md 是在压缩之后从磁盘重新读取。正如 §5 所述，有报告称 CLAUDE.md 里的指示没有被遵守，所以把语言指定放在设置里更可靠。

Q4. 变成英文之后放着不管，会怎么样？

如果是类型1，放着越久，英文往往越占上风。#32181 的报告者写道，Claude 没有察觉到切换，也没有自己切回来。发现时就用一句话拉回来，或者事先用设置预防，这样最可靠。