【萝卜快跑集体“脑死亡”：自动驾驶不能用公共道路当试验田】

快速阅读： 2026年3月31日晚，武汉近百辆萝卜快跑无人车集体瘫痪，停在高架和主干道上，乘客被困近两小时，多车追尾。故障暴露了自动驾驶系统缺乏本地冗余备份的结构性缺陷，以及应急响应机制的严重失位。

---

高架桥上，一个人坐在停止的无人车里，车门能开，但不敢下。外面是时速一百公里的车流。屏幕上写着“系统异常”。SOS按了没反应，客服电话永远占线。

这不是科幻小说的情节。这是3月31日晚上，武汉，真实发生的事。

近百辆萝卜快跑在二环、三环、白沙洲大桥等主干道上几乎同时熄火停驶，并排堵在最左侧车道，三股道压成一股。有网友描述白沙洲大桥堵出了“猪肝红”。一辆坦克300躲避不及，右前悬直接撞废。交警最后挨个车去敲门救人。

武汉交警通报：系统故障，无人员伤亡。

“系统故障”这四个字很好用，能解释一切，也能掩盖一切。

真正值得追问的不是“为什么出故障”，而是“为什么一出故障就是百辆同时趴窝”。答案其实并不复杂：这套系统过度依赖云端控制，本地没有冗余备份机制。后台一旦断线，车队就集体失去大脑，像进程全部阻塞的操作系统，没有任何一个线程能独立恢复。

单点失败，全军覆没。这在分布式系统设计里是最基础的反模式，任何一本教科书都会告诉你不能这么做。

有网友提到，SOS按钮形同虚设，客服需要乘客提供车牌号才能受理，而乘客根本不知道自己坐的是哪辆车。整个应急链条在最需要它的时刻完全失灵。萝卜快跑事后的回应是“网络原因”，没有道歉，没有赔偿方案。那辆被追尾的坦克300，车主的损失至今不明。

有观点认为，故障是技术迭代的必经过程，不应因此否定自动驾驶的前景。这话本身没错，问题在于，在公共高架桥上让乘客坐在停滞车厢里等两小时，这不叫“迭代”，叫把风险外包给用户。

商业化运营和内部测试的区别就在这里。测试可以接受失败，运营必须保障兜底。萝卜快跑在武汉已经跑了不止一年，2024年就出过雷雨停运、障碍物识别失误等问题，当时客服的回应是“测试阶段”。现在还在用同一套话语框架吗？

公众不是在要求自动驾驶不能出错。出错可以。但出错之后，车得能停在安全位置，乘客得能联系到人，救援得在二十分钟内到位。这些不是高标准，是基本门槛。

监管部门现在面对的问题是：要不要强制要求本地化冗余机制？要不要明确“物理接管权限”，比如在紧急情况下允许交警直接断电？这些问题如果还停留在讨论阶段，下一次趴窝的现场，大概还是一样的收场方式：交警挨个敲车门，企业发一条“网络原因”的声明。

那个被困在三环高架上的乘客说，车开到辅道之后他还是不敢下去。“在高架上，下车了也不知道该往哪里走。”

这句话说的是那晚的处境，也说的是整个行业现在的位置。

#武汉多辆萝卜快跑出故障##交警通报萝卜快跑行驶中突然停车#