你的系统提示词还在用英文：AI 本地化不完全的隐形成本

你的团队发布了一项 AI 功能。你为本地化工作感到欢欣鼓舞：每个按钮标签、工具提示和错误消息都被翻译成了 12 种语言。产品经理签了字。该功能在全球上线。

然而，六周后，一位德国用户发布了一张截图。AI 的回答用词正确但语域（Register）不对 —— 在非正式的客服场景中显得过于生硬。一位日本用户反映，结构化输出中的日期格式为 MM/DD/YYYY，这导致他们的下游工具出现故障。一位巴西的支持工程师注意到，AI 在对复杂查询进行推理时，偶尔会在句子中途滑入英语。这些并不是基础设施故障。你的仪表盘显示一切正常。但对于非英语用户来说，产品正在悄无声息地变得更糟。

根本原因几乎总是一样的：团队翻译了 UI 字符串，但却让系统提示词保留为英文。这看起来像是本地化，但事实并非如此。

为什么系统提示词不是中性文本

系统提示词不是配置文件。它是模型运行其中的推理支架。它确立了角色、语气、输出结构、约束，以及模型与用户之间隐性的文化契约。当这个支架是用英文编写，而用户正在使用德语、日语或阿拉伯语进行交互时，模型会面临一种失配，而这种失配是英语性能指标永远无法揭示的。

多语言大语言模型（LLMs）处理所有语言的方式并不对称。在内部，即使处理非英语输入，大多数主流模型也会默认采用类似英语的表示空间 —— 它们将输入转换为英语潜空间表示进行推理，然后再翻译回目标语言进行输出。这产生的输出虽然语法正确，但在语用上却显得失当。正式度标记无法干净利落地转换。礼貌习惯也各不相同。短语“be concise and direct”（简洁直接）在英语商业写作中意味着特定的含义；但在日语中，委婉通常是职业规范，这条指令生成的回答在母语者听来会显得粗鲁。

跨越 29 种语言的 MMLU-ProX 基准测试显示，在完全相同的问题上，英语和斯瓦希里语的表现差距高达 38 分。即使是像希腊语和阿拉伯语这样的高资源语言，在复杂推理任务上的准确率也比英语低 20–40%。这些数字反映了当语言被视为等价输入时，模型层面会发生什么。它们也反映了当你上线一个假设模型始终以英语进行推理的系统提示词时，你的用户会遇到什么。

不完整本地化悄然失效的三个地方

正式度和语域漂移。 德国商业环境需要正式称呼；如果在粗心翻译的系统提示词中默认使用非正式的“du”，会生成让人感到居高临下的输出。西班牙语因地区而异 —— 如果不进行调整，同一个提示词无法同时覆盖西班牙和墨西哥。英文系统提示词中要求“语气亲切友好（be warm and approachable）”嵌入了英语语用学。在日语客服场景、巴西场景和英国场景中，“亲切”的含义是不同的，模型并不会根据用户的语言推断文化规范 —— 它只是在遵循你给出的英文指令。

针对跨语言提示词礼貌性的研究证实，最佳礼貌水平因语言而异，而不仅仅是文化。一项关于跨语言提示词可控性的研究发现，英文系统提示词在人口统计描述中始终会产生更高的偏见，且这种偏见差距随着模型规模的增大而扩大。在更多英文数据上训练的大型模型，会放大嵌入在系统提示词中以英语为中心的默认设置。

结构化输出格式不匹配。 日期是最明显的信号。主要在英文文本上训练的模型默认使用 MM/DD/YYYY。如果你的系统提示词没有明确指定使用 ISO 8601 (YYYY-MM-DD) 以及目标语言预期的区域设置（Locale），模型将生成具有本地歧义的日期。10 月 3 日在美国输出中变成 10/03，而在欧洲的预期中是 03/10，如果你的下游消费者预期特定格式，这两者都是错误的。

数字分隔符也遵循同样的模式：英语计数法中的 1,234.56 与德语计数法中的 1.234,56。货币符号的位置也各不相同。这些不仅仅是美观问题 —— 当代码消费格式错误的结构化输出时，程序会崩溃。而且它们专门在非英语区域设置下失效，这意味着这种失效在你的英语测试覆盖范围中是不可见的。

领域词汇缺口。 专业术语通常缺乏完美的翻译，LLMs 会用直译或音译来填补空缺，而不是使用领域内恰当的对应词。一个使用经过英语培训的法律术语的 AI 法律助手，会默认使用让母语法律从业者感到陌生的字对字直译。法语医疗 AI 可能会在存在法语临床词汇的地方使用英语化的技术术语。用户会注意到，但指标不会。

分词让问题变得结构化

