机器翻译译后编辑怎么做？MTPE 流程、错误分级与交付标准

机器翻译已经读起来很顺，为什么还需要译后编辑？因为流畅与准确是两件事。译文可能语法完整，却遗漏限制条件、改变否定关系，或者把“预计”写成“保证”。这种错误往往比明显的错别字更难被快速阅读发现。

MTPE，即机器翻译译后编辑，是在原文和交付要求的约束下检查并修正机器译文。它不是单纯润色，也不意味着所有机器输出都值得逐字修补。本指南围绕任务分级、错误判断、编辑顺序和可追踪交付，建立一套可实际执行的流程。

一、先定义译文用来做什么

同一段内容用于内部浏览、客服答复和公开帮助中心，接受标准可能不同。项目开始前，应明确受众、发布范围、术语要求、格式要求，以及哪些错误绝对不能进入交付物。不要只写“达到专业质量”。

团队可以约定轻度编辑和完整编辑，但必须写出各自范围。前者也不能放任影响理解的意义错误；后者则可以进一步要求自然表达、风格一致和适用的版式检查。名称本身不是标准，也不能用来宣称获得任何认证。

欧盟委员会关于其网站机器翻译的说明提醒，质量会随文本和语言方向变化。这也是工作流应以实际内容验收，而不是以“已经调用翻译工具”作为完成条件的原因。

二、在编辑前检查源文和初稿

先确认源文件版本，查看是否存在缺句、未定义缩写、事实冲突或混乱的格式。源文无法确定含义时，应向内容负责人提出问题；不要要求译后编辑者凭经验补齐业务事实。

抽取少量代表性段落判断机器初稿是否可用。若出现大量结构错位、意义颠倒或不适合的语言方向，重新翻译可能比逐段修补更可靠。是否重做应根据实际编辑工作量判断，不要为了证明机器翻译有价值而保留一个劣质起点。

同时确认占位符、链接、表格和文件结构是否完整。被截断的响应或错位的段落需要先恢复结构，再进入语言审校，否则编辑者可能把正确译文放到错误的原文位置。

三、按后果区分错误等级

这是一种项目可调整的示例分级，不是通用行业评分公式。错误后果取决于用途：一个按钮动词的误译可能直接导致错误操作，而某个宣传形容词的不同选择未必构成缺陷。

记录问题时，应包含原文位置、当前译文、问题类型、理由和建议。只留言“翻得不好”无法帮助下一位编辑者判断，也难以用于改进术语表和测试样本。

四、第一轮只核对意义和事实

先按句段对照原文，检查主语、动作、对象、条件、范围、时间和否定。确认没有多译、漏译或未经授权的解释。自然表达可以暂时放在后面，避免一边润色一边忽略关键事实。

例如原创句子“We may extend the trial after review”应保留“审核后可能延长试用”的条件和不确定性。若改成“审核后将延长试用”，语气更顺畅却改变了承诺。审校重点不是哪句话更好听，而是哪句话忠实表达了原文。

数字也需要结合关系检查。“不超过 10 个成员”和“至少 10 个成员”包含相同数字，却给出相反限制。只运行数字一致性脚本不能发现这种问题，必须阅读数字所修饰的条件。

五、第二轮处理术语与表达

在意义确认后，统一产品名、界面标签和已批准术语，再调整目标语言的句式与衔接。源文过长时可以合理拆句，但应保留逻辑关系，避免把条件从句变成独立承诺。

不要为了展示编辑工作而改写所有句子。正确、自然且符合项目风格的内容可以保留。对可接受的同义表达反复修改，会增加成本，也会让团队难以区分必要修正与个人偏好。

发现术语表缺项或冲突时，先记录候选决定并提交审批。不能一边编辑一边各自创造译名，再期待最后一轮审校自动解决全部不一致。术语治理可参考术语表指南。

六、第三轮检查结构和目标环境

检查占位符、链接、列表层级、表格对应和代码保护。对于界面文案，还应查看真实页面上的截断、换行和按钮长度；对于文档，检查目录、脚注和页眉页脚。编辑器里正确的文字，不一定在最终载体里完整显示。

自动化适合发现缺失变量、重复 ID 和无法解析的文件；人工适合判断指代、语气和事实关系。把两者分工清楚，避免把“自动检查通过”误写为“翻译已经正确”。

若版式调整需要缩写或删减，应重新核对意义。不要在最后排版时删除限制条件，却沿用此前已经批准的状态。任何改变含义或重要信息的修改，都应重新进入相应复核环节。

七、用风险决定复核范围

新的语言方向、变化较大的源文、重要承诺和关键操作提示，值得更严格的复核。历史上稳定的低风险内容可以采用项目约定的抽样方式，但抽样通过不代表未检查部分不存在错误。

发现严重问题时，应扩大检查到具有相同错误模式的内容，例如同一模板、同一术语规则或同一批次。只修复被抽中的一句，可能留下其他相同问题。扩大范围的依据应记录下来，而不是依赖临时感觉。

需要第二位审校者时，给对方提供源文、初稿、修改记录和未解决问题，不要只交付一份看似完美的目标语言文本。没有原文的通读，主要能检查表达，无法可靠判断是否忠实。

八、记录成本，不预设固定折扣

译后编辑耗时受初稿质量、领域难度、格式复杂度和交付要求影响。不能仅因为使用机器翻译，就预设所有项目都能按同一个比例节省费用或时间。

可以分别记录机器生成、源文澄清、意义修正、术语处理、排版与复核时间。再与同类内容、同一标准的其他流程比较。若大量时间花在定位原文和修复文件，问题可能是工具流程，而不只是语言能力。

统计修改量也要谨慎。改动少可能说明初稿好，也可能说明审校不足；改动多可能是必要修正，也可能是无意义的风格改写。应结合缺陷和返工结果解释，不能孤立使用字符差异作为绩效指标。

九、让交付结果能够追溯

交付包应明确源版本、目标语言、编辑范围、术语版本、已解决问题和未解决事项。只有符合项目发布条件的内容标记为已批准；不应把待确认段落藏在最终文件中，期待收件人自行发现。

保留必要的修改记录，并把批准后的句段写入合适的翻译资产。未经审校的机器初稿可以作为历史输入保存，但不应与正式记忆库混为一谈。相关区别见记忆库、术语表与缓存对比。

TranslateHub 可作为文档化能力范围内的翻译调用环节，具体以开发者文档为准。人工审批、文件结构保护和发布责任仍需要在业务工作流中明确，不能因为接入 API 就视为自动完成。

十、常见问题

译后编辑就是润色吗？

不是。润色主要改善表达，译后编辑首先要对照原文修正意义、遗漏和错误。只看目标语言是否流畅，无法完成这个任务。

机器初稿很差时必须继续编辑吗？

不必。可以先做代表性样本评估，再决定重新翻译、换用更合适的方法或直接人工处理。应以交付质量和总工作量为依据。

轻度编辑可以保留意义错误吗？

不应保留影响既定用途的错误。可以减少不必要的风格调整，但必须明确接受标准，不能把“轻度”当作不检查事实的理由。

能否只抽查而不逐段审校？

取决于风险和合同约定。抽查可以支持质量评估，但不等于所有内容都已审校；交付时应如实说明范围，并为发现系统性问题预留扩大检查的流程。