PDF 翻譯 Part 05

之前在測試使用 Claude API 翻譯的結果時，順手請 AI 寫了一個 Windows PDF Viewer，來幫助我快速閱讀翻譯過的技術文件。

果然自己寫的東西最符合自己的需求，於是我 05/24 便想要繼續來個 Android PDF Viewer，AI 一下就把程式寫好，無奈當天第三方函式庫網站似乎有問題，Claude Code 使用了好多種方法及程式語言想要下載都不成功，故最後沒辦法得到一個 APK 來使用。

其實我後來想想，搞不好是 AI 寫法有問題導致被 Bang 也說不一定？

今天早上，為了監控 git push 的執行，不得不坐在書桌前，於是便繼續這個小專案，這次下載就很順利。

後來又陸續加了很多功能，目前所有功能如下

- 顯示或隱藏圖層，可以閱讀原文或是翻譯的中文。

- 可以連續捲動模式或是整頁模式。

- 整頁模式可以點擊或是滑動翻頁。

- 頂部工具列可以隱藏或固定。

- 目錄功能。

- 跳頁功能。

- 回到上一頁功能。

- 允許或關掉翻頁效果。

- 自動裁邊功能。

有些功能是一次就搞定，有些則是測試發現問題後請 AI 修改。

過程中大概遇到 2 ~ 3 次的自動壓縮，有一次還失去了編譯環境相關的內容，故 AI 又浪費 token 重新建立起環境的認知。

因為不是自己寫的 APK，故我都是請 AI 直接編譯，再加上我習慣用 Windows Git Bash 的環境啟動 Claude，故每次 AI 都要花時間設定環境。

這次發現自動壓縮丟失原本內容的問題，馬上請他把環境寫成文字檔，之後別的專案就不用從頭建立環境了。

看了一下，雖然不知道昨天 05/30 的使用量哪來的，但約 16 塊的花費還是很值得。

還順便問了一下裁邊演算法，原來又是沒人好好填上 PDF meta 資料的鍋。

總之，我現在可以在我的 Pubook Pro 上閱讀技術文件了。

颶風翻了身

好景不常，繼上次「閒適臥雲中」般的順利推 Code，這個星期說是跋山涉水，披荊斬棘也不為過。

首先，星期三的會議，以我破英文對客戶說話的理解，好像可以先跑測試，之後如果沒有更新，其實不用再跑？

但此番理論跟我從 git hook 看到的禁制似乎有所違背？

果然，不管你有沒有跑完測試，git push 就是要你再跑一次，但我實在沒空把整個 hook 看過一遍，也許答案藏在測試的 Makefile 中也說不一定？

總之，星期三晚上的推 Code 果然還是因為有人比我早更新而導致我推 Code 失敗！還好，當天還算幸運，第二次就順利推 Code 成功，故我當天就又推了一次，本想這樣一來，我六日就可以先不推 Code，於是當天又搞到 2 點才睡，

無奈，本週還是要推 Code，但想到可以讓同事以及專案流程順利一點，還是默默地從星期五晚上開始推 Code，也許可以像星期三那樣走狗屎運也說不準？

本週測試項目來到約 13X 個，就在順利跑完 120 個左右後，一來是剩餘測試卡住好久，二來是我在另外一個 reference 資料夾檢查的結果已經有人又推 Code 成功，於是就不等了，凌晨 12 點半就上床睡了。

不知是不是心懸測試結果的緣故，半夜四點醒來後就睡不著了，忍到七點多吃完早餐才進去客戶工作站檢查結果，沒想到測試居然還沒跑完，因為已經知道不可能成功，還是按下 Ctrl + C 停止所有測試，沒想到這是個不對的方式，直到後來才發現後果？（推 Code 有問題要停掉，一定要用 bkill，不能 Ctrl + C）

因為星期六通常還是有人推 Code，故我的 SOP 已經改成星期六晚上 8 點後再視情況決定推 Code 事宜！

星期六晚上 8 點過後，距離最後一個 commit 已經有一段時間了，應該暫時沒人推 Code 了，故還是勇敢的 git push。

沒想到在剩下 1X 個項目的時候，測試又被卡住了，檢查一下 git commit 情況，已經有人截足先登了，於是決定取消，但這次用 bkill 終止所有測試。

星期日一早又看到一堆 git commit 的更新，說真的我也無從判斷該不該做，想了一下，還是默默地跑了下去。

老樣子，測試又卡住了，嚴格來說，是跑工作的 Server 都掛了，這似乎已經是常態了？

還好剛剛所有的測試都跑完了，只是要上傳的時候，一直跟我說 Git is locked？

等了幾次重試後，突然靈機一動，感覺跟星期五強制 Ctrl + C 有關？

於是火速回頭檢查禁制，果然此訊息是腳本本身的訊息而不是 git command 的訊息！

總之，此腳本推 Code 時，會產生一個 /tmp/git-push-2 的檔案，腳本以此檔案來避免有人同時推 Code。

檢查的結果，果然所有人是我，檔案建立時間就是星期五晚上的時間。

果斷的砍掉檔案之後，跑一跑突然又出現一個錯誤，然後整個腳本就結束了，本來以為又要重推了，髒話都要罵出來了？

還好後來想了一下，這個錯誤應該是 git 想要幫你重整 db 的動作，不影響推 Code 結果。

最後終於脫離了從星期五晚上執行到剛剛的鬧劇，真是不堪回首呀？

唉，少點心眼都不行，還好我曾經是一個貨真價實的軟體工程師，不然真的會被搞死，六日原本的計畫又泡湯了，幸好早上監控推 Code 時，順手把 Android PDF Viewer 完成，不然真的會幹到不行。

閒適臥雲中

這個星期又坐在電腦桌前面推 Code 了。

昨天難得順風順水，不用解 patch issue，不用管 make build issue，重要的是每個測試都能夠順利通過。

於是昨天便違反 SOP，大膽的給它用力推 Code，直到今天凌晨 3 點才睡。

這才對嗎，既然用了不合理規則擋我路，至少要像這樣順順利利，我才會心甘情願XD

昨天下午推 Code 前，去了一趟 IKEA，買了幾件小物，整理一下書桌，套句《劍來》的術語，這樣的環境才有助於聚集天地靈氣，養育我這一小方天地。

麻將大俠曾說：人品好，牌品自然好。

我要求的不多，每次推 Code 就像今天這樣就好了！
 

待會終於有時間玩一下暗黑 2 了。

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 看當下用量。