百度萝卜快跑在武汉“集体宕机”：当无人驾驶卡在路中央，技术神话也得面对红绿灯

武汉街头，一场来自未来的“死机”事故

自动驾驶最尴尬的时刻，不是它不会开，而是它突然不动了。

据多家外媒报道，百度旗下 Apollo Go 机器人出租车本周二在武汉发生大面积异常，多辆车在道路中途停摆，有乘客被困车内，有车辆滞留在高架和主干道上，混乱之中还引发了至少一起交通事故。武汉警方随后确认，确实接到多起相关报警，初步调查指向一次“系统故障”。目前没有人员伤亡，这是不幸中的万幸。

这件事之所以迅速引发关注，不仅因为画面足够戏剧化——一排无人车像按下暂停键一样停在路中央——更因为武汉不是一个边缘试验场，而是百度自动驾驶最重要的样板间之一。这里投放的无人车数量据称已超过 500 辆，地方媒体引述的信息显示，受影响车辆可能达到上百台。换句话说，这不是一辆车犯迷糊，而更像是一次系统级“打喷嚏”。

如果说人类司机在路上最怕“熄火”，那么机器人出租车最怕的就是“集体脑雾”。因为前者是个体问题，后者往往意味着平台、调度、车端系统或者云端协同出了更深层的毛病。它让公众第一次非常直观地意识到：所谓“无人驾驶”，并不是一辆聪明汽车单兵作战，而是一整套高度耦合的软件、传感器、地图、通信和运营体系。一处松动，整片路网都可能跟着紧张起来。

这不是小概率插曲，而是自动驾驶商业化的成人礼

很多公司喜欢展示自动驾驶最光鲜的一面：平稳转弯、自动避让、精准停靠，甚至还能让用户在后排轻松刷手机。但真正决定一家公司能不能把这门生意做大的，不是 demo 时刻，而是故障时刻。

自动驾驶发展到今天，行业叙事其实已经悄悄变了。前些年大家比拼的是“能不能开”，现在竞争核心变成了“能不能稳定地规模化运营”。这听起来只差了几个字，背后却是完全不同的难度。前者考验算法能力，后者考验的是工程、运维、冗余、安全机制，以及企业对极端情况的处理能力。

百度这些年在自动驾驶上的投入不小，也是全球少数把 Robotaxi 真正跑出规模的中国公司之一。按照公开资料，Apollo Go 已在全球 26 个城市部署，还与 Uber 在伦敦、迪拜等地展开合作。对百度来说，这已经不是一个实验室项目，而是必须经得起公众、监管和合作伙伴共同审视的商业业务。

也正因此，武汉这次故障格外敏感。它发生在自动驾驶行业加速出海、抢占城市运营权的节骨眼上。Waymo 在美国不断扩大无人出租车版图，特斯拉还在试图把 FSD 叙事推向更大规模，中国厂商则希望凭借更低成本和更快部署，把 Robotaxi 变成新的技术名片。这个时候，一场大面积停摆不只是公关危机，更像是一盆冷水：商业化不是把车投出去就算赢，真正的考题是出了问题以后，系统能不能迅速自救，乘客能不能安全脱困，城市交通能不能被尽量少地打扰。

自动驾驶最难的，往往不是“开车”，而是“兜底”

很多普通人对自动驾驶的理解，还停留在“它能不能识别红绿灯”“会不会撞人”这些层面。但从工程角度看，更难的问题常常发生在失效边缘。

比如，一辆无人车突然与后台失联怎么办？地图服务异常怎么办？调度系统指令冲突怎么办？车辆检测到风险后，是原地停车最安全，还是应该尝试靠边？如果停车地点恰好是高架桥、十字路口、公交站附近，所谓“安全停车”可能立刻变成对整个交通流的二次伤害。自动驾驶的真正能力，恰恰体现在这种不漂亮、也不适合做宣传视频的场景里。