在模型开始推理之前，分词（Tokenization）就已经对非英语用户施加了惩罚，并让其他问题变本加厉。由于分词器的训练数据以英语为主，使用非拉丁脚本的语言——阿拉伯语、中文、日语、韩语、印地语——所需的 token 数量是等效英语文本的 2 到 15 倍。一个可以容纳完整英语对话的上下文窗口，在处理阿拉伯语对话时可能会发生截断，从而剥离了模型至关重要的上下文。

乌克兰语、印地语和印度官方语言表现出严重的分词低效。一位研究人员对此做了精辟的总结：分词正在“扼杀多语言 LLM 的梦想”。这不只是提示词工程的问题，而是基础设施的问题。但它会与提示词工程的决策产生交互。一个在英语中只有 300 个 token 的系统提示词，在日语中可能达到 800 个 token，从而消耗了本应分配给用户内容的上下文预算。针对英语优化上下文窗口使用量的团队，直到处理其他语言的生产流量时，才会注意到这种不对称性。

评估差距：没有人为多语言质量负责

以下是这些失败累积的原因：负责系统提示词的是 AI/ML 团队；负责翻译的是本地化团队；负责评估（evals）的是数据科学团队。没有人被授权负责这些领域的交集——即非英语用户的 AI 输出质量。因此，多语言评估从未真正落地。

研究界已经产出了弥补这一差距的框架。MEGA（微软多语言评估）涵盖了 70 种语言的 16 个 NLP 数据集。MMLU-ProX 在 29 种语言中运行 11,829 个相同的问题进行直接对比。BenchMAX 涵盖了 17 种语言的 10 个任务。CIA Suite（跨语言自动评估）提供了特定语言的评估器 LLM 和现成的测试集。这些工具是存在的，但它们并没有被普遍用于生产评估流水线中。

组织模式是一致的：团队在英语（可能还有另外一两种语言）中运行评估，建立基准，并监控聚合指标。当提示词的更改降低了土耳其语或印度尼西亚语用户的输出质量时，系统不会触发任何告警——因为没有建立针对特定语言的质量指标。这种退化是不可见的，直到有用户截图反馈。

一项针对 52 种语言的多租户智能体评估发现，表现最好的模型在所有语言中的平均准确率仅为 34%，其中英语为 57%，而低资源语言则低于 10%。向全球发布 AI 功能的团队如果不进行测量，就等同于默认接受了这种差距。

本地化感知的提示词设计究竟是什么样的

修复方法并不复杂。它是组织层面的——需要有人对此负责。

本地化整个系统提示词，而不只是面向用户的表面层。 “你是一个乐于助人的客服人员”并不是一条中立的指令。将其翻译成目标语言，并调整隐含的角色和语气。在德语中：使用正式称呼的 “Sie sind ein hilfsbereiter Kundendienst-Mitarbeiter”。在日语中，服务人员的文化角色带有不同的礼貌和委婉惯例，这需要显式编码。

显式强制执行特定区域的结构化输出约束。 不要指望模型能从用户的语言中推断出日期格式。明确说明它：“无论语言环境如何，将所有日期格式化为 YYYY-MM-DD”或“对于德国用户，使用以下日期格式：[DD.MM.YYYY]”。数字分隔符、货币显示和计量单位也是如此。当 Schema 合规性至关重要时，在推理时进行约束解码（Constrained decoding）可以增加第二层强制保障。

维护语言细分的评估基准。 按语言运行质量评估，而不是聚合评估。独立建立每种语言的基准准确率、结构化输出合规率和幻觉率。针对每种语言的指标偏移进行告警，而不仅仅是整体指标。虽然这会带来实际的开销，但与向非英语用户交付质量无感知退化的产品的风险相比，这是成比例的。

对于低资源语言，在目标语言中使用少样本 (few-shot) 示例。 使用用户语言中具有文化相关性和领域相关性的少样本示例进行提示，可以弥补单纯翻译提示词无法解决的性能差距。这对于零样本 (zero-shot) 性能显著低于英语的语言尤其有效。

将推理语言视为一个变量，而不是常量。 对于中等资源语言，有时使用英语思维链 (CoT) 中转可以提高准确率。而对于高资源和低资源语言，使用母语推理的表现通常与英语中转持平甚至更好。没有标准答案——请根据你具体的任务领域，针对每个语系进行基准测试。

组织架构上的修复比技术上的修复更彻底

上述技术模式已经广为人知。组织架构上的差距才是更难解决的问题。需要有人像负责英语 AI 质量一样，负责多语言 AI 质量——拥有评估套件、监控仪表盘，并在每种语言的质量下降时进行事件响应。

本地化团队懂语言。AI 团队懂提示词。默认情况下，这两个团队都不负责交集部分。修复方法是明确授予一项职责——无论是一个专门的角色、团队之间的共享 SLA，还是定期审计多语言提示词质量和评估覆盖范围的节奏。

在建立这种责任制之前，团队将继续翻译 UI 字符串，保留英语的系统提示词，并在发布六周后通过用户的截图发现质量退化。而在此期间，基础设施指标将一直保持绿色。