(經原作同意轉載翻譯，原文來自 The 70% problem: Hard truths about AI-assisted coding)
在花了幾年的時間投入人工智慧輔助開發之後，我注意到一個很有趣的現象。儘管工程師們表示使用人工智慧後生產力大幅提升，但我們日常使用的軟體似乎並沒有明顯變得更好。這是怎麼回事？
我想我知道原因，而這個答案揭示了我們需要正視的軟體開發的一些根本真相。讓我跟你分享我的發現。
開發者實際上如何運用人工智慧
我觀察到團隊運用人工智慧進行開發的兩種截然不同的模式。我們稱之為「快速建構派」(bootstrappers) 和「迭代優化派」(iterators)。這兩種模式都在幫助工程師（甚至是非技術用戶）縮短從想法到執行（或最小可行產品, MVP）的距離。
快速建構派：從零到最小可行產品 (MVP)
像 Bolt、v0 和截圖轉程式碼 (screenshot-to-code) 人工智慧工具正在徹底改變我們啟動新專案的方式。這些團隊通常會：
-
從設計或粗略概念開始
-
利用人工智慧產生完整的初始程式碼
-
在幾小時或幾天內取得可運作的原型，而非數週
-
專注於快速驗證和迭代
成果可能令人印象深刻。我最近親眼看到一位獨立開發者使用 Bolt 將 Figma 設計轉換成一個運作中的網頁應用程式，幾乎是轉眼間就完成。雖然這個版本不具生產環境的品質，但已經足夠蒐集最初的使用者回饋。
迭代優化派：日常開發
第二個陣營使用 Cursor、Cline、Copilot 和 WindSurf 等工具進行日常開發工作流程。這看起來不太華麗，但潛在影響可能更為深遠。這些開發者正在：
-
使用人工智慧進行程式碼補全和建議
-
運用人工智慧處理複雜的重構任務
-
產生測試和文件
-
將人工智慧當作解決問題的「結對程式設計夥伴」(pair programmer)
但問題是：儘管這兩種方法都可以極大地加速開發，但它們卻帶有一些不太明顯的隱藏成本。
「AI 加速」的隱藏成本
當你看到資深工程師使用像 Cursor 或 Copilot 這樣的 AI 工具時，整個過程看起來就像魔法一樣。他們能在幾分鐘內構建出完整的功能，甚至連測試和文件都一併完成。但仔細觀察，你會發現一個關鍵點：他們並不是完全接受 AI 提供的建議，而是在不斷地：
-
將生成的程式碼重構為更小、更專注的模組
-
補充 AI 漏掉的邊界情況處理
-
強化型別定義與介面設計
-
質疑架構設計的決策
-
加入全面的錯誤處理機制
換句話說，他們正在運用多年累積的工程經驗來修正和約束 AI 的輸出。AI 確實加速了他們的實現過程，但真正讓程式碼具備可維護性的，是他們的專業能力。
相較之下，初階工程師往往忽略了這些重要步驟。他們更容易直接接受 AI 的輸出，這就導致了我所稱的「紙牌屋程式碼」——表面看起來完整無缺，但在實際應用中卻經不起考驗，輕易崩塌。
知識悖論
我發現了一件非常反直覺的事情：AI 工具對於有經驗的開發者幫助更大，而非初學者。這似乎反過來——AI 難道不應該讓編程更普及化嗎？
事實上，AI 更像是你團隊中一位非常積極的初階工程師。他們能迅速撰寫程式，但需要持續的監督和修正。你對開發了解得越多，就越能有效地引導他們的工作。
這也形成了我所稱的「知識悖論」：
-
資深開發者利用 AI 加速他們已經熟悉的工作
-
初階開發者試圖利用 AI 學習該怎麼做
-
結果卻有著天壤之別
我見過資深工程師使用 AI 來：
-
快速原型化他們已經理解的概念
-
生成基礎實作並進一步優化
-
探索已知問題的替代方案
-
自動化重複性任務
但相對地，初階工程師往往會：
-
接受錯誤或過時的解決方案
-
忽略關鍵的安全性與效能考量
-
對 AI 生成的程式碼難以進行除錯
-
建出自己無法完全理解的脆弱系統
70% 問題：人工智慧的學習曲線悖論
最近有一則推文完美地捕捉了我在業界觀察到的現象：非工程師使用人工智慧進行程式開發時，會遇到一道令人沮喪的障礙。他們驚訝地發現自己可以很快地完成 70% 的工作，但那最後的 30% 卻變成了一場報酬遞減的掙扎。
這個「70% 問題」揭示了當前人工智慧輔助開發的關鍵本質。一開始的進展看起來簡直像魔法——你可以描述你想要的內容，而像 v0 或 Bolt 這樣的人工智慧工具就會產生一個看起來令人印象深刻的可運作原型。但接著現實就會隨之而來。
-
你嘗試修正一個小 bug
-
AI 提出看似合理的修改建議
-
這個修正卻破壞了其他功能
-
您請 AI 修復新的問題
-
這又造成更多問題
-
如此反覆循環
對非工程師來說，這個循環特別痛苦，因為他們缺乏理解根本問題的心智模型。當經驗豐富的開發者遇到問題時，他們可以基於多年的經驗推理潛在的原因和解決方案。沒有這樣的背景，您基本上就是在盲目地用打地鼠遊戲的方式處理一段不完全理解的程式碼。
學習悖論的深層面向
這裡存在一個更深層的問題：讓 AI 開發工具對非工程師來說看似容易的關鍵——它們代勞處理複雜性的能力——反而可能阻礙學習。當程式碼似乎憑空出現，而你又未能理解其中的基本原理時：
-
您無法培養除錯技能
-
會錯過學習基本程式設計模式
-
無法對架構決策進行邏輯推理
-
難以維護和演進程式碼
這造成了一種依賴模式，您只能不斷返回 AI 尋求修正，而非培養自身處理問題的專業能力。
知識差距
在使用 AI 開發工具的非工程師中，我看到最成功的是採取混合方法的人：
-
使用人工智慧進行快速原型開發
-
花時間理解生成程式碼的運作邏輯
-
在使用 AI 的同時學習基本程式設計概念
-
逐步建立知識基礎
-
將 AI 視為學習工具，而非僅是程式碼產生器
而這需要耐心與投入，這與許多人期望 AI 能帶來的方便性其實恰恰相反。
對未來的啟示
這個「70% 問題」表明目前的人工智慧程式開發工具最好被視為：
-
資深開發者的原型加速器
-
對理解開發深感興趣的人的學習輔助
-
快速驗證想法的最小可行產品 (MVP) 產生器
但它們尚未成為許多人期待的程式設計平民化解決方案。最後的 30% ——讓軟體達到正式環境水準、可維護和穩定的部分——仍然需要真正的工程知識。
好消息？這個差距很可能隨著工具的改進而縮小。但就目前而言，最務實的做法是利用 AI 來加速學習，而不是完全取代它。
真正實用的方法
在觀察了數十個團隊後，我歸納出以下幾個有效的做法：
1. 「AI 初稿」模式
-
讓 AI 生成基本實作
-
手動檢閱並重構以提高模組化
-
完善錯誤處理
-
編寫詳盡的測試
-
記錄關鍵決策
2. 「持續對話」模式
-
為每個不同的任務開啟新的 AI 對話
-
保持上下文聚焦且簡潔
-
頻繁地檢閱和提交變更
-
維持緊湊的回饋與修正節奏
3. 「信任但驗證」模式
-
使用 AI 進行初始程式碼生成
-
手動檢查所有關鍵路徑
-
自動化測試邊界情境
-
定期進行安全審核
展望未來：人工智慧的真正潛力？
儘管存在這些挑戰，我對人工智慧在軟體開發中的角色仍然持樂觀態度。關鍵在於了解它真正擅長的領域：
-
加速已知領域 人工智慧擅長協助我們實現已經理解的模式。就像有一個無限耐心、打字速度極快的結對程式設計夥伴。
-
探索可能性 人工智慧非常適合快速原型化想法並探索不同方法。就像擁有一個可以迅速測試概念的沙盒。
-
自動化常規任務 人工智慧大幅減少在樣板和常規程式碼任務上花費的時間，讓我們可以專注於更有趣的問題。
這對你意味著什麼？
如果您剛開始接觸人工智慧輔助開發，以下是我的建議：
-
從小處著手
-
先用人工智慧處理獨立且定義明確的任務
-
逐行檢視生成的程式碼
-
逐步擴大到更大的功能開發
-
-
保持模組化
-
將所有內容拆分成小型、聚焦的檔案
-
維持元件之間的清晰介面
-
記錄模組邊界
-
-
信任您的經驗
-
使用 AI 加速，而非取代自身的判斷
-
對看起來不對勁的生成程式碼保持質疑
-
堅持你的工程標準
-
代理軟體工程 (Agentic Software Engineering) 的興起
隨著我們邁入 2025 年，AI 輔助開發的格局正發生極大變化。儘管目前的工具已經改變了我們原型開發和迭代的方式，但我相信我們正站在一個更加重大的轉型邊緣：代理軟體工程的興起。
我所說的「代理」是什麼意思？這些系統不再只是單純回應提示，而是能夠以日益增長的自主性來規劃、執行和迭代解決方案。
如果您對代理（agents）感興趣，並想了解更多關於 Cursor、Cline、v0、Bolt 的看法，可以參考我近期在 JSNation 的演講。
我們已經看到這種演進的早期跡象：
從回應者到協作者
目前的工具主要等待我們的指令。但看看像是 Anthropic 在 Claude 的電腦使用功能，或 Cline 能自動啟動瀏覽器和執行測試的新功能。這些不僅僅是誇大的自動完成——它們實際上能理解任務並主動解決問題。
這些代理不再只是建議修正，它們能夠：
-
主動識別潛在問題
-
啟動並執行測試套件
-
檢查 UI 元素並擷取螢幕截圖
-
提出並實作修正
-
驗證解決方案是否有效（這可能是個重大突破）
多模態的未來
下一代工具將不僅僅是處理程式碼，而是能夠無縫結合：
-
視覺理解：UI 截圖、設計模型、流程圖
-
語言互動：自然語言對話
-
環境互通：瀏覽器、終端機、API
這種多模態能力意味著，工具能以人類的方式全面理解並處理軟體，而不僅限於程式碼層面。
自主但受引導
從使用這些工具的經驗中，我得到的關鍵啟示是，未來並不是 AI 取代開發者，而是 AI 成為一個愈加強大的協作者，能夠在保持人類引導與專業知識的前提下，主動執行任務。
到 2025 年，有效的團隊將會是能做到以下幾點的團隊：
-
為 AI 代理設定明確的界限與指導方針
-
建立穩固的架構模式，讓 AI 能在其中運作
-
創造人類與 AI 能力之間的有效回饋循環
-
在運用 AI 自主性時，仍維持人類的監督
英語優先的開發環境
正如 Andrej Karpathy 所說：
「英語正成為最新潮的程式語言。」
這代表我們與開發工具互動的方式正發生根本性的改變。能以自然語言清晰思考並準確溝通的能力，正變得和傳統開發技能一樣重要。
這種代理開發（agentic development）轉變，要求我們提升以下技能：
-
更強的系統設計與架構思維
-
更佳的需求規範與溝通能力
-
更注重品質保證與驗證
-
強化人類與 AI 能力間的協作
軟體工藝的回歸？
雖然 AI 讓快速開發軟體變得前所未有的簡單，但我們可能正在失去一些關鍵的東西——打磨真正精緻、優秀使用者體驗的技藝。
演示品質的陷阱
一種模式越來越常見：團隊利用 AI 快速開發出令人驚豔的演示作品。理想路徑運行順暢無比，讓投資人與社交媒體驚嘆不已。但當真實用戶開始操作時，一切卻分崩離析。
我親眼目睹過以下情況：
-
錯誤訊息讓普通用戶完全無法理解
-
邊界情況導致應用崩潰
-
混亂的 UI 狀態未經妥善清理
-
完全忽視無障礙設計
-
在低階設備上的效能問題
這些問題不僅僅是次要的「P2 Bug」，它們決定了軟體是讓人將就接受，還是讓人真正愛不釋手。
被遺忘的打磨技藝
打造能順暢使用的軟體——用戶無需求助客服即可順利使用——需要一種截然不同的思維方式：
-
對錯誤訊息的極致關注
-
在慢速網路環境下測試
-
優雅地處理每一種邊界情況
-
確保功能易於發現
-
與真實用戶，尤其是非技術用戶進行測試
這種對細節的關注（也許）無法由 AI 生成，而是來自同理心、經驗，與對工藝的深切關注。
個人軟體的復興
我相信，我們即將迎來個人軟體開發的復興。在 AI 生成的 MVP 產品充斥市場的情況下，能脫穎而出的產品將來自於那些開發者，他們：
-
以自己的技藝為榮
-
在意每個細節
-
專注於完整的用戶體驗
-
考慮到所有邊界情況
-
打造真正順暢的使用體驗
諷刺的是，AI 工具可能正是促成這場復興的關鍵。通過處理例行的編碼任務，AI 讓開發者能將精力專注於最重要的部分——創造真正服務並取悅用戶的軟體。
核心觀點
AI 並未顯著提升軟體品質，因為軟體品質的限制（或許）從來不是寫 code 速度的問題。軟體開發中真正困難的部分——理解需求、設計可維護的系統、處理邊界情況、確保安全性與效能——仍然需要人類的判斷。
AI 能做到的是讓我們更快地迭代與實驗，透過更迅速的探索找到更好的解決方案。但這只有在我們保持工程紀律，將 AI 當作工具而非取代良好軟體開發實踐的情況下才能實現。記住：目標不是更快地寫更多程式碼，而是打造更好的軟體。明智地運用 AI，確實能幫助我們達成這個目標，但「更好」的定義以及如何實現它，仍然由我們決定。