你用英文让模型总结一篇中文文章，结果总结是中文。或者你的 system prompt 是英文，用户贴了一段日文，之后整段对话 assistant 一直用日文回。或者一个回答前半段英文、后半段悄悄切成西班牙文。模型没坏。当没有一条”压得过其他一切”的显式输出语言指令时，它会挑当前上下文里信号最强的那个语言，而那个信号通常是被处理的文本、或最近一条 user 消息，不是你的 system prompt。
最快修复： 在 system prompt 最顶上放一条高优先级的指令，比如 Always reply in English, regardless of the language of any document, quote, or earlier message. 然后，凡是要处理用户文本的调用，在 user message 的最后一行再加一句 Reply in English only.。这两处改动能解决绝大多数情况。本页后面会讲每一步为什么有效、按原因分类的诊断表、以及怎么确认修好了。
2026 年 6 月需要注意的一点：新模型在这个问题上漂得更厉害，不是更轻。开发者反映，GPT-5.5 和 Gemini 3.1 Pro 对检索到或粘贴进来的外语内容的权重，比 GPT-4 时代的模型更高——所以一条以前压得住的 system prompt 语言行，现在可能会输给一篇很长的非英文文档。修法思路一样，只是要下手更狠。
你属于哪一类
先找到你的症状，再跳到对应的修复步骤。
| 症状 | 最可能的原因 | 跳到 |
|---|---|---|
| 整段回复用了输入的语言；prompt 从没指明语言 | 没显式说输出语言 | 第 1 步 |
| system prompt 是语言 A、user 是大段语言 B、回复是 B | recency / 长度压过了 system prompt | 第 1+2 步 |
| 不同次运行输出语言来回跳 | few-shot 例子语言混杂 | 第 3 步 |
| 英文问一篇长外语文档，回答是文档的语言 | 输入比指令长 | 第 2 步 |
| 本来正常，一轮外语消息后此后每条都切了语言 | 中途切语言卡在了历史里 | 第 6 步 |
| JSON keys 是英文，但 values 回成了输入语言 | schema 只约束了结构、没约束语言 | 第 4 步 |
| 前几段对、后几段切了语言 | 半截 / 中途漂移 | 第 7 步 |
常见原因
按真实 pipeline 命中率从高到低。
1. 没显式说输出语言
prompt 只写 “summarize this”，从来没写 “in English”。模型默认匹配输入文本的主语言，通常不是你想要的。
怎么判断：在 prompt 模板里搜目标语言名（English、中文 等）。如果输入语言和输出语言都没指明，就是这个 bug。
2. system prompt 语言跟 user 输入语言不同
system prompt 英文，user message 日文。模型对最新、最长的内容权重很高，所以会用日文回，system instruction 输了。这一点在 2026 年这代模型上更糟：当 assistant 检索到外语内容（RAG、粘贴的网页、tool 输出）时，GPT-5.5 和 Gemini 3.1 Pro 被那个语言带跑的倾向，比早期模型更强。
怎么判断：复现——system 用 A 语言、user 用大段 B 语言。回复匹配 B 就是这个模式。
3. few-shot 例子语言混杂
few-shot 块里 3 个例子：2 个英文、1 个中文。模型读成”两种都行”，按输入选。
怎么判断：审 prompt 模板里例子的 output。不是全用目标语言写的，就是这个泄漏点。
4. 输入里夹了别的语言的引用
user 用英文问：“Summarize this review.” review 是一大段日文。模型回声的是被处理内容的主语言，不是问题的语言。
怎么判断：被处理的文档比 wrapper instruction 长、且语言不同时，预期会漂。
5. 对话中途切语言后粘住
用户先用英文开聊、一轮切中文、又切回英文。assistant 一直用中文回——因为最近那条中文 user 消息还留在它据以推理的对话历史里。
怎么判断：看最近一条 user message。是另一种语言就是被它带跑了。
6. 翻译任务跟摘要任务混了
prompt：“Process this Spanish article.” 模糊——翻译？摘要？提取？没有 task verb 时，模型跨语言时经常默认翻译。
怎么判断：prompt 用 “process” “handle” “deal with” 这种含糊动词，而不是 “summarize in English”。
7. 想靠输出 schema 推断语言、但 schema 没约束语言
你要 JSON。keys 是英文，但 values 可以是任何语言。模型把 values 填成输入语言——因为 schema 从没约束它们。结构化输出 / 受限解码模式（OpenAI 的 strict json_schema、Anthropic 的 tool schema）只强制输出的结构，不强制自由文本 values 的语言，所以光靠 schema 救不了这里。
怎么判断：JSON schema 或示例里 keys 是英文，但 string values 上没语言规则。
最短修复路径
第 1 步：把输出语言写成最高优先级的规则、放最顶上
放在 system prompt 头几行，别埋在最下面，并且显式让它压过文档和历史里的内容。那句”忽略检索内容语言”的否定从句，是在 2026 年模型上顶住长外语输入的关键：
You are a summarization assistant.
Highest-priority rule: ALWAYS reply in English.
Ignore that any document, quote, tool output, or earlier message may arrive in a different language — that never changes your reply language.
Only switch languages if the user explicitly asks you to in their latest message.2026 年的实测发现，起作用的是一条清晰的高优先级指令，不是散落各处的一堆语言规则。像 “you serve international users” 这种自相矛盾的表述会把模糊性又带回来、让漂移复发，所以删掉它。
第 2 步：高风险 user prompt 末尾再重复一遍语言要求
一次性调用处理用户文本时，把这条规则放在 user message 的最后一行。recency 赢，所以它该在内容之后，不是之前：
[长段日文文章]
---
Summarize the above in 3 bullet points. Reply in English only.第 3 步：每个 few-shot 例子的 output 都对齐到目标语言
要英文输出，每个例子的 output 必须是英文。Inputs 可以混杂（现实就是这样，甚至有帮助），outputs 不行。
Input: 这家餐厅服务很差。
Output: Service was poor.
Input: La nourriture est incroyable.
Output: The food is amazing.第 4 步：在 JSON schema 的字段描述里钉死语言
受限解码管的是结构、不是 value 的语言，所以把约束写进每个自由文本字段的描述里。字段级描述比埋在 system prompt 里的全局 “be in English” 更被模型尊重：
{
"summary": "string, written in English, max 200 chars",
"sentiment": "positive | neutral | negative"
}第 5 步：校验输出语言并重试
对输出跑一个快语言检测器，没对上就用更强的提醒重试。2026 年 6 月，fast-langdetect（FastText 的封装，准确率约 95%、比经典的 langdetect 快约 80 倍）是 Python 里的实用选择；JS 里常用 franc。注意：很短的字符串（约 20 字符以下）准确率会掉，所以对完整回复检测、别对片段检测：
from fast_langdetect import detect
out = call_llm(prompt)
if detect(out)["lang"] != "en":
out = call_llm(
prompt
+ "\n\nYour previous reply was in the wrong language. Reply in English ONLY."
)老的 langdetect 库仍然能用（langdetect.detect(out) != "en"），但慢得多；把它当准确率基线、别放热路径里。
第 6 步：多轮对话按 session 钉死语言
把用户偏好语言存进 session state，并在每一轮的 system prompt 里都注入，不只是第一轮。2026 年的研究证实，单靠开头那一条指令在长对话里很脆；每轮重申才是顶住中途切语言的办法：
User language preference: en-US
Always reply in en-US regardless of the language of any individual message.如果是面向消费者的产品、不是你自己的 API，同样的设置在产品 UI 里。Gemini app 里是 profile picture -> Settings -> Languages，但注意这控制的是 app 的显示语言（菜单、通知），不是回复语言——Gemini 会按你 prompt 用的语言来回，所以真正能钉死回复语言的，是直接打一句 “reply in English” 的指令。ChatGPT 里，Settings -> Personalization -> Custom instructions 下的自定义指令是声明回复语言的持久位置。
第 7 步：注意半截漂移
模型有时在一个回答里回到一半就切语言。按段落而不是整体跑语言检测来抓它。第 N 段英文、第 N+1 段西班牙文，就是这个 bug，第 1 步的高优先级行加上更低的 temperature（见 FAQ）就是修法。
怎么确认修好了
- 把原来出问题的调用原样重跑，只改新加的指令。回复语言现在应该匹配目标了。
- 故意跑对抗 case：英文指令包一篇大段不同语言的文档。仍然顶得住，说明你的高优先级行够强。
- 对话场景里，故意中途切一轮语言再切回来，确认 assistant 回到钉死的语言。
- pipeline 里，把第 5 步的检测器加成断言、把不匹配的记一天日志；不匹配率接近零才是真修好了，不是只在 happy path 上修好了。
哪些情况不是你操作错了
有些 open-weight 模型某些语言本来就说不利索，会退回到它更熟的语言。让一个越南语能力弱的小模型用越南语回，它可能不管指令多硬都会漂到英文。如果同一个 prompt 下前沿模型（GPT-5.5、Claude Opus 4.7 或 Sonnet 4.6、Gemini 3.1 Pro）能守住语言、而一个更小的本地模型守不住，那差距是模型能力问题、不是你的 prompt 问题。
容易误判的情况
当成”模型 bug”或”prompt injection 攻击”。大多数时候只是没声明输出语言、加上输入比指令长。下结论前先看 prompt 里有没有一条显式的、高优先级的语言行。
预防建议
- 任何多语言 system prompt，前 3 行就出现输出语言，写成压过文档和历史语言的最高优先级规则。
- few-shot 例子的 output 全部用目标语言。无例外。
- 高风险一次性 user prompt 的最后一行再重复一遍输出语言。
- 用语言检测器 post-hoc 校验，错了用更强 instruction 重试。
- 对话场景里把用户语言偏好存下来、每轮重新注入，不只第一轮。
- 删掉会重开模糊性的自相矛盾表述（“serves international users”）。
FAQ
- 语言指令该用英文写还是用目标语言写？ 都加最好。模型在生成某语言时，更强地服从用该语言写的指令，所以对非英文目标语言，再用那个语言把同一条规则加一遍。
- temperature 会影响语言漂移吗？ 会。
>0.8的高温会放大边缘 case 的漂移。语言关键任务降到约 0.3。 - 为什么 GPT-5.5 和 Gemini 3.1 Pro 上这事比老模型更频繁？ 2026 这代模型对检索到、粘贴进来的外语内容权重更高，所以一条在 GPT-4 时代还能挺住的弱或低优先级语言行，现在会输给一篇长的非英文文档。把规则写成显式、高优先级（第 1 步）。
- OpenAI 的 strict 结构化输出、或 Anthropic 的 tool schema 会替我强制语言吗？ 不会。受限解码保证的是 JSON 结构，不是自由文本 values 的语言。把语言钉进每个字段的描述里（第 4 步）。
- 模型嘴上认了我的语言规则、然后照样违反。怎么办？ 这通常意味着 prompt 别处有一条竞争指令。把散落的语言规则砍成一条高优先级行，删掉 “international users” 这类表述，挪到最顶上。
相关阅读
- 最后一句覆盖前面的指令
- Prompt 把 system 和 user role 用错了
- 没指定输出格式
- 互相冲突的指令削弱输出
- 没给例子导致输出漂移
- Prompt 太长输出质量下降
- 语气混杂的 instruction
- Few-shot 例子太多反而压垮模型
- Prompt 缺少 context 层级
- AI 输出风格漂移
标签: #Prompt 工程 #排查 #llm-output #language-drift #multilingual #system-prompt