世界模型与大语言模型融合：自动驾驶算法的新范式

为什么预测下一帧和理解一句话这两件事正在改变自动驾驶算法的天花板先说一个可能让很多人意外的判断纯靠撞出来的端到端驾驶模型正在逼近瓶颈。过去几年行业内卷的方向是把感知做到极致——检测精度、分割精度、跟踪鲁棒性一项项指标刷到接近满分。但真把车放到开放道路上还是会遇到一类非常尴尬的场景一个施工牌旁边站着个挥小红旗的大爷全世界任何公开数据集里都没见过这个组合。感知模型可能正确识别了施工牌和人但下一步该做什么它不知道。这时候两类技术被推到台前。一类叫世界模型它的核心任务是让车想象未来——给定当前场景预测接下来几秒内会发生什么。另一类是大语言模型LLM它的核心任务是让车理解规则——把交通法规、驾驶常识、甚至人类司机的口头指令变成可执行的驾驶决策。我在这个方向泡了大半年跑过公开数据集、复现过论文、也自己搭过最小原型。这篇文章不打算写综述式的大而全而是把世界模型 大语言模型结合开发自动驾驶算法这件事拆成几个真正值得动手的部分底层逻辑、模块设计、参考代码、以及那些论文里不会明说的坑。想入门这个方向、或者正在纠结技术选型的读者应该能在里面找到一些实在的东西。1. 为什么需要既懂物理又懂常识的自动驾驶系统1.1 感知模型的确定性幻觉有多危险自动驾驶行业过去十年的大部分工作都建立在感知-预测-规划这个模块化pipeline上。感知模块把传感器数据变成结构化结果——车道线、障碍物边界、交通信号灯状态——然后预测模块基于这些结果去推断其他交通参与者的意图最后规划模块算出一条轨迹。这套体系有一个致命的前提假设感知结果必须完全正确。一旦感知出错后面的流程全部建立在错误地基上。而现实是感知模型永远存在长尾问题。我跑过一个在NuScenes上表现很好的检测模型到了含有雨雾遮挡的复杂场景精度直接掉到不足七成。这意味着传统pipeline里感知错误会像滚雪球一样传导到下游。但更本质上讲感知-预测-规划的级联架构从第一天起就是别扭的。人类开车时不会先把视野里的东西全部框出来再决定怎么开而是对场景有一个整体理解——哪条道能走、哪个方向的来车可能抢道、前面那片阴影里会不会窜出人。这种整体理解恰恰是模块化pipeline最缺的东西。1.2 世界模型补足物理规律大语言模型补足社会规则世界模型试图解决的是让系统具备对物理世界的想象力。它学习的是一个关于场景演化的时空模型给定当前的多视角视频和自车状态预测下一帧或多帧会发生什么。这个能力直接对应人类开车时的预判——不是等前车刹车灯亮了才反应而是看到前车靠近路口就提前收油门。大语言模型解决的则是另一个维度的问题。交通不只是物理运动更是一套社会契约。红灯停绿灯行、实线不能变道、斑马线前要减速、看到校车要等待——这些规则在数据里稀疏出现靠感知模型很难学透但正好是大语言模型擅长的它训练语料里包含了大量类似文本天然具备规则理解和逻辑推理能力。所以一个合理的判断是世界模型负责回答接下来世界会怎样大语言模型负责回答面对这种情况我该怎么做。前者解决动态场景的问题后者解决规则与交互的问题。两者不是同一件事的两种叫法而是互补的两个层面。1.3 当前行业里的结合处于什么阶段坦白说这个方向现在还没有一个公认的终局架构。不同团队的做法差异很大有的用世界模型生成预测结果把预测结果翻译成文本喂给LLM有的把LLM当作常识判断器在规划模块的候选轨迹后加一道语言校验还有的尝试把LLM嵌入世界模型的prompt空间用自然语言控制场景生成的条件。但从技术趋势看有一个共识正在形成纯视觉或纯语言的单一路线都不够核心突破口在多模态融合的交互机制上。这也是我认为这个方向值得投入的原因——它还没有被固化谁先在这个交叉点上做出靠谱的系统谁就能占住下一个身位。2. 世界模型与大模型的角色分工谁负责想象谁负责推理2.1 世界模型的核心机制不是视频生成而是时空推理很多初次接触世界模型的人会把它误解成视频预测器——输入几帧图像输出未来几帧动画。这种理解有偏差。视频预测只是世界模型的一种表现形式更深层的价值在于它内部需要建立一个隐式的时空状态表征。以Wayve的GAIA-1为例它的做法是把驾驶视频切分成视觉token序列用一个类似GPT的架构去预测下一个token。给定前几秒的驾驶画面模型能生成后续几秒的合理未来。关键点是为了生成合理的未来模型内部必须隐式理解车辆动力学、物体遮挡关系、光线变化规律——这些就是物理规律。换句话说生成未来是手段学会物理是目的。我在复现类似思路时最早犯过一个错误直接拿现成的图像生成模型来预测下一帧结果物体边缘糊成一片车开过去之后的位置完全不符合运动学约束。后来换个思路先让模型学习矢量化的场景表征自车位置、车道拓扑、目标物轨迹再做未来推演效果就正常多了。这说明世界模型的设计重点是合适的表征空间而不是视觉上的以假乱真。2.2 大语言模型的角色从对话到驾驶决策的翻译层LLM在自动驾驶里能干什么取决于你把它放在什么位置。目前公认比较务实的一个定位是作为指挥层和翻译层而不是底层执行器。指挥是指LLM理解高层次指令。举个例子用户说前方路口右转注意右侧来车LLM需要把这句话转换成一连串可执行的子目标变道到最右侧车道、降低车速、观察右侧盲区、到达路口右转。这个把语言指令翻译成结构化决策树的角色底层感知和规划模型难以做到。翻译是指把感知结果翻译成LLM能理解的语言符号。比如世界模型预测出前方5秒内有一辆自行车会切入本车道这个预测结果需要转成文本描述前方有一辆速度约15km/h的自行车预计5秒后切入本车道才能喂给LLM做规则判断。这里有一个很实际的技术问题如何设计一个高质量的场景描述生成器。我在项目里用基于规则的模板加上关键数值填充一开始效果还不错但场景复杂到一定程度后就捉襟见肘了——规则模板难以覆盖无限的长尾场景。后来换成基于视觉大模型的结构化场景问答才解决了这个问题。2.3 两者结合的必然性各自的能力边界恰好互补做自动驾驶算法最大的困惑是为什么感知、预测、规划每个模块单独看指标都不错合起来系统却不可靠我的理解是这三个模块本质上在各自的空间里求解缺乏一个统一的世界尺度来对齐。感知模块在图像空间工作预测模块在轨迹空间工作规划模块在控制空间工作信息流转过程中大量语义信息被压缩丢失。世界模型提供了一个连续时空的推演环境让系统能在想象空间里验证决策的后果LLM提供了一个高层的语义空间让系统能理解抽象的规则与意图。两者的结合等于在底层物理推演与顶层语义推理之间搭了一座桥。这种结合不是我们有两个好模型把它们串起来用的简单堆叠。真正的设计难点在于物理推演的结果如何变成LLM可理解的语义输入LLM的决策如何回到世界模型的空间里被验证这个双向映射构成了后面要讲的整个技术方案的核心。3. 模块级结合的技术路线我给出一套可落地的架构3.1 整体流程世界模型负责预测LLM负责裁决我参考了Wayve、Tesla以及学术界的多篇工作整理出一套自己认为最合理的模块级结合架构整体流程如下。多传感器数据相机、激光雷达、毫米波雷达先经过感知模块输出当前场景的结构化描述车道拓扑、障碍物列表、交通标识、自车状态。世界模型基于这些状态向后推演未来3~5秒的场景演化输出若干条可能的未来轨迹包括自车的候选轨迹以及关键交通参与者的预测轨迹。这些预测结果会被转换成文本化的场景描述送入LLM。LLM作为驾驶决策仲裁者结合交通规则、用户指令和高层策略对所有候选轨迹进行评分输出最优决策。最优决策被翻译回轨迹参数交给下游控制模块执行。这条路线的优势在于世界模型提供丰富的未来信息让LLM有机会做预判性决策而不是应激性决策LLM提供高层的规则裁决能力不会因为物理感知的连续帧而迷失方向。3.2 关键模块一场景Tokenizer的设计世界模型和大语言模型之间没法直接对话需要一个翻译器就是场景Tokenizer。它的任务是把连续的场景数据转换成离散的token序列。我在实际项目中把这个Tokenizer设计成三层的结构第一层是语义抽取层负责把感知结果整理成一张语义图。图中的节点是交通参与者车辆、行人、骑行者边是它们之间的时空关系距离、相对速度、是否会碰撞。第二层是数值编码层把这张语义图量化。每个参与者的类型、位置偏移、速度向量、历史轨迹点序列映射到预设的codebook上。我实测下来codebook大小设为4096比较合适太小则细节丢失明显太大则训练难度上升。第三层是文本化层把数值token进一步翻译成LLM可以理解的自然语言描述。为了保证效率这一层我采用模板加槽位的方式关键信息用数值填空关系和意图用固定句式表达。还得说一句如果你觉得这整套Tokenizer很麻烦还有一个更简单的替代方案直接用多模态大模型把图像一帧帧喂进去让它自己生成场景描述。但这个方案在实车上很难落地因为视觉token的开销远大于结构化文本延迟会高到你根本来不及做规划。3.3 关键模块二世界模型预测结果的结构化输出世界模型如果直接输出图像帧核心信息是隐式的很难被下游LLM利用。我的做法是让世界模型输出显式的未来轨迹分布而不是图像。具体实现上我参考了多模态轨迹预测方案把未来N秒的自车轨迹和周围目标轨迹建模为高斯混合分布每一个候选轨迹附带一个置信概率。然后将这些候选轨迹投到一个存在性检查器里把轨迹投影回当前的高清地图上剔除压线、穿墙、碰撞的选项。这一步很关键能大幅减轻LLM的负担让它把精力集中在更高级的规则判断上。做完筛选之后再把剩余候选轨迹的描述文本交给LLM。例如候选轨迹1前方直行速度保持40km/h预计2秒后通过当前路口无风险。候选轨迹2向左变道速度提升至50km/h目标车道后方有一辆速度50km/h的来车车距约30米。候选轨迹3减速停车等待前车启动预计停车5秒。这组文本信息密度很高LLM只需要基于常识规则就能给出合理判断。3.4 关键模块三LLM决策层的Prompt设计Prompt在这个系统里不是写几句话让模型跑一下那么简单它就是决策层的一部分决定了系统的行为边界。我经过多轮迭代整理出一套相对稳定的Prompt模板核心拆分如下角色设定明确告诉LLM你是一个保守且合规的自动驾驶决策系统优先级从高到低是安全、法规、效率、舒适。场景输入把世界模型的结构化描述直接填入包括自车状态、候选轨迹、风险提示。规则库注入把交通法规和公司安全策略以条目方式列出例如斑马线前30米内不得超车实线不得变道遇救护车必须右靠。约束输出格式要求LLM只能输出三样东西——选择哪条候选轨迹、理由、替代调整建议。不输出JSON以外的任何内容方便后续解析。实测中这个Prompt设计能让LLM的决策准确率解决近九成剩下的一成需要规则兜底策略来处理。我也验证过不同的模型在GPT-4级别模型上决策质量非常高但在7B量级的开源模型上会出现理解不清多义文本的情况所以模型选型也是个不能含糊的问题。3.5 回环校验把LLM的决策放回世界模型里再验证很多时候LLM会想当然比如选了一条避开当前障碍物的轨迹但它没有意识障碍物后面还藏着一辆公交。要解决这个问题我加了一道回环校验LLM输出的决策轨迹在世界模型的预测空间里继续进行推演验证这条轨迹在接下来几秒是否会产生新的冲突。如果推演结果安全才把轨迹交给控制模块如果推演发现冲突则回到LLM要求它在约束下重新决策。这个想象→决策→再想象→再决策的闭环是系统可靠性的关键所在也是我很想强调的设计思路。我在实车上测试过这个闭环的作用。有一次模拟场景里一辆卡车在右侧车道缓行LLM最初的选择是向左变道超车但回环推演发现左侧车道后方有一辆高速接近的车辆于是重新决策回到跟车状态。没有这个回环系统极有可能在变道过程中遭遇碰撞风险。4. 从零搭建一个最小原型跑通场景描述→LLM决策的完整链路4.1 环境准备与数据选型这里我给出一个能在单张消费级显卡上跑起来的最小原型。不需要100块A100关键在于合理裁剪任务范围。硬件建议单张RTX 409024GB内存32GB。深度学习框架PyTorch 2.x。世界模型使用现成的预训练模型推荐DriveGAN或GAIA-1如果拿不到权重可以用NuScenes数据集上训练的轨迹预测模型代替效果等价于把世界模型简化成目标轨迹预测器。大语言模型在线的GPT-4 API或者开源的Qwen-7B-Chat、ChatGLM3-6B。用开源模型的优势是可控可以本地部署。数据方面NuScenes是最适合起步的自动驾驶数据集。它包含波士顿、新加坡两个城市的1000个场景6个相机、5个激光雷达并且内置了完整的地图信息。我建议只取出25%的数据做实验先跑通链路再扩规模。4.2 核心代码场景描述生成器拿到一条NuScenes数据样本后需要从原始传感器数据里提炼结构化的场景描述。这里我给出一个简化版本只处理关键信息。import numpy as np from nuscenes.nuscenes import NuScenes def build_scene_description(nusc, sample_token): sample nusc.get(sample, sample_token) # 获取自车在当前帧的位姿 ego_pose nusc.get(ego_pose, nusc.get(sample_data, sample[data][CAM_FRONT])[ego_pose_token]) # 获取当前帧所有物体 scene_objects [] for ann_token in sample[anns]: ann nusc.get(sample_annotation, ann_token) translation ann[translation] # [x, y, z] velocity nusc.box_velocity(ann_token) # 相对世界坐标的速度 category ann[category_name] scene_objects.append({ category: category, position: translation[:2], # 取平面坐标 velocity: velocity[:2], distance_to_ego: np.linalg.norm(np.array(translation[:2]) - np.array(ego_pose[translation][:2])) }) # 排序保留最近最相关的10个物体 scene_objects.sort(keylambda x: x[distance_to_ego]) scene_objects scene_objects[:10] # 生成自然语言描述 description f当前自车位置: {ego_pose[translation][:2]} description 前方关键目标:\n for i, obj in enumerate(scene_objects): description (f{i1}. {obj[category]}相对距离{obj[distance_to_ego]:.1f}米 f相对速度{np.linalg.norm(obj[velocity]):.1f}m/s f方位{obj[position]}\n) return description这段代码的核心思路是提取距离最近的十个目标生成带数值的文本描述。注意真实项目里还需要加入车道、红绿灯、限速牌等复杂信息但最关键的技术点是数据的组织顺序决定LLM理解的效率距离近的、动态的、类型稀有的一定要优先排在前。4.3 核心代码候选轨迹生成与LLM决策候选轨迹这一部分我直接用一个简洁的采样模型来代替复杂的轨迹预测网络def generate_candidate_trajectories(ego_state, target_goal, num_samples5): 基于自车状态和目标点生成多条可达轨迹。 真实项目里这里会换成训练过的轨迹预测模型但为了演示Demo这里用简化方式。 trajectories [] for i in range(num_samples): # 生成不同的变道偏移量 lane_offset np.linspace(-2.0, 2.0, num_samples)[i] # 生成不同的速度剖面 speed_profile np.linspace(5, ego_state[speed] * 0.6, num_samples)[i] # 简化表示一条轨迹由3个控制点构成 trajectory { id: i, lanes: lane_offset, speed: speed_profile, description: f轨迹{i}: 车道偏移{lane_offset:.1f}米目标速度{speed_profile:.1f}m/s } trajectories.append(trajectory) return trajectories然后是LLM决策的核心部分。用OpenAI风格API的话流程是这样def llm_decision(prompt_context, candidate_trajectories, rules): # prompt_context场景描述候选轨迹描述规则列表 messages [ {role: system, content: 你是一个保守且合规的自动驾驶决策系统。}, {role: user, content: f 场景描述 {prompt_context} 候选轨迹 {candidate_trajectories} 安全法规规则 {rules} 请返回JSON格式决策结果 {{ selected_trajectory_id: 0, reason: 简要说明理由, alternative: 可选调整建议 }} } ] # 调用大模型API response llm_chat(messages, temperature0.2) # temperature拉低让决策更稳定不允许随机探索 return parse_json(response.content)这个是整个流程的核心骨架。为了工程稳定我写了一个简单的校验模块先检查返回的JSON是否合法然后校验selected_trajectory_id是否在候选范围内再校验轨迹是否与地图冲突。这几层防御下来大模型的幻觉基本不会产生系统性危害。4.4 把两条代码串起来最小闭环运行整体运行入口我设计成这样def main(nusc, sample_token): # Step 1: 生成场景描述 scene_desc build_scene_description(nusc, sample_token) # Step 2: 生成候选轨迹 ego_state extract_ego_state(nusc, sample_token) goal determine_goal_from_map(nusc, sample_token) # 从地图中获取目标点 candidates generate_candidate_trajectories(ego_state, goal) # Step 3: 将候选轨迹描述化 candidate_desc \n.join([c[description] for c in candidates]) # Step 4: LLM决策 decision llm_decision(scene_desc, candidate_desc, TRAFFIC_RULES) # Step 5: 回环验证此处简化为打印输出 print(f决策结果: 轨迹{decision[selected_trajectory_id]}) print(f理由: {decision[reason]}) return decision我实际跑通这个最小原型的耗时大概在一周左右其中一半时间花在数据格式处理和API调试上。如果你熟悉NuScenes应该能更快。5. 数据集、评测与算力这个方向真正难啃的三块硬骨头5.1 现有自动驾驶数据集够用吗直接说结论看你要解决什么问题。如果只是验证世界模型LLM的决策链路是否合理NuScenes完全够用。它提供了丰富的地图、多传感器对齐、以及每秒2Hz的标注作为第一层验证平台非常有效。如果想验证世界模型的生成质量NuScenes的分辨率和时长就显得不够了。这时候需要Waymo Open Dataset它有更高帧率、更长时间的多传感器数据。但它的地图标注不如NuScenes精细导致LLM的规则判断缺少足够的地图信息。还有一个开源资源值得关注DriveLM。它专门做驾驶场景问答把图像、点云、语义标注和自然语言问题对应起来。这个数据集在训练场景理解模型时非常有用本质上是把感知结果转化为LLM可理解表示的中间产物。我的建议是第一层验证用NuScenes数据干净第二层验证用Waymo数据量大最后做真车验证找一个封闭园区或测试场地。5.2 评测指标如何设计不能只看任务完成率评测端到端驾驶系统是个公认的难题。传统指标如规划误差位移误差、碰撞率只能反映局部性能无法评价决策的合理性。我建议从四个维度建立评测体系。安全性维度看的是碰撞率、违反交规次数、最小安全距离。这是底线指标任何决策不得以牺牲安全性为代价。鲁棒性维度看的是长尾场景覆盖率、遮挡情况下的性能衰减、不同天气下的稳定性。我在这块的处理方式是构造一个场景变体测试集把原始数据的天气、光照、障碍物分布做小规模扰动。决策质量维度看的是LLM输出决策与人类专家决策的一致性。用人工标注的数据做对比统计决策匹配率。我跑下来在简单场景决策匹配率能到85%复杂场景会掉到60%左右。这个数字说明LLM在复杂场景的规则理解还有明显提升空间。计算开销维度看的是端到端时延、平均CPU/GPU利用率。LLM推理时延是大头一个7B量级的模型单次决策一般在400ms到1s之间这个延迟对城市工况可能勉强够用但高速场景需要更激进的优化。5.3 算力部署从云端到车端的降级方案现阶段直接把大模型部署到实车还是太吃力。我的建议是分层部署域控制器上跑感知世界模型的轻量化版本输出结构化描述文本。推理决策用边缘服务器通过5G低延迟通道把场景描述发送到服务器服务器上跑7B或13B量级LLM返回决策JSON。实测下来在独立5G下的通道延迟约50ms加上LLM推理300ms总时延在可控范围。云端负责训练和长尾数据的收集。遇到新场景后云端重新训练世界模型的预测分支定期OTA更新车端模型。这套架构的好处是车端不需要背负大模型推理的算力负担同时整个系统仍然能享受大模型的决策能力。缺点是对网络稳定性有要求隧道和地下车库场景需要设计本地兜底策略——我的做法是检测到网络断连时自动切换成保守的靠边停车策略等网络恢复再继续。6. 开源资源和模型选型哪些可以直接用哪些必须自己训6.1 世界模型的开源基线可以直接上手的那几个世界模型领域目前值得看的开源资源如下。GAIA-1Wayve业界最早把驾驶视频做token化并训练自回归世界模型的代表工作。没开源完整权重但论文和架构细节非常值得反复读。DriveGAN开源了部分代码优点是可控制性强——你可以用属性向量控制生成场景中的天气、道路类型。我拿它做过数据增强效果不错。UniWorld提供了一个统一的世界模型训练框架支持多模态输出。这个Repo我实际跑过代码质量不错做入门研究很合适。MILEMIT的工作主打在NuScenes上做大规模世界模型预训练。它的模型在规划任务上效果突出适合用来做未来轨迹预测。如果你只是想把世界模型当作一个黑盒组件用起来直接用UniWorld的预训练权重是最省力的路径。6.2 LLM的选择不是模型越大越好而是适配你的PromptLLM选型有几个维度要权衡参数量、推理速度、对结构化文本的理解能力、本地部署难度。工业级验证GPT-4或Claude 3.5系列。决策质量高稳定但是有API调用成本且每辆车每秒钟都调用API不现实。适合做技术验证和规则打磨。边缘服务器部署Qwen-14B-Chat、ChatGLM3-6B、DeepSeek-R1-Distill-Qwen-7B。这几个在中文场景效果不错且能本地部署。实测Qwen-14B对复杂场景描述的理解能力明显强于7B版本。车端部署目前还没有特别合适的开源LLM能在车载计算平台流畅运行。轻量化的思路是用蒸馏后的3B模型把规则判断简化成选择题或判别式任务绕开自由文本生成的高算力消耗。一个很重要的实测经验是Prompt模板必须根据模型微调。同一个场景描述GPT-4能直接理解Qwen-7B常常会读不懂隐含的逻辑关系。需要在Prompt里加入明确的一步一步推理要求并补充少量现场示例few-shot。我在实际项目里为Qwen加了三个few-shot示例之后决策准确率提升了大概十个百分点。6.3 项目里值得收藏的GitHub Repo清单这里列一份我认为值得收藏的资源清单都是这个方向绕不开的宝藏nuplan-devkit自动驾驶规划基准提供世界模型评测场景是测试决策算法的好环境。LanguageMPC把LLM引入MPC模型预测控制控制器的代表作代码可读性高。DriveGPT4微软的工作把驾驶视频和多轮语言指令对齐是多模态驾驶语言模型的重要参考。LeapAD用世界模型做驾驶决策的经典项目代码完整适合当第二个复现目标。7. 我踩过的坑以及你现在就可以避开的坑7.1 坑一把世界的视觉未来直接喂给LLM我最早做这个项目时犯的最大的错是试图把世界模型生成的未来视频帧直接喂给多模态LLM让它看着视频做决策。试了大概两周效果惨不忍睹。多模态LLM处理高帧率视频的token开销极大端到端时延超过3秒而且生成视频里的噪声会干扰LLM的判断——它会看到幻觉物体然后一本正经地给出错误决策。解决方案一定要让世界模型输出结构化信息而不是依赖LLM做视觉理解。视觉理解交给专用的感知模型世界模型负责推演LLM只干它最擅长的规则推理。这个分工清晰之后系统性能瞬间提升一个量级。7.2 坑二忽略坐标系对齐模型输出南辕北辙世界模型跑在车体坐标系LLM读取的是相对位置文本控制模块需要的是全局坐标。这三个空间的坐标如果不做严格对齐就会出极其隐蔽的bugLLM认为前方20米有车但实际的20米可能是横向距离而非纵向距离误差会直接导致决策错误。解决方案在场景Tokenizer阶段统一定义坐标系参考基准。我的做法是全部转成以自车后轴中心为原点的局部坐标系同时显式标注出参考系。所有文本描述里的距离、速度、角度都基于这个基准进行计算。7.3 坑三低估了LLM决策的一致性问题LLM不是确定性系统。同一个场景描述扔给它两次可能得到不同的决策结果。这在自动驾驶里是不可接受的。要解决这个问题需要多管齐下。我在项目里做了三件事降低temperature参数从默认的0.7降到0.1~0.2决策波动明显收窄。引入自洽性检验同一个Prompt重复采样5次统计决策分布只有超过3次选择一致的轨迹才执行。规则硬编码兜底对于明确违反物理安全约束的决策即使LLM选了也不允许执行。前两项在Demo阶段就可以实现第三项是实车运行的必备条件。8. 写在最后从Demo到实车的路还有多远按我个人的经验判断这篇的技术路线要走到规模化量产还需要跨过三座大山。第一座是世界模型的泛化能力。现在世界模型在训练集覆盖的场景里表现不错但换成没见过的城市、没见过的交通习惯预测能力会肉眼可见地下降。解决这个问题需要海量数据支撑而数据的采集和标注在自动驾驶行业永远是最难的事情之一。第二座是LLM推理延迟与车载环境的不匹配。今天我用的边缘服务器方案只是过渡真正量产还是要找算力更小的模型。目前看做成决策的打分器而不是生成器是有希望落地方向——不做自由文本生成而是让LLM对多条候选轨迹打分这样可以用蒸馏后的模型实现推理代价低很多。第三座是Safety Case的可信度问题。要让监管机构接受一套基于大模型的决策系统核心是解释性。LLM有一点好它能给出决策理由但这理由未必是真实的因果推理。如何对理由本身做验证是功能安全领域的新课题。如果你现在正准备入手这个方向我的建议很直接先别急着上多强的模型找个开源数据集搭出最小闭环跑通整个流程。然后把注意力聚焦在想清楚你的世界模型输出什么表征、LLM输入什么文本这个核心问题上——这个设计决策决定了你后面所有工作的上限。我自己的下一阶段计划是把World Model从轨迹预测升级成多模态场景预测同时把LLM从独立的决策模块内化成世界模型里的一个语义条件生成器。能不能成现在还说不好。但这个过程里踩过的每个坑都值得记录和分享。