這項由德國慕尼黑工業大學自主車輛系統教席、慕尼黑機器人與機器智能研究所，以及倫敦大學學院聯合開展的研究，已被2026年IEEE國際智能機器人與系統大會（IROS 2026）接收發表。論文編號為arXiv:2607.14387，有興趣深入了解的讀者可通過該編號在arXiv平台查詢完整原文。
自動駕駛汽車上路之前，工程師們需要對它進行海量的"模擬考試"。這些考試不能只在真實道路上做，因為真實道路上很難刻意製造出"闖紅燈的行人"或"突然失控的前車"這類危險場景，而且成本極高、風險極大。於是，工程師們轉向了虛擬仿真：在電腦里搭建一個虛擬城市，讓虛擬汽車在裡面跑各種各樣的險境，以此來檢驗自動駕駛系統是否足夠可靠。
然而，這裡有一個長期困擾研究者的難題：這些"模擬考試劇本"是用一種特殊的編程語言寫成的，工程師得一行行手寫代碼才能描述"在十字路口，一輛卡車突然從左側闖入"這樣的場景。隨著法規要求越來越複雜——光是聯合國的車輛法規就有幾百條——手工編寫這些劇本既費時又費力，根本無法覆蓋所有需要測試的情況。
這個困境催生了一個自然而然的設想：能不能讓AI大語言模型直接"讀懂"法規條文，然後自動幫我們寫出測試代碼？研究團隊圍繞這個設想開發出了Chat2Scenic系統，這是第一個將"疊代式檢索增強生成"思路用於自動駕駛場景腳本生成的完整框架，並在123個真實監管規範場景構成的公開基準上，將代碼編譯成功率從此前最好方法的30%大幅提升至76%以上。
一、自動駕駛測試為何像在寫"劇本"
要理解這項研究解決的問題，可以把自動駕駛測試想像成一場大型話劇的排練。話劇導演（工程師）需要給演員（虛擬汽車）準備詳細的劇本：什麼時候進場、走哪條路線、遇到什麼道具（行人、障礙物、紅綠燈）、劇情如何發展、在什麼條件下結束這場戲。這份劇本必須用仿真軟體能"看懂"的格式寫成，也就是一種叫做"領域特定語言"（Domain Specific Language，簡稱DSL）的專用編程語言。
其中最常用的一種DSL叫做Scenic，它可以和CARLA這款開源自動駕駛仿真平台配合使用。用Scenic寫出的一段代碼，可以描述"在一個有四條車道的十字路口，一輛林肯
MKZ沿直線行駛，同時一輛垃圾車靜止在行車道中央，天氣為晴天，場景在自動駕駛車輛行駛超過50米後結束"。這段代碼一旦運行，CARLA就會在虛擬城市裡真實呈現出這個畫面。
問題在於，法規文本用的是自然語言，比如"當前方有靜止障礙物時，車輛應能在規定距離內完成緊急變道"。把這句話翻譯成幾十行Scenic代碼，對人類工程師來說就已經很費腦筋，對AI來說更是挑戰重重：AI必須理解場景的語義、掌握Scenic的語法規則、還要確保生成出來的代碼能真正跑起來而不報錯。
在這項研究之前，學術界主要有兩種思路來應對這個挑戰，但兩種思路都有各自的硬傷。第一種叫"檢索拼裝"：先把大量已有的Scenic代碼片段存進資料庫，遇到新場景需求時，AI從資料庫里找相似的片段拼在一起。這種方式就像用現成的樂高積木拼房子，拼出來的東西通常能用，但如果遇到資料庫里沒有的形狀，就完全束手無策。第二種叫"直接生成"：讓AI從頭到尾一口氣寫出完整的Scenic程序。這種方式創造力強，但就像讓一個人一口氣背誦一篇從未見過的幾百字文章，出錯率極高，生成出來的代碼往往因為語法問題根本跑不起來。
Chat2Scenic的核心創新，正是找到了一條繞開這兩條路各自死角的第三條道路。
二、三個核心模組：像流水線一樣協作的"劇本工廠"
Chat2Scenic的工作方式，可以用一家專業劇本工廠來類比。這家工廠有三個車間：前台接待室負責聽清楚客戶的需求、資料查閱室負責找到相關的專業資料、生產車間負責一個零件一個零件地組裝劇本。
**前台接待室：互動模組**
當用戶用自然語言輸入一段場景描述，比如"前車突然向左變道以躲避一輛靜止的摩托車，導致自動駕駛跟車處於高度緊急狀態"時，互動模組首先登場。這個模組基於Gradio框架搭建了一個聊天機器人界面，用戶可以像和人聊天一樣描述場景，甚至可以在AI理解有偏差時進一步修正和追加說明。
更關鍵的是，互動模組內置了一個"解讀員"。這個解讀員會把用戶的自然語言描述分解成四類結構化資訊：空間關係（路的形狀、各個車輛的相對位置）、自動駕駛主車的行為參數、其他參與者的資訊（比如那輛靜止的摩托車）、以及限制條件（比如場景什麼時候結束）。這四類資訊合起來，加上地圖、天氣、車輛型號等全局配置，就構成了一張完整的"場景需求清單"。
這張清單的每一個條目都被壓縮成一句簡潔的描述，比如"一輛摩托車靜止在車道中央作為障礙物"。這句話隨後會被送到資料查閱室去匹配相關素材。整個解讀過程還支持多輪對話——用戶發現AI理解有誤時，可以直接追加說明，系統會記住整個對話歷史，無需重新開始。
**資料查閱室：RAG模組**
RAG是"檢索增強生成"（Retrieval-Augmented Generation）的縮寫，簡單說就是在AI生成答案之前，先讓它查一查相關資料，避免憑空亂編。Chat2Scenic的資料查閱室里存放著兩類檔案。
第一類是代碼片段資料庫。研究團隊把官方Scenic示例代碼拆解成一個個獨立的小零件，每個零件對應一類場景元素——比如"車輛直行"、"行人穿越馬路"、"車輛在路口轉彎"等等。每個零件都配有一句自然語言說明，用向量嵌入（一種讓AI理解語義的技術）的方式儲存，方便後續根據語義相似度快速檢索。
第二類是文檔資料庫，裡面存放著Scenic的官方語法文檔，以及聯合國車輛法規R152、R157、R171等真實監管規範。這些文檔被切割成語義完整的段落塊，同時支持兩種檢索方式：一種是基於關鍵詞精確匹配的BM25檢索（類似於搜尋引擎的關鍵詞搜索），另一種是基於語義相似度的向量檢索。兩種檢索結果通過一種叫做"互惠排名融合"的算法合併排序，確保既能找到精確的API定義，也能捕捉到語義相關的背景知識。
這種"雙檢索器架構"的好處在於：當AI準備寫某個代碼片段時，它既能看到"別人是怎麼寫類似代碼的"（代碼片段），也能查閱"這個功能的官方說明是什麼"（文檔），兩者結合大大降低了生成出語法錯誤代碼的概率。
**生產車間：生成模組**
有了需求清單和參考資料，生產車間就開始按順序逐塊組裝劇本。這個"逐塊組裝"正是Chat2Scenic區別於以往方法的最關鍵特點。
工廠不是讓AI一口氣寫完整個劇本，而是把整個劇本拆成幾個標準零件，按照嚴格的依賴順序逐個生成：先生成全局配置（地圖、天氣、車輛型號），再生成空間關係代碼，然後是主車行為代碼，接著是每一個場景參與者的代碼，最後是限制條件代碼。每生成完一個零件，就把它加入"已生成代碼"的上下文，作為下一個零件生成時的參考。
這就像流水線上的工人：做車門的工人先量好車身的尺寸，確保車門裝得上去；裝發動機的工人參考了車底盤的規格，確保發動機能塞進去。每一步都參考前一步的成果，最終組裝出來的整車各零件之間天然兼容，不會出現"車門裝不上去"這種問題。相比之下，直接生成整個劇本就像讓一個工人同時記住所有零件的規格，一次性焊接完成，出錯的概率自然高得多。
三、四種"提示技巧"：教AI說專業語言的四套教材
生產車間裡的每個AI生成步驟，都使用了四種精心設計的"提示工程"技巧，可以把它們理解為教AI完成任務時用到的四套配套教材。
第一套叫"情境提示"（Contextual Prompting）。在發給AI的指令里，直接塞入Scenic語言的語法規則、類型層次體系（比如"道路網路元素→線性元素→道路/車道"這樣的分類樹）和可用的操作符。這就像給剛接手新工作的員工一份詳盡的崗位手冊，讓他在完成任務時隨時查閱。
第二套叫"思維鏈"（Chain of Thought）。要求AI在生成代碼之前，先按照規定的步驟思考一遍。比如生成主車行為代碼時，AI必須依次完成"理解需求→檢查上下文→選擇車輛類型→定義參數→定義行為→實例化→驗證"這七個思考步驟，然後再輸出代碼。這就像讓工人在動手之前先在腦子裡過一遍施工圖紙，減少返工。
第三套叫"少樣本學習"（In-Context Learning）。在指令里提供若干示例，包括正確寫法的範例和常見錯誤的對照示例。AI通過觀察這些例子，理解什麼叫"對"、什麼叫"錯"。研究者特別設計了包含錯誤修正的"負面示例"，幫助AI主動規避已知的坑。
第四套叫"檢索增強少樣本學習"（Retrieval-Augmented In-Context Learning）。這套教材是動態的：每次生成時，系統會根據當前任務的具體描述，實時從資料庫里撈取最相關的代碼片段（最多三個）作為示例，同時檢索最相關的文檔段落作為背景說明。與固定的示例集相比，動態檢索的好處在於示例始終和眼前的任務最相關，並且資料庫可以持續擴充，讓整個系統隨時間推移越來越聰明。
實驗結果清晰地揭示了這四套教材疊加的效果。從完全沒有任何提示技巧的零樣本基線出發，代碼編譯成功率是0%——AI完全不知道怎麼寫Scenic代碼。加入情境提示後，成功率升到12.2%。再加入少樣本學習，跳升至47.15%。進一步疊加思維鏈，達到54.47%。最終四種技巧全部疊加（但去掉文檔檢索，因為文檔檢索反而增加耗時但不提升成功率），編譯成功率達到76.42%，整體框架準確率為58.17%。
四、用123個真實法規場景來"閱卷"
為了客觀衡量Chat2Scenic的表現，研究團隊專門搭建了一套評測基準，這在這個領域此前是空白的。
這套基準收錄了123個真實場景描述，來源涵蓋三個方向。其一是CARLA自動駕駛挑戰賽的24個官方測試場景，覆蓋無信號燈路口通行、緊急變道等典型危險情況。其二是美國國家公路交通安全管理局（NHTSA）的47個事故分析場景，其中16個來自真實碰撞數據，31個來自碰撞前的預警情境，包括行人橫穿多車道這類高危場景。其三是聯合國車輛法規中的52個測試場景，涉及R152（緊急制動輔助）、R157（自動變道系統）和R171（駕駛員警示系統）三部法規，場景複雜度最高，描述往往包含大量技術細節和約束條件。
這123個場景分布極為多樣：有純車輛交互場景，有涉及行人和騎行者的脆弱道路使用者場景，有需要響應交通信號的場景，有不同天氣時段的場景，還有描述複雜動態行為的場景。如此豐富的覆蓋面，確保評測結果不會是在某類簡單場景上的"偏科"表現。
評測使用了兩層指標體系。框架性能層面，研究團隊統計了代碼編譯成功率（生成的代碼能否真正在CARLA里跑起來不報錯）、每個場景的平均生成時間，以及消耗的平均詞元數量（衡量AI的"思考量"和經濟成本）。場景生成質量層面，由人工評測員對成功編譯的場景逐層評分，評分維度包括道路幾何是否正確、交通設施是否到位、時間天氣是否符合描述、動態物體行為是否準確、環境條件是否匹配，最終匯總成一個"場景質量分"。框架準確率則等於編譯成功率乘以場景質量分，是衡量端到端整體水平的綜合指標。
五、大比武：哪款AI最擅長寫自動駕駛劇本
研究團隊在同一套基準上測試了十餘款大語言模型和兩套此前的最優方法，結果呈現出幾個鮮明的規律。
先看開源模型的表現。Qwen3-Coder:30B、Qwen3:30B和Gemma3:27B三款模型的編譯成功率均為0%，幾乎完全無法生成可運行的Scenic代碼。GPT-OSS:20B和Mistral-Small3.2:24B略好，但成功率也只有不到2%。開源模型的集體失利，主要歸因於參數規模相對較小、預訓練數據覆蓋的Scenic代碼量有限，以及在多種複雜提示技巧交織使用時，跟隨指令的能力不足。
商業模型的表現則參差不齊。DeepSeek-V3.2的兩種模式（聊天版12.2%，推理版14.63%）、Qwen系列各版本（從1.63%到15.44%不等）均遠低於Gemini-3系列。Gemini-3-Pro達到60.16%，而Gemini-3-Flash以76.42%的編譯成功率和58.17%的框架準確率拔得頭籌，成為Chat2Scenic框架的最優搭檔。
一個出人意料的發現是：Gemini-3-Flash（非思維增強版）的表現優於Gemini-3-Pro。研究者給出的解釋是：帶有深度內部推理能力的"思維模型"，在面對包含多種外部提示結構的複雜指令時，內外兩套思考機制之間容易相互干擾，反而降低效率；而專門針對指令跟隨優化的Flash版本，能更穩定地執行結構化提示模板，從而發揮出更強的整體性能。
再看與兩套"前輩方法"的橫向對比。ChatScene採用檢索拼裝方式，從CARLA挑戰賽的現有代碼庫里檢索片段進行拼接，在Gemini-3-Flash的加持下編譯成功率為30.08%，框架準確率11.03%。NL2Scenic採用檢索式完整腳本生成，編譯成功率僅16.26%，框架準確率10.86%。Chat2Scenic的76.42%編譯成功率，分別是這兩套方法的2.5倍和4.7倍，框架準確率則分別是5.3倍和5.4倍。
ChatScene略優於NL2Scenic的原因也在情理之中：ChatScene用的是真實可運行的代碼片段拼在一起，只要片段本身沒問題，拼裝結果通常能編譯；而NL2Scenic要讓AI一口氣生成完整程序，對於複雜場景描述，任何一處語法疏漏都會導致整個程序崩潰。Chat2Scenic的逐塊疊代生成策略，則從根本上化解了這兩種方式各自的軟肋。
至於響應時間的代價，Chat2Scenic平均每個場景需要約222秒。相比ChatScene的10秒和NL2Scenic的43秒，確實慢了許多。不過研究者指出，自動駕駛測試場景的生成屬於離線工作——工程師不需要實時等待，花三四分鐘換來可靠的測試代碼，這筆賬在實際工程中完全划算。
六、三幅真實畫面：系統生成的場景長什麼樣
論文中展示了三個成功生成並在CARLA中運行的典型場景，從鳥瞰視角、第一人稱視角和第三人稱視角多角度展示了虛擬場景的視覺效果。
第一個場景來自CARLA挑戰賽的描述，呈現的是自動駕駛主車需要通過一個無信號燈路口，與其他車輛協商通行權的情境，遵循"先到先過"的規則。從生成的影片畫面可以看到，虛擬城市路口的細節相當真實，車輛的相對位置和運動軌跡與描述完全吻合。
第二個場景來自聯合國R171法規，描述的是主車跟隨前車行駛，前車突然向旁邊車道偏移以躲避車道中央靜止的摩托車或重型卡車。生成的場景在時間步進畫面中清晰展示了前車的偏移軌跡和靜止障礙物的位置，完全符合法規測試的意圖。
第三個場景來自NHTSA事故數據，描述行人在無人察覺的情況下橫穿多車道道路，駕駛員當時的注意力分散在其他車輛和交通控制設施上。這類涉及脆弱道路使用者的場景，正是自動駕駛系統最難應對的危險情況之一，也是測試中最重要的覆蓋點。
---
說到底，Chat2Scenic幹的事情，是在自動駕駛驗證這個領域打通了一條此前走不通的捷徑。工程師不再需要逐行手寫仿真測試代碼，也不再受限於資料庫里現有的有限場景；只需要用普通語言描述一個場景，甚至直接粘貼一段法規原文，系統就能自動生成可以真正運行的測試劇本。76%的編譯成功率意味著大約每生成四個場景，只有一個需要人工干預修復，這在工程實踐中已經足夠有用。
當然，這條路還沒走到盡頭。目前系統還只能處理文字描述，如果能讓工程師直接上傳一張手繪的路口草圖、或者一段真實事故的行車記錄儀影片，系統自動據此生成測試場景，那將會更直接、更直觀。另外，現在生成的場景在運行一遍之後就結束了，未來如果能讓仿真結果實時反饋給生成系統——比如"這個場景里主車根本沒有機會觸發緊急制動，請調整參數使場景更具挑戰性"——就能形成一個自我進化的閉環，讓測試覆蓋越來越全面、越來越有針對性。
這項研究提醒我們，大語言模型不只是寫文章、聊天的工具，當它和專業領域的結構化知識、疊代反饋機制結合在一起時，可以成為工程師手中真正好用的專業工具。對自動駕駛行業來說，更高效地覆蓋測試邊界，最終意味著路上的每一輛自動駕駛汽車更安全、更可靠。
---
Q&A
Q1：Chat2Scenic生成的Scenic代碼能直接用於真實自動駕駛系統的測試嗎？
A：Chat2Scenic生成的Scenic代碼適用於CARLA仿真平台中的虛擬測試，生成的場景是在電腦里運行的虛擬仿真劇本，而非控制真實道路上的汽車。工程師可以用這些虛擬場景來驗證自動駕駛算法的行為，但從仿真結果到真實道路部署之間還需要額外的驗證步驟。
Q2：Chat2Scenic為什麼選擇逐塊生成而不是一口氣生成完整代碼？
A：一次性生成完整Scenic程序時，大語言模型需要同時兼顧所有組件之間的語法兼容性，任何一處疏漏都會導致整個程序報錯無法運行。Chat2Scenic的逐塊疊代方式讓每個代碼片段在生成時能參考已有的上下文，確保各部分天然兼容，這是編譯成功率從16%跳升至76%的核心原因。
Q3：開源大語言模型能不能在Chat2Scenic框架里達到和Gemini相近的效果？
A：根據論文的測試結果，目前測試的開源模型（包括Qwen3:30B、Gemma3:27B等）編譯成功率幾乎為零，主要原因是參數規模和預訓練數據的差距，以及在處理多種提示技巧交織的複雜指令時指令跟隨能力不足。未來隨著開源模型能力持續提升，這一差距有望縮小。
