它失效的地方

對它的邊界要誠實，因為無人監督的 vibe coding 正是在這些地方把人坑慘：

• **深奧而新穎的邏輯。**微妙的演算法、併發、任何"對了 95%"就等於"壞了"的東西。模型即便錯了也很自信。
• **鋪得很開的跨檔案改動。**它在大型程式碼庫裡會跟丟線索，悄無聲息地搞壞它看不見的東西。
• **安全和錢。**認證、支付、許可權，任何一個看似合理的 bug 會帶來真實後果的地方。審查這些時要像你的飯碗繫於此一樣，因為它可能真的是。
• **規格說明不足的問題。**如果你都不知道正確長什麼樣，AI 沒法讀你的心。規格說明是垃圾進，程式碼就是垃圾出。

失敗的模式幾乎總是一樣的：程式碼看起來對，在順利路徑上能跑，卻以一種你只要讀了就能抓住的方式錯了。解藥就是審查這一步。它無法被跳過。

兩個問題就能把任何任務放到這張地圖上——模式是否常見，以及結果是否容易核查:

                   易於驗證            難以驗證
                ┌──────────────────┬──────────────────┐
   常見         │   純賺           │   放慢,          │
   模式         │   (腳手架,       │   要求測試       │
                │   樣板           │                  │
                ├──────────────────┼──────────────────┤
   罕見 /       │   需讀但可行     │   危險區         │
   新穎         │                  │   (新邏輯,       │
                │                  │   鑑權, 金錢     │
                └──────────────────┴──────────────────┘

注意上面那條規則的反面：這些都是罕見、微妙、或驗證成本高的情形。模式不常見，所以模型在猜；或者 bug 在順利路徑上不可見，所以快速檢查抓不到。這並不意味著在這裡就要躲開 AI——它意味著你要放慢、把步子切小、要求測試，並把每一行都當作有敵意的來讀。