AI 產生的程式碼應被視為“初稿”，而非“定稿”！ 來自GoogleChrome 工程負責人@addyosmani 的博客，他的觀點非常明確：AI 生成的代碼應被視為“初稿”，而非“定稿”，應該把AI 當作“一位勤奮但缺乏經驗的實習生”。 Osmani 提出，AI 產生的程式碼往往看起來很完美，但它缺乏對上下文的深刻理解和對「意圖」的掌握。因此，我們對待AI 程式碼的態度，應該像對待一位初級開發者或實習生的程式碼一樣： · 可以利用它來提高速度：讓它去寫樣板程式碼、做繁瑣的苦力活。 · 絕不能外包「閱讀」和「理解」的過程：你可以讓AI 寫，但必須由人來讀和審。 為什麼必須這樣做？ （潛在風險） 1. 意圖與行為的斷裂(Intent vs. Behavior) · 如果你不去閱讀和理解程式碼，你就切斷了「程式碼行為」與「設計意圖」之間的連結。 · 一旦程式碼出了問題，如果你當初沒有審閱過，你就無法知道它為什麼是這樣寫的，維護將變成一場噩夢。 2. 技能退化(Skill Atrophy) · 盲目接受AI 的輸出會侵蝕工程師的批判性思考和調試能力。 · 正如一位工程師所言：“如果我們停止驗證AI 的輸出，不僅會引入即時的Bug，還會系統性地降低我們需要用來發現這些錯誤的能力。” 3. 由於「看起來正確」而產生的誤導· AI 代碼往往能跑通，測試也能過，但可能存在微妙的邏輯漏洞、安全隱患（如注入漏洞）或處理不好邊緣情況。 · 記住：LLM 不會發布糟糕的程式碼，發布糟糕程式碼的是團隊。 責任永遠在人。 實操建議：如何與AI 共存 Osmani 給了一些具體的建議，幫助團隊在利用AI 提效的同時保持程式碼品質： · 建立「Human-in-the-loop」：AI 可以起草第一版，但必須由人來確保程式碼的行為符合預期目的。 · 嚴格的程式碼審查：對AI 程式碼的審查標準不能降低，甚至應該比審查人類同事的程式碼更嚴格。 · 不只是「能跑就行」：不僅要驗證程式碼是否能運作，還要理解它是如何運作的。不要合併任何你沒讀懂的程式碼。 · 利用自動化工具：雖然要有人的審查，但也可以利用智能體工具來進行自動化的Lint 檢查、正規匹配和單元測試，作為輔助防線。 部落格網址：
