在测试前明确决策目标
写下驱动决策的关键要素：语言对、内容类型、月翻译量、交付时效预期、术语需求、文档格式以及隐私限制。某款工具可能在通用散文上表现优异，但对于简短的界面字符串、受监管文档或术语密集的技术资料而言，未必合适。
在看到输出结果之前，先定义何为“成功”。有用的衡量指标包括：严重语义错误、术语一致性、格式恢复能力、每千词审校分钟数，以及发布前所需的修改次数。
构建具有代表性的源文本集
选取真实但非敏感的样本，涵盖标题、列表、数字、日期、人名、缩写、否定句、歧义短语以及重复出现的领域术语。样本集应足够小，以便进行细致的人工审查；同时也应足够广泛，以暴露不同的失败模式。
不要围绕那些看起来很容易的句子来调整样本。应包含措辞别扭的源文，以及少量语境会改变正确译文的段落。
执行受控翻译测试
对于所有参与对比的产品，使用相同的源文本、目标语言、术语表决策和文档设置。记录日期、产品界面、账户类型及相关设置，因为服务会随时间变化。
在初次审查时，尽可能保持输出结果的匿名性。审稿人对品牌的既有预期可能会影响其对风格的判断。
- 保留未经修改的源文件和输出文件
- 一致地使用相同的术语表或不使用术语表
- 记录确切的工作流程和日期
先审查语义，再审查风格
首先标记遗漏、增译、实体错误、数字错误、意思反转、否定失效以及术语错误。这些问题的后果远比审稿人是否偏好某个同义词更为严重。
随后评估流畅度、语域、重复率、标点符号以及受众适配度。将这两轮审查分开进行，能使结果更具实用性，并减少主观偏好的干扰。
纳入文档处理与运营适配性
如果工作流涉及文件处理，请测试标题、表格、脚注、说明文字、链接和页面顺序。既要测量修复布局所需的时间，也要测量编辑语言所需的时间。
从官方来源审查当前的定价、套餐限制、隐私条款、账户管理、支持服务、集成工作量及 API 行为。不要将旧的套餐细节带入新的评估中。
做出可回溯的决策
总结 DeepL 表现可靠的领域、人工干预仍然较高的环节，以及不应使用该工作流的内容类型。保留源文本集和评分方法，以便在产品或政策发生重大变更后重复评估。
经过衡量的决策可能会为不同任务分配不同的工具。标准化审查流程往往比强制所有翻译通过单一产品更有价值。