3.4亿单季度订单背后，一场系统故障让百度自动驾驶的体面碎了一地。武汉交警的接警记录显示，周二晚"一个接一个"的求助电话，全部指向同一批停在路中间的白色无人车。
高架桥上的90分钟：当客服只会说"已派专员"
晚上9点，武汉某高架桥。一辆Apollo Go（百度无人出租车服务）突然刹停，四周是呼啸而过的渣土车。
「一开始打不通客服，反复打之后，每个人都说已经派了专员。」被困用户在社交平台RedNote上回忆。直到10点半订单被取消，她仍被困在原地——无人车没有门把手，乘客无法自行离开。
另一名用户上传的视频标题更直接：「Apollo Go，你瘫痪了吗？」画面里，车载平板的客服界面反复加载，无人应答。
武汉警方周三通报确认，「多辆Apollo Go停在道路中央无法移动」，初步调查指向系统故障。百度在武汉部署了超过500辆无人车，但官方未披露本次瘫痪的具体数量。
客服话术 vs 真实救援：一场不对等的博弈
用户最愤怒的并非故障本身，而是事后的应对逻辑。
「 useless platitudes（无用的空话）」，这是被困乘客对客服的评价。百度客服的标准流程——"已记录""已派专员""请耐心等待"——在90分钟的孤立无援面前，成了讽刺。
一个细节值得玩味：无人车的设计逻辑是"全无人"，却未给乘客预留紧急出口。传统出租车至少能推门下车，而Apollo Go的车门控制权完全归属云端系统。系统宕机时，乘客连最基本的逃生权都被锁死在代码里。
这暴露了自动驾驶商业化的一个结构性矛盾：为了证明"比人类更安全"，厂商把控制权收得越来越紧；但系统失效时，乘客却连最原始的自救手段都没有。
3.4亿订单的增长神话，遮不住两次致命停摆
百度最新财报数字很漂亮：2025年第四季度提供340万次无人车服务，同比增长超200%。与Lyft、Uber的出海合作也在推进中。
但数字背后的事故密度同样刺眼。去年12月，株洲市一辆百度无人车撞倒两名行人，致其重症监护，当地直接叫停了运营。加上本次武汉集体瘫痪，半年内两次系统性风险，发生在两个不同的城市。
株洲事故指向感知或决策层的漏洞——"没看见"或"看见了没刹住"。武汉故障则更像云端系统的连锁崩溃——"突然集体下线"。两种故障路径，指向同一个问题：当车辆规模从几十辆测试车膨胀到500辆运营车队，系统的鲁棒性（robustness，抗干扰能力）是否跟上了扩张速度？
百度2020年在北京开放Apollo Go公测，此后逐步铺向多个城市。但"多城运营"的叙事容易掩盖一个事实：每个城市的道路环境、交通参与者行为模式、气候条件都截然不同。武汉的高架桥、渣土车、夜间照明，与北京的测试场完全是两套系统负载。
无人车的"恐怖谷"：比人类司机危险，还是比人类司机更不可控？
自动驾驶行业有个心照不宣的指标：脱离率（disengagement rate，人类安全员接管的频率）。但百度在武汉已经部署"全无人"车队，意味着这个安全网被撤掉了。
撤掉安全员的底气，来自仿真测试和有限场景验证。但仿真无法复现"周二晚上9点、武汉高架桥、渣土车环绕、系统突然宕机"的组合场景。更无法训练客服话术如何应对一个被困在移动棺材里的真实人类。
用户被困90分钟的遭遇，撕开了一个尴尬的现实：无人车的故障响应链条，比车辆本身的自动驾驶链条更长、更脆弱。车端感知→云端决策→远程客服→现场救援，任何一个环节断裂，乘客都暴露在风险中。而传统出租车只需要一步：司机开门。
百度与Lyft、Uber的合作消息发布于本次事故之前。海外扩张的叙事里，"中国最大无人车队"是核心卖点。但武汉高架桥上的90分钟，会让海外监管机构和用户问出同一个问题：当系统故障时，你们打算让乘客等多久？
无人车的竞争从来不是单纯的技术竞赛，而是"故障时的兜底能力"竞赛。特斯拉选择保留方向盘和踏板，Waymo（谷歌旗下自动驾驶公司）在美国部分城市仍配备远程监控员，都是对这种不确定性的妥协。
百度押注的"全无人"路线，本质上是用极端场景下的用户风险，换取日常场景下的成本优势。这个等式是否成立，取决于系统故障的频率和应急响应的完备性。340万单季度订单是答案的一部分，武汉高架桥的90分钟是另一部分。
被困乘客最终获救，但她在社交平台留下的问题没有答案：「为什么没有人告诉我，遇到紧急情况该怎么办？」
这个问题，百度需要回答。Lyft和Uber的合规团队，大概也在等一份比"已派专员"更详细的说明书。
热门跟贴