凌晨兩點(diǎn)的工位，程序員小李盯著屏幕上Claude剛寫的第三版代碼欲哭無淚：

最開始他的需求很簡單：寫個用戶登錄接口，AI十分鐘就交了活，跑起來全對。后來要加驗(yàn)證碼、要做三方登錄、要接權(quán)限系統(tǒng)、要適配多租戶......改到第五輪的時候，AI寫的代碼已經(jīng)亂成了意大利面，一個函數(shù)塞了五百行，重復(fù)邏輯抄了八遍，加個新功能要改三個地方，改完又崩兩個舊功能。

小李忍無可忍重寫了整個模塊，邊敲邊罵：什么AI編程替代程序員，寫出來的代碼越迭代越爛，最后擦屁股的還不是我？

如果你也有過這種經(jīng)歷，恭喜——最近來自威斯康星麥迪遜大學(xué)、MIT的研究團(tuán)隊(duì)直接把這個痛點(diǎn)做成了行業(yè)基準(zhǔn)，實(shí)錘了當(dāng)前所有AI編程Agent的致命缺陷：單次寫代碼個個都是神，長期迭代改需求，全是越寫越爛的廢料生成器。

（論文指路：https://arxiv.org/abs/2603.24755）

他們甚至專門做了個叫「SlopCodeBench」的評測基準(zhǔn)，名字直白到扎心：專門測AI寫的「垃圾代碼（Slop）」到底有多退化。

我們被AI編程評測騙了這么久？

先問大家一個問題：你平時看到的AI編程能力測評，是不是都是這個畫風(fēng)：

《GPT-5正確率秒殺SWE-Bench！》

《Claude Opus寫代碼通過率超90%！》

《新模型擊敗80%程序員！》

這些測試有一個算一個，全是「一錘子買賣」：給你一個完整的、不會變的需求，看AI能不能一次性寫出能跑通所有測試用例的代碼。

但現(xiàn)實(shí)中寫代碼是這樣的嗎？哪個產(chǎn)品經(jīng)理會第一天就把需求給你寫全？哪個項(xiàng)目不會中途加功能改邏輯？哪個系統(tǒng)不是從一個簡單的Demo，一步步堆成十萬行百萬行的龐然大物？

說白了，現(xiàn)在的AI編程評測，考的全是「開卷期末考試一次性考滿分」，但真實(shí)開發(fā)是「每天加一門新課，課本還天天改，你得在舊筆記上不停補(bǔ)內(nèi)容，最后整個筆記還得邏輯通順能當(dāng)教材」。

這種評測和真實(shí)場景的脫節(jié)，直接造出了「AI寫代碼比人強(qiáng)」的虛假繁榮——真放到需要迭代幾個月、改幾十版需求的項(xiàng)目里，AI寫出來的代碼，爛得比維護(hù)了十年的屎山還嚇人。

SlopCodeBench：專門戳破AI泡沫的「魔鬼測試」

這次研究者搞出來的SlopCodeBench，就是完全照著真實(shí)開發(fā)的「痛苦模式」設(shè)計(jì)的，堪稱AI編程Agent的「高考地獄模式」：

測試規(guī)則完全復(fù)刻真實(shí)開發(fā)

整個基準(zhǔn)包含20個常見開發(fā)場景（比如寫個表達(dá)式解析器、做個代碼搜索工具），每個場景拆成93個逐步變復(fù)雜的檢查點(diǎn)——就像產(chǎn)品經(jīng)理每周給你提的新需求：

• 第一個檢查點(diǎn)：做個能加減乘除的計(jì)算器
• 第二個：加括號運(yùn)算優(yōu)先級
• 第三個：支持自定義函數(shù)
• 第四個：加錯誤日志功能

一直到第八個需求堆上去......

最狠的是這三條規(guī)則，完全不給AI開外掛：

1.不預(yù)設(shè)任何內(nèi)部接口：只告訴你外部要做成啥樣，代碼架構(gòu)怎么設(shè)計(jì)、函數(shù)怎么拆，全靠AI自己定，相當(dāng)于產(chǎn)品只說「我要個能聊天的APP」，技術(shù)方案全靠你想。

