表面光鮮的代碼庫下，暗流涌動。

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

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

“代碼是AI寫的，但責(zé)任是我的?！毙⊥蹩嗌叵搿?/p>

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

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

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

但事情沒那么簡單。

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

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

“大泥球”代碼的誕生

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

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

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

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

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

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

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

舉個例子：原來一個類有5個方法，結(jié)構(gòu)清晰，職責(zé)明確?，F(xiàn)在，AI“優(yōu)化”后生成了50個微小的輔助函數(shù)，每個只有三五行的代碼，因為它們“看起來更符合單一職責(zé)原則”。

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

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

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

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

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

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

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

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

決策激進派”的困局：決策的功利化

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

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

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

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

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

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

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

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

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

這還不是最可怕的。

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

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

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

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

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

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

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

布魯克斯在《人月神話》中說過：“沒有銀彈?！?/p>

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

但恰恰相反。

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

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

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

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

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

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

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

沒有“防御性”的代碼

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

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

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

如何駕馭混沌？

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

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

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

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

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

• 保持對細(xì)節(jié)的掌控——不要因為AI能寫代碼就放棄理解代碼

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

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

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

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

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

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

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

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