让大模型写自动驾驶测试代码,编译率从16%飙升到76%

自动驾驶行业有个老生常谈的难题：如何高效地构造足够多、足够硬核的测试场景？路测成本高、覆盖面窄，仿真测试是公认的解法。但在仿真环境里跑场景，你得有一份可执行的脚本——通常是 Scenic 这种领域特定语言（DSL）写出来的代码。问题来了：法规文件里写的"前方车辆突然变道、本车紧急制动"这类自然语言描述，怎么自动变成一段能编译通过、语义准确的 Scenic 程序？

用大语言模型直接生成完整脚本？编译成功率不到 17%。从数据库里拼凑现成代码片段？编译能过，但泛化能力差，遇到新场景就傻眼。慕尼黑工业大学联合伦敦大学学院团队提出的Chat2Scenic，在这个"编译率 vs 泛化性"的死胡同里另辟蹊径——用迭代式组件级生成配合 RAG 检索增强，把编译成功率拉到了 76.42%，框架准确率达到 58.17%，两项核心指标分别碾压既有方案数倍。论文已被 IROS 2026 接收。

一、问题出在哪：两代方法的根本矛盾

现有的 DSL 场景生成路线大致分两派，各有各的硬伤。

检索拼装派（Retrieval-Assemble）的做法是先建一个代码片段库，用 LLM 把用户的自然语言需求映射到库里最接近的片段，再拼接成完整脚本。TARGET、ChatScene、Text2Scenario 都是这个思路。好处是"有据可查"——每个片段本身都是经过验证的代码，拼出来的东西编译通过的概率相对较高。但代价也很明显：你的场景天花板就是数据库的边界。库里没有的交互逻辑、没见过的交通行为，这条路基本走不通。这类方法的编译成功率（CSR）大概在 30% 左右徘徊，框架准确率（FA）只有 11%。

直接生成派（Direct Generation）则更激进，让 LLM 从零开始一口气写出完整 Scenic 脚本。LEADE、LeGEND、ScenicNL、NL2Scenic 等都属于这一类。理论上泛化性更强，毕竟不受代码库限制。现实却很骨感——Scenic 语法有一定门槛，变量引用、空间约束、终止条件这些要素之间牵一发动全身。LLM 一次性生成几十行代码，变量名对不上、依赖关系写乱、语法细节出错是常态。即使引入了思维链（CoT）、上下文学习（ICL）等高级提示技术，编译成功率依然只有约 16%，框架准确率仅 10.86%。

图1：检索拼装、直接生成与迭代组件级生成三种范式的核心差异

更关键的一点是，此前几乎所有方案都只用简化的场景描述作为输入——"一辆车在前方路口左转"这种程度的文字。但真正有行业价值的场景，应该来自 NHTSA（美国公路交通安全管理局）法规、联合国车辆法规（UN Regulation）等正式文件，那些描述动辄上百字，嵌套多种条件和约束。Chat2Scenic 是首批把这类法规级复杂文本作为标准输入的工作之一。

二、拆解 Chat2Scenic：三个模块如何协作

Chat2Scenic 的整体架构由交互模块、RAG 模块和生成模块组成，数据流从用户输入一路流到可执行的 Scenic 脚本。

图2：Chat2Scenic 框架三模块协作流程

2.1 交互模块：先把需求"翻译"成结构

用户可以用自然语言描述想要测试的场景，框架底层会通过一个基于 Gradio 的聊天界面进行多轮交互。这个模块的核心能力不在于"聊天"，而是把一段模糊的自然语言描述解析为一个结构化的逻辑表示S = {G, R, E, O, T}。其中 G 是全局配置（地图、天气、车辆型号），独立于场景逻辑单独提取；R 是空间关系（道路拓扑、实体间相对位置）；E 是主车行为（速度、路线）；O 是障碍物集合；T 是约束条件（初始状态、终止条件）。

图3：场景描述被拆解为五个逻辑组件的结构示意

这个拆解策略相当务实。每个组件只对应一句精炼的自然语言描述，比如 R 组件可能是"主车沿双向四车道行驶，前方 50 米处有一辆同向行驶的轿车"。这种粒度的语义描述恰好对齐了代码片段库中的条目格式，也为后续的检索和逐组件生成铺好了路。解释器借助 LangGraph 的状态检查点机制维持对话上下文，用户随时可以修正某个组件的理解，不需要推倒重来。

