在聊天窗口里翻译一段话，流程很简单：粘贴原文，提出翻译请求，检查结果。整本书的工作量则完全不同。你需要记录各个章节的进度，保留原文，在不同会话中沿用统一的译法，最后还要把译文整理成一个能读的文件。
不要以为能接收长文档，就一定能得到一本完整译好的电子书。能输入多少内容、一次回复能返回多少、以及如何打包成 EPUB，是三个独立的问题。设计工作流之前，先查清当前产品文档写明的限制和你账号的实际情况；本文不规定固定的页数或上下文长度上限。
给每个章节一个固定编号
保留一份未改动的原文和一份工作副本。按有意义的边界切分文本，比如按章或按内容完整的节，不要为了凑某个字数从句子中间截断。
为每一节记录编号、原文的首句和末句，以及处理状态。返回的译文用同一个编号保存。一张写着“第 3 章第 2 节”的表格，比一串叫“继续翻译”的聊天记录好核对得多。
如果你把相邻段落也放进去帮助理解上下文，要标明哪部分是背景、哪部分需要翻译。否则重叠的内容会在最终成书时重复出现。拼接各节之后，再检查一遍边界。
整理一份简短的译名和文风备忘
准备一份简短的说明，写清主题、人名译法、反复出现的术语和语气。只有对照原文确认过的决定才写进去。不要指望自己记得之前每一次讨论。
一条示例指令可以这样写：
把下面这一节翻译成英文，不要概括。人名保持原样。机构统一用已确定的译名“Coastal Council”。相邻段落只作背景参考，请翻译标记出的部分。
然后拿结果和原文对照。写了“不要遗漏”并不等于真的没有遗漏。要核对数字、否定表达、对话归属，以及每一节的首句和末句。
涉及私密材料时，上传或粘贴之前先看清实际所用服务和账号的数据条款。源文件在本地，不代表聊天处理也在本地。隐私检查清单列出了需要问清楚的问题。
把产品当前的限制与方法分开看
OpenAI 的 API 文件输入文档讲的是 API 的处理方式，包括文件内容如何进入模型请求。这些 API 规则不能代替 ChatGPT 自己当前的账号和上传规定。同样，也不要以为订阅了消费版服务就能覆盖另一套 API 工作流。
不要照搬旧文章里“所有模型都能处理固定页数”的说法。页面密度各不相同，功能也在变化，上传一本书之后，可能仍然需要把请求拆成范围明确的几段。设计章节记录时，要能发现输出不完整的情况，而不是相信一句“把全部内容都翻译了”的笼统承诺。
动手前先规划 EPUB 重建
一段翻译好的文本回复并不是完整的 EPUB。你还需要章节结构、目录导航、图片、图注、注释和元数据。如果在提取文本时把这些结构丢掉了，重建它们可能成为整个项目中最耗时的部分。
用合适的电子书编辑器或转换工具，并保留原始排版以便对照。拼装完成后检查资源链接和注释跳转。必要时用外部工具验证结果，再用你打算使用的阅读器打开。
| 工作项 | 需要保留的内容 |
|---|---|
| 分节翻译 | 原文与译文一一对应，并标明边界 |
| 术语译法 | 一份经过核对的简短命名与风格说明 |
| 成书拼装 | 标题、章节顺序、图片、注释和链接 |
| 最终检查 | 一份清单，列出已核对和尚未解决的段落 |
与基于文件的 EPUB 工作流对比
直接用 EPUB 翻译工具，可以省去手动提取和拼装。在 PDF Craft 中，上传完整可用的 EPUB，选择目标语言和译文或双语输出，填写说明，然后下载处理好的文件。双语输出会把译文放在每段原文之后。
这并不能保证上下文完美，也不保证达到专业文学翻译的水准。重要段落、反复出现的人名和目录导航仍然需要你检查。新用户会获得试用额度，处理按用量计费，详见价格。
如果工作的核心是逐段交互打磨，而且你愿意围绕聊天工具来管理整本书，就选聊天式流程。如果主要交付物是一本可以继续阅读的 EPUB，就选基于文件的流程。Google 翻译 EPUB 指南讨论了类似的拼装取舍，韩语书籍翻译则侧重语言层面的连贯性检查。