Baidu’s robotaxis froze in traffic, creating chaos
一句話版本
百度蘿蔔快跑的機械人的士疑似喺真實車流入面集體「呆住」，令現場混亂，重點唔只係單次失誤，而係自動化系統一旦卡死，會即刻變成公共秩序同信任問題。
點解重要
- 唔係普通 bug，而係實體世界故障
- 呢類系統一出錯，後果唔停留喺畫面或者日誌，而係直接塞住條路、影響其他司機同路人，代表任何「卡住但未完全失效」嘅狀態都要當高風險事故處理。
- 「安全停低」未必等於「營運安全」
- 如果車輛選擇保守到原地不動，技術上可能避免咗撞車，但營運上反而製造新危險；對我哋嚟講，失敗模式唔可以只問「有冇更大傷害」，仲要問「會唔會令現場失去秩序」。
- 單車問題會變成 fleet 問題
- 標題用複數語氣去講 robotaxis，意味住如果同類條件會觸發同一反應，問題可能由一架車擴散成車隊級事件；任何集中式規則、模型、策略更新，都要預設可能同步放大錯誤。
- 公眾唔會區分感知錯、規劃錯定控制錯
- 外界見到嘅只係「自動車搞亂交通」，所以內部再精細嘅技術切分，對外都會收斂成品牌可靠性問題；呢點提醒我哋，事故敘事一定要有清晰責任邊界同可驗證證據。
- 邊界情況先係真考驗
- 真實城市交通入面，最難唔係直路巡航，而係突發擁塞、互相讓車、臨時阻塞呢類模糊場景；如果系統喺呢啲情況只識 freeze，代表產品未真正處理到「不確定但又要繼續運作」嘅核心難題。
- 恢復能力比檢測能力同樣重要
- 發現自己冇把握只係第一步，之後點樣快速脫困、降級、求助、重新接管，先決定事故會唔會惡化；一個只識停、唔識復原嘅系統，長遠會喺高摩擦環境入面失去可用性。
- 現場混亂說明人機協調設計可能不足
- 當車停喺度造成 chaos，通常代表其他道路使用者唔知道佢下一步會點，亦冇清楚訊號可以配合；即係話「系統狀態可見性」本身就係安全功能，而唔係附加功能。
- 事故成本會穿透技術團隊
- 呢類新聞會拉高監管審視、媒體關注、合作方壓力，甚至影響後續擴區同商業化節奏；所以一次 freeze 事件，實際代價往往大過修一次程式錯誤。
- 「可大規模部署」同「可小規模示範」係兩回事
- 如果一個系統喺有限路段都會因交通細節而亂陣腳，咁規模化之後只會更頻密撞到長尾情況；呢點提醒我哋，驗證標準一定要針對最煩、最髒、最不規則嘅真實操作場景。
我哋點睇
- 對我哋做本地控制系統而言，最值得借鏡唔係「如何更進取自動化」，而係要先定義清楚每一種卡死狀態由邊個模組發現、邊個模組接手、邊個條件先可以宣告恢復，避免系統停喺一個無人負責嘅中間態。
- 任何會影響外部世界嘅自動執行，都應該有可重播事故證據鏈；如果出事後只剩模糊描述，就無法分清係策略太保守、感知太脆弱，定係恢復流程太慢。
- 驗證唔應只測「成功路徑」，要刻意做 regression case 去覆蓋「卡住但未完全失效」場景，因為真正傷信任嘅，通常正正係呢種表面安全、實際失控嘅狀態。