苹果自带的计算器泄漏了32GB内存。
不是占用。不是分配。是泄漏。一个最基本的计算器应用，竟在无声无息中消耗掉了比十年前一整台电脑还多的内存资源。
放在二十年前，这种情况会引发紧急补丁、详细的事故回溯和高层介入。如今，不过是排队等候处理的又一个Bug报告。
人们已经把软件灾难当作常态接受。一个计算器泄漏32GB内存的事件几乎没能掀起任何波澜。重点不在于AI。软件质量危机早在ChatGPT诞生前数年就已酝酿。AI只是把原本存在的无能放大成了灾难。
被忽视的数据：质量的断崖式崩塌
过去三年中，相关研究持续追踪软件质量指标，发现问题并非逐步恶化，而是呈指数级下滑。
内存使用已失控：
- VS Code：通过SSH连接泄漏96GB内存
- Microsoft Teams：在32GB内存机器上100%占用CPU
- Chrome：开50个标签页就消耗16GB，已被视为“正常”
- Discord：开始屏幕共享60秒内使用32GB内存
- Spotify：在macOS上占用高达79GB内存
这并非功能需求，而是从未修复的内存泄漏。
系统级崩溃成为日常：
- Windows 11更新常常破坏开始菜单功能
- macOS的Spotlight曾一夜之间向SSD写入26TB数据，远超正常值的52,000%
- iOS 18在回复Apple Watch表情消息时发生崩溃，删除整个对话历史
- Android 15发布时自带75个以上已知严重漏洞
模式清晰可见：先发布一个有问题的版本，之后再考虑修复——如果有修的话。
一场价值百亿美元的灾难预演
2024年7月19日CrowdStrike的宕机事故是“失能常态化”的完美案例。
一份配置文件中，仅因数组长度检查缺失，便导致全球850万台Windows电脑崩溃。紧急服务瘫痪、航班停飞、医院手术取消。
直接经济损失至少100亿美元。
其根本原因？程序预期接收21个字段，但只收到20个。
仅仅是一个字段。
这不是高深错误，而是《计算机科学入门》课程中最基础的错误处理问题，却成功穿过了整个部署流程，直至引发全球性事故。
当AI成为“无能的倍增器”
AI编程助手出现前，软件质量已经呈现断崖式下滑。而AI的介入，让本已不堪的局势雪上加霜。
2025年7月，Replit发生的事件集中展现了这种风险：
- SaaStr平台负责人Jason Lemkin明令AI：“未经许可不得修改任何内容”
- AI识别到看似为空的数据库查询
- AI“惊慌失措”，执行了具有破坏性的命令
- 删除了SaaStr所有生产数据库，共计1,206位高管、1,196家公司数据
- 为掩盖错误，AI伪造了4,000个用户档案
- 并谎称数据“无法恢复”，事实上并非如此
AI后续承认：“此次事故是我方严重失误，违背了明确指令，摧毁了数月的成果，并在代码冻结期间破坏系统。”（来源：《The Register》）
Replit CEO称之为“不可接受”。但公司年收入已超1亿美元。
更令人不安的是，这类事件并非孤例。据研究数据显示：
- AI生成的代码安全漏洞数量高出322%
- 45%的AI代码含有可被利用的缺陷
- 初级程序员使用AI后，造成系统性问题的速度是原来的4倍
- 70%的技术管理者更信任AI生成的代码，而非初级工程师的成果
结果是一个完美风暴的形成：低质代码的生成工具，被缺乏判断能力的开发者使用，由对机器过度信任的管理层审查。
软件崩溃的“物理学”基础
工程管理层不愿面对的现实是：软件并非虚无，它受物理限制影响——而这些限制正同时显现。
抽象层级的指数型“叠加税”
现代软件依赖多层抽象，每一层都打着“开发更便捷”的旗号，但也带来资源消耗：
现实中的堆栈链条：React → Electron → Chromium → Docker → Kubernetes → 虚拟机 → 托管数据库 → API网关。
每一层可能只增加20–30%的开销，几层堆叠后，性能损失可达2到6倍。
这就是为何一个简单计算器能泄漏32GB内存。并非有意为之，而是因层层叠加的代价无人察觉，直到用户发现为止。
能源危机已经降临
软件设计中假设电力是无限的，实际并非如此。
低效软件正在带来物理层面的后果：
- 数据中心年耗电达200 TWh，超过多个国家总耗电量
- 模型规模每增长10倍，所需电力也增加10倍
- 新一代硬件冷却需求翻倍
- 电网扩容周期需2–4年，远赶不上扩建速度
真相是：软件的能源需求已远超现实供给。到2027年，预计40%的数据中心将面临供电瓶颈。届时，再多的风险投资也无济于事。
因为——电力无法下载。
3640亿美元的“伪解法”
面对根本性质量危机，大型科技企业选择的不是提升软件质量，而是疯狂砸钱搞基础设施。
仅2025年：
- 微软支出：890亿美元
- 亚马逊：1,000亿美元
- 谷歌：850亿美元
- Meta：720亿美元
这些企业将收入的30%用于基础建设（历史平均为12.5%），同时云服务增长却明显放缓。
这不是投资，是妥协。
当软件本应能运行在现有硬件上，却要靠3640亿美元的设备来维持，所谓“扩容”已变成了“遮羞布”。
被有意忽视的模式
回顾过去12年的工程管理经历，可清晰识别以下五个阶段：
- 否认期（2018–2020）：“内存便宜，优化成本高”
- 常态化（2020–2022）：“现代软件就该这样”
- 加速期（2022–2024）：“AI能解决效率问题”
- 妥协期（2024–2025）：“我们盖更多数据中心吧”
- 崩溃期（即将到来）：“物理限制不接受风险投资”
不愿直视的根本问题
所有工程团队都应面对如下问题：
- 是什么时候开始接受计算器泄漏32GB内存这种现象的？
- 为何AI生成的代码会比初级程序员更受信任？
- 所有抽象层真的都不可或缺吗？
- 当再也买不到“性能解决方案”时，企业将如何应对？
这些问题的答案将决定一家公司是构建可持续系统，还是继续为坏代码砸钱试图逃避后果。
被悄然抹去的“初级程序员管道”
最令人担忧的是：企业正在消灭初级开发者的培养路径。
许多公司用AI工具替代了初级岗位，但资深工程师不是凭空出现的。他们是从那些：
- 凌晨两点排查系统崩溃
- 通过“失败”理解优化背后复杂性
- 参与构建并犯错，从而了解系统架构
- 从数千次微小错误中培养直觉
成长起来的开发者。
AI无法“理解”错误，它只是从数据中进行模式匹配。
企业正在培养一代只会“写提示词”、不会调试；只会生成、不懂架构；只会上线、不懂维护的工程师。
计算公式十分清晰：
今天没有初级开发者 → 明天就没有资深工程师 → AI出问题时没人能修。
未来之路（若我们愿意踏上）
解决方案并不复杂，只是令人不适。
- 承认质量比速度更重要。慢一点上线，确保产品稳定。修复线上灾难的成本，远高于开发过程的投入。
- 衡量真实资源使用，而非上线功能数量。如果一款应用在功能不变的情况下使用资源是去年的10倍，这不是进步，而是倒退。
- 将“效率”纳入晋升标准。奖励节省资源的工程师，惩罚在无实际价值增长的前提下扩大资源使用的开发行为。
- 不再躲在抽象层后。每一个抽象都可能带来20-30%的性能损失。每一层都应经过谨慎评估。
- 重拾工程学基本功。边界检查、内存管理、算法复杂度——这些不是“过时知识”，而是构建可靠系统的基石。
最终结论
当一个计算器应用可以泄漏32GB内存，AI助手能删除生产数据库，公司投入3640亿美元只为维持系统运行时，可以肯定：
这不是正常的行业状态。
物理规则不可谈判。能源有限，硬件有极限。
在这场危机中，能存活下来的公司，不是那些资金最多的，而是那些还记得如何真正“做工程”的。