為什麼AI編程能快速落地?
2024 年預期的 AI 應用爆發並沒有到來,但是編程領域卻是個特例。AI 編程工具正在引領大模型落地的浪潮,展現出明顯的產品市場契合度(Product Market Fit,PMF)。
從市場表現看,編程領域的 AI 發展最為迅猛,一批估值增長最快的 AI 初創公司,比如 Cursor、Windsurf、Devin 等主營業務都是構建編程智能體。在 2024 年 12 月,Cursor 的開發商 Anysphere 宣佈完成了超過 1 億美元的 B 輪融資,投後估值高達 26 億美元。孵化自北京大學軟件工程研究所的矽心科技,專注於企業私有大模型部署,也於今年 1 月宣佈成功完成 B 輪融資。

在實際應用方面,AI 編程的滲透率已經達到了一個驚人的水平。據Google透露,超過 25% 的新代碼是由人工智能生成。Github 表示他們目前新寫的代碼中由 30% 都是在 Github Copilot 輔助下完成的。除了大型科技公司,個人開發者也借助 AI 工具也實現了開發效率的顯著提升,編程能力得到全面增強。彷彿一夜之間,所有程序員都用 AI 武裝上了自己。
與此同時,模型性能也在持續突破,在軟件風格基準測試 SWE-bench verified 中,GPT-o3 模型準確率達到 71.7%,相比 GPT-o1 模型提升超過 20%。在 CodeForces 競賽中,GPT-o3 模型更是達到 2727 ELO 分,遠超 O1 的 1891 分,展現出強勁的技術進步形勢。似乎模型的進化仍在狂飆。
那麼,為什麼是編程領域率先實現了 AI 的有效落地?
AI 跑通了 PMF 是一個結果,而非原因。其背後的根本原因是編程領域獨特的「可信驗證」機制。
而要理清這一問題,我們不妨先從 AI 編程的發展現狀入手。

AI 編程工具的發展歷程
AI 編程工具的發展呈現出明顯的自動化演進路徑,目前按照自動化程度大致可分為三類:
首先是以早期的 Github Copilot 為代表的代碼補全工具。這類工具主要提供實時代碼提示和自動補全功能,並不能主動編寫代碼。自動化程度相對較低。隨著技術發展,這類工具正在向更高級的智能編程助手演進,逐步融入更多自動化特性。
第二類是以 Cursor、MarsCode 為代表的半自動編程工具,標誌著 AI 編程邁入了更高級的發展階段。這類產品不僅提供代碼補全功能,還創新性地引入了「Apply(應用)」機制,讓 AI 生成的代碼可以一鍵直接集成到目標文件中。用戶不需要再把代碼複製過去,自己進行調整修改。雖然自動化程度有所提升,但仍需要開發者的持續參與和判斷,體現了「人機協作」的特點。
第三類則是以 Devin 為代表的全自動編程工具。這類工具自動化程度最高,Devin 被稱為全球首個 AI 程序員,可以自主調試部署。構建部署應用、自主調試等多項能力。支持使用 AI 規劃進行任務分解,並自動部署代碼。用戶只需下達任務指令,靜待結果即可,就像與真實程序員協作一樣。
AI 編程工具的發展歷程清晰展現了一條從輔助到自主的演進路徑。第一代代碼補全工具專注於提升專業程序員的編碼效率,通過智能補全實現段落級別的開發加速。隨後,以 Cursor 為代表的半自動工具將 AI 能力進一步擴展,通過代碼直接應用等功能,在保持人工把控的同時顯著提升了開發效率。而 Devin 的出現則開創了全自動編程的新範式,實現了從需求理解到部署的端到端自主開發。
這一演進過程本質上反映了 AI 編程範式的重要轉變:從「實時交互」走向「批量處理」。這不僅降低了用戶參與的頻率,更重要的是大幅降低了編程門檻,使得 AI 編程工具的受眾群體得到顯著擴展。

