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。