AI寫程式時代真的來臨？Google 工程師解析如何利用 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 輔助開發的格局正在發生巨大變化。雖然目前的工具已經改變了原型設計和迭代方式，但我們正處於更重要轉型的風口浪尖：AI代理（Agent）軟體工程的興起。AI代理不僅可以回應提示，還將以越來越高的自主性規劃、執行解決方案。

比如 Anthropic 的 Claude 能夠使用電腦，或者 Cline 自動啟動瀏覽器和運行測試的能力。

在除錯過程中，AI代理系統不僅給出修復 bug 的建議，還可以：主動識別潛在問題、啟動和運行測試套件、檢查 UI 元素並捕獲螢幕截圖、提出並實施修復、驗證解決方案是否有效。

下一代工具將可以無縫整合視覺理解（UI 螢幕截圖、模型、圖表）、口頭語言對話和環境互動（瀏覽器、終端、API）。

未來的 AI 不是取代開發人員，而是成為一個越來越有能力的協作者，既可以採取主動，又能尊重人類的指導和專業知識。