為什麼只有AI編程成功落地?

原本計劃寫一篇2024年AI領域的年度總結,但鴿了。現在決定將內容拆分成系利雲章。開局先放王炸,聊聊為什麼大模型落地喊得火熱,但是實際落地的場景只有AI編程。

AI編程無疑是當下大模型落地最成功的一個領域。從Github的Copilot,到Cursor,再到第一個AI程序員Devin。好多人都在說:AI編程找到了PMF(Product Market Fit,產品市場契合)

但為什麼是它?

有人說「因為是真實需求」。難道AI在其他領域就是偽需求嗎?

有人說「因為代碼比自然語言更容易生成」。真的是這樣嗎?

還有人說「其他領域的模型能力還不夠」。但為什麼編程夠呢?

這些解釋都過於表面,今天就從我的角度來解析為什麼AI編程能成功落地,以及它未來的發展。

先從一個問題開始。

一、代碼和自然語言,到底哪個更難生成

「代碼的關鍵詞少,規則固定,所以更容易生成。」這是解釋AI編程為什麼好用的常見說法。

聽起來挺有道理的?代碼就那些關鍵詞,模型只要從有限的詞裡面挑就行了,采樣空間相比自然語言小太多了。

但是什麼時候「詞少=容易」了?如果真的是這樣的話,數學問題的描述足夠精簡,符號也少。那大模型做數學問題應該更強吧。

顯然不是這樣。

大模型到現在連JSON都弄不明白。JSON是一種編程領域常用的數據交互格式,在面對較為複雜的JSON時,大模型經常會出現括號對不上、層級關係錯亂的問題。

這個「代碼更容易生成」的論點,其實混淆了「生成」和「應用」兩個階段。

在自然語言生成中,我們對大模型的容忍度很高。它可以犯語法錯誤,可以前後矛盾,可以邏輯混亂,我們依然能從中提取有價值的信息。容錯性非常高。

但代碼生成完全是另一個維度的挑戰。就像做數學題,代碼能跑就是能跑,跑不通就是報錯。它不存在「基本正確「或「大致可用「的中間狀態。每一個分號、每一處縮進、每一個變量名都必須精確無誤。所以代碼生成其實是更難的,因為對代碼的可用性要求是遠高於文本的。

二、核心:可信驗證

代碼生成難度更高,為什麼它應用得最好呢?那些難度低的領域為什麼反而應用效果差呢?真正原因其實是編程具有一種可信驗證機制。

所謂可信驗證,簡單地說,就是一種能夠快速、客觀地判斷AI輸出結果的可用性的驗證模式。

1. 客觀性:驗證結果不依賴人或者AI模型的主觀判斷;

2. 即時性:能夠立刻得到驗證結果;

3. 確定性:對就是對,錯就是錯。

接下來我將論述可信驗證是怎樣讓AI編程成功的。

1. 應用端的應用:快速而準確的驗證

為什麼說編程領域有著完美的可信驗證?這讓我想到網上流傳的一句話:

戀人會背叛你,朋友會欺騙你,但數學不會,因為數學不會就是不會。

答案就藏在代碼的本質特性中:程序設計就像數學一樣,是一個非黑即白的世界——能跑就是能跑,跑不了就是跑不了。 這種確定性來自一個關鍵角色:編譯器。它負責將代碼編譯成可執行文件,這個過程是嚴格符合語法規定的。

編譯器將代碼編譯成可執行程序編譯器將代碼編譯成可執行程序

在這個過程中,編譯器扮演著一個獨特的角色:它是第三方的、非AI的、完全可靠的驗證機制。它不會被情緒影響,也不會擔心被人類誘導,不會有主觀偏見,只會忠實地執行語法規則。符合規則就可以編譯,不符合就是報錯。

這種嚴格的驗證機制成就了AI編程的應用。在AI嘗試落地的所有領域中,幾乎沒有哪個領域能像編程這樣擁有如此客觀、即時、確定的驗證標準。這種驗證機制對使用者的要求極低——不需要你懂編程原理,不需要你精通算法,只要能運行代碼,就能知道大模型輸出的結果是否可用。

為什麼要強調非AI?

