06. 為什麼「用 AI 寫代碼」反而可能帶來負產出？

速度的背叛：從 Demo 的「起飛」到項目的「墜落」

在與大量一線研發團隊交流後，我觀察到了一個普遍存在的**「倒 U 型」效率曲線**： 在項目初期的 Demo 階段，AI 確實能帶來驚人的 3-5 倍提速。原本需要兩週的原型，現在兩天就能跑通。 但在進入為期數月的完整項目週期（包含測試、修復、變更）後，整體交付效率的提升幅度會迅速回落，甚至在某些缺乏治理的團隊中出現負增長。

很多管理者對此百思不得其解：「AI 寫出的代碼看起來很規範，註釋也很詳細，甚至還貼心地寫了單元測試，為什麼到了項目後期，我們反而陷入了無盡的 Debug 和返工？」

答案隱藏在代碼的表象之下：AI 是一個完美的「執行者」，但它是一個糟糕的「質疑者」。

AI 的致命缺陷：默認「問題正確」

人類工程師在接到需求時，第一反應通常是質疑：

• 「為什麼要做這個功能？」
• 「這個邏輯是不是和現有的權限體系衝突？」
• 「這個數據結構後面擴展會有問題吧？」

而 AI 的第一反應是順從。 如果你告訴 AI：「請幫我寫一個函數，每秒鐘輪詢一次數據庫，檢查有沒有新訂單。」 AI 會立刻給你寫出一個完美的、帶重試機制的、甚至處理了異常連接的輪詢函數。

但它不會告訴你：「在高並發場景下，每秒輪詢數據庫會把 DB 打掛，你應該用消息隊列。」

這就是 「高質量的錯誤執行」。 AI 用極其優雅的代碼，高效地實現了一個從架構上就是錯誤的設計。如果此時使用 AI 的工程師缺乏足夠的判斷力去識別這個架構缺陷，那麼這行優雅的代碼就是一顆埋在系統裡的定時炸彈。

漂亮代碼的欺騙性

更可怕的是，AI 生成的代碼往往具有極強的欺騙性。

以前，初級工程師寫的爛代碼通常長得很醜：縮進混亂、變量名拼音混雜、邏輯嵌套過深。資深工程師一眼就能看出來：「這代碼不行，得重寫。」

現在，AI 生成的代碼長得非常「專業」：符合 PEP8 規範，變量名地道，甚至還有 Docstring。 這種「漂亮的皮囊」會極大地降低審查者的警惕性。 Code Reviewer 可能會下意識地覺得：「寫得這麼工整，應該沒問題吧？」從而忽略了對核心業務邏輯的深層審查。

這就是為什麼 AI 帶來的 Bug 往往比人類手寫的 Bug 更難排查：它們披著「正確」的外衣，潛伏在系統的最深處。

誰有資格「監督 AI」？

這就引出了一個關鍵的管理問題：在你的團隊裡，誰有資格按住 AI 的「確認鍵」？

我認為，管理者必須設定一條紅線： 只有當一個人有能力不依賴 AI 獨立寫出這段代碼，或者至少能完全讀懂這段代碼的每一行邏輯時，他才有資格使用 AI 生成這段代碼。 而這條紅線，必須由管理者承擔解釋成本，而不是由工程師獨自承擔後果。

如果一個工程師連 SQL 的 Join 機制都不懂，就讓 AI 生成複雜的報表查詢語句，這不僅僅是偷懶，這是在瀆職。 這裡的問題，並不在於個人能力，而在於組織是否允許、甚至鼓勵在缺乏理解的情況下直接確認。

結語：判斷權的回歸

AI 時代，我們面臨的最大風險，不是 AI 不夠聰明，而是我們太容易放棄判斷權。

當生成代碼變得如此容易，思考「代碼背後的邏輯」就變成了一件苦差事。 但正是這件苦差事，構成了工程師的核心價值。

對於管理者來說，現在的挑戰不是如何鼓勵大家多用 AI，而是如何建立一套機制，防止大家在 AI 的糖衣砲彈下喪失了對複雜度的敬畏。

記住：AI 不是銀彈，它只是把執行這件事變得更快。AI 可以幫你省下敲鍵盤的時間，但它絕不應該省下你思考的時間。