前言：把「順便檢查」寫成能照著做的 prompt

Day 11 講了心態：AI 不會自動「順路」注意到測試缺口，除非你明確要求。今天把這件事變成真的能照著做的方法——給幾個具體的 prompt 範例，示範怎麼問才會問到重點。

今日目標

• 拿到 1-2 組可以直接套用的 prompt 範例，用來要求 AI 在補功能時一併檢查測試缺口
• 理解為什麼「請幫我補齊測試」這種模糊的要求通常問不到重點
• 知道怎麼把 Day 09-10 學到的「順路補測試」邏輯，轉譯成 AI 聽得懂的具體指令
• 認清這個方法的侷限：AI 列出來的缺口清單，仍然需要人判斷「要不要補、優先順序是什麼」

為什麼籠統的要求問不到重點

如果你只是說「幫我看看這個套件的測試夠不夠」，AI 通常會給一堆泛泛的建議（「建議增加邊界值測試」「建議提高覆蓋率」），聽起來正確，但不具體到能直接動手。原因是這個要求沒有限定範圍，也沒有給出判斷「夠不夠」的標準——AI 只能用它自己對「一般來說測試該長什麼樣子」的理解去回答，而不是針對這個套件實際的程式碼現況。

❌ vs ✅：模糊要求 vs 帶著範圍跟依據的要求

❌ 模糊的要求
"這個套件的測試夠嗎？幫我看一下"
→ AI 只能給通用建議,答案跟這個套件的實際現況脫鉤

✅ 帶著具體範圍跟比對依據的要求
"我要在 src/Message/PurchaseRequest.php 加一個新的付款方式支援。
 完成這個功能跟對應測試後，
 請列出這個檔案裡所有 private 的 getXxxFields() 方法，
 逐一確認 tests/Message/PurchaseRequestTest.php 裡
 有沒有對應的測試案例覆蓋到；
 如果有方法完全沒被任何測試呼叫到，列出方法名稱，
 不要自己決定要不要補，先讓我確認"
→ AI 有明確的檢查對象（哪個檔案的哪一類方法）、
   明確的比對依據（對照哪個測試檔案）、
   明確的產出格式（列清單，不要自作主張動手改）

正例的 prompt 之所以問得到重點，關鍵在三個具體限定：檢查誰（哪個檔案、哪一類方法）、依據什麼（對照哪份測試）、產出成什麼（清單，而不是直接動手）。這三件事對應到 Day 09 講的「順路補測試」發生的實際過程——人類開發者是先鎖定「我正在改的這個檔案」，再對照「這個檔案已經有的測試」，才發現缺口，AI 需要同樣的鎖定過程，才能問到重點。

再進一步：把「檢查」擴大到整個套件層級

如果不是針對單一功能改動，而是想定期健檢整個套件，prompt 可以這樣調整：

✅ 套件層級的健檢 prompt
"讀 src/Message/ 底下所有類別，
 統計每個類別有幾個 public 方法、
 tests/Message/ 裡對應的測試類別有幾個測試方法，
 用表格列出來，並標注哪些類別的測試方法數
 明顯少於它的 public 方法數（差距超過一半以上算明顯）。
 不需要幫我補測試,只要列出清單讓我自己判斷"

這其實就是 Day 05 那張測試覆蓋分布表格的做法——只是這次是請 AI 幫你生成，而不是自己手動盤點。這也回答了 Day 12 提出的問題：在還沒有覆蓋率門檻這種正式制度的情況下,用這種定期健檢的 prompt,可以是一個介於「完全靠自覺」跟「靠正式覆蓋率工具」之間的過渡做法。

這個方法的侷限

AI 能幫你列出「哪裡沒被測到」，但列出清單之後，要不要補、先補哪個，仍然是人的判斷。Day 10 已經說明過，RefundRequest/VoidRequest 的測試缺口不是因為不重要才被冷落，只是沒等到「順路」的機會——AI 列出這個缺口之後，你還是得自己權衡「這個缺口的風險有多高、現在有沒有時間補」，AI 不會替你做這個判斷，也不應該替你做，因為它不知道你團隊的風險偏好跟資源狀況。

今日思考題

如果你現在把今天的 prompt 範例套用到自己手上的專案，你猜會列出哪些「早就存在但沒被測到」的方法？在看到答案之前，先猜猜看——這個猜測跟實際結果的落差，本身就是一個有意思的資訊。

今日重點回顧

• 模糊的「幫我看測試夠不夠」問不到重點，因為沒有限定範圍跟比對依據
• 有效的 prompt 要包含：檢查誰、依據什麼比對、產出成什麼格式（清單而非直接動手）
• 可以把這種檢查擴大成套件層級的定期健檢 prompt，當作覆蓋率門檻正式上線前的過渡做法
• AI 只能列出缺口清單，要不要補、先補哪個，仍然是人的判斷，這件事不該外包給 AI

明日預告

明天是第二部的小結，回到「制度 vs 自覺，哪個更靠得住」這個問題，收斂前七天看到的所有觀察，為第三部（跨版本相容性、靜態分析工具）鋪路。