为什么你的 AI 听起来不对劲，即使技术上完全正确
某物流聊天机器人收到了一位客户的消息——他的包裹已经丢失一周了。机器人的回复是："我没有被训练来关心这件事。"从事实角度看，这完全准确：系统正确解析了查询，正确识别出无法路由处理该问题，也正确传达了其局限性。这个答案在每一个可量化的维度上都是技术正确的。但它同时也是一场产品灾难。
这就是语域问题——而这几乎肯定是你的评估套件没有在衡量的失效模式。
语言学中的"语域"（Register），指的是适用于特定情境、关系和目的的语言变体。它不仅仅是礼貌程度，而是整个交流契约：你有多正式、表达多少共情、以多大把握断言信息、是先给事实还是先给感受。客服代理、法律审查员、医疗助手和面向开发者的命令行工具，听起来应该截然不同——不是因为它们掌握的知识不同，而是因为它们在不同的交流期待下运作。
工程师构建 LLM 驱动的产品时，几乎总是只针对"知识问题"进行优化：调整准确性、上下文检索、幻觉减少和任务完成率。语域被当作一种"感觉"——在系统提示中加一句"友好而专业"就算解决了。事实并非如此。语域不匹配是一个隐性的用户流失驱动因素，它藏在"感觉就是不对劲"或"机器人好像不懂我"之类的反馈背后，几乎不会出现在你的定量评估套件中。
为什么你的评估套件对此视而不见
评估 LLM 输出的标准工具——BLEU、ROUGE、准确率分数、事实正确性检查——都是为了衡量一件事而构建的：正确信息是否出现在输出中。这些指标计算词汇重叠、检查关键事实的存在，以及验证答案是否与参考输出匹配。它们对信息如何传达完全无感。
一个回复"你的订单因供应链中断而延误"和一个回复"嘿！你的订单好像出了点供应链的状况——会晚一点，抱歉 :)"在大多数自动化指标下得分完全相同。两者在事实上毫无差异。哪个更合适，完全取决于具体情境——平台、用户的情绪状态、品牌声音、问题的严重程度——这些都是 BLEU 看不到的。
研究明确地证实了这一盲点。关于 LLM 评估的研究发现，衡量准确性的指标不足以用于对话式 AI 评估，因为它们对语气、多轮对话连贯性和情感共鸣视而不见。人工评估者能始终捕捉到自动化指标遗漏的问题：令人不适的语气转变、正式程度不匹配、不同回复之间的语域不一致。这个差距是结构性的，而非偶然。
其后果是：团队发布的产品每项准确率 A/B 测试都通过了，每个事实评估都是绿色，用户却仍在流失。问题不在任何 已记录的指标中，而存在于与产品交互的整体感受之中。
五种语域（以及 AI 产品在哪里失败）
社会语言学描述了正式程度谱系上的五种宽泛语域：凝固语域（仪式性、不变的）、正式语域（专业写作、法律文书）、咨询语域（协作性专业场合）、随意语域（朋友间的交谈）和亲密语域（亲密的个人关系）。大多数 AI 产品需要根据情境在咨询到随意之间运作。
失败模式主要集中在以下几种类型：
对情境而言过于正式。 一个说话像法律文书的消费者产品会制造距离感。用户感觉不是被帮助，而是被处理。这在企业 SaaS 产品中很常见——它们的系统提示经过法务和合规审查后，系统性地将语言推向了回避、限定语和被动语态。
对风险而言过于随意。 一个用轻松对话语气回应的金融或医疗助手会削弱自身权威。用户本能地感觉到语气与所询问事项的严重性不符。即使每个答案都是正确的，这种语域也在传递系统没有认真对待情况的信号。
与情感情境不匹配。 当用户来报告服务中断时，聊天机器人用"嗨！😊 今天有什么我可以帮你做的？"来开场，造成的伤害比中性回复还要大。南佛罗里达大学 2026 年的一项研究发现，聊天机器人的共情回复实际上可能触发心理抗拒——当共情来自非人类系统时，用户会感知为一种侵入或操纵，反而降低满意度，而非提升。在任一方向上把握不好共情的"刻度盘"都会产生摩擦。
文本一致，但多轮对话中前后矛盾。 多轮对话会暴露单轮评估永远捕捉不到的语域不稳定性。聊天机器人可能开始正式，随着上下文窗口填满而变得随意；可能开始时富有共情，当提示中的情感支撑耗尽后转为临床冷淡。这些转变令人迷失方向，即使单独查看每个回复时看起来都还不错。
提示腐化问题
语域不一致往往不是模型问题，而是工程过程问题。系统提示会积累补丁。
这个轨迹人们都很熟悉：产品经理注意到机器人听起来很冷漠，于是添加"要温暖有共情"；法务添加免责条款；客服添加特定边缘情况的处理；工程修复格式化问题；市场加入品牌声音说明。每一个改动单独来看都有道理，整合在一起却将系统提示变成了一个充满矛盾指令的九头蛇，模型必须在每次请求时去协调。
一个同时管理五种不同行为关注点——语气、法务规避、品牌声音、格式化和特定任务边缘情况——的提示，在架构上已经不稳定了。模型没有一致的语域可供参照；它有的是一组相互竞争的指令，会根据具体输入以不同方式解决张力。结果是用户体验为机器人有着不可预测性格的不一致性。
这与模型能力问题有着可测量的区别。同一个基础模型，给定一个结构良好、语域规格清晰一致的系统提示，会产生可靠一致的语气；同一个模型，给定一个有五层冲突语气指令的提示，会产生语域层面的信号噪声。
这要求的工程纪律是：将语域视为提示中的一等架构关注点——不是你随手添加的一行，而 是你以与任务指令同等严格程度维护的一个章节。当新的行为需求来临时，问题不应该是"我在哪里加这个？"而应该是"这符合现有语域吗？如果不符合，我们如何调和冲突？"
如何将语域规格化为需求
CO-STAR 提示框架做出了一个大多数其他框架会合并的有用区分：它将风格（结构性呈现——正式、新闻体、对话式）与语气（情感质量——自信、共情、紧迫、临床）分开。大多数系统提示把这两者当作一件事。分开处理给了你两个独立的调节杠杆。
对于客服工具：风格是"直接、第一人称、清晰句子，无行话"；语气是"耐心而就事论事，不过度温暖"。这与开发者文档助手不同——后者的风格可能是"精确的技术散文"，语气是"中性，假设用户有能力"。两者都是"专业的"，但在实践中听起来完全不同——将它们混为"专业点"这一笼统指令，两者都无法可靠实现。
对于语域控制，少样本示例比散文指令更可靠。告诉模型"温暖而权威"是模糊的——模型必须去解释这意味着什么，在不同输入上会产生不同的内插结果。展示三个你想要的语域的确切示例则模糊性小得多。模型会外推这个模式，而不是解读抽象指令。把你最强的示例放在最后——模型对后出现的示例赋予更大权重。
对于多轮语域一致性，值得在轮次序列而非仅单个回复上显式测试语气。一个以困难问题开始、经过沮丧的追问、以解决请求结 束的对话，是测试系统提示语域在压力下是否成立的自然测试用例。如果它经不住考验，不稳定性通常要么在提示结构中，要么在用户情感语气渗入系统上下文的方式中。
评估你在衡量的东西
将语域纳入评估套件不需要对每个回复进行人工审查，尽管人工审查能捕捉到自动化遗漏的东西。对大多数团队来说，实用的路径是对代表性样本使用 LLM-as-judge（以 LLM 作为评判者）。
明确定义标准：不是"这是个好回复吗？"而是"这个回复是否为当前情境维持了正确的正式程度？"和"情感语气对用户所陈述的情况是否合适？"这些是可评估的维度。评判模型可以被提示，根据从你的风格指南中提炼的标准在李克特量表上对其评分。评分不完美，但对语域问题的敏感度远高于 BLEU 分数或准确率检查，也不需要每次运行都有人工评审。
然而，最有用的信号往往就在你已有的失败数据中。支持工单升级、低分回复，以及用户在其中脱离对话的具体交流——在大多数已部署产品中，这些比事实问题更多地集中在语气问题上。当用户说"机器人好像不懂我"而没有指出具体的事实错误时，他们描述的就是语域不匹配。将这类反馈导入语域专项分析，往往会揭示出提示修复可以解决的模式。
核心纪律
技术正确性是底线，而非天花板。一个事 实正确但在情境中听起来不对劲的回复，即使通过了评估，也依然让用户互动失败。这两种失效模式是正交的——你可以只有其中之一——而只有其中一种会出现在大多数团队追踪的指标中。
语域所要求的纪律，是将交流适当性视为与事实准确性同等重要的需求来对待：明确规格化、系统测试、在生产中监控，并防范提示腐化。这意味着将语域作为结构化章节而非模糊形容词写入系统提示，在轮次序列而非单一输出上进行测试，并构建能真正区分"技术正确"与"交流恰当"的评估标准。
那些用起来感觉好的产品——用户描述 AI 真正理解他们的那些——不是事实准确率得分最高的。而是那些语域针对情境校准得当且保持一致的产品。这是一个工程问题，不是模型问题，它有工程解决方案。
