在對話中翻譯一段文字，流程並不複雜：貼上原文、請對方翻譯，再檢查結果即可。整本書的工作量完全不同。你必須追蹤各段落、保留原文、讓跨對話的決定保持一致，最後還要組裝成可讀的檔案。
別以為能上傳長篇文件，就一定能得到翻譯完整的電子書。可輸入的容量、單次回覆能輸出多少內容，以及把結果包裝成 EPUB，是三個不同的問題。設計流程之前，請先確認目前產品文件記載的限制與你帳戶的實際額度；本文不規定固定的頁數或上下文上限。
為每個段落建立固定的識別方式
保留一份未經更動的原始檔，另存一份工作副本。依章節或內容完整的區段來切分文本，不要為了湊到某個大小而在句子中間截斷。
為每個段落記錄識別碼、原文首句與末句，以及處理狀態。回傳的譯文以相同的識別碼存檔。用「第 3 章第 2 節」這樣的表格來核對，遠比面對一串名為「繼續翻譯」的對話紀錄容易得多。
如果附上相鄰段落來釐清上下文，請標明哪些文字只是背景、哪些才要翻譯。否則重疊的部分可能在最終成書時變成重複內容。合併各段落後，記得檢查接縫處。
整理一份簡短的譯名與文風備忘
寫一份精簡的備忘，列出主題、慣用譯名、反覆出現的術語與語氣。只有在對照原文確認某項決定後，才更新這份備忘。不要憑印象假設對方記得先前每一次討論。
假設的指令可以這樣寫：
請將以下段落翻譯成英文，不要摘要。人名保持原樣。機構一律使用已定的譯名「Coastal Council」。相鄰段落僅供參考，請只翻譯標示的區段。
接著把結果與原文比對。要求「不要遺漏」並不能證明真的沒有漏譯。請檢查數字、否定語氣、對話的說話者標示，以及每個段落的首句與末句。
若內容涉及私人資料，上傳或貼上之前，請先查閱該服務與你帳戶實際的資料條款。原始檔放在本機，不代表對話處理也在本機進行。隱私檢查清單列出了該問的問題。
把產品目前的限制與方法分開看
OpenAI 的 API 檔案輸入文件說明的是 API 的處理方式，包括檔案內容如何進入模型請求。這些 API 條件不能取代 ChatGPT 本身目前的帳戶與上傳規則。同樣地，也不該假設一般訂閱方案涵蓋另一套 API 工作流程。
不要照抄舊文章的說法，宣稱所有模型都能處理固定頁數。頁面的文字密度各不相同，功能會變動，上傳一本書之後，可能仍需要把請求拆成範圍明確的小段。設計段落紀錄時，要讓自己看得出輸出是否只完成一部分，而不是相信一句籠統的「全部翻好」。
開始之前先規劃 EPUB 重建
翻譯好的文字回覆並不是完整的 EPUB。章節結構、目錄導覽、圖片、圖說、註釋與中繼資料都還需要處理。如果在擷取內容時把這些結構丟掉，重建往往會成為整個專案最耗時的部分。
請使用合適的電子書編輯或轉檔工具，並保留原始版面供對照。組裝完成後，檢查資源連結與註釋的跳轉目標。必要時用外部工具驗證，再放進你打算使用的閱讀器開啟。
| 工作項目 | 需要保留的內容 |
|---|---|
| 段落翻譯 | 對應的原文與譯文，並標明界線 |
| 術語譯法 | 一份經過核對的簡短譯名與風格備忘 |
| 成書組裝 | 標題、章節順序、圖片、註釋與連結 |
| 最後校對 | 已檢查與尚未解決的段落清單 |
與以檔案為基礎的 EPUB 流程比較
直接使用 EPUB 翻譯工具，可以省去手動擷取與組裝。在 PDF Craft 中，上傳完整且可用的 EPUB，選擇目標語言與譯文或雙語輸出，加入指示，然後下載完成的檔案。雙語輸出會把譯文接在每段原文之後。
這並不保證上下文完美，也不保證達到專業文學譯作的品質。重要段落、反覆出現的人名與導覽結構仍需自行檢查。新使用者會獲得試用額度，處理費用依用量計算，詳見價格方案。
如果工作的核心是逐段來回討論，而且你願意自行打理整本書的流程，就選擇對話式做法。如果主要目標是取得一本能繼續閱讀的 EPUB，就選擇以檔案為基礎的流程。Google 翻譯 EPUB 指南說明了類似的組裝取捨，韓文書籍翻譯則著重於針對特定語言檢查前後連貫。