你叫 AI 修一個 bug。它回報：找到原因了，改好了，測試全過，還附上改之前、改之後的數字。

你打開 App，還是一樣。

Day 5 說過，收到「完成」先找證據：你要的數字有沒有出現在回報裡。這次數字都在，也都是真的，只是量的不是你遇到的那個問題。

一個選單列小工具，吃掉九成 CPU

usage 是我做的開源小工具，放在 Mac 螢幕最上面那排選單列，顯示 Claude Code 和 Codex 這兩個 AI 工具的額度還剩多少、今天花了多少錢。額度就是它們的五小時上限和每週上限，用完得等。這些數字不連網去問，是讀電腦裡這兩個工具自己留下的使用紀錄，在我的電腦上算出來的。

7 月 5 日早上，我覺得它開起來卡卡的。

我讓兩個 AI 分工：Claude 跟我討論、寫工作單（交給 AI 的任務說明），Codex 照工作單動手。兩邊的環境不一樣：Claude 直接跑在我的電腦上，看得到其他程式在做什麼；Codex 跑在沙盒（限制它能碰什麼的隔離環境）裡，看不到。

Claude 先量：usage 一直吃掉九成以上的 CPU（電腦的運算力），開了兩分鐘還是這麼高。它只是在螢幕上顯示幾個數字，卻跟一支正在算東西的程式一樣忙。

它再用 Mac 內建的取樣工具，看 App 在忙什麼——每隔幾毫秒對 App 拍一張照，統計它最常在做哪件事。結果約三分之一的時間，花在選單列上的動畫：Claude Code 的數字後面跟著一隻鳳凰，Codex 的數字後面跟著一條龍，哪個工具用得越兇，那一隻就跳得越快。動畫每跳一格，選單列就整個重新排一次版。

Claude 把這個發現寫成第一張工作單交給 Codex，裡面寫了停損（什麼情況要停手回報）：你那邊量不出這個現象，就停下來回報，不要照抄我的結論。

Codex 照停損停了：在沙盒裡量不到 CPU，一行程式都沒改。Claude 說這是對的判斷，動畫那段它自己修。

三輪都證明修好了

動畫是第一輪。接下來兩輪是同一個劇本：猜一段程式，量那段程式，數字漂亮，App 照卡。

修完動畫，Claude 再量一次：還是一陣一陣衝到八、九成。這次取樣拍到的照片裡，大部分時間花在讀檔案、把讀到的文字拆成一筆一筆紀錄。

可是照片只拍得到「在讀檔案」這種動作，拍不到是程式裡哪一段叫它讀的。Claude 這樣推：應該是讀 Claude Code 使用紀錄的那段，檔案一變長就整份從頭重讀。

第二張工作單的第一步是「先自己驗證這個假設」，接著補了一句：你的環境量不到 App 的 CPU，不要試了，改量這段程式本身跑多久。

Codex 照做：照工作單造了幾千行假的使用紀錄，拿來量那段程式。usage 每分鐘重算一次畫面上的數字，修完之後，這段重算從平均 102.75 毫秒降到 3.5 毫秒。

Claude 重新打包再量：還是七成到九成五。這次的照片裡多了一個資料庫，而整個 App 只有讀 Codex 使用紀錄的那段會用到它。第三張工作單就換成那段，一樣先驗證、一樣用假資料量。Codex 回報：做好了，也驗證過了。

十點半多，Claude 跟我說：動畫、兩段讀紀錄的程式，三個都證明修好了，測試全過，可是打開真的 App 量，還是常常衝到九成以上。

而且這時候兩個工具打架了：一個說 CPU 衝到九成，取樣的照片裡，App 卻什麼都沒在做、全部在等。Claude 說它分不出是 App 真的還有問題，還是我這台電腦（系統裝的是測試版）把這種程式的 CPU 算錯了。要判誰對，得用第三個工具 py-spy，但它要管理員權限（sudo）。它是這樣說的：

py-spy（更準的 Python 層級剖析工具）在這台 macOS 26 beta 上需要 sudo 才能附加，被你的權限設定擋掉了，沒辦法交叉驗證
……
比較實際的做法是你自己用一陣子感受一下還卡不卡

我回：

什麼權限 我開就好 要處理好啊

結果不是權限的事：那個工具要在終端機打密碼，Claude 沒有打密碼的管道，那行指令得我自己跑。我沒跑。早上就停在這裡。

數字都是真的，量的都是 AI 猜的那段程式

三個問題都是真的，也真的修好了，下午四點跟著新版一起發布。App 還是卡。

三次回報的數字都是真的，那為什麼打開還是一樣？因為沒有一個，是讓 App 一直吃掉九成 CPU 的那個問題。

回頭看第二、三張工作單的驗收條件（做完怎麼算對），寫的是：那段程式改之前、改之後各跑多久，加上測試要過。Codex 每一項都做到了。

但這個標準，是照著「猜的原因」寫的。猜哪一段，就量哪一段；每一輪換一個猜測，量法也跟著換。所以每一輪都能過，而「App 打開卡不卡」，從頭到尾沒寫進標準裡。

量的資料也不一樣。Codex 量的是幾千行假紀錄；我電腦上光 Claude Code 的使用紀錄，就有 647 個檔、500 多 MB。

