當(dāng)AI編程成為“銀彈”，我們可能正站在新的深淵邊緣

表面光鮮的代碼庫下，暗流涌動(dòng)。

凌晨兩點(diǎn)，小王盯著屏幕上那幾萬行由AI生成的代碼，額頭上的汗珠順著臉頰滑落。

生產(chǎn)環(huán)境又崩了。這已經(jīng)是本月第三次了。詭異的是，每一段代碼單獨(dú)看都“完美無瑕”：注釋清晰、命名規(guī)范、遵循單一職責(zé)原則。但當(dāng)它們拼湊在一起，卻成了一個(gè)無人能解的黑箱。

“代碼是AI寫的，但責(zé)任是我的。”小王苦色地想。

這不是虛構(gòu)場景。在AI編程工具普及的今天，這樣的困境正在無數(shù)開發(fā)團(tuán)隊(duì)中悄然上演。

“復(fù)雜度”并未消失，只是轉(zhuǎn)移了

當(dāng)AI編程助手剛出現(xiàn)時(shí)，所有人都?xì)g呼雀躍，終于可以告別繁瑣的CRUD、重復(fù)的工具類、千篇一律的配置代碼了。效率提升了，開發(fā)周期縮短了，項(xiàng)目看起來更“先進(jìn)”了。

但事情沒那么簡單。

AI并沒有消滅軟件工程中那個(gè)隱形的敵人——“復(fù)雜度”，它只是狡猾地從“實(shí)現(xiàn)期”轉(zhuǎn)移到了“集成期與維護(hù)期”。

過去，程序員需要花大量時(shí)間思考設(shè)計(jì)、編寫模塊文檔、規(guī)劃接口。現(xiàn)在，為了“省事”，我們跳過了這些步驟，直接讓AI生成細(xì)粒度的函數(shù)。代碼確實(shí)跑起來了，速度很快，但代價(jià)是什么？

“大泥球”代碼的誕生

AI有一個(gè)致命傾向：為了確保代碼能立刻運(yùn)行，它會(huì)生成高內(nèi)聚的“大泥球”。這聽起來似乎不錯(cuò)？等等，別被術(shù)語迷惑了。

“高內(nèi)聚”在這里并非褒義詞。它意味著AI傾向于將所有相關(guān)邏輯塞進(jìn)一個(gè)巨大的函數(shù)或類中，而不做深度的、前瞻性的抽象。AI沒有“未來感”，它只關(guān)心“當(dāng)下這一刻”——輸入什么，輸出什么，中間的過程能跑通就行。

我是《軟件設(shè)計(jì)的哲學(xué)》的譯者，也是作者的好友，書中提到了一個(gè)概念叫“戰(zhàn)術(shù)性編程”——為了快速完成任務(wù)而寫爛代碼，這是軟件腐爛的根源。

而AI，本質(zhì)上就是極致版本的“戰(zhàn)術(shù)性編程”。AI沒有“戰(zhàn)略”，它只有“下一步”。

想象一下：100萬行由AI生成的“戰(zhàn)術(shù)性代碼”被拼湊在一起。表面上，項(xiàng)目進(jìn)度喜人、功能齊全。但內(nèi)部邏輯已經(jīng)變成了一座巴比倫塔——沒有任何一個(gè)人類大腦能夠完全理解這座塔是如何運(yùn)作的。

細(xì)節(jié)的爆炸：當(dāng)“單一職責(zé)”走向極端

更隱蔽的問題是：AI導(dǎo)致了“超細(xì)粒度碎片化”。

舉個(gè)例子：原來一個(gè)類有5個(gè)方法，結(jié)構(gòu)清晰，職責(zé)明確。現(xiàn)在，AI“優(yōu)化”后生成了50個(gè)微小的輔助函數(shù)，每個(gè)只有三五行的代碼，因?yàn)樗鼈儭翱雌饋砀蠁我宦氊?zé)原則”。

這聽起來很“整潔”，對嗎？

錯(cuò)。系統(tǒng)的認(rèn)知負(fù)擔(dān)非但沒有降低，反而因?yàn)榧?xì)節(jié)的過度暴露而激增。人類大腦的“工作記憶”容量是有限的——我們只能同時(shí)處理大約7個(gè)信息塊。當(dāng)50個(gè)微小的輔助函數(shù)散落在代碼庫中，你需要在腦海中拼湊的邏輯碎片已經(jīng)遠(yuǎn)遠(yuǎn)超出了認(rèn)知負(fù)荷。

