1. 得先承认：AI翻译的能力已经过了“能用”这道坎
1.1 长难句、语序和跨段指代：以前的机器翻译玩不转，现在可以了
先说结论。我最近接手一批中英互译的技术文档，内容涉及API接口说明、部署指南和一段市场宣传文案。按照以前的经验，这种材料想翻得能交付，至少要经过“机翻、粗改、精校”三轮，而且机翻那一版基本只能用来当草稿。这次我抱着同样预期，先把一个比较绕的英文长句丢给大模型：Users who attempt to configure the service without enabling the required module will encounter an error that only becomes visible once the log level is raised to debug。
这句子结构是三层嵌套，旧式机器翻译大概率会翻成“用户谁尝试配置服务没有启用必需模块将遇到一个错误只有当日志级别被提高到调试时才可见”，中文语序完全没法读。这次大模型给出的译文是：“如果用户未启用必需模块就尝试配置服务，会遇到一个错误，不过该错误只有在日志级别调高到debug时才会显示出来。”整体语序调整得很自然，还自动把only becomes visible处理成了“只有……才”的转折结构。它不是字对字转换，而是先把主干拆出来，再重新组装成中文习惯的表达方式。
更让我意外的是跨段指代。翻译材料里有一段话，上段说的是某个配置项A，下段开头直接用this setting来做主语。旧式机翻往往会翻成“这个设置”，导致读者根本分不清是哪个设置。大模型在翻译时能够回溯前文，把this setting还原成“该配置项（即上文的A）”，或者用“这个开关”来承接。这种能力在几年前基本只能靠人工判断，现在AI确实已经有接近“读过全文再下笔”的处理效果。
1.2 风格控制和术语一致性：从“翻得对”到“翻得像人说的”
能力强不只是体现在语法层面，风格控制同样是一个重要变化。我现在可以让模型分别输出“正式商务版”和“口语化版本”，也可以用一段示例教它模仿某种文风。比如品牌宣传语Built for the messiest parts of your day，如果直译就是“为你一天中最混乱的部分而生”，句子没有错，但放在中文语境里很生硬。我要求模型按“广告文案语气”重译后，它给出“专治一天里最手忙脚乱的时刻”——这种处理已经不是纯粹的翻译，而是带上了本地化创作的成分。这就是为什么我说AI翻译已经从“翻得对”迈向了“翻得像人说的”。
术语一致性在长文档里尤其明显。过去用旧式机翻，同一份文档里module一会儿翻成“模块”，一会儿翻成“模组”，deployment一会儿是“部署”一会儿是“布署”，后期统一术语的工作量非常大。现在的主流大模型在对话上下文里天然会维持术语的统一——只要你在同一轮会话里连续翻译，它基本能记住前文用过的译法。而且我可以提前给它一份术语表，让它“凡遇到X一律译为Y”，实测下来一致性高了很多。
整体来说，我今天愿意把文章的开头定位成“先承认AI很强”，因为如果看不到它的强在哪里，后面关于“犯错”的讨论就容易变成无意义的吐槽。这个部分写到这里，就要开始讲反面了。正因为它在语言层面表现得过于自然，它犯的那些错误才更加隐蔽、更加需要警惕。
2. 翻车现场复盘：这几类错误我几乎每周都能撞见
2.1 语境误判：字面意思全对，实际意思跑偏
第一类典型错误是语境误判。英文里的Good luck with that，如果出现在对方正在做一个明显不靠谱的计划时，语气其实是讽刺，意思是“那你加油吧，我看你要完”。模型如果只看这一句话，通常会老老实实翻成“祝你好运”，情绪完全不对。上下文里如果没有足够明确的讽刺信号，AI很难识别出来——因为它在训练语料里见过太多种Good luck的正面用法，正面语义的概率更高。
再举个例子：That‘s a clever idea, really. 如果前文是某人提出了一个显然行不通的方案，这句话大概率是反话。我实测过多次，AI在缺少上下文时会翻成“这真是个聪明的想法”，带着真诚的赞扬语气；只有当我额外加了一句“说话者其实在讽刺”时，它才会改成“这主意可真聪明啊（反话）”。这个现象说明，模型对语气的判断高度依赖上下文提示，而真实场景中讽刺、反讽、夸张往往都隐藏在对话历史里。人类读者能靠常识识别，AI却不一定能把这些线索串起来。
这类错误难防就难在：字面上看起来完全通顺，语法没有问题，术语也没有错，唯一错的是发话者的真实态度。审阅的人如果对英文原文没有足够的敏感度，很容易被通顺的译文带着走。
2.2 文化负载词、双关和广告语：直译之后味道全无
第二类和文化有关。英文里的习语、典故、双关语，属于AI翻译最容易“直译翻车”的重灾区。Break a leg是“祝演出成功”，不是“摔断一条腿”。我第一次让AI翻译带这句的剧本片段时，它的输出是“祝你好运”——这一点倒是准确的，因为训练语料里这个习语太常见了。
但换成不那么高频的表达就麻烦了。比如It’s not rocket science，它可以翻成“这不是火箭科学”，也可以翻成“这不是什么高深莫测的事”。模型通常能选对后者。可如果遇到Let‘s not reinvent the wheel，它就可能在“不要重新发明轮子”和“别做无用功，沿用现成方案”之间犹豫。我见过它给出“我们不要再发明轮子了”，中文母语者看了会愣一下，虽然能猜到意思，但很不自然。
双关语、谐音梗更是无解。英文广告里那句经典的Get a lift with our new elevator，lift既有“电梯”又有“提气、振奋”的双关意思，中文几乎无法同时保留两个语义。AI通常的做法是选择一个主要语义，把另一个舍弃。负责任的做法是加注释说明原文玩了一个双关，但模型不会主动加——它只会默默牺牲掉那个梗。处理这类文本，我现在都不指望AI能翻出神韵，只要求它把表面意思翻出来，然后我自己再在括号里注明原文的双关意图，让读者知道这里原文是有梗的。
2.3 数字、单位和名称：自信满满的“硬错误”
比语义错误更危险的是数字和单位错误。这类错误没有半点含糊空间，错了就是事实性错误，一旦混进合同、规格说明书或者新闻稿，后果很实在。
我遇到过一个典型案例：The bridge spans more than 1.2 kilometers and carries about 200,000 vehicles per day. 模型翻成“大桥全长超过1200公里，每天承载约20万辆车。”前半句的“1200公里”当然是错的——1.2 kilometers是1.2公里，不是1200公里。这个错误就是因为模型在生成“1.2”和“公里”时，没有把数字和单位作为一个整体去做语义校验，它只是顺着概率把“1.2 kilometers”扩写成了“1200公里”这种在中文语料里更常见的量级。
还有一个我印象更深的：The budget for the project is 1 billion dollars. 模型翻成“项目预算是1亿美元”。凡是熟悉英文数字的人都知道，1 billion是10亿，不是1亿。这种错误一旦出现，财务数据的偏差是九倍，不是小事。单位换算同样容易翻车，miles和kilometers、pounds和kilograms、feet和meters，AI经常在原文不给出换算要求的时候直接硬换成另一套单位，而且有时候换算错了却保持相同的数值。
除了数字和单位，专有名词也属于高危区。人名、地名、机构名如果拼写和常见形式不一致，模型容易按自己的记忆强行“纠正”。比如一家叫Brightpath Health的机构，它可能一顺手翻成“光明之路医疗”，实际上很多机构名应该保留原文不译。我现在的原则是：凡是第一次出现的专有名词，默认要求AI保留原文，除非我明确告诉它某个词有约定俗成的官方译名。
2.4 否定、让步和潜台词：语气的隐形磨损
第四类错误藏在逻辑和语气里。英文中的否定结构对AI来说一直是个难点，尤其是not...until、hardly、seldom这类带有隐性否定含义的表达。
举一个翻车实例：Little did I know that the meeting had already been postponed. AI翻成“我几乎不知道会议已经被推迟了。”实际上Little did I know是一个倒装结构，意思接近于“我当时完全不知道”，语气上是后知后觉的感叹。模型给出的译文在准确度上已经偏离，中文读者会以为说话者只是“了解得不多”。我把这句丢给好几个模型，只有明确了“这里Little did I know表示强调，意思是当时一点都不知道”之后，才翻出“我当时哪里知道，会议早就推迟了”这种正常的中文。
还有让步语气。英文原文里常常用while表示“虽然”，用though表示转折，AI有时会把整句逻辑翻成并列关系。例如While the update reduces the file size, it significantly increases CPU usage，模型可能翻成“更新减少了文件大小，同时显著增加了CPU使用率”，原文的让步对比被削弱成了并列。中文读者读起来会觉得作者只是在陈述两个事实，没有读出“虽然……但是”的对比态度。这种语气磨损不会让译文看起来有错，但会让译文的准确度打折扣。
现在回到根本问题：这些错误并不是偶尔出现的小概率事件，而是由模型自身的生成机制决定的。理解这一点，你才能真正知道该怎么防。
3. 从模型机制看AI为什么“必犯这些错”
3.1 逐个Token赌概率：语言模型并不真正理解语义
先说最核心的机制。当下主流大模型的翻译能力，本质是在给定前文的前提下，逐个预测下一个语言单元（Token）的概率分布。它每生成一个词，不是先在脑子里确认好整句意思再写出来，而是“看一眼已经写出来的所有词，再赌下一个词最可能出现的是什么”。这个“赌”的过程非常快，而且因为训练数据足够多，大多数时候赌得很准，这就是它看起来懂语言的原因。但它本质上处理的是符号序列的统计相关性，而不是真实世界的语义指称。
这个机制能解释很多事情。为什么它会在“1.2 kilometers”上翻成“1200公里”？因为在它的训练语料里，“公里”前面的数字经常以“1200”这类大数值形式出现，它做的是模式匹配，不是数值换算。为什么它会把“Good luck with that”翻成正面语气？因为它见过的good luck大多用于真诚祝愿，讽刺用法在数据里占比低，概率排序上后者天然吃亏。它不是“判断失误”，而是没有在做判断，只是在做概率选择。
3.2 训练数据的偏好如何沉淀为翻译的偏见
大模型翻译能力的底座是海量双语语料，但这些语料本身是偏的。公开可获取的平行语料库里，技术文档、新闻、百科条目占了很大比重，文学作品、口语对话、方言俚语的占比就相对少。模型对技术类和新闻类文本的翻译自然更准，对幽默、调侃、文化梗的处理就明显吃力，这不是因为它不聪明，而是它见过的数据不够杂。
另一个数据层面的问题是：不同语言对在语料里的数量级不一样。热词里反复出现“ai大模型”“大模型ai”，大家可以注意到网上中文内容生成速度虽然快，但英文和中文的双语高质量对齐语料依然稀缺。大模型在英译中时，很多时候依赖的是“英文语料的语义理解加中文生成能力”，两者之间的转换模式其实没有得到充分校准。结果就是：它英文读得懂，中文也写得顺，但连接两者的时候会顺着自己的惯性走——比如把英文里常用的让步结构翻成并列结构，把计量单位直接沿用源语言而不做转换。这些偏差不是单一模型的问题，是整个数据生态的问题。
3.3 长上下文下的注意力稀释与幻觉高发
第三个机制层面的因素是上下文长度。现在的模型动辄支持几十万字上下文，但这不意味着它在处理长文档时能把每个细节都记住。注意力机制虽然强大，但在信息过载时会出现注意力稀释——开头提到的信息在翻译到后半段时权重被压得很低。我处理一份长文档时，明明前几段已经明确说了“本产品版本号为3.2”，到了文档后半部分，模型一不留神就把version 3.2翻成了“版本2.3”。这个错误没有任何语义难度，纯粹是它没把这么靠前的信息一路带过来。
更麻烦的是“幻觉”现象。当模型遇到一段它没把握的文本时，它不会老老实实标记“这里我不确定”，而是会顺着上下文生成一段流利但可能是编造的内容。翻译场景里，幻觉最常见的表现是：原文里根本没有提到某个数字或某个结论，译文里却出现了。我有一次拿一篇产品测评原文做测试，原文只写了“续航表现中等”，AI在译文里擅自补了一句“续航大约八小时”——八小时这个数字完全不在原文里。这就是典型的生成幻觉，而且因为整段译文读起来很顺，很多人根本不会去核对原文。
了解了这三点，你会明白一个必然结论：AI翻译的错误不可能被清零，它只会被控制。接下来分享我现在的应对流程。
4. 我当前的AI翻译工作流：多模型加人工审校的组合打法
4.1 把提示词当翻译需求文档来写，而不是直接丢文本
很多人用AI翻译是直接把一大段文本丢进去，然后复制译文。我现在的做法完全不同——我会把提示词当成一份“翻译需求文档”来写。
我的基础模板大致是这几条：
- 角色设定：你是一名具有十年经验的中英翻译专家，擅长技术文档和市场营销文案。
- 翻译方向：明确中译英还是英译中，避免模型自己猜。
- 风格要求：说明正式程度、目标受众。
- 术语约束：提供术语表，说明哪些词必须固定译法，哪些词必须保留原文。
- 句式要求：长句拆分到什么程度，是否允许调整段落顺序。
- 输出格式：逐段输出，段与段之间用分隔符隔开，保留原文中的标题层级和序号。
这样做的好处是减少模型的自由度。AI的自由度越大，创作性越强，但准确性越差；给它的约束越具体，它越能进入“翻译”模式而不是“创作”模式。我实测过，加了角色设定之后，模型在处理技术文档时引用专有名词的稳定性提升很明显，擅自加内容的现象也会减少。
还有一个关键操作：不要一次把整份文档全塞进去。分段翻译时，我控制在每次输入的文本量不超过两千字左右。这个容量既能保证上下文连贯，又不容易触发长文本注意力稀释。对于特别长的文档，我按章节分成多次任务，第一次先让模型通读全文并输出术语表，第二次再逐段翻译。先建立共同理解，再执行翻译，效果比一次性翻译好很多。
4.2 多模型交叉翻译：差异最大的地方就是风险最高处
“多AI协作”这个词现在很热，但我认为它在翻译场景里最实用、也最容易落地。我的做法是：对同一段原文，同时丢给两个或三个不同的大模型，得到多个译文，然后对比差异。
这里的核心原则是：如果多个模型翻译出来的结果高度一致，说明这段大概率没有风险；如果译文之间差别很大，那这里就是人工复核的重点。
举例来说，一份医疗科普文章里有一句Patients should take the medication with food to minimize stomach discomfort。模型A翻成“患者应在进食时服药，以减轻胃部不适”，模型B翻成“患者应随餐服用药物，尽量减少胃部不适”。两个译文意思接近，差异只在于用词习惯，这种情况我可以放心。
但如果某一句文化负载很重，两个模型给出的译文完全不同，我就知道这句存在语义歧义或文化差异，必须对照原文仔细判断。这个方法其实是在利用模型之间的独立错误来做交叉验证——每个模型有各自不同的训练数据和生成偏好，它们同时犯同一个错误的概率比单个模型犯错的概率低得多。差异点就是可疑点，人工只需要集中精力审可疑点，效率比逐字审校高很多。
4.3 译后人工必查的五个位置
无论AI翻译多快，我的译后人工审校环节始终保留，而且有一个固定的检查顺序。如果你只记住一份清单，我建议记住这五类：
第一，数字、单位、日期。这是我在前面反复强调的硬错误高发区。审校时我会专门把译文里的所有数字和单位单独列出来，跟原文一栏一栏对。不需要理解上下文，只看数值和单位是否严格一致。
第二，专有名词与官方译名。检查人名、地名、公司名、产品名是否保留了原文，或者是否有约定俗成的译名。特别要小心AI“过度翻译”——把应该保留的英文名硬翻成中文。
第三，否定与逻辑连接词。把not、hardly、seldom、unless、despite等词对应的中文部分圈出来，确认译文的逻辑方向和原文一致。这一步建议在脱离上下文的情况下做，只看字面逻辑。
第四，引语与对话中的语气。凡是原文里有直接引语的段落，都要对照检查说话者的态度有没有在译文中发生变化。讽刺、反问、让步这些情绪最容易在引语里丢失。
第五，格式和标记。技术文档里的代码、变量名、占位符、超链接，如果被AI翻译了，轻则读者看不懂，重则程序报错。我的规则是：所有代码块和变量名默认禁止翻译，出现一次就要求重译。
4.4 沉淀术语库和双语对照语料，让翻车概率越来越低
最后一点是关于工程化的。单次翻译任务做得再好，如果不沉淀，下一次还会遇到同样的问题。我现在每完成一个项目，会把AI翻错过的术语和短语整理成一个简单的双语对照表，格式就是三列：原文、错误译文、正确译文。
这个术语表有两个用途。第一，下次翻译同类文档时，直接把术语表贴进提示词，让模型避开以前踩过的坑。第二，积累几十个项目之后，这个表本身就是一份非常有价值的审校清单——在新的译文里搜索这些词，就能快速定位潜在错误点。这不是复杂的技术，但它是一种很实在的工程化方法，相当于给AI翻译加了一道越来越厚的防火墙。
说到防火墙，还有一个边界问题值得单独提出来。
5. 用AI翻译这么久，我最想提醒你的一件事
我最想提醒的是：AI翻译的错误不可怕，可怕的是它越来越会“用通顺掩盖错误”。早期机器翻译的错误一眼就能看出来，“机翻味”太重，你会本能地保持警惕；现在的AI译文已经流畅到接近人工水平，反而让人降低了怀疑心。我见过不少人直接拿AI译文发布，原因是“读起来很顺”，但恰恰是那些顺到像真话的句子，里面可能藏着完全相反的事实。
所以我的实际态度是：AI翻译适合当高效助理，但永远需要一个人来当最终责任人。技术文档、科普文章、市场文案这种风险可控的内容，我会大胆用AI提效；合同、医疗、法律、财务这类高风险文本，AI只做初稿，终审必须由懂行的人逐条核验。这个边界不是对AI不信任，而是对事实负责。
最后再分享一个具体的小技巧。我现在的默认工作节奏是：第一轮让模型通读全文并出术语表，第二轮分段翻译并用多模型交叉验证，第三轮人工检查上面说的五类必查点，最后一轮把全文粘贴回去让模型做一次“通读润色”，但要明确限制它“只许调整中文表达，不得改动事实信息”。这一步经常能发现前面漏掉的逻辑漏洞，因为AI在通读自己的译文时，对上下文矛盾的敏感度比逐段翻译时要高。这个流程看起来比直接丢文本多花几步，但它把翻车概率压到了我能接受的范围。如果你也依赖AI翻译干活，我建议从今天开始，至少把数字核查和多模型对比这两步加上，剩下的可以慢慢磨合。
