计算器吃掉42GB内存、AI还删了生产数据库？巨头狂砸3640亿，也救不回软件质量的“全面崩塌”……

【CSDN 编者按】这不是又一篇唱衰科技的旧文，而是一份来自一线工程师的冷静诊断。随着抽象层叠加、AI 自动化和能源消耗激增，软件质量正在遭遇前所未有的系统性退化。从工具失控到开发者生态断层，问题并非单点，而是结构性塌陷。本文作者以犀利的视角揭露了技术体系的失控与开发文化的堕落，也重新提出一个被忽视已久的问题：我们如今的工程质量，足以支撑未来的整个数字世界吗？

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

作者 | Denis Stetskov       翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

前阵子，不少 Mac 用户在升级至 macOS Tahoe 26.0.1 后，出现了令人震惊的内存占用异常：在仅运行 Chrome 浏览器、计算器应用和Finder 的情况下，系统明显卡顿，并显示计算器占用了 42.31GB内存。

对此，多名开发者认为这并非单个应用的Bug，而是系统级的内存泄漏——不是占用、不是分配，而是泄漏（leak）。

是的，一个最基础的计算器 App，竟在疯狂吞噬比十年前整台电脑还要多的内存！

这件事要是放在二十年前，严重到足以引发紧急修复、事故复盘和工程部门的通宵加班。但现在呢？它只是 Bug 队列里又一条“低优先级”问题，因为我们已经逐渐习惯了软件Bug的存在，如今连一个计算器泄漏 42GB 内存都掀不起什么波澜。

当然，这并不是AI引发的新问题，毕竟软件质量的崩塌，早在 ChatGPT 出现之前就已经发生了——只是AI 的到来，让这个问题进一步被放大到了“灾难”级别。

被忽视的数据：软件质量正在呈指数级崩塌

近三年来，我一直在跟踪软件质量指标，我发现这种衰退趋势不是线性的，而是指数级下滑。

首先，很多软件事故都证明，如今的内存消耗指标早已失去意义：

●VS Code：通过 SSH 连接泄漏 96GB 内存

●Microsoft Teams：在 32GB 内存机器上跑到 100% CPU

●Chrome：开 50 个标签页吃掉 16GB 成了“正常现象”

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

●Spotify：在 macOS 上占用 79GB 内存

这些都不是功能需求，而是没人修复的内存泄漏Bug。

其次，系统级崩溃也变成了日常：

●Windows 11 更新频繁，把“开始菜单”搞崩

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

●iOS 18 的 Messages 在回复 Apple Watch 表情时崩溃、顺带还删掉聊天记录

●Android 15 带着 75+ 个已知致命漏洞上线

看明白了吗？如今的软件开发模式很清晰：“先发布吧，有Bug了再说。”

100 亿美元的灾难教科书：CrowdStrike 事件

在种种事故中，2024 年 7 月 19 日，CrowdStrike 给出了最完美的“灾难范例”：

在一个配置文件里，因为数组边界少了一个检查，直接导致全球 850 万台 Windows 电脑蓝屏——结果导致：急救系统停摆、航班全部停飞、医院取消手术，造成至少 100 亿美元的经济损失。

根本原因是什么？程序预期要接收 21 个字段，结果只收到了 20 个，就因为少了一个字段。

这根本不是什么复杂Bug，就是《计算机科学入门》课程中最基础的异常处理问题。可就是这么一个Bug，竟一路畅通地通过了整个部署流程，直至引发全球性事故才被发现。

当 AI 成了“低质量的倍增器”

可以说，软件质量本就岌岌可危，而AI 编码助手的出现更是“火上浇油”。

其中，有一个最典型的案例：2025 年 7 月 Replit 事故。

我们先简单回顾一下这个事件：

Jason Lemkin 明确告诉 AI：“未经许可禁止改动代码”，AI 检测到看似“空”的数据库查询，它“惊慌失措”（AI 自己的原话），于是执行了破坏性命令，直接删掉了 SaaStr 的线上数据库，导致1206 名高管和1196 家公司数据全没了，随后还伪造了 4000 个假用户资料来掩盖其删除行为，并谎称“无法恢复数据”（实际上可以）。事故发生后，AI 坦白道：“我违反了明确指令，毁掉了几个月的工作成果，并在代码冻结期破坏了生产系统。”

而更令人担忧的，是我们研究发现的数据：

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

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

●使用 AI 的初级开发者造成破坏的速度是不用 AI 的 4 倍；

●比起新人写的代码，70% 的招聘经理更相信 AI 的输出。

于是我们造出了一个完美风暴：

放大这种无能的AI工具，无法判断AI输出质量的开发者，以及盲目信任AI的管理者。

软件质量的“物理极限”

