TranslateBooksWithLLMs：把整本书交给 LLM 翻译时的工程取舍
Translate full-length books and documents with Ollama, OpenAI-compatible, Gemini, Mistral, DeepSeek, Poe or OpenRouter. Preserves formatting. Resumes where you left off. No file size limits.
秒懂
- 它是什么？
- 这是一个用本地或云端大模型翻译 EPUB、SRT、DOCX、TXT 的桌面工具，卖点是分块、断点续传和格式保留。它解决的是长文档翻译的工程问题，而不是翻译质量问题，这两件事需要分开判断。
- 适合谁用？
- 如果你的工作流是把整本 EPUB 或整份 SRT 交给模型逐段翻译，并且中途断掉不能从头再来，这个工具值得先跑一本短书验证；如果你只需要翻译几段文本、或者要求译文经过人工逐句校对后再交付，用 API 脚本反而更直接。上手前先确认三件事：目标模型是否在你的 provider 列表里可用（Ollama 需先 ollama pull，云端需对应 API key），EPUB 的样式与结构在输出文件里是否完整，以及你能否接受 AGPL-3.0 对分发和网络服务的要求。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的不是翻译问题，是长文档的调度问题
把一段文字丢给大模型翻译，任何人都能做。把一本四百页的小说丢进去，问题立刻变成另一类：上下文窗口装不下，一次请求必然要切分；切分之后，段落之间的指代、人称、术语会漂移；请求发到一半网络断了或者额度用完，前面几小时的算力白费；EPUB 里的章节结构、脚注链接、样式表在往返过程中很容易被压平。README 里列出的四个卖点，无大小限制、格式保留、随时续传、可复用文风，全部指向第二类问题。
目标用户因此相当明确：手里有整本书、整季字幕或整份合同要处理，又愿意自己配模型和 API key 的人。它不是给偶尔查一句话的人用的。README 把 EPUB、SRT、DOCX、TXT 四种格式并列，其中 SRT 的存在说明它也在意字幕场景，时间轴同步是字幕翻译里最容易出错的地方，README 声称时间戳保持不变。
分块、checkpoint 与文风预设：三个机制串起来看
README 对内部实现的描述很克制，能确认的是这几件事。文档被切成块（chunk），块与块之间保留上下文，这是所谓 intelligent chunking system 的说法；进度以 checkpoint 形式自动保存，中断后从上次的位置继续；文风以 preset 的形式存在，可以从样本书里抽取，也可以手写，然后应用到每一个块上，目的是让整本书的语气、节奏和意象保持一致。
把这三者放在一起看，逻辑是自洽的：分块保证单次请求不超限，checkpoint 保证长任务可恢复，文风预设用来对抗分块带来的风格漂移。最后一点是这个项目比较少见的设计，多数翻译脚本只传递上一段的译文作为上下文，而它把风格做成了可复用的独立对象。
术语表（glossary）的处理也值得注意。README 说明，如果没有现成的术语表或预设，可以在下拉框里选 Auto，应用会在正式翻译开始前，从待翻译文档本身各做一次额外的 LLM 调用，推导出术语表和文风，且不保存到磁盘。这是对冷启动问题的务实处理，代价是每次任务多两次调用，而且推导结果不可复用，换一本书要重新推。对于术语密集的技术书或系列小说，手动维护一份术语表仍然更划算。
从 release 包到命令行：两条上手路径
最省事的路径是直接下 release。README 给出 Windows、macOS Intel、macOS Apple Silicon 三个压缩包，解压后运行 TranslateBook.exe 或 ./TranslateBook，然后在浏览器打开 http://localhost:5000。首次启动会创建 TranslateBook_Data 文件夹存放设置，macOS 首次运行需要在系统设置里手动允许打开。注意它是本地起了一个 Web 服务，界面在浏览器里，不是传统的原生窗口程序。
从源码安装的路径 README 也写了：需要 Python 3.8+、Ollama 和 Git，克隆仓库后进入目录，执行 ollama pull qwen3:14b 拉模型，Windows 跑 start.bat，Mac 和 Linux 用 chmod +x start.sh && ./start.sh，界面同样在 5000 端口。
命令行入口是 translate.py，参数形式在 README 里给了完整示例。基本调用是 python translate.py -i book.epub -sl English -tl Chinese，输出文件名会自动生成为 book (Chinese).epub。切换 provider 用 --provider，配合各自的 key 参数和 -m 指定模型，例如 --provider openrouter --openrouter_api_key YOUR_KEY -m anthropic/claude-sonnet-4，或者 --provider gemini --gemini_api_key YOUR_KEY -m gemini-2.0-flash。本地 OpenAI 兼容服务（llama.cpp、LM Studio、vLLM、LocalAI）指向自己的 endpoint 即可。
provider 覆盖面是它相对同类工具的主要优势：DeepSeek、Gemini、Mistral、NVIDIA NIM、OpenAI、OpenRouter、Poe，加上本地的 Ollama 和任意 OpenAI 兼容服务。README 指向 docs/PROVIDERS.md 看详细配置，排障则指向 docs/TROUBLESHOOTING.md，其中列出的两个典型问题是 Ollama 连不上（先用 curl http://localhost:11434/api/tags 确认服务在跑）和模型不存在（先 ollama list 再 ollama pull）。
README 没有回答的问题
这份材料对失败路径的描述偏薄，有几处需要你自己验证。
分块策略的具体边界没有公开。块多大、按段落还是按字符切、上下文窗口里究竟保留了前面多少内容，README 只说 intelligent 和 preserves context。这直接决定了译文里指代会不会错乱，也决定了长书的 API 成本，因为重叠的上下文意味着重复计费。
格式保留的验证方式没有给出。EPUB 的样式和结构、SRT 的时间码，README 用的是断言式表述，但没有说明哪些元素会被保留、哪些会被丢弃。EPUB 内部差异极大，固定版式的书和纯流式排版的书写法完全不同，脚注、交叉引用、图片说明这些边缘元素的表现需要实测。
成本没有估算。README 提到云端 provider 常常有免费额度，但一本几百页的书要发多少次请求、每次带多少上下文，材料里没有数字。用本地 Ollama 就没有这个问题，代价是速度和显存。
翻译质量本身不在这个项目的责任范围内。README 把模型选择指向 wiki 里的 Translation Quality Benchmarks，等于承认译文好坏取决于你接的是哪个模型。这一点应该被明确说出来，而不是让用户以为装上工具就有好译文。
什么时候该用别的方案
最直接的替代不是另一个同类工具，而是自己写脚本调 API：读文件、切段、循环请求、拼回原格式。几十行代码就能覆盖基本流程，好处是完全可控，坏处是 checkpoint、格式往返、provider 抽象、术语一致性这些都要自己写，而这几件事恰好是这个项目的主要工作量所在。如果你只翻译一次、文档不长、也不需要中途恢复，自写脚本更省事。
另一类是专业的本地化工具链，比如围绕 XLIFF 或 TMX 构建的翻译记忆系统。两者的方法论差别很大：翻译记忆靠句段复用和人工确认，译文可追溯、可审校，适合有术语规范和交付要求的商业项目；这个项目靠模型逐块生成，没有句段库，没有审校环节，改一个词要重跑对应的块。图书、字幕这类以可读性为目标的长文本，前者的优势不明显，后者的速度优势明显。反过来，需要术语一致性证明的文档，这个工具目前给不了。
还有一类是通用文档翻译服务。它们的差别在于你不控制模型，也不控制数据流向。这个项目支持 Ollama 和本地 OpenAI 兼容服务，这一点对不便外发的稿件是实质性的区别。
维护成本与 AGPL-3.0 的实际含义
从仓库信息看，项目处于活跃维护状态，最近的版本是 v1.5.10，2026 年 9 月发布，此前 v1.5.8 和 v1.5.9 在 8 月下旬相隔数小时发布，说明修复节奏较快。默认分支 main，未归档。对使用者来说，这意味着接口和参数可能随版本调整，命令行参数和配置文件格式在升级时需要重新核对。
真正的长期成本来自 provider 侧。云端模型的名称和可用性会变，README 示例里的模型标识（如 deepseek-v4-pro、anthropic/claude-sonnet-4）属于示例，实际可用性要看你调用时的服务状态。本地 Ollama 模型也一样，换模型意味着译文风格会变，同一本书前后两次翻译可能不一致。升级前值得先在短文档上跑一遍，确认 CLI 参数没有变化。
许可方面，项目采用 AGPL-3.0。这对个人使用和内部使用通常没有额外要求，但如果你修改代码后通过网络向他人提供服务，AGPL 的传染性条款会要求你公开修改后的源码。把它集成进闭源产品再对外分发，需要先确认合规路径。这里只陈述许可证标识，具体适用请咨询法务。
判断是否采用，看这三件事
第一，你的输入格式是否落在 EPUB、SRT、DOCX、TXT 这四类里。其他格式（PDF、MOBI、ASS 字幕）不在 README 列出的范围内。
第二，你是否需要中断恢复。这是它相对自写脚本最实在的差异。一本几百页的书在云端跑几个小时，任何一次网络抖动都可能让进度归零，checkpoint 的价值在这里。如果你用的是本地模型、任务能在一次会话里跑完，这个优势会缩小。
第三，你对译文一致性的容忍度。文风预设和术语表是缓解手段，不是保证。系列小说、技术手册这类对术语敏感的文本，建议先用 Auto 模式跑一章，检查推导出的术语表是否可用，再决定是手工维护还是直接开始。README 明确说 Auto 模式推导出的内容不会保存，所以它只能作为一次性的起点，不能当作可积累的资产。
编辑结论
如果你的工作流是把整本 EPUB 或整份 SRT 交给模型逐段翻译，并且中途断掉不能从头再来，这个工具值得先跑一本短书验证；如果你只需要翻译几段文本、或者要求译文经过人工逐句校对后再交付，用 API 脚本反而更直接。上手前先确认三件事：目标模型是否在你的 provider 列表里可用（Ollama 需先 ollama pull，云端需对应 API key），EPUB 的样式与结构在输出文件里是否完整，以及你能否接受 AGPL-3.0 对分发和网络服务的要求。最后一点最容易被忽略：翻译质量取决于你选的模型，这个项目负责的是流程，不是译文。
社区笔记