DeepSeek 翻譯實測：哪些情況可行，哪些情況會出錯

DeepSeek 是便宜且能力不錯的長文本翻譯工具，尤其是透過 API 使用時。它的弱點不在多數評測會測試的地方。根據我們的經驗，問題很少是句子不通順，而是輸出看似完成卻不然：漏掉粗體字、程式碼範例被翻譯、出現錯誤書寫系統的字元，或是為了滿足修正要求而重複句子。把一段文字貼進聊天視窗時，這些問題都不會出現；但翻譯整份文件時，全部都會浮現。

我們會知道這些，是因為 DeepSeek 負責翻譯這個網站。2026 年 10 月，我們把產出在地化文章（27 種語言）與介面文字的流程，從另一個模型切換到 DeepSeek API，此後每一筆新增或修復的翻譯都出自它。以下是初期執行時出錯的地方、我們加入的檢查、以目前 API 價格計算一本書的翻譯成本，以及 DeepSeek 不再適用的情況。

關於 DeepSeek 模型、價格與政策的事實，來自 DeepSeek 自家文件，查核日期為 2026-10-13。DeepSeek 經常更換模型與價格，因此依賴任何數字前請先查看連結。

DeepSeek 為翻譯提供的功能

有兩種使用方式，適合不同的工作。

兩種介面都不會回傳翻譯後的 EPUB、DOCX 或 PDF。你拿到的是文字，重建檔案是你自己的事。

我們在 DeepSeek 首次執行時遇到的五個失敗

我們的流程會將每個段落、標題或表格儲存格作為一個單位，分批送出，並要求以 JSON 格式回傳。每個回答都會經過檢查，只有在所有檢查都通過時，才會寫入本地化檔案。在 DeepSeek 首次對我們部落格的完整執行中，大多數工作都通過了，而大多數被拒絕的原因是機械性問題，而非翻譯品質不佳。以下是讓我們學到一些東西的案例。

1. 格式消失了，但文字是對的

在一篇阿拉伯語文章中，翻譯沒問題，但 not 的粗體不見了，所以句子失去了強調。在一篇荷蘭語文章中，一個粗體詞組回來時被拆成了兩個。除非你將標記與原文對照，否則這些讀起來都不像有錯。

修正方式： 翻譯後，每個段落都會重新解析，且必須包含與英文相同的連結、粗體詞組、行內程式碼和圖片，順序不限，因為其他語言會重新排列詞序。

這對你的意義： 如果格式在你的文件中帶有含義，例如粗體警告、連結或註腳標記，請在原文和譯文中都計算它們的數量。

2. 不該翻譯的東西被翻譯了

一篇馬來語文章中有一個來自字幕範例的行內程式碼範例 [door slams]。DeepSeek 翻譯了它。在一篇緬甸語文章中，程式碼片段中引用的日語句號 。 變成了緬甸語句號 ။。兩者對散文來說都合理，但對字面範例來說都是錯的。

修正方式： 行內程式碼必須與送出時完全一致地回傳。

這對你的意義： 告訴模型哪些字串是字面值，例如程式碼、檔案名稱、產品名稱和引用的範例，並在事後檢查它們。

3. 文字以錯誤的文字系統回傳

DeepSeek 在一個印地語句子中放入了一個孟加拉語單詞，並在一個緬甸語句子中放入了僧伽羅文字元。印地語和孟加拉語是近鄰。僧伽羅語和緬甸語則不是，這提醒我們無法預測這種情況會在何處發生。如果你不閱讀目標語言，抽查是無法發現的。

修正方式： 每個請求都會指明目標語言及其書寫系統，而不只是代碼（我們的請求讀起來像「Twi (locale code tw, written in the Latin alphabet)」）。然後，文字系統檢查會拒絕任何包含該語言不使用之文字系統字元的輸出。

這對你的意義： 寫「Translate into Brazilian Portuguese」，而不是「translate to pt」。如果你無法閱讀目標語言，至少檢查文字系統是否正確。

4. 重試重複了錯誤，或者「修正」得很糟

當檢查拒絕了一個回答時，以 temperature 0 重試會逐字回傳相同的錯誤答案，包括印地語中的孟加拉語單詞。低 temperature 會使輸出可重複，而這包括錯誤。模糊的拒絕訊息也沒有更好。有一次，被要求還原一個缺失的粗體詞組時，DeepSeek 在原始句子後面加上了整個句子的粗體副本。粗體回來了，而句子現在出現了兩次。

修正方式： 重試提示會確切指出缺失或意外的內容，例如「missing inline code 。」，之後的嘗試使用 temperature 0.4，最後的檢查會拒絕英文中沒有重複的句子。

一個相關的陷阱： DeepSeek 的思考模式預設為開啟，而在思考模式下，temperature 沒有效果（thinking mode）。我們透過 "thinking": {"type": "disabled"} 關閉思考來進行翻譯，這也減少了延遲。

5. JSON 有效，但鍵無效