代碼生成其實更難?
「代碼的關鍵詞少,規則固定,所以更容易生成。」這是一種常見的評論。乍看似乎很有道理,相比自然語言浩如煙海的詞彙量,編程語言的關鍵字確實少得多,采樣空間相比自然語言小太多了。
但這種「詞少就容易」的邏輯其實經不起推敲。如果按這個邏輯,數學問題應該是最容易的才對——數學符號更少,規則更嚴格。但現實恰好相反,大模型在數學領域的表現並不理想。
這種誤解的根源在於混淆了「生成」和「應用」兩個截然不同的階段。在生成階段,編程語言的有限詞彙讓模型的選擇空間大大縮小。但在實際應用階段,代碼的難度遠超自然語言。
在對話時,用戶對大模型的容忍度很高。它可以犯語法錯誤,可以前後矛盾,可以邏輯混亂,我們依然能從中提取有價值的信息,甚至我們自己都發現不了他有語法錯誤。但代碼生成完全是另一個維度的挑戰——它就像數學題,代碼要麼能跑通, 要麼跑不通,不存在「基本正確」或「大致可用」的中間狀態。每一個分號、每一處縮進、每一個變量名,都必須精確無誤。這種對精確性的嚴格要求,也註定了代碼任務的難度其實要更高的。

可信驗證機制
AI 編程成功的核心原因,在於它具有一種可信驗證機制。
什麼是可信驗證?簡單而言,就是一種能夠快速、客觀地判斷 AI 輸出結果的可用性的驗證模式,具備三個關鍵特徵:
1. 客觀性:驗證結果不依賴人或者 AI 模型的主觀判斷;
2. 即時性:能夠立刻得到驗證結果;
3. 確定性:驗證結果是非黑即白的;
這種可信驗證機制對 AI 編程領域產生了兩個方向的影響。使其達到了「能用且好用」的狀態。
從應用端來說,編程領域的可信驗證機制,為 AI 應用創造了一個近乎完美的用戶體驗閉環。
代碼編寫後,需要使用編譯器將其翻譯成機器可執行的程序。同一種語言會使用統一的編譯器,會基於嚴格設定的語法規則,這有效保證了客觀性。
編譯後的結果也是二元的,只有「能運行」和「不能運行」兩種狀態,不存在模棱兩可的情況。讓用戶不需要主觀判斷,可以完全依據客觀結果來做決策。此外,編譯過程通常時間較短,可以讓用戶及時知道 AI 生成的代碼是否可用。
這種依賴編譯器的可信驗證,幾乎不需要用戶的專業知識,只要他能點「運行」按鈕就夠了。這極大擴展了 AI 編程工具的受眾群體。這也解釋了為什麼現在很多零知識用戶都在嘗試使用 AI 來寫程序。
所謂「零知識用戶」,指的是那些不懂編程但想開發應用的人。這類用戶對可信驗證的需求最為迫切,因為他們無法自行處理異常情況。這個概念同樣可以推廣到 AI 的其他應用領域。
在所有 AI 應用場景中,很少有哪個領域能像編程這樣擁有如此理想的驗證機制。這也解釋了為什麼 AI 編程工具能夠率先實現規模化應用——它為用戶提供了一個可靠、高效、低門檻的使用環境。
再從模型端來說,為什麼大模型在編程領域的進步如此顯著?答案可能會讓人意外:在當前訓練數據普遍枯竭的背景下,編程或許是大模型為數不多可以持續進步的領域。原因還是在於可信驗證。
讓我們先看看大模型訓練的困境。業界頻繁強調自家模型在代碼和數學方面的突破,卻很少宣稱「AI 說話更像人了」。這背後是一個公開的秘密:自然語言訓練數據正面臨枯竭危機。在大模型訓練中,數據質量與模型架構同等重要。數據的枯竭,就意味著模型能力提升也在放緩。
面對這個困境,大模型廠商通常採取兩種應對策略:一是人工生產新數據,通過網絡爬取或人工編寫;二是使用更高級的模型合成數據。但這兩種方案都存在明顯缺陷:人工生產成本高昂,而合成數據則可能導致模型崩潰。大量研究表明,質量差的合成數據會讓模型輸出逐漸偏離人類表達方式,加重模型幻覺問題。

