PDF 翻譯 Part 04

今天無意間將 PDF Viewer 縮小，過了一陣子可能是 10 分鐘以上？此時可以從工作管理員看到，原本占了 6G 多的記憶體會剩下不到 1G。如果再把 app 叫回前景，隨意操作一下，記憶體仍然未回到 6G 多！

我想這應該是程式哪邊有 Bug？

回家後馬上問一下 AI，他也很快的找到問題所在。

有時候我還真搞不懂大語言模型為什麼這麼神奇？

二十年累積的東東好像跟屁沒兩樣？

還好我不會有什麼 AI 焦慮，我只會擔心 Vim 功力退步很多XD

如果可以不用工作，我一定要好好把 Vim 學好！

PDF 翻譯 Part 03

果然是因為 PDF 翻譯工具在翻譯時，同時又在開發 PDF Viewer，才導致記憶體爆掉。

目前使用 Python + Qt 開發的 PDF Viewer，開啟一個快 900 頁的 PDF，全部就佔了快 7G 記憶體，難怪昨天程式會當機。

今天使用 PDF Viewer 閱讀有翻譯圖層的 PDF，果然好用，隨時可以按下快速鍵拿掉圖層閱讀原文內容。

晚上又加了一些功能，除了開啟快 900 頁的 PDF 要 3 秒外，其他沒有甚麼好挑剔的。

應該不會開發新功能了，Unix 哲學，一次只做一件事，把事做好。

兩天統計，全部花了約 2800 萬個 token，換算約美金 17 塊。

花錢的翻譯果然還是比免費的 Google 翻譯好，美金 7 塊多很值得。

可惜的是昨天翻了 2000 頁的內容，因為當機一頁都沒留下，白白花了約 23 塊美金，有空再來改進他。

不得不說，原來這就是用嘴巴 Coding 的感覺。

PDF 翻譯 Part 02

前天使用自製工具翻譯了一份文件，大概快 900 頁，下面是 API 使用情況。

=== Summary ===

Paragraphs translated : 4186

Input tokens          : 211,790

Output tokens         : 302,468

Estimated cost        : $7.0905 USD

還不賴，比一本書便宜。

另外，PDF 翻譯工具需改進，一個是動態調整 RPM 限制，另一個則是要考慮如何保存中間結果。

因為我遇到一個 5000 頁的文件，做到約 2250 頁時，系統當機，應該是我同時做很多事，導致記憶體用到快 16 G。

AI 給的 RPM 修改建議方向

先做：查你目前的狀態（5 分鐘）

查 Tier 在哪裡

方法 1：Console 介面

1. 登入 console.anthropic.com
2. 左側選單 → Settings → Limits（或 Plans & Billing）
3. 會看到「Tier 1 / 2 / 3 / 4」字樣，以及對應的 RPM、ITPM、OTPM 數字

方法 2：用 curl 直接問 API（更準）

打開 cmd 或 PowerShell，把 YOUR_KEY 換成你的 API key：

curl https://api.anthropic.com/v1/organizations/rate_limits ^
  -H "anthropic-version: 2023-06-01" ^
  -H "x-api-key: YOUR_KEY"

回傳的 JSON 裡會直接告訴你每個模型的 RPM/ITPM/OTPM，對照下面的表就知道 Tier：

Tier	Sonnet RPM	Sonnet ITPM
1	50	30,000
2	1,000	80,000
3	2,000	800,000
4	4,000	2,000,000

查 prompt caching 有沒有開

直接搜你的翻譯工具程式碼，看 system 那段：

# 在你的翻譯工具資料夾
findstr /S "cache_control" *.py

• 有輸出 → 有開 caching
• 沒輸出 → 沒開 caching

或更簡單：跑一次翻譯，在你的程式裡 print 出 response.usage，看有沒有這兩個欄位：

• cache_creation_input_tokens（第一次跑會有）
• cache_read_input_tokens（第二次以後會有）

兩個都是 0 → 沒開 caching。

---

然後：直接用 Batch API 改造你的工具

既然你選「注重速度，可以掛著等」，Batch API 是完美解答。我直接幫你準備好可以丟給 Claude Code 的修改說明。

Batch API 對你的好處（再次確認）

