AI 編碼的天花板：為何「驗證迴圈」比生成能力更重要？
AI 寫 code 的能力越來越強，但為何我們常陷入「修好 A、弄壞 B」的無限迴圈？本文從實務角度剖析，指出 AI 編碼的真正瓶頸不在生成，而在於缺乏自主的驗證與修正能力。這不只是工具的限制，更重新定義了我們對「編碼能力」的理解。
近來 AI 編碼工具的能力飛速成長，但許多開發者都遇過一個共同的困境：AI 助手看似修好了一個 bug，卻在別處製造了新問題，使我們陷入徒勞的修正迴圈。我認為，這揭示了當前 AI 編碼的真正天花板——瓶頸並非生成程式碼的能力，而是缺乏一套自主的「驗證迴圈」（Verification Loop）。能否建立假設、執行驗證、根據反饋修正，才是決定一個系統能否真正解決複雜問題的關鍵。這也迫使我們重新思考，「編碼能力」的本質究竟是什麼。
為何 AI 總在看似簡單的修復任務中鬼打牆？
這個場景想必不陌生：你將一段有問題的程式碼丟給 AI 編碼助手，明確指示「請修復這個 bug」。幾秒或幾分鐘後，它回覆「已修正」並提供新的程式碼。你滿懷期待地執行，卻發現問題依舊，甚至還引發了其他錯誤。你只好再次提供新的錯誤訊息，請它再試一次。AI 再次分析、修改，然後再次失敗。這個過程不斷重複，就像一個沒有盡頭的迴圈。
問題的核心在於，AI 在這個流程中缺少了最關鍵的一步：驗證。它產出了一段程式碼，但它「不知道」這段程式碼是否真的解決了問題。它像一個只能紙上談兵的建築師，畫得出精美的藍圖，卻無法親自到工地確認鋼筋是否綁對、水泥磅數是否足夠。
為何 AI 總在同一個地方打轉？
人類工程師與 AI 助手在工作流程上有著根本性的差異。一個有經驗的開發者，其工作模式是一個緊密的反饋閉環。這個迴圈不僅僅是寫 code，更重要的是後續一連串的驗證行為。
- 人類工程師的迴圈：提出假設 -> 修改程式碼 -> 執行（編譯、運行）-> 跑單元測試或整合測試 -> 查看 log 輸出 -> 在介面上手動操作確認 -> 根據結果，形成新的假設 -> 重複。
- 典型 AI 助手的流程：接收指令 -> 分析上下文 -> 生成程式碼 -> 結束。
人類工程師的每一步修改，都伴隨著立即的驗證與反饋。這個在幾秒或幾分鐘內就能完成的微小迴圈，是確保程式碼收斂至正確狀態的基礎。反觀 AI，如果沒有被明確指示，它只會停留在「生成」這一步。它缺乏一個內建的機制去主動執行自己寫下的程式碼，更不用說去解讀測試報告或觀察執行結果了。這導致它只能根據我們提供的文字描述來「猜測」問題是否被解決，自然容易陷入緣木求魚的困境。
我們對 AI 的期待，不該是它一次就寫出完美的程式碼，而是它能否建立一個系統，讓自己能提出假說、測試假說，並根據測試結果迭代修正。這才是真正意義上的自主解決問題。
編碼能力的本質，其實是驗證能力嗎？
這個觀察，讓我們不得不重新審視「編碼能力」的定義。長期以來，我們或許將編碼能力等同於撰寫程式碼語法的流暢度與演算法的知識。但實際上，一個資深工程師的價值，更多體現在他建立與執行驗證迴圈的效率與嚴謹性上。這正是敏捷開發中 測試驅動開發（TDD） 等方法論的核心精神：先寫測試（定義成功的標準），再寫能通過測試的程式碼。
當前的 AI 發展也正朝著這個方向努力。近期備受矚目的自主 AI 代理（Autonomous Agent），其核心突破就在於試圖賦予 AI 執行與驗證的能力。例如，在 SWE-bench 這類評估 AI 解決真實世界軟體工程問題的基準測試中，表現優異的系統（如 Devin 聲稱達到的 13.86% 未經輔助解決率）無一不是整合了 shell、編輯器、測試框架等工具，讓 AI 能在一個模擬的開發環境中自主操作。它們的目標不再只是生成程式碼片段，而是完整地執行「分析問題、編寫程式、運行測試、除錯修正」的整個迴圈。
此外，一些前沿研究如 Self-Refine 框架，也明確提出讓大型語言模型（LLM）自我反思與迭代改進其產出，本質上就是在模擬這個驗證與修正的過程。這些發展都指向同一個結論：單純的程式碼生成只是起點，真正的智慧體現在後續的驗證與收斂能力。
如何打造有效的 AI 協作迴圈？
在 AI 能夠完全自主驗證之前，我們作為使用者，必須扮演「驗證迴圈的外部驅動者」。與其期待 AI 一次到位，不如將它視為一個需要明確指令才能執行驗證的初級開發者。具體來說，我們可以這麼做：
- 賦予工具權限：在安全的環境下，讓 AI 代理有權限使用終端機、讀寫檔案、執行測試指令。像 GitHub Copilot Workspace 或 Cursor 這類整合了終端機的 AI 原生編輯器，就是朝這個方向發展的工具。
- 將驗證步驟指令化：在你的 prompt 中，不僅要描述問題，更要明確給出驗證的步驟。例如：「請修改 `main.py` 來解決這個 bug。修改完成後，請執行 `pytest tests/` 指令，並將完整的輸出結果告訴我。」
- 從最小可驗證單元開始：將複雜的任務拆解成數個可以獨立驗證的小步驟。每完成一步，就要求 AI 進行驗證，確保在正確的基礎上繼續前進。
雖然這樣做會讓 prompt 變得更長、更繁瑣，但這是在現階段技術限制下，最能有效利用 AI 編碼能力的方法。我們的工作，正從一個純粹的「程式碼撰寫者」，轉變為一個「AI 協作系統的設計者與驗證者」。未來，AI 編碼能力的競賽，比的將不是誰的生成模型更強大，而是誰能打造出更高效、更可靠的自主驗證與修正迴圈。
延伸閱讀
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (arXiv)
- Introducing Devin, the first AI software engineer (Cognition)
- Self-Refine: Iterative Refinement with Self-Feedback (arXiv)
- Test-Driven Development (Martin Fowler)
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。