我用平行 AI 代理喺 4 日內翻譯咗 390 萬個字
493 篇博客文章，橫跨 17 年，翻譯成 10 種語言，大約 4,900 個檔案，大約 390 萬個字。Claude Code 嘅平行代理令呢件事成為可能——但韓文嘅災難、粵語語氣嘅問題，同埋 5 小時嘅使用上限，教咗我嘅嘢比成功更多。
一個月前，我喺 48 小時內為 DIALØGUE 加咗 5 種語言，並且寫低咗計劃文件係快速 AI 執行嘅秘訣。
嗰次係 5 種語言，用嚟做一個只有大約 400 個 UI 字串嘅應用程式。
今個星期，我試咗一件大得多嘅事：將我整個博客——493 篇橫跨 17 年嘅文章——本地化成 10 種語言。越南文、印尼文、西班牙文、法文、葡萄牙文、德文、日文、韓文、簡體中文，同埋粵語。
大約 4,900 個翻譯檔案。大約 390 萬個字。4 日。
呢唔係一個關於 AI 有幾神奇嘅故事。係關於當你將數千個翻譯任務交畀平行 AI 代理時，實際會發生咩嘢——哪啲編排方式係有效嘅，哪啲失敗到你睇完輸出先發現，以及當機器大規模寫作時，質量控制方面令人不舒服嘅真相。
規模問題
我嘅博客可以追溯到 2007 年。有啲文章係關於新加坡搜尋行銷嘅 300 字更新。有啲係關於中美關係或海外移民指南嘅 5,000 字深度分析。文章庫包括由 Yahoo SEM 分析到書評到 AI 產品發布嘅所有嘢。
手動將 493 篇文章翻譯成 9 種語言，需要一個專業翻譯團隊花上幾個星期。可能係幾個月。而且費用會介乎「令人不舒服」到「要重新抵押房子」之間。
但我已經建好咗 i18n 基礎設施——next-intl 路由、具備語言感知嘅組件、非英文頁面嘅 ISR——作為更廣泛國際化推動計劃嘅一部分。技術棧係準備好嘅。我只係需要內容。
第一日：越南文同第一批教訓
我由越南文開始，因為呢個係我嘅母語。我可以睇每一篇翻譯文章，即刻知道有冇嘢聽落唔對。
Claude Code 喺一個 session 入面翻譯咗全部 493 篇文章。個過程睇落去好清晰：
- 讀取英文 MDX 檔案
- 翻譯內容，保留所有 frontmatter 結構
- 保持 URL、代碼塊，同埋技術術語唔變
- 將翻譯後嘅檔案寫到
content/blog/vi/YYYY/MM/DD/slug.mdx - 以越南文對應嘅「Cheers, Chandler」作結
第一次 QA 發現咗一個會喺每種語言都出現嘅規律：URL 同埋結尾簽名。代理會「翻譯」內部博客 URL（將 /blog/2024/... 改成唔存在嘅越南文 slug），將「Chandler」替換為越南文名字變體，偶爾仲會完全丟失 frontmatter 嘅 slug 欄位。
我整咗一個 QA 清單：
- 檔案數量與來源一致（493）
- 冇空白或殘缺檔案
- 所有 frontmatter 都有
slug、title、date、categories - 冇被重寫嘅內部 URL
- 結尾簽名符合目標語言嘅慣例
- 對於 CJK 語言：確認本地字符實際存在
呢份清單成為咗之後每種語言嘅核心框架。
第二日：平行代理嘅突破
越南文完成，QA 清單亦證實有效，我需要跑得更快。Claude Code 用於呢類工作嘅殺手鐧係平行子代理調度——你可以同時啟動多個獨立代理，各自平行處理唔同嘅檔案。
以下係西班牙文嘅編排方式：
Dispatching 30 translation agents...
├── Agent 1: 2007-2008 posts (42 posts)
├── Agent 2: 2009 posts (38 posts)
├── Agent 3: 2010-2011 posts (35 posts)
├── ...
├── Agent 28: 2025 Nov-Dec posts (12 posts)
├── Agent 29: 2026 Jan posts (8 posts)
└── Agent 30: 2026 Feb posts (9 posts)
每個代理拿到一批文章、風格指南、QA 清單，同埋結尾簽名慣例。佢哋平行運行，各自獨立寫入檔案。唔需要協調，因為每個代理係處理唔同嘅檔案。
西班牙文：喺一個 session 內翻譯咗 493 篇文章。 跟住係法文。葡萄牙文。德文。日文。
大約 12 小時內完成五種語言。係呢個部分感覺好似係未來——睇住你嘅終端機被 30 個同時運行嘅進度指示器填滿，每個代理都喺你煮飯嗰陣喺翻閱十年嘅博客文章。
以下係粵語（zh-HK）翻譯 session 實際睇落嘅模擬——由計劃到調度再到 QA：
編排規律
浮現出嚟嘅規律：
- 預先建立所有目錄——如果目標目錄唔存在，代理會靜靜地失敗
- 按年份範圍分批——普通文章每個代理 10-15 篇，超過 3,000 字嘅文章每個代理 2-3 篇
- 每次調度都包含風格指南——代理冇共享記憶，所以每個都需要完整嘅上下文
- 每個語言完成後立即做 QA——檔案數量、空白檔案、損壞嘅 frontmatter、URL 重寫、結尾簽名一致性
- 用針對性嘅清理代理修復遺漏——總會有 5-15 篇文章被跳過或格式有問題
韓文嘅災難
韓文本來應該係例行公事。同其他 7 種語言一樣嘅規律。調度代理、等待、QA、修復遺漏。
結果卻係所有語言中翻譯質量最差嘅。
72% 嘅韓文文章唔係翻譯——係摘要。 代理將 350 多篇文章截短成 2-3 段嘅概要，丟失晒所有細節、所有個性、所有細微差別。一篇關於 Ray Dalio《原則》嘅 4,000 字分析變成咗一個 200 字嘅概述。一個詳細嘅 SEM 教程變成咗「本文討論搜尋引擎行銷策略。」
UI 字串檔案（messages/ko.json）情況更糟。通篇混合韓文同英文，仲有損壞嘅字符，好似「Ch및ler」而唔係「Chandler」。및 字符係韓文嘅「和」——不知何故模型喺字中間替換咗佢。
我要從頭重做整個語言版本。每一篇文章。第二次嘗試，帶住關於保留完整內容、與來源文章長度匹配嘅更嚴格指示，最後出來嘅結果係乾淨嘅。
教訓：平行執行會放大錯誤。 如果你嘅提示有微妙嘅缺陷，30 個代理會以快 30 倍嘅速度犯同樣嘅錯誤。QA 唔係可選嘅——係「完成」同「災難」之間唯一可靠嘅嘢。
中文問題：43 次提交先至搞掂
簡體中文（zh）係最費勁嘅語言版本。唔係因為質量問題——翻譯係好嘅——而係因為 43 次獨立提交橫跨 493 篇文章，話畀你知個 session 不斷撞到上限。
Claude Code 係用 Anthropic 嘅 API 運行，而且有使用上限。即使係 Max 版本用 Sonnet 4.6，調度幾十個平行代理嘅延長 session 最終都會遇到 5 小時嘅冷卻期。對於中文，呢個意思係分批翻譯：大約 50 篇文章、撞到上限、等待、繼續、再次撞到上限。
中文翻譯亦需要最多嘅 QA，因為 CJK 內容有獨特嘅失敗模式：
- 來自錯誤文字系統嘅字符（日文漢字混入簡體中文）
- 過於正式嘅語氣，讀起來像政府文件而唔係博客
- 西方標點符號代替中文標點符號（，vs. , 同埋 。vs. .）
- 唔應該翻譯嘅名字被翻譯咗（「Claude」係中文嘅「Claude」，唔係克勞德）
粵語語氣問題
當我加入繁體中文配粵語語氣（zh-HK）嘅時候，我面對嘅係一個完全唔同嘅挑戰。翻譯需要使用粵語特有嘅語氣助詞——嘅（所有格）、咗（過去式）、喺（在）、啲（一些）、冇（冇有）——並且保持定義粵語寫作特色嘅輕鬆、對話式語氣。
標準普通話翻譯喺香港讀起來係官僚氣十足嘅。「本网站提供中文版本」係正確嘅普通話，但粵語讀者期待嘅係「呢個網站有中文版本。」意思一樣，語氣完全唔同。
挑戰唔係翻譯準確性——係語氣真實性。模型可以產出語法正確嘅粵語，但係除非你明確指示佢使用口語化助詞同代碼混合模式，否則佢會默認用普通話語氣。
我嘅粵語 QA 檢查包括用 grep 搜尋每個檔案，確認粵語特有助詞嘅存在。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 喺 session 中途變得可用時，我切換過去。好啲，但仍然冇平行執行。根本嘅架構差異——Claude Code 可以調度 30 多個獨立代理同時運行，而 Codex 係作為單一順序進程運行——令 Claude Code 對於大量內容任務嚟講快得多。
坦誠嘅比較： Codex 適合專注嘅單檔案工作。響應靈敏，緊跟指示。但對於我需要嘅大規模平行執行——4,437 個檔案橫跨 9 個語言版本——Claude Code 嘅代理架構完全係另一個層次。
拯救一切嘅清單
每個語言版本都經過同樣嘅 QA 流程：
✓ File count: 493/493
✓ Empty files: 0
✓ Small files (<100 bytes): 0
✓ Missing slugs: 0
✓ Rewritten URLs: 0
✓ Broken frontmatter: 0
✓ Wrong sign-off: 0
✓ Native characters present: 493/493
對於 CJK 語言，我加咗：
✓ Cantonese particles (嘅/咗/喺/啲/冇): 493/493
✓ No mixed-script contamination: PASS
✓ Chinese punctuation: PASS
冇呢份清單，我就會將韓文摘要版本發布到生產環境。我就會發布 70% 英文嘅粵語 UI。我就會發布帶住指向唔存在翻譯 slug 嘅損壞內部鏈接嘅博客文章。
呢份清單唔係官僚主義。係當你嘅生產流程產出數千個你無法親自閱讀嘅檔案時，唯一可靠嘅 QA 方式。
最終數字
| 語言 | 11 個（英文 + 10 個翻譯） |
| 翻譯文章 | 每種語言 493 篇 × 10 = 約 4,900 個檔案 |
| 字數 | 約 390 萬字 |
| 日曆日數 | 4 日（2 月 24 至 27 日） |
| UI 字串檔案 | 10 個語言 JSON 檔案（每個約 475 個鍵） |
| 電郵模板 | 10 個語言版本 |
| 旅程資料 | 里程碑 + 學習路徑透過 JSONB 翻譯 |
| 撞到使用上限次數 | 數唔清 |
| 完整語言重做次數 | 1 次（韓文） |
我實際學到嘅嘢
1. 風格指南係一切。 粵語語氣、韓文嘅正式程度、葡萄牙文嘅「Abraço」結尾簽名——呢啲唔係裝飾。係「翻譯」同「本地化」之間嘅分別。冇風格指南，你拿到嘅係語法正確但讀起來像政府表格嘅內容。
2. 平行代理係力量倍增器——亦係風險倍增器。 當 30 個代理正確執行，你可以喺一個鐘頭內完成一種語言。當 30 個代理犯同樣嘅錯誤，你就會拿到 350 篇截短嘅文章同一次完整重做。
3. 大規模 QA 唔係可選嘅。 你無法手動審閱 4,437 篇翻譯文章。但你可以自動化結構性檢查，捕捉最常見嘅失敗：缺少檔案、損壞嘅 frontmatter、URL 重寫、錯誤簽名、截短內容。
4. 最難嘅部分唔係翻譯——係語氣。 任何 LLM 都可以翻譯文字。要令佢聽起來像寫原文嗰個人——保持溫暖、輕鬆、充滿求知慾——橫跨 9 種語言同 17 年不斷演變嘅寫作風格，呢個需要明確嘅指示同反覆嘅改良。
5. 使用上限係實際嘅限制。 即使係最高版本，延長嘅平行代理 session 都會撞到上限。計劃好中斷。將工作結構化，令你可以由停下嘅地方繼續。
6. 用真實讀者測試。 我可以自己 QA 越南文翻譯。對於韓文或日文，我依賴結構性檢查同信任模型。呢個係已知嘅缺口。如果你對你唔識講嘅語言嘅質量係認真嘅，就搵母語讀者抽查一個樣本。
值唔值得？
我嘅博客而家可以用 11 個語言版本，以讀者嘅母語接觸到佢哋。胡志明市嘅越南行銷專業人士可以用越南文閱讀我 2011 年對新加坡搜尋市場嘅分析。日本 AI 研究員可以用日文閱讀我 2024 年關於建立 Sydney 嘅文章。香港嘅粵語讀者拿到嘅內容聽起來係為佢哋而寫嘅，而唔係翻譯到佢哋嘅。
係唔係每篇翻譯都係完美嘅？唔係。呢個規模嘅機器翻譯有粗糙嘅邊緣。有啲比喻唔夠傳神。有啲文化參考需要超越逐字替換嘅本地化。
但替代方案係 493 篇文章只有英文版，只有大約 20% 嘅全球網絡用戶可以訪問。而家超過 60% 可以訪問咗。
四日。390 萬個字。基礎設施已經就位。我用英文寫嘅每一篇新文章，都會作為部署流程嘅一部分翻譯成 10 種語言。
真正嘅問題唔係 AI 翻譯係咪完美。係完美係咪可訪問性嘅敵人。
祝好， Chandler
