70%問題：AI學習曲線的悖論
最近有一則推文完美捕捉到我在實務上觀察到的現象：非工程師在使用AI編程時會遇到一道令人沮喪的障礙。他們能夠驚人地快速完成70%的進度，但最後30%卻變成了一場投入報酬遞減的練習。
這個「70%問題」揭示了AI輔助開發現況的一個關鍵現象。一開始的進展感覺像魔法一般 － 你只需描述你想要什麼，像v0或Bolt這樣的AI工具就能生成一個看起來令人印象深刻的可用原型。但接著現實就浮現了。
倒退兩步的模式
接下來通常會發生一個可預見的模式：
- 你試圖修復一個小錯誤
- AI提出一個看似合理的修改建議
- 這個修復卻導致其他地方出問題
- 你請AI修復新出現的問題
- 這又產生了兩個新問題
- 如此循環往復
學習悖論繼續
這裡有個更深層的問題：讓非工程師也能使用AI編程工具的特性 － 即代為處理複雜性的能力 － 實際上可能會阻礙學習。當程式碼只是「憑空出現」，而你不理解其背後的原理時：
- 你無法培養除錯技能
- 你錯過了學習基礎模式的機會
- 你無法對架構決策進行推理
- 你難以維護和改進程式碼
這種情況造成了一種依賴性，你需要不斷地回去請教AI來修復問題，而不是培養自己解決問題的專業能力。
知識落差
我看過最成功的非工程師在使用AI編程工具時都採用混合方式：
- 使用AI進行快速原型設計
- 花時間理解生成的程式碼如何運作
- 在使用AI的同時學習基本的程式設計概念
- 逐步建立知識基礎
- 將AI作為學習工具，而不僅僅是程式碼產生器
但這需要耐心和投入 － 恰恰與許多人最初使用AI工具時所期望達到的目標相反。
對未來的影響
這個「70%問題」顯示目前的AI編程工具最適合被視為：
- 資深開發者的原型開發加速器
- 致力於理解開發的學習輔助工具
- 快速驗證想法的最小可行產品生成器
但它們還不是人們所期待的編程民主化解決方案。最後的30% － 也就是使軟體達到可上線、可維護和穩健性的部分 － 仍然需要真正的工程知識。
好消息是，隨著工具的改進，這個差距可能會逐漸縮小。但目前而言，最務實的做法是將AI用於加速學習，而不是完全取代學習。
實用模式：什麼方法真正有效
在觀察了數十個團隊後，以下是我發現持續有效的方法：
1. 「AI初稿」模式
- 讓AI生成基本實作
- 手動檢視並重構以達到模組化
- 加入完整的錯誤處理
- 撰寫詳盡的測試
- 記錄關鍵決策
2. 「持續對話」模式
- 為每個不同任務開始新的AI對話
- 保持重點明確且精簡的上下文
- 經常性檢視並提交更改
- 維持緊密的回饋循環
3. 「信任但驗證」模式
- 使用AI進行初始程式碼生成
- 手動審查所有關鍵路徑
- 自動化測試邊界情況
- 定期安全性稽核