我們送出編號單位，例如 body:0059，並要求回傳相同的鍵。有時 DeepSeek 會按正確順序回傳每個翻譯值，但將某個鍵重新命名為單純的 body，或新增了我們從未送出的鍵。JSON 解析成功了。一個天真的腳本會丟失或錯置一個段落。

修正方式： 只有在其他所有鍵都在預期位置時，才會按位置將重新命名的鍵匹配回去，而多餘的鍵會被忽略。

這對你的意義： 如果你用腳本進行翻譯，請在組裝文件之前，檢查你送出的每個單位是否都以其自己的 ID 回傳。

有一個教訓比 DeepSeek 更早出現。我們的流程過去會在每個連結和粗體詞組處分割句子，而我們在 DeepSeek 之前使用的模型不斷回傳空片段，例如「 for reading」，因為在目標語言中，它們的含義已經轉移到鄰近的片段中。任何模型都會這樣做。永遠不要送出半個句子。如果你要將一本書分塊，請在段落邊界處切割。

使用 DeepSeek 翻譯長文件的檢查清單

無論你是在聊天應用程式中操作，還是透過 API 撰寫腳本，都請採用以下做法：

1. 以段落或章節邊界為單位切分。 絕不拆分句子。讓每個請求都夠小，使翻譯輸出能穩妥地落在輸出上限之內。
2. 在每個請求中都放入詞彙表。 人名、自創術語和固定譯法都放在每個區塊的開頭。模型只看得到眼前的那個請求。
3. 用文字明確寫出語言和文字系統，再加上你想要的語域（正式、口語、文學）。
4. 如果你用腳本處理，就要求結構化輸出。 使用 API 時，將 response_format 設為 {"type": "json_object"}，在提示中寫入「json」這個詞，並展示你期望的確切格式（JSON 輸出）。
5. 將空白、遭截斷或無法解析的回應視為失敗。 達到 max_tokens 的回應會直接中斷，所以要檢查 finish_reason，而 DeepSeek 也指出 JSON 模式「偶爾可能回傳空白內容」（JSON 輸出）。遇到這兩種情況都應重試，而不是直接儲存。
6. 當重試以相同方式失敗時，就改變一些做法： 說明哪裡出了問題，並在非思考模式下提高 temperature。
7. 在你閱讀每個區塊之前，先以機械方式檢查： 沒有空白內容、沒有錯誤文字系統的字元、連結、數字和標題的數量都與原文相同。
8. 然後審查意義。 機械檢查能抓出損壞的輸出，卻抓不出誤譯。對於任何將要發布的內容，仍需由流利的讀者檢查人名、數字和語氣。我們的術語一致性指南說明了如何讓術語在各章之間保持一致。

一本書在 DeepSeek API 上的成本

API 夠便宜，所以成本很少成為決定因素。以下是將一本 100,000 字的英文書以 deepseek-flash 在尖峰價格下翻譯的粗略估計：每百萬輸入 token 為 $0.30（快取未命中），每百萬輸出 token 為 $1.20（定價）。

離峰費率是這個數字的一半。Token 比例因語言而有很大差異，所以請把這當成數量級，而不是報價。API 翻譯的真正成本是你的時間：撰寫切分邏輯、檢查機制，以及重建可用檔案的程式碼。

上傳前先檢查隱私

DeepSeek 的隱私政策（最後更新於 2026 年 2 月 10 日）表示，該公司「在中華人民共和國」收集、處理和儲存個人資料，並將訓練和改進其模型列為使用你提交內容的用途之一。政策中也列出退出訓練的權利，但你必須寄電子郵件給 DeepSeek 才能行使，而非透過應用程式內的設定（DeepSeek 隱私政策）。

對於合約、未出版的手稿或客戶檔案，請在上傳任何內容之前先做出決定。DeepSeek 的模型權重也可以由其他供應商代管，或在你自己的硬體上執行，屆時這些條款並不適用，但你得改為檢查該供應商的條款。文件翻譯隱私檢查清單列出了你應該向任何工具（包括我們的工具）提出的問題。

DeepSeek 何時是合適的工具，何時不是

哪個模型最能翻譯你的語言組合是另一個問題。我們的最佳翻譯 LLM 指南說明瞭如何自行測試。如果你正在聊天工具之間做選擇，ChatGPT、Claude和 Gemini指南分別針對每個工具涵蓋了相同的問題。

當你能看見並修正每一個失誤時，DeepSeek 就是合適的工具：無論是你會仔細閱讀的段落，或是由你掌控檢查環節的流程。當你想要一份完整翻譯檔案，卻不想建構那套流程時，它就不是合適的主要工具。那正是 BookTranslator 所做的工作。你上傳 PDF、EPUB、DOCX 或其他支援的檔案，它會帶著上下文與一致的詞彙表翻譯整份文件，然後你取回翻譯後的檔案，若格式支援，還會附上雙語版本。對於掃描的 PDF，OCR 模式會根據辨識出的內容重建一份乾淨的翻譯 PDF，而不是完全複製原始頁面版面。你在結帳前就能看到價格，因此可以上傳檔案後再決定。無論你使用哪種工具，重要內容都請保留人工審閱。