翻譯在地化達人：別每次重新賭運氣，把翻譯做成可驗證的工程

這行的痛點

翻譯這一行真正麻煩的從來不是「看不懂外文」，是規模一大就守不住一致性：一本書、一整年的部落格文章、一部影集的字幕，都要求同一個術語從頭到尾譯法一樣、同一個角色名字不能一集一個樣、語氣不能忽然從口語跳成書面。這正是 CAT 工具（如 Trados、memoQ）幾十年來在解決的老問題——termbase 鎖定術語、translation memory 記住翻過的句子、QA 規則抓不一致。

Claude Code 把這套邏輯搬進 CLI 裡重做一遍：詞彙表可以只是一份 JSON 或 Markdown，用 skill 或 subagent 把「取樣建詞彙表 → 翻譯 → 獨立審校」變成可重複呼叫的流程，不用每次開新對話從頭講一次規則。對本來就熟悉 CAT 概念的譯者，這個心智模型幾乎是現成的，只是換了個工具長相。

更關鍵的是，翻譯工作本質上是批次的（整本書、整季字幕）又可腳本化（排程跑、串進交付流程），這正是 CLI 比網頁聊天視窗好用的地方——網頁版一次貼整份字幕常常被截斷、角色名前後對不上；CLI 可以切塊、可以重跑失敗的部分、可以留下執行紀錄（哪一塊翻過、用了哪個版本的詞彙表）。

但這行的從業者也最該保持戒心：AI 譯文終究是草稿，人工終審這條線省不得，後面陷阱段落會具體講到——這不是客套話，是所有第一手案例（含最樂觀的那幾個）都自己承認的底線。

動手前的準備

• 完全沒碰過 Claude Code 的話，先看 Claude Code 教學第 1 章（安裝與基本設定），這裡不重複裝機步驟。
• 想順便看 Codex CLI 能不能做同樣的事，先看 Codex CLI 教學第 1 章（安裝與基本設定）。
• 只處理你擁有、已取得授權或依法可使用的檔案與影音；先確認來源平台條款、著作權與委託保密義務。安裝第三方 skill 前先檢查來源與版本；客戶文件先確認資料處理條款，勿把機密原文直接送入未核准的雲端服務。
• 場景二、場景三提到的 skill 安裝都靠 npx skills add <repo> -a claude-code，先確認機器裝了 Node.js。
• 場景二的整本書翻譯還需要 Calibre（ebook-convert）與 Pandoc 轉檔，動工前先跑一次 ebook-convert --version 確認能動，環境沒裝好流程直接卡在第一步。
• 場景三的古籍手稿管線吞吐量跟 Claude 訂閱層級直接掛鉤（Max 每 5 小時窗約 40 批、Pro 少很多），處理大量頁數前先想清楚訂閱層級夠不夠用，不然會翻到一半發現額度撐不住。
• 場景四的字幕工具依賴 ffmpeg、ffprobe、yt-dlp、Python 3、OpenAI Whisper（large 模型），Whisper large 沒有 GPU 會很慢，Windows 環境需要 Git Bash 或 MSYS2 處理路徑問題。
• 場景一「只翻有變動段落」的招式要靠 git 歷史比對，文章不在 git 儲存庫版本控制之下就用不了這招。

場景一：部落格三語同步不必每次重翻

Vincent Ethier 是一位母語法文、旅日十年的技術部落客，想把英文部落格同步發布法文版與日文版。人工翻譯每篇每個語言要花 3 到 4 小時，外包太貴，一般機翻品質又保不住他自己的語氣。這是他 2026-01-14 發文分享的第一手工作流。

Claude Code 怎麼做

1. 1

   建立 sync-translations skill 當總指揮

   寫一個 sync-translations skill 當總指揮，負責讀設定、串起整條流程。

2. 2

   用偵測腳本把文章分成三態

   用偵測腳本 check-sync.sh 把每篇文章分成三態：NEW（尚無譯文）、SYNC（英文原文在上次翻譯後改過）、ABORT（譯文已是最新）——用 git 歷史抽出上次翻譯以來的英文精確 diff，只翻有變動的段落，不整篇重翻。

3. 3

   主 agent 依 learnings 檔草譯

   主 agent 依「learnings 檔」草譯，寫入磁碟。

4. 4

   每語言派全新 context 編輯 subagent 審稿

   每個語言各派一個全新 context 的編輯 subagent 獨立審稿——編輯只看得到英文原文、譯文草稿、共用 learnings 檔，檢查自然度、慣用語轉換、術語、語氣一致性。

5. 5

   learnings 檔累積術語與風格決策

   learnings 檔是逐語言累積的 Markdown，記下術語與風格決策（例如法文版記「proof by contradiction → par l'absurde」），形成「每翻一篇、下一篇更準」的回饋迴圈，功能上就是一份輕量版 termbase 加 style guide。

實際操作大概像這樣：

# 先跑一次同步檢查，看哪些文章是 NEW / SYNC / ABORT
./check-sync.sh

