代碼生成不是語言問題，是流程問題
代碼生成的瓶頸不在提示詞，在於能否利用測試反饋建立自動化改進迴圈。
AlphaCodium 的觀察
我看 AlphaCodium 這篇論文時，注意到一個容易被忽視的轉變：它不是在優化提示詞怎麼寫，而是在重新設計 LLM 生成代碼的整個工作流。這個區別很重要。
傳統的代碼生成方法把問題定義為「怎麼讓模型理解需求」。所以大家在調提示詞、加上下文、優化 few-shot 例子。但 AlphaCodium 問的是另一個問題：如果我給模型一個完整的反饋迴圈，讓它能看到自己的代碼執行結果，會發生什麼？
答案是效能有明顯提升。但更重要的是，提升的方式跟自然語言任務完全不同。
為什麼代碼不能用語言優化的方式
代碼有一個自然語言沒有的特性：可驗證性。你寫的句子再優美，也沒人能客觀判斷是否「正確」。但代碼不一樣——它能執行，能測試，能得到明確的 pass 或 fail。
AlphaCodium 的核心就是利用這個特性。它不是一次生成就完事，而是：
- 生成初版代碼
- 對著測試用例跑一遍
- 看哪些失敗了
- 根據失敗反饋重新生成
- 重複
這個流程在語言任務上沒有對應物。你沒辦法對翻譯或摘要做同樣的自動化反饋迴圈。所以用在 ChatGPT 上有效的提示詞優化技巧，在代碼生成上可能根本不是瓶頸。
測試驅動生成的現實
論文裡提到的多階段測試流程，我的理解是這樣運作的：
模型不是被動地等待「更好的提示詞」，而是主動地跟測試結果對話。每一次失敗都是一個信號——不是模型「沒理解」，而是代碼在某個具體的點上出了問題。這個信息密度遠高於再寫一遍自然語言提示詞。
實際上，這讓我想起傳統軟體開發的一個教訓：最有效的除錯方式不是看著代碼想，而是讓它跑起來看。AlphaCodium 本質上就是在把這個原則應用到 LLM 生成的過程。
應用上的限制
但這個方法有前提：你需要有測試用例。而且不能太複雜——複雜到模型無法在有限的迭代內修正。
對於演算法題、LeetCode 那種題目，這個方法很有效。對於「寫一個完整的微服務」這種開放式任務，測試本身就難以定義，流程的優勢就沒那麼明顯。
另一個現實是成本。每一次測試執行都要消耗資源。如果你在用 API 調用計費的模型，這個流程會變得昂貴。所以 AlphaCodium 的優勢可能主要在本地推理或有充足預算的場景。
我的看法
這篇論文重要的不是因為它達到了什麼新的準確率，而是因為它改變了問題的框架。它說：與其把代碼生成當作「語言理解問題」來優化，不如當作「反饋迴圈問題」。
這意味著如果你要建代碼生成系統，應該投資的是測試框架、執行環境、反饋解析——而不是更複雜的提示工程。
我後來決定換一個問題：不管 LLM 的能力怎麼變，我能不能建立一個流程，讓模型自己去發現和修正錯誤？這比依賴更好的提示詞更有長期價值。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。