速度與品質分開看
「vibe coding」——看氛圍寫程式，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 改二十個檔案，出錯時你連從哪裡開始看都不知道。把任務切小：一次一個功能、改完跑測試、過了再下一步。AI 時代 code review 的單位變小了，頻率變高了——這是好事。
守則六：定期還債
就算守則一到五都做到，AI 協作的專案還是會累積比手寫更快的重複與不一致。固定排「清債時段」：找出重複邏輯抽成函式、統一命名、刪掉沒人用的程式碼。債在小的時候還，利息最低。
一個能抓出錯誤的測試
在標籤正規化練習裡，只比對輸出不足以證明「不改動輸入」。保留輸入陣列副本，執行後另行比對，才能發現原地排序的副作用。這種測試辨識的是規格，不是複製實作。
測試也可能寫錯。當需求或原先預期有誤，應先用可核對依據更正規格與測試，再修改實作；不能為了通過而任意放寬斷言。
官方資料與延伸閱讀
方案、可用功能與限制會更新，請以連結中的官方說明及帳號當下顯示為準。本文的練習是編輯設計的示例，不是工具效能實測。