書譯
書譯

如何使用 Claude 進行翻譯:長篇文件、詞彙表與審閱

Claude 能讀完整本書,但其輸出上限、Projects 檢索機制與對話摘要功能會限制一致性。詞彙表該放在哪裡,以及如何分段處理。

BookTranslator

BookTranslator Team

19 min read

Claude 是翻譯長篇文件的章節、文章和段落的強大工具,其最新模型能在單一對話中讀完整本書。錯誤在於假設 Claude 能讀完整本書,就能翻譯整本書並保持一致。有三項有文件記載的行為會造成阻礙:Claude 單次回應的寫入量上限、檔案變大後 Projects 改為採用搜尋式檢索,以及長對話會被摘要以騰出空間。

這些都不是缺陷,而是 Claude 在處理大量輸入時保持可用的方式。但每一項都決定了你的詞彙表該放在哪裡,以及每次翻譯請求該多大。本指南涵蓋 Claude 應用程式(claude.ai、桌面版和行動版)以及 Claude API。以下每一項限制都來自 Anthropic 自家的文件,查核日期為 2026-10-12。Anthropic 經常更新這些頁面,因此在依據某個數字做規劃前,請先查看連結。

Claude 接受與回傳的內容

介面可上傳的內容可運用的上下文回傳的內容
對話上傳每個對話最多 20 個檔案,每個檔案 500 MB;PDF 最多 1,000 頁;支援 PDF、DOCX、EPUB、TXT、HTML 等格式付費方案:最新模型(例如 Opus 5.5 和 Sonnet 5.5)為 1M token,其他模型為 500K 或 200K對話文字,或 Claude 以程式碼產生的新檔案
專案檔案每個檔案 30 MB;總內容必須能放入上下文窗口,否則付費方案會改用 RAG與對話相同,付費方案另加檢索功能相同
Claude API每次請求的 PDF 最多 32 MB 和 600 頁(若請求的上下文窗口低於 1M 則為 100 頁)所有現行模型皆為 1M token文字;每次同步回應最多 128K 輸出 token

來源:將檔案上傳至 Claude、付費方案的上下文窗口、API PDF 支援,以及模型總覽。

這些頁面中有兩個細節對翻譯的影響比標題數字更大:

  • 只有 PDF 會以視覺方式讀取,而且僅限短篇。在應用程式中,Claude 會分析 100 頁以下 PDF 的文字,以及其中的圖像、圖表和圖形。從 101 到 1,000 頁,它只處理文字。對於 DOCX、EPUB 和其他非 PDF 檔案,Anthropic 表示 Claude「僅擷取文字」,無法讀取內嵌圖片。如果你上傳 300 頁的圖文 PDF 或 EPUB,請假設 Claude 只看到文字,而非版面、圖片中的說明文字或圖表。
  • Claude 可以回傳檔案,但那是全新的檔案。 開啟程式碼執行與檔案建立功能後,Claude 可以建立 Word 文件、PDF、試算表和簡報供你下載。這對簡短的翻譯文件很實用。但它仍是 Claude 透過撰寫程式碼所建構的文件,而不是將你的原始 EPUB 或 PDF 直接更換語言。你得自行檢查標題、註腳、圖片和頁面結構。

三種會破壞長篇翻譯的 Claude 行為

1. 決定區塊大小的是輸出上限,不是上下文視窗

Anthropic 列出目前每個 API 模型都有 100 萬個 token 的上下文視窗,以及 128K 個 token 的最大輸出量。Anthropic 自己的經驗法則是,以目前的 tokenizer 計算,100 萬個 token 大約相當於 55.5 萬個英文單字。按相同比例,128K 個輸出 token 大約是 7.1 萬個英文單字。這是我們根據 Anthropic 公布數據所做的推算,並非實測結果;如果你的目標語言每字需要更多 token,或者你要求翻譯時附帶註解,實際數字還會更低。

所以一部小說可以塞進 Claude 能讀取的範圍,卻無法在一次回應中全部寫回。翻譯的答案長度與原文相當,不像摘要那樣簡短。請根據你需要的輸出量來選擇區塊大小,而不是根據 Claude 能容納的輸入量。一次一章,或幾千個字,能讓每次回應遠低於上限,也讓每個審閱單位小到容易發現漏掉的段落。

2. 大型 Project 不會讀完整本書

Project 讓你上傳一次檔案,就能在不同對話中重複使用。在付費方案中,Anthropic 表示「當你的專案知識接近上下文視窗上限時,Claude 會自動啟用 RAG 模式」。在 RAG 模式下,Claude 不會載入每份文件。它會搜尋專案並擷取與你的要求最相關的部分(專案的 RAG)。你無法自行開啟或關閉這項功能。