業界主要依賴兩種方式來判斷合成數據質量:用更強大的模型篩選,或依靠人工來主觀判斷。這不僅成本高昂,還難以規模化,且可靠性無法保證。一旦涉及到主觀意識,它就很難設置統一標準。會導致數據質量參差不齊。
可信驗證機制有效保證了代碼合成數據質量的下限。
人類和 AI 寫的代碼都只有正確性這一客觀評判標準。只要代碼能通過編譯和運行,兩者代碼就可以看作等價的。無非是誰寫的質量更高的問題。但這保證了合成數據具備基本的訓練價值。這等價於有成千上萬個不知疲倦的初級程序員在持續產出數據。
可信驗證機制讓合成數據形成良性循環:模型生成代碼,驗證機制篩選,有效代碼反饋回訓練集。有趣的是,通過這種方式生成的代碼,質量要高於 GitHub 上很多代碼。這種低成本的質量保證機制,確保了模型在代碼領域能持續提升。
應用端和模型端的雙向價值完美解答了 AI 商業化的兩大難題:用戶敢不敢用,模型怎麼持續進步。特別是在企業級市場,可靠性一直是最大的痛點。而可信驗證提供了一個完整的解決方案:輸出結果可控可驗證,配合自動化測試框架和現有的代碼審查機制,極大降低了應用風險。此外,對零知識用戶的友好讓 AI 編程迅速破圈。如此也就不難理解為什麼 AI 編程普及率那麼高了。

AI 編程存在的問題
儘管 AI 編程擁有獨特的可信驗證機制,但它依然存在很多問題。
第一,AI 生成的代碼生成質量有待提高。可信驗證機制確實為代碼質量提供了一個基本保障——能運行的代碼至少是「可用的」。但「可用」並不等於「好用」。當前 AI 生成的代碼仍然面臨著多個層面的質量問題:比如代碼風格不一致、代碼性能不穩定、在面對複雜工程時無法處理複雜的依賴關係。
大語言模型在代碼生成中依然存在幻覺問題和不穩定性,這可能導致代碼風格和命名規範的不一致,甚至出現歧義名稱。雖然可以通過提示詞進行一定程度的約束,但效果有限。這種代碼風格的問題表面上看對程序運行影響不大,但到後期人類的閱讀難度增大、甚至連 AI 都會被自己的代碼搞混。嚴重時可能導致程序難以繼續開發。
可信驗證可以保證程序的最低運行標準,但現實中的軟件往往需要根據具體場景進行優化。當前的大語言模型在場景評估和針對性優化方面仍顯不足。這一局限性在複雜工程中尤為明顯:當對軟件進行優化時軟件架構的權衡和優化往往需要基於實際環境作出決策,才能找到它的問題。而 AI 目前並不具備這樣的分析能力。
這也解釋了為什麼零基礎用戶通常只能借助 AI 完成一些基礎程序開發,比如快速搭建簡單的網站或小程序。但當需要擴展功能或深化開發時,往往會遇到瓶頸。當用戶缺乏對軟件結構的深入理解時,而僅依賴 AI 目前還無法有效構建和優化複雜的軟件架構。雖然 AI 能夠快速實現一個框架,但對於核心功能的開發往往需要大量重構和優化工作。
第二,AI 編程對語言支持並不平衡。對於較為靈活的編程語言,容錯率較高的語言支持效果更好(如 Python)這裏主要有兩點原因:
首先是訓練數據量的差異。Python 作為 AI 時代最火的編程語言,開源社區為其提供了海量的高質量訓練數據。而其他語言的數據量相比較少。

其次是語言特性的影響。Python 的語法相對靈活,容錯性更高,這使得 AI 更容易生成可用的代碼。相比之下,Java 等強類型語言的語法約束更嚴格,對代碼生成的要求也更高。所以成功率也會低一些。
第三個問題,雖然 AI 編程工具都在追求更高程度的自動化,但「批處理」式的開發模式未必是最優解。這種模式雖然效率看似提高了,卻削弱了用戶對代碼變更的實時把控,反而可能增加認知負擔。Devin 在這個問題上表現的淋漓盡致。