# 對 Claude Code 下指令，讓 sync-translations skill 接手
"執行 sync-translations，處理所有標記為 NEW 或 SYNC 的文章，
 完成後分別派法文與日文編輯 subagent 用全新 context 獨立審稿"

成效部分要老實講：作者自評每篇文章全語言翻譯壓到 1 分鐘以內（原本 3 到 4 小時／篇／語），也自評譯文「連技術內容都讀起來非常自然」——這是作者自己的評價，沒有第三方驗證，但這篇部落格文章本身就是用這套系統翻譯出來的，算是某種自我實證。👤達人

換成 Codex CLI

Codex CLI 目前找不到這職業的第一手翻譯案例，但用它的通用能力應該也能做到類似效果：同樣的架構可以用 codex exec --profile translate "translate posts marked NEW or SYNC" 搭配 AGENTS.md 放語言規則。差別在於 Codex 沒有原生 subagent 概念，「全新 context 編輯審稿」這一步得靠另外開一個 codex exec 行程手動模擬，沒有現成的一鍵分派機制。

場景二：整本書平行翻譯，詞彙表先行

想把一整本書（PDF／DOCX／EPUB）翻成另一種語言時，單一 session 硬翻整本書會撞上三個問題：context 累積、輸出被截斷、術語前後不一致。deusyu/translate-book 這個開源 skill（903 顆星、118 個 fork，上架首週就衝上 600 多顆星）把這套流程工程化了。

Claude Code 怎麼做

1. 1

   轉檔

   用 Calibre 的 ebook-convert 把 PDF／DOCX／EPUB 轉成 HTMLZ 再轉 Markdown，切成約 6,000 字元的區塊，並建一份 SHA-256 manifest 逐塊記 hash 做完整性驗證。

2. 2

   詞彙表先行

   正式翻譯前先抽 5 個區塊取樣，抽出專有名詞與領域術語、定出標準譯法，做成三欄表（原文｜別名｜譯文）注入每個區塊的 prompt——上百塊的書就是靠這個維持術語一致。

3. 3

   平行翻譯

   預設 8 個 subagent 同時進行，每個都有獨立 context window；每塊另外拿到相鄰區塊約 300 字元的唯讀節錄，用來正確判斷代名詞與人物指涉。

4. 4

   驗證與合併

   合併前做原文／譯文 1:1 配對檢查、比對 manifest hash（擋掉過期輸出）、拒收空白輸出。

5. 5

   產出

   合併後的 Markdown 轉 HTML（含浮動目錄），再用 Calibre 產出 DOCX／EPUB／PDF。

6. 6

   可續跑

   run_state.json 記錄每塊狀態、用過的詞彙表版本與輸出 hash；重跑會自動跳過已完成的、重試失敗的塊；詞彙表改了只重翻受影響的區塊。

npx skills add deusyu/translate-book -a claude-code -g   # 安裝
translate /path/to/book.pdf to Chinese                    # 對話觸發
/translate-book translate /path/to/book.pdf to Japanese   # slash 指令
python3 scripts/convert.py /path/to/book.pdf --olang zh   # 手動跑轉檔

這個專案的設計哲學值得記下來：「腳本管記帳，LLM 管語意」——Python 負責確定性的狀態管理、hash、I/O；模型只負責命名、性別指涉、衝突裁決這類需要判斷的事。共用的詞彙表與狀態檔只有主 agent 一個寫入者，避免多個流程同時搶寫造成競態問題。

換成 Codex CLI

npx skills add deusyu/translate-book -a codex 理論上裝得起來（skills 生態明確支援 Codex），但這個 skill 深度依賴 Claude Code 的平行 subagent 機制，Codex 端能不能等效運作並未經過驗證。老實說：架構概念可以借鏡，但工具本身是綁在 Claude Code 上的，不建議直接期待 Codex 跑出一樣的結果。

場景三：古籍手稿翻譯，跳過 OCR 直讀圖檔

數千部希伯來文、拉丁文的歷史著作（從中世紀天文學到 18 世紀卡巴拉哲學）從來沒有英譯本，而掃描件是 14 到 18 世紀的破損鉛字與手稿——傳統 OCR 碰到這種素材直接陣亡。sweisman/translation-pipeline 這個開源管線改用 Claude 的視覺能力直接讀頁面圖檔，整條路徑跳過 OCR。

Claude Code 怎麼做

1. 1

   收書與切分

   對 Claude Code 說「Add https://archive.org/details/...」就能自動從 Internet Archive、HebrewBooks.org、Gallica 建檔；說「Translate gans/tzemach_david」就啟動整條管線；PDF 會切成每批約 4 頁。

2. 2

   翻譯 subagent 迴圈

   每批交給一個 Claude Opus subagent 處理，prompt 內建語言專屬的「已知混淆模式」（例如希伯來文 gershayim ״ 與 kaf כ 容易混淆）、「數字照排版原樣轉錄」的鐵律、逐頁回報 running header 原文等要求，輸出結構化 JSON（逐頁譯文、異常旗標、圖表描述）。

3. 3

   批次記錄

   每批記下頁碼、字數、異常類別，有問題的寫進 rerun_candidates.txt，批與批之間停 5 分鐘避免一口氣吃爆 session 額度。

