2024年AI編程有多強？Google工程主管揭秘殘酷真相
新智元報導
編輯：alan
【新智元導讀】2024年的AI編程到底什麼實力？近日，Google的工程主管Addy Osmani，為我們揭示了AI輔助編碼在一線開發中的真實情況。
2024年，AI編程已然滲透了各行各業，影響著軟件的整個生命週期。
那麼問題來了，AI coding用過都說好，但我們平時用的軟件咋感覺沒什麼進步呢？
近日，Addy Osmani，Google的工程主管，同時也是一位亞馬遜暢銷書作家，為我們揭示了AI輔助編碼在一線開發中的真實情況。
碼農怎麼用AI？
一般來說，團隊利用AI進行開發有兩種不同的模式：「引導程序（bootstrappers）」 和 「迭代器（iterators）」。兩者都在幫助工程師（甚至是非技術用戶）縮小從想法到執行的差距。
Bootstrappers
這一類包括Bolt, v0, 和screenshot-to-code等AI工具，其特點為：
從設計或粗略概念開始；
使用AI生成完整的初始代碼庫；
能夠在幾小時或幾天內獲得工作原型；
專注於快速驗證和迭代
這樣的工作流令人印象深刻。比如一位獨立開發人員可以使用Bolt，在短時間內將Figma設計轉變為有效的Web應用程序。儘管達不到生產級別的要求，但用來獲得初步的用戶反饋綽綽有餘。
Iterators
這一類主要負責日常開發工作流程，包括Cursor、Cline、Copilot和WindSurf等工具，效果沒有上面那麼浮誇，但更加實在，比如：
完成代碼、提供建議；
執行複雜的重構任務；
生成測試和文檔；
作為解決問題的「結對程序員」
雖然這兩種方法都可以大大加快開發速度，但「天下沒有免費的午餐」。
「AI速度」的隱性成本
高級工程師使用Cursor或Copilot等AI工具，可以在幾分鐘內搭建整個功能的基架，並完成測試和文檔，就像變魔術一樣。
但仔細觀察就會發現，在參考AI建議的同時，資深工程師們還會：
將生成的代碼重構為更小的模塊；
添加邊緣情況處理；
優化類型定義和接口；
添加全面的錯誤處理；
甚至是質疑AI給出的架構
換句話說，他們正在用多年積累的工程智慧，塑造和限制AI的輸出。AI負責加速代碼實現，但人類的專業知識確保代碼的可維護性。
而初級工程師就經常錯過這些關鍵步驟。他們更容易接受AI的輸出，從而導致所謂的「紙牌屋代碼（house of cards code）」——看起來很完整，但在現實世界的壓力下會崩潰。
知識悖論
所以實際上，相比於初學者，AI反而更能幫助有經驗的開發人員，——這多少有點反直覺。
高級工程師利用AI快速構建想法的原型（理解）、生成基本實現（可改進）、探索已知問題的替代方法等等；
而初學者卻經常接受不正確或過時的解決方案、忽略關鍵的安全性和性能問題、不知道如何調試AI生成的代碼，最終構建了一個自己不完全理解的脆弱系統。
70% problem
使用AI進行編碼的非工程師，經常遇到一個窘境：他們可以出人意料地迅速完成70%的工作，但最後的30%就相當痛苦了。
「70% problem」揭示了AI輔助開發的現狀，剛開始如有神助，後來被現實按在地上摩擦。
實際情況通常是：
嘗試修復一個小錯誤——>
AI提出了一個似乎合理的更改——>
這個更改破壞了其他一些東西——>
要求AI修復新問題——>
又產生了兩個新bug——>
無限循環
這個循環對於非工程師來說尤其痛苦，因為他們缺乏專業知識來理解真正出了什麼問題。
有經驗的開發人員遇到bug時，可以根據多年的模式識別來推理潛在原因和解決方案。如果沒有這個背景，那基本上就是在用自己不完全理解的代碼「打地鼠」。
學習悖論
還有一個更深層次的問題：讓非工程師使用AI編碼工具，實際上可能會阻礙學習。
代碼生成了、運行了，但「開發者」不瞭解基本原理，此時，他錯過了學習基本模式、沒有培養調試技能、無法對架構決策進行推理，而這份代碼又需要維護和擴展。
於是，「開發者」不斷返回AI來解決問題，而沒有培養自己處理問題的專業能力。
非工程師使用AI編碼工具的最好方式可能是「混合模式」：
1. 使用AI進行快速原型設計
2. 花點時間瞭解生成的代碼是如何工作的
3. 學習基本的編程概念以及AI使用
4. 逐步建立知識基礎
5. 將AI用作學習工具，而不僅僅是代碼生成器
但這需要耐性和奉獻精神，與許多人使用AI工具的目標恰恰相反。
「70% problem」表明，當前的AI還不是許多人希望的那個AI。最後30%的工作（使軟件可用於生產、可維護等），仍然需要真正的工程知識。
最佳實踐
Addy Osmani觀察了幾十個團隊，總結了一些最佳實踐方式：
「AI初稿」模式
讓 AI 生成基本實現；手動審查和模塊化重構；添加全面的錯誤處理；編寫全面的測試；記錄關鍵決策。
「持續對話」模式
為每個不同的任務開始新的AI聊天；保持上下文集中和最小；經常查看和提交更改；保持緊密的反饋循環。
「信任但驗證」模式
使用AI生成初始代碼；手動審查所有關鍵路徑；邊緣案例的自動測試；定期安全審計。
AI的真正前景？
儘管存在這些挑戰，但作者對AI在軟件開發中的作用持樂觀態度。關鍵是要充分利用AI的真正優勢：
加速已知AI擅長幫助實現我們已經瞭解的模式，就像有一個無限耐性的結對程序員，他可以非常快速地打字。
探索可能性AI非常適合快速構建想法原型和探索不同的方法，就像一個沙箱，我們可以在其中快速測試概念。
自動化例程AI大大減少了花在樣板和日常編碼任務上的時間，讓我們可以專注於有趣的問題。
如果您剛剛開始AI輔助開發，作者的建議是，先從小處著手。
將AI用於非耦合的、定義明確的任務，查看生成的每一行代碼，逐漸構建更大的功能。
過程中保持模塊化：將所有內容分解為小的重點文件，在組件之間保持清晰的接口，記錄模塊的邊界。
重要的一點是，相信自己的經驗：AI用來加速而不能取代你的判斷、感覺不對勁時要質疑、時刻維護自己的工程標準。
Agent興起
隨著我們進入2025年，AI輔助開發的格局正在發生巨大變化。雖然當前的工具已經改變了原型設計和迭代方式，但我們正處於更重要轉型的風口浪尖：智能體（Agent）軟件工程的興起。
智能體系統不僅可以響應提示，還將以越來越高的自主性規劃、執行和迭代解決方案。
比如Anthropic的Claude能夠使用計算機，或者Cline自動啟動瀏覽器和運行測試的能力。
在調試過程中，智能體系統不僅給出修復bug的建議，還可以：
主動識別潛在問題、啟動和運行測試套件、檢查UI元素並捕獲屏幕截圖、提出並實施修復、驗證解決方案是否有效。
下一代工具將可以無縫集成視覺理解（UI 屏幕截圖、模型、圖表）、口頭語言對話和環境交互（瀏覽器、終端、API）。
未來的AI不是取代開發人員，而是成為一個越來越有能力的協作者，既可以採取主動，又能尊重人類的指導和專業知識。
參考資料：
https://addyo.substack.com/p/the-70-problem-hard-truths-about