這種碎片化帶來的不是靈活性，而是一場認(rèn)知災(zāi)難。

虛假的掌控感：溫水煮青蛙

起初，一切都在掌控之中。局部代碼由AI生成，但人類工程師仍在審查、合并、測試。此時(shí)的復(fù)雜性依然可控，因?yàn)榇a量尚未爆炸。

但問題在于，這種“可控”是虛假的。

AI提升了局部效率 → 人類放棄對細(xì)節(jié)的掌控 → 系統(tǒng)失去概念完整性 → 集成成本呈指數(shù)級上升。

當(dāng)項(xiàng)目發(fā)展到某個(gè)臨界點(diǎn)，你會(huì)發(fā)現(xiàn)：總項(xiàng)目時(shí)長反而可能高于純?nèi)斯r(shí)代。那些被AI“節(jié)省”下來的時(shí)間，在后期會(huì)以幾倍甚至幾十倍的代價(jià)償還。

決策激進(jìn)派”的困局：決策的功利化

我也是《整潔架構(gòu)之道》的譯者，書中強(qiáng)調(diào)：“一個(gè)優(yōu)秀的架構(gòu)師，應(yīng)該讓系統(tǒng)在最大程度上推遲對細(xì)節(jié)的決策。”

但AI天生是“決策激進(jìn)派”。它不擅長“推遲決策”，它只擅長“立刻實(shí)現(xiàn)”。當(dāng)AI生成了數(shù)萬行耦合了具體實(shí)現(xiàn)的代碼后，那些原本應(yīng)該推遲到后期的決策，已經(jīng)永遠(yuǎn)被固化在了代碼庫里。

更諷刺的是，AI并非不知道這些原則。

你可以讓它“按照整潔架構(gòu)生成代碼”，它確實(shí)會(huì)把目錄結(jié)構(gòu)分成Application、Domain、Infrastructure。但只要深入看內(nèi)部實(shí)現(xiàn)，就會(huì)發(fā)現(xiàn)依賴方向依然混亂：Domain層的實(shí)體莫名其妙地依賴了ORM框架的注解，Use Case直接調(diào)用了具體的HTTP客戶端。

“黑箱”中的調(diào)試：心智模型的崩塌

當(dāng)生產(chǎn)事故來臨時(shí)，真正的噩夢才開始。

工程師試圖調(diào)試，卻發(fā)現(xiàn)代碼是一個(gè)“黑箱”。由于AI生成了大量非結(jié)構(gòu)化、充滿巧合性邏輯的代碼，人類無法通過傳統(tǒng)的靜態(tài)分析或單步調(diào)試來建立心智模型。

你無法理解AI為什么要在這里加一個(gè)看似無用的判斷，為什么要在這個(gè)類里引入那個(gè)看似不相干的方法，為什么要用這種奇怪的遞歸方式，但它就是“恰好”能跑通。

建立心智模型的成本已經(jīng)超過了人腦極限。你面對的不是代碼，而是一團(tuán)無法解開的邏輯毛線球。

這還不是最可怕的。

最隱蔽的災(zāi)難：失去下一代工程師

最可怕的是，由于AI接管了所有“臟活累活”，初級工程師失去了通過編寫CRUD、修復(fù)簡單Bug來建立“代碼直覺”的路徑。

十年前，每個(gè)新入職的程序員都要從寫最簡單的增刪改查開始，在一次次Bug修復(fù)中理解計(jì)算機(jī)的思維方式，在代碼審查中學(xué)習(xí)如何寫出可維護(hù)的代碼。

現(xiàn)在呢？AI幫他們完成了這一切。

十年后，世界上很可能沒有足夠多的人真正理解“計(jì)算機(jī)是如何在底層運(yùn)行的”。軟件工程會(huì)變成一個(gè)“召喚術(shù)”行業(yè)——大家都會(huì)念咒語（提示詞），但沒人懂魔法原理。

到那時(shí)，當(dāng)AI生成的代碼出錯(cuò)，當(dāng)系統(tǒng)需要深度優(yōu)化，當(dāng)安全漏洞需要修復(fù)——誰來解決問題？

《人月神話》的啟示：沒有銀彈

布魯克斯在《人月神話》中說過：“沒有銀彈。”

AI就是那顆看起來最像銀彈的東西。它讓我們相信，只要有一個(gè)足夠強(qiáng)大的AI，軟件工程的復(fù)雜性問題就能迎刃而解。

但恰恰相反。

