就在前天,(3月31日晚)武汉百度「萝卜快跑」自动驾驶车辆大面积集体停摆 ,具体情况信息如下:
⏰ 时间与范围
- 时间:2026-03-31 20:57起(晚高峰后)
- 地点:武汉全城主干道、高架、桥梁
- 二环线、三环线、杨泗港长江大桥、白沙洲高架、雄楚高架、月湖桥等
- 规模:约 80~100台 萝卜快跑同时停在路中央
![]()
![]()
事发经过
1. 车辆行驶中先卡顿,突然急刹停在车道中间,无法进退
2. 屏幕提示:系统异常,请留在车内
3. 车门可手动开,但多在高架/快车道,乘客不敢下车
4. SOS/客服响应慢、占线、接通后只说网络异常
5. 造成严重拥堵、少量追尾剐蹭
6. 乘客多被困 30分钟~2小时,靠交警徒步上高架疏散
7. 无人员伤亡
官方通报(武汉交警 4月1日凌晨)
初步判断为系统故障所致,所有乘客已安全下车,无人员受伤,具体原因正在调查
业内与舆论分析(主流观点)
- 高度依赖云端/中心化调度:本地失效安全(Fail-safe)缺失
- 不是单车硬件问题,而是云端/服务器/软件/网络级故障
- 触发最小风险策略但执行错误:直接停路中,不是靠边
- 暴露L4级无人车大规模商业化的安全短板
✅ 最新进展
- 4月1日凌晨已全部清场、交通恢复
- 萝卜快跑尚未发布详细技术原因说明。
本次事件的反思
L4自动驾驶关键安全缺陷(从本次事件总结)
1. 云端强依赖,无网/服务器崩=全车瘫痪
- 车辆高度依赖云端调度、地图、算力,不是纯本地决策
- 云端一出问题,车辆直接进入安全降级失效
- 未做到断网仍能安全靠边停车
2. 失效安全策略(Fail-Safe)设计严重错误
- 系统异常后的默认动作:直接刹停在车道中央
- 正确安全逻辑应是:
缓慢减速 → 打灯 → 靠边 → 停车
- 把车停在高架主路、快车道,属于安全设计事故
3. 大规模并发故障,无冗余与隔离机制
- 不是单台车问题,是全城同批车辆同时故障
- 说明系统缺乏分区、冗余、熔断机制
- 单点故障直接引发区域性瘫痪
4. 远程接管能力失效
- 出现异常后远程人工接管不可用
- 客服、SOS响应极慢,乘客只能等交警
- 无人车最关键的兜底机制失效
5. 乘客安全告知与应急流程缺失
- 只提示“系统异常,请留在车内”,无有效指引
- 高架、快速路停车,不告知如何避险、何时能开门
- 无应急广播、无统一安抚,造成恐慌与拥堵
6. 复杂道路场景安全冗余不足
- 事件集中在高架、桥梁、快速路
- 这些路段无法随意停车、无法行人下车
- 系统未识别场景风险,统一粗暴刹停
7. 车规级可靠性不达标
- 大面积同时宕机,说明软件稳定性、测试覆盖不足
- 未充分模拟云端断连、服务雪崩、网络抖动等极端情况
- 商业化运营前安全验证不充分
8. 交通协同与城市应急机制缺失
- 无人车瘫痪后,未自动报警交警
- 未与交管系统联动,拥堵扩散后才人工处置
- 对公共交通影响评估不足
一句话总结行业教训
L4无人车要真正安全,必须做到:本地足够强、云端是辅助,失效先靠边,而不是停路中间。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.