• ✅ 不受 RPM 限制 — 5,000 段一次提交也沒事
• ✅ 價格 5 折（input 和 output 都打 5 折）
• ✅ 24 小時保證，實測通常 1–2 小時
• ✅ 與 prompt caching 可疊加（更便宜）
• ⚠️ 結果是「全部一起回」，不能邊跑邊看
• ⚠️ 中途無法取消個別請求

---

改完之後的預期效果

以你 800 頁論文為例：

方案	時間	你需要在電腦旁
現況	~4 小時	全程
+ Prompt caching	~3 小時	全程
+ Tier 升級 (-> 2)	~30 分鐘	全程
改 Batch API	1–2 小時	0 分鐘（掛著等）
Batch + Tier 升級	1–2 小時	0 分鐘

Batch API 對你的價值不只是「快」，而是「解放你的時間」 — 提交完就可以關電腦睡覺，醒來結果就在那。

成本方面：800 頁論文（假設 50 萬 input tokens、20 萬 output tokens）大致估算：

方案	預估成本（粗估）
現況	~$4.50
+ Caching	~$3.00
+ Batch API	~$2.25
Caching + Batch	~$1.50

數字僅供參考，實際看你的文件密度。改完最多省 2/3 成本，外加 4 小時變 1-2 小時、還不用顧。

---

給你的執行順序建議

1. 先查 Tier（用上面 curl 或 console）
2. 新開 Claude Code session，把你的翻譯工具資料夾打開，把上面那段 prompt 貼進去
3. 試跑一份小檔案（10-20 頁）驗證 batch 流程沒問題
4. 正式跑 800 頁那份，掛著去睡覺
5. 醒來檢查結果，用我們之前規劃的那個 PDF Compare Viewer 並排看 Google Translate 版 vs Claude API 版

整個工作流就完整了。

原來之前都在玩玩具

難得本週不用推 Code，於是便想繼續完成 PDF 翻譯相關的想法。

途中好奇，想要自己寫個 PDF Viewer 好方便我比較不同 Translator API 的差異，跟 Web Claude 討論的結果，他也覺得自己寫會比現成的方便，於是我就請 Web Claude 規劃，分階段實作及驗收。

目前來到 M3 階段，終於第一次碰到 Limit 限制，提示我必須等到 11:50 AM 過後才能繼續。

抓個圖留作紀念。

Web Claude 使用多少 token 未知，但本機用量如下。

Claude 各方案比較

限制詳細說明

API 使用限制

Pro 5 小時上限估計

換算成實際工作比較

AI 給的建議

給你的實戰建議

根據這些數字，Pro 規劃工作流的原則：

1. 開新對話的時機

• 對話超過 20-30 輪就考慮開新對話
• 任務切換時開新對話（不要在同一對話跨多個專案）
• 把當下對話的「結論」貼到新對話起頭，可以用很少 tokens 換到清爽 context

2. 模型選擇策略

• 日常對話、寫文件：用 Sonnet（你目前模型 Opus 4.7 約 5x 貴）
• 複雜推理、艱難 debug：才用 Opus
• 如果只是「優化措辭」之類的小任務，可以切到 Haiku

3. 上傳檔案的成本意識

• 一份 800 頁 PDF（你的論文）一上傳可能就 200-400K tokens，超過 Pro 5 小時池子十倍
• 大檔案優先用 API 處理（你的翻譯工具就是對的方向）
• 想討論大檔內容，先用工具抽出關鍵段落，貼進 Claude 對話

4. 你目前的工作流估算

你過去這 6-7 輪我們的對話，加上 spec / prompts 文件產出，大概用掉 30-50K tokens。 意思是：這種「規劃 + 寫規格」的對話，一次 5 小時的 Pro 配額大概可以撐 2-3 個專案。

但如果你還要同時用 Claude Code 開發那個 PDF Viewer，Claude Code 燒很快（一次 1-2 小時的開發就可能吃完 5 小時池子）。

5. 撞牆時的判斷

情境	建議
每週撞 5 小時牆 1-2 次	改用「開新對話」「換 Sonnet」習慣
每週撞 3+ 次	認真考慮 Max 5x（$100），ROI 大幅提升
Claude Code 一天用 4+ 小時	Max 5x 起跳，重度的話 Max 20x

