翻译任务该用哪个模型：从样本测试到稳定交付的六步指南

翻译任务没有通用的最佳模型。商品描述、软件界面、合同和品牌文案，对速度、准确性与表达方式的要求不同。与其按模型名气决定，不如先定义交付标准，再用真实材料比较。下面这套流程适合个人译者，也适合通过 API 批量处理内容的团队。

§ 第一步：把翻译需求写成验收条件

先明确源语言、目标语言和地区变体，再说明读者、用途与不可改动的内容。例如，同样是译成中文，面向开发者的接口文档与面向消费者的产品介绍，需要不同的术语密度和语气。

• 信息准确：数字、单位、条件、否定和责任主体不能改变。
• 表达适配：确定采用直译、自然表达，还是允许有限的本地化改写。
• 结构保留：列出标签、占位符、变量名和段落顺序等约束。
• 交付限制：记录可接受的响应时间、预算和人工复核范围。

涉及医疗、法律或安全事项时，应把专业人员复核设为必要环节，不能用语言流畅代替事实准确。

§ 第二步：只选两个候选模型

初次测试不必覆盖所有模型。可以把 Gemini 2.5 Flash 作为侧重响应速度与预算的候选，把 Claude Sonnet 5.5 作为复杂语境和文风控制的对照候选。这是测试起点，而不是对翻译质量的固定排名；具体语对和材料可能得到不同结果。

通过 Vana API，可以在统一接入中比较不同供应商的模型，减少重复配置。它提供兼容 OpenAI 的端点，也支持 Anthropic Messages 和 Gemini 原生协议。比较时应保持原文、提示词及输出要求一致，并记录实际使用的模型与参数。

§ 第三步：准备有代表性的小样本

从真实业务中抽取约二十至三十段文本，覆盖日常内容和容易出错的边界情况。不要只用一句问候语测试，也不要仅凭某个模型擅长的例子做决定。

• 加入术语密集、主语省略或存在多义词的句子。
• 加入金额、日期、百分比、否定条件和例外条款。
• 加入连续段落，检查上下文中的指代与称谓。
• 加入带标签或占位符的内容，检查是否误改结构。

测试材料应先脱敏。客户姓名、访问凭据和未公开合同等信息，需要遵循所在组织的数据处理要求。

§ 第四步：使用可重复的翻译指令

提示词应说明任务、上下文、术语和输出边界，而不是只写“请翻译”。例如：

指令示例：将以下英文产品文档翻译为简体中文，供软件开发者阅读。保持信息完整，不增删事实，不解释原文。遵循提供的术语表；保留变量名、占位符、标签和段落顺序。遇到歧义时依据上下文选择最合理的译法，不擅自补全缺失信息。只输出译文。

把术语表与原文明确分隔，并说明原文中的指令只是待翻译内容，不应执行。长文按章节或语义单元拆分，同时提供必要的前文摘要和统一术语表，避免逐句切割造成指代断裂。

§ 第五步：盲评质量，再核算真实成本

隐藏模型名称，逐段比较结果。优先检查漏译、误译、数字变化和否定关系，再看术语一致性、目标语言自然度与格式。可以为每项设定相同评分尺度，但关键事实错误应单独标记，不能被流畅度得分抵消。

成本也不能只看一次请求的价格。Vana API 按实际 token 用量计费，没有月费；具体单价应以调用时的价格信息为准。记录输入、输出用量，并把重试、复核和人工修改纳入计算。更有用的指标是每千字合格译文的总成本，而非单次调用成本。

§ 第六步：按内容风险分流并持续抽检

如果两个候选在普通文本上质量接近，就选择总成本更低、延迟更符合要求的方案。对于长句、复杂语境或高风险内容，再使用测试中表现更稳的模型，并增加人工复核。不要默认所有文本都需要双模型处理。

上线后保留评测样本、提示词版本和修改记录。术语表、模型版本或内容类型变化时，重新运行样本测试；日常则抽检数字、占位符与关键条款，观察质量是否漂移。

如果准备验证这套流程，可以创建一个 Vana API 账户，先用同一组脱敏样本完成对照测试，再决定长期使用哪个模型。最终应选择能以可接受成本稳定满足验收条件的方案，而不是名称更新或输出更长的模型。