Make 17. PDF 翻译自动化：利用 Make 打造反思翻译工作流

引言

翻译这件事，单靠大模型直译已经能做到七八十分了。但如果你翻过整本书或者长篇论文就知道，直译出来的东西读起来总是差点意思——"很多周日我都会在附近的披萨店买一块披萨"，一看就是英文句式硬翻过来的。

我是翔宇。翔宇做跨语言内容时试过直译和反思翻译的效果对比，反思策略的译文质量提升肉眼可见。

问题不在模型能力不够，而在于翻译流程太粗。一遍过的翻译，没有反思、没有校对、没有文体适配，结果自然粗糙。人类译者的工作流是"初译 → 审校 → 润色"，大模型为什么不能也这样干？

这期视频我就搭了一套完整的反思翻译工作流。核心思路是借鉴严复的"信达雅"翻译理论，让大模型分三个角色依次处理：翻译专家出初稿、评审助手按信达雅三维度提改进建议、优化专家逐条应用建议出终稿。实测对比，终稿在通顺度和文学性上比初稿有明显提升。

你将学到

• 如何用 Jina Reader API 提取 PDF 全文并转为 Markdown
• 长文本自动切割的公式设计（处理中英文字符计数差异）
• OpenRouter 模块实现多模型自由切换的技巧
• 基于"信达雅"理论的三阶段反思翻译提示词体系
• Notion 属性驱动工作流分支（PDF 翻译 vs 文本翻译）
• 通过 Router 路由条件实现一个场景覆盖多个翻译场景
• 改进建议数量的动态计算公式，避免大模型胡编乱造

视频教程

本教程配套视频已发布在 YouTube，建议搭配视频一起学习效果更佳。

详细教程

工作流整体架构

整套工作流分为两条路径，通过 Notion 知识库的状态字段自动切换：

PDF 翻译路径：Notion 监听（状态=开始 PDF）→ Jina Reader 提取 PDF 全文 → Repeater 文本切割 → Set Variable 截取片段 → OpenRouter 整理 Markdown → OpenRouter 初稿翻译 → OpenRouter 信达雅反思评审 → OpenRouter 终稿优化 → Google Docs 保存 → Notion 更新状态

文本翻译路径：Notion 监听（状态=开始文本）→ OpenRouter 初稿翻译 → Notion 保存翻译结果

两条路径共用一个 Notion 监听模块，通过 Router 的条件判断自动分流。这样一个场景就覆盖了日常所有翻译需求。

Notion 知识库设计

这套工作流的输入和输出全部通过 Notion 管理。知识库属性设计如下：

几个设计要点：

状态驱动分支：通过"开始 PDF"和"开始文本"两个状态值，Router 自动判断走哪条路径。不需要为两种场景分别建工作流。

模型名称必须精确：Select 选项的值直接映射到 OpenRouter 的 model 字段，所以必须和 OpenRouter 官方的模型 ID 完全一致，比如 openai/gpt-4o-mini 或 anthropic/claude-3.5-sonnet。

文本粒度控制翻译质量：长文本选 1000（效率优先），短文本选 300 或 100（质量优先）。粒度越小，每次翻译的片段越短，大模型处理得越精细。

第一步：PDF 文本提取

用 Jina Reader API 的 HTTP 模块提取 PDF 全文。Notion 的"文件和媒体"属性会提供一个 PDF 的 URL，直接传给 Jina Reader，返回 Markdown 格式的全文内容。

注意：Notion 免费版有 5MB 文件大小限制。超过的 PDF 可以先用 iLovePDF 在线压缩。

第二步：长文本自动切割

这是整个工作流最精妙的部分。一篇 PDF 可能有几万字，大模型的输出 Token 有限，必须分段翻译。

核心用到两个模块：Repeater（重复器）和 Set Variable（变量设置）。

Repeater 模块决定"分成几段"。公式逻辑：

ceil(length(Content) / 文本粒度)

length() 返回文本的字符总数，除以文本粒度（比如 1000）再向上取整，就是需要重复的次数。比如全文 9000 字符、粒度 1000，Repeater 就重复 9 次。

这里有个陷阱：length() 对英文返回的是字母数，不是单词数。"Hello" 返回 5 而不是 1。所以英文文本需要修正——假设平均每个单词 6 个字母，粒度要乘以 6。我用 contains() 函数判断源语言是否包含"中"字来自动切换：

• 中文源语言：直接除以文本粒度
• 英文源语言：除以（文本粒度 x 6）

Set Variable 模块决定"每段取哪部分"。用 substring() 函数截取：

substring(Content, (i-1) * 粒度, i * 粒度)

其中 i 是 Repeater 当前的迭代次数。第一次取 0-1000，第二次取 1000-2000，以此类推。

第三步：Markdown 格式整理

文本片段先经过一个 OpenRouter 模块做格式清理：删除页眉页脚页码、清理空行、保留原文语言不翻译、转换为标准 Markdown 格式。这一步保证后续翻译模块拿到的是干净的结构化文本。

