EPUB 格式並不規範，內容很長，直接讓 AI LLM 翻譯會遇到以下問題：
- 上下文過長導致格式被破壞：整本書一次性送入 LLM，容易丟失或改寫 HTML 標籤、屬性、錨點，導致 EPUB 檔案損壞，無法開啟。
- Token 消耗難以平衡：長文件需要大量 context 保持術語一致，失敗時還要重試，成本不可控。
- 翻譯時間過長：整本書作為單個或少數大 prompt 處理，耗時長，且難以分段重跑。
- 除錯困難：輸出是整塊內容，出錯時難以定位具體章節或標籤。
EPUB Translator 將 LLM 翻譯能力 與 工程能力 結合：
直接 LLM 翻譯 vs EPUB Translator
| 方面 | 直接 LLM 翻譯 | EPUB Translator |
|---|
| EPUB 結構 | 易破壞，輸出常無效 | 保持完整，輸出有效 EPUB |
| Token/成本 | 不可控，可能激增 | 分段處理，可預測 |
| 長文件 | 風險高，單批次易失敗 | 按章處理，可單獨重跑 |
| 可除錯性 | 整塊輸出，難以定位錯誤 | 按檔案隔離，對應清晰 |
| 漏譯/完整性 | 漏句、縮寫難以察覺 | 逐句檢查，漏翻段落換強模型重翻 |
- EPUB 感知的結構化流程：按章節分段處理，保留標記邊界和中繼資料，降低「一處錯誤導致全書失效」的風險。
- 受控的上下文：分段翻譯，避免超大 prompt，實現可預測的成本和更快的處理速度。
- 格式保持優先：將 EPUB 結構保持作為首要目標，確保輸出檔案在各閱讀器中可正常開啟。
- 可除錯、可重跑：問題可隔離到具體檔案或段落，僅重跑受影響部分。
- 逐句檢查漏翻：聊天模型處理長輸入時，可能悄悄跳過、縮寫或原樣留下某些句子。EPUB Translator 逐句檢查每一段譯文有沒有沒翻的句子；三次仍有句子沒翻的段落，會自動交給更強的模型重翻。實測中，快模型沒翻好的 36 段，強模型救回了 35 段。大部分篇幅由快模型翻，強模型只用在沒過檢查的段落上。
如果你的目標不只是「翻譯好的文本」，而是 一本可正常使用、格式完好的翻譯版 EPUB，EPUB Translator 是更穩妥的選擇。
整本書算下來，這裡也比自己在 ChatGPT 或 Claude 裡翻更省錢，原因一半是發送方式（每段只發一次、失敗只重跑那一塊），一半是模型分工（快模型翻大部分，只有沒過檢查的段落交給強模型）。發送方式的差別在於：聊天視窗每發一次新請求都會把前面所有章節一起帶上，等於同一段文字反覆付費，而結構一旦回傳時壞掉，那一節還得重翻重付。EPUB Translator 只把每一段發一次、只帶這一段需要的上下文，失敗時也只重跑那一個分塊——所以一本 500,000 字元的長篇在這裡是付款前就看得到的一次性約 $4.75。