以 Devin 為例,這個被譽為全球首個 AI 程序員,號稱具備全棧開發、自學新技術、構建部署應用、自主調試等多項能力。初次體驗時,這種全自動的開發體驗確實令人驚豔。就像擁有了一個 AI 實習生,可以獨立完成任務,讓我能專注於其他工作。
但實際體驗下來,相比 Cursor 等半自動 AI 編程工具,存在兩個致命問題:一是反饋週期過長,用戶需要等待較長時間才能知道結果是否正確。如果指令有誤或思路錯誤,前期的等待就成了純粹的時間浪費,沉沒成本顯著提高。二是調試成本的劇增。AI 生成的代碼量越大,理解成本就越高,調試時常常難以判斷到底是代碼生成的問題,還是操作出了偏差。這對零知識用戶來說尤其困難。
在軟件開發生命週期中,缺陷修復的成本與發現時間呈指數級關係。越晚發現問題,修復成本就越高。軟件開發從需求分析、系統設計、代碼實現到測試驗證、運行維護,是一個環環相扣的過程。當 AI 接管的越多,就導致發現問題的環節推後。而此時的修復不僅涉及單個函數,還可能引發連鎖反應,甚至出現架構設計層面的缺陷,需要整體上重新設計。開發人員在此時往往需要深入理解 AI 生成的代碼,才能進行有效修復。

筆者專門做了個實驗:完全以零知識用戶的身份,讓 Devin 寫代碼,再用 Claude 來 debug。實際體驗下來,Devin 寫了 20 多分鐘的程序,Claude 修了一個小時,核心功能依然沒能跑通。只能選擇重做。
與自動駕駛不同,開車時你可以隨時接管,因為車輛的當前狀態是顯而易見的。但在編程中,如果 AI 走錯了方向,之前的工作就全部作廢了。那幾十分鐘的等待,就真的變成了純粹的時間浪費。得到的是你和 AI 都處理不了的一大堆代碼。

AI 編程的未來發展:更高級的可信驗證
目前應用端的可信驗證還很初級,主要是看代碼「能不能跑」,考慮的是終端輸出結果。但隨著技術發展,會出現更高級的可信驗證方法,考慮更多的因素。
例如現代 IDE 已經能夠自動檢測性能隱患和安全漏洞。這些自動化的質量評估機制同樣可以傳遞給大模型——它們同樣具備客觀性和即時性,只是驗證維度更加豐富。
將 DevOps 實踐等現代化的軟件工程實踐方案引入 AI 輔助開發流程,建立更完善的代碼質量保障體系,確保 AI 生成的代碼不僅能夠運行,更能夠滿足現代軟件工程的高標準要求。及時測試並反饋。自動化測試框架能夠生成測試用例、檢查邊界條件、驗證業務邏輯,包括對代碼性能進行檢測,提供了另一層次的可信驗證。
這些客觀的質量指標同樣可以反饋到模型。隨著驗證機制的不斷完善,AI 編程將會從「基本可用」進化到「高質量」,而像 Devin 這樣的全自動編程工具也將迎來更廣闊的應用空間。因為它代表了 AI 編程的未來方向:真正實現開發者的解放,讓人類專注於更具創造性的工作。儘管我們不知道它什麼時候能被實現。
但是筆者認為這種 AI 編程可能依然不適合零知識用戶,它的未來或許就是極大的增加程序員的生產力。對於零知識用戶,或許零代碼平台(比如 Dify)更可靠。因為它不需要擔心「能不能跑起來」的問題。
AI 編程領域的成功經驗給我們一個重要啟示:任何領域要想成功應用 AI,都必須建立起有效的可信驗證機制。
雖然不是每個領域都能像編程那樣擁有編譯器這種精確的驗證工具,但我們可以借鑒這一思路,建立適合各自領域特點的驗證體系。這個驗證機制無需一開始就做到完美,但至少要能給出基本的可用性判斷。模型的上限很重要,但是對於大模型的應用,模型的下限同樣重要。可信驗證不僅能降低 AI 應用的使用門檻,還能為模型優化提供可靠的反饋數據。AI 領域最理想的場景,應該同時具備「用戶友好」和「模型可進化」這兩個特質。
參考文獻
1.https://www.nature.com/articles/s41586-024-07566-y
2.https://github.blog/news-insights/octoverse/octoverse-2024/
運營/排版:何晨龍