你修好一個 bug，測試全綠，CI 全綠。什麼時候可以回覆使用者「修好了」？

28 天累積的驗收清單：34 行，分 10 組

工作單（交給 AI 的任務說明）裡有一格叫「做完怎麼算對」。Day 2 開了這一格，Day 4 把它拆成「AI 自己驗」和「我自己按」，Day 8 起幾乎每一篇都往裡面加幾行。到昨天，扣掉重複的，一共 34 行。

34 行一次全貼給 AI，一大半跟這次的改動無關，回報會被無關的行淹掉。所以我照情境分成 10 組：

• 每一次改動都要做的（6 行）
• 修 bug（4 行）
• 推上去、發版（8 行）
• 算數字、改檔案、改預設值（4 行）
• 跨作業系統、日期時間（2 行）
• 文字、翻譯、說明文件（5 行）
• 安裝（1 行）
• 畫面（2 行）
• 搬程式、刪程式（1 行）
• 別人或另一個 AI 送來的改動（1 行）

完整的 34 行放在文末，每一行標著來自哪一篇。

用法是兩步：先看這次改動屬於哪幾組，把那幾組的行貼進「做完怎麼算對」；再叫 AI 逐行回報：做了沒、結果、證據。

拿 Day 28 的修正來驗

Day 28 那篇，我在 usage（我做的開源小工具，顯示 Claude Code、Codex 這些 AI 工具用了多少額度）開了一個分支，重修 Day 26 的 #42：使用者在面板（點選單列圖示彈出的視窗）上按右鍵點 Reload，面板變成一片空白。重修時發現，6 月 22 日上線的右鍵過濾從沒拿掉 Reload。程式只改一個名稱，測試改用真的選單項目。先紅後綠（拿掉修正，測試失敗；放回去，測試通過），CI（每次推上去自動跑的檢查）在 Mac 上跑的七項，在本機全過。

照以前的習慣，這時候就會回覆使用者「修好了」。今天先拿清單驗一次。

這個修正屬於 7 組：「每一次改動」「修 bug」「推上去、發版」「跨作業系統、日期時間」（usage 也有 Windows 版）「畫面」「搬程式、刪程式」（這次沒有搬或刪，可是改的那行是 6 月 22 日修 bug 時寫的，要確認當時修的東西還在），還有「別人或另一個 AI 送來的改動」（修正是我請 AI 寫的）。7 組裡，跟這次有關的是 23 行（跨作業系統那組只用得上型別檢查那一行）。

23 行裡，過了 12 行

23 行裡，12 行過了，每一行都有輸出可以貼。挑幾行：

• 測試數字附基準（Day 12）：2652 passed，基準是主線 main（還沒修之前）的 2652 passed。這次是改寫一個測試，沒有增減。
• 新加或改過的測試（Day 27）：它最後檢查的是「過濾完，選單剩下哪幾項」，也就是使用者按右鍵看到的選單。算「使用者看得到的結果」。
• 拿掉修正要紅（Day 9）：只改測試、不改程式，紅在 'WKMenuItemIdentifierReload' != 'WKMenuItemIdentifierCopy'，也就是過濾完第一項還是 Reload。
• 症狀前後（Day 6）：在真的面板上點 Reload，修正前面板上的文字從 323 個字變 0 個字；修正後選單裡沒有 Reload，文字維持 323 個字。Day 25 那行的前半「照他的步驟重跑」，也是這一次；後半「再回覆他」還不能做，所以那一行算在還沒到。
• 每個作業系統各跑一次型別檢查（Day 17）：Mac 上加 --platform win32 再跑一次（Day 17 那行寫的就是這個做法），也過。

沒過的三件事

一、我自己的 commit 說明，沒貼前後輸出

Day 27 那行是寫給「收別人或另一個 AI 送來的改動」的：說明裡要貼修正前、修正後各一次的實際結果。這次的修正是我請 AI 寫的，算「另一個 AI 送來的改動」。它的 commit（存進 git 的每一筆改動）說明寫了原因和修法，沒有貼前後的輸出。

這一行 Day 27 才寫進清單，這次就沒做到。

二、右鍵選單裡，沒有東西可以點

Day 26 那行要按 Cmd+R、兩指左右滑，再「把選單每一項點一次」。前兩件沒問題：按 Cmd+R，面板上的字數不變；兩指滑動換上一頁、下一頁，這個網頁元件預設是關的，usage 也沒打開。卡在第三件：修正後，在 usage 的 classic 外觀主題上按右鍵，選單只剩一條分隔線。

6 月 22 日的任務書寫著：保留「複製」，不要整個停用右鍵選單，因為使用者會複製面板上的數字。我想照著點一次「複製」，先用程式把面板上的字全選，結果選到 0 個字。一查，usage 的面板有 16 種外觀主題可以換，其中 14 個在樣式裡寫了 user-select: none，不准選取文字。選不到字，「複製」就不會出現。

這一句在工作單裡屬於另一格，叫「已經決定的」（Day 7）：寫下你故意的設計，附上原因。保留「複製」的原因寫了，可是沒有人去確認，使用者到底選不選得到字、叫不叫得出「複製」。

