抖音崩完淘宝崩，AI和裁员的代价开始到来

这一周堪称软件崩溃周。

抖音、猫耳FM、扇贝单词、淘宝接连出现系统故障，带着产品轮番上热搜。

而真相是，从2025年下半年至今，主流App“崩了”从偶发新闻变成行业常态。

孤立的技术越来越多，那就必有隐情。

01

大厂系统集体进入“脆弱期”

9月3日，不少用户发现淘宝出现订单页无法打开、页面集中报错的问题，随后客服回应称“系统出现一点问题，现在已经恢复”。

光看这件事，虽然会让人觉得不应该发生——毕竟淘宝也算是从PC互联网时代就开始做的基础设施了，但也不至于觉得过于离谱。

但问题是，这已经是短短三天内，第四起冲上热搜的互联网平台故障。

就在前一天，扇贝单词被曝页面转圈加载、验证码收不到、学习权益加载失败，官方承诺修复后补偿打卡用户；9月1日，猫耳FM App和网页端的首页、播放、直播、已购等页面集中报错；再往前两天的8月31日，抖音推荐系统突发异常，大量用户被推送完全不感兴趣的内容，还伴随播放卡顿和无网络提示。

你方唱罢我登场，但这戏却不是什么好戏。

比较值得关注的是抖音，作为移动互联网时代异军突起的黑马，靠着大数据和算法建立起了生态壁垒，可是在2026年以来，已经三次因系统故障登上热搜：

1月29日，搜索结果出现空白或长时间加载，仅核心推荐流正常；8月11日，直播间人数、弹幕、福袋、私信、作品发布等功能全面异常，连客服页面都排队99+。平均每三个月一次的公开故障，让它的的系统稳定性备受质疑。

但如果拉长时间线看，这股“崩溃潮”其实早在2025年下半年就已经开始。

从2025年9月到2026年9月的整整一年间，仅登上热搜的大型App故障就超过10起：2025年9月美团商家详情页无法加载、用户无法正常下单；同年10月小红书页面卡顿、内容无法刷新，知乎同步出现登录异常；2026年开年，汉堡王、肯德基先后因活动流量过大，出现App和小程序无法下单、支付异常等问题；2月千问因30亿免单活动挤爆服务入口，官方紧急加派资源。

这还只是热度足够出圈的故障，那些没登上热搜的局部功能异常、区域服务波动、业务线小故障更是数不胜数。

曾经“某App崩了”是足以刷屏的大新闻，如今却成了网友习以为常的调侃。

02

被砍掉的冗余，正是稳定的护城河

为什么偏偏是这两年，互联网系统突然变得“脆弱”了？

因为系统稳定性本身，就是一件非常“反人性”的事：做得越好，越像一群人什么都没干。服务器预留出冗余容量，闲时看起来是资源浪费；两套灾备系统平时只跑一套，看起来是重复投入；熟悉全链路的运维工程师每天处理不了几个紧急需求，看起来更是“闲人”。

尤其在现代公司体系里，财务报表上这些都是清清楚楚的显性成本；而“避免了多少次全站故障”、“扛过了多少次流量峰值”，却是看不见、难量化的隐性收益。

当互联网行业从高速扩张转向降本增效，这些“产出不直观”的岗位和投入，就成了先被开刀的对象。

过去两年行业持续裁员，有一个非常清晰的倾向：能做业务增长、能讲AI故事、能拉新做活动的团队更容易被保留；而负责老系统维护、监控告警、全链路压测、发布审核、灾备演练的团队，往往被归为“支持部门”、“非核心岗位”，要么缩编，要么外包。

短期来看，这笔账算得很划算：砍掉一批“非核心”人力，成本能下降，而且系统不会在裁员当天就崩溃。

但隐患会在之后的几个月里慢慢发酵。

很多看似“突然爆发”的故障，都能追溯到发布或配置环节。以前有严格的发布审核、灰度验证、快速回滚机制，小错误能被及时拦截；当发布流程简化、代码评审变薄、值班人手不足，一个参数改错、一条网关规则更新失误，就可能直接引发全站异常，故障发现和恢复的速度也会大打折扣。

还有订单、支付这类核心链路故障，往往是某一个依赖环节超时，前端就大面积报错。这类问题的预防，需要对全链路每个环节都做容量评估和降级预案；当运维和测试团队收缩，没人再去梳理复杂的依赖关系，一个环节出问题就会顺着链路传导到前端。

更隐蔽的是“重试风暴”。一个小故障导致客户端和下游服务不断重试，请求量在几分钟内被放大数倍，把原本正常的服务也拖下水。要避免这种雪崩效应，需要提前做好限流、熔断、降级策略。

而这些“防患于未然”的工作，恰恰容易在降本中被当成“无用投入”砍掉。

很多活动引发的崩溃就是例子。汉堡王代言人礼盒、肯德基促销活动、千问30亿免单，表面看是“瞬时流量太大超出预期”，本质上都是容量评估失误、弹性扩容机制失效、降级预案缺失。

但带来代价的潘多拉魔盒，不止这一个。

03

AI提效的幌子

更值得玩味的是，这一轮稳定性收缩，恰好和AI浪潮完全叠加。

很多大厂都把“AI提效”当成了裁员的合理外衣——宣称用AI可以实现自动化运维、智能测试、自动容量规划，因此不再需要那么多工程师。

但从实际落地效果来看，AI在系统稳定性领域的作用，目前还很有限。

AI可以处理标准化的告警聚合、做简单的日志关键词分析，但面对复杂的分布式链路故障、突发的非常规流量、跨系统的兼容性问题，AI根本替代不了熟悉业务的资深工程师。

真正的故障根因排查、全链路容量规划、跨团队灾备演练，高度依赖对业务逻辑的深度理解和长期的经验积累，这些都是AI短期内无法覆盖的场景。

所谓的“AI提效”，更多是把最简单、最重复的机械工作自动化了，然后企业以此为借口砍掉对应的人力岗位。

剩下的工程师要承接更多业务需求，还要兼管稳定性维护，结果就是没人愿意再投入精力做“锦上添花”的灾备建设、冗余扩容、压测演练——毕竟这些工作做了也没有显性产出，出了问题却要直接背锅。

换句话说，正是因为AI只是一个幌子，才让提效没有按照外界的剧本一样发生。

于是行业就形成了一个恶性循环：用AI的名义降本裁员→稳定性投入持续不足→小隐患演变成大事故→紧急修复后继续压缩成本。用户端感受到的，就是App崩得越来越频繁，故障恢复时间越来越长，官方通报的原因越来越模糊。

这次淘宝故障，大概率依然会以一句“系统异常，现已恢复”收尾，不会有详细的根因说明和改进方案。

毕竟对企业来说，承认一次技术失误很容易，承认是降本裁掉了关键岗位、透支了系统稳定性，才是更难开口的事。

但从目前的行业趋势看，降本依然是互联网公司的核心主线，AI的故事也还会继续讲下去。只是普通用户需要慢慢习惯，那些曾经追求99.99%可用性的互联网服务们，将会一点点降低容错标准。