企业官网建设流程全解析

为什么"预测下一帧"和"理解一句话"这两件事，正在改变自动驾驶算法的天花板

先说一个可能让很多人意外的判断：纯靠"撞出来"的端到端驾驶模型，正在逼近瓶颈。

过去几年，行业内卷的方向是把感知做到极致——检测精度、分割精度、跟踪鲁棒性，一项项指标刷到接近满分。但真把车放到开放道路上，还是会遇到一类非常尴尬的场景：一个施工牌旁边站着个挥小红旗的大爷，全世界任何公开数据集里都没见过这个组合。感知模型可能正确识别了"施工牌"和"人"，但下一步该做什么，它不知道。

这时候两类技术被推到台前。一类叫世界模型，它的核心任务是让车"想象未来"——给定当前场景，预测接下来几秒内会发生什么。另一类是大语言模型（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 4090（24GB），内存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(key=lambda 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"{i+1}. {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_samples=5): """ 基于自车状态和目标点，生成多条可达轨迹。 真实项目里这里会换成训练过的轨迹预测模型，但为了演示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, temperature=0.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-1（Wayve）：业界最早把驾驶视频做token化并训练自回归世界模型的代表工作。没开源完整权重，但论文和架构细节非常值得反复读。
• DriveGAN：开源了部分代码，优点是可控制性强——你可以用属性向量控制生成场景中的天气、道路类型。我拿它做过数据增强，效果不错。
• UniWorld：提供了一个统一的世界模型训练框架，支持多模态输出。这个Repo我实际跑过，代码质量不错，做入门研究很合适。
• MILE：MIT的工作，主打在NuScenes上做大规模世界模型预训练。它的模型在规划任务上效果突出，适合用来做未来轨迹预测。

如果你只是想把"世界模型"当作一个黑盒组件用起来，直接用UniWorld的预训练权重是最省力的路径。

6.2 LLM的选择：不是模型越大越好，而是适配你的Prompt

LLM选型有几个维度要权衡：参数量、推理速度、对结构化文本的理解能力、本地部署难度。

• 工业级验证：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读取的是相对位置文本，控制模块需要的是全局坐标。这三个空间的坐标如果不做严格对齐，就会出极其隐蔽的bug：LLM认为"前方20米有车"，但实际的20米可能是横向距离而非纵向距离，误差会直接导致决策错误。

解决方案：在场景Tokenizer阶段统一定义坐标系参考基准。我的做法是全部转成以自车后轴中心为原点的局部坐标系，同时显式标注出参考系。所有文本描述里的距离、速度、角度都基于这个基准进行计算。

7.3 坑三：低估了"LLM决策的一致性"问题

LLM不是确定性系统。同一个场景描述，扔给它两次，可能得到不同的决策结果。这在自动驾驶里是不可接受的。

要解决这个问题，需要多管齐下。我在项目里做了三件事：

1. 降低temperature参数，从默认的0.7降到0.1~0.2，决策波动明显收窄。
2. 引入自洽性检验，同一个Prompt重复采样5次，统计决策分布，只有超过3次选择一致的轨迹才执行。
3. 规则硬编码兜底，对于明确违反物理安全约束的决策，即使LLM选了也不允许执行。

前两项在Demo阶段就可以实现，第三项是实车运行的必备条件。

8. 写在最后：从Demo到实车的路还有多远

按我个人的经验判断，这篇的技术路线要走到规模化量产，还需要跨过三座大山。

第一座是世界模型的泛化能力。现在世界模型在训练集覆盖的场景里表现不错，但换成没见过的城市、没见过的交通习惯，预测能力会肉眼可见地下降。解决这个问题需要海量数据支撑，而数据的采集和标注在自动驾驶行业永远是最难的事情之一。

第二座是LLM推理延迟与车载环境的不匹配。今天我用的边缘服务器方案只是过渡，真正量产还是要找算力更小的模型。目前看，做成决策的"打分器"而不是"生成器"，是有希望落地方向——不做自由文本生成，而是让LLM对多条候选轨迹打分，这样可以用蒸馏后的模型实现，推理代价低很多。

第三座是Safety Case的可信度问题。要让监管机构接受一套基于大模型的决策系统，核心是解释性。LLM有一点好，它能给出决策理由，但这"理由"未必是真实的因果推理。如何对"理由"本身做验证，是功能安全领域的新课题。

如果你现在正准备入手这个方向，我的建议很直接：先别急着上多强的模型，找个开源数据集，搭出最小闭环，跑通整个流程。然后，把注意力聚焦在"想清楚你的世界模型输出什么表征、LLM输入什么文本"这个核心问题上——这个设计决策决定了你后面所有工作的上限。

我自己的下一阶段计划，是把World Model从轨迹预测升级成多模态场景预测，同时把LLM从独立的决策模块内化成世界模型里的一个"语义条件生成器"。能不能成，现在还说不好。但这个过程里踩过的每个坑，都值得记录和分享。