人的角色：審查、品味與擁有權

AI 生成程式碼這件事，最容易被誤解的部分不是技術，而是角色：工程師的工作變了，但工程師沒有被取代。從「主要生產者」轉換成「意圖定義者、驗證者、審查者、責任擁有者」——每個角色都需要更深的能力，不更淺。

草稿 vs 成品

AI 產出是草稿，不是成品。這不是謙遜的說法，而是工程事實：

草稿的用處是：把「打字」這件事的成本壓到幾乎為零，讓工程師的時間和注意力集中在判斷（草稿是否正確、是否符合意圖、是否可維護）而不是生產。

接受草稿而不做判斷，不是「善用 AI」，是把工程師最重要的工作外包給了一個不承擔後果的系統。

一、審查（Review）

有領域知識的人看 AI 生成物，識別問題、確認正確、批准整合。這不是走形式。Code review 的五個維度（正確性、可讀性、架構、安全性、效能）在 AI 生成的程式碼上，每一個都不能省略——因為 AI 的靜默失敗模式（見 AI 生成程式碼的失敗模式）正好分佈在這五個維度的薄弱點上。

審查的深度不應該因為「這是 AI 生成的、速度快」而降低。生成速度和審查嚴謹度是不相關的兩件事；把它們混淆，是技術債積累的常見原因。

二、判斷（Judgment）

哪些決策是正確的，哪些需要 trade-off 分析，哪些看起來可行但長期有問題——這需要工程判斷，不是 AI 能替代的。

特別是 Doubt-Driven 的那類判斷：「AI 給了一個方案，它說這個方案更好，我是否主動試圖找它的反例？」默認接受 AI 的建議，而不是主動懷疑它，是一種判斷的放棄。

三、品味（Taste）

什麼是好的程式碼？什麼是不必要的複雜度？什麼樣的架構決策能在六個月後讓接手的工程師輕鬆理解，而不是苦苦追蹤？

品味是從閱讀大量程式碼、寫大量程式碼、維護過大量程式碼、被大量技術債燒過之後積累的判斷力。它不是可量化的規則，是一種模式識別——看到一段設計，能感覺出「這裡有問題，我說不太出來確切是什麼，但我知道它以後會讓人頭痛」。

AI 沒有品味。它有訓練資料裡常見的模式，但常見的模式不等於好的模式。辨別 AI 給的是「常見模式」還是「你這個系統裡真正合適的設計」，需要品味。

四、擁有權（Ownership）

這段程式碼是你的，不是 AI 的。當它在 production 出問題，你要能理解它、解釋它、修復它。

「AI 寫的，我不太確定為什麼這樣設計」是一個紅旗，不是一個藉口。如果你不能解釋一段程式碼的設計理由，它不應該進 production。

擁有權不是象徵性的，它是功能性的：你擁有一段程式碼，意味著你理解它的假設、它的限制、它在什麼情況下會失敗、如何修復。沒有這些，你擁有的只是一段功能不明確的字元序列。

工程師在 AI 輔助開發裡的核心工作，從「生產程式碼」轉向「確保程式碼是正確的、可維護的、可解釋的」。這個轉換有幾個實際含義：

寫好 spec 比打程式碼更重要：把 30 分鐘花在寫清楚 spec 上，比花在等 AI 生成然後反覆修正上，ROI 更高。

能快速識別 AI 的錯誤比能快速使用 AI 更重要：知道「AI 哪類問題容易犯錯」的工程師，比「能快速讓 AI 生成更多程式碼」的工程師，在 AI 時代更有價值。

工程深度更重要，不更不重要：只有真正理解系統、理解領域、理解業務規則的工程師，才能有效審查 AI 生成物。「我不太懂這個系統，AI 懂」——這是危險的，因為 AI 其實也不懂，它只是不說。

「Vibe coding」是 AI 時代出現的一個詞，指的是不寫 spec、不寫測試、不做 review，把 AI 的生成物直接接受進 production 的開發方式。

Vibe coding 有它的適用場景：個人實驗、快速 prototype、一次性腳本、不需要長期維護的工具。在這些場景，速度的優先權高於其他一切，對品質的期望也低。

Vibe coding 不適用的場景：生產系統、有業務邏輯的服務、需要長期維護的 codebase、有用戶資料或安全需求的系統。在這些場景，vibe coding 積累的技術債，代價最終由維護者（和用戶）承擔。

知道何時 vibe coding 可以接受、何時需要完整的工程紀律——這本身也是一種判斷力。