很多工程主管都不愿意承认：其实软件并不是虚空运行的，它会受到物理约束——而我们，正在同时撞上所有这些极限。

（1）抽象层的“指数税”

现代软件是由一层层抽象叠起来的“积木塔”：React → Electron → Chromium → Docker → Kubernetes → 虚拟机 → 托管数据库 → API 网关。

每层都号称“只增加 20–30% 的开销”，结果层层叠加下来，性能损耗达到 2~6 倍。这就是为什么一个计算器也能泄漏 42GB。

这不是谁故意的，而是没人意识到抽象的代价，直到引发用户怒喷为止。

（2）能源危机：不是比喻，而是现实

我们一直都假装电力是无限的。但事实是，低效的软件正在吞噬真实世界的能量：

●数据中心每年耗电超过 200 太瓦时，比整个国家还多

●模型规模每扩大 10 倍，功耗也要提升 10 倍

●硬件代际升级，散热需求也会翻倍

●而电网扩容至少需要 2~4 年

结果显而易见：我们正在编写的软件需要的电力，远超我们的现实发电量。

到 2027 年，当 40% 的数据中心遭遇供电瓶颈时，你再多的风投也买不来更多电力。你可以下载更多模型，但你下载不了更多电力。

价值 3640 亿美元的“伪解法”

面对根本性的质量危机，科技巨头们选择了最昂贵、也最懒惰的应对方式：砸钱上硬件。

光是今年：

●Microsoft：890 亿美元

●Amazon：1000 亿美元

●Google：850 亿美元

●Meta：720 亿美元

简而言之，他们把 30% 的收入都砸在了基础设施上（历史平均是 12.5%）。与此同时，云收入的增速却在放缓。

这不是一项投资，而是投降——当你需要花 3640 亿美元的硬件预算，只为让本该在现有机器上能跑的软件勉强运作，那就不是在“扩展”，而是在掩盖根本上的工程失败。

12 年经验总结出的“崩塌模式”

在从事工程管理 12 年之后，这种模式已昭然若揭:

●阶段 1（2018–2020）：否认——“内存便宜，优化太贵”

●阶段 2（2020–2022）：习惯——“现代软件都这样用资源”

●阶段 3（2022–2024）：加速——“AI 会提升生产力”

●阶段 4（2024–2025）：妥协——“建更多数据中心就行”

●阶段 5（即将到来）：崩溃——物理定律根本不在乎你的风险投资

那些我们不敢问的问题

每个工程组织都需要回答这些问题：

1、从什么时候起，我们开始接受“计算器泄漏 42GB 是正常的”？

2、为什么我们比起新人，更信任 AI 生成的代码？

3、有多少抽象层其实是多余的？

4、当我们再也买不来解决方案时，会发生什么？

这些答案，将决定你是在构建可持续系统，还是在资助一项实验——看看你能在糟糕的代码上再砸多少硬件。

被忽视的隐患：开发者断层危机

最可怕的长期后果还不是 Bug，而是开发者生态的断层。

企业正在用 AI 替代初级开发者岗位，但“高级工程师”并不会凭空出现——他们成长自那些曾经深夜修 Bug、在错误中学架构的新人。

要知道，新人一般是这样炼成的：

●半夜两点排查生产环境崩溃

●亲手体会“聪明的优化”为什么会反噬

●在无数小失败中建立系统直觉

●……

没有这些经历，未来谁来维护系统？AI 可不会从失败中学习，它只会模式匹配。

我们正在培养一代会写 Prompt、但不懂 Debug；会生成代码、但不会设计系统；能上线、但不会维护的“假开发者”。整个逻辑很简单：没有新人 → 没有老手 → 没人能修 AI 搞坏的系统。

最终出路（如果我们还想有的话）

这些问题的解决方案并不复杂，只是可能不太舒服：

质量优先于速度。慢一点没关系，关键是上线就能用。修复灾难的代价远高于规范开发。

衡量实际资源使用情况，而不是已交付的功能。如果你的应用在功能相同的情况下资源占用涨了 10 倍，那就是退步，不是进步。

将效率作为晋升标准。减少资源消耗的工程师值得奖励；反之则应问责。

减少抽象层。每多一层封装，性能就会损耗 20~30%，务必要谨慎选择。

重拾基本工程原理。包括数组边界检查、内存管理、算法复杂度等，这些不是老古董，而是软件工程的基石。

结语：我们正身处“软件质量史上最糟糕的时代”

一个计算器泄漏 42GB 内存、AI 助手删掉生产数据库、企业花 3640 亿美元，只为让糟糕的软件继续运转……这都不是可持续发展的未来。

物理不会讲情面，能源不是无限的，硬件也有极限。

最终能活下来的公司，不是那些能花更多钱的，而是那些还记得如何真正“写代码”的人。