从目前披露的信息看，武汉事件原因仍然笼统地指向“系统故障”，但这四个字其实信息量很大。它可能是车端系统 bug，也可能是云控平台异常，甚至不排除定位、通信或批量更新引发连锁反应。对于自动驾驶运营商来说，这类故障最可怕的地方在于同步性：如果同一套逻辑、同一版本软件被大规模部署，那么一个错误可能不是单车失灵，而是整支车队在同一时间做出同样错误的保守反应。

这也是为什么，自动驾驶行业越来越像航空业，而不只是汽车业。乘客能否接受无人车，不取决于它 99% 的时间表现得像老司机，而取决于剩下那 1% 的意外时刻，它能否像一个成熟系统那样优雅、透明、有兜底。你可以允许机器偶尔犯错，但你很难接受一整条街一起卡死。

中国为何格外关注这类事故

放在中国语境里，这件事的分量又更重了一层。

中国是全球对 Robotaxi 最积极的市场之一。原因很现实：城市密度高，道路场景复杂，网约车需求旺盛，地方政府也愿意把自动驾驶当作新产业来扶持。武汉、北京、重庆、深圳、广州，几乎都在给无人驾驶开放道路和政策窗口。企业也乐于把这些城市当成技术跑马场，谁先跑通，谁就有机会定义未来出行的规则。

但越是在这种高热度环境下，事故的示范效应越强。一次小故障，可能让用户重新质疑“我为什么要坐一辆没有司机的车”；一次大面积停摆，则会让监管部门重新审视放量节奏。公众对新技术的宽容度，通常只在早期高一点，一旦进入日常使用阶段，大家衡量它的标准就会迅速向地铁、电梯、民航这些基础设施靠拢：便宜是加分项，可靠才是底线。

这里还有一个很现实的问题：如果 Robotaxi 未来真要成为公共交通补充，它到底应该被当成“互联网产品”还是“城市基础设施”？前者允许快速试错、灰度上线、版本迭代；后者则要求极高的稳定性、审计能力和事故响应机制。自动驾驶企业一直试图同时拥有两种身份的好处——像互联网公司那样迭代快，又像交通系统那样获得信任——但武汉这次事件提醒我们，这两套逻辑并不总能兼容。

百度和整个行业，都到了不能只讲故事的时候

平心而论，任何新技术走向规模化，都绕不开事故、故障和争议。Waymo 出过交通阻塞问题，Cruise 更因事故和监管风波一度被迫大幅收缩，特斯拉的辅助驾驶系统也长期处在舆论和监管聚光灯下。自动驾驶从来不是一条没有坑的赛道，真正有价值的不是假装没有问题，而是如何建立一套让问题可追踪、可复盘、可修复的机制。

百度眼下最需要做的，恐怕不是一句轻飘飘的“系统已恢复”，而是更完整地解释：故障到底发生在哪里？受影响车辆规模有多大？乘客如何脱困？后续是否会调整远程接管、软件更新、最小风险停车策略？公众想看的不是技术信仰，而是工程诚意。

我一直觉得，Robotaxi 是一项很容易让人产生未来感的技术：你坐进车里，方向盘前空无一人，车辆却自己并线、掉头、停靠，那种感觉确实会让人短暂地相信，科幻小说已经开进现实。但与此同时，它也很容易让人忽略一个朴素事实：交通不是发布会，马路也不是实验室。每一次算法决策，背后都对应真实的人、真实的拥堵、真实的风险。

武汉这次集体“趴窝”，从行业视角看并不一定是坏事。它撕开了自动驾驶最不体面的部分，也逼着企业和监管正视一个核心命题：比起让车自己开，人们更需要它在出问题时别把整座城市拖进异常状态。未来出行当然值得期待，但它要先学会在现实世界里，安静而可靠地活下去。

自动驾驶的难点，早已不是“有没有司机”，而是“出了问题谁来兜底”。这才是武汉事件留给行业最沉重的一句注脚。