如何使用 Claude 進行翻譯:長篇文件、詞彙表與審閱
Claude 能讀完整本書,但其輸出上限、Projects 檢索機制與對話摘要功能會限制一致性。詞彙表該放在哪裡,以及如何分段處理。

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





