1. 为什么单次 AI 翻译还不够稳定？

我平时会高频使用 LLM 来处理日语/英语翻译。最开始使用的方法很简单，跟传统的机械翻译一样：输入原文，让模型直接输出译文。这个方法很简单而且效率很高，我认识的人多数都会使用这个方法。

在模型选择上，尤其是使用 Flash 模型，刚输入完原文过几秒译文就出现了。速度虽然很快，但产生的译文只能作为参考，如果要投入到生产中还需要大量的人工修改。

单次翻译很难稳定解决漏译、术语一致性和语气控制等问题。后来我开始使用反思工作流，把翻译、审校和最终整合拆成几个环节，由不同节点各自处理。我发现通过这个思路构建的工作流产生的译文质量明显比单次翻译的好。

2. 吴恩达的 Translation Agent 思路

在后续的使用和学习中，我发现了吴恩达的 Translation Agent 这个项目。

https://github.com/andrewyng/translation-agent

它的核心是三步：初步翻译 ➡️ 反思与评价 ➡️ 改进与润色。我借鉴了这个项目的思路，在 Dify 中构建了一个自己的反思工作流。

3. 个人工作流总览

4. 每一阶段的设计思路

这个工作流就是把翻译任务拆分成不同阶段：输入、文本切片、知识检索、初译、反思、合并。每个阶段只负责一类明确的任务，这样可以减少长文本翻译中的各种问题。

4.1 输入阶段

工作流的起点，我会设置几个基础变量：

• source_doc：需要翻译的文件
• source_text：需要翻译的文本
• source_lang：原始语言
• target_lang：目标语言
• country：目标语言的国家或使用场景

这个节点的变量是让后续所有节点知道“文本从哪里来、要翻译成什么语言、面向的国家或者使用场景是什么”。在翻译实践中，经常有一个误区就是：中文就是中文，英语就是英语，法语就是法语。但实际上不同国家或者地区的同一语言是有些许不同的。打个比方，同样的英语翻译为中文，面向中国大陆的中文、面向港澳台地区的中文以及面向新加坡的中文是不一样的，部分用词和语气可能都不同；同样的日语翻译为中文，面向商品资料、客服邮件、技术说明的不同情况时，表达方式也都是不一样的。这也是 LLM 相比于传统的机器翻译的优势之一：可以使用 Prompt 来自定义输出的风格。

这个节点主要是确定翻译任务的各种条件，避免模型自由发挥。通过变量传递，更好地让模型遵守语言和地区的设定。

4.2 文档提取阶段

这一阶段主要是检测输入的是纯文本还是文档，如果检测到文档就使用特定的功能来提取文档内的内容。也就是把source_doc转换为文本。如果输入的是source_text，那就会直接跳过这一阶段。

这一阶段没有任何 LLM 参与的内容，主要都是程序自动转换。需要注意的是，常规的翻译接触到的可能都是 Word、Excel 等带有复杂格式的文件，这类就不适合直接输入到工作流中让程序自动转换。这类最好使用 CAT 软件来提取文档内容，然后再输入到工作流之中。CAT 软件最大的优势就是格式保持。

4.3 变量聚合阶段

文档或者文本经过上一个阶段后，会进入变量聚合器。它可以把文档中提取出来的文本或用户直接输入的文本统一成一个新的变量。使用这个新的变量将文本继续传递下去。这一目的是让后续的节点只需要接受一个统一的文本，而不需要关心这些文本是由文档输入的还是文本输入的。

概括一下：

如果用户上传了文档，则使用文档提取器提取文本。（上一节点）

如果用户直接输入了文本，则直接使用用户输入的文本。

将统一后的待翻译内容命名为source_content

这一步虽然很简单，但对于自动化工作流来说是很有必要的。它让整个流程可以兼容短文本、长文本和文档内容。

4.4 文本切片阶段