4. 4

   對帳五階段

   異常分四類（A 重跑可解／B 排版註腳／C 原書本身就有錯／D 留給合併階段處理）→ 人工挑出 A 類 → 用驗證式框架重跑（prompt 要寫「檢查原文實際是什麼」，不是「套用這個修正」）→ 合併成附頁碼引用的完整文件 → 產出討論報告供學術審閱。

5. 5

   續跑

   session 額度用完後，說「Resume gans/tzemach_david from batch 39」，程式會從磁碟上已存的批次檔驗證進度後再往下跑。

# 從 Internet Archive 建檔收書
Add https://archive.org/details/xxxxx

# 啟動整條翻譯管線
Translate gans/tzemach_david

# session 額度用完之後續跑
Resume gans/tzemach_david from batch 39

成效這裡要講清楚來源性質：這是作者自陳的實跑紀錄與估計值，不是第三方測過的數字。作者拿《Astronomia Danica》（1640 年出版、532 頁）當測試案例，已經整本翻完（133 批）；吞吐量方面，作者估計 Claude Max（每月 100 美元）每 5 小時額度視窗約能跑 40 批，換算每週約 1,500 頁，Pro（每月 20 美元）則約每週 300 頁，整個 4,500 頁的書庫規模估計要 4 到 6 週（以 Max 方案每天使用計）。👤達人

換成 Codex CLI

這裡沒有等效案例可以對照。這個場景高度依賴 Claude 直接讀圖的視覺能力加上 Opus 等級的推理，是 Claude Code 在這類應用上少見的差異化強項——目前也找不到用 Codex CLI 做類似古籍手稿翻譯的第一手或推展案例，這段就不勉強湊對照了。

場景四：MKV／YouTube 雙語字幕，繁體中文預設輸出

追劇或看教學影片沒有中文字幕，逐字聽打太慢；直接把整份字幕貼進 ChatGPT 網頁版常常被截斷，角色名前後也對不上。joshhu/makeownsrt 是一個 MIT 授權的開源 slash 指令，繁體中文是預設輸出，開發者明顯是以台灣讀者為對象設計的。

Claude Code 怎麼做

1. 1

   安裝

   把 translate-srt.md 複製到 ~/.claude/commands/translate-srt.md（全域）或 .claude/commands/translate-srt.md（專案層級），就會變成 Claude Code 的 /translate-srt slash 指令。

2. 2

   前置工具

   ffmpeg、ffprobe、yt-dlp、Python 3、OpenAI Whisper（large 模型，用 CUDA GPU 約需要 5GB VRAM）。

3. 3

   內部流程

   解析參數與語言對 → 判斷是本機檔案還是 YouTube 連結（是的話用 yt-dlp 下載 MP4 加內嵌字幕）→ 用 ffprobe 偵測是否已有字幕軌，有就用 ffmpeg 擷取，沒有就上 Whisper 語音轉錄 → 切成每批 40 條字幕的 JSON 區塊 → 依語言規則批次翻譯 → 自動驗證輸出是否含禁用字元 → 組回雙語 SRT（目標語言在上、原文在下）→ 清暫存檔並回報結果。

4. 4

   翻譯風格規則

   （原文明寫）：走「影視翻譯風格，口語自然流暢」；語意要精確；成語與慣用語會在地化改寫；全片角色名稱強制統一；中文輸出強制走繁體中文（台灣慣例），明令禁止特定簡體轉譯殘留字元（原文舉「乘」字轉寫誤用為例）；人名採標準通用譯法，日文人名走片假名判斷，韓文與俄文各自遵循該語言的轉寫慣例。

/translate-srt video.mkv                                     # 預設英文 → 繁體中文
/translate-srt video.mp4 ja>en                                # 日文 → 英文
/translate-srt https://www.youtube.com/watch?v=xxxxx ja>zh   # YouTube 直接下載＋翻譯

輸出的 SRT 檔名會跟來源影片同名，播放器可以直接自動載入雙語字幕。

換成 Codex CLI

這段延伸自通用用法，沒有第一手實測。translate-srt.md 本質上是一份 Markdown 定型 prompt，加上外部 CLI 工具鏈（ffmpeg／yt-dlp／whisper），並不是 Claude Code 專屬的 API，理論上把同一份 Markdown 存成 ~/.codex/prompts/translate-srt.md，或整段貼進 codex exec 的 prompt 裡，也應該能重現類似效果。真正的差異在於「每批 40 條加自動驗證禁用字元」這段檢查邏輯，Codex 沒有原生對應的批次驗證迴圈，得自己接一段 shell script 補上。

常踩的坑

延伸資源

• Vincent Ethier：用 Claude Code 做部落格三語同步翻譯（第一手工作流）
• deusyu/translate-book：整本書平行翻譯 skill（903 顆星）
• sweisman/translation-pipeline：希伯來文／拉丁文古籍翻譯管線
• joshhu/makeownsrt：繁體中文雙語字幕 slash 指令（台灣開發者製作）