多语言客服流畅作答，却改错业务条款

AI 能用流利的西班牙语接待客户，不代表它能准确执行公司的退款和报价规则。原文讲的是一家美国得克萨斯州医美连锁店：英文客服遵守政策，西班牙语客服却把价格有效期延长、把不可退款说成可退款，持续了七个月才被发现。

作者的建议很明确：涉及钱、期限和承诺的句子，应当像配置一样维护，提前翻译并审核，限制模型临场改写。对正在做多语言 AI 客服的团队，这篇最有用的地方，是把「回答是否自然」变成了「业务规则是否一致」这一套可检查的问题。

外语说得越顺，为什么越容易漏掉错误

这家店有两处门店，41% 的入站消息使用西班牙语。店主很满意 AI 第一天就能直接接待，无须插件，也无须增加供应商。

作者抽查了 300 段西班牙语对话，对照英文政策，发现三处表述都朝着更宽松的方向偏移。到问题暴露时，已有 11 位客户按错误的 90 天价格有效期预约，另有 4 位客户要求退还被告知可以退的定金。原文没有逐条展示最初的三处差异，后文集中讨论了定金、效果承诺和报价有效期。

作者认为，风险来自模型重新组织意思的过程：它理解原句，再生成另一种语言，每次重组都有机会丢掉限制条件。这个解释有合理性，但文中没有提供模型内部证据，不能当作已经验证的故障机制。

更容易观察的是四类输出问题：

• 数字和否定丢失，例如「不可退款」「不含税」「不保证」中的限制消失。
• 称谓不合场景，例如西班牙语的 tú/usted、德语的 Sie/du，以及日语敬语层级没有按品牌要求统一。
• 内部术语混入客户回复，产品档位、内部编号和邮件模板名称未经处理就出现在外语句子里。
• 对话切换语言后，AI 没有跟随客户；转人工时，又把摘要写成接手客服读不懂的语言。

多语言客服要验证的，是每种语言下的业务承诺是否相同。

语气自然只能证明表达顺畅。客户实际依据什么价格、什么期限、什么退款条件作决定，需要单独检查。

把政策句子存下来，比反复要求准确翻译更可控

作者提出维护一张平行政策表：每行对应一个受保护的句子，每列对应一种语言，译文先由人工翻译、审核，再供 AI 原样引用。

示例中的三个键分别是 deposit_refund、results_disclaimer 和 package_validity，覆盖定金在 48 小时内不可退款、效果因人而异且不作保证，以及套餐价格有效期为 30 天。语言列包括英文 en、西班牙语 es 和日语 ja。

这里也有一个需要审校的细节：英文示例里的「within 48 hours」没有明确从什么时间点计算，而日文写到了取消预约的情形。源政策自身若有歧义，存成固定字符串也不会自动变准确。

下面这段指令用于限制回复如何调用已审核的政策：

When a reply touches deposit, refund, results, warranty, or pricing validity:
1. Detect the customer's language.
2. Emit the approved string for that language VERBATIM from the
   policy sheet. Do not translate, paraphrase, shorten, or rephrase.
3. If no approved string exists for that language, reply in English
   and set needs_translation: true in the handoff payload.

要看第三条：没有批准译文时，回复英文，并在转交数据中设置 needs_translation: true。它把缺少翻译变成了一个可见的待办，避免模型悄悄补出另一套政策。

这家店的葡萄牙语服务也存在同样问题：AI 一直能流畅作答，却没人审核过相应政策。

这套方案适合保护稳定条款。开场白和普通解释仍可以灵活生成，但定金、退款、效果、保修和报价有效期等内容，需要有明确的权威来源。原文给出的是提示词约束，没有展示程序如何保证最终输出确实逐字一致。

回译负责拦截，固定问题负责持续发现变化

固定政策表覆盖不了所有临时让步和边界情况。作者建议在发送前增加一次回译：把外语回复按字面翻回英文，再和英文政策比较。