三、面板壞掉時，App 沒有第二個結束鍵

Day 26 的第二行：列出 App 裡每一個能結束它的地方。全部在同一個畫面上的，寫出那個畫面壞掉時使用者怎麼結束 App。

Mac 版能叫 App 結束的地方，只有一個：面板上的「結束」按鈕。選單列圖示點下去，只會開關面板。這次的修正拿掉了右鍵的 Reload，可是面板還有別的方式會壞，Day 26 的 PR #29 就是在處理畫面程式自己掛掉的情況。面板一壞，使用者就回到 #42 回報裡那句：「想重開，但找不到在哪裡結束。」

這一行，改一行程式擋不住。#42 的標題本來就是兩件事：面板空白，和找不到結束。6 月 22 日的修正和這次的修正，都只處理了前一件。面板壞掉時使用者怎麼結束 App，這次的修正沒有回答。

還沒到的 8 行：要等發版，或要有人去做

剩下 8 行，要等發版，或要有人去做：

• 推上去之後、發版前（Day 10 兩行）、出貨前開一次（Day 8）、發版後下載回來打開（Day 22）、同一天第二版（Day 22）：驗的那天，修正還在分支上，沒推、沒發。
• 我自己按（Day 4）：我在真的面板元件上按過，不是在打包好的 App 上按的。
• 回覆使用者（Day 25）、驗不到的要有人做完（Day 28）：要等上面幾行做完。

usage 的發版流程裡，有一步會自動打開打包好的 App，Day 8 那行「寫進出貨流程」算過了。可是流程裡沒有一步會按右鍵，這一項只能有人去按。

Day 28 加的那一行說：AI 交回來的「驗不到的」，每一項寫上誰來做；沒人做完，就不准回覆使用者「修好了」。所以驗的那天，答案是：還不能。

你可以這樣用這份清單

清單不會替你做完這些事。它做的是讓你在說「修好了」之前，知道還差哪幾件。

把文末的 34 行存成一個檔。下次叫 AI 做完一件事，接著交給它這段：

下面是驗收清單。
1. 先告訴我這次的改動屬於哪幾組，每一組說一句為什麼。
2. 那幾組的每一行，逐行回報：做了沒、結果、證據（指令和輸出）；跟這次無關的行，寫「不適用」和一句原因。
3. 沒做的，寫原因，再寫誰來做、做完要貼什麼。
4. 最後一行寫：可以回覆使用者「修好了」嗎？可以／不行，不行的話差哪幾行。

不用一開始就 34 行。從你最常做的那一組開始，出過事的再加進去。這份清單本來就是這樣長出來的：每一行，都是 usage 出過的一次事。

今天可以帶走的

「做完怎麼算對」的完整清單，照情境分組，每一行標著來源篇：

【每一次改動】
- 你自己驗：跑了什麼、結果是什麼，指令和結果貼在回報裡（Day 4、Day 5）
- 我自己按：打開＿＿＿，按＿＿＿，應該看到＿＿＿（Day 4）
- 驗不到的：先說哪一類你驗不到（例如要用滑鼠點、要看真實畫面），再列出這次落在裡面的項目（Day 4）
- AI 交回來的「驗不到的」：每一項寫上誰來做、做完貼什麼；沒人做完，就不准回覆使用者「修好了」（Day 28）
- 回報的測試數字旁邊寫上基準：「pytest：N passed（基準 ____）｜跑的範圍：____」；N 比基準少不准寫完成，全套跑不完就寫只跑了哪些，剩下的我自己跑（Day 12）
- 新加或改過的測試：每一個用一句白話說它最後檢查什麼，標出是「使用者看得到的結果」還是「程式內部有沒有做某個動作」。修 bug 的測試至少要有一個是前者，Day 9 那條「拿掉修正要紅」就拿這一個來跑（Day 27）

【修 bug】
- 在＿＿＿量到＿＿＿，正常應該是＿＿＿；修完再量同一個地方，貼出前後數字（Day 6）
- 修 bug 附的測試：先拿掉修正跑一次，要紅，而且紅在＿＿＿（bug 發生時的樣子）；放回修正再跑，要綠。兩次的輸出都貼在回報裡。拿掉修正還是綠，就補一個會紅的測試（Day 9）
- 修 bug 補測試：列出這次修正改了哪幾處，每一處分開拿掉、各跑一次測試，貼出結果。每拿掉一處都要變紅；有一處拿掉還是綠的，就補一個會紅的檢查。那一處如果管的是程式執行時去哪裡找檔案，這個檢查就是打開打包好的 App（Day 23）
- 修使用者回報的錯誤：照他寫的步驟重跑一次，貼出這次成功的輸出，再回覆他「修好了」（Day 25）

