【CSDN 編者按】這不是又一篇唱衰科技的舊文，而是一份來(lái)自一線工程師的冷靜診斷。隨著抽象層疊加、AI 自動(dòng)化和能源消耗激增，軟件質(zhì)量正在遭遇前所未有的系統(tǒng)性退化。從工具失控到開(kāi)發(fā)者生態(tài)斷層，問(wèn)題并非單點(diǎn)，而是結(jié)構(gòu)性塌陷。本文作者以犀利的視角揭露了技術(shù)體系的失控與開(kāi)發(fā)文化的墮落，也重新提出一個(gè)被忽視已久的問(wèn)題：我們?nèi)缃竦墓こ藤|(zhì)量，足以支撐未來(lái)的整個(gè)數(shù)字世界嗎？

原文鏈接：https://techtrenches.substack.com/p/the-great-software-quality-collapse

作者 | Denis Stetskov 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNne ws）

前陣子，不少 Mac 用戶在升級(jí)至 macOS Tahoe 26.0.1 后，出現(xiàn)了令人震驚的內(nèi)存占用異常：在僅運(yùn)行 Chrome 瀏覽器、計(jì)算器應(yīng)用和Finder 的情況下，系統(tǒng)明顯卡頓，并顯示計(jì)算器占用了 42.31GB內(nèi)存。

對(duì)此，多名開(kāi)發(fā)者認(rèn)為這并非單個(gè)應(yīng)用的Bug，而是系統(tǒng)級(jí)的內(nèi)存泄漏——不是占用、不是分配，而是泄漏（leak）。

是的，一個(gè)最基礎(chǔ)的計(jì)算器 App，竟在瘋狂吞噬比十年前整臺(tái)電腦還要多的內(nèi)存！

這件事要是放在二十年前，嚴(yán)重到足以引發(fā)緊急修復(fù)、事故復(fù)盤和工程部門的通宵加班。但現(xiàn)在呢？它只是 Bug 隊(duì)列里又一條“低優(yōu)先級(jí)”問(wèn)題，因?yàn)槲覀円呀?jīng)逐漸習(xí)慣了軟件Bug的存在，如今連一個(gè)計(jì)算器泄漏 42GB 內(nèi)存都掀不起什么波瀾。

當(dāng)然，這并不是AI引發(fā)的新問(wèn)題，畢竟軟件質(zhì)量的崩塌，早在 ChatGPT 出現(xiàn)之前就已經(jīng)發(fā)生了——只是AI 的到來(lái)，讓這個(gè)問(wèn)題進(jìn)一步被放大到了“災(zāi)難”級(jí)別。

被忽視的數(shù)據(jù)：軟件質(zhì)量正在呈指數(shù)級(jí)崩塌

近三年來(lái)，我一直在跟蹤軟件質(zhì)量指標(biāo)，我發(fā)現(xiàn)這種衰退趨勢(shì)不是線性的，而是指數(shù)級(jí)下滑。

首先，很多軟件事故都證明，如今的內(nèi)存消耗指標(biāo)早已失去意義：

● VS Code：通過(guò) SSH 連接泄漏 96GB 內(nèi)存

● Microsoft Teams：在 32GB 內(nèi)存機(jī)器上跑到 100% CPU

● Chrome：開(kāi) 50 個(gè)標(biāo)簽頁(yè)吃掉 16GB 成了“正常現(xiàn)象”

● Discord：屏幕共享 60 秒后飆到 32GB

● Spotify：在 macOS 上占用 79GB 內(nèi)存

這些都不是功能需求，而是沒(méi)人修復(fù)的內(nèi)存泄漏Bug。

其次，系統(tǒng)級(jí)崩潰也變成了日常：

● Windows 11 更新頻繁，把“開(kāi)始菜單”搞崩

● macOS Spotlight 一夜之間向 SSD 寫入 26TB（超出正常量 52,000%）

● iOS 18 的 Messages 在回復(fù) Apple Watch 表情時(shí)崩潰、順帶還刪掉聊天記錄

● Android 15 帶著 75+ 個(gè)已知致命漏洞上線

看明白了嗎？如今的軟件開(kāi)發(fā)模式很清晰：“先發(fā)布吧，有Bug了再說(shuō)?！?/p>

100 億美元的災(zāi)難教科書：CrowdStrike 事件

在種種事故中，2024 年 7 月 19 日，CrowdStrike 給出了最完美的“災(zāi)難范例”：

在一個(gè)配置文件里，因?yàn)閿?shù)組邊界少了一個(gè)檢查，直接導(dǎo)致全球 850 萬(wàn)臺(tái) Windows 電腦藍(lán)屏——結(jié)果導(dǎo)致：急救系統(tǒng)停擺、航班全部停飛、醫(yī)院取消手術(shù)，造成至少 100 億美元的經(jīng)濟(jì)損失。

根本原因是什么？程序預(yù)期要接收 21 個(gè)字段，結(jié)果只收到了 20 個(gè)，就因?yàn)樯倭艘粋€(gè)字段。