---

給你的核心收穫

Pro 5 小時 ≈ 44K tokens ≈ 30-50 則中等對話，這是你規劃工作的心理基準。

實務上你可以這樣抓：

• 「跟 Claude 規劃個東西、寫個規格」→ 30-50K tokens，剛好用滿 5 小時池子的一半到全部
• 「用 Claude Code 做半天開發」→ 容易撞牆
• 「上傳大檔深度分析」→ 一次就用很多，挑著用

如果你想更精確地監控，可以在 claude.ai 設定裡看 Usage 頁面（如果有開放給 Pro），或在 Claude Code 裡跑 /status 看當下用量。

PDF 翻譯 Part 01

很多技術文件都是英文，無奈個人英文差，常常自以為的解釋其實跟原文差了十萬八千里XD

上星期突然想到是否可以請 Claude Code 寫個程式來幫我翻譯？

之所以要這麼搞剛，是因為 Web AI 都聽不懂人話居多，請他逐字逐字翻譯，結果都無法照做？當然也有可能是我不會用導致？不過，我並沒有用其他第三方的 AI 網站，而是直接使用我有訂閱的 Gemini 或是 Claude。

一開始 Claude 就知道要用 PyMuPDF 來處理 PDF，不過，對於圖表或是程式碼的判斷差強人意。

隔天有空搜尋了一下，原來這套函式庫非常有名，大家都是使用他來處理 PDF。

官方也很貼心的提供一個範例，並將翻譯過的內容使用圖層的方式貼到原本文字上，這意味著當翻譯不好時，我們隨時可以關掉圖層直接看原文，這實在是很方便的一個功能。

於是我第二版的程式就以官方範例為底稿，直接請 Claude Code 增添功能。

配合圖層的設計，終於我也有一個堪用的 PDF 翻譯工具了。

過程中，也釐清了一些我原來不懂的問題。

也許網路上還有更好的解法，但現在的方法對我來說已經夠用了，缺點就是要花時間把手邊一些文件重新翻譯。

NotebookLM 不是說不好，但有些時候，你還是需要閱讀原文才知道 AI 是不是有誤會什麼？

下面節錄我請 AI 整理的報告內容

七、關於 PDF 格式語意結構的討論

--------------------------------

問：check.py 都是自己判斷格式，是 PDF 格式沒有定義，還是函式庫的問題？

答：主要是 PDF 格式本身的設計所致，與函式庫（PyMuPDF）無直接關係。

  PDF 的設計初衷是「視覺呈現」，儲存的是：

    - 文字的座標、字型、大小

    - 圖片像素資料

    - 向量圖形繪圖指令

  PDF 格式本身不儲存語意結構，不知道「這段是頁首」「這段是程式碼」。

  PDF 有一個選用規格稱為 Tagged PDF（PDF/UA），允許文件作者加入語意標籤：

    <H1> 章節標題 </H1>

    <P>  段落文字 </P>

    <L>  清單（項目符號）</L>

    <Table> ... </Table>

  PyMuPDF 可以讀取這些標籤，若 PDF 有正確標注則不需要啟發式規則。

  本文件的實際情況：

    - 產生工具：PDFium

    - Tagged PDF：否（未加語意標籤）

    - PyMuPDF 回傳的 XML 標籤（block、line、char）是函式庫自行解析的

      幾何結構，並非 PDF/UA 語意標籤

    - 結論：PyMuPDF 無從得知各 block 的語意角色，因此必須以啟發式

      規則（正規式、座標範圍、關鍵字）自行推斷

  簡言之：這是絕大多數市面上 PDF 的共同現況，並非 PyMuPDF 的限制。

八、目前已知限制與未來改進建議

