2024年的AI程式設計到底什麼實力？近日，Google的工程主管Addy Osmani，為我們揭示了AI輔助編碼在一線開發中的真實情況。 2024年，AI程式已然滲透了各行各業，影響著軟體的整個生命週期。那麼問題來了，AI coding用過都說好，但我們平常用的軟體咋感覺沒啥進步呢？

近日，Addy Osmani，Google的工程主管，同時也是一位亞馬遜暢銷書作家，為我們揭示了AI輔助編碼在一線開發中的真實情況。

碼農怎麼用AI？

一般來說，團隊利用AI進行開發有兩種不同的模式：「引導程式（bootstrappers）」 和「迭代器（iterators）」。兩者都在幫助工程師（甚至是非技術用戶）縮小從想法到執行的差距。

引導者

這一類包括Bolt， v0， 和screenshot-to-code等AI工具，其特點為：

從設計或粗略概念開始；

使用AI產生完整的初始程式碼庫；

能夠在幾小時或幾天內獲得工作原型；

專注於快速驗證和迭代

這樣的工作流程令人印象深刻。例如一位獨立開發人員可以使用Bolt，在短時間內將Figma設計轉變為有效的Web應用程式。儘管達不到生產等級的要求，但用來獲得初步的用戶回饋綽綽有餘。

迭代器

這一類主要負責日常開發工作流程，包括Cursor、Cline、Copilot和WindSurf等工具，效果沒有上面那麼浮誇，但更實在，例如：

完成程式碼、提供建議；

執行複雜的重構任務；

產生測試和文件；

作為解決問題的“結對程式設計師”

雖然這兩種方法都可以大大加快開發速度，但「天下沒有白吃的午餐」。

「AI速度」的隱性成本

高級工程師使用Cursor或Copilot等AI工具，可以在幾分鐘內建造整個功能的基架，並完成測試和文檔，就像變魔術一樣。

但仔細觀察就會發現，在參考AI建議的同時，資深工程師們還會：

將生成的程式碼重構為更小的模組；

新增邊緣情況處理；

優化類型定義和介面；

添加全面的錯誤處理；

甚至是質疑AI給的架構

換句話說，他們正在用多年累積的工程智慧，塑造和限制AI的輸出。 AI負責加速程式碼實現，但人類的專業知識確保程式碼的可維護性。

而初級工程師就常常錯過這些關鍵步驟。他們更容易接受AI的輸出，從而導致所謂的「紙牌屋代碼（house of cards code）」——看起來很完整，但在現實世界的壓力下會崩潰。

知識悖論

所以實際上，相較於初學者，AI反而更能幫助有經驗的開發人員，──這多少有點反直覺。

資深工程師利用AI快速建立想法的原型（理解）、產生基本實作（可改進）、探索已知問題的替代方法等等；

而初學者卻經常接受不正確或過時的解決方案、忽略關鍵的安全性和效能問題、不知道如何調試AI生成的程式碼，最終構建了一個自己不完全理解的脆弱系統。

70%的問題

使用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不是取代開發人員，而是成為一個越來越有能力的協作者，既可以採取主動，又能尊重人類的指導和專業知識。

來源：新智元