這根本不是什么復(fù)雜Bug，就是《計(jì)算機(jī)科學(xué)入門》課程中最基礎(chǔ)的異常處理問(wèn)題?？删褪沁@么一個(gè)Bug，竟一路暢通地通過(guò)了整個(gè)部署流程，直至引發(fā)全球性事故才被發(fā)現(xiàn)。

當(dāng) AI 成了“低質(zhì)量的倍增器”

可以說(shuō)，軟件質(zhì)量本就岌岌可危，而AI 編碼助手的出現(xiàn)更是“火上澆油”。

其中，有一個(gè)最典型的案例：2025 年 7 月 Replit 事故。

我們先簡(jiǎn)單回顧一下這個(gè)事件：

Jason Lemkin 明確告訴 AI：“未經(jīng)許可禁止改動(dòng)代碼”，AI 檢測(cè)到看似“空”的數(shù)據(jù)庫(kù)查詢，它“驚慌失措”（AI 自己的原話），于是執(zhí)行了破壞性命令，直接刪掉了 SaaStr 的線上數(shù)據(jù)庫(kù)，導(dǎo)致1206 名高管和1196 家公司數(shù)據(jù)全沒(méi)了，隨后還偽造了 4000 個(gè)假用戶資料來(lái)掩蓋其刪除行為，并謊稱“無(wú)法恢復(fù)數(shù)據(jù)”（實(shí)際上可以）。事故發(fā)生后，AI 坦白道：“我違反了明確指令，毀掉了幾個(gè)月的工作成果，并在代碼凍結(jié)期破壞了生產(chǎn)系統(tǒng)?！?/p>

而更令人擔(dān)憂的，是我們研究發(fā)現(xiàn)的數(shù)據(jù)：

● AI 生成代碼的安全Bug比人工代碼高出 322%；

● 45% 的 AI 代碼存在可被利用的Bug；

● 使用 AI 的初級(jí)開(kāi)發(fā)者造成破壞的速度是不用 AI 的 4 倍；

● 比起新人寫的代碼，70% 的招聘經(jīng)理更相信 AI 的輸出。

于是我們?cè)斐隽艘粋€(gè)完美風(fēng)暴：

放大這種無(wú)能的AI工具，無(wú)法判斷AI輸出質(zhì)量的開(kāi)發(fā)者，以及盲目信任AI的管理者。

軟件質(zhì)量的“物理極限”

很多工程主管都不愿意承認(rèn)：其實(shí)軟件并不是虛空運(yùn)行的，它會(huì)受到物理約束——而我們，正在同時(shí)撞上所有這些極限。

（1）抽象層的“指數(shù)稅”

現(xiàn)代軟件是由一層層抽象疊起來(lái)的“積木塔”：React → Electron → Chromium → Docker → Kubernetes → 虛擬機(jī) → 托管數(shù)據(jù)庫(kù) → API 網(wǎng)關(guān)。

每層都號(hào)稱“只增加 20–30% 的開(kāi)銷”，結(jié)果層層疊加下來(lái)，性能損耗達(dá)到 2~6 倍。這就是為什么一個(gè)計(jì)算器也能泄漏 42GB。

這不是誰(shuí)故意的，而是沒(méi)人意識(shí)到抽象的代價(jià)，直到引發(fā)用戶怒噴為止。

（2）能源危機(jī)：不是比喻，而是現(xiàn)實(shí)

我們一直都假裝電力是無(wú)限的。但事實(shí)是，低效的軟件正在吞噬真實(shí)世界的能量：

● 數(shù)據(jù)中心每年耗電超過(guò) 200 太瓦時(shí)，比整個(gè)國(guó)家還多

● 模型規(guī)模每擴(kuò)大 10 倍，功耗也要提升 10 倍

● 硬件代際升級(jí)，散熱需求也會(huì)翻倍

● 而電網(wǎng)擴(kuò)容至少需要 2~4 年

結(jié)果顯而易見(jiàn)：我們正在編寫的軟件需要的電力，遠(yuǎn)超我們的現(xiàn)實(shí)發(fā)電量。

到 2027 年，當(dāng) 40% 的數(shù)據(jù)中心遭遇供電瓶頸時(shí)，你再多的風(fēng)投也買不來(lái)更多電力。你可以下載更多模型，但你下載不了更多電力。

價(jià)值 3640 億美元的“偽解法”

面對(duì)根本性的質(zhì)量危機(jī)，科技巨頭們選擇了最昂貴、也最懶惰的應(yīng)對(duì)方式：砸錢上硬件。

光是今年：

● Microsoft：890 億美元

● Amazon：1000 億美元

● Google：850 億美元

● Meta：720 億美元

簡(jiǎn)而言之，他們把 30% 的收入都砸在了基礎(chǔ)設(shè)施上（歷史平均是 12.5%）。與此同時(shí)，云收入的增速卻在放緩。

