translate-book 的意义：把长文档翻译从一次性提示词变成流水线

长文档翻译最容易被低估。几页文章可以靠一次提示词解决，整本书不行。真正的问题是格式转换、分块策略、术语一致性、中断续跑、输出合并和最终格式交付。translate-book 的价值正在这里：它把“让模型翻译一本书”拆成了可执行、可检查、可恢复的流水线。

deusyu/translate-book 是一个面向 Claude Code 的 Skill，官方描述是使用并行 subagent 将 PDF、DOCX、EPUB 翻译成任意语言。仓库主语言为 Python，MIT 许可，README 同时提供英文和中文说明。它受 claude_translater 启发，但不是 shell 脚本堆叠，而是把转换、chunk、术语表、状态记录、合并构建都放进一个更清晰的 Skill 编排中。

它解决的不是翻译能力，而是翻译过程管理

模型本身已经能翻译一段文字。难的是一百个片段之间保持一致，并在第 73 个片段失败时不用推倒重来。translate-book 通过 manifest.json 绑定源 chunk 哈希，用 source_fingerprint.json 绑定源文件字节，用 run_state.json 记录 chunk 与术语表关系。这些机制让它更像数据处理管道，而不是聊天窗口里的批处理。

这种设计尤其适合团队内部材料、开源书籍、培训手册、技术书草稿和多语言知识库迁移。它把一次不可控的大任务拆成多个小任务，每个小任务都有文件名、输入、输出和校验条件。

并行 subagent 的收益和代价

默认 8 路并发可以明显降低整书处理时间，也避免单会话上下文越来越长。但并行不是免费午餐。fresh-context subagent 缺少整本书记忆，可能造成叙事语气和术语漂移。translate-book 用两个补丁降低这个问题：邻居上下文和术语表。

邻居上下文给每个 chunk 提供前后片段的短摘录，用于代词和实体判断；术语表则把高频专名和领域术语注入每个相关 chunk。二者都不完美，但比完全孤立地批量翻译可靠得多。

真正的边界在输入质量和审校

PDF 转 Markdown 从来不是纯净过程。页码、页眉、脚注、双栏排版、扫描 OCR、图片标题都可能污染 chunk。translate-book 依赖 Calibre 和 Pandoc 处理格式转换，这让流程具备广泛格式支持，但也意味着输入质量决定了后续翻译质量上限。

因此采用它时要把“预处理检查”列为正式步骤：先看 input.md 和前几个 chunk 是否干净，再开始大规模翻译。完成后也不要只检查最终 PDF 是否生成，而要抽查 output.md、术语表命中和章节连续性。

适合采用的团队

• 需要批量翻译长文档，并且能接受人工抽检。
• 已有 Claude Code 或 OpenClaw/Codex 类 agent 工作流。
• 愿意安装 Calibre、Pandoc、Python 依赖并维护本地环境。
• 希望输出 HTML、DOCX、EPUB、PDF，而不是只要一段 Markdown。

不适合的场景也很明确：机密书稿没有数据出境方案、版权不清晰、格式复杂到需要专业排版、或只需要翻译几页短文。这些场景里，translate-book 的流水线成本可能高于收益。

判断它是否成熟，要看校验机制

一个长文档翻译工具最重要的不是宣传“并行”，而是失败时能不能解释发生了什么。translate-book 的 manifest 校验、空输出检查、源文件指纹、术语影响重译、最终多格式构建，是它最需要认真评估的部分。它把 AI 翻译从一次性生成，往可运营的内容工程推进了一步。