先划清适用范围：这篇不是教你把一篇小说翻成十四种语言。它解决的是内容团队真正高频的那类需求——有稳定产出的长文内容，需要同时维护中文和至少一个外语版本。技术博客、产品文档、出海官网、行业观察……这类内容的共同点是：不是只翻一次，而是每周每月都要翻新的。
一旦「持续」这个前提成立，事情的性质就变了。翻一次可以用任何工具凑合；翻一年就必须解决三个问题：术语前后一致、不重复烧钱、翻完能直接发。手工方式撑不住这三条，而这恰恰是 Agent 擅长的活。
第一步：先想清楚给谁看，这决定了翻译策略
很多人跳过这一步直接翻，结果做了大量白工。译前必须回答两个问题：
- 读者是终端用户，还是内部同事？给外部读者的译文要本地化——例子换成当地能懂的、单位换成当地习惯的、日期格式重排；给内部同事看的只要准确，本地化反而增加理解成本。
- 这个语种是「要有」还是「有人看」？如果目标是 SEO 覆盖而非真实读者，「完整、准确、关键词到位」就够；如果真有当地用户，就需要母语审校这一道人工关。
把这两个问题的答案写进 Agent 的指令里。同一个团队，对日语版本精细化处理、对西班牙语版本快速覆盖，是完全合理的取舍——没必要所有语种一个标准。
第二步：术语表是这件事的地基，先做再翻
多语言内容最容易被投诉的不是「翻得不够优美」，而是同一个东西在不同页面叫不同名字。读者会觉得这不是一个团队做的，品牌感直接垮掉。
术语表要包含四类内容：
- 产品与品牌名：哪些必须保留原文不翻译，哪些有官方译名，大小写怎么写（这一条最容易被机器翻错）。
- 行业专有名词：统一的中英对应，比如某个技术概念固定译成什么，避免同一篇文章里两种译法混用。
- 禁译词与替换词：哪些表达在当地有歧义或敏感含义，该换成什么说法。这一条是本地化的关键，纯机器翻译完全无法处理。遇到拿不准的译法，可以让 Agent 先查一遍权威用法再定，联网查证的做法见 OpenClaw 联网搜索。
- 风格约定：称呼用「你」还是「您」，标题用不用冒号，数字和单位怎么写。风格指南不用很长，一页就够，但必须写下来。
术语表做成结构化文件（表格最省事），交给 Agent 在每次翻译前读取。不要把它塞进提示词里手打一遍——手打的迟早会漏，而文件是可以版本管理的。术语表本身的维护方式，可以沿用 企业内部知识库 里讲的入库与更新机制；术语表文件的读取与解析，和 Agent 读取文件 讲的是同一套能力，Excel 里的术语对照表它同样能直接吃进去。
第三步：三条翻译路线，按预算和语种分
（1）通用大模型直接翻译。把术语表和风格指南连同原文一起给模型，让它一次输出译文。优点是上下文理解好，长句和语气能照顾到，还能顺便处理格式；缺点是成本比专用翻译接口高，且不同批次之间可能轻微漂移。适合语种少、对质量要求高的场景。这是最推荐起步的路线。
（2）专用翻译模型或翻译接口。成本低、速度快、大批量友好，术语一致性可以通过术语库参数控制。缺点是语气和语境把控弱一些，遇到口语化、双关、文化梗基本会翻车。适合量大、以信息传递为主的内容。这类服务通常以接口形式提供，挂进 Agent 的方式可参考 OpenClaw 接 MCP 工具。
（3）机翻打底 + 模型润色。先用便宜的方式出一版粗译，再让模型带着术语表和风格指南做一次改写。这条路线的性价比常常最高——粗译解决了「从零生成」的成本，润色解决了「像不像人话」的问题。代价是多一次调用、多一层流程。
实操建议：先用路线一跑通整条链路并按语种固定好，再对量大的语种换成路线三压成本。别一开始就为了省钱选最便宜的方案，因为你会花更多时间修质量。
第四步：格式保护，这是最容易翻车的地方
文章通常是有结构的（HTML、Markdown），里面有链接、代码块、图片地址。直接把这些丢给模型翻译，会出现三类事故：
- 标签被翻译或改写。HTML 标签名、属性值被当成正文翻了，页面直接崩。
- 链接被破坏。URL 里的路径被翻成译文，点开就是 404。
- 代码块被「顺手优化」。模型会把代码里的变量名、注释一起处理，代码就跑不起来了。
正确做法是先抽取、翻译、再回填：把正文文本内容抽出来单独翻，链接、代码、图片、标签原样保留，用固定标记占位，翻完再按标记填回原位。
另外根据目标语言调整排版细节：中文用全角标点，英文用半角；中英混排时注意空格规则；数字千分位和日期格式按目标地区重排（月/日/年还是日/月/年，这个弄错了会闹笑话）。这些细节不需要 Agent 判断，写死在流程里就行。
第五步：质量校验，别把「通顺」当成「正确」
机器翻出来的文字大多读起来挺顺，这正是危险所在——顺不等于对。三类校验可以在无人值守的情况下自动跑：
- 术语一致率。检查译文里所有术语表词条是否都按约定处理。只要出现未经约定的译法，就标记出来。这是一个可以量化的硬指标，比人工通读靠谱得多。
- 回译检查。把译文再翻回中文，和原文对比语义偏差。注意：回译只用来发现漏译、错译、语义反转，不能用来判断文笔——回译得越像原文，往往说明译文越生硬。
- 完整性检查。段落数对不对、有没有整段被吞掉、列表项数量是否一致、数字和专有名词有没有被改。这类结构性问题用程序比对非常有效。
- 风险词扫描。检查有没有出现当地不该出现的表达。
校验不通过的条目不要直接发，按 失败升级规则 处理：轻微问题自动重译，反复不通过的转人工。上线前的整体检查清单可参考 变更后验证清单，人工抽检的比例建议照 人工复核抽检 的做法定——不是每篇都看，但新语种上线初期要看得密一些。
第六步：双语对照排版与多语种站点
排版方式取决于发布场景，两条常见路线：
双语对照（同一页面对照展示）。适合文档、帮助中心、技术资料这类读者会对照原文核实的场景。技术上就是把两种语言按段落对齐，用左右栏或交替段落呈现。关键是段落级对齐——按整篇文章对照毫无意义，按句对齐又太碎。这一步 Agent 做起来很稳，因为段落结构从原文就带来了。
分语言独立页面。适合面向搜索引擎的内容站。这里有个 SEO 上的必做项：各语言页面之间要用标准标签互相声明对应关系，并且每个页面要明确声明自己的语言，否则搜索引擎会把不同语言版本当成重复内容，可能只索引其中一版。另外别用自动跳转把用户强行导到某个语言——用户和搜索引擎都会烦，给一个清楚的语言切换入口就够了。
URL 的组织方式建议一开始就定好，中途改会丢掉已有收录：要么用子目录区分语言，要么用子域名。选一种，然后别再动。站内链接在新语言版本里也要同步更新，别出现译文里链回中文页面的情况。
第七步：增量翻译，只翻新增的部分
这是整套流程里最省钱的一环，也是手工方式几乎做不到的。做法很简单：
- 给每个段落做一个稳定的内容指纹，存进记录文件。
- 每次翻译前先比对：指纹没变的段落直接复用已有译文，只翻新出现或已修改的段落。
- 整篇的元信息（标题、摘要、关键词）单独维护一张对照表。
这一条对「每周更新一版长文档」的场景尤其有效——通常只有 5% 到 10% 的内容会变，却要付 100% 的翻译钱。做增量之后，成本直接掉一个数量级。每次翻译用了哪版术语表、哪批段落、校验结果如何，也建议一并留档，做法参考 证据包怎么留——多语言内容出问题时，最常被追问的就是「当时按什么标准翻的」。
顺带把这件事接进定时任务：内容更新完自动触发翻译、校验、生成译文，第二天早上就能看到新版本。定时和推送的配置方式见 OpenClaw 定时发日报周报；如果是双语内容要一起出稿交付，可以接上 自动做汇报材料 里那套排版流程。
三个必须提前知道的坑
坑一：翻译腔。逐句直译出来的中文，读者一眼就能看出来。解法是在指令里明确要求「按目标语言母语者的表达习惯重写，不要逐句对应」——这一条加上去，观感差别很大。
坑二：文化特定内容无法直译。段子、谐音、本地热点、以及用中文简写才成立的表达，翻译过去要么没意义，要么尴尬。这类内容要么加一句本地化的说明，要么在目标版本里直接换成当地同类例子。别硬翻。
坑三：多语种带来的维护成本是乘法。每增加一个语种，后续每次内容更新都要同步一次，术语表也要同步扩充。所以别一次性开十种语言——先把一到两个语种跑成稳定流水线，验证读者真的需要，再扩。
优缺点与适合人群
优点：术语一致率变成可量化的指标，不再靠人记；增量翻译把重复成本压到接近零；翻完直接是排好版、链接可用的成品，省掉手工搬运；历史版本和术语表都可留档复用。
缺点：搭起来要花时间，尤其是术语表和校验规则，前期投入不轻；必须持续维护术语表，否则一致性会慢慢退化；对文学性、营销创意类内容（需要重写而非翻译）帮助有限。
适合：有稳定内容产出、需要维护双语或多语言版本的团队；做技术文档、帮助中心的团队；做出海产品需要持续更新官网和博客的团队。如果你只是偶尔要翻一两篇，手工加个翻译工具更快——流水线的价值来自「重复」。
一句话总结：多语言内容的难点从来不在「翻译」，而在「持续翻译还保持一致」。把术语表立起来、把增量做进去、把校验跑起来，你才真正拥有了一个能一直用的多语言内容能力，而不是一堆翻一次就再也对不上的旧文档。
