近百辆车集体“趴窝”,萝卜快跑没准备好|钛度车库

汽车
技术故障不可怕,可怕的是故障之后,没人、没路、没退路。

图片系AI生成

图片系AI生成

2026年3月31日夜晚,武汉三环线高架上的空气似乎比往常更加焦灼。百度旗下 “萝卜快跑” 多辆无人车在行驶途中突然集体瘫痪,停在在城市主干道、高架路中央,导致交通拥堵,多名乘客被困,最终依靠交警救援才得以安全撤离。

4 月 1 日,武汉市公安局交通管理局发布警情通报,初步判定为系统故障所致,无人员受伤,事故原因仍在进一步调查中。

自动驾驶车辆发生故障的事情时有发生,但令人费解的是,为什么一出故障就是百辆同时“趴窝”?当车外是时速一百公里的车流,车内屏幕上只剩“系统异常”四个字,被困在里面的乘客,又该怎么办?

一场突发的 “交通瘫痪”

3 月 31 日 20 时 57 分起,武汉 122 报警中心陆续接到群众报警,称多辆 “萝卜快跑” 车辆停在路中间无法移动。据现场目击者与被困乘客描述,从二环线、三环线高架到城市主干道,数十辆萝卜快跑车辆同时 “罢工”,打着双闪停在道路中央、快车道甚至高架桥上,后方车辆只能紧急绕行,造成局部交通大面积拥堵。

根据社交平台上用户的反馈,武汉光谷二环高架、汉口二环匝道口、月湖桥隧道、雄楚高架、南三环、墨水湖大桥、高新大道等地均出现萝卜快跑车辆故障,有的地方停了七八辆萝卜快跑。

有乘客称车辆行驶至三环线高架中央时突然骤停,屏幕显示 “驾驶系统异常”,却无法开门下车;有乘客尝试联系客服,多次拨打均无法接通,按下车内 SOS 按钮后,客服仅回应 “网络问题”,却未提供有效救援方案。有的乘客虽可通过按钮开门,但因高架环境无法安全撤离,更有乘客被困高架桥近两小时,最终只能报警求助,由交警现场救援才得以脱困。

截至发稿前,百度方暂未披露武汉车辆故障原因、受影响乘客赔偿方案等。

“指挥权”被交出之后

武汉萝卜快跑事件并非孤例。2025 年 12 月,谷歌 Waymo 无人车曾因旧金山交通信号灯失效,触发 “最小风险策略” 原地停滞,引发交通拥堵;国内此前也多次出现自动驾驶车辆无故急刹、跑偏、停驶等故障。

从技术逻辑来看,自动驾驶通常拥有一套被称为“最小风险策略”的底层协议。理论上,当系统检测到通讯中断或算力异常时,车辆应采取避险措施:减速、打双闪、缓慢靠边停车。然而,在高架桥这种封闭且高时速的环境中,“就地停车”往往意味着制造了更大的交通风险。

在高时速场景下,自动驾驶的应急方案如果仅仅是简单的“就地停驶”,实际上是将乘客置于追尾事故的高风险之中。如果系统无法在检测到网络故障的瞬间,利用残余感知能力自动靠边或寻找安全避险带,那么这种智能本身就带有某种“算法傲慢”。

更为值得警惕的是,“百车同步停摆”的现象。客服初期回应的 “网络问题” 的指向性明确,大概率是大范围网络波动、云端服务器故障或数据传输延迟,导致车辆与云端失去连接、失去核心指挥,进而触发集体停滞。而这也是集中式架构的致命弱点:单点失败,全军覆没。

在运营层面,萝卜快跑在这次事件中同样“掉链子”。萝卜快跑是百度旗下的无人车服务平台,于2022年5月在武汉正式落地,并于同年8月启动全无人商业化运营。2024年年底,仅在武汉就已经部署达到了千辆。在百度世界2025大会上李彦宏表示,萝卜快跑每周的全无人订单数已经超过了25万,全球的出行服务次数超过了1700万次。

这种规模,意味着萝卜快跑已经进入准商业化阶段,按照常理,当云端指令失效,人工客服与地面运维团队应该7×24小时应急响应。然而,在大规模掉线发生时,企业的应急呼叫中心似乎并未能提供足够的带宽与安抚能力。

对于监管部门来说,现在要面对的问题是:自动驾驶企业是否已经具备了与城市管理部门秒级联动的底层数据接口?当系统性故障发生时,是否应强制要求车辆具备物理级别的、非网络依赖的“手动释放”逻辑,让乘客或路面执法者能够迅速接管车辆以恢复交通?

自动驾驶的终点终究是“为人”。 公众不是要求自动驾驶不能出错,但出错之后网络断了,车能不能自己找个安全的地方靠边?客服能不能打得通、管上用场?交警能不能直接让车挪开?

这些事,才是真正的底线。

(文|引擎视角 作者|韩敬娴 编辑|杨林)

本文系作者 引擎视角 授权钛媒体发表,并经钛媒体编辑,转载请注明出处、作者和本文链接
本内容来源于钛媒体钛度号,文章内容仅供参考、交流、学习,不构成投资建议。
想和千万钛媒体用户分享你的新奇观点和发现,点击这里投稿 。创业或融资寻求报道,点击这里

敬原创,有钛度,得赞赏

赞赏支持
发表评论
0 / 300

根据《网络安全法》实名制要求,请绑定手机号后发表评论

登录后输入评论内容

扫描下载App