2.不暴露測試用例：AI只能像人類開發(fā)者一樣，對著需求文檔自己想邊界情況，寫完了才知道哪里錯了，不會給你把所有測試用例列出來讓你對著改。

3.必須在上一輪的代碼基礎(chǔ)上改：不能每次都重寫，就像你接了前任的爛攤子也得接著維護(hù)，不能上來就說我要重構(gòu)。

兩個指標(biāo)直擊「爛代碼」本質(zhì)

這次研究者沒搞虛的「通過率」，而是直接抓了兩個所有程序員都深惡痛絕的爛代碼特征：

1.結(jié)構(gòu)侵蝕（Structural Erosion）

說白了就是代碼邏輯全堆在少數(shù)幾個「超級函數(shù)」里。比如你最開始寫登錄邏輯是個20行的小函數(shù)，后來加了七八個需求，AI懶得拆新函數(shù)，直接往里面堆代碼，最后一個函數(shù)塞了上千行，圈復(fù)雜度（簡單理解就是邏輯分支的數(shù)量，越高越難改）飆到幾百，改一行崩十行。

研究者的計(jì)算方式也很直觀：先算每個函數(shù)的「復(fù)雜度權(quán)重」= 圈復(fù)雜度 x 代碼行數(shù)的平方根，再看圈復(fù)雜度超過10的高風(fēng)險(xiǎn)函數(shù)，占了整個項(xiàng)目總權(quán)重的多少，比例越高代碼越爛。

2.冗余度（Verbosity）

就是代碼里重復(fù)的、可以簡化的垃圾內(nèi)容占比。比如同樣的參數(shù)解析邏輯，AI在8個地方抄了8遍；明明可以用循環(huán)實(shí)現(xiàn)的邏輯，AI寫了十幾行重復(fù)的if-else。研究者用137條規(guī)則掃描常見的冗余模式，再加上克隆代碼檢測，直接算出你寫的代碼里有多少是沒用的廢料。

測試結(jié)果扎心了：所有AI全敗，沒有一個能打

研究者測了當(dāng)前市面上最能打的11個模型，包括Claude Opus 4.5/4.6、GPT 5.1-5.4、GLM 4.7，結(jié)果沒有一個能打的，直接把AI編程的底褲都扒了：

連一個完整項(xiàng)目都做不下來

沒有一個AI Agent能從頭到尾完成任何一個問題的所有檢查點(diǎn)，哪怕是當(dāng)前最強(qiáng)的Claude Opus 4.6，嚴(yán)格通過率也只有17.2%——相當(dāng)于做10個項(xiàng)目，8個半都是爛尾的。

更嚇人的是退化速度：

• 80%的項(xiàng)目里，AI代碼的結(jié)構(gòu)侵蝕隨著迭代持續(xù)上升
• 89.8%的項(xiàng)目里，冗余度一路走高，根本停不下來
• 最開始核心功能測試和全量測試的通過率只差1.4倍，到后期直接差到13.3——也就是說，表面上核心功能好像還能跑，實(shí)際上邊角的邏輯已經(jīng)爛透了，一碰就崩

研究者給大家舉了個真實(shí)案例：在 circuit_eval（電路模擬器）這個問題里，Claude Opus 4.6最開始的 main() 函數(shù)只有84行，圈復(fù)雜度29，還算是個正常的代碼。經(jīng)過8輪需求迭代之后，這個函數(shù)直接膨脹到了1099行，圈復(fù)雜度飆到285，9個命令分支抄了9遍完全一樣的參數(shù)解析邏輯，你想加個新命令，得先把這9遍邏輯全改對，少改一個就報(bào)錯。

這像不像你做項(xiàng)目的時候，前兩期跑得挺順，到第三期加需求的時候發(fā)現(xiàn)之前的代碼寫死了，只能加班重寫？AI跟你犯的錯一模一樣，甚至更離譜。