因為大模型是基於概率的,所以要使用可靠的傳統的規則算法。當然,你用更高的模型來驗證低模型輸出也可以,但這依然是不可靠的。這點會在下一小節繼續論述。

注1:為了行文流暢,我忽略了一些細節,例如我把編譯和解釋同時稱作了「編譯」……但是這並不是重點。

注2:程序員直接看代碼生成質量也算一種可信驗證,但這依賴於用戶的知識水平。這裏只討論最基礎的可信驗證機制。

2. 模型端的應用:進擊的合成數據

光有可靠的驗證機制還不夠,模型本身的能力也很關鍵。(你總不能接受一個只有5%成功率的大模型吧)但有趣的是,大模型在代碼領域的進步似乎特別快,而且一直在進步。

這真的只是巧合嗎?

業界一直在強調自己家新模型在數學和代碼方面的突破,卻很少有人說「AI說話更像人了」。為什麼?

答案可能會出乎意料:因為訓練數據枯竭,大模型目前可能只能在代碼這個領域進步。

已經無數人提到過這個問題了,模型的自然訓練數據面臨枯竭。在大模型訓練中,數據和模型架構是同等重要的。數據的枯竭意味著模型能力提升會放緩。目前大模型廠商常用的應對策略:

(1)人工生產新的數據,包括但不限於在網上爬取,或者找人手動編寫新的數據;

(2)使用更高級的或者舊的模型合成數據訓練新模型。

人工生產新數據的成本高昂,大部分都會採用合成數據來訓練。而使用模型生成的合成數據又可能導致模型崩潰。已有大量研究證實,質量差的合成數據和人類語言的偏差會導致後續訓練模型的輸出越來越偏離人類表達。

那麼模型訓練方又是如何控制合成數據生成質量的?目前並沒有客觀的評價標準。主流方案是用更強大的模型來篩選,以及人工主觀判斷。這不僅成本高昂,還難以規模化,也不夠可靠。

然而可信驗證機制有效保證了代碼合成數據的下限,它縮小了合成數據和人類數據的差異。

代碼的驗證標準是二元的(能跑/不能跑)能運行並得到正確結果的就是好程序,報錯的就是錯誤程序。這種客觀標準讓我們可以大規模生成並驗證合成數據,效果等價於成千上萬個初級程序員在不知疲倦地編寫代碼,從中挑選可用的代碼。

這就是代碼合成可靠的根本原因:即使生成的代碼質量不高,但只要能通過編譯和運行,就具備基本的訓練價值。這種低成本的質量保證機制,確保了模型在代碼領域能持續進步。其實,大模型生成的代碼其實要比很多github上代碼質量更高。

3. 可信驗證的雙重價值

通過上面的分析,我們可以看到,可信驗證在AI編程領域發揮著雙重作用:

  • 在應用端,它讓AI編程獲得了用戶的信任。不需要專業知識,不需要複雜判斷,能跑就是能跑,不能跑就是不能跑。這種簡單直接的驗證機制大大降低了使用門檻,加速了AI編程的普及。而且讓很多「零知識用戶」也可以進行嘗試。

零知識用戶:不會編程但想做app的人,這個概念可以引申到其他領域。他們對可信驗證的要求極高,因為他們自己不會處理異常情況。

  • 在模型端,它解決了AI發展的數據瓶頸。當其他領域還在為訓練數據發愁時,編程領域已經找到了可持續的數據來源。可信驗證確保了合成數據的基本質量,讓模型能力持續提升。

可信驗證不僅解決了「用戶敢不敢用「的問題,還解決了「模型怎麼進步」的問題。在大模型產品toB端,可靠性一直是最大的痛點。但可信驗證機制提供了一個極為有效的解決方案 —— 它讓輸出結果可控、可及時驗證,配合原有的代碼審查集成機制,大大降低了應用風險。

在可信驗證的加持下,AI編程形成了一個良性循環,走出了一條可持續發展的道路。

三、關於AI編程的其他觀察

1. AI編程目前的局限性

(1)代碼生成質量依然有待提高

雖然有可信驗證機制,但目前AI生成的代碼質量仍然參差不齊。好在我們可以通過代碼覆蓋率、複雜度等客觀指標來評估代碼質量(沒錯,更高級的可信驗證),這些指標又可以反過來指導訓練數據的篩選,形成質量提升的閉環。