2.2 RAG 模块：双检索器架构

RAG（检索增强生成）在 Chat2Scenic 里不是简单的外挂，而是被设计成了两条相互独立的检索通道，分别服务不同的信息需求。

图4：代码检索器与文档检索器的并行检索架构

代码片段检索器走的是纯语义搜索路线。团队从 Scenic 官方源码中收集了大量场景，将其拆解为覆盖 R、E、O、T 四类组件的独立代码单元。每个单元附带一句由 LLM 生成的摘要描述，再通过 sentence-transformers（all-MiniLM-L6-v2）编码为向量。生成某个组件代码时，系统拿该组件的自然语言描述做语义查询，召回最相关的代码片段作为上下文喂给生成模型。

文档检索器则走混合检索路线，同时使用语义向量和 BM25 关键词匹配。这个库的内容来自 Scenic 官方文档以及 NHTSA、联合国车辆法规等监管文件。文档经过清洗后被按层级结构分块，确保检索时不会丢失上下文。两条通道的检索结果在进入生成阶段前进行融合，保证模型同时拥有"怎么写代码"和"法规怎么要求"的双重知识支撑。

2.3 生成模块：逐个击破，迭代推进

生成模块的设计思路是 Chat2Scenic 区别于此前所有方案的关键。它不做一次性全量生成，也不做简单的片段拼装，而是走了一条"逐组件迭代生成"的中间路线。

图5：迭代组件级生成的逐步推进过程

具体而言，全局配置 G 由一个独立的"全局配置生成器"提取，与场景逻辑解耦。场景内部的四个组件 R、E、O、T 则由"迭代组件生成器"逐一处理——每生成一个组件的 Scenic 代码，就用编译器检查是否通过。如果通过，已生成组件的代码会作为后续组件生成的上下文，确保变量引用一致性和组件间兼容性。如果编译失败，系统会基于报错信息重试。这种"写一段、验一段、再写下一段"的策略，本质上把一个大模型不擅长的长代码生成任务拆解为若干个短代码生成任务，每个任务的复杂度大幅降低。

在提示工程方面，Chat2Scenic 组合运用了多种技术：上下文提示（Contextual Prompting）将已有组件代码注入后续生成的上下文窗口，思维链（CoT）引导模型分步推理，上下文学习（ICL）提供参考示例，RAG-ICL 则将检索到的代码片段作为动态 in-context 示例。这些技术层层叠加，不是堆砌噱头，而是每一层都在解决一个具体问题——上下文提示管组件间一致性，CoT 管生成逻辑链，ICL 管语法模板，RAG-ICL 管领域适配。

三、实验表现：数据说话

团队构建了包含 123 个场景的基准测试集，覆盖 CARLA 排行榜、NHTSA 法规和联合国车辆法规等多个来源，并在六款主流大模型上进行了全面评测。

3.1 与现有方案的正面交锋

核心对比如下表所示（以 GPT-4o 作为 backbone 的结果）：

图6：Chat2Scenic 与两类现有方法在编译成功率和框架准确率上的差距

这两组数字的差距之大，在 DSL 代码生成领域相当少见。CSR 从 30% 到 76% 是 2.5 倍的提升，FA 从 11% 到 58% 是 5 倍以上的飞跃。值得注意的是，检索拼装方法的 CSR 虽然有 30%，但 FA 只有 11%——这说明即使编译通过了，语义正确率也极低，生成的脚本可能在语法上没问题但执行出来的行为跟预期完全不同。Chat2Scenic 在保持高编译率的同时把 FA 也拉到了接近 60%，说明生成的代码不仅是"能跑"，而且在语义层面忠实于原始需求。

3.2 消融实验：每个组件的贡献

消融实验揭示了各提示技术的增量贡献。从 Baseline 出发，逐个叠加 CoT、ICL、上下文提示、RAG-ICL，每一步都有可观的性能增益。RAG-ICL 是收益最大的单项，验证了检索增强的上下文学习在 DSL 代码生成中不可替代的地位。上下文提示的贡献紧随其后，说明组件间的依赖关系确实是影响编译通过率的头号障碍——把前面已经生成的、编译通过的代码作为后续生成的参考，比让模型"凭空想象"后续代码靠谱得多。

