周二傍晚，武汉三环线上，一辆正常行驶的白色轿车突然急刹变道。后车司机还没反应过来，就听见"砰"的一声——他的车头撞上了一辆纹丝不动的白色无人车。这不是交通事故，这是一场规模罕见的系统宕机：超过100辆百度Apollo Go无人车在同一时刻"死"在了路上。
90分钟内，一位司机的行车记录仪拍到了至少16辆僵在原地的无人车。有的停在红绿灯路口，有的横在高速公路快车道，像被按了暂停键的电子宠物。
这场宕机持续了数小时。武汉交管部门当晚通报，事故"极大概率由系统故障引发"，具体原因仍在调查。百度至今未回应媒体问询。
当"远程接管"变成"远程失联"
对乘客而言，这场故障更像一场密室逃脱。一位女性乘客向《连线》杂志描述了她和朋友被困车内的90分钟：车辆断断续续停了四五次，最终抛锚在一个路口。车载屏幕显示"工作人员将在5分钟内到达"，但无人现身。
她们拨打客服电话，得到的答复毫无用处。最后三人发现车门并未上锁，自行下车离开。
社交媒体上，更多乘客晒出相似遭遇。有人按下App里的"SOS紧急求助"按钮，屏幕弹出一行字："该功能暂不可用。"这位用户在RedNote上质问："那这SOS按钮到底是干什么用的？"
讽刺的是，Apollo Go的宣传话术里，"7×24小时远程安全员监控"是核心卖点。但显然，当系统本身崩溃时，监控成了摆设，求助通道成了空号。
三次追尾背后：人机混行的灰色地带
这次宕机至少造成三起追尾事故。除前述变道避让导致的碰撞外，另有视频显示一辆面包车径直撞上无人车尾部。一位路过司机证实，她在现场看到了这辆受损的面包车。
这些事故暴露了一个被长期回避的问题：当无人车突然失能，人类司机的应急反应时间是否足够？
百度Apollo Go在武汉的运营规模已超过数百辆，但城市道路并非封闭测试场。人类司机对无人车的行为模式缺乏预判——它们会突然变道吗？会在绿灯亮起时纹丝不动吗？会在高速上毫无征兆地刹停吗？
周二的事故给出了肯定答案。更麻烦的是，这些"僵尸车"并未开启双闪警示，也没有自动靠边停靠。它们只是停在那里，像被拔掉电源的服务器，等待着永远不会到来的重启指令。
武汉模式：激进部署的代价
百度选择武汉作为Apollo Go的最大运营城市，有其现实考量。武汉交管部门对无人车路权开放较早，测试区域覆盖市中心至机场的高速路段。这种"政策友好"让百度得以快速扩张车队规模，但也意味着故障影响被成倍放大。
一个值得玩味的细节：部分被困乘客发现车门未锁。这在日常是便利，在故障时却成了安全隐患——如果车辆停在高速中央，乘客自行下车意味着什么？
百度没有解释为何车门保持解锁状态。一种可能是系统设计缺陷，另一种可能是工程师早已为"系统彻底失联"预留了物理逃生通道。无论哪种，都暗示着某种程度的预判。
这次事件并非无人车首次"掉线"。2023年，美国旧金山也曾发生Cruise无人车集体堵塞路口的事故，导致加州监管机构紧急叫停其运营许可。但旧金山的规模远小于此次武汉事件——100辆车同时瘫痪，在公开报道中尚属首次。
宕机之后：谁来定义"安全冗余"
无人车行业的核心叙事是"比人类司机更安全"。这个命题建立在统计学意义上：系统反应更快，不会疲劳驾驶，不会酒后驾车。但周二的事故揭示了另一个维度——人类司机的"故障"是分散的、局部的，而系统的故障是集中的、同步的。
一位武汉交警在视频中透露，当晚至少有100辆车受影响。这个数字与百度公开的车队规模相比，意味着故障渗透率可能高达两位数百分比。如果是软件更新引发的级联错误，其波及范围将远超单一交通事故。
目前尚无监管机构对百度提出处罚。武汉交管部门的通报措辞谨慎，仅称"正在调查"。这种模糊处理或许反映了地方政策的两难：既要维护无人车产业形象，又需回应公众安全焦虑。
对乘客来说，更实际的困惑是：下次叫无人车时，如何判断它不会再次"死机"在中环线上？百度的App里不会显示车辆的健康状态，客服电话在故障时形同虚设，SOS按钮则干脆告诉你"不可用"。
唯一可靠的避险方式，或许是像周二那三位乘客一样——记住车门没锁，随时准备弃车。
无人车的终极承诺是"解放双手"，但周二的武汉街头，一群人站在路口，手里攥着手机，正在思考如何向公司解释迟到原因。他们的无人车还停在几十米外，屏幕亮着，车轮锁死，像一尊未来主义的雕塑。
如果下次你叫的无人车在半路突然沉默，车门没锁，屏幕显示"请等待"却无人前来——你会选择继续等，还是推门离开？
热门跟贴