就在前天，（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无人车要真正安全，必须做到：本地足够强、云端是辅助，失效先靠边，而不是停路中间。