百度萝卜快跑集体趴窝：武汉高架堵了90分钟，乘客被困车内等救援

武汉三环线的高架上，李女士看着窗外一辆接一辆的货车呼啸而过，自己坐的无人车却像被按了暂停键。屏幕弹出提示：请留在车内，等待客服接入。这一等，就是90分钟。

这不是科幻片的片场故障，是4月8日发生在武汉的真实场景。百度旗下萝卜快跑（Apollo Go）的多辆无人车在同一时段集体停摆，造成局部交通瘫痪，部分乘客被困车内超过一小时。

系统宕机：无人车变成"路障"

武汉交警在官方微博通报，"多辆萝卜快跑车辆停在道路中央无法移动"。初步调查指向"系统故障"，但百度至今未对事件发表正式回应。

一位乘客向《连线》杂志描述了她的遭遇：行程中车辆停了四五次，最终在一处路口彻底锁死。车内屏幕循环播放着同一句话——等待公司代表上线。她花了30分钟才接通人工客服。

社交媒体上流传的视频显示，多辆白色无人车横亘在车道上，后方车辆被迫绕行。有目击者称，部分路段因此出现追尾事故。

当算法决定"安全第一"的方式是原地不动，乘客的安全感反而成了最先被牺牲的东西。

萝卜快跑的"武汉速度"

百度选择武汉作为萝卜快跑的核心运营城市，看中的是这里复杂的路况——高架桥密集、施工路段多、电动车穿行频繁。用产品经理的话说，"能在武汉跑通，全国都能复制"。

截至2024年初，萝卜快跑在武汉投放了超过500辆无人车，累计订单量突破300万单。百度宣称其"全无人"运营比例已达70%， meaning 每10辆车里有7辆彻底取消了安全员。

这次宕机暴露的正是这70%的脆弱性。没有安全员兜底，系统一旦掉线，车辆就变成了既不能自主移动、也无法人工接管的四吨重铁块。

一位自动驾驶工程师打了个比方：现在的无人车像"断网就死机的游戏机"，而理想的形态应该是"离线也能玩的掌机"。两者的差距，就是这次事故的核心矛盾。

行业通病：优雅降级还是硬着陆？

萝卜快跑不是第一个栽跟头的。2023年，通用汽车旗下的Cruise在旧金山发生类似事件，十几辆无人车同时瘫痪，造成数小时拥堵。最终Cruise被吊销运营许可，退出加州市场。

这些事故的共同点在于：系统设计时优先考虑"不出事"，而非"出事之后怎么办"。当传感器数据异常或云端连接中断，车辆默认选择停车等待——这在空旷路段是安全策略，在繁忙高架就是交通灾难。

百度内部人士曾透露，萝卜快跑的远程接管系统理论上能在30秒内响应。但4月8日的乘客反馈显示，实际等待时间远超这个阈值。是并发量过载？还是应急预案本身有漏洞？百度沉默。

技术公司喜欢讲"99.99%的可靠性"，但用户遭遇的永远是那0.01%。

监管与商业的赛跑

武汉是中国首批发放全无人运营牌照的城市之一。当地对自动驾驶的态度堪称激进：2023年一次性开放超过3000公里测试道路，允许全无人物流车、出租车同时上路。

这种"先跑起来再修规则"的模式，与加州形成鲜明对比。后者要求企业每月提交详细的安全报告，任何事故必须在10个工作日内公开披露。

截至目前，中国尚未建立统一的无人车事故披露标准。4月8日的宕机事件，若非乘客在社交媒体发声，外界可能完全无从知晓。百度选择冷处理，或许是认为"没有人员伤亡就不算大事"——但这种逻辑能撑多久？

一个值得注意的细节：萝卜快跑App在事件后悄悄更新了用户协议，新增条款称"因系统故障导致的行程中断，平台保留最终解释权"。