第四步：初稿翻译

第二个 OpenRouter 模块执行初稿翻译。系统提示词定义了一个"资深跨语言翻译专家"角色，核心要求：

• 识别文本类型（技术文档、文学作品、法律文件等），选择对应的翻译策略
• 遵循"信达雅"标准
• 保留专有名词原文，不音译
• 参考术语表确保术语一致性
• 本地化处理（货币、日期、度量单位）

提示词中动态映射了 Notion 知识库的源语言、目标语言和术语表字段，实现真正的参数化翻译。

第五步：信达雅反思评审

这是整套工作流的核心创新。第三个 OpenRouter 模块扮演"翻译评审助手"，基于严复的信达雅理论对初稿进行三维度审阅：

• 信（Faithfulness）：译文是否准确传达原文内容和意图
• 达（Expressiveness）：译文是否通顺流畅，符合目标语言习惯
• 雅（Elegance）：译文是否语言优美，风格得体

评审模块不直接修改译文，而是输出一份改进清单，每条建议包含问题描述、原译文和改进后译文。

改进建议的数量通过公式动态计算：

ceil(文本粒度 / 50) + 6

1000 字粒度对应 26 条建议，500 字对应 16 条。这个数值是经过实测调整的——如果要求太多（比如 150 条），大模型提不出那么多有效建议，就会开始编造无意义的内容。

实测效果举例：

第六步：终稿优化

第四个 OpenRouter 模块扮演"翻译优化专家"，接收三个输入：原文、初稿、改进清单。严格按照改进清单逐条应用修改，输出最终译文。

关键约束：只能按照改进清单修改，不能自行添加未列入清单的调整。这保证了修改的可控性和可追溯性。

第七步：保存与遍历

每个文本片段翻译完成后，结果追加到 Google Docs 文档中。所有片段遍历完成后，更新 Notion 状态为"已完成"。

Google Docs 在这里的作用是充当长文本的存储——Notion 的文本属性有 2000 字限制，而 Google Docs 没有。

文本翻译分支

下方的文本翻译路径很简单：直接从 Notion 读取"翻译的文本"字段，经过一个 OpenRouter 模块翻译，结果写回"翻译的结果"字段。适合翻译短段落或单句。

Router 的条件设置：上方路径要求状态包含"PDF"，下方路径要求状态包含"文本"。

OpenRouter 模型切换技巧

OpenRouter 支持数十种大模型，通过统一的 API 格式调用。在这套工作流中，模型名称存储在 Notion 的 Select 属性里，直接映射到 OpenRouter HTTP 请求的 model 字段。

切换模型只需要在 Notion 里改一下下拉选项，工作流中的所有 OpenRouter 模块自动跟随切换。追求性价比选 GPT-4o-mini（百万 Token 不到十元），追求效果选 Claude。

延伸阅读

• Make 18. 跨境电商必备：Make 与 RAG 打造文章自动化创作工作流
• Make 20. Make 工作流改造方法论：一个工作流如何变成 1000 个工作流？

常见问题

Q：反思翻译比直接翻译好多少？
实测对比，终稿在"达"和"雅"两个维度上有明显提升。初稿往往有直译痕迹（"很多周日"），终稿会自动调整为中文自然表达（"经常在周日"）。对于文学性要求高的文本效果最明显，纯技术文档提升较小。

Q：反思模块可以叠加多轮吗？
可以。我在小报童中分享了"信达雅三轮分别反思"的版本——信反思一轮、达反思一轮、雅反思一轮，每轮 20 条建议，共 60 条。轮数越多效果越好，但 API 成本也成比例增加。根据实际需求选择。

Q：除了翻译，反思机制还能用在哪？
任何需要"初稿→优化"的场景都可以套用。比如去 AI 味道的文章改写、模拟特定写作风格、学术论文润色。只需要替换中间的反思提示词，初稿和终稿模块的逻辑不变。

Q：PDF 提取出来格式乱怎么办？
Jina Reader 对大部分 PDF 的解析效果不错，但扫描件或复杂排版的 PDF 可能有问题。第一个 OpenRouter 模块（Markdown 格式整理）会做一轮清理。如果效果还不理想，可以考虑用 Kimi 的 PDF 解析 API 替代 Jina Reader。

总结

这套工作流的核心价值不在于翻译本身，而在于"反思机制"这个模式。通过初稿翻译、信达雅评审、逐条优化三个阶段，大模型从"一遍过"变成了"三遍打磨"，翻译质量有了质的提升。同时通过 Notion 属性驱动模型选择、文本粒度、源目标语言等参数，一个工作流就覆盖了日常所有翻译场景。

这个反思机制不只适用于翻译。任何"初稿 → 优化"的内容生产场景——写作、改写、润色——都可以套用同样的三阶段架构。

下一期我会分享跨境电商的文章自动化创作工作流，教你用 Make 和 RAG 打造内容生产线。

资源下载

• AI 编程实操课：国内版-FlowUS | 国际版-BMC
• YouTube 频道：翔宇工作流