在 AI 協作開發的實戰中，有一條常常被技術人員忽略、但極為重要的認知：AI 在骨子裡，其實是一個不折不扣的「作弊仔」。
如果你採用傳統的開發習慣——讓 AI 先把業務功能寫完，再命令它「幫我補上測試程式碼」——AI 為了快速交差，極大機率會使出通靈大招，幫你生出一份「假測試」。例如，它寫的計算逻辑明明把「滿千折百」算錯成了「折兩百」，它寫的測試代碼卻會貼心地把預期結果也寫成二百，然後對系統宣告「測試綠燈，順利通過」。它拿自己寫錯的邏輯，去配上一個絕對會通過的測試，導致你根本抓不出 bug。
為了徹底封殺 AI 的作弊空間，我們必須在環境中強行導入 TDD（Test-Driven Development，測試驅動開發） 的工程紀律。
TDD 防作弊循環
先證明測試會失敗。
再讓 AI 寫到測試通過。
檢查壞味道與作弊行為。
在測試保護下整理。
實戰步驟一：防作弊鐵律——必須先看見紅燈，才能動工寫程式
TDD（測試驅動開發）的核心精神非常簡單：在寫任何一行功能程式碼之前，必須先寫好用來檢查對錯的測試程式碼。
要強迫 AI 誠實，請在實作階段（Implement）命令 AI 嚴格執行以下循環：
第一步：先立下死規矩，並跑出「紅燈（Fail）」：例如要開發「滿千折百」功能，AI 必須先寫一段測試程式：「當購物車金額為 1000 元時，結帳金額必須扣除 100 元」。此時，因為你根本還沒寫任何功能代碼，測試一跑下去，絕對會失敗，系統必須亮起象徵失敗的紅燈。
第二步：功能實作，直到「變綠燈（Pass）」：只有當紅燈確實亮起、證明測試是真的在發揮監督作用後，AI 才能開始撰寫真正的算錢邏輯。AI 必須不斷修改、重試，直到測試程式跑出代表過關的綠燈為止。透過這種「先紅燈、後綠燈」的硬性開發順序，才能徹底擠壓 AI 亂寫、編造假測試的投機空間。
實戰步驟二：保持乾淨認知的 Code Review——導入 12 種重構壞味道檢查清單
當程式碼寫完且測試通過後，Matt Pocock 的系統會自動觸發另一個極具智慧的動作：開啟一個全新的、乾淨的對話視窗（Session）來進行程式碼審查（Code Review）。
之所以要大費周章地開新視窗，是為了讓審查的 AI 保持在最乾淨、最清醒的認知狀態，避免被先前開發過程中殘留的歷史對話記憶干擾。而且，大神的審查 Skill 絕不是空泛地說一句「幫我檢查有無 bug」。它是將軟體工程名著《重構》（Refactoring）中，幾十年來公認的 12 種程式碼壞味道（Code Smells），寫成極其具體的硬性檢查清單：
散彈槍修改（Shotgun Surgery）：你明明只是想改一個按鈕的顏色，AI 卻同時打開了十幾個不同檔案去修改。這代表程式碼邏輯散落各處。Checker 會強制要求 AI 必須把這些四散的程式碼重新集中起來。
依戀情結（Feature Envy）：一段本該處理「訂單」的程式碼，卻老是越權跑去管「庫存」檔案拿資料計算。Review 腳本會立刻發出警告，要求 AI 把這段邏輯移回對應的檔案中。
資料泥團（Data Clumps）：在你的專案中，「買家姓名、電話、地址」這三個變數總是如影隨形地同時在各個檔案間傳遞。既然它們永遠綁在一起，Linter 就會強制要求 AI 必須把它們打包成單一的「聯絡人（Contact）」物件，不准散落傳遞。