即使程式碼可以運作，何時仍應拒絕 AI 生成的程式碼

AI 輔助開發中的審查瓶頸

AI 編碼代理（AI coding agents）已將軟體開發的主要瓶頸從實作轉移到了審查。雖然 AI 可以快速生成大量程式碼，但審查一份開發者並未親自構思的 git diff 所需的認知負荷，顯著高於審查手寫實作的程式碼。

拒絕 AI 生成程式碼的標準

可以運作的程式碼並不等同於良好的解決方案。一個通過 CI（Continuous Integration）並能在本地端運行的解決方案，並不一定符合擴展性、可延伸性或可維護性的要求。應根據以下標準拒絕 AI 生成的程式碼：

• 缺乏概念性理解：當開發者無法用自己的話解釋該方法時，應拒絕該程式碼。
• 過大的 Diff Size：當變更的大小（the diff）與所解決的問題不成比例地大時，應拒絕該程式碼。
• 過度抽象：當在尚未證明抽象的必要性之前就引入了新的抽象時，應拒絕該程式碼。
• 降低可推理性：當實作方式使得系統變得更難以推理時，即使功能正確，也應拒絕該程式碼。
• 過度依賴輸出：當開發者對 AI 輸出的信任程度超過了對系統本身的理解時，應拒絕該程式碼。

工程師的角色作為引導者

有效使用 AI 編碼代理需要流程上的轉變。工程師不應讓代理驅動實作，而必須由工程師來驅動代理。這包括在指示 AI 實作特定的、已規劃的解決方案之前，先鞏固問題定義並整合上下文資訊。

成功的實作通常需要多次對話。在許多情況下，為了讓工程師能更好地理解問題空間，可能會完全拒絕第一次 AI 生成的嘗試。最終解決方案品質的差異，通常不是因為使用了不同的 LLM 模型，而是因為工程師提供了更好的引導與更精確的問題定義。

人類審查的必要性

由於工程師往往過快地接受了 AI 生成的變更，人類審查仍然是一項關鍵的保障。人類審查能確保實作是一個充足、具擴展性且具可延伸性的解決方案，而不僅僅是一個能讓 CI 變綠的解決方案。