图7：逐个叠加提示技术后的性能变化趋势

3.3 跨模型表现

评测覆盖了闭源和开源两阵营：GPT-4o、Claude-3.5-Sonnet、Gemini-1.5-Pro 属于闭源侧，Llama-3.1-70B、DeepSeek-V3、Qwen-2.5-72B 属于开源侧。GPT-4o 整体表现最优，Claude-3.5-Sonnet 紧随其后且差距不大。值得关注的是 DeepSeek-V3 在开源模型中展现出极强的竞争力，某些指标上已经逼近闭源模型水平。这一发现对业内团队有实际参考意义——如果出于成本或部署灵活性考虑不想用闭源 API，DeepSeek-V3 是一个值得优先尝试的选择。

图8：六款主流大模型在编译成功率和框架准确率上的表现

四、深度剖析：为什么这个思路能成？

跳出论文本身的实验框架，从更宏观的视角审视 Chat2Scenic 的方法论价值。

Chat2Scenic 的核心洞察可以归纳为一句话：与其让 LLM 做它不擅长的事（写几十行互相耦合的代码），不如把任务拆成它擅长的粒度（写几行独立的代码块），再用工程化的流程把它们组装起来。这个思路在其他代码生成领域其实已有苗头——比如软件工程中的函数级生成、分文件生成。但在 DSL 场景生成这个特定领域，Chat2Scenic 是首次系统性地把"迭代组件级生成"做成完整框架的工作。

双检索器设计也值得细品。代码片段库和文档库的分工不是随意为之——前者提供"语法正确性锚点"，后者提供"语义合规性约束"。对于一个需要同时满足"能编译"和"符合法规"双重目标的任务来说，这种双轨知识供给比单一知识源有效得多。尤其是在处理来自 NHTSA 和联合国法规的复杂描述时，文档检索器提供的法规原文片段能让生成模型"有据可依"，而不是靠自身参数中模糊的法规知识去猜。

迭代生成策略还有一层容易被忽略的价值：可调试性。如果一次性生成完整脚本后编译失败，你很难定位是哪部分出了问题。但在迭代框架里，每个组件独立编译，一旦某个组件出错，错误范围被天然隔离在该组件内部，重试成本远低于全量重写。这种"分治"思想在工程实践中已经被验证过无数次，Chat2Scenic 把它嫁接到了 LLM 代码生成的场景中。

五、不足与行业落地思考

再亮眼的数据也不能掩盖现有局限，冷静审视才能看清技术的前路。

最直接的短板是 FA 58.17% 意味着仍有超过四成的场景在语义层面存在偏差。编译通过不等于行为正确——比如法规要求"前车在距本车 30 米处开始制动"，但生成的脚本可能写成了 20 米。这类数值偏差在仿真测试中可能直接导致完全不同的碰撞结果，对安全验证而言是不可忽视的风险。论文目前通过人工评估语义准确性，评估成本高且存在主观性，未来引入自动化语义验证机制是必要的。

另一个值得关注的问题是生成效率。逐组件迭代虽然提升了准确率，但也意味着更多的 LLM 调用次数。一个包含 4 个组件的场景至少需要 4 次生成 + 编译循环，加上可能的重试，延迟和 API 成本都会叠加。在需要批量生成成千上万个测试场景的工业场景下，这个成本需要被仔细权衡。如果未来能对简单场景自动跳过迭代直接生成、仅对复杂场景启用完整迭代流程，或许可以在速度和质量之间取得更好的平衡。

从行业落地的视角看，Chat2Scenic 的思路有几个方向值得进一步探索：一是与场景数据库的深度整合，让它不只是从开源 Scenic 示例中检索，而是接入车企自有的场景库；二是扩展到更多 DSL 格式（如 OpenSCENARIO、OpenDRIVE），降低对特定仿真平台的绑定；三是在生成的脚本基础上增加自动仿真执行和结果反馈回路，形成"生成-仿真-评估-修正"的闭环。

代码已在 GitHub 开源。对于一个致力于推动自动驾驶仿真测试标准化的行业来说，这种开放态度本身就有不小的价值——至少它提供了一个可以被第三方复现、比较和改进的统一基准，而不像此前很多工作那样缺少公开代码，让对比验证成为空谈。