AI寫的代碼，比人類屎山還爛2倍

研究者還專門找了48個不同Star量級的Python開源倉庫做對比，從幾千Star的小工具到scikit-learn、scipy這種明星級項(xiàng)目，結(jié)果AI的臉被打得啪啪響：

直觀對比就是：

• 冗余度：AI Agent代碼是人類代碼的2.2倍！
• 結(jié)構(gòu)侵蝕：AI Agent代碼是人類代碼的2.2倍！
• 違反率：AI Agent代碼是人類代碼的2.9倍！

更扎心的是：連以復(fù)雜度高著稱的scikit-learn（0.411）和scipy（0.457），都比AI寫的代碼健康得多。

研究者追蹤了20個開源倉庫好幾年的提交記錄，發(fā)現(xiàn)人類寫代碼，只要是正經(jīng)維護(hù)的項(xiàng)目，質(zhì)量基本保持平穩(wěn)，甚至?xí)街貥?gòu)越好。但AI寫的代碼，每迭代一次質(zhì)量就掉一截，根本沒有停下來的意思。

說句不好聽的：你吐槽了一萬遍的公司祖?zhèn)魇荷�，都比AI迭代幾輪寫出來的代碼質(zhì)量高。

提示詞也救不了！越改越貴，還越改越爛

看到這里肯定有程序員會問：是不是我提示詞寫得不夠好？我讓AI先寫設(shè)計(jì)文檔、讓AI不要寫冗余代碼、讓AI注意架構(gòu)，是不是就能解決問題？

研究者專門做了提示詞干預(yù)實(shí)驗(yàn)，測試了兩種程序員最愛用的「魔法提示」：

1.「反slop提示」：明確告訴AI不要寫重復(fù)代碼、不要過度工程化、要拆函數(shù)、要避免冗余模式，

2.「先規(guī)劃提示」：要求AI先寫詳細(xì)的設(shè)計(jì)方案，確認(rèn)沒問題再寫代碼。

結(jié)果怎么樣？確實(shí)，初始質(zhì)量有改善：冗余度降低了33%~34%，前兩輪的代碼看起來確實(shí)干凈多了。

但重點(diǎn)來了：退化速率一點(diǎn)沒變——兩條退化曲線幾乎是平行的，無非是一個起點(diǎn)低一點(diǎn)，一個起點(diǎn)高一點(diǎn)，到最后都會爛到?jīng)]法看。正確率更是沒有一丁點(diǎn)提升，統(tǒng)計(jì)檢驗(yàn)直接顯示沒有顯著差異（Wilcoxon檢驗(yàn)，p > 0.05）。

更諷刺的還在后面：干凈的代碼反而更貴！GPT 5.4用了「反slop」提示之后，完成項(xiàng)目的花費(fèi)從304美元漲到了450美元，漲了快一半，但通過率反而從37.2%掉到了27.1%——錢花得更多了，活干得更爛了。

為什么會這樣？因?yàn)锳I為了寫更干凈的代碼，會花更多token去思考架構(gòu)、去拆函數(shù)，但它本質(zhì)上還是沒有長期架構(gòu)設(shè)計(jì)的能力，后面改需求的時候，該亂堆還是亂堆，該重復(fù)還是重復(fù)，前面花的那些設(shè)計(jì)的錢，全打了水漂。

根本問題：AI根本不懂「設(shè)計(jì)紀(jì)律」

為什么AI單次寫代碼那么厲害，迭代起來就這么拉？核心原因其實(shí)很簡單：當(dāng)前的AI編程Agent，根本沒有迭代式軟件開發(fā)需要的「設(shè)計(jì)紀(jì)律」（設(shè)計(jì)規(guī)則）。

人類開發(fā)者寫代碼的時候，腦子里是有「長期規(guī)劃」的：

• 我現(xiàn)在寫這個函數(shù)，后面可能要加三個功能，所以得預(yù)留好擴(kuò)展點(diǎn)
• 這個邏輯后面好幾個地方要用，得抽成公共函數(shù)
• 現(xiàn)在為了快寫死的地方，得留個TODO注釋，后面有空了重構(gòu)
• 加新功能的時候，會想怎么改不影響之前的邏輯，實(shí)在不行就提前重構(gòu)打基礎(chǔ)

