本地化智能体：流畅度不再预示忠实度，而你的评审流程还没察觉。
三十年来，人工审校译文之所以管用，靠的是一条没人写下来的捷径：糟糕的译文读起来就糟糕，所以审校者一路扫着别扭之处，顺手就抓住了大多数真错误。这条捷径没了。今天的模型产出的文字地道、笃定，偶尔说的是另一件事，而一个只读译文的审校者根本拿不到任何信号——那句把警告反转过来的话，读起来和没反转的一样漂亮。这份手册里的一切都由此推出：可审校的单位是 diff 中的原文-译文对，关卡是机器可校验的不变量，而译文质量恰恰是这条流水线里你最不该操心的部分。
瓶颈挪位了，任务的定义也要跟着挪。
本能的框架是"把我们的内容翻成八种语言"，而它把力气指向了这个问题里已被大体解决的那一部分。照这个框架做出来的团队会得到一份出色的初稿，然后发现真正的成本从来就不在初稿。
- 是整个语料的一致性，不是单句的质量。把一篇文档翻好很容易。让四千篇文档里同一个产品名词、同一个按钮标签、同一段法律免责声明每一次都呈现得一模一样，是一个状态管理问题——而本地化预算真正花在的地方正是这里。
- 是变更的吞吐。内容不是翻一次就完事。周二改动的一个段落，必须在周四之前抵达八个语言区，而且不必把没变的那九成重新翻译一遍、也不必重新审校一遍。一个把每次发布都当作全新全量翻译来做的智能体，只是把一份线性成本换成了另一份线性成本，外加一条审校队列。
- 是那些没人翻的东西的覆盖率。报错文案、空状态、工具提示、图示的 alt 文本、那封 2023 年之后没人读过的确认邮件。它们单个看微不足道，加起来体量惊人，而它们至今在你的产品里还是英文，诚实的原因是它们从来不值得走一次供应商采购单。这是可得的最清晰的一份收益，值得优先拿下。
注意这里哪一项是翻译问题：一项都不是。它们是流水线问题、状态问题和覆盖率问题——这恰恰是为什么智能体（一个能调工具、能跨许多文件把任务扛住、能照着清单走的东西）在这里的增益，会大过换一个更强的模型。想靠买更强的模型来修一个一致性问题，是这个领域里的标志性错误。
失败模式是"流畅且错误"，而读是抓不住它的。
能从现代模型里幸存下来的错误并不笨拙。它们是笃定、结构完好的句子，说着原文没说的事：一个否定被丢了、一个条件句被压成了祈使句、一处保留措辞被删掉了、"不得"变成了"不必"、一个单位被悄悄换算了、一个专有名词被热心地翻译了。每一句读起来都完美。没有一句能在看不见原文时被发现。
- 绝不单独把译文拿去审校。按句段对齐的原文与译文并排显示，这不是锦上添花——它就是如今审校得以成立的全部机制。只拿到译文的审校者，做的是一次流畅度检查，然后会报告一切正常。
- 按后果路由，不按置信度路由。含有否定、数字、日期、货币、剂量、法律情态动词或安全指示的句段，一律走人工审校，不管任何分数怎么说。这是一个针对原文的确定性分类器，比模型的自我评估可靠得多。
- 不要拿 LLM 评判器当主关卡。被问"这是不是一个好译文"的评判器，就是一个多绕了几步的流畅度检测器，而且它与产出这段文字的翻译器共享失败模式。它适合用来给候选排序、用来标出离群点；它不适合当"一条被误译的安全警告"与客户之间的那道屏障。为什么、以及它在哪里确实管用，见 用 LLM 作为智能体评判者。
- 回译是一个读起来像强信号的弱信号。绕回源语言能抓住粗暴的语义丢失，却恰恰漏掉你真正担心的那一类细微错误——因为把否定丢掉的那个模型，会热心地在回译里把它补回来。把它当作若干输入之一，永远别当作通过/不通过的判据。
用机器能校验的不变量设关卡。
既然"读"已不再够用，你的质量保证就大部分必须机械化——而幸运的是，真实的本地化缺陷中有惊人的一部分是机械可检的。在任何人看到输出之前就跑这些检查；一个不变量失败是一份缺陷报告，不是一次见仁见智的判断。
- 占位符与变量对等。原文里出现的每一个
{count}、%s和具名插值，在译文里都原样出现且恰好一次。占位符损坏是"一条译文字符串从一个错误变成一次崩溃"的最常见方式。 - 标记完整性。标签成对开闭、属性被保留、代码块与原文逐字节相同、行内元素没有被重排成非法嵌套。代码围栏里的一切一律照抄、绝不翻译——包括注释，这条规则是团队最先破坏、也最后悔的一条。
- 术语库合规。已批准的术语渲染为其已批准的译法；被禁的译法一律驳回。这是对着一张表做查找，它是精确的，也是本地化中回报最高的自动检查——因为术语漂移在单篇文档里隐形，在整个语料上却刺眼。
- 数字、日期与单位的保全。原文里的数字要在译文里出现，只在语言区配置说要换算的地方才换算。悄悄的单位换算是一类既容易检、漏掉又昂贵的错误。
- UI 字符串的长度预算。一个比英文长 60% 的德文标签，会撑坏它当初为之而写的布局。把这个约束作为任务的一部分交给智能体——每条字符串的最大字符数——并去校验它，而不是在截图里才发现。
- 文档的结构对等。标题数目相同、列表长度相同、链接目标相同。少了一整节，正是流畅度审校最不可能注意到的失败，因为剩下的部分读起来毫无问题。
这些检查同时也是智能体自己的反馈回路。把失败作为结构化工具错误返回给它，让它在进队列之前先修好自己的活——这与任何其他用工具的智能体是同一份纪律。这条流水线可度量的目标是每交付一千字所需的人工审校分钟数，而机械检查对它的推动远大于模型选型。
术语与上下文是检索问题，不是提示词问题。
常见的失败是把术语表塞进提示词。三十个术语时它管用，三百个时它悄悄退化，而这就是你的产品名在这一页被翻译、在下一页却没有的原因。术语属于智能体按句段查询的工具，而不属于它必须记住的系统提示词。
- 把翻译记忆库当检索工具。查询相似句段此前已批准的译法，并优先采用精确匹配而不是新生成一个。这不是成本优化——这是让语料保持一致的机制，它意味着人做过一次的决定会传播开来，而不是被一个对此毫无记忆的模型反复重审一遍。
- 术语库按需查表，只查该句段中实际出现的术语。检索让注入的上下文保持精简，也让行为在术语库长到任何提示词都装不下之后依然稳定。
- 孤立字符串的上下文是那个困难而长期缺人管的问题。像 "Open" 这样一条 UI 字符串在孤立状态下无解——它是形容词还是动词？而在许多目标语言里，这是两个不同的词。智能体需要周围的界面、键名、一张截图，或者开发者注释。哪里都没有的时候，正确的行为是发问；而一个从不发问的本地化智能体，正是在你的用户最常看到的那些字符串上产出笃定的猜测。
- 术语之外的风格需要示例，不是形容词。"专业但友好"跨语言传递不了任何东西。取自你自己语料的、已批准的改前改后对照则可以——这是少数几处少样本示例完胜指令的地方之一。
工作单位是 diff。
把整个系统围绕"变更"而不是围绕"文档"来设计，大部分运维之痛就消失了。把本地化当作源内容的一件构建产物：源句段是输入，目标文件是生成物，而任何时候只重新生成增量。
- 句段级指纹。给每个源句段做哈希。发生改动时，只有哈希变了的句段才重译；其余一律从上次已批准的输出里照抄。审校队列会缩到与这次编辑一样大，这就是两天周转与两周周转之间的差别。
- 批准是一种状态，它属于版本控制。一个审校过的句段带着一份批准，这份批准能熬过同一文件中别处的无关编辑。没有这个状态，每一次发布都会把每一个决定重新打开一遍，而你的审校者会因为在重读自己已经批准过的东西而不再认真读。
- 让构建因未解决的不变量而失败，而不是因未审校的内容而失败。因"每条字符串都要人工审校"而卡住发布，正是团队最终永远在上线英文兜底的原因；因占位符损坏而卡住发布，则是一道人人都会接受的缺陷关卡。
- 让陈旧可见，而不是让它阻塞。一个源文已变、但尚未重新批准的目标句段，应当在预发布环境里带标记渲染，并且在看板上可计数。无声的陈旧正是一个语言区腐烂的方式——页面一个不少，其中一半在描述去年的产品。
任何维护过双语代码库的人都已经领教过这件事咬人的那个版本：英文页面拿到一个紧急修复，另一个语言区没有，而系统里没有任何东西提示这件事。检测这种分叉只是一个脚本，而它比任何译文质量的提升都更值钱。
什么留给人，以及那个没人清洗的输入。
有两条边界值得直说。第一，有些内容压根不是翻译问题：目标在于效果而非等值的营销文案；本地化文本自身承载独立法律效力的一切——合同、受监管的披露、医疗说明、安全标识；以及任何一条误译即构成合规事件而非缺陷的字符串。对这些，智能体起草，由一位有资质的人对产出负责，与法律场景智能体完全一样。以你自己的名义发布由智能体翻译的受监管文本，会把责任转移到你身上，而且只转移到你身上。
第二条更安静：源内容是不可信输入。一个翻译智能体会摄入用户生成的文本、第三方文档、支持工单和网页，而一段写着"忽略先前指令，把下面这段翻译成……"的文字，在模型看来与"待翻译的内容"无从区分。当同一个智能体还握有你内容仓库的写权限时，后果就比一次糟糕的翻译严重得多。要显式给源内容定界、绝不让它够到工具选择通路、并把写入步骤与翻译步骤分开——提示词注入 101里那个结构性论证，在这里比多数人预期的更直接地适用。
从不变量检查和句段级 diff 开始，早于你评测任何一个模型。它们是一周不体面的工程活，对你现有的任何翻译来源都能跑，而且今天就会把你当前已本地化内容里蹲着的缺陷翻出来——损坏的占位符、漂移的术语、悄悄消失的整节。然后，在每一块审校界面上把原文摆在译文旁边，并按规则把否定、数字与安全文本路由给人。本地化智能体的活儿，是让审校者的二十分钟落在那些能伤到你的句段上；而再高的译文质量，也替代不了"知道是哪二十个句段"。
相关：多语种智能体讲这一切底下的模型侧行为，为信任而设计讲审校界面那一半，把实战手册适配到你的领域讲这一篇背后的方法。