當防護欄尖叫時：先分診，再修

防護欄只有在你好好回應時才有用，而失敗模式是可預料的：構建變紅了，你有點慌，然後把報錯貼給 AI，附上"修一下"。有時這管用。但更多時候，它會造出一個修復——讓紅字消失，卻沒有處理真正出錯的地方：AI 把測試削弱了、把型別放寬了，或者把那個失敗的呼叫包進一個會吞掉問題的 try/catch 裡。

在你放任它去"修"任何東西之前，花十秒做個分診。防護欄的失敗其實只有三類：

• 一個你剛剛引入的真 bug。 檢查正在盡職。去修程式碼，而不是修檢查。
• 一個現在已經過時的測試。 你是故意改了行為，舊的斷言不再匹配了。把測試更新為斷言新的正確行為——是經過深思的，而不是條件反射式的。
• 一個不穩定或本身就錯的檢查。 真的很罕見。在這裡要懷疑你自己；這正是人們用來傾倒真 bug 的那個桶，因為它是唯一一個能讓你矇混過關、繼續往前走的桶。

那條能讓 AI 保持誠實的指令，是逼它在改任何東西之前先做診斷：

"never discounts below zero" 這個測試失敗了。
首先，告訴我它為什麼失敗——程式碼現在做了什麼，對比
測試期望什麼。然後告訴我哪個才是對的：程式碼，還是測試。
在我確認之前，什麼都別改。

那一次停頓，就是"一個保護你的防護欄"和"一個被你悄悄訓練 AI 去攻克的防護欄"之間的區別。一個紅色的檢查是資訊；你能做的最糟的事，就是在沒讀懂它想告訴你什麼之前，就花代價把它弄綠。