十倍速的兩面
AI 寫程式的效率提升是真實的：原型一個下午就能跑起來、樣板代碼不用再手打、陌生框架的學習曲線被壓平。但同一件事的另一面是：爛程式的產量也快了十倍。以前寫出一千行技術債要一週，現在一個晚上就夠了——而且這些債看起來整潔、有註解、充滿專業感。
「vibe coding」——看氛圍寫程式，AI 產什麼收什麼，能跑就過——拿來做週末玩具專案完全沒問題。但只要這段程式碼會活過一個月、會被別人接手、會碰到真實使用者，你就需要一套紀律。
AI 代碼的五種典型缺陷
1. 幻覺 API
呼叫了不存在的函式、用了三個版本前就被移除的參數、引用了名字很合理但根本沒有的套件。這類錯誤編譯期通常抓得到，真正危險的是「存在但行為不同」的呼叫——名字對了、參數對了、語意錯了。
2. 過度防禦
每個函式都 try/catch、每個參數都判空、錯誤被吞掉然後回傳 null。看起來「很安全」，實際上是把爆炸點從「出錯的地方」搬到「三層之外某個莫名其妙的地方」。錯誤要在邊界處理，不是在每一層都包一次。
3. 為了過而過
這是最陰險的一類：測試跑不過，AI 把斷言改寬；型別報錯,AI 塞一個 any 或強制轉型；lint 不過,AI 加一行 disable 註解。症狀消失了，病還在——而且下次發作的時候，現場已經被清理乾淨了。
4. 複製貼上式重複
AI 不會記得它十分鐘前在另一個檔案寫過幾乎一樣的邏輯。放著不管，三個月後你會有六個「大同小異」的實作，改一個 bug 要改六個地方。
5. 看起來完成了
AI 很擅長交出「形狀正確」的成品：函式簽名漂亮、註解齊全、demo 路徑能跑。但邊界條件、並發、錯誤路徑這些「不在快樂路徑上」的部分，常常是空的或錯的。形狀正確和真的正確，中間隔著一次認真的審查。
六條守則
守則一：讀不懂就不合併
這是整套紀律的地基。你合併的每一行程式碼，出了問題都是你的名字在 git blame 上。讀不懂的段落，要嘛請 AI 逐段解釋到你懂，要嘛請它改寫成你讀得懂的版本。「AI 寫的我也不太確定」在事故檢討會上不是一句能說出口的話。
守則二：先寫驗收，再要程式
在請 AI 寫實作之前，先確定「怎樣算對」：測試案例、輸入輸出範例、邊界條件清單。先有驗收標準，AI 的產出就有客觀的對錯；沒有驗收標準，你只能憑感覺，而感覺會被漂亮的程式碼騙走。
守則三：測試不准跟著實作改
AI 修 bug 時改測試斷言、把失敗的測試 skip 掉，都要當成紅色警報。規矩很簡單：測試描述的是「應該的行為」，實作要遷就測試，永遠不是反過來。審查 diff 時先看測試檔有沒有被動過。
守則四：小步走，勤驗證
一次讓 AI 改二十個檔案，出錯時你連從哪裡開始看都不知道。把任務切小：一次一個功能、改完跑測試、過了再下一步。AI 時代 code review 的單位變小了，頻率變高了——這是好事。
守則五：架構決策自己做
AI 給的架構建議永遠「聽起來很對」，因為它擅長生成聽起來很對的文字。要不要引入這個套件、要不要抽這層抽象、資料模型長什麼樣——這些決策的後果會跟著專案三年，而 AI 不用負責任何後果。讓 AI 提供選項和利弊，決定權留在會被 on-call 電話吵醒的人手上。
守則六：定期還債
就算守則一到五都做到，AI 協作的專案還是會累積比手寫更快的重複與不一致。固定排「清債時段」：找出重複邏輯抽成函式、統一命名、刪掉沒人用的程式碼。債在小的時候還，利息最低。
一個心智模型：AI 是無限精力的 junior
把 AI 當成一個打字飛快、讀過所有文件、永遠不累、但沒有品味也不承擔後果的 junior 工程師。你不會讓這樣的人直接 push 到 main——你會給他清楚的規格、審他的每個 PR、教他專案的慣例，然後隨著信任累積，逐步放大他的任務。對 AI 也一樣，差別只是這位 junior 的產能是全團隊加起來的十倍，所以你的審查紀律必須跟著升級，而不是跟著鬆懈。
結語
「AI 會不會取代工程師」是個無聊的問題，真正的分水嶺是：有紀律地用 AI 的工程師，正在取代沒有紀律地用 AI 的工程師。速度是 AI 給的，品質永遠是人給的——這條線暫時看不到被跨過的跡象。