【优快云 编者按】这不是又一篇唱衰科技的旧文，而是一份来自一线工程师的冷静诊断。随着抽象层叠加、AI 自动化和能源消耗激增，软件质量正在遭遇前所未有的系统性退化。从工具失控到开发者生态断层，问题并非单点，而是结构性塌陷。本文作者以犀利的视角揭露了技术体系的失控与开发文化的堕落，也重新提出一个被忽视已久的问题：我们如今的工程质量，足以支撑未来的整个数字世界吗？
原文链接：https://techtrenches.substack.com/p/the-great-software-quality-collapse
作者 | Denis Stetskov 翻译 | 郑丽媛
出品 | 优快云（ID：优快云news）
前阵子，不少 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 亿美元，只为让糟糕的软件继续运转……这都不是可持续发展的未来。
物理不会讲情面，能源不是无限的，硬件也有极限。
最终能活下来的公司，不是那些能花更多钱的，而是那些还记得如何真正“写代码”的人。
推荐阅读：
C++之父Bjarne Stroustrup亲临现场，2025全球C++及系统软件技术大会重磅官宣
扫一扫
3806
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