真的 App，只有跑在我電腦上的 Claude 量得到。它量了，數字沒降，最後交回給我「自己用用看」。

傍晚換個問法：讓 App 自己說它在忙什麼

傍晚，Claude 換了做法：把打包好的 App 直接開起來，打開除錯紀錄（程式邊跑邊印出自己在做什麼），看它印了什麼。

10 秒內，它印了 15,012 行「查不到」，光下面這一句就佔了 13,797 行：

pricing: no match for model=glm-5.2

意思是：價格表裡找不到 glm-5.2 這個模型的價錢。

glm 是另一家公司的 AI 模型。我平常也用它派工，用的那個工具會把紀錄寫進 Claude Code 存紀錄的同一個資料夾，兩邊混在一起，glm 的約 1.5 萬筆。

usage 每次重算，要分別算最近一天、一週、一個月和全部的花費，所以同一筆紀錄要算四次。沒標價錢的紀錄，每算一次就去價格表查一次。整張價格表有上千個模型，查不到也不會記下「這個查不到」，下一次又從頭翻一遍。

1.5 萬筆乘四，等於一次重算要查六萬次；每一次都把上千個模型從頭翻一遍，翻完什麼也沒記住。一分鐘後再來一輪。

早上三輪猜的原因裡，沒有它。

這一次的工作單，「背景」那一段的標題是：

背景(已用實測數據抓到的真實根因,不是臆測)

同一天，同樣是 Claude 寫的工作單，早上寫「先驗證這個假設」，傍晚寫「不是臆測」。差別在證據：早上的證據只說得出「很忙、在讀檔」，兩個工具還互相打架；傍晚的證據直接說出是誰在忙、忙了幾次。

修法是記住查不到的模型，每個只翻一次表。同一個傍晚，Claude 在我電腦上還量到另一個問題：App 每次重開，都要把全部使用紀錄從頭讀一遍，花 5 秒多。這個也一起修了。

修完重開，我自己看了一下，usage 那一行的 CPU 是 21.7%。早上是九成起跳。我跟 Claude 說：

那你 push 發版吧 省得別人下載 燒 cpu

晚上七點前，新版發布。

抓 bug 的工作單，先寫「症狀怎麼量」

Day 2 講過，交給 AI 的工作單可以分三格：改哪裡、哪裡不准動、做完怎麼算對。可是抓 bug 的時候，你根本不知道要改哪裡，第一格只能填猜的。

所以抓 bug 的工作單，在三格前面先加一格：

症狀怎麼量：
- 在＿＿＿（你自己會打開的那個畫面）量到＿＿＿（數字）
- 修完再量同一個地方，把前後數字貼出來

改哪裡可以一輪一輪換，這個數字不能換。那天早上，每一輪換一個要修的地方，也跟著換了一個量法，所以每一輪都「達標」，App 還是卡。

拿那天的第二張工作單來改寫，會長這樣：

橘色是改掉的地方。要修的還是同一段，量的東西從 Codex 改的那段程式，換成我打開的那個 App。

寫這一格，注意三件事：

• 量你看得到的東西。 不是「那段程式快了多少」，是「App 打開五分鐘，CPU 剩多少」「按下去幾秒才有反應」。Mac 看活動監視器，Windows 看工作管理員。
• 動手的 AI 量不到，就寫明誰來量。 那天 Codex 在沙盒裡讀不到 CPU，工作單就叫它改量別的。應該寫的是：你量不到，修完先別說修好了，交回來，由 Claude（或我）在真的 App 上量。Day 4 說過，工作單最後可以加一行「驗不到的」，讓 AI 自己列出哪些它驗不了、要你親手確認。CPU 就該寫進這一行。
• 證據要指得出是哪一段。 「大部分時間在讀檔」指不出是哪一段程式，只能猜；「10 秒印了 1.5 萬次查不到 glm 的價錢」一看就知道是查價錢那段。證據還指不出是哪一段，這一輪就先只找原因，不急著改。

今天可以帶走的

下次叫 AI 抓 bug，照這樣寫：

症狀怎麼量：
- 在＿＿＿量到＿＿＿，正常應該是＿＿＿
- 修完再量同一個地方，貼出前後數字
- 你量不到的話，說你量不到，交回來給＿＿＿量；不要改量別的
改哪裡：＿＿＿（猜的就寫「猜的」，附上證據指到哪）
哪裡不准動：＿＿＿（修的時候不能順手改到的地方）
做完怎麼算對：上面那個數字降到＿＿＿以下

收到「修好了」，看一眼回報裡的數字：量的是你打開 App 遇到的那個症狀，還是它改的那段程式？後者再漂亮，也要自己打開 App 看一次。

明天是這個系列講「怎麼下指令」的最後一篇：五個月下來，我的工作單寫法變了哪些。

參考資料

• usage 專案：https://github.com/aqua5230/usage
• 早上三個修正進專案的那次改動（commit 25a40fd，隨 v0.24.0 發布）：https://github.com/aqua5230/usage/commit/25a40fd
• 傍晚兩個修正（commit 87c85ba，隨 v0.24.1 發布）：https://github.com/aqua5230/usage/commit/87c85ba