前言：制度跟自覺，哪個更靠得住？

第二部用一筆真實的 commit，帶出了一連串觀察。今天把它們收在一起，回答一開始留下的問題：制度跟自覺，哪個更靠得住？

今日目標

• 回顧第二部（Day 08-13）六天的觀察，看它們怎麼串成一條完整的論證
• 明確回答「制度 vs 自覺，哪個更靠得住」，但不是簡化成二選一的答案
• 呼應全系列主題句，準備銜接第三部要看的跨版本相容性與靜態分析工具
• 帶著一個具體的判斷框架離開這一部，而不是只有一堆案例的印象

六天看到了什麼

• Day 08：一筆 commit 的訊息講的範圍，比程式碼實際變更的範圍還大——這個落差本身就是線索
• Day 09：拆解出「新功能配新測試」跟「順路補測試」兩種節奏，後者是務實的機會成本判斷，不是沒紀律
• Day 10：RefundRequest/VoidRequest 至今沒等到「順路」機會，證明這個機制依賴運氣，介面越穩定的程式碼越容易被冷落
• Day 11：AI 不會自動承接「順路補測試」的直覺，因為它沒有持續性的專案責任感，這件事必須每次明確交代
• Day 12：把前面的觀察歸納成一句話——這個套件目前完全靠自覺跟隨機的修改機會在驅動測試覆蓋，沒有制度性機制兜底
• Day 13：給出具體的 prompt 範例，示範怎麼把「順路補測試」的直覺，轉譯成 AI 能承接的明確指令

回答問題：制度 vs 自覺，哪個更靠得住

答案不是「制度贏」，也不是「自覺贏」，而是這兩者解決的是不同的問題，缺一不可。

自覺的強項是判斷精準——testInvalidCheckMacValue 那種對安全關鍵路徑的直覺敏感度，靠的正是開發者的自覺,不是任何覆蓋率工具能自動生成的。工具只會告訴你「這行程式碼有沒有被執行過」，不會告訴你「這行程式碼一旦出錯後果有多嚴重」——這個判斷永遠需要人。

制度的強項是均勻性——它不管你當下有沒有動機、有沒有剛好打開那個檔案，只要條件沒達到就會被看見。RefundRequest/VoidRequest 的缺口如果靠自覺，可能永遠等不到被補上的一天；但如果有一個機制定期（不管是覆蓋率門檻，還是 Day 13 那種定期健檢 prompt）主動把這種缺口攤出來,它就有機會被看見、被排進待辦清單。

靠自覺,你會把最擅長判斷風險的地方做到最好；靠制度,你能保證沒有一個角落被完全遺忘。兩者疊在一起,才是完整的品質防線——這也是為什麼這個系列的主題句是「AI 能幫你補程式碼，但補不出你自己都沒發現的測試缺口」，AI 再怎麼強，扮演的都是「補程式碼」的角色，「發現缺口」這件事，永遠需要某種形式的制度或自覺在背後撐著,AI 才有東西可以補。

銜接第三部

前兩部看的都是「測試覆蓋」這個面向。但品質防線不是只有測試一件事——一個套件要跨越 PHP 7.1 到 8.3 這麼寬的版本矩陣、要面對沒有 PHPStan 的型別把關現況，這些也是防線的一部分,而且防線裡的破洞跟前面看到的一樣真實。

今日思考題

回顧第二部這六天，如果要你替自己手上的專案設計一個「介於完全自覺跟完整制度之間」的過渡做法，你會先從哪一步開始？

今日重點回顧

• 制度跟自覺解決的是不同問題：自覺負責判斷精準，制度負責保證均勻
• 這個套件目前完全依賴自覺跟機會,是第二部六天觀察疊加出的結論
• 兩者不是二選一，是互補關係——AI 能加速「補程式碼」，但「發現缺口」永遠需要制度或自覺在背後撐著
• 品質防線不只是測試覆蓋一件事，第三部會看跨版本相容性跟靜態分析工具這個新的面向

明日預告

明天進入第三部：這個套件的 CI 矩陣涵蓋 PHP 7.1 到 8.3，但 composer.json 完全沒有宣告最低版本限制——這個相容性防線,實際上是怎麼撐住的？