当无人驾驶Robotaxi失控，谁来为安全兜底？

3月31日晚，多辆萝卜快跑车辆突然停在道路中间不能移动，部分车辆滞留超过30分钟。

当日20时57分，武汉市122报警中心接到第一通求助电话，随后求助增多。

近百台萝卜快跑车辆几乎在同一时刻接收到“异常终止指令”，触发了最保守的防御策略：fail-safe（故障安全）。这种策略之下，出现故障后，系统优先停下来，把风险降到最低。

一时间，主干道、高架桥上，多辆无人车先后停驶，部分还发生追尾事故，致使原本顺畅的交通陷入拥堵。

比交通拥堵更令人揪心的，是被困在车里的乘客。

媒体报道，有乘客因为乘坐的萝卜快跑“趴窝”，导致被困在高架桥上近两个小时。乘客鲁先生乘坐的无人车，在三环线中间突然停下，两侧是疾驰的大货车，车速飞快，他不敢下车。车上的SOS按钮按了没反应，后座屏幕上的电话拨过去就被挂断。通过400电话联系上客服后，对方说派专员来接，结果快一个小时过去，都没有等到。最后是鲁先生报警，交警带着萝卜快跑的工作人员赶到，他才得以脱身。

事后，百度将故障原因初步归结为“网络问题”，而武汉交警4月1日凌晨的通报则判断为“系统故障”。

但无论哪种说法，都指向同一个事实，这套被寄予厚望的无人驾驶系统，在关键时刻掉链子了。

故障发生后，车内屏幕显示“工作人员预计5分钟赶来”。但现实是，被困乘客等待了一小时以上。SOS按钮无用、客服热线拥堵、救援力量无法及时覆盖近百台分散在不同路段的故障车。这暴露出的不是单一技术漏洞，而是整个应急响应机制存在缺陷。

最终，是交警为无人车兜了底。

监管的质变也由此开始。武汉市经开区管委会及交通运输部门迅速约谈百度负责人，监管重点从早期的“准入测试”转向“常态化运营监控”，要求企业必须建立拥堵即时疏导机制，一旦车辆在主干道长时间停留，15分钟内必须完成物理干预。

这次系统故障事件，折射出Robotaxi商业化长期面临的现实矛盾：安全、成本和盈利能力，很难同时做到极致。

当前行业普遍采用“边运营、边收集反馈、边修正Bug”的模式。原因很现实：如果完全靠内部封闭测试穷尽所有问题，成本高到商业上无法承受。在真实运营中发现问题、修正问题，是更常见的路径。

但对乘客来说，感受完全不同。乘客购买的是一项出行服务，而不是参与一场技术试验。平时系统运行顺利时，这种矛盾不突出；一旦出现集体停摆，外界会直观意识到：这项技术仍处于持续试错阶段。

佐治亚理工学院的一项研究用渗流理论模拟了联网汽车同时瘫痪的后果：高峰时段，只需让路上20%的车辆随机停下，城市交通就会彻底冻结；10%的车辆停摆，就足以阻止急救车和消防车通行。

武汉此次故障，虽未达全域阈值，但已在夜间饱和路段引发了拥堵连锁反应。

科技的终极意义，是让生活更安全、更便捷，而非制造隐患。

行业人士接受媒体采访时表示，类似情形更理想的方案是fail-operational（故障运行）：即便系统或车辆硬件出现异常，无人车仍能保持基本行驶能力，以低风险状态继续行驶一段，将车辆和人员带到安全区域，完成靠边停车，再等待远程接管或线下救援。

系统故障导致的车辆停摆，不是自动驾驶行业的“终点”，但必须成为行业反思的“起点”。当车辆失控等极端事件出现时，SOS按钮要真能救命，客服电话要真能解决问题，救援力量要真能及时赶到。

技术可以快一点，但安全必须更稳一点。毕竟，比起技术的突破，公众更在意的，是每一次出行的平安抵达。