智能体本地化:这个博客如何在没有翻译团队的情况下保持多语言

你正在阅读的是一篇"知道如何翻译自己"的文章。本日志中的每篇文章都是一个带类型的 TypeScript 模块,包含英文原文和可选的语言变体——这些语言变体由 LLM 智能体按计划生成,经人工审核后,像任何代码变更一样合并上线。这篇文章(恰如其分地)附带的中文翻译,正是由这条流水线产出的。

内容模型:语言是字段,不是分叉

每篇文章导出一个对象,带有 translations 映射:en 必填,zh 和 ja 可选。标题、描述和正文按语言成组存放,翻译在结构上永远不会偏离原文——类型检查器不允许。文章的日期、标签和配图在所有语言间共享,因此除语言之外的一切都只有一个事实来源。

流水线:对比、翻译、审核

三步,刻意保持"无聊":

1. 检测过期。定时任务列出英文原文在某语言变体之后被修改过的文章(借助 git 历史只需一行命令),以及完全缺失目标语言的文章。
2. 带完整上下文翻译。智能体阅读整篇文章——而不是孤立的字符串——并就地写入语言变体。它对每种语言都有风格说明:简体中文使用大陆产品词汇,日文使用です/ます体,代码标识符与产品名保持原文。
3. 以审核为闸门。智能体提交 Pull Request,由人工(或拥有否决权的第二个审核智能体)阅读 diff。未经合并,任何内容都不会上线。

因为翻译就是代码,我们对代码的所有保障同样适用于翻译:CI 做类型检查,缺字段会让构建失败,git revert 几秒钟就能下线一篇糟糕的翻译。

为什么不在运行时做机器翻译?

运行时翻译 API 很诱人——不用文件,不用 PR。但它们翻译的是句子,不是论证。读完整篇文章的 LLM 智能体能保留比喻、章节结构,以及与早前文章一致的术语。它还可以拒绝直译:当一个双关语无法跨越语言时,它会改写句子,而不是让我们出洋相。而且由于产出被冻结在 git 中,每种语言的读者看到的都是经过审核的文字,而不是每次刷新页面掷一次骰子。

同样的方法也适用于 CMS

如果你的内容存放在 Payload 或其他无头 CMS 而非 git 中,这套思路依然成立:用 afterChange 钩子检测源语言的修改,排入翻译任务队列,智能体通过 API 将目标语言写回为草稿,等待编辑批准。原则完全相同——智能体提案,人类批准,每次变更都是可审阅的 diff。如果你正在选型,我们在另一篇文章里写了完整的 CMS 与 git 方案对比。