【推上去、發版】
- 推上去之前：打開 CI 設定檔，每一項檢查在本機用同樣的指令跑一遍，每項貼最後一行結果；本機跑不了的列出來，推上去之後列出這個版本在 GitHub 上的每一項檢查和結果（Day 11）
- 推上去之後：列出這個版本在 GitHub 上跑的每一項檢查（名字、在哪個系統跑、結果），貼在回報裡；有一項紅就不算完成，先貼那顆紅燈錯誤訊息的第一段（Day 10）
- 發版前：同一個版本的每一項檢查都綠了才准發；新加的檢查第一次就紅，當天查清楚、修綠，不准當成「本來就紅」（Day 10）
- CI 的上限檢查（例如每個檔案最多幾行）要過；超過時只准把程式搬走或合併，不准調高上限數字（Day 15）
- 出貨前開一次：拿使用者會拿到的那一份（安裝檔／部署後的網址／裝好的指令），照使用者的開法打開＿＿＿，應該看到＿＿＿；出現錯誤就不准出貨（Day 8）
- 寫進出貨流程：上面這一步每次自動跑，不靠人記得（Day 8）
- 發版：發出去後馬上把使用者會下載的那個檔下載回來，先確認這次新加的檔案在裡面（貼出 unzip -l 那幾行），再打開打包好的 App，確認能正常啟動；只在自己的專案資料夾跑過不算數（Day 22）
- 同一天要發第二版以上：說明這一版為什麼不能等到當天收工再一起發（Day 22）

【算數字、改檔案、改預設值】
- 算數字的功能：拿一筆真實資料，跟一個不是這段程式算的數字對（官方數字、別的工具、手算），回報兩邊的值和差距；差距的原因要附證據，不准只寫推測（Day 13）
- 會改檔或改設定的功能：成功訊息不算數，AI 回報要附改動前後的比對；測試要拿一份真實環境裡用過的檔案跑一次，不能只用自己想像的寫法（Day 14）
- 會改用預設值的功能：測試要各餵一次「少一個」和「內容是空的」，兩種都要紅；測試說明寫要抓什麼症狀，就親手做出那個症狀跑一次（Day 16）
- 有更新快照的改動：回報要貼出快照多出來的那幾行；新功能在快照裡要看得到數字；把新功能故意改壞一次，快照要紅；新畫面用真實資料打開看一次（Day 19）

【跨作業系統、日期時間】
- 支援多個作業系統的專案：型別檢查每個作業系統各跑一次（mypy --platform），回報要寫明在哪個作業系統上跑的（Day 17）
- 改到日期、時間的程式：「拿掉修正要紅、放回要綠」，要在切不動時區、而且不是 UTC 的環境跑；只在 CI 或自己的 Mac 上過，不算數。回報要寫明在哪個作業系統、哪個時區跑的（Day 21）

【文字、翻譯、說明文件】
- 有繁體中文介面的專案：繁中文字用 OpenCC（s2twp）掃過，標出來的每一句不是改掉，就是連同原文寫進例外清單；這個掃描寫成測試（Day 18）
- 改了有翻譯版的文件：每個語言版本都要改到，AI 回報要列出每一版改了哪幾行；同步檢查通過不算數（Day 20）
- 改了檢查的範圍：同一個改動裡，把說明檔裡描述這個檢查的句子一起改（Day 20）
- 寫給使用者看的訊息（錯誤提示、空白畫面的說明）：寫出這句會在什麼情況出現、看到的人是怎麼裝的。叫人跑指令的，確認裝 App 的人也跑得了；App 裡有按鈕做得到的，就叫他按按鈕（Day 24）
- 改了安裝方式、加了按鈕或新入口：把介面文字裡提到舊做法的句子全部找出來，貼出搜尋結果，一起改（Day 24）

【安裝】
- 動到安裝方式（安裝說明檔、打包格式、README 的安裝指令）：照 README 一字不差跑一次安裝，貼出最後 10 行輸出（Day 25）

【畫面】
- 畫面是網頁的 App：在打包好的 App 上，對每個畫面按右鍵、把選單每一項點一次，再按 Cmd+R、兩指左右滑；每一步貼出畫面截圖。程式自己會重新載入畫面的地方，要在真的網頁元件上跑一次，貼出載入後畫面上的文字；只用假物件數它被叫了幾次，不算數（Day 26）
- 結束、重開這類出口：列出 App 裡每一個能結束它的地方，各在哪個畫面上。全部在同一個畫面上的，寫出那個畫面壞掉時使用者怎麼結束 App（Day 26）

【搬程式、刪程式】
- 貼出要動的那幾行的 git blame 結果，標題有 fix 或 issue 編號的 commit 列出來，逐一確認它們修的東西在新位置還在（Day 23）

【別人或另一個 AI 送來的改動】
- 說明裡要貼修正前、修正後各一次的實際結果（數字、畫面截圖或輸出）；只勾「手動驗證過」，不算數（Day 27）

明天是最後一篇。Day 1 問了一個問題：用 AI 做出來的東西，敢交給別人用嗎？明天用這 29 篇裡發生過的事來回答。

參考資料

• usage 專案
• issue #42
• PR #29〈fix: reload web panel after render process failures〉
• MDN user-select