Claude Code 突然改说日语韩语：语言漂移的原因与解决思路

用 Claude Code 写代码，前一句还在用中文讨论需求，下一句突然变成日语，再追问一句又跳成韩语；明明当前在 a 目录里工作，它却一本正经地分析 b 目录的文件。这类「不听话」的表现看似是两个问题，实际上指向同一个机制：模型的注意力在长会话里被稀释，你给的约束没有稳定地出现在每一次请求里。

社区里对这个现象的描述相当一致：一直用中文对话，某次突然回一段看不懂的韩语或日语，加上「请用中文与我交流」之后，下一条变成另一种外语；有人换成英文提问也一样随机。也有用户表示从没遇到过，或者只在某个特定模型版本上遇到。下面按「现象—原因—做法」梳理一遍。

问题具体长什么样

• 语言漂移：中文对话中随机切到日语、韩语、英文，偶尔出现繁体中文。切换后即使明确要求改回中文，也可能只是从一个外语换成另一个外语。
• 路径/上下文错乱：在某个目录下提问，回答却围绕另一个目录的文件展开，说明它读到的上下文和你以为的不一致。
• 症状随会话变长而加重，新开的会话往往一开始是正常的。
• 同类工具表现不同：有用户反馈另一款命令行编码工具几乎不出现外语回复，而 Claude Code 会；也有人反过来，说两边都遇到过。

几种可能的原因，以及它们各自的证据

出口 IP 决定语言？证据不强

最直觉的解释是「按 IP 判断地区，再决定用什么语言」。但这条说法在讨论里被直接反驳过：有人用的是美国机房出口，依然在中日韩英之间随机切换；也有人在同样的网络环境下从未复现。比较稳妥的结论是：IP 可能作为弱信号影响语言先验，但不是决定性因素，不要为了这个专门去折腾网络出口，尤其是通过非常规手段更改地区本身就有账号风险和合规风险。

模型版本差异，是出现频率最高的线索

多条反馈集中在同一个方向上：某个较早的版本基本稳定输出中文，切换到较新的版本后开始偶尔冒英文或日语；也有用户说新版本用下来一次都没出现。这类版本号会随时间变化，具体哪个版本更稳，只能以你自己当前的实测为准，不必把他人的结论当成定论。可以确定的是，不同模型对系统指令的遵循程度确实不同，这是需要纳入排查的变量。

上下文压缩把语言指令「洗掉」了

这条解释最有说服力，也最能指导操作。长会话触发的上下文压缩会摘要历史内容，CLAUDE.md 里的规则、你前面说过的「请用中文」都可能被压缩掉或降权，于是模型回退到默认的语言先验。这也解释了为什么「新开会话正常、聊久了才出问题」，以及为什么反复提醒只能管一两轮。

CJK 语料的先验让「随机」偏向东亚语言

模型训练语料里中日韩文本高度混杂，当中文指令的权重下降时，它并不是等概率地挑语言，而是容易落到同一书写体系内的其他语言上——所以看到的多是日语、韩语，偶尔繁体中文。这也解释了为什么「要求说中文」有时反而触发另一种 CJK 语言：它抓住的是「用 CJK 回复」这个更粗的特征。

少数情况要留意幻觉

有用户提到模型会凭空描述一段并不存在的提示词注入攻击并宣称已拦截，复查输入侧并无异常。这类内容大概率是生成出来的，不必当成真实安全事件；但如果确实涉及密钥、生产环境操作，仍应以日志和实际输入为准核对，不要只信模型的叙述。

把语言固定下来的具体做法

1. 写进每次都会加载的文件

项目级 ./CLAUDE.md 和用户级 ~/.claude/CLAUDE.md 都会随会话加载。把语言要求放在文件最顶部，用短句、祈使句，别写成一段散文：

# 全局约定
- 所有回复一律使用简体中文，包括解释、计划、提交信息说明。
- 代码、命令、日志、错误信息保持原文，不要翻译。
- 若上下文被压缩后仍继续本会话，重新确认本约定。

用户级文件里放一份，可以覆盖所有项目；项目级再放一份，防止换机器后丢失。

2. 首条消息固定声明，长会话定期重述

给自己准备一段固定开头，每次新会话粘一次，比中途补救有效：

接下来全程用简体中文回复。代码和命令保持原样。
当前工作目录是 <绝对路径>，只讨论该目录下的文件。

配合「只讨论该目录」这类明确约束，顺带缓解答错目录的问题。会话超过一定长度后主动重述一次，或者干脆开新会话。

3. 确认配置里的语言项是否真的生效

讨论里提到在配置中加入类似 "language": "Simplified Chinese" 的字段，理由是它会被注入系统提示词、每次请求都携带。这个思路是对的——把约束放进系统层比放在对话层更稳。但字段名、位置、是否被当前版本识别，各版本可能不同，请以官方文档为准，并且一定要自己验证：设置后开一个全新会话，观察若干轮是否仍会漂移。斜杠命令同理，先在帮助里确认当前版本是否提供语言相关命令，再决定是否依赖它。

4. 控制会话长度，压缩之后重新声明

• 一个任务一个会话，做完就清空，不要用一个会话跑一整天。
• 察觉语气或语言开始异常，往往意味着上下文已经很长，此时重置比纠正更省事。
• 重置后第一句就把语言规则和工作目录补回去。

5. 做个小对照实验，别凭感觉

同一段指令、同一个仓库，分别在新会话、长会话、不同模型下各跑几轮，记录出现外语回复的次数。只有把变量分开，才能判断到底是模型版本、会话长度还是你的网络环境在起作用。

回答慢、连接中断也值得一并排查

有反馈提到响应时快时慢。如果慢或卡顿集中在特定时段，且伴随会话中途断开重连，那就不是模型的问题，而是本地网络到服务端这条链路不稳定。反复重连会打断会话，也让「重述语言规则」这类补救失去意义。

如果工作流需要长时间挂着 AI 编码任务在跑，本地机器休眠、代理波动都会影响连续性。一种可选做法是把这类长跑会话放到网络出口稳定、长期在线的远程 macOS 环境里执行，本地只负责连接和查看结果，能减少「聊到一半断线重来」带来的上下文丢失。这不是必选项，本地环境稳定的话完全没必要换。

几点提醒

• 别跟模型较劲。生气、重复质问都只是多消耗 token，不会让它更守规矩；把规则写进系统层比提高音量有用。
• 口头承诺不等于执行。模型「承认错误」只是生成了一段符合你预期的文本，下一次是否遵守取决于请求里实际带了什么。
• 涉及安全或不可逆操作时，语言和目录的漂移会放大风险。让它在执行前复述「要改哪个文件、执行哪条命令」，人工确认后再放行。
• 版本与命令细节变化快，配置字段、斜杠命令、默认模型都可能调整，以官方最新说明和你自己的实测为准。

小结

语言漂移本质上是「约束在长会话中失权」的表现：模型版本影响它有多听话，上下文压缩决定你的规则还在不在，CJK 语料先验决定它跑偏时偏向哪种语言。出口 IP 大概率只是次要变量，不值得为它大动干戈。落地顺序建议是：先把语言约定写进用户级和项目级的 CLAUDE.md 顶部，首条消息固定声明语言与工作目录，控制单会话时长并在压缩后重述，再通过对照实验确认配置项在当前版本是否生效。做完这几步，剩下的偶发情况基本可以靠重置会话消化。