先說一個場景。
你是一名自動駕駛算法工程師，早上九點打開電腦，第一件事是打開一個GUI地圖編輯器，手動畫一段慕尼黑市區的馬路，畫完之後再切換到另一個資料庫工具，翻找有沒有類似的危險場景可以復用。找到了，你又打開第三個腳本工具，手動改改車輛軌跡讓場景更刁鑽一點。改完之後，運行測試腳本，等結果跑出來，再打開Excel統計成功率和碰撞率。整個流程涉及四五個互不相通的軟體，每一步都要你親自搬磚。
這就是當前自動駕駛「場景測試」的真實狀況：一條流水線,被拆成了好幾個各自為戰的孤島。
**場景測試**：在虛擬環境裡模擬各種交通狀況（比如突然變道的卡車、闖紅燈的行人），檢驗自動駕駛系統會不會闖禍的一種驗證方法。因為真實世界裡的危險場景太貴也太少見，所以行業普遍靠模擬器批量製造這些"邊緣案例"。
TUM（慕尼黑工業大學）團隊的這篇論文,做的事情說起來不複雜:把這條流水線上所有的孤島,全部塞進一個用大語言模型驅動的聊天機器人里,讓你打字聊天就能完成整套測試。這個系統叫PlannerForge。
場景測試為什麼這麼麻煩
行業里有一套經典的六階段測試框架,來自德國Pegasus項目和後續的學術綜述:場景來源、場景生成、場景資料庫、場景選擇、測試執行、結果評估。這六步說起來清楚，但現實中，每一步都是不同的軟體工具在做,彼此之間幾乎零配合。
生成場景靠人工畫圖或寫腳本；從資料庫里挑場景靠人工寫篩選條件；想稍微改改某輛車的行為，往往根本沒有現成工具支持，只能自己動手改配置文件；測試跑完了，規劃器的參數是手動調的；不同規劃器之間要對比，還得各自跑一遍再手動拼數據。整個過程像是雇了五個互不說話的助理，你得親自當傳話筒。
在這篇論文之前，已經有不少研究把大語言模型用到了自動駕駛測試里，但幾乎都只盯著"場景生成"這一個環節。比如ChatScene、TTSG這些工作，專注於用自然語言生成CARLA模擬器里的危險場景；LLM-Attacker專門優化攻擊者軌跡。這些工作各自解決了流水線上的一塊拼圖，但沒有人把整條流水線串起來。這就是PlannerForge要填的空。
一個會聊天的路由器,是怎麼讓流水線活起來的
PlannerForge最核心的設計,是一個叫"模組路由器"（Module Router）的組件。
傳統測試工具是死板的：生成場景後必須先選擇,選擇後必須再修改,修改後才能測試,測試後才能分析,順序完全固定,你沒法半路插一句"等等,我想先改改這輛車的行為"。
**模組路由器**：一個負責理解你說的話屬於哪種操作意圖的LLM組件，它會把你的自然語言請求分類成"修改場景""調參數""跑測試""看分析""隨便問問"這五種動作之一，然後把具體指令轉發給對應的功能模組去執行。
路由器的工作方式分兩步。第一步，LLM先讀懂你這句話到底想幹什麼，把它整理成一個結構化的JSON，裡面寫明"這是MODIFY類型"還有具體要改的參數是什麼。第二步，一個叫"處理引擎"的東西拿著這個JSON，去調用對應的功能模組真正執行操作。
這就像餐廳里的服務生和後廚的關係。你對服務生說"這道菜少放點辣"，服務生不會自己跑去炒菜，他要先聽懂你的意思（辣度調整，具體是這盤菜），然後把這個指令準確傳給後廚。如果沒有這個服務生環節，你得自己衝進廚房告訴廚師，而廚房的流程是死板的先炒後調味,你根本插不進去。路由器扮演的正是這個"翻譯並轉發"的角色，它讓原本必須按順序走的流水線，變成了你隨時可以打斷、隨時可以跳轉的對話。
論文測試發現，一個用正則表達式硬編碼規則做的路由器，只能達到45.5%的準確率。而用LLM做同樣的事，最好的模型能到99.7%。這個差距說明什麼？說明人說話的方式太靈活了，"幫我把這輛車改凶一點"和"讓20026號車開快點"表達的可能是同一個意圖，但字面上完全不像，靠關鍵詞匹配根本兜不住。
場景是怎麼被"生造"出來的
PlannerForge生成新場景，走的是兩階段路子。
第一階段是地圖和交通合成。你說"慕尼黑一個十字路口，中等車流，重點看一輛轉彎的卡車"，LLM會把這句話解析成一個結構化的意圖：地點、道路類型、車流密度、車輛構成、模擬時長。這個邊界框會去調用OpenStreetMap的Overpass接口，抓取真實的路網數據。
**OpenStreetMap**：一個開源的世界地圖數據項目，任何人都能編輯，包含全球真實的道路、建築等地理資訊。
抓到路網之後，交給SUMO微觀交通模擬器去填充車流，讓車輛按照真實的跟車、變道規律動起來，再轉換成CommonRoad格式的場景文件。
**SUMO**：一個開源的微觀交通流模擬軟體，能模擬每輛車的加減速、跟車、變道行為，常用於交通研究。CommonRoad是慕尼黑工大自己開發的自動駕駛場景描述格式，相當於場景文件的"通用語言"。
第二階段是規劃問題的合成：從生成好的場景里，選一輛車當"自車"（ego vehicle），再給它指定一個目標區域，一個完整的可測試場景就成型了。
這裡有個值得說的設計：論文裡明確把"LLM該管什麼"和"LLM不該管什麼"劃得很清楚。LLM只負責把自然語言解析成結構化意圖，剩下的地圖抓取、格式轉換、交通模擬，全部交給確定性的工具去做，LLM完全不碰。
為什麼要這樣切割？因為LLM會犯幻覺,如果讓它直接生成路網拓撲或者車輛軌跡，很可能編出一個不存在的車道ID，或者一條物理上不可能的加速軌跡，這種錯誤一旦混進流水線，可能到最後一步才暴露，返工成本極高。這就像裝修房子時，你可以讓室內設計師（LLM）決定牆刷什麼顏色、家具怎麼擺，但絕對不能讓他去做承重牆的結構計算，那部分必須交給有資質的工程師（確定性算法）用規範公式來算，出了事故設計師賠不起。把幻覺風險死死限制在"語言理解"這一層，後面的幾何和物理計算全靠可驗證的程序，是這套系統能跑得穩的關鍵。
在實驗中，93個查詢里91.5%的場景庫能順利執行，96%的城市、道路、車輛屬性都精準命中了用戶要求。相比一個叫Scenario Factory 2.0的規則式競品，PlannerForge慢了近十倍（21.6秒對2.2秒），但換來的是200個查詢里193個能成功跑完（對方只有144個），而且能針對城市、道路類型這些細節屬性做精確控制，規則式工具根本沒法理解這些自然語言裡的微妙要求。
從資料庫里「撈」場景，比關鍵詞搜索精準多少
如果資料庫里已經有現成的場景，何必重新生成？這就是選擇模組要幹的事。
選擇模組的設計思路是五步走的漏斗式過濾。用戶和LLM進行一場五輪對話，每一輪LLM都從你說的話里抽取一個結構化資訊片段：地理位置、場景標籤、道路網路類型、障礙物設置、速度範圍。每問完一輪，候選場景池就被過濾縮小一次，像是不斷收緊的篩子。
如果這五輪問下來篩出的候選集是空的，系統會退而求其次，用語義相似度搜索兜底。
**語義相似度搜索**：把用戶的話和場景庫里每條描述都轉成向量（一串數字），比較向量之間的接近程度來找相似內容，而不是死板匹配關鍵詞。
論文把這套系統和經典的BM25關鍵詞搜索做了對比。BM25幾乎不花錢不費時（不到0.01秒），但在"第一條結果就命中用戶要求"這件事上，只能做到67.5%，而PlannerForge能做到92%。差距在哪？關鍵詞搜索沒法處理同義改寫、地點的模糊指代，也理解不了隱含的數值範圍要求，比如用戶說"車速大概二十來公里"，關鍵詞搜索根本不知道該匹配哪個區間，而LLM能把這種模糊表達轉成一個具體的速度區間去匹配。
不過這套系統也有個明顯的軟肋：在五個待抽取的資訊槽位里，"場景標籤"這一項的準確率始終卡在64%到67%之間，遠低於其他四項。原因不是漏抽了標籤（漏抽率只有0.3%），而是LLM太愛"加戲"了，它會給場景硬貼上一些資料庫里根本不存在的標籤，比如"交通擁堵"這個標籤被憑空捏造了139次，而實際資料庫里沒有一個場景帶這個標籤。這提醒我們，讓LLM做資訊抽取時，"寧缺毋濫"往往比"儘可能多說"更可靠，多說的部分反而成了噪音。
改場景這件事，為什麼必須繞道SUMO
場景修改模組解決的是一個很實際的問題：CommonRoad里的場景一旦生成，車輛軌跡就是寫死的固定數據。如果你想讓某輛車繞道、讓某輛車變得更激進，直接編輯軌跡坐標，很容易改出一個物理上不可能存在的運動，比如瞬間從靜止變成時速一百公里。
PlannerForge的解法是，把每一次編輯都先轉換成SUMO的路網和路由文件格式，讓LLM在這個格式上做修改，改完之後再轉換回CommonRoad，這個"回爐"的過程會自動保證軌跡的運動學合理性。
這套系統支持四類編輯：軌跡重定向（讓某輛車改走別的路）、行為預設切換（把某輛車的駕駛風格換成"激進型"或"謹慎型"）、車輛增減（往場景里加一輛卡車或刪掉某輛車）、目標點調整（改變自車的行駛目標）。
對比一個叫From-Words-to-Collisions的同類LLM工具，差距非常懸殊。那個工具是直接生成坐標數值，結果大約70%的編輯在物理上根本不成立，相當於讓一輛車瞬間穿牆而過。PlannerForge因為繞道SUMO再轉回來，四類編輯的物理有效率全部保持在94%以上。
這就好比修改一份Word文檔的排版，你可以直接在渲染出來的最終畫面上用畫圖工具塗塗改改，改完之後這份文件已經不是一份能被Word正常打開的文檔了，格式全亂了。而正確的做法是回到Word的編輯界面，用它自帶的排版功能改，改完存盤，打開還是一份規規矩矩的文檔。SUMO在這裡扮演的正是那個"合規編輯器"的角色，繞過它直接改最終坐標看似省事,但產出的東西根本經不起下一步驗證。
十種大模型的「月考」成績單
論文對十種大模型（五個商業API、五個開源模型）在生成、選擇、修改、路由、規劃器測試、性能提升這六大任務上做了系統評測，一共跑了八萬次調用，全程沒有做任何針對性的微調。
結果顯示，各任務的最高分數在0.88到1.00之間，其中生成任務0.957，路由任務0.997，規劃器測試任務甚至有模型拿到滿分1.00。
開源模型的表現出乎意料。參數量在20B到35B之間的開源模型，在三個任務上追平了商業API的水平。這個結果值得琢磨一下：不是說開源模型全面碾壓商業模型，而是說在這些結構清晰、有明確輸出格式約束的任務上，模型的"理解力天花板"其實沒有想像中那麼高，一旦任務本身足夠規整，中等規模的開源模型也能摸到這個天花板。
論文還發現一個有意思的現象：給帶"思考模式"的開源模型（比如Qwen3.6:35b的Think版本）額外疊加思維鏈提示，反而會拉低表現，還會增加延遲和token消耗。這說明外部強加的推理腳手架，可能會和模型自身內置的推理機制打架，就像給一個本來就會自己規劃路線的司機硬塞一張導航圖，反而讓他分心走錯路。
把六個模組串成一條完整流水線（從生成到資料庫、選擇、修改、測試、參數調優）後，用同樣的200個種子查詢測試，商業模型能保住83%的查詢存活到最後一步，開源模型是78%。這個"漏損率"主要發生在選擇和修改兩個環節，因為這兩步涉及最複雜的語義理解。
LLM給規劃器"調參"，成績單能變多好看
論文裡有一組數據格外抓人眼球:用LLM去調整運動規劃器的成本權重參數，在400個測試場景上，成功率從50.4%提升到70.2%，碰撞率從19.0%降到8.4%，而且全程沒做任何專門的微調訓練。
**成本權重**：運動規劃器在做決策時，會給不同的駕駛目標（比如"離障礙物遠一點""加速度小一點""貼近參考路徑"）賦予一個權重數值，權重的組合直接決定了這輛虛擬車最終開出來是什麼風格。手動調這些權重通常需要資深工程師反覆試錯。
用戶可以直接說"配置得更安全一點，把和障礙物的距離權重設成0.4"，LLM就能把這句話翻譯成一份符合格式規範的YAML配置文件，替換掉原來的默認參數。論文測試了gpt-5.4-mini這個模型，在一種進階提示條件下，這項任務拿到了滿分1.000，比裸提示條件下的0.675高出0.325。而對照組用的是一個死板的YAML編輯器，只能做到72.5%。
這組數字背後藏著一個更深的問題：為什麼直接改配置文件的規則編輯器打不過LLM？因為像"開得安全一點"這種表達本身是模糊的，安全對應到具體哪幾個參數、該往哪個方向調、調多少，需要一種語義層面的推斷能力，規則編輯器只能處理你寫清楚變量名和數值的指令，遇到模糊表達就束手無策。
這就像你告訴理財顧問"我想穩一點"，可靠的顧問會理解你說的是要降低股票配比、增加債券比例，具體調整多少個百分點；而一個只會執行"把股票倉位設為30%"這類精確指令的自動交易程序，壓根聽不懂"穩一點"是什麼意思。
寫在後面
讀完這篇論文，最觸動我的不是某個具體的技術指標，而是那個關於"該讓LLM管什麼，不該讓它管什麼"的取捨。
論文裡反覆強調一個原則：LLM只處理語言到結構化輸出的轉換，幾何計算、物理模擬這些確定性的活兒，一律交給傳統算法。這不是一個討巧的工程決定，而是一種對LLM能力邊界的清醒認知，它知道大模型擅長什麼，也知道大模型的幻覺在哪個環節最致命,於是把最脆弱的部分死死焊住，只讓LLM在它真正擅長的自然語言理解上發揮。
另一個讓我意外的細節是那個"場景標籤"抽取失準的案例，139次編造出一個根本不存在的標籤。這提醒我們，評估LLM系統的時候，不能只看"它做對了多少"，還得看"它憑空多做了什麼"。過度自信有時候比徹底沉默更危險，一個說"我不知道"的模型至少不會誤導你，一個信心滿滿編造答案的模型才是真正的隱患。
論文最後也坦白承認了限制：整套系統目前是開環運行的，也就是說其他交通參與者只按照預先錄製好的軌跡走，不會對自車的實際動作做出反應。這在真實道路上顯然是不成立的，真車會因為你的一個急剎車而跟著調整。這個"閉環"的缺口，恰恰是這類工作接下來最值得較勁的方向。
如果有一天，你的車能自己跟工程師說"我覺得這段路測試得不夠狠，再給我加個突然變道的卡車"，那會是什麼感覺？
Q&A
Q1：PlannerForge是什麼？
A：PlannerForge是慕尼黑工業大學團隊開發的一個用大語言模型驅動的自動駕駛場景測試框架，它把場景生成、選擇、修改、執行測試、結果分析這些原本分散的環節全部整合進一個聊天機器人界面，用戶打字聊天就能完成整套自動駕駛測試流程。
Q2：PlannerForge用的是什麼大模型，效果怎麼樣？
A：論文測試了十種大模型，包括Qwen3.6、Deepseek、Gemini、GPT等商業和開源模型。結果顯示各任務最高得分在0.88到1.00之間，20B到35B參數規模的開源模型在多個任務上能追平商業API的水平，且全程沒有做任何針對性微調。
Q3：PlannerForge調整規劃器參數能帶來多大提升？
A：在400個測試場景上，用LLM調整規劃器的成本權重參數後，成功率從50.4%提升到70.2%，碰撞率從19.0%降到8.4%，用戶只需說出類似"配置得更安全一點"這樣的自然語言指令即可完成調參。
