最新研究戳穿AI寫代碼的致命騙局：越改越爛，連人類屎山都打不過！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.不預設任何內部接口：只告訴你外部要做成啥樣，代碼架構怎么設計、函數怎么拆，全靠AI自己定，相當于產品只說「我要個能聊天的APP」，技術方案全靠你想。

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

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

兩個指標直擊「爛代碼」本質

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

1.結構侵蝕（Structural Erosion）

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

研究者的計算方式也很直觀：先算每個函數的「復雜度權重」= 圈復雜度 x 代碼行數的平方根，再看圈復雜度超過10的高風險函數，占了整個項目總權重的多少，比例越高代碼越爛。

2.冗余度（Verbosity）

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

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

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

連一個完整項目都做不下來

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

更嚇人的是退化速度：

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

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

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

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

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

直觀對比就是：

• 冗余度：AI Agent代碼是人類代碼的2.2倍！
• 結構侵蝕：AI Agent代碼是人類代碼的2.2倍！
• 違反率：AI Agent代碼是人類代碼的2.9倍！

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

研究者追蹤了20個開源倉庫好幾年的提交記錄，發(fā)現人類寫代碼，只要是正經維護的項目，質量基本保持平穩(wěn)，甚至會越重構越好。但AI寫的代碼，每迭代一次質量就掉一截，根本沒有停下來的意思。

說句不好聽的：你吐槽了一萬遍的公司祖?zhèn)魇荷剑急華I迭代幾輪寫出來的代碼質量高。

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

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

研究者專門做了提示詞干預實驗，測試了兩種程序員最愛用的「魔法提示」：

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

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

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

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

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

為什么會這樣？因為AI為了寫更干凈的代碼，會花更多token去思考架構、去拆函數，但它本質上還是沒有長期架構設計的能力，后面改需求的時候，該亂堆還是亂堆，該重復還是重復，前面花的那些設計的錢，全打了水漂。

根本問題：AI根本不懂「設計紀律」

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

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

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

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

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

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

現在的所有評測，都在獎勵AI的「短期行為」：只要這次能過測試，你代碼寫得再爛都算對。但真實的軟件工程，要的是「長期可維護」，這恰恰是當前AI最缺的東西。

最后說兩句

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

給非技術讀者說句實在話

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

給程序員朋友的建議

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

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

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

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

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

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