前言：把「應該要這樣做」寫成能照著做的規則

第二部提過一個原則性的想法：AI 補功能時,可以被要求順便檢查同一個檔案裡有沒有其他測試缺口。今天把這個想法寫成一段具體、可以直接放進專案 CLAUDE.md 或類似設定檔的規則文字，而不是停在「應該要這樣做」的空話。

今日目標

• 看懂一份「單純要求 AI 加功能」的指令，跟一份「同時要求檢查測試缺口」的指令，實際差在哪裡
• 拿到一段可以直接套用的 CLAUDE.md 規則草稿
• 理解這段規則要有效，需要先滿足哪些前提條件
• 知道這個做法的邊界：AI 能幫你找出缺口，但排優先順序還是要人做

❌ vs ✅：兩種指令方式

❌ 只要求加功能
「幫我在 PurchaseRequest 裡加一個 XXX 付款方式的支援,並寫測試。」

AI 通常會照做：加程式碼、幫新功能寫測試。但不會主動去看「這個檔案裡，除了我剛加的這個功能，還有沒有別的路徑測試覆蓋不足」——這不是 AI 偷懶，是沒人要求它做這件事,它沒有理由自己去找。

✅ 同時要求檢查測試缺口
「幫我在 PurchaseRequest 裡加一個 XXX 付款方式的支援,並寫測試。
另外,在你動手之前,先列出這個檔案裡目前還沒有對應測試覆蓋的其他 public 方法或分支,
列給我看,不用一次全部補齊,但要讓我知道有哪些缺口存在。」

差別不在「AI 有沒有能力做到」，在於有沒有人明確要求它做。第二部 commit 80d3469 那個案例,是開發者自己順手發現 ATM/彈性分期缺測試才補上去；如果換成 AI 執行同一個任務，AI 不會有「順手發現」這種直覺，除非任務描述裡明講要它去找。

一段可以放進 CLAUDE.md 的規則草稿

## 補功能時的測試覆蓋檢查

在幫任何既有類別新增功能或修改邏輯之前，先確認同一個檔案（或同一個高度相關的一組檔案）
目前的測試覆蓋現況：

- 列出這個檔案裡目前「沒有」對應測試的 public 方法、分支或錯誤路徑
- 特別留意 `validate()`、拋出例外的邏輯這類容易被忽略的路徑
- 不需要自作主張把所有缺口都補齊，但要在動手前把清單列給使用者確認，
  由使用者決定這次要不要一併處理

這條規則的目的不是要求每次改動都變成一次全面補測試的大工程，
而是避免「新功能配新測試，舊缺口繼續放著」這種模式無限期持續下去。

這段文字刻意沒有要求「每次都要補齊所有缺口」——如果訂得太嚴格，會變成每次小改動都要先花大量時間補歷史債，這條規則反而會被跳過或關掉。規則要能長期被遵守，通常要先承認「不會馬上解決所有問題」，只解決「讓缺口至少被看見、被記錄」這一步。

這條規則生效的前提

這段規則文字本身不會憑空生效，需要幾個前提配合：

1. AI 真的看得到完整的檔案內容跟對應的測試檔案——如果只把要改的那個方法片段餵給 AI，它沒有足夠上下文判斷「這個檔案裡還有哪些方法缺測試」
2. 使用者願意花時間看 AI 列出的清單——如果每次都直接忽略 AI 列出來的缺口清單，這條規則形同虛設
3. 團隊要有一個地方讓「已知但還沒補的缺口」被記錄下來，不然每次都是列了清單、當下沒空處理，下次又要重新發現一次

第三點特別重要——如果沒有地方記錄，這條規則頂多讓開發者在「當下那一刻」意識到缺口存在,但意識到跟真的排進待辦清單是兩回事。

今日思考題

如果你要把類似的規則寫進自己專案的 CLAUDE.md，你會用什麼方式追蹤 AI 列出來、但當下沒空處理的測試缺口清單？一個 TODO 註解、一份獨立的文件，還是別的做法？

今日重點回顧

• 「加功能」跟「加功能時順便檢查測試缺口」是兩種不同的指令，AI 不會自己升級成後者
• 一段可行的規則文字，重點是要求「列清單給使用者確認」而不是「自動補齊所有缺口」
• 這條規則要生效，需要 AI 有完整上下文、使用者願意看清單、團隊有地方記錄缺口三個前提
• AI 能幫你找出缺口在哪裡，但排優先順序、決定要不要處理，還是要人做

明日預告

明天回到文件漂移的問題：README、CHANGELOG 沒跟上這件事，能不能也用類似的方式讓 AI 幫忙偵測？