下面的提示词把检查拆成三类，并规定发现偏差就停止发送：

Original English policy sentence: <s>
AI's outbound message: <m>
1. Translate <m> back to English, literally.
2. Compare to <s>. Report any of:
   - NUMERIC DRIFT (any number, unit, or duration differs)
   - POLARITY DRIFT (a negation appears or disappears)
   - COMMITMENT DRIFT (a hedge like "may," "varies," "cannot"
     becomes a promise, or vice versa)
3. If any drift: DO NOT SEND. Route to human review with both texts.

关键是最后一条 DO NOT SEND：检测结果必须影响发送流程，而不能只留在日志里。NUMERIC DRIFT 检查数字、单位和时长；POLARITY DRIFT 检查否定是否出现或消失；COMMITMENT DRIFT 检查「可能」「无法保证」是否被改成了承诺。

例如，90 天回译后仍是 90 天，便能与原政策的 30 天形成差异。作者称，在一个部署项目中，这道检查首月拦截了 2.8% 的出站消息，还发现了地址、电话号码和预约时间被改坏的情况。不过，原文没有给出样本量、误报率和漏报率，2.8% 只是拦截比例，不能用来表示检测准确率。

另一层检查是固定探针题：把相同问题提前人工翻译，在所有支持语言中每周运行，对照英文基线，检查定金、报价、效果保证、退款、改期、保险、取消窗口、迟到费、儿童陪同、事后联系和额外费用。

原文称其为「12-question probe set」，实际列出的只有 11 道题。这是材料本身的缺口，不能自行补一道后当成作者原版。

周报则记录 12 q x n langs 的完成情况、三类漂移数量、回译拦截及处理情况，以及转人工摘要能否被客服读懂。作者主张观察每 100 组探针对比的漂移数，并期望固定条款覆盖后的前两周结束时归零。但发现偏差也可能来自检索、语言识别或生成环节，不能直接认定一定有人改了政策却没同步译文。

我的判断

我赞同先保护业务规则，再优化外语表达。价格、期限和退款条件发生变化，会直接影响客户决策，把它们作为缺陷处理，比争论译文是否地道更有效。

相较于每次把完整政策交给模型翻译，审核后的固定句子更容易追溯和复查。对少量稳定条款，也可以由应用根据政策键和语言直接取出文本，减少模型参与改写的机会；数字、币种和期限还能增加确定性校验。这样的实现建议超出了原文，但与它要解决的问题一致。

回译适合作为补充检查，不能成为准确性的唯一凭据。同样依赖模型判断，仍可能漏掉语义变化。作者所说的「便宜」只说明多一次模型调用，没有给出延迟、调用费用，以及误报带来的人工复核成本。

案例的后续结果是：上线六周后，西班牙语和葡萄牙语的定金说明被修正，效果声明改为固定文本，错误的 90 天报价消失；英语客服也开始收到两行英文转交摘要。四笔退款争议按此前承诺处理，合计约 1,100 美元。这些是作者报告的项目结果，没有对照实验。

作者还称，探针测试约 20 分钟就能暴露问题，由一名负责人每周用不到 45 分钟运行和复核。这更适合作为经验目标。语言数量、政策复杂度和人工复核量变了，投入也会变。

能拿来做什么

• 如果正在做多语言 AI 客服，先整理退款、价格、期限和保证条款，建立政策键、权威原文和已审核译文的对应关系，并明确缺少译文时如何处理。
• 在 Node 服务的发送入口校验受保护内容，把 needs_translation: true 接入待办或转人工流程；回译发现偏差时，应真正阻止消息发送。
• 建立覆盖实际服务语言的固定回归问题集，政策或提示词变更后重新运行，每周记录数字、否定和承诺的差异。原文缺少的第十二题应根据自己的业务补齐。
• 给客服前端补上语言切换和转人工检查：客户改用另一种语言后能否正确跟随，摘要是否使用接手人员的工作语言，同时保留原始消息供核对。