用 Obsidian 和 Hugo 搭建人工审核的双语发布流水线

Wed, 22 Jul 2026 00:18:29 +0800

那套方案解决了文章应该存放在哪里，却留下了另一个问题：同一篇文章需要以两种语言发布时，该怎么办？

起初，我以为双语发布无非是翻译：把 Markdown 交给模型，让它生成中文或英文，再将结果保存在原文旁边。真正动手后我才发现，翻译反而是整个问题中最简单的一环。

真正棘手的是一系列架构问题：

我最终搭建的系统没有把本地化做成一个翻译按钮，而是将它纳入一条受控的发布流水线。

核心规则很简单：

文章在 Obsidian 中写作，发布工具的代码在 Hugo 仓库中维护。生成的草稿未经人工批准，一律不得进入网站。

原文始终是唯一可信版本链接到标题

一篇文章可以先用英文写，也可以先用简体中文写。发布工具会识别原文语言，再生成另一种语言的版本：

英文原文 -> 中文本地化版本
中文原文 -> 英文本地化版本

最初的 Obsidian 笔记始终是权威原文。本地化文章只是从中生成的派生版本，不是另一份需要独立维护的原稿。

这一点很重要。两份都能独立编辑的原稿很快就会出现偏差：日期可能只在英文文章中得到修正，中文文章却没有同步；重写后的结论可能只出现在一种语言中，另一种语言仍沿用早先的论证。一旦把两个文件都视为原稿，之后的每次修改都会变成一道同步难题。

原始笔记只需声明允许自己进入发布流水线：

publish: true

系列文章还需要记录阅读顺序：

series: Remote Agent Workflow
seriesOrder: 2

系统只根据 seriesOrder 选择系列中的下一篇文章，绝不随机挑选。这看似只是一条不起眼的操作规则，却能避免自动化系统将内容本身没有问题的文章按错误的叙事顺序发布。

如果要求一个提示词一次完成所有工作，它承担的任务就太多了：既要理解论证，又要用自然的目标语言写作，还要保留所有事实，并确保 Markdown 毫发无损。这些要求混在一起，产出的文章即使流畅，也可能出错；即使忠实，也可能满是翻译腔。

因此，我把整个过程拆成四个阶段。

第一轮不做翻译，只提取文章的核心主张、目标读者、推理链、事实、术语、语气和结构元素。