我用并行AI智能体在4天内翻译了390万词
493篇博文横跨17年，翻译成10种语言，约4900个文件，约390万词。Claude Code的并行智能体让这一切成为可能——但韩语灾难、粤语语气问题，以及5小时用量上限，教会了我比成功更多的东西。
一个月前，我在48小时内为DIALØGUE添加了5种语言，并写了一篇关于规划文档如何成为AI快速执行秘诀的文章。
那次是为一个只有大约400个UI字符串的单体应用添加5种语言。
这周，我尝试了一件大得多的事：将我整个博客——493篇横跨17年的文章——本地化为10种语言。越南语、印度尼西亚语、西班牙语、法语、葡萄牙语、德语、日语、韩语、简体中文和粤语。
约4900个翻译文件。约390万词。4天。
这不是一个关于AI神奇魔力的故事。这是一个关于当你把数千个翻译任务交给并行AI智能体时，实际发生了什么的故事——哪些编排方式有效，哪些错误在你读到输出结果之前根本看不出来，以及当机器大规模写作时，质量控制这件事有多令人不安。
规模问题
我的博客要追溯到2007年。有些文章只是300词的新加坡搜索营销动态。有些则是5000词的长文，深度分析美中关系或海外华人移居指南。这个档案里什么都有：Yahoo SEM分析、书评、AI产品发布。
手动将493篇文章翻译成9种语言，需要专业翻译团队几周，甚至几个月的时间。费用介于"令人不舒服"和"得把房子再抵押一次"之间。
但我已经搭建好了i18n基础架构——next-intl路由、支持语言感知的组件、非英语页面的ISR——作为更大规模国际化推进的一部分。技术栈已经就绪，我只缺内容。
第1天：越南语与初次经验
我从越南语开始，因为这是私人感情——越南语是我的母语。我可以阅读每一篇翻译稿，立刻判断是否有哪里听起来不对劲。
Claude Code在一次会话中翻译了全部493篇文章。流程看起来很清晰：
- 读取英文MDX文件
- 翻译内容，保留所有frontmatter结构
- 保持URL、代码块和技术术语不变
- 将翻译后的文件写入
content/blog/vi/YYYY/MM/DD/slug.mdx - 以越南语对应的"Cheers, Chandler"结尾
第一轮QA就发现了一个模式，这个模式后来困扰了每一种语言：URL和结束语。智能体会"翻译"内部博客链接（把 /blog/2024/... 改成根本不存在的越南语slug），把"Chandler"替换成越南语名字变体，偶尔还会把frontmatter中的 slug 字段整个丢掉。
我整理了一份QA清单：
- 文件数量与源文件一致（493）
- 没有空文件或占位文件
- 所有frontmatter都有
slug、title、date、categories - 没有被改写的内部URL
- 结束语符合目标语言的惯例
- 对于CJK语言：确认实际存在原生文字
这份清单成为了每个后续语言的基础框架。
第2天：并行智能体的突破
越南语完成、QA清单经过验证之后，我需要提速。Claude Code在这类工作中的杀手级特性是并行子智能体调度——你可以同时启动多个独立智能体，让它们各自处理不同的文件。
以下是西班牙语的编排方式：
正在调度30个翻译智能体...
├── 智能体 1: 2007-2008年文章（42篇）
├── 智能体 2: 2009年文章（38篇）
├── 智能体 3: 2010-2011年文章（35篇）
├── ...
├── 智能体 28: 2025年11-12月文章（12篇）
├── 智能体 29: 2026年1月文章（8篇）
└── 智能体 30: 2026年2月文章（9篇）
每个智能体获得一批文章、风格指南、QA清单和结束语规范。它们并行运行，各自写入文件，互不干扰——因为每个智能体处理的是不同的文件。
西班牙语：在一次会话中翻译了493篇文章。 然后是法语、葡萄牙语、德语、日语。
大约12小时内完成了五种语言。这就是让人感觉像是未来的部分——看着终端里涌现出30个同时运行的进度指示器，每个智能体都在梳理过去十年的博文，而你则在做晚饭。
以下是粤语（zh-HK）翻译会话的模拟还原——从规划到调度再到QA的全过程：
编排模式
逐渐形成的模式如下：
- 提前创建所有目录 — 如果目标目录不存在，智能体会静默失败
- 按年份范围分批 — 普通文章每个智能体10-15篇，超过3000词的文章每个智能体2-3篇
- 每次调度都附上风格指南 — 智能体之间没有共享记忆，所以每个都需要完整的上下文
- 每个语言完成后立即运行QA — 文件数量、空文件、frontmatter损坏、URL被改写、结束语一致性
- 用有针对性的清理智能体修复遗漏 — 总有5-15篇文章被跳过或格式损坏
韩语灾难
韩语本应是例行操作，和其他7种语言一样的流程：调度智能体、等待、QA、修复遗漏。
结果，它成了所有语言中翻译质量最差的一次。
72%的韩语文章根本不是翻译——它们是摘要。 智能体把350多篇文章压缩成了2-3段的概要，所有细节、所有个性、所有层次感全部消失。一篇4000词分析Ray Dalio《原则》的文章，变成了200词的概述。一篇详细的SEM教程变成了"本文探讨搜索引擎营销策略。"
UI字符串文件（messages/ko.json）更糟糕。韩文和英文混杂其中，还有损坏的字符，比如"Ch및ler"而不是"Chandler"。및这个字符在韩文里是"和"的意思——不知怎的，模型在词中间替换了它。
我不得不从零开始重做整个语言。每一篇文章。第二次尝试时，我加入了更严格的指令，要求保留完整内容、与源文章篇幅匹配，结果干净了很多。
教训：并行执行会放大错误。 如果你的提示词有一个细微的缺陷，30个智能体会以30倍的速度犯同一个错误。QA不是可选项——它是"完成"和"灾难"之间唯一可靠的防线。
中文问题：43次提交才搞定
简体中文（zh）是最耗费心力的语言。不是因为质量问题——翻译质量是好的——而是493篇文章经过43次独立提交，说明会话一直在触及用量上限。
Claude Code运行在Anthropic的API上，存在用量上限。即使是Max套餐加Sonnet 4.6，调度数十个并行智能体的长时间会话最终也会触发5小时冷却期。对于中文来说，这意味着分波次翻译：大约翻译50篇，触达上限，等待，继续，再触达上限。
中文翻译也需要最多的QA，因为CJK内容有其独特的失败模式：
- 脚本混用（日文汉字混入简体中文）
- 过于正式的语气，读起来像政府公文而不是博客
- 使用西式标点而不是中文标点（，与 , 以及 。与 .）
- 翻译了不该翻译的名字（"Claude"在中文里就是"Claude"，而不是"克劳德"）
粤语语气问题
当我添加带粤语语气的繁体中文（zh-HK）时，我面临了完全不同的挑战。翻译需要使用粤语特有的语气词——嘅（所有格）、咗（过去时）、喺（在/于）、啲（一些）、冇（没有）——并保持粤语书写中那种随意、口语化的腔调。
标准普通话翻译在香港读起来像官方文件。"本网站提供中文版本"是正确的普通话，但粤语读者期待的是"呢個網站有中文版本"。意思相同，语气天壤之别。
挑战不在于翻译的准确性，而在于语气的真实性。模型可以生成语法正确的粤语，但除非你明确指示它使用口语语气词和粤普混用的表达方式，否则它默认会用普通话的语气。
我对粤语的QA检查包括用grep扫描每个文件，确认粤语特有语气词的存在。493篇中493篇通过。但我仍然不得不手动重写整个 messages/zh-HK.json UI字符串文件，因为第一版大约70%是英文——智能体跳过了大部分翻译。
我对OpenAI Codex的尝试
大约在翻译德语的过程中，我触达了Claude Code的用量上限，决定趁等待期间试试OpenAI的Codex。我有一个月的ChatGPT Plus免费试用，其中包含Codex访问权限。
好的方面： Codex能生成质量不错的规划文档。它对代码库的初步分析和提出的翻译方案结构清晰、合理。响应速度很快，而且能严格按照指令执行——有时甚至显得太过字面，这反倒成了一个特点。
不好的方面： 我使用的版本（gpt-5.2-codex）无法运行并行子智能体。它按顺序处理文章——一篇接一篇。对于493篇文章来说，这根本不可行。它也是以短促的方式运作，完成5-10篇后就停下来等待反馈。每次我都得说"继续"才能进行下一批。
当gpt-5.3-codex在会话中途上线时，我切换了过去。效果更好，但依然没有并行执行能力。这个根本性的架构差异——Claude Code可以调度30多个独立智能体同时运行，而Codex作为单一的顺序进程工作——使得Claude Code在批量内容任务上的速度快出不止一个量级。
坦诚的比较： Codex适合专注的单文件工作，响应及时，执行指令到位。但对于我所需要的那种大规模并行执行——9种语言共4437个文件——Claude Code的智能体架构完全不在同一个层级。
拯救一切的清单
每种语言都经过相同的QA流程：
✓ 文件数量：493/493
✓ 空文件：0
✓ 过小文件（<100字节）：0
✓ 缺失slug：0
✓ URL被改写：0
✓ 损坏的frontmatter：0
✓ 错误的结束语：0
✓ 原生文字存在：493/493
对于CJK语言，我额外添加了：
✓ 粤语语气词（嘅/咗/喺/啲/冇）：493/493
✓ 无混合脚本污染：通过
✓ 中文标点：通过
没有这份清单，我可能会把韩语摘要版发布到生产环境，会把70%是英文的粤语UI发布上去，会把内部链接指向不存在的翻译slug的博文也发布出去。
这份清单不是官僚主义。当你的生产流水线生成了数千个你根本读不完的文件时，它是唯一可靠的质量保证。
最终数字
| 语言数 | 11（英语 + 10种翻译） |
| 翻译文章数 | 493篇 × 10种语言 ≈ 4900个文件 |
| 总词数 | 约390万词 |
| 日历天数 | 4天（2月24日至27日） |
| UI字符串文件 | 10个语言JSON文件（各约475个键） |
| 邮件模板 | 10种语言 |
| 旅程数据 | 里程碑和学习路径通过JSONB翻译 |
| 触达用量上限次数 | 数不清了 |
| 完整重做的语言 | 1个（韩语） |
我真正学到的东西
1. 风格指南就是一切。 粤语的语气、韩语的正式程度、葡萄牙语的"Abraço"结束语——这些不是装饰。它们是"翻译了"和"本地化了"之间的差距。没有风格指南，你得到的是语法正确但读起来像政府表格的内容。
2. 并行智能体是力量倍增器，也是风险倍增器。 当30个智能体正确执行时，你能在一小时内完成一种语言。当30个智能体犯同一个错误时，你会得到350篇被截断的文章，然后全部重做。
3. 规模之下，QA不是可选项。 你不可能手动审阅4437篇翻译文章。但你可以自动化结构检查，捕捉最常见的失败：文件缺失、frontmatter损坏、URL被改写、结束语错误、内容被截断。
4. 最难的部分不是翻译——而是语气。 任何大语言模型都能翻译文字。但让翻译听起来像是写出原文的那个人——保留那份温度、随意、智识上的好奇心——跨越9种语言、17年不断演变的写作风格，这需要明确的指令和反复的打磨。
5. 用量上限是真实的约束。 即使是最高套餐，长时间的并行智能体会话也会触及限制。提前规划好中断。把工作结构化，确保你能从中断的地方继续。
6. 用真实读者来测试。 我自己能QA越南语翻译。对于韩语或日语，我依赖结构检查，信任模型。这是一个已知的缺口。如果你对不懂的语言的质量认真对待，找母语读者抽样检查。
值得吗？
我的博客现在能以读者的母语触达11个语言区的用户。胡志明市的越南营销专业人士可以用越南语阅读我2011年对新加坡搜索市场的分析。日本的AI研究人员可以用日语阅读我2024年关于构建Sydney的文章。香港的粤语读者看到的内容，读起来像是专门为他们写的，而不是对着他们翻译的。
每一篇翻译都完美吗？不是。这种规模的机器翻译有粗糙的边角。有些比喻没法自然落地，有些文化引用需要超越逐字替换的本地化处理。
但另一种选择，是让493篇文章只存在于英语，只对全球互联网用户中大约20%的人可及。现在，它可以触达超过60%的用户。
四天。390万词。基础设施已经就位。我用英语写的每一篇新文章，都会作为部署流程的一部分，被翻译成10种语言。
真正的问题不是AI翻译是否完美。而是完美是否是可及性的敌人。
致敬， Chandler
