中英混合输出混乱通常不是模型的语言能力缺陷，而是提示词中缺少明确的语码边界。模型在预训练阶段接触了大量中英文交错的数据，当输入没有指定主语言时，它会根据上下文概率同时激活多个语言通路，导致一句话里既有中文动词又有英文名词，甚至整段切换到英文。要解决这个问题，必须在请求中显式声明主语言，并对需要翻译的内容做结构化拆分。
先看一个典型失败案例：用户写了一句“解释一下 transformer 的 attention 机制，然后给个代码”。这个提示词本身混杂了中英文，模型很难判断输出语言到底以哪个为主，于是返回的内容常常是“Transformer 的 attention 机制通过 query 和 key 计算权重，代码如下：def forward(self, x) …”这种中英夹杂形式。问题不在模型，而在语言目标没有被锁定。
中英混合的根因：语码切换与提示词边界模糊
语码切换是双语者或多语模型常见的现象，指的是在同一段话中频繁切换语言。对生成式模型而言，训练语料中大量技术文章、代码仓库、论坛问答本身就是中英混合体。比如中文技术博客里经常出现“这个 API 封装了句柄，调用时要注意 null 和 undefined”，模型学习到这种分布后，在没有明确指令时会随机复现。
另一个原因是提示词本身没有区分“目标语言”和“引用语言”。如果用户说“帮我翻译一下这段代码的英文注释”，模型可能把翻译结果和原始代码混在一起输出。此时需要把角色、输入内容、输出语言分开声明，让模型知道哪部分是需要处理的原始文本，哪部分是必须遵守的输出规范。
还有一个容易被忽略的因素是系统消息与用户消息的权重差异。很多 API 调用只把限制条件写在用户消息里，但模型对系统消息的遵循度更高。把主语言声明放进系统提示里，再在用户消息中重复一次简短约束，能显著降低混合概率。
主语言声明的正确写法：从含糊到强制
单写“请用中文回答”效果有限，因为模型可能认为这只适用于当前一句，而不是整个会话。更有效的做法是使用完整的语言策略声明，例如“本次对话的主语言为简体中文。所有解释、总结、代码注释、列表项、标题均使用中文。英文仅允许出现在专业术语首次出现时的括号标注中，例如‘注意力机制（attention）’”。这种写法把允许英文的场景也限定清楚，避免模型自行发挥。
下面是一个通过 API 构造多轮消息的示例，展示如何把主语言声明放在系统消息中。
messages = [
{
"role": "system",
"content": (
"主语言：简体中文。"
"所有回复、解释、代码注释、变量说明均使用中文。"
"专业术语首次出现时用中文，括号内保留英文原词。"
"禁止整段英文输出，禁止中英混杂句式。"
)
},
{
"role": "user",
"content": "解释 transformer 的 attention 机制，并给出一个简化实现。"
}
]
这个示例把语言边界写成三条硬性规则，而不是笼统的“用中文”。实际测试中，加上“禁止整段英文输出”这一句非常关键，因为模型一旦开始生成英文短语，后续内容很容易被带偏。主语言声明越具体，返回结果的语码一致性越高。
需要注意的是，主语言声明并非要求所有英文单词都翻译成中文。像 API、JSON、HTTP 这类已经广泛使用的缩写，强行翻译成“应用程序接口”反而降低可读性。可以在声明中明确豁免范围，例如“通用技术缩写保持原文，如 API、JSON、SQL、HTTP”。这样模型不会因为“禁止英文”而把缩写改成奇怪的中文表达。
翻译请求的拆分策略：片段化与术语表
当任务是翻译一段英文技术文档或代码注释时，直接塞给模型一大段混合内容往往导致输出仍保留英文结构。更可靠的方式是拆分请求：先把原文完整给出，然后单独写清翻译规则，最后要求模型只输出译文。分段翻译能减少上下文干扰，尤其是长文档中不同段落语言风格不一致时。
以翻译一段包含代码的技术说明为例，可以这样组织提示词。
prompt = """ 请将下面英文技术说明翻译成简体中文。 规则： 1. 逐句翻译，不改变原文句子顺序。 2. 代码标识符、变量名、函数名保持原文，不翻译。 3. 专业术语首次出现时写成中文（英文原词）。 4. 输出只包含译文，不要附带原文或额外说明。 英文原文： The function reads a file from disk and returns its content. If the file does not exist, it raises FileNotFoundError. """
这种结构把输入原文和输出要求完全分开，模型在翻译时不会把规则误当成待翻译内容。特别要强调“输出只包含译文”，否则模型可能先输出原文再附上译文，造成中英混排。术语表的作用也很大，如果某个词已经被项目约定为固定中文，比如把“token”统一翻译为“令牌”，可以在请求中直接锁定，避免模型随机选择“标记”“词元”“令牌”等不同译法。
对于代码注释翻译，还可以进一步要求保留注释符号。例如“保留 # 或 // 注释前缀，注释内容翻译为中文，代码本身保持原样”。这样模型不会把 Python 的 # comment 改成其他格式，也不会在翻译时把代码块里的关键字改动。
解码参数控制：从采样层抑制语言漂移
除了提示词，解码参数也会影响语言一致性。当 temperature 设置得较高时，模型在每一步都有更大随机性，可能突然切换到英文。如果输出语言是你最关心的指标，建议将 temperature 控制在 0.2 到 0.5 之间，让生成更确定。top_p 可以设置为 0.9 左右，避免过长尾词干扰。
某些 API 还支持 logit_bias 参数，可以对特定 token 的生成概率进行惩罚。比如把常见英文起始词“The”“This”“However”的 token id 调低权重，可以进一步阻止模型开启英文整句。但实际操作中 logit_bias 的效果不如提示词稳定，因为 token 化粒度不同，同一个英文单词可能被拆成多个子词。
response = client.chat.completions.create(
model="your-model",
messages=messages,
temperature=0.3,
top_p=0.9,
frequency_penalty=0.2,
# 可选：对某些英文起始 token 做负向偏置
# logit_bias={12345: -10, 67890: -10}
)
实际使用中，主语言声明和翻译请求拆分已经能解决大部分中英混合问题，参数控制属于补充手段。如果发现模型偶尔在代码块之外冒出英文短句，可以尝试降低 frequency_penalty 或加入一条“结束代码块后必须回到中文解释”的规则。关键是把语言目标当成一个必须遵守的硬约束，而不是靠模型自行判断。
这套方法在技术写作、代码助手、API 文档翻译等场景都能直接落地。把主语言声明写进系统消息，把翻译请求拆成原文、规则、输出三段，再用温和的解码参数收紧随机性，中英混合输出混乱就能得到有效控制。