AI生成的代碼如果缺乏概念完整性，它非但沒有減少工作量，反而通過制造“虛假的完成感”，將90%的工作量（維護(hù)、調(diào)試、集成）壓縮到了最后10%的時(shí)間里。

結(jié)果是：項(xiàng)目后期的“雪崩”比人力時(shí)代來得更猛烈、更突然。

《軟件設(shè)計(jì)的哲學(xué)》：被遺忘的智慧

在《軟件設(shè)計(jì)的哲學(xué)》中，奧斯特豪特強(qiáng)調(diào)了優(yōu)秀設(shè)計(jì)的核心：“讓簡單的事情簡單，讓復(fù)雜的事情隱藏。”

這就是“深度模塊”（Deep Modules）的價(jià)值，一個(gè)深度模塊有簡單的接口和復(fù)雜但隱藏的實(shí)現(xiàn)。它幫你隱藏復(fù)雜性，讓你專注于核心邏輯。

但AI的天性是反哲學(xué)的。它傾向于平鋪直敘地解決所有問題，把所有細(xì)節(jié)都暴露在外。結(jié)果是“深度模塊”的消亡，取而代之的是無數(shù)個(gè)“淺層模塊”（Shallow Modules）的堆砌。

每一個(gè)模塊看起來都很“簡單”，但你需要理解所有模塊才能理解整個(gè)系統(tǒng)。這不是簡化，這是復(fù)雜性的轉(zhuǎn)移和擴(kuò)散。

沒有“防御性”的代碼

另一個(gè)被忽視的問題是：AI生成的代碼缺乏“防御性編程”意識(shí)。

在《軟件設(shè)計(jì)的哲學(xué)》中，好的設(shè)計(jì)需要“防御性地”讓錯(cuò)誤顯而易見。人類程序員在寫代碼時(shí)，出于一種“不信任”的本能，會(huì)添加冗余斷言、異常處理、邊界檢查、容錯(cuò)機(jī)制，因?yàn)槲覀冎溃F(xiàn)實(shí)世界是不完美的，輸茹數(shù)據(jù)會(huì)出問題，依賴服務(wù)會(huì)掛掉，需求會(huì)變更。

但AI呢？為了通過測試用例，它會(huì)生成恰好通過測試的脆弱代碼。當(dāng)業(yè)務(wù)復(fù)雜度超出測試用例的覆蓋時(shí)，系統(tǒng)會(huì)以極其優(yōu)雅的方式崩壞——因?yàn)榇a太“精巧”了，精巧到?jīng)]有為任何意外情況留有余地。

如何駕馭混沌？

《人月神話》中有這樣一句話：“軟件工程中最困難的部分，是確定要構(gòu)建什么，以及確保構(gòu)建出的東西不會(huì)在構(gòu)建者心中留下一片混沌。”

AI正在放大這片混沌，除非我們學(xué)會(huì)用更深刻的哲學(xué)去駕馭它。

AI的能力確實(shí)在進(jìn)化，但AI本身沒有責(zé)任感，代碼的質(zhì)量保障仍然依賴于人。即使AI學(xué)習(xí)了《設(shè)計(jì)模式》和《整潔架構(gòu)之道》，最終的檢測和維護(hù)還是需要人工介入。而當(dāng)代碼量超過負(fù)荷后，這種檢測效果依然會(huì)大打折扣。

AI編程工具不是洪水猛獸，它們確實(shí)能提升效率、減少重復(fù)勞動(dòng)。但我們不能把它們當(dāng)作解決一切問題的“銀彈”。

在享受AI帶來的效率紅利時(shí)，我們需要保持清醒：

• 保持對細(xì)節(jié)的掌控——不要因?yàn)锳I能寫代碼就放棄理解代碼

• 重視概念完整性——確保系統(tǒng)有統(tǒng)一的設(shè)計(jì)哲學(xué)，而不是散亂的“戰(zhàn)術(shù)性代碼”

• 培養(yǎng)下一代工程師——讓他們從基礎(chǔ)做起，建立真正的代碼直覺

• 擁抱防御性編程——代碼不僅要能跑通，還要能應(yīng)對未知的錯(cuò)誤

• 投資于文檔和設(shè)計(jì)——AI不能替代人類的戰(zhàn)略思考

否則，我們建造的不是軟件，而是一座無人能懂的“巴比倫塔”。

來源 | 茹炳晟聊軟件研發(fā)（ID：gh_cdbee3a1ef29）

作者 | 茹炳晟+AI ; 編輯 | 呼呼大睡

內(nèi)容僅代表作者獨(dú)立觀點(diǎn)，不代表早讀課立場