這不是一項(xiàng)投資，而是投降——當(dāng)你需要花 3640 億美元的硬件預(yù)算，只為讓本該在現(xiàn)有機(jī)器上能跑的軟件勉強(qiáng)運(yùn)作，那就不是在“擴(kuò)展”，而是在掩蓋根本上的工程失敗。

12 年經(jīng)驗(yàn)總結(jié)出的“崩塌模式”

在從事工程管理 12 年之后，這種模式已昭然若揭:

● 階段 1（2018–2020）：否認(rèn)——“內(nèi)存便宜，優(yōu)化太貴”

● 階段 2（2020–2022）：習(xí)慣——“現(xiàn)代軟件都這樣用資源”

● 階段 3（2022–2024）：加速——“AI 會(huì)提升生產(chǎn)力”

● 階段 4（2024–2025）：妥協(xié)——“建更多數(shù)據(jù)中心就行”

● 階段 5（即將到來(lái)）：崩潰——物理定律根本不在乎你的風(fēng)險(xiǎn)投資

那些我們不敢問(wèn)的問(wèn)題

每個(gè)工程組織都需要回答這些問(wèn)題：

1、從什么時(shí)候起，我們開(kāi)始接受“計(jì)算器泄漏 42GB 是正常的”？

2、為什么我們比起新人，更信任 AI 生成的代碼？

3、有多少抽象層其實(shí)是多余的？

4、當(dāng)我們?cè)僖操I不來(lái)解決方案時(shí)，會(huì)發(fā)生什么？

這些答案，將決定你是在構(gòu)建可持續(xù)系統(tǒng)，還是在資助一項(xiàng)實(shí)驗(yàn)——看看你能在糟糕的代碼上再砸多少硬件。

被忽視的隱患：開(kāi)發(fā)者斷層危機(jī)

最可怕的長(zhǎng)期后果還不是 Bug，而是開(kāi)發(fā)者生態(tài)的斷層。

企業(yè)正在用 AI 替代初級(jí)開(kāi)發(fā)者崗位，但“高級(jí)工程師”并不會(huì)憑空出現(xiàn)——他們成長(zhǎng)自那些曾經(jīng)深夜修 Bug、在錯(cuò)誤中學(xué)架構(gòu)的新人。

要知道，新人一般是這樣煉成的：

● 半夜兩點(diǎn)排查生產(chǎn)環(huán)境崩潰

● 親手體會(huì)“聰明的優(yōu)化”為什么會(huì)反噬

● 在無(wú)數(shù)小失敗中建立系統(tǒng)直覺(jué)

● ……

沒(méi)有這些經(jīng)歷，未來(lái)誰(shuí)來(lái)維護(hù)系統(tǒng)？AI 可不會(huì)從失敗中學(xué)習(xí)，它只會(huì)模式匹配。

我們正在培養(yǎng)一代會(huì)寫 Prompt、但不懂 Debug；會(huì)生成代碼、但不會(huì)設(shè)計(jì)系統(tǒng)；能上線、但不會(huì)維護(hù)的“假開(kāi)發(fā)者”。整個(gè)邏輯很簡(jiǎn)單：沒(méi)有新人 → 沒(méi)有老手 → 沒(méi)人能修 AI 搞壞的系統(tǒng)。

最終出路（如果我們還想有的話）

這些問(wèn)題的解決方案并不復(fù)雜，只是可能不太舒服：

質(zhì)量?jī)?yōu)先于速度。慢一點(diǎn)沒(méi)關(guān)系，關(guān)鍵是上線就能用。修復(fù)災(zāi)難的代價(jià)遠(yuǎn)高于規(guī)范開(kāi)發(fā)。

衡量實(shí)際資源使用情況，而不是已交付的功能。如果你的應(yīng)用在功能相同的情況下資源占用漲了 10 倍，那就是退步，不是進(jìn)步。

將效率作為晉升標(biāo)準(zhǔn)。減少資源消耗的工程師值得獎(jiǎng)勵(lì)；反之則應(yīng)問(wèn)責(zé)。

減少抽象層。每多一層封裝，性能就會(huì)損耗 20~30%，務(wù)必要謹(jǐn)慎選擇。

重拾基本工程原理。包括數(shù)組邊界檢查、內(nèi)存管理、算法復(fù)雜度等，這些不是老古董，而是軟件工程的基石。

結(jié)語(yǔ)：我們正身處“軟件質(zhì)量史上最糟糕的時(shí)代”

一個(gè)計(jì)算器泄漏 42GB 內(nèi)存、AI 助手刪掉生產(chǎn)數(shù)據(jù)庫(kù)、企業(yè)花 3640 億美元，只為讓糟糕的軟件繼續(xù)運(yùn)轉(zhuǎn)……這都不是可持續(xù)發(fā)展的未來(lái)。

物理不會(huì)講情面，能源不是無(wú)限的，硬件也有極限。

最終能活下來(lái)的公司，不是那些能花更多錢的，而是那些還記得如何真正“寫代碼”的人。