我给 Notion 博客加了一套 AI 翻译流程
我给 Notion 博客加了一套 AI 翻译流程
我的博客以中文为主，内容放在 Notion 中维护。为了让英文和日文读者也能阅读，我给网站加上了多语言支持。
多一种语言，就意味着多一份需要维护的内容。文章第一次发布时可以手动翻译，但之后改了一个说法、补了一段解释，其他版本也要跟着更新。时间久了，很容易出现中文已经改过，译文还停留在旧版本的情况。
所以，我希望继续只在 Notion 中维护中文原文，把其他语言的更新交给后台处理，同时保留人工检查和修改的空间。
这套流程大致是：
在 Notion 中发布或修改中文内容
↓
后台检查新增内容和变化
↓
调用 AI 生成英文、日文译文
↓
校验结果，保存到 GitHub 仓库
↓
触发部署，更新网站
先生成译文，再提供给读者
我选择在后台提前生成译文。读者切换到英文或日文页面时，网站直接读取已经保存好的内容。
这样做有几个实际的好处。读者不需要等待模型生成，同一篇文章也不会因为被反复访问而重复调用翻译 API。译文保存下来以后，还可以检查、修订，并通过 Git 追踪变化。
相应的代价是，中文原文更新后，其他语言版本需要经过检查、翻译和部署才能同步。如果翻译任务失败，更新也会延后。
对于个人博客，我可以接受这个时间差。文章发布和修改的频率有限，提前准备好可供阅读的版本，更符合我的使用方式。
让 AI 处理文字，让程序保留结构
我的文章来自 Notion，一篇文章里除了正文，还可能有标题、列表、链接、图片和代码块。
翻译时，程序会遍历这些内容，提取需要翻译的文字，例如标题、段落、图片说明和 SEO 描述。Notion 的块结构、文字样式和链接地址则由程序保留。模型返回译文以后，再把文字填回原来的位置。
目前，翻译接口默认指向 DeepSeek，具体使用哪个模型由环境变量配置。提示词会要求模型保留作者语气、技术含义和格式，并按照固定的 JSON 结构返回结果。
我还放了一份简单的术语表，用来统一“大语言模型”“智能体”“提示词”等词的翻译。它无法解决所有表达问题，但能减少同一个概念在不同文章里出现多种译法的情况。
改一段，尽量只翻译那一段
如果只是修改了文章中的一个段落，重新翻译整篇文章会带来额外开销，也可能让原本已经满意的其他段落发生变化。
为此，我给内容增加了指纹比较。程序会检查整篇文档是否变化，再比较各个文字块。未变化的部分复用原来的译文，变化的部分才重新请求模型。
这个比较也会考虑目标语言、术语表和模型配置。因此，更换模型或调整术语表后，即使中文没有变化，也可能需要重新生成译文。
分块处理也有局限。模型每次看到的是当前文字块和术语表，上下文比阅读整篇文章少。一些跨段落的指代、语气和术语，仍然可能需要人工调整。节省重复翻译的同时，也要留意这种拆分对质量的影响。
翻译失败时，保留已有版本
调用外部模型会遇到超时、限流和返回格式错误，翻译任务不能假设每次都顺利完成。
目前的实现会对部分错误进行重试，并在每个文字块完成后保存进度。后续再次运行时，可以复用已完成且仍然有效的结果。
一篇文章只有在所需内容全部翻译完成后，才会替换已发布版本。中途失败时，读者仍然可以阅读上一份完整译文。如果文章还没有译文，页面会回退到中文，并显示提示。
程序也会做一些基本校验：返回的文字数量是否正确、是否存在空内容、原文中的代码和链接是否被改动。
这些检查能减少格式损坏，却无法判断一句话是否自然、含义是否准确。通过程序校验，只代表结果满足了发布所需的结构要求。
给人工修订留一个入口
我给这套流程做了一个管理后台，可以按内容和语言查看翻译状态、发起任务，以及修订译文。
对于已经人工调整好的内容，可以进行锁定。当对应原文发生变化时，系统会标记为待审核，等待人工决定如何更新。
这能保留一些自动翻译难以替代的判断。比如一句中文在英文中是否应该换一种说法，日文表达是否过于生硬，或者某个技术概念是否需要额外解释。这些问题，仅靠格式校验无法解决。
后台也支持定时检查。开启后，任务会按照设置的频率扫描已发布内容，寻找缺失或需要更新的译文。手动检查则适合刚发布文章、希望尽快同步其他语言的时候。
接下来要观察的，是译文质量
目前，这套实现把内容读取、翻译、保存和发布串成了一条可以重复执行的流程。正文译文保存在仓库中，网站界面的导航和按钮文案则由本地语言字典维护。
接下来，我更想观察它在持续写作中的表现：原文频繁修改后，各语言版本是否容易保持同步；分块翻译是否会影响全文的一致性；人工修订过的表达，能否逐渐沉淀为更有用的术语和翻译规则。
多语言版本最终还是要交给读者阅读。流程可以自动运行，表达是否清楚、是否保留了原文想说的意思，仍然需要一篇篇地看。