修好一個 bug，你大概會請 AI 順手補一個測試，免得它以後又回來。那個測試守的，是整個修正，還是你當下記得的那一半？
昨天講到 5 月 22 日：usage（我做的開源小工具，顯示 Claude Code、Codex 這些 AI 工具用了多少額度）發出去的 App 一打開就崩，第一個別人開的 issue（#4）回報了這件事，當天傍晚 v0.6.8 修好。
兩天後，5 月 24 日晚上 10 點多，usage 在半小時多一點裡連發了 v0.10.0、v0.10.1、v0.11.0 三版。v0.11.0 加上了更新檢查，就是 #4 那位使用者隔天要求的功能：打開 App 時去查有沒有新版。
v0.11.0 發出 26 分鐘後，一個不認識的帳號 cmhcm 送來 PR #6（把改好的程式送來請我合併）。第一段寫：v0.10.0 到 v0.11.0 這三版的 App，第一次打開就跳出 Launch error（啟動失敗）。他從終端機直接執行 App 裡的程式，貼出完整的錯誤，最後一行是：
NotADirectoryError: [Errno 20] Not a directory: '/Applications/usage.app/Contents/Resources/lib/python313.zip/i18n.json'
我把 #4 那張截圖翻出來對，最後一行一字不差。
也就是說，加了更新檢查的 v0.11.0 一打開就崩，更新檢查還來不及跑。
這個 PR 寫得很完整：怎麼重現、原因在哪、怎麼改、新加 5 個測試，還寫原有的 187 個測試都過。不到 20 分鐘我就合併，再 5 分鐘，修好的 v0.11.1 發出去。從第一個壞版發出到 v0.11.1，84 分鐘。到我這次去查時，三個壞版各只被下載過 1 次（v0.11.1 是 35 次）。這次發現得這麼早，是因為剛好有人在那一個多小時裡下載、打開，還把錯誤寫了下來。
先回到 5 月 22 日那次修正（昨天寫過）。#4 的錯，要修兩件事：
i18n.json 放進 App。python313.zip，「同一個資料夾」就變成壓縮檔裡面。錯誤訊息那條怪路徑，就是這樣來的。v0.6.8 兩件都做了，commit 訊息（每次存檔附的說明）也兩件都寫了。
v0.6.8 發出後十來分鐘，usage 多了一個測試，commit 標題是「防止資料檔沒被打包（與 #4 相關）」。
它不執行程式，只讀程式碼：把每個程式檔掃一遍，找出所有「找同一個資料夾裡某個檔案」的寫法，確認那個檔名有列在打包清單裡，少列一個就失敗。
這是第 1 件事的守門員。第 2 件事，程式執行時到底去哪裡找，它不看。這個測試的 commit 訊息說，要擋的是「i18n.json 有被程式讀，卻沒放進 App」這一類錯，也只寫了第 1 件。
5 月 24 日下午，usage 有一個改了 22 個檔的大 commit，主要是把另一個統計 token 用量的小工具併進 usage。其中一件，是把「讀翻譯檔」那段程式，從選單列 App 的主程式搬到一個新檔案。
搬的時候，v0.6.8 加的「先去 App 資源資料夾找」那 13 行被刪掉了；新檔案裡寫的，是 v0.6.8 之前那一行：找同一個資料夾裡的那一個。那 13 行旁邊，沒有任何註解寫它是修 #4 用的；5 月 24 日這個 commit 的訊息很長，也沒提到這件事。
打包清單裡，翻譯檔還在。所以那個測試照樣通過；當晚三次發版，CI（每次推上去自動跑的檢查）也全綠。
我把 5 月 22 日那個測試原封不動，放進兩個壞版的程式裡各跑一次。
v0.6.7，#4 那時的壞版（節錄）：
AssertionError: i18n.json is read by menubar.py, but is not listed in setup_app.py resources
2 failed
v0.11.0，PR #6 那時的壞版：
2 passed
兩次打開 App 印出的是同一行錯誤，這個測試卻第一次紅、第二次綠。
Day 9 寫過一個檢查法：把修正拿掉，測試要變紅；不紅，就代表它沒在測這個修正（那天是別人送來的測試，修正拿掉照樣綠）。這次我在 v0.6.8 的程式上，把兩件事各拿掉一次再跑：拿掉第 1 件，2 failed；拿掉第 2 件，2 passed。這個測試只對一半的修正有反應。
我也把這幾版的 App 下載回來，先用昨天建議的 unzip -l（列出 zip 裡有哪些檔）看發版的 zip 裡有沒有翻譯檔，再一版一版打開：
v0.11.0 的 zip 裡，unzip -l 看得到翻譯檔；打開它，終端機印出的就是那行 NotADirectoryError。三種檢查裡，只有「打開 App」兩次都抓到。發版流程裡的「打開 App」這一步，是 9 月另一次「打包後一開就崩」之後才加的（Day 8 寫過）；5 月這兩次，流程裡都還沒有它。
測試沒守住，至少可以查出修正是在哪一次 commit 不見的。在專案資料夾裡跑：
git log -S'resourcePath()' --date=short --format='%h %ad %s' -- menubar.py i18n.py
-S 後面放修正那幾行裡比較特別的字，最後面放檔名。這裡的 resourcePath()，就是那 13 行裡「去找 App 資源資料夾」的那個呼叫。git 會列出「這段字出現的次數有變」的每一次 commit，新的在上面。usage 跑出來只有兩行：
352c203 2026-05-24 feat: rich statusLine renderer + final token-tracker → usage cleanup
086f1fe 2026-05-22 release v0.6.8 — bundle i18n.json into .app (fixes #4)
下面那行是 v0.6.8 加進來，上面那行是 5 月 24 日搬程式時刪掉。換成你的專案：挑一個 AI 修過的 bug，拿修正裡最特別的那幾個字跑一次。最上面那行如果就是修好的那次，代表那幾個字後來沒被刪過；上面還多出幾行，就點開來看那幾次改了什麼。
這是事後查。事前防，是在搬程式或刪程式之前，先看要動的那幾行是哪次 commit 加的：
git blame --date=short menubar.py
每一行前面會印出最後改它的 commit 編號，再用 git show --no-patch <編號> 就看得到那次的標題。5 月 24 日搬程式前，那 13 行前面印的都是 086f1fed，標題是 v0.6.8 那行，寫著 fixes #4。
工作單（交給 AI 的任務說明）裡那格「做完怎麼算對」，今天再加兩行（沒用過這張工作單，也可以直接把這兩行交給 AI，當作驗收要求）：
做完怎麼算對：
- （Day 4、Day 8 到 Day 22 加的幾行）
- 修 bug 補測試：列出這次修正改了哪幾處，每一處分開拿掉、各跑一次測試，貼出結果。每拿掉一處都要變紅；有一處拿掉還是綠的，就補一個會紅的檢查。那一處如果管的是程式執行時去哪裡找檔案，這個檢查就是打開打包好的 App
- 搬程式、刪程式：貼出要動的那幾行的 git blame 結果，標題有 fix 或 issue 編號的 commit 列出來，逐一確認它們修的東西在新位置還在
5 月 22 日補的那個測試沒有寫錯，它只檢查了翻譯檔有沒有列進打包清單，沒檢查程式去哪裡找。修正有幾處，就要拿掉幾次試試看。
8 月 6 日，又一位不認識的使用者開了 issue。他用 Homebrew（Mac 上裝軟體的工具）裝好 App，App 上寫著：請執行 python3 main.py --setup。他猜是要進到 App 裡跑，就在裡面找到一個 main.py 來跑，跑出來的錯，點名的正是今天 PR #6 加的那個函式 packaged_resource_path。明天看這一次。
iThome鐵人賽
看影片追技術