對於針對一本書提問,這是合理的設計。但就翻譯一致性而言,這會改變你能依賴的東西。如果你上傳整本書、先前翻譯的章節,以及詞彙表檔案,然後要求第 14 章「與先前章節保持一致」,Claude 可能只會擷取其中一部分內容。這是我們根據 Anthropic 說明所做的推論,並非有紀錄的失敗率。這表示你不該指望大型 Project 能記得你在第 2 章如何翻譯某個角色的暱稱。

3. 長對話會被摘要

在開啟程式碼執行的付費方案中,Anthropic 表示當對話接近上下文上限時,Claude 會「摘要先前的訊息,以騰出空間容納新內容」(自動上下文管理)。你的對話紀錄會保留,對話也能繼續進行。但你在第一則訊息中貼上的詞彙表,到了第四十則訊息時可能只是根據摘要運作。Anthropic 也指出,這些較長的對話會用掉你更多使用額度。

詞彙表該放在哪裡

這張表是根據上述三種行為推導而來。這是 Claude 翻譯工作流程必須做對的主要決策。

位置是否總是呈現在 Claude 面前?用途
專案知識中的詞彙表檔案一旦 RAG 模式啟動就不是;只會載入被擷取的部分參考資料,例如原書和過往章節,供抽查之用
專案指示套用於該專案的對話;Anthropic 建議保持簡潔,用於關鍵準則和 Claude 的角色簡短的風格說明,以及 10 到 20 個絕不能更動的詞彙
每次翻譯要求的最開頭是,就該次要求而言該區塊完整的已核准詞彙表,加上該區塊本身的新詞彙
長對話中的第一則訊息不可靠;之後可能會被摘要沒有任何你依賴的內容
使用提示快取的 API 系統提示會,每次請求都會完整的詞彙表與風格簡報,以較低的輸入成本在許多區塊間重複使用

規則很簡單:翻譯必須遵守的任何內容,都要放進請求本身或指示中,而不是放進 Claude 可能不會取用的檔案裡。 專案知識用於 Claude 可能查閱的素材,而非規則。

長文件的實用工作方法

這是一套方法,不是基準測試結果。它將 Anthropic 文件記載的行為,轉化為你可以重複執行並稽核的步驟。請依你的方案與模型調整區塊大小。術語一致性指南說明了詞彙表應包含哪些內容。

  1. 凍結來源並為區塊編號。 以單一最終檔案為準。依章節或段落切分,而非依頁面,讓句子與註腳保持完整。將它們標記為 C01、C02 等,並記下每個區塊的第一句與最後一句。
  2. 在另一個對話中建立詞彙表。 上傳整本書,請 Claude 列出反覆出現的人名、地名、術語與稱謂,並附上建議譯法及每個詞首次出現的頁碼。這正是大型上下文視窗發揮價值之處:Claude 會完整讀過一遍。請合格人員審核這份清單。
  3. 設定專案。 將簡短的風格簡報與絕不可更動的術語放進專案指示。若希望 Claude 查閱上下文,可將來源檔案上傳為知識,但不要把完整詞彙表放進知識。
  4. 每個區塊或每幾個區塊使用一個對話。 每次請求都以完整的已核准詞彙表與該區塊開頭。請 Claude 以區塊 ID 開頭,並以 END C07 或對應的 ID 結尾,這樣一來,提早中斷的回覆就會很明顯。開啟全新對話可避免摘要內容滲入已執行數小時的對話串。
  5. 在繼續之前檢查每個區塊。 比對段落數,並確認來源的最後一句已有譯文。若缺少 END 標記,請重新請求該區塊,而不是從中段繼續。將任何新術語加入詞彙表、核准它,並納入後續請求。
  6. 在組裝後的譯文中搜尋偏移。 查核每個詞彙表術語與每個來源語言名稱。拼寫變體與殘留的來源詞語是常見的跡象。
  7. 請真人審閱高風險段落。 人名、數字、日期、否定語氣,以及任何法律、醫療或即將出版的內容,都需要合格的讀者。

如果你使用 API

同一套方法也很容易寫成指令碼,而兩項 API 功能有助於降低成本:

  • 提示快取讓你跨請求重複使用固定的前綴,例如含有完整詞彙表與風格簡報的系統提示。Anthropic 的快取讀取價格僅為基礎輸入價格的一小部分(根據模型總覽,Opus 5.5 與 Sonnet 5.5 為 5%)。
  • Message Batches API 的費用比標準請求低 50%,且 Opus 5.5、Sonnet 5.5 與 Haiku 5.5 在搭配 beta 標頭時,每個批次請求支援最多 300K 輸出詞元。批次適合區塊翻譯,因為詞彙表固定之後,區塊之間很少互相依賴。

