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

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

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

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

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

這不是虛構場景。在AI編程工具普及的今天，這樣的困境正在無數開發團隊中悄然上演。

“復雜度”并未消失，只是轉移了

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

但事情沒那么簡單。

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

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

“大泥球”代碼的誕生

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

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

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

而AI，本質上就是極致版本的“戰術性編程”。AI沒有“戰略”，它只有“下一步”。

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

細節的爆炸：當“單一職責”走向極端

更隱蔽的問題是：AI導致了“超細粒度碎片化”。

舉個例子：原來一個類有5個方法，結構清晰，職責明確。現在，AI“優化”后生成了50個微小的輔助函數，每個只有三五行的代碼，因為它們“看起來更符合單一職責原則”。

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

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

這種碎片化帶來的不是靈活性，而是一場認知災難。

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

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

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

AI提升了局部效率 → 人類放棄對細節的掌控 → 系統失去概念完整性 → 集成成本呈指數級上升。

當項目發展到某個臨界點，你會發現：總項目時長反而可能高于純人工時代。那些被AI“節省”下來的時間，在后期會以幾倍甚至幾十倍的代價償還。

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

我也是《整潔架構之道》的譯者，書中強調：“一個優秀的架構師，應該讓系統在最大程度上推遲對細節的決策。”

但AI天生是“決策激進派”。它不擅長“推遲決策”，它只擅長“立刻實現”。當AI生成了數萬行耦合了具體實現的代碼后，那些原本應該推遲到后期的決策，已經永遠被固化在了代碼庫里。

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

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

“黑箱”中的調試：心智模型的崩塌

當生產事故來臨時，真正的噩夢才開始。

工程師試圖調試，卻發現代碼是一個“黑箱”。由于AI生成了大量非結構化、充滿巧合性邏輯的代碼，人類無法通過傳統的靜態分析或單步調試來建立心智模型。

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

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

這還不是最可怕的。

最隱蔽的災難：失去下一代工程師

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

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

現在呢？AI幫他們完成了這一切。

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

到那時，當AI生成的代碼出錯，當系統需要深度優化，當安全漏洞需要修復——誰來解決問題？

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

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

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

但恰恰相反。

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

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

《軟件設計的哲學》：被遺忘的智慧

在《軟件設計的哲學》中，奧斯特豪特強調了優秀設計的核心：“讓簡單的事情簡單，讓復雜的事情隱藏。”

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

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

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

沒有“防御性”的代碼

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

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

但AI呢？為了通過測試用例，它會生成恰好通過測試的脆弱代碼。當業務復雜度超出測試用例的覆蓋時，系統會以極其優雅的方式崩壞——因為代碼太“精巧”了，精巧到沒有為任何意外情況留有余地。

如何駕馭混沌？

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

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

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

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

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

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

• 重視概念完整性——確保系統有統一的設計哲學，而不是散亂的“戰術性代碼”

• 培養下一代工程師——讓他們從基礎做起，建立真正的代碼直覺

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

• 投資于文檔和設計——AI不能替代人類的戰略思考

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

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

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

內容僅代表作者獨立觀點，不代表早讀課立場