这是第一个代码执行节点。在这个节点会使用代码将上面输入的文本按照段落进行切片，我使用的是 Python 来处理这部分内容。这样做的原因是模型在处理长文本翻译时很容易出现这几个问题：上下文注意力分散，后半段质量暴跌，格式混乱，术语前后不一致等问题。虽然现在的 LLM 的上下文都很大了，但随着上下文内容的增多，模型更容易出现注意力分散和精度下降的情况。按照段落切片后，每一段都可以进入独立的翻译、反思和合并流程。每个小切片更容易让模型稳定处理，也方便后续逐段检查。

切片的原则如下：

• 优先按照正常的段落切分
• 保留标题和正文的相邻关系
• 控制每个切片的长度
• 避免把同一句话或者同一个列表切散
• 给每个切片保留顺序编号

4.5 知识检索阶段

这个阶段使用的是迭代节点。切片会逐个经过知识检索节点。这个节点会根据当前段落的内容，从知识库中检索相关术语、固定译法、背景信息或者一些翻译规范，然后把这些信息作为备注一起输入给下一节点。

利用 LLM 进行翻译很令人头痛的一点就是术语不统一。比如，A 在某个行业应该翻译为 B，但由于 A 在其他行业可以翻译为 C，所以 LLM 把这个 A 翻译为了 C，这就导致译文前后容易不一致。

知识节点可以添加下面的文本内容：

• 各类术语
• 产品名称
• 固定表达
• 品牌名称
• etc.

这个节点涉及到了知识库维护的内容，需要使用 Embedding 模型。由于这篇文章主要分享的是工作流思路，故不涉及这部分的内容。

4.6 术语去重阶段

知识检索阶段过后，工作流会进入第二个代码执行节点。这部分我也使用的 Python 进行处理。主要是对上一个节点的内容做去重和整理。在长文本的情况下，知识检索很大概率会检索到多个相似条目，出现很多重复术语。直接把这些内容交给 LLM，更容易导致混乱而且增加不必要的 API 花费。

这部分代码的主要工作内容如下：

• 删除重复术语
• 保留优先级更高的译法
• 保留和当前段落最相关的术语
• 控制术语参考的长度

4.7 LLM 1：初译阶段

这一阶段终于开始进行翻译了，它负责生成第一版译文。这个阶段的目标是准确且完整地把原文翻译为目标语言。它不需要过度的润色，也不需要改动原文的结构。在我的实践中，第一版译文越是稳定，后面的反思和合并节点就越容易发挥作用。

在模型的选择上，不是需要严谨表达的文章可以选择参数量比较小的模型以平衡成本，比如各类 Flash 模型。

这一阶段的 Prompt 的重点如下：

• 忠于原文
• 保留全部信息
• 参考传递的术语参考内容
• 保留原文的格式
• 根据目标地区调整用词

4.8 LLM 2：反思阶段

这一阶段需要对上一阶段的翻译质量进行检查。这个节点需要同时读取原文、初译和输入的术语参考内容，然后从中发现问题并提出修改意见。

这个阶段重点是发现问题，所以我会要求模型输出结构化的审校意见，而不是在初译的基础上重写译文。结构化的输出更容易被后面阶段利用，也方便人工审查时思考哪些意见值得采纳。在翻译实践中，很多译文看起来通顺，但很多问题在对照原文的情况下才更容易发现。

在模型选择上，我建议选择性能最好的模型，这个阶段是最重要的。比如选择 Claude Opus、Gemini Pro、ChatGPT 带思考的系列。

这一阶段的 Prompt 的重点如下：

• 对照原文来检查初译
• 找出其中的问题
• 检查术语是否符合参考内容
• 检查语气是否符合场景
• 检查文章格式
• 给出具体的修改建议以及理由

4.9 LLM 3：合并阶段

这一阶段会根据原文、初译和反思节点给出的建议，生成最终的译文。这个阶段由 LLM 做取舍，采纳或舍弃建议。目标是输出一版准确、自然、更适合交付的译文。

这一阶段的 Prompt 重点如下：