--------------------------------

  1. 項目符號：僅跳過 • 等符號開頭的 block，若使用其他少見符號需手動擴充

     BULLET_PATTERN。

  2. 程式碼偵測：以「同時含 { 與 ;」為條件，可能誤判含這兩個字元的自然語句。

     更精確的做法是檢查文字區塊所使用的字型名稱（等寬字型如 Courier、

     Consolas 通常代表程式碼）。

  3. 頁首／頁尾：比例閾值（8%）適用於大多數標準排版，但若文件邊距特別大

     或小，可能需要調整，或升級至方案 B（自動偵測重複內容）。

  4. 表格偵測：PyMuPDF 的 find_tables() 對有明顯框線的表格效果佳，對無框線

     表格可能漏判。安裝 pymupdf_layout 套件可提升偵測精確度。

  5. 翻譯品質：使用 Google Translate API（免費版），有次數限制與品質限制，

     專業術語翻譯可能不準確。

有了 AI 不用白不用，以下是 Web Claude 給的解決方案

英文技術文件翻譯成中文：5 個最佳方案

針對技術文件的完整翻譯，我為你整理了五個經過實測效果不錯的方案，並依照不同使用情境分類。

---

方案一：Claude / ChatGPT / Gemini（大型語言模型）

直接將文件內容貼到對話框，或上傳檔案請 AI 翻譯。

優點

• 翻譯品質目前在技術文件領域是最高的，能理解上下文、保留技術術語的一致性
• 可以下指令客製化，例如「保留程式碼區塊不翻譯」、「使用台灣繁中習慣用語」、「術語表優先」
• 能處理 Markdown、HTML 等格式，輸出後排版幾乎不需要再整理
• 遇到模糊語意時會根據語境合理判斷，而非機械式直譯

缺點

• 長文件需要分段處理，否則容易遇到輸出長度限制（通常一次 3000–5000 字較穩定）
• 不同段落之間的術語一致性需要自己維護術語表，或在 prompt 中明確指定
• 免費版本通常有用量限制，重度使用需要訂閱
• 偶爾會出現幻覺，特別是專有名詞或版本號，需要人工校對

最適合： 重視翻譯品質、文件量中等（一份文件數千到數萬字）、願意動手調整 prompt 的人。

---

方案二：DeepL（含 DeepL Pro / DeepL Document Translator）

專注於翻譯的服務，支援 .docx、.pptx、.pdf、.txt 等檔案上傳，整份翻譯後下載。

優點

• 翻譯流暢度極佳，中文輸出比 Google 翻譯更自然
• 文件上傳後會完整保留原始排版（字型、表格、圖片位置）
• 操作極簡，零學習成本
• 有 API 可串接到自己的工作流程

缺點

• 對於最新的技術術語（特別是 AI、區塊鏈等新領域）有時不如 LLM 精準
• 免費版有每月字數和檔案大小限制（單檔約 5MB、每月 3 份）
• 無法針對特定術語做客製化翻譯記憶（這是 Pro 才有的 Glossary 功能）
• 對程式碼區塊的處理不如 LLM 細緻，有時會誤譯變數名稱

最適合： 需要保留原始檔案排版、追求穩定輸出、不想花時間調整參數的人。

---

方案三：Immersive Translate（沉浸式翻譯）瀏覽器擴充功能

主要用於網頁翻譯，但也支援 PDF、EPUB 等文件，採雙語對照顯示。

優點

• 雙語對照模式對技術文件閱讀極友善，原文與譯文並列方便核對
• 可以串接多種翻譯引擎（Google、DeepL、OpenAI、Claude、自訂 API 等）
• 支援線上文件（GitHub README、官方文件網站）即時翻譯
• PDF 翻譯保留原始排版，輸出雙語 PDF
• 免費版功能已足夠日常使用

缺點

• 串接 OpenAI/Claude API 需要自己申請金鑰並支付費用
• PDF 翻譯的進階功能（如完整檔案翻譯下載）需要 Pro 訂閱
• 對於要交付的「翻譯成果」不是最佳選擇，比較適合自己閱讀
• 排版複雜的 PDF 偶爾會出現對位錯誤

最適合： 主要是「自己要看懂」技術文件、會頻繁瀏覽英文網頁文件、想要保留原文對照的人。

---

方案四：Crowdin / Lokalise / Weblate（專業在地化平台）

針對軟體與技術文件設計的協作翻譯平台，支援多種檔案格式（Markdown、JSON、PO、XLIFF 等）。

優點

• 有完整的翻譯記憶庫（TM）和術語表（Glossary）功能，確保跨文件術語一致
• 支援團隊協作、版本控管、審校流程
• 可直接串接 GitHub/GitLab，文件更新時自動同步
• 整合機器翻譯（MT）作為初稿，再由人工校對
• 適合長期維護的文件專案

缺點

• 學習曲線較陡，初次設定需要花時間
• 主要為團隊與企業設計，個人偶爾使用過於笨重
• 免費方案限制較多（Crowdin 有開源專案免費方案，Lokalise 沒有真正的免費版）
• 不適合一次性的翻譯任務

最適合： 持續維護的技術文件（如開源專案 docs、產品手冊）、團隊協作、需要版本控管的場景。

---

方案五：Google 翻譯（含 Google Docs 內建翻譯 / Google 文件翻譯）

老牌通用翻譯工具，可直接上傳文件或在 Google Docs 中使用「翻譯文件」功能。

優點

• 完全免費，無使用量限制
• 支援格式廣泛，文件上傳可保留基本排版
• 速度極快，整份文件幾秒鐘完成
• 與 Google Workspace 整合良好

缺點

• 翻譯品質在技術文件上明顯落後於 DeepL 和 LLM，中文常有「翻譯腔」
• 不擅長處理技術術語，有時會把專有名詞硬譯
• 無法客製化術語或語氣
• 程式碼區塊處理粗糙

最適合： 對品質要求不高、需要快速理解大意、預算為零的場景。

---

我的建議組合

如果是要交付的正式翻譯成果，實務上最有效率的做法是混搭：

LLM（Claude/ChatGPT）做初翻 → 人工校對 → DeepL 或 Immersive Translate 對照檢查

如果你能告訴我這份技術文件的類型（API 文件？產品手冊？學術論文？）、長度，以及翻譯後的用途（自己看 / 交付給客戶 / 發佈），我可以給你更具體的方案推薦。

如果我有 AI

這是一個我今天在思考的問題？

今天是第一次透過 script 把所有相關應該手動 patch 的東西，都在 script 中自動化搞定！

我想這跟我昨天下午請了半天假休息有關，今天整個人神清氣爽，不然真的是感覺很久沒放假了！假日為了推 Code，人都被綁在書桌前面，出去吃個飯也是急忙趕著回家觀看 make build 結果，一整個心累。

又或許也跟我們終於有一版比較完整的 script 版本，這也有助於我自動化所有 patch 瑣事。

因為這些手動 patch 真的很瑣碎，我實在很難開好 spec 請 AI coding，因為描述這個問題的打字，可能我直接寫 script 還是比較快。

更別提我們根本不可能在客戶環境內使用 AI？

總之，今天這個 script 的建立，當我們下次換新 tag 繼續驗證時，至少可以節省 60% 以上的時間。

因為我已經建立了一套 SOP，下次行動就有準則了。

比如說，copy 要怎麼做？

copy 的 reference 也要建立一個 reference_tag 的資料夾供 reference。

遇到要手動改檔案的地方，如果那個檔案不能參考 reference _tag 的話，改將相關東西放到 tools/git_patch 裡面，使用 git apply 的方式上 patch。

另外，上面這個路徑，也可以放客戶 patch 有問題時，我 patch 他的 patch 檔案。

難怪古人說：不以規矩，不能成方圓。 

ScreenBar Halo 2 入手

我最近的人生終於有光明了XD

問了幾家附近的 3 C 買場都沒有賣此掛燈，上網購買又得避開晚上送貨，不知為啥也不能選擇常去的便利商店取貨？

今天雖然推 Code 不順，還是抽空去了三創一趟，既然好不容易上去台北，還是每層樓都走馬看花一下，很多店家動線貌似都有重新調整，逛起來舒服多了。

來到現場，看不出來這款掛燈特殊之處，可能是展場燈光本來就很亮的緣故。

反正我就是要買，故也沒多做考慮，一個放家裡，一個放公司。

回家剛裝上時，還覺得是不是裝錯了，感覺一點用處都沒有，後來才發現原來燈管可以旋轉調角度，調整過後果然好多了。

可惜現在老了不在書桌看書寫字了，不然我這鍵盤處的一小塊天地，真的是充滿光明。

明天去公司時應該就能點光明燈了XD