2018年3月18日晚上10點，一輛Uber自動駕駛測試車在美國亞利桑那州坦佩市撞死了一名叫Elaine Herzberg的行人。她推著自行車橫穿馬路，車上的系統識別到了她,但沒能正確分類,更沒能及時剎車。
這件事發生七年後,類似的問題依然沒有解決。2025年,中國進行了一場針對36台車輛的ADAS高速公路測試,涉及15種危險場景,結果撞出了216次碰撞。其中一個場景是一隻假的黑豬玩偶橫穿馬路,多輛車壓根沒反應過來,因為這個物體不在它們的訓練數據分布里。
你可能會覺得奇怪:都2025年了,自動駕駛都吹了這麼多年,怎麼連"識別一隻在路上的豬"這種事都做不好?
這正是本文要講的這篇論文想要挖出來的東西。倫敦大學學院、慕尼黑工業大學、塔爾圖大學和倫敦國王學院的研究團隊,採訪了來自六個國家、九家公司的九位一線自動駕駛測試專家,試圖搞清楚一件聽起來很基礎、但行業內部至今沒有共識的事:自動駕駛系統到底應該怎麼測?測到什麼程度才算夠?誰說了算?
為什麼這個問題一直沒有答案
先說清楚問題有多難。
自動駕駛系統不是普通軟體。普通軟體的測試邏輯很直接:輸入A,期望輸出B,跑一遍看對不對。但自動駕駛要面對的是真實世界,而真實世界裡的場景數量幾乎是無窮的。下雨天加逆光加突然竄出來的貓,和晴天加正常光線加同樣的貓,是兩個完全不同的測試場景。你永遠無法窮舉所有可能性。
更麻煩的是,這個行業還沒有一套公認的"及格線"。飛機有明確的適航認證標準,藥品有臨床試驗的三期流程,但自動駕駛系統要跑多少公里、覆蓋多少場景類型、失敗率控制在多少以內才算"足夠安全",目前每家公司都有自己的一套內部標準,彼此並不透明,外界也無從比較。
這就好比每個學校都在用自己的方式給學生評分,卻從來不組織統一的中考聯考。學生之間沒法比較,家長也不知道某個分數到底意味著什麼水平。自動駕駛行業現在就是這種狀態:每家公司都說自己的系統"經過了嚴格測試",但嚴格到什麼程度、跟別家比起來誰更可靠,沒人知道。
正因為這種模糊,這九位受訪專家分享的東西才特別有價值。他們不是在講PPT里的理想流程,而是在講自己每天上班要面對的真實困境。
這些專家在測什麼樣的車
先了解一下受訪者的背景,能幫你更好判斷後面資訊的可信度。
九位專家來自瑞典、中國、德國、英國、日本、比利時六個國家的九家公司,大部分是員工超過一萬人的整車製造商,也有軟體開發和技術類公司。他們的從業經驗從2年到14年不等,但每個人都至少有2年自動駕駛領域的直接經驗。角色也很雜:系統分析師、總工程師、系統測試員、研究員、產品工程師、高級工程師、董事總經理、工程經理。
這些人測試的系統類型跨度也很大,從L2級別的輔助駕駛(ADAS,driver assistance system,車輛提供輔助但司機仍需對駕駛負全責的系統)到L4甚至號稱L5的全自動駕駛系統都有覆蓋。功能上包括自主泊車、城市道路駕駛、高速公路駕駛,乃至跨越城市、高速、鄉村路況的全場景系統。
這裡有個特別值得說的細節。一位受訪者(編號P6)提到,他們公司的泊車系統實際上已經能做到完全自主泊車,達到了L4的技術水平,但官方卻把它標註為L2。原因不是技術不夠,而是責任歸屬問題:自動駕駛等級越高,廠商承擔的法律責任就越大,監管要求也越嚴格。L2的責任還在司機身上,所以廠商更願意把系統標為L2、L2+甚至L2++,即便實際體驗已經接近L3甚至L4。
這就像一個廚師明明手藝已經能開米其林餐廳,卻堅持只掛"家常菜館"的招牌,因為米其林招牌意味著更嚴苛的衛生檢查和更高的賠償風險。表面上是謙虛,實際上是精算過的風險規避。這種"官方等級"和"實際能力"之間的灰色地帶,論文特別指出值得未來深入研究。
測試到底是怎麼做的:一場層層遞進的接力賽
如果你以為自動駕駛測試就是"造一輛車,上路試試",那和真實情況差得遠。
受訪者描述的測試流程更像一場接力賽,分成好幾個階段,一步步把風險從"純軟體層面"推向"真實馬路上"。這套體系有個專業名字。
X-in-the-Loop測試:指模型在環(model-in-the-loop)、軟體在環(software-in-the-loop)、硬體在環(hardware-in-the-loop)、整車在環(vehicle-in-the-loop)測試的統稱,是自動駕駛行業最主流的分階段驗證方法,核心思路是讓被測系統逐步從虛擬環境走向真實物理世界。
具體怎麼運作?先從最抽象的層面說起。模型在環測試階段,系統還只是一堆高層次的數學模型,工程師用它來快速跑大量場景變體,因為這時候還沒有具體代碼要調試,跑得快、成本低。這一步的另一個好處是讓不同團隊能各自專注自己負責的模組,比如感知團隊不用管規劃團隊的代碼細節。
接下來是軟體在環測試,這時候某個功能模組比如控制系統已經寫成真實代碼了,要在仿真環境裡測試這段代碼本身或者它跟別的模組搭配起來是否穩定,是否會莫名其妙報錯或死機。
再往下是硬體在環測試,把傳感器、轉向、制動、底盤這些真實硬體接進來,部分模擬軟體依然保留。這一步要看硬體反應速度、通信延遲、組件間的相互影響。有位受訪者(P3)描述得很具體:用CAN總線和線束把傳感器和執行器連接到測試台上,把軟體加載進去,驗證功能是不是真的存在、是不是真的能跑起來。
最後是整車在環測試,把所有軟硬體裝進一台完整的車,拉到封閉測試場或者開上公開道路。這時候關注的不只是"功能對不對",還有"體驗好不好":剎車是不是平順、轉向是不是舒適、換擋是不是讓人心裡發慌。
這個從抽象到具體、層層遞進的結構,其實很像學開車考駕照的過程。你不會一上來就直接上高速,而是先在駕校練車場學倒車入庫,再去簡單路段跑幾圈,最後才被允許獨自上路。如果跳過中間步驟直接把新手扔上高速,一旦出事根本不知道是方向盤的問題、是判斷力的問題、還是純粹運氣不好,排查起來無從下手。分階段測試的價值就在這裡:每個階段只暴露特定類型的問題,方便快速定位和修復。
如果沒有這套分層結構會怎樣?論文裡有個例子特別說明問題。有位受訪者(P5)提到,某些極端場景根本沒有可靠的"標準答案"數據,自動化評估系統判斷不出對錯,工程師得親自去量真實世界的物理距離才能確認系統到底做對了沒有。可以想像,如果所有測試都只在真實道路上一次性完成,類似這種需要精細核查的邊緣情況會淹沒在海量正常數據里,根本找不出來。
測試策略:六種不同的思考起點
除了測試流程,受訪者還分享了他們制定測試計劃的思路,這部分論文歸納出六種不同的策略取向。
功能驅動策略是最直覺的做法:測試內容完全跟著被測功能走。測泊車系統就去找不同類型的停車場,垂直的、平行的、斜角的都試一遍;測車道保持和自適應巡航,就去高速公路上跑。
需求驅動策略則更系統化,一切從系統需求文檔出發,確保每一條需求,無論是功能層面、系統層面還是零部件層面,都被充分定義和正確實現。這種策略下,測試環境的選擇要看需求本身的性質。比如要驗證一個自動駕駛功能的響應時間是否足夠快到能避免碰撞,軟體在環或者硬體在環環境根本不夠用,必須拉到試車場或者上路實測才能拿到真實數據。
仿真驅動策略,也叫"左移策略",目標是儘量把測試往開發早期推,多用仿真、少用實車,理由很實際:實車測試貴、還有安全風險。但這條路要付出代價,仿真必須足夠真實才有意義,而"足夠真實"本身又是個無底洞。測感知和視覺系統往往需要接近電影級畫質的仿真,而測決策和控制邏輯,低精度的簡化環境反而夠用了。
開發驅動策略更貼近某些企業實際的疊代節奏。因為ADAS功能跟車輛底盤、動力系統、車身控制系統緊密耦合,開發和測試往往是同步演進的,今天上線一個泊車功能,收集問題,打補丁,下一輪再測,如此循環往復。
數據驅動策略是被反覆提及的一種新興思路,尤其是隨著大模型進入自動駕駛領域後變得越來越重要。傳統的仿真方法建立在顯式的、基於物體級別的建模上,適合規則明確的低階系統,但現代AI驅動的自動駕駛系統越來越依賴隱式的、基於token的表示方式和海量真實傳感器數據,傳統的場景建模方式已經跟不上了。行業正在轉向直接用攝影機、雷射雷達等原始多模態駕駛數據作為測試場景的核心素材。
最後一種叫目標驅動策略,測試用例直接從"保證案例"(assurance case,一套用來支撐系統安全性和質量聲明的結構化論證)里推導出來。這種做法用一種叫GSN的工具來組織整個論證結構。
GSN:全稱Goal Structuring Notation,目標結構表示法,是一種用來梳理"目標-子目標"層級關係的圖形化框架,常用於安全論證,幫助工程師清晰展示"為什麼我們認為這個系統是安全的"這套邏輯鏈條。
這六種策略不是互相排斥的,現實中往往是混著用。這一點其實揣摩得出研究者的用意:他們沒有強行給出一個"標準答案"式的最佳策略,而是老老實實呈現了行業里真實存在的多樣性,這恰恰反映出這個領域還沒走到"大家用同一套方法"的成熟階段。
怎麼知道該往下一階段推進了
一個更棘手的問題是:測試從一個階段過渡到下一個階段,靠什麼判斷"這一步夠了,可以往前走了"?
論文歸納出四種過渡策略。需求驅動型是最理論化的做法,先定義需求規範,分析ODD(Operational Design Domain,運行設計域
,指系統被設計用來正常工作的具體條件範圍,比如晴天、限速120以下的高速公路),再選擇或生成對應場景,跑完之後檢查系統是否滿足預設的性能要求,達標才推進。
指標驅動型更依賴量化數據。比如從仿真過渡到試車場,要看碰撞次數、偏離道路次數、乘坐舒適度這些指標是否達標;從試車場過渡到公開道路,還要評估延遲、安全行為、對各種交互場景的響應能力。有位受訪者(P1)提到一種覆蓋率的判斷標準,可以按百分比、組合覆蓋等級、優化疊代次數來定義,比如設定"跑夠多少輪優化疊代,如果沒發現新問題,就算測完了"。
經驗驅動型聽起來不太"科學",但卻是行業里非常真實的現狀。一位受訪者(P2)直言,行業內目前沒有清晰的共識來劃定不同測試階段的邊界,實踐中主要靠各家公司、部門、項目積累的最佳實踐和經驗判斷,團隊覺得"信心足夠了"就往下推進。
分析驅動型則是基於變更影響分析:系統每次改動都要先分析這次改動影響了哪些規格和實現,再決定哪些測試場景需要重新跑。比如一次改動只影響縱向控制,那橫向控制相關的場景可能就不用重跑了,因為之前已經測過。
這四種方式混雜共存的現狀,其實暴露了整個行業的一個尷尬事實:大家都知道"經驗判斷"不夠嚴謹,但目前還沒有一套足夠可靠的量化標準能完全取代它。這也是論文後面提出改進框架的重要動因。
滿意標準:安全到底意味著什麼
測試通過的"滿意標準"是什麼,論文裡有個特別值得展開的細節。
有位受訪者(P8)提出一個很樸素但極具衝擊力的觀點:自動駕駛最基本的安全要求,就是不能主動撞上路上的東西,尤其是靜止的障礙物。聽起來是常識,但現實里很多系統在標準物體上表現良好,遇到"訓練數據里沒見過的東西"就容易翻車。他提到的那個黑豬玩偶測試就是個例子,這隻玩偶之所以能讓多輛車失靈,本質原因是它跳出了系統訓練時見過的物體分布範圍。
類似的問題也出現在Elaine Herzberg的悲劇里,她推著自行車橫穿馬路的姿態,是一種"不常見的行人呈現方式",系統的感知模組沒能正確歸類。
這揭示了一個深層次的矛盾:機器學習系統的"聰明"高度依賴訓練數據的覆蓋範圍,而現實世界的豐富程度永遠超出任何數據集能覆蓋的邊界。這不是簡單加大數據量就能徹底解決的問題,而是這類系統與生俱來的局限。
除了"別撞上東西"這條底線,受訪者還提到了不少具體的量化指標。成功率是最常見的一種,比如泊車系統看不同停車場類型下的成功率,高速駕駛系統看車道偏離、車道居中、彎道處理、減速行為、急剎車事件這些細項。
準確率則常常跟歐洲監管標準掛鉤,比如某些歐洲法規和TUV(德國技術監督協會,負責車輛認證等技術合規審查的權威機構)標準要求,開放道路測試跑滿300公里,系統準確率必須超過90%。而且白天和夜晚的表現要分別達標,任何一項不達標,整體就算失敗,不能靠平均分矇混過關。
還有一種叫故障率的指標,關注系統在長期測試周期里的問題趨勢。高速駕駛這類安全關鍵功能對故障率要求極其嚴格,哪怕是很小的bug都可能導致產品無法發布,而泊車這類低速功能因為風險相對較低,標準會寬鬆一些。
值得一提的是"數據飽和"這種更另類的判斷方式。有受訪者(P1、P7)提到,他們把路測本質上看作一個數據收集的過程,判斷路測是否可以結束的標準是"收集到的里程里,觀察到的車輛行為是否持續符合預期"。但這裡有個誠實的困惑,連他們自己都還沒搞清楚:到底要收集多少數據,才能有信心說這輛車已經足夠成熟可以發布了?目前沒有一個被普遍接受的標準答案。
那些沒人願意公開談的挑戰
說完了測試流程和標準,該談談這個行業真正頭疼的問題了。
論文把這些挑戰歸納成了十幾類,我挑幾個最核心、最有代表性的詳細展開。
**仿真和現實之間的差距,是被提得最多的一個問題。**
這個差距有專業名字。
Sim-to-real gap:仿真到真實世界的差距,指的是在虛擬仿真環境裡訓練或測試出來的系統性能,搬到真實世界後往往打折扣,因為仿真環境無法完全復現真實世界的物理特性和隨機性。
這個問題至少體現在三個層面。第一個層面是仿真精度不足。有受訪者(P9)提到,路面、建築物、玻璃、樹木都會產生不同的物理反射特性,影響傳感器和點雲數據,而目前仿真環境在這方面的還原度還遠遠不夠。特別是攝影機數據的仿真尤其困難,新型傳感器還在不斷湧現,仿真跟不上現實設備的疊代速度。
第二個層面更微妙,叫仿真表徵能力的局限。有受訪者(P7)舉了個特別具體的例子:如果一個系統的感知模組和規劃模組之間有一個預定義的接口,而這個接口只能表示"檢測到的智能體"和"道路結構",卻不包括交通錐桶、交通指揮員、臨時路障這些元素,那這些場景就壓根沒法在仿真里被正確表示和測試。他特別提到交通錐桶這個例子,因為這類物體體積小、在訓練數據里出現頻率低,感知系統很難可靠識別。而感知系統識別不出來的東西,仿真器自然也就沒法還原,這形成了一個死循環:要解決就必須重新訓練感知系統,這個過程可能要花上幾個月,還得依賴收集足夠的真實世界稀有場景數據。
第三個層面是仿真質量本身怎麼評估的問題。有受訪者(P4)提到,像CARLA這樣在學界和業界廣泛使用的仿真平台,大家其實都不太確定它的精度到底夠不夠用來測試某些視覺系統或特定模組。
針對第一個層面,行業里出現了一個技術方向的嘗試。
3D Gaussian Splatting:一種實時三維場景表示方法,通過大量微小的高斯分布點來重建三維空間,能比傳統渲染方式更快速、更逼真地還原真實場景,近年被引入自動駕駛仿真領域,用來提升虛擬環境的物理真實度。
有受訪者提到他們已經在探索用這種技術來提升仿真質量,但同時強調,光是提升視覺外觀上的逼真度還不夠,材質、紋理、傳感器反射、環境形變這些更底層的物理真實性也需要跟進。
針對第二個層面的接口局限問題,受訪者提出了兩個方向:一是端到端架構,直接去掉感知和規劃之間的顯式接口;二是所謂的"世界模型"。
世界模型(World Model):一種能直接從數據里學習並生成逼真駕駛環境和傳感器交互表現的AI技術,目標是讓系統能更整合地進行仿真、測試和訓練,而不需要依賴預先設計好的模組接口。
Waymo和Nvidia這些公司正在重點投入這個方向。它的好處是能繞開"感知模組識別不出某個物體,仿真就沒法還原這個場景"的死結,但代價是犧牲了系統的可解釋性,因為端到端系統直接輸出駕駛軌跡,不再暴露中間的感知表示,出了問題也更難排查是哪個環節的鍋。
這個權衡有點像去一家全自動化的中央廚房吃飯還是一家開放式廚房的餐館。全自動化廚房出餐速度快、味道穩定,但一旦你吃出問題,廚房是黑箱,沒法直接看到到底哪個環節出了差錯。開放式廚房你能看清每個步驟,出問題容易定位,但效率和靈活性會打折扣。行業現在正處於要不要往"黑箱但更強大"的方向走的十字路口,這不是一個純技術判斷,而是"可解釋性"和"性能上限"之間的取捨。
**第二個大問題是行業缺乏公開的性能基準。**
這一點被一位受訪者(P8)稱為最關鍵的挑戰之一。他拿大語言模型行業作對比,即便是閉源的大模型,業內也有一批公認的公開評測榜單,大家能在同一套標準下比高低。但自動駕駛公司幾乎不公開自己的性能數據、測試數據、傳感器配置或評估方法,導致外界根本沒法橫向比較不同公司的系統誰更可靠。
雖然確實存在一些公開數據集,比如加州車管所(California DMV)的脫離報告、Waymo開放數據集、nuScenes數據集,但這些數據集在傳感器配置、地圖資訊、評測設置上都不統一,沒法直接拿來做公平對比。
針對這個問題,受訪者提出了一套組合方案:監管、透明度、行業領導力、標準建設,四管齊下。他特別指出,單靠監管是不夠的,因為公司總能找到形式上合規卻實際沒有真正提升性能的方法。真正能推動改變的,是像Waymo、Nvidia這樣的行業頭部玩家主動帶頭公開基準和性能結果,逐漸把透明度變成行業慣例。
**第三個大問題是場景覆蓋的不完整性,這被一位受訪者(P5)明確認定為最critical的挑戰。**
道理很簡單:再怎麼努力測試,系統總會有覆蓋不到的場景,而現實世界裡最危險的往往正是那些沒被覆蓋的稀有場景。這也解釋了為什麼當前的脫離率和碰撞率數據顯示,完全可靠的L4甚至L5級自動駕駛系統離現實還有距離。
針對這個問題,有個方向是用AI生成的方式來擴充測試場景庫,思路是不斷積累的真實世界數據可以為訓練大型AI模型打底,讓AI去生成人類可能從未想到過的場景組合。這被描述為一種從"量變到質變"的過程:先靠大規模數據積累打基礎,再靠AI去做組合和延伸。相比完全依賴人類設計的場景,AI輔助生成可能更擅長探索超出人類想像力的方向。
不過這裡也藏著前面提到的另一層困境:AI生成的場景本身是否足夠真實、足夠有代表性,又成了一個新問題,論文裡稱之為"場景真實性的不確定性"。這就形成了一種嵌套的難題,你想用AI來解決場景不夠用的問題,但AI生成的場景本身夠不夠真實又需要另一套驗證。
**還有幾個不那麼"高大上"但極其真實的運營層面挑戰,值得單獨說一說。**
數據傳輸困境是其中一個。有受訪者(P6)提到,他們的車輛日誌需要從車上取出再手動傳輸到內部網路,而不是像特斯拉那樣直接通過雲端實時上傳。這個流程效率低,尤其是海外測試的時候,國內團隊根本沒法直接訪問車端網路遠程取數據。他建議參考特斯拉的雲端持續改進模式,但也坦誠地指出,不同國家對數據儲存和傳輸有不同的法律要求,海外部署可能還需要建立本地數據中心並對數據做脫敏處理才能共享,這不是純技術問題,還牽扯到跨國合規。
資源約束也是個繞不開的話題。有受訪者(P3)認為這是最critical的挑戰之一,原因很現實:壓縮的開發周期和緊迫的上市時間表往往留不出足夠的時間做全面測試,公司有時候不得不降低預期的成功率標準來趕發布節點。更讓人無奈的是,有些問題技術上是可以解決的,比如傳感器計算延遲,但需要更換成本高昂的硬體,一旦開發進入後期,這種改動就變得不現實了,只能帶著已知的缺陷發布產品。
不可復現的問題則是另一種令人頭疼的現實。有受訪者(P3)描述,某些在測試中觀察到的問題極其critical,但發生頻率極低,幾乎復現不出來,即便在看起來完全相同的條件下也難以重現。解決這類問題往往需要測試團隊、系統設計負責人、供應商等多方長時間協作。
安全論證的空白同樣是個尚未解決的核心難題。有兩位受訪者(P2、P4)提到,針對基於機器學習的組件,行業還缺乏專門的安全論證方法。現有的安全理論和框架大多是為傳統的規則驅動系統設計的,面對大型AI模型的黑箱特性,這些框架的有效性正在打折扣。這裡面還牽涉到一個專業概念。
SOTIF:全稱Safety of the Intended Functionality,預期功能安全,是一套關注"系統即便沒有硬體故障,但因為設計局限或性能不足而導致的安全問題"的國際標準(ISO 21448),這跟傳統功能安全標準關注硬體失效的角度不同,更貼合AI系統"沒壞,但判斷錯了"這種問題類型。
未來會怎樣:專家們的預測和顧慮
聊完當下的困境,受訪者們也分享了他們對未來的展望,這部分內容同樣值得認真讀。
一個比較一致的預期是測試流程會變得更快、更自動化。有受訪者(P9)提到,現在從模型在環到軟體在環再到硬體在環的整個流程還是相對順序化的,未來會通過持續地把真實世界日誌數據餵入不同測試階段來大幅縮短這個流程。他還提到了一個概念。
SDV:軟體定義車輛(Software-Defined Vehicle),指的是車輛的核心功能和性能主要由軟體而不是硬體來定義和疊代的車輛設計理念,配合OTA(Over-The-Air,空中下載)技術,廠商能像更新手機應用一樣遠程升級車輛功能,而不需要召回換硬體。
另一個受訪者(P6)的預測則更激進一些,他設想未來的車輛本身會成為一個"自主測試代理",能自己判斷該測什麼、去哪測、收集數據、發現問題、自動反饋改進,幾乎不需要人工介入測試過程。這個設想聽起來有點像科幻,但如果放在軟體定義車輛和大規模OTA更新的背景下想,倒也不完全是空想。
AI在測試場景生成中的應用是另一個被廣泛提及的趨勢,但受訪者也很坦誠地指出了這條路上的現實障礙:除非AI生成的環境能真正在物理層面上還原真實世界的物理規律、傳感器行為和動力系統交互,否則這類方法很難被大規模採用。這一點其實又繞回了前面提到的仿真精度問題,說明整個行業的挑戰是相互關聯、層層嵌套的,不是解決了A就自動解決了B。
行業透明度和數據共享也被寄予厚望。有受訪者提到Nvidia開源了名為Alpamayo的安全透明自動駕駛項目,認為這代表著行業正在從"炫技式演示"轉向"真實部署和可衡量性能"的階段,這種轉變自然會推動更透明的指標、數據和基準共享。
關於安全論證的走向,有位受訪者(P1)提出一個特別值得深思的觀點。他們希望減少對"proven-in-use"(通過長期實際使用積累的運行數據來證明系統安全性,而不是通過系統化驗證方法)這種論證方式的依賴,轉而追求更系統化的安全論證,而不是簡單地說"這套系統已經用了很多年沒出大問題所以是安全的"。但他也很誠實地承認,如果其他驗證和論證方法仍然不夠充分,proven-in-use可能仍然會是唯一可行的論證手段。
這個坦白特別打動我。研究者和從業者都清楚地知道"用了很久沒出事"不等於"真的安全",但在沒有更好替代方案之前,這種不夠嚴謹的論證方式依然會被使用。這不是掩耳盜鈴,而是在承認現實約束下的一種權衡。
一個嘗試整合一切的框架
基於所有這些訪談內容,論文最後提出了一個叫"證據中心閉環測試框架"的東西,試圖把前面講到的所有零散實踐和挑戰,串成一套結構化的流程。
這個框架分六個階段。第一階段是定義安全聲明和測試意圖,意思是測試不應該從"我們要測哪些場景"開始,而應該從"我們想證明這個系統滿足什麼安全或質量聲明"開始。比如一個泊車系統的安全聲明可能是"車輛在目標泊車運行域內不會撞上靜止或移動的障礙物",這個聲明再被拆解成更具體、可測試的子目標,比如檢測相關障礙物、保持安全距離、無危險行為完成泊車動作。
第二階段是構建並維護一個場景組合庫,場景來源可以是法規標準、專家知識、自然駕駛數據、優化技術、AI輔助生成等多種渠道,每個場景都要打上儘可能豐富的標籤,比如來源、運行域標籤、稀有度、關鍵程度、真實性置信度、預期行為等,這樣才能清楚知道每個場景在整體測試目標中扮演什麼角色。
第三階段是規劃證據生產和測試環境路由,意思是根據每個場景需要產出什麼證據,來決定它應該被分配到哪種測試環境,仿真、試車場、還是真實道路,並在正式執行前確認測試就緒狀態,比如傳感器和日誌系統是否配置正確、數據同步是否正常。
第四階段是應用證據門檻和驗收標準,這一步不再單純依賴工程師的經驗判斷,而是設置一系列檢查關卡,比如場景質量關、仿真適配度關、覆蓋率關、性能安全關、數據質量關、變更影響和回歸測試關、部署一致性關、發布就緒關。如果某個關卡沒通過,就要生成更多場景、優化現有場景,或者換個更合適的環境重新測試。
第五階段是構建安全論證並決定推進或發布,把整個測試過程中積累的證據整合成一套結構化的安全論證,據此決定系統是否可以進入下一測試階段、正式發布、在受限運行域內運行、還是需要更多數據或重新設計。
第六階段是從運營中進行閉環學習,把大規模路測和部署後收集到的運營反饋,比如車輛日誌、安全員干預記錄、脫離事件、不可復現故障、部署差異、新遇到的場景,統統反饋回場景組合庫和回歸測試流程里,讓整個測試體系隨著系統的生命周期不斷進化。
這個六階段框架說白了不是一個全新的發明,而是把訪談里散落各處的實踐、痛點和期望,用一條邏輯線串了起來。它最大的價值不在於提出了什麼顛覆性的新方法,而在於第一次把"要證明什麼"、"用什麼場景證明"、"在哪測"、"怎麼判斷夠不夠"、"怎麼從實際運營中學習"這幾件事,明確地連接成了一個閉環,而不是讓它們各自為戰。
這就像修一座橋。以前各家公司都在各自的河段上架橋,有的用木頭,有的用鋼筋,誰也不知道對岸的橋能不能跟自己的接上。這個框架試圖畫出一張統一的施工圖,不強求每家公司用一樣的材料,但至少讓大家知道橋墩要建在哪、跨度該怎麼算、驗收標準怎麼定,這樣將來這些橋才有可能真正連成一條完整的路。
寫在後面
讀完這份訪談整理,我最大的感觸是這個行業遠比外界想像的更"手工"、更依賴經驗判斷。我們平時看到的自動駕駛宣傳總是充滿數字,多少億英里的路測,多少個九的準確率,但訪談里九位一線專家反覆提到的卻是"沒有明確的分界標準""靠經驗判斷""目前還沒有很有效的解決方案"。這種落差挺有意思,因為它說明公開話語和內部實踐之間存在一道明顯的縫隙。
有個細節我一直在想。中國那場36車15場景的ADAS測試,撞出216次碰撞,這個數字放在新聞標題里顯得挺唬人,但讀完整篇論文後我更願意把它理解成一種"壓力測試暴露真相"的健康信號,而不是行業的恥辱。一個願意把系統拉出來公開撞、公開記錄失敗數據的測試活動,本身恰恰是論文裡反覆呼籲的那種"透明度"的雛形。真正讓人擔心的,反而是那些從不公開測試結果、只靠營銷話術講故事的系統。
還有一個問題我沒能在論文裡找到答案,也想留給你:當"proven-in-use"這種靠時間堆出來的信任,和"系統化安全論證"這種靠結構證明出來的信任,兩者都不夠成熟的時候,普通人上車的那一刻,到底應該相信哪一種?
Q&A
Q1：自動駕駛系統測試目前主要用什麼方法？
A：主要採用場景化測試和X-in-the-Loop分階段測試,從模型在環、軟體在環、硬體在環逐步過渡到整車在環測試,再到試車場和真實道路測試,層層遞進驗證系統的功能和安全性。
Q2：為什麼自動駕駛系統在仿真里表現好,到了真實世界卻容易出問題？
A：這就是所謂的sim-to-real gap(仿真到真實的差距),原因包括仿真環境無法完全還原真實世界的物理反射特性、感知模組的接口限制導致某些物體類型無法在仿真中表示、以及仿真平台本身的精度評估標準不明確。
Q3：自動駕駛行業為什麼沒有統一的安全測試標準？
A：因為各家公司很少公開自己的性能數據、測試方法和評估標準,行業內缺乏類似大語言模型領域那樣公開透明的基準測試體系,導致外界無法橫向比較不同廠商系統的真實可靠性水平。