這兩項功能都不會改變輸出:API 傳回的是文字。你仍然需要用它重建譯文文件。

經得起區塊切分的提示

使用與我們的 ChatGPT 翻譯指南及 Gemini 翻譯指南相同的四區塊結構,並加上區塊控制。Claude 自家的提示指引偏好清楚明確的指示,而加上標籤的區段能讓界線一目了然:

<task>
Translate chunk C07 from [source language] to [target language].
</task>

<audience>
[Who will read it and what they need to do with it.]
</audience>

<rules>
- Apply the glossary exactly. If a term is missing, keep the source term in
  [brackets] and list it after the translation as NEW TERM.
- Preserve names, numbers, dates, citations, and paragraph boundaries.
- Do not summarize, skip, or add explanations.
- Start with "C07". End with "END C07".
</rules>

<glossary>
[full approved term list]
</glossary>

<source>
[chunk text]
</source>

將審閱與翻譯分開。區塊完成後,開啟新的請求,附上來源區塊、譯文、詞彙表,以及一份簡短評分標準:遺漏、增譯、數字或名稱變更、詞彙表違規,以及語域錯誤。將 Claude 的發現視為待查核的事項,而非定論。與任何模型一樣,它可能漏掉錯誤,或誤判正確的選擇。就小說而言,章節之間的語氣偏移是與術語偏移不同的風險。AI 小說翻譯工作流程涵蓋了角色聖經與語氣測試。

上傳前先確認隱私設定

你的文件會受到什麼處理,取決於你的帳戶類型:

  • Free、Pro 與 Max:你的對話是否會被用於訓練 Anthropic 的模型,取決於「設定 > 隱私權」下的「協助改善我們的 AI 模型」設定(模型改善設定)。若你允許,Anthropic 可能會以去識別化形式保留新對話或接續對話的資料最多五年(資料保留)。若你不允許,Anthropic 表示現行的 30 天保留期仍會持續(消費者條款更新)。無痕對話不會被用於改善 Claude,即使該設定已開啟亦然(模型訓練)。被安全分類器標記的對話仍可能用於 Anthropic 的信任與安全工作。
  • Team、Enterprise 與 API:Anthropic 表示消費者訓練設定「不適用於我們商業條款所涵蓋的服務」,其中包括 Claude for Work 與 API 使用。請查閱你組織的協議,了解其保留條款。

對於合約、受 NDA 保護的手稿或客戶檔案,請在上傳任何內容之前先處理好這件事。文件翻譯隱私檢查清單列出了你應該向任何工具(包括我們的工具)提出的問題。

Claude 何時是合適的工具,何時不是

你最終需要的成果Claude更好的途徑
理解一本外語書或論文很適合:上傳它、提出問題、翻譯你需要的段落Claude 就足夠了
大型翻譯前的詞彙表與風格簡報非常適合:它可以一次讀完整本書先用 Claude,再由人工核准清單
某一章或短篇文件的譯文適合,但需搭配上述分段檢查Claude
一份簡短的翻譯 Word 或 PDF 檔案可透過建立檔案來完成;請手動檢查結構Claude,或者若樣式與表格很重要,可使用 DOCX 翻譯工具
整本書以翻譯後的 EPUB 或 PDF 形式取回並非為此設計:數十個分段、反覆貼上詞彙表,以及重建檔案檔案層級的工作流程,例如 EPUB 翻譯工具或 PDF 翻譯工具
將掃描書轉換為可閱讀的翻譯 PDF在應用程式中,可讀取最多 100 頁 PDF 的頁面影像;超過此頁數則僅讀取文字以 OCR 為基礎的 PDF 翻譯工具,可重建翻譯後的檔案

哪個模型最適合您的語言組合是另一個問題。我們的最佳翻譯 LLM 指南說明如何實際測試,而非盲目相信排行榜。

當您能看見並修正每一個錯誤時,Claude 就是正確的工具:您會仔細閱讀的章節、正在草擬的詞彙表,或正在審閱的譯文。但當工作涉及完整檔案時,它就不是主要工具。到了那個階段,您得手動管理分段、詞彙表、結束標記和版面配置。這正是 BookTranslator 所擅長的工作。您上傳 PDF、EPUB、DOCX 或其他支援的檔案,它會運用上下文和一致的詞彙表翻譯整份文件,然後回傳翻譯後的檔案,若格式支援,還會附上雙語版本。對於掃描的 PDF,OCR 模式會根據辨識出的內容重建乾淨的翻譯 PDF,而非完全複製原始頁面版面。結帳前您就能看到價格,因此可以先上傳檔案再決定。無論使用哪種工具,對於重要內容,請保留上述的審閱步驟。

相關文章