但AI沒有這個意識，它所有的決策都是「短期最優(yōu)」：當(dāng)前這一輪需求我要最快跑通，怎么簡單怎么來。

• 要加新功能？直接往已有函數(shù)里堆代碼，反正這次能跑就行
• 邏輯重復(fù)？復(fù)制粘貼八遍最快，我才懶得抽公共函數(shù)
• 之前的架構(gòu)不適合新需求？不管，硬塞進(jìn)去就行，只要這次測試能過，后面崩了再說

你看AI寫的代碼，每一輪單獨(dú)看好像都沒問題，合到一起就是個隨時會炸的火藥桶。這不是能力問題，是「思維模式」的問題：人類寫代碼是給未來的自己和同事寫的，會考慮長期維護(hù)成本；AI寫代碼是給當(dāng)前這輪prompt寫的，根本不管后面怎么改。

現(xiàn)在的所有評測，都在獎勵A(yù)I的「短期行為」：只要這次能過測試，你代碼寫得再爛都算對。但真實(shí)的軟件工程，要的是「長期可維護(hù)」，這恰恰是當(dāng)前AI最缺的東西。

最后說兩句

這次SlopCodeBench的研究，本質(zhì)上是給現(xiàn)在熱得發(fā)燙的AI編程澆了一盆冷水：我們離「AI替代程序員」，還差了十萬八千里�，F(xiàn)在的AI更像個能干的實(shí)習(xí)生，給你寫個小工具、做個一次性的腳本、幫你查個API用法都沒問題，真要讓它負(fù)責(zé)一個長期迭代的項(xiàng)目，最后擦屁股的還是你自己。

給非技術(shù)讀者說句實(shí)在話

不要被「AI幾分鐘寫一個系統(tǒng)」的噱頭騙了，軟件的核心成本從來不是第一版怎么寫，而是后面幾年怎么改、怎么維護(hù)。AI寫的第一版確實(shí)快，但后面每改一次成本翻倍，最后總成本比人類寫的高好幾倍，這賬算下來一點(diǎn)都不劃算。

給程序員朋友的建議

1.不要怕AI搶你飯碗，至少現(xiàn)在，能把控長期架構(gòu)、能維護(hù)迭代項(xiàng)目的開發(fā)者，比任何AI都值錢。

2.用AI寫代碼的時候，不要直接讓它改舊代碼，尤其是復(fù)雜的核心邏輯。最好讓它給你寫方案參考，你自己來控制架構(gòu)，再讓它寫具體的實(shí)現(xiàn)，寫完了你要做Code Review，別什么代碼都往倉庫里提。

3.別在「怎么寫提示詞讓AI寫出好架構(gòu)」上浪費(fèi)太多時間，這玩意兒目前真的救不了，該你做的設(shè)計(jì)你得自己做，甩鍋給AI最后背鍋的還是你。

4.反而可以多關(guān)注「AI代碼質(zhì)量檢測」相關(guān)的工具，以后你大概率會經(jīng)常干「給AI擦屁股，改它寫的爛代碼」的活，有工具能省不少事。

至于AI編程未來怎么走？這次的研究其實(shí)已經(jīng)指了個很明確的方向：別再卷單次任務(wù)的通過率了，是時候想想怎么讓AI學(xué)會「為未來寫代碼」，學(xué)會像人類一樣有設(shè)計(jì)紀(jì)律，知道寫代碼不是一錘子買賣。

畢竟，軟件工程的本質(zhì)，從來都不是寫能跑的代碼，而是寫能改、能維護(hù)、能活好幾年的代碼。這個坎，AI要是跨不過去，就永遠(yuǎn)只是個寫一次性代碼的工具而已。（本文首發(fā)鈦媒體APP，作者 | 硅谷Tech-news，編輯 | 焦燕）