本文來自微信公眾號：阿茶的AI之路，作者：起名賊費勁的阿茶，題圖來自：AI生成
原本計劃寫一篇2024年AI領(lǐng)域的年度總結(jié)，但鴿了�，F(xiàn)在決定將內(nèi)容拆分成系列文章。開局先放王炸，聊聊為什么大模型落地喊得火熱，但是實際落地的場景只有AI編程。
AI編程無疑是當下大模型落地最成功的一個領(lǐng)域。從Github的Copilot，到Cursor，再到第一個AI程序員Devin。好多人都在說：AI編程找到了PMF（Product Market Fit，產(chǎn)品市場契合）。
但為什么是它？
有人說“因為是真實需求”。難道AI在其他領(lǐng)域就是偽需求嗎？
有人說“因為代碼比自然語言更容易生成”。真的是這樣嗎？
還有人說“其他領(lǐng)域的模型能力還不夠”。但為什么編程夠呢？
這些解釋都過于表面，今天就從我的角度來解析為什么AI編程能成功落地，以及它未來的發(fā)展。
先從一個問題開始。
一、代碼和自然語言，到底哪個更難生成
“代碼的關(guān)鍵詞少，規(guī)則固定，所以更容易生成�！边@是解釋AI編程為什么好用的常見說法。
聽起來挺有道理的？代碼就那些關(guān)鍵詞，模型只要從有限的詞里面挑就行了，采樣空間相比自然語言小太多了。
但是什么時候“詞少=容易”了？如果真的是這樣的話，數(shù)學(xué)問題的描述足夠精簡，符號也少。那大模型做數(shù)學(xué)問題應(yīng)該更強吧。
顯然不是這樣。
大模型到現(xiàn)在連JSON都弄不明白。JSON是一種編程領(lǐng)域常用的數(shù)據(jù)交互格式，在面對較為復(fù)雜的JSON時，大模型經(jīng)常會出現(xiàn)括號對不上、層級關(guān)系錯亂的問題。
這個“代碼更容易生成”的論點，其實混淆了“生成”和“應(yīng)用”兩個階段。
在自然語言生成中，我們對大模型的容忍度很高。它可以犯語法錯誤，可以前后矛盾，可以邏輯混亂，我們依然能從中提取有價值的信息。容錯性非常高。
但代碼生成完全是另一個維度的挑戰(zhàn)。就像做數(shù)學(xué)題，代碼能跑就是能跑，跑不通就是報錯。它不存在“基本正確“或“大致可用“的中間狀態(tài)。每一個分號、每一處縮進、每一個變量名都必須精確無誤。所以代碼生成其實是更難的，因為對代碼的可用性要求是遠高于文本的。
二、核心：可信驗證
代碼生成難度更高，為什么它應(yīng)用得最好呢？那些難度低的領(lǐng)域為什么反而應(yīng)用效果差呢？真正原因其實是編程具有一種可信驗證機制。
所謂可信驗證，簡單地說，就是一種能夠快速、客觀地判斷AI輸出結(jié)果的可用性的驗證模式。
1. 客觀性：驗證結(jié)果不依賴人或者AI模型的主觀判斷；
2. 即時性：能夠立刻得到驗證結(jié)果；
3. 確定性：對就是對，錯就是錯。
接下來我將論述可信驗證是怎樣讓AI編程成功的。
1. 應(yīng)用端的應(yīng)用：快速而準確的驗證
為什么說編程領(lǐng)域有著完美的可信驗證？這讓我想到網(wǎng)上流傳的一句話：
戀人會背叛你，朋友會欺騙你，但數(shù)學(xué)不會，因為數(shù)學(xué)不會就是不會。
答案就藏在代碼的本質(zhì)特性中：程序設(shè)計就像數(shù)學(xué)一樣，是一個非黑即白的世界能跑就是能跑，跑不了就是跑不了。這種確定性來自一個關(guān)鍵角色：編譯器。它負責(zé)將代碼編譯成可執(zhí)行文件，這個過程是嚴格符合語法規(guī)定的。
編譯器將代碼編譯成可執(zhí)行程序在這個過程中，編譯器扮演著一個獨特的角色：它是第三方的、非AI的、完全可靠的驗證機制。它不會被情緒影響，也不會擔心被人類誘導(dǎo)，不會有主觀偏見，只會忠實地執(zhí)行語法規(guī)則。符合規(guī)則就可以編譯，不符合就是報錯。
這種嚴格的驗證機制成就了AI編程的應(yīng)用。在AI嘗試落地的所有領(lǐng)域中，幾乎沒有哪個領(lǐng)域能像編程這樣擁有如此客觀、即時、確定的驗證標準。這種驗證機制對使用者的要求極低不需要你懂編程原理，不需要你精通算法，只要能運行代碼，就能知道大模型輸出的結(jié)果是否可用。
為什么要強調(diào)非AI？
因為大模型是基于概率的，所以要使用可靠的傳統(tǒng)的規(guī)則算法。當然，你用更高的模型來驗證低模型輸出也可以，但這依然是不可靠的。這點會在下一小節(jié)繼續(xù)論述。
注1：為了行文流暢，我忽略了一些細節(jié)，例如我把編譯和解釋同時稱作了“編譯”……但是這并不是重點。
注2：程序員直接看代碼生成質(zhì)量也算一種可信驗證，但這依賴于用戶的知識水平。這里只討論最基礎(chǔ)的可信驗證機制。
2. 模型端的應(yīng)用：進擊的合成數(shù)據(jù)
光有可靠的驗證機制還不夠，模型本身的能力也很關(guān)鍵。（你總不能接受一個只有5%成功率的大模型吧）但有趣的是，大模型在代碼領(lǐng)域的進步似乎特別快，而且一直在進步。
這真的只是巧合嗎？
業(yè)界一直在強調(diào)自己家新模型在數(shù)學(xué)和代碼方面的突破，卻很少有人說“AI說話更像人了”。為什么？
答案可能會出乎意料：因為訓(xùn)練數(shù)據(jù)枯竭，大模型目前可能只能在代碼這個領(lǐng)域進步。
已經(jīng)無數(shù)人提到過這個問題了，模型的自然訓(xùn)練數(shù)據(jù)面臨枯竭。在大模型訓(xùn)練中，數(shù)據(jù)和模型架構(gòu)是同等重要的。數(shù)據(jù)的枯竭意味著模型能力提升會放緩。目前大模型廠商常用的應(yīng)對策略：
（1）人工生產(chǎn)新的數(shù)據(jù)，包括但不限于在網(wǎng)上爬取，或者找人手動編寫新的數(shù)據(jù)；
（2）使用更高級的或者舊的模型合成數(shù)據(jù)訓(xùn)練新模型。
人工生產(chǎn)新數(shù)據(jù)的成本高昂，大部分都會采用合成數(shù)據(jù)來訓(xùn)練。而使用模型生成的合成數(shù)據(jù)又可能導(dǎo)致模型崩潰。已有大量研究證實，質(zhì)量差的合成數(shù)據(jù)和人類語言的偏差會導(dǎo)致后續(xù)訓(xùn)練模型的輸出越來越偏離人類表達。
那么模型訓(xùn)練方又是如何控制合成數(shù)據(jù)生成質(zhì)量的？目前并沒有客觀的評價標準。主流方案是用更強大的模型來篩選，以及人工主觀判斷。這不僅成本高昂，還難以規(guī)�；膊粔蚩煽�。
然而可信驗證機制有效保證了代碼合成數(shù)據(jù)的下限，它縮小了合成數(shù)據(jù)和人類數(shù)據(jù)的差異。
代碼的驗證標準是二元的（能跑/不能跑），能運行并得到正確結(jié)果的就是好程序，報錯的就是錯誤程序。這種客觀標準讓我們可以大規(guī)模生成并驗證合成數(shù)據(jù)，效果等價于成千上萬個初級程序員在不知疲倦地編寫代碼，從中挑選可用的代碼。
這就是代碼合成可靠的根本原因：即使生成的代碼質(zhì)量不高，但只要能通過編譯和運行，就具備基本的訓(xùn)練價值。這種低成本的質(zhì)量保證機制，確保了模型在代碼領(lǐng)域能持續(xù)進步。其實，大模型生成的代碼其實要比很多github上代碼質(zhì)量更高。
3. 可信驗證的雙重價值
通過上面的分析，我們可以看到，可信驗證在AI編程領(lǐng)域發(fā)揮著雙重作用：
在應(yīng)用端，它讓AI編程獲得了用戶的信任。不需要專業(yè)知識，不需要復(fù)雜判斷，能跑就是能跑，不能跑就是不能跑。這種簡單直接的驗證機制大大降低了使用門檻，加速了AI編程的普及。而且讓很多“零知識用戶”也可以進行嘗試。
零知識用戶：不會編程但想做app的人，這個概念可以引申到其他領(lǐng)域。他們對可信驗證的要求極高，因為他們自己不會處理異常情況。
在模型端，它解決了AI發(fā)展的數(shù)據(jù)瓶頸。當其他領(lǐng)域還在為訓(xùn)練數(shù)據(jù)發(fā)愁時，編程領(lǐng)域已經(jīng)找到了可持續(xù)的數(shù)據(jù)來源�？尚膨炞C確保了合成數(shù)據(jù)的基本質(zhì)量，讓模型能力持續(xù)提升。
可信驗證不僅解決了“用戶敢不敢用“的問題，還解決了“模型怎么進步”的問題。在大模型產(chǎn)品toB端，可靠性一直是最大的痛點。但可信驗證機制提供了一個極為有效的解決方案 它讓輸出結(jié)果可控、可及時驗證，配合原有的代碼審查集成機制，大大降低了應(yīng)用風(fēng)險。
在可信驗證的加持下，AI編程形成了一個良性循環(huán)，走出了一條可持續(xù)發(fā)展的道路。
三、關(guān)于AI編程的其他觀察
1.AI編程目前的局限性
（1）代碼生成質(zhì)量依然有待提高
雖然有可信驗證機制，但目前AI生成的代碼質(zhì)量仍然參差不齊。好在我們可以通過代碼覆蓋率、復(fù)雜度等客觀指標來評估代碼質(zhì)量（沒錯，更高級的可信驗證），這些指標又可以反過來指導(dǎo)訓(xùn)練數(shù)據(jù)的篩選，形成質(zhì)量提升的閉環(huán)。
（2）AI編程對語言支持度不均衡
AI在Python上表現(xiàn)出色，而在Java等語言上相對遜色。這里有兩點原因。
首先是訓(xùn)練數(shù)據(jù)的差異。Python的開源社區(qū)活躍，這為大模型提供了海量的高質(zhì)量訓(xùn)練數(shù)據(jù)。
其次是語言特性的影響。Python的語法相對靈活，容錯性更高，這使得AI更容易生成可用的代碼。相比之下，Java等強類型語言的語法約束更嚴格，對代碼生成的要求也更高。
2. 自動化會帶來額外心智負擔
可信驗證的即時性還挺重要的，否則會給用戶帶來意想不到的心智負擔。這一點在Devin身上體現(xiàn)得特別明顯。
Devin被譽為全球首個AI程序員，號稱具備全棧開發(fā)、自學(xué)新技術(shù)、構(gòu)建部署應(yīng)用、自主調(diào)試等多項能力。
初次體驗Devin時，它確實讓人感覺非常爽。只要你把任務(wù)安排給它，然后就不需要管它了。就像真的擁有了一個實習(xí)生可以獨立完成任務(wù)，讓我能專注于其他工作。等著驗收就行。
但相比Cursor，Devin存在兩個致命問題：
（1）得到反饋的時間要更長，這意味著如果我給他的命令是錯的，或者他思維錯了，過很久我才會知道。這會嚴重降低工作效率，沉沒成本也更高了。
（2）調(diào)試成本劇增。AI生成的代碼量越大，debug的難度就越高。因為這些代碼不是你寫的，你需要額外的時間來理解它的邏輯。而且還有更嚴重的事情，在你debug的時候，經(jīng)常會不知道到底是它代碼生成的有問題，還是你操作有問題。這點對于零知識用戶更為致命。
考慮到AI同樣可以debug。我專門做了個實驗：完全以零知識用戶的身份，讓Devin寫代碼，再用Claude來debug。Devin寫了20多分鐘的代碼，Claude debug了一個小時，功能依然沒能跑通。
與自動駕駛不同，開車時你可以隨時接管，因為車輛的當前狀態(tài)是顯而易見的。但在編程中，如果AI走錯了方向，之前的工作就全部作廢了。那幾十分鐘的等待，就真的變成了純粹的時間浪費。得到的是你和AI都不想用的一大堆代碼，沒有任何價值的代碼。
注：Devin不好用還有個很大的原因我覺得是背后的自研模型不夠強。我用Cursor的Agent搭配Claude，生成的代碼質(zhì)量就高很多。
3. AI編程的未來發(fā)展：更高級的可信驗證
目前應(yīng)用端的可信驗證還很初級，主要是看代碼“能不能跑”，考慮的是終端輸出結(jié)果。但隨著技術(shù)發(fā)展，會出現(xiàn)更高級的可信驗證方法，考慮更多的因素。例如上文的覆蓋率這些指標。
現(xiàn)代IDE已經(jīng)能夠自動檢測性能隱患和安全漏洞。這些自動化的質(zhì)量評估機制，本質(zhì)上也是一種可信驗證它們同樣具備客觀性和即時性，只是驗證維度更加豐富。
其次是自動化測試的進化。即使代碼能夠運行，也需要驗證其功能完整性。自動化測試框架能夠生成測試用例、檢查邊界條件、驗證業(yè)務(wù)邏輯，包括對代碼性能進行檢測，提供了另一層次的可信驗證。這些客觀的質(zhì)量指標同樣可以反饋到訓(xùn)練環(huán)節(jié)。這些進步意味著AI編程可以從“基本可用”進化到“高質(zhì)量”，Devin這樣的產(chǎn)品也會更好用。我依然相信Devin是AI編程的未來，因為這種把人解放的自動化才是真正的自動化。
但是這種AI編程不適合零知識用戶，它的未來或許就是極大的增加程序員的生產(chǎn)力。對于零知識用戶，或許Dify這樣的平臺更可靠。
4. 對其他領(lǐng)域的啟示
通過分析AI編程的成功，我們其實可以得到一個重要啟示：任何想要成功應(yīng)用AI的領(lǐng)域，都需要找到自己的“可信驗證”機制。
不是所有領(lǐng)域都能像編程那樣有編譯器這種完美的驗證工具。也可以借鑒這種思路，在各自領(lǐng)域內(nèi)建立相對可靠的驗證機制。這個驗證機制即使早期不能做到100%準確，但至少要能給出一個基本的可用性判斷。“要知道模型的下限在哪”�？尚膨炞C不僅能降低使用門檻，還能為模型訓(xùn)練提供可靠的數(shù)據(jù)來源。
本文來自微信公眾號：阿茶的AI之路，作者：起名賊費勁的阿茶
本內(nèi)容為作者獨立觀點，不代表虎嗅立場。未經(jīng)允許不得轉(zhuǎn)載，授權(quán)事宜請聯(lián)系 hezuo@huxiu.com
正在改變與想要改變世界的人，都在 虎嗅APP