• 以原文为准
• 参考初译和反思意见
• 采纳合理建议
• 保留术语一致性
• 输出最终译文
• 避免引入新的信息

4.10 输出阶段

每个切片完成直译、反思和合并后，工作流把所有切片按照原始顺序重新汇总，输出完整译文。这一阶段还是需要人工审查，避免长文本输出错误。我会着重检查顺序、否定句、条件句、专有名词、产品规格，这些内容出错的话会比表达错误产生的问题更大。

5. 这个流程适合哪些翻译场景？

5.1 技术文档与产品说明书

这类文章通常包含大量行业专有名词、公司的内部表达、产品规格，单次翻译很容易出错。

5.2 跨境电商营销文案与独立站

可以通过这个工作流针对不同国家的消费者调整语气，既要说服力强，又要包含特定的 SEO 关键词。可以利用这个工作流将原文译为有本土吸引力的文案。RAG 可以确保品牌名和核心卖点不被错误翻译。

5.3 商品资料与本地化 QA

商品标题、规格参数、卖点描述和客服话术都对术语一致性有较高要求。通过这个思路也可以让译文的准确度、风格和品牌惯用表达上更加稳定。

6. 成本、限制和质量风险

这个工作流可以一定程度上提升译文的稳定性，但它会带来额外的成本。相比于单次翻译，即：「输入原文 ➡️ 直接输出译文」的方式，反思工作流至少会经历初译、反思、合并三个阶段。整个流程的 token 消耗、处理时间和调试成本都会明显增加。

因此，这个流程更适合有一定质量要求的文本，例如上面提到的技术文档、产品说明书、商品资料、本地化内容等。对于非常短、风险很低、只需要快速浏览的文本，单次翻译通常是足够的。反思工作流的价值主要体现在「需要交付质量」的场景，而不是所有翻译场景。

虽然我们都会在三个不同节点中通过 Prompt 来限制 LLM 的行为，但也有概率出现问题。比如 LLM 2 的反思节点过分挑刺，LLM 3 的节点产生了新的额外内容等情况。因此即使是这种自动化工作流，在面对要求非常严格的场景时，人工审查仍然是必要的。

还有一点是切片容易带来的上下文断裂。上文的节点中其实可以在某个节点内添加「概括段落」的内容，然后一起输出给翻译节点，这样翻译节点会获得前后的上下文，上下文一致性会更好。切片的目的是降低模型的处理压力，提升精度，但切片切得太碎的话依旧会降低稳定性，使用时需要自己找到其中的平衡。

这个工作流最核心的依旧是 LLM 自身的能力。如果你使用三个很差的模型，那产生的结果可能好不到哪里去。目前的顶尖模型在面对翻译的场景下通常表现是不错的，有效上下文也随着模型迭代不断增加。在我的实践中，我认为通常要保持 LLM 2、LLM 3 这两个使用了顶尖模型，这样这个工作流才会更稳定一些。

对于 LLM 来说，面对不同语言情况选择不同模型也是有必要的。比如 Claude、Gemini、ChatGPT 这几个国外模型，它们训练时使用的中文语料相比国内的模型少很多，在面对中文相关翻译时表现可能不会很好。因此也需要使用者充分了解各个模型的优势，才能够让输出的译文更加稳定。

7. 让 AI 翻译变为可控流程

对我来说，现在 LLM 的价值不只在于「翻译得更快」，更在于它可以参与到审校、改写、术语整理和质量检查等环节中。只要把任务拆分清楚，并在关键位置保留人工判断，AI 翻译就可以从一个临时工具，变成一个稳定的内容处理流程。都说未来 2026-2027 是 Agent 爆发增长的时期，相比于 OpenClaw 这类个人助手，我感觉类似的工作流可能会更好地帮助我们工作和生活。

这个工作流也可以迁移到其他的场景中，背后的核心就是把复杂的文本任务拆分为明确的步骤，再通过工具和人工复核共同提高最终交付质量。