(2)AI編程對語言支持度不均衡

AI在Python上表現出色,而在Java等語言上相對遜色。這裏有兩點原因。

首先是訓練數據的差異。Python的開源社區活躍,這為大模型提供了海量的高質量訓練數據。

其次是語言特性的影響。Python的語法相對靈活,容錯性更高 ,這使得AI更容易生成可用的代碼。相比之下,Java等強類型語言的語法約束更嚴格,對代碼生成的要求也更高。

2. 自動化會帶來額外心智負擔

可信驗證的即時性還挺重要的,否則會給用戶帶來意想不到的心智負擔。這一點在Devin身上體現得特別明顯。

Devin被譽為全球首個AI程序員,號稱具備全棧開發、自學新技術、構建部署應用、自主調試等多項能力。

初次體驗Devin時,它確實讓人感覺非常爽。只要你把任務安排給它,然後就不需要管它了。就像真的擁有了一個實習生可以獨立完成任務,讓我能專注於其他工作。等著驗收就行。

但相比Cursor,Devin存在兩個致命問題:

(1)得到反饋的時間要更長,這意味著如果我給他的命令是錯的,或者他思維錯了,過很久我才會知道。這會嚴重降低工作效率,沉沒成本也更高了。

(2)調試成本劇增。AI生成的代碼量越大,debug的難度就越高。因為這些代碼不是你寫的,你需要額外的時間來理解它的邏輯。而且還有更嚴重的事情,在你debug的時候,經常會不知道到底是它代碼生成的有問題,還是你操作有問題。這點對於零知識用戶更為致命。

考慮到AI同樣可以debug。我專門做了個實驗:完全以零知識用戶的身份,讓Devin寫代碼,再用Claude來debug。Devin寫了20多分鐘的代碼,Claude debug了一個小時,功能依然沒能跑通。

與自動駕駛不同,開車時你可以隨時接管,因為車輛的當前狀態是顯而易見的。但在編程中,如果AI走錯了方向,之前的工作就全部作廢了。那幾十分鐘的等待,就真的變成了純粹的時間浪費。得到的是你和AI都不想用的一大堆代碼,沒有任何價值的代碼。

註:Devin不好用還有個很大的原因我覺得是背後的自研模型不夠強。我用Cursor的Agent搭配Claude,生成的代碼質量就高很多。

3. AI編程的未來發展:更高級的可信驗證

目前應用端的可信驗證還很初級,主要是看代碼「能不能跑」,考慮的是終端輸出結果。但隨著技術發展,會出現更高級的可信驗證方法,考慮更多的因素。例如上文的覆蓋率這些指標。

現代IDE已經能夠自動檢測性能隱患和安全漏洞。這些自動化的質量評估機制,本質上也是一種可信驗證——它們同樣具備客觀性和即時性,只是驗證維度更加豐富。

其次是自動化測試的進化。即使代碼能夠運行,也需要驗證其功能完整性。自動化測試框架能夠生成測試用例、檢查邊界條件、驗證業務邏輯,包括對代碼性能進行檢測,提供了另一層次的可信驗證。這些客觀的質量指標同樣可以反饋到訓練環節。這些進步意味著AI編程可以從「基本可用」進化到「高質量」,Devin這樣的產品也會更好用。我依然相信Devin是AI編程的未來,因為這種把人解放的自動化才是真正的自動化。

但是這種AI編程不適合零知識用戶,它的未來或許就是極大的增加程序員的生產力。對於零知識用戶,或許Dify這樣的平台更可靠。

4. 對其他領域的啟示

通過分析AI編程的成功,我們其實可以得到一個重要啟示:任何想要成功應用AI的領域,都需要找到自己的「可信驗證」機制。

不是所有領域都能像編程那樣有編譯器這種完美的驗證工具。也可以借鑒這種思路,在各自領域內建立相對可靠的驗證機制。這個驗證機制即使早期不能做到100%準確,但至少要能給出一個基本的可用性判斷。「要知道模型的下限在哪」。 可信驗證不僅能降低使用門檻,還能為模型訓練提供可靠的數據來源。

本文來自微信公眾號:阿茶的AI之路,作者:起名賊費勁的阿茶