用可驗證規則取代主觀判斷，作為 AI 編碼助手的品質門檻

這份工程紀律的核心邏輯是：不信任 AI 編碼助手「應該沒問題」這類主觀判斷，改用具體、可量化的規則強制產生證據，才允許判定任務完成。

三條規則共同構成同一套機制：

  1. 先寫失敗測試，再寫功能實作：新功能開發流程改為 TDD 順序——先寫一個會失敗的測試，功能完成的定義是「測試由紅轉綠」，而不是「程式碼寫完了」。這讓「完成」有客觀驗證點，不再依賴主觀感覺。
  2. 用量化門檻自動觸發審查：修改超過 20 行的 PR，強制執行 /review。用「行數」這種可自動偵測的數字，取代人工判斷「這次要不要仔細審查」，避免因疲勞或僥倖心態而跳過審查。
  3. 禁止模糊結論，要求具體證據：這是貫穿前兩條的元原則——任何「看起來應該沒問題」的說法都不被接受，取而代之的必須是測試結果、review 輸出等可檢驗的產出物。

三者的共通策略是：把品質控管從「依賴判斷力」轉換成「依賴可觸發、可驗證的機制」，這對容易在大量產出下產生虛假自信的 AI 編碼助手特別重要，也是設計 Agent 工作流程規範時可延伸套用的一般模式。

#Skills #TDD #Code Review