百度100輛無人車集體癱在路中央：武漢晚高峰被堵90分鐘

周二傍晚，武漢三環線上，一輛正常行駛的白色轎車突然急剎變道。后車司機還沒反應過來，就聽見"砰"的一聲——他的車頭撞上了一輛紋絲不動的白色無人車。這不是交通事故，這是一場規模罕見的系統宕機：超過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按鈕則干脆告訴你"不可用"。

唯一可靠的避險方式，或許是像周二那三位乘客一樣——記住車門沒鎖，隨時準備棄車。

無人車的終極承諾是"解放雙手"，但周二的武漢街頭，一群人站在路口，手里攥著手機，正在思考如何向公司解釋遲到原因。他們的無人車還停在幾十米外，屏幕亮著，車輪鎖死，像一尊未來主義的雕塑。

如果下次你叫的無人車在半路突然沉默，車門沒鎖，屏幕顯示"請等待"卻無人前來——你會選擇繼續等，還是推門離開？