企业官网建设流程全解析

视觉语言模型在自动驾驶上火了，但坦白说，圈子里不少讨论都跑偏了——大家拼命往模型里塞各种问答数据，好像让模型多看几张图、多答几个问题，车就能开稳。Qwen-Drive-1.0这个方向反而点破了关键：通用视觉语言模型走向自动驾驶，缺的根本不是更多问答，而是一层能被检查、能被验证、能和下游规控闭环的3D与轨迹接口。

我在自动驾驶行业摸爬滚打了这么多年，从传统感知到端到端模型都做过，看到这个思路时确实有点共鸣。今天想从实际工程角度聊聊，为什么接口比问答更重要，3D接口和轨迹接口到底该怎么设计，以及落地时有哪些躲不开的坑。

1. 视觉语言模型上车：为什么大家一拥而上，却容易跑偏

1.1 从“看图说话”到“看路开车”，VLM到底强在哪

先理清一个概念。视觉语言模型（VLM）本质上是一个多模态模型，它把图像编码器和语言模型粘在一起——图像进来，先经过视觉编码器变成特征，再交给语言模型去理解、推理、生成回答。过去几年火起来的大模型，本质上都是在“预测下一个token”，但加上视觉编码器之后，模型就多了一双眼睛，能看到真实世界的图像、点云、视频，然后基于这些视觉信息做语义层面的推理。

在自动驾驶场景里，VLM的优势是显而易见的。传统感知模型可以检测出“前方有一辆白色轿车”，但很难理解“前面那辆车打了右转向灯，旁边车道还有空隙，它很可能要向右变道”。这种对交通参与者意图、场景上下文、罕见状况的综合理解，恰好是VLM最擅长的事情。模型能看图说话、能做常识推理，这就让自动驾驶系统具备了处理长尾场景的潜力——比如路边摆放的临时施工牌、前车掉落物、交警手势，这些都是规则引擎很难预先穷举的情况。

1.2 纯问答路线的三大局限

很多团队做VLM上车，走的是“多模态问答”的路线：喂一张前向摄像头图像，让模型用自然语言描述场景，或者回答“前方是否可以变道”“有没有危险”。一开始效果看起来不错，demo视频也很惊艳，但只要往量产方向细想，就会发现纯问答路线有三个硬伤。

第一个硬伤是信息瓶颈。自然语言是一个高度压缩的离散符号系统，你说“前方有一辆车离我们很近”，这句话丢失了大量信息——车在哪个车道、横向距离多少、纵向距离多少、相对速度是多少、它的朝向角如何？语言可以描述定性的趋势，但无法输出定量的、毫秒级精确的几何信息。

第二个硬伤是不可验证性。大模型天生会幻觉，让它描述一个没有行人的画面，它也可能煞有介事地告诉你“右前方有一个行人正在横穿马路”。如果这个描述直接送去规划模块，那就成了事故源头。语言输出的东西不是结构化数据，没法做传统的阈值判断、协方差校验、真值比对，可靠性完全无从谈起。

第三个硬伤是和下游脱节。规划控制模块要的不是句子，是障碍物在自车坐标系下的坐标、多边形轮廓、速度矢量，或者是未来几秒内自车的期望轨迹。你给规划器一段文字“请减速并向右避让”，规划器根本没法直接用。中间还得翻译，而翻译的过程就会损失信息、引入错误。

所以结论就出来了：通用视觉语言模型想做自动驾驶，关键不是让模型“会说话”，而是给模型加一层“手脚”——把语义理解翻译成几何与轨迹的接口。这个接口必须是显式的、可检查的、能对接传统自动驾驶技术栈的。Qwen-Drive-1.0提出的方向，就是在视觉语言模型之上构建3D接口和轨迹接口，让模型不仅“看懂”了路，还能把看懂的东西落到物理世界的坐标和路径上去。

2. 3D接口：让模型真正站在物理空间里思考

2.1 为什么要显式的3D表达，而不是2D框加文字

如果VLM只输出2D检测框和自然语言描述，它在物理世界里根本无法闭环控制。2D检测框是图像平面上的像素坐标，它不包含深度信息，也不包含物体在自车坐标系下的真实位置。摄像头图像本身就是透视投影的产物——一个近距离的小物体和一个远距离的大物体，在图像上可能占相同大小的面积。

举一个我实测中遇到的例子。前向摄像头检测到一个“疑似障碍物”的2D框，它既可能是一辆距离5米的电瓶车，也可能是一辆距离50米的大货车。如果没有深度估计和3D定位，这个感知结果对规划模块来说几乎没有价值——因为不知道障碍物到底在哪里、什么时候会撞上。

所以，3D接口的第一层含义，就是要让模型输出物体在自车坐标系下的3D位置、尺寸、朝向，甚至是占据栅格或密集深度。这样才能和传统感知链路——比如激光雷达点云、毫米波雷达检测结果——做融合、交叉验证。自动驾驶是一个对精度有极高要求的系统，厘米级的误差在高速场景下会被放大成致命的碰撞风险。VLM的输出必须落在3D空间里，才算真正和下游打通。

2.2 Qwen-Drive-1.0中3D接口的实现路径

从行业里公开的技术趋势和我个人的工程经验来看，给VLM加3D接口有一套比较成熟的路径，Qwen-Drive-1.0大概率也是沿着类似方向走的。

基础方案是：在视觉编码器后面加一个3D感知分支，用查询（query）机制去解码BEV（鸟瞰视角）特征或者3D空间特征，而不是让模型直接生成文本。具体来说，可以设计一组“3D锚点查询”——每个查询对应三维空间中的一个位置或区域——让模型在这些锚点上输出目标的类别、尺寸、朝向和速度。这样就把VLM的视觉理解能力嫁接到了一个结构化的几何输出上。

更进一步，可以用3D高斯泼溅或神经辐射场类的技术来建模场景。3D高斯泼溅这几年很火，它本质上是把连续场景表达成一组可微分的3D高斯分布，能够从多个视角的图像中重建场景的几何和外观。好处在于它天然支持多视角一致性，还能渲染出任意视角的图像。对自动驾驶来说，这意味着模型可以不只理解“当前这一帧图像”，而是在一个统一的3D场景表征里理解整个周围的动态环境。Qwen-Drive-1.0如果想把通用视觉理解能力真正用起来，这样一个3D场景表征层几乎是必需品。

实际落地的时候还要考虑传感器配置。纯视觉方案能输出3D，但直接测距精度不够，尤其是夜间、逆光、雨雪天气。所以量产车上一般会做激光雷达和摄像头的多模态融合——激光雷达提供精确的几何骨架，摄像头提供丰富的语义纹理，再把两者通过3D接口合并成统一的传感器表征喂给VLM。这里的关键是“显式”两个字：3D接口不应该隐藏在模型的黑盒子里，而是应该能导出成清晰的坐标、帧、类别、置信度，让人能看、能查、能校验。

2.3 设计3D接口时最容易出错的几个细节

我在实际工程中踩过不少坑，这里挑几个关键细节说。

首先是坐标系。自动驾驶里至少有四套坐标系——图像像素系、相机系、车体系、世界系。3D接口必须明确约定输出落在哪个坐标系里。我见过有团队让模型直接回归图像坐标，结果在弯道上车辆位置和人眼看到的画面完全对不上。正确的做法是统一到自车后轴中心的车辆坐标系，输出X为纵向、Y为横向（或相反），单位统一用米，角度用弧度。

其次是时间同步。相机和激光雷达的采集时刻如果不同步，哪怕只差几十毫秒，在车辆高速行驶时都会产生显著的位移误差。一辆以30米/秒行驶的车，50毫秒的时间差就意味着1.5米的定位误差，这在高速汇入场景中是致命的。接3D接口时，必须做传感器的时间戳对齐，必要时做运动补偿（Motion Compensation）。

第三是输出格式的可检查性。3D接口最好同时输出三样东西：数值结果、结构化语义标签、可视化渲染图。比如模型输出“前方50米处有一辆白色SUV，速度约10米/秒”，除了保存结构化数据外，还应该把3D框/占据栅格直接渲染到图像和BEV图上，让测试人员一眼就能看出模型是否理解错了场景。没有可视化检查工具，3D接口就是不可调试的黑盒，几千小时的测试数据也会因为无法快速排查而大打折扣。

注意：3D接口本质上是一个转换层——它把VLM的语义推理能力“翻译”成物理可度量的几何信号。做这个转换层时，优先保证输入的传感器数据经过时间同步和内外参标定，否则任何基于几何的下游任务都会是空中楼阁。

3. 轨迹接口：不只说“前方有危险”，而是给出一条能落地的路

3.1 从语义理解到自车轨迹预测

3D接口解决的是“世界是什么样”的问题，轨迹接口则要回答“我该怎么走”。这也是Qwen-Drive-1.0这个思路里最核心的一环。

传统自动驾驶的规控模块，需要的是若干条候选轨迹，每条轨迹由一系列时空路径点组成。规划器再通过代价函数来选择最优的一条。VLM要融入这个链路，就不能只输出“应该向左避让”这种语义级别的建议，而必须直接生成稠密的轨迹序列——包括未来5到10秒内，每隔0.1到0.2秒的自车位置、速度、加速度、曲率等信息。

轨迹接口的意义在于，它把VLM的语言推理能力，和底层的运动学约束、动力学约束、安全约束，彻底打通了。举个例子，模型通过语义理解判断“前方有事故，需要变道到左车道”，那么轨迹接口就需要输出一条在横向上平滑换道、在纵向上适度减速的候选轨迹。这条轨迹必须满足车辆运动学约束——比如最大转向角、最大横向加速度——不是随便画一条曲线就能执行的。

3.2 轨迹接口的典型结构

从实现角度讲，我一般会把轨迹接口分成两个层次：意图层和曲线层。

意图层负责输出驾驶意图，比如“保持车道”“向右变道”“靠边停车”“减速通过”。这可以由VLM的语义推理头直接输出，对应一个离散的意图类别。曲线层负责输出具体的时空轨迹，以多条候选轨迹的集合形式给出，并附上置信度分数和约束标记。

代码层面，一个简化的轨迹输出结构可以做成这样：

@dataclass class TrajectoryCandidate: # 轨迹未来时间点，单位：秒 time_s: List[float] # 自车坐标系下纵向位置序列，单位：米 x_m: List[float] # 自车坐标系下横向位置序列，单位：米 y_m: List[float] # 每个轨迹点的期望车速，单位：米/秒 v_mps: List[float] # 每个轨迹点的曲率，单位：1/米 curvature: List[float] # 意图标签，如 "left_lane_change", "keep_lane" intention: str # 模型置信度，范围 0~1 confidence: float # 安全约束标记，如 "passive_safety", "comfort_constraint" constraints: List[str]

把轨迹设计成多条候选的方式，最重要的原因是给下游规划器留出仲裁空间。VLM不是全知全能的，它可能对场景的理解有偏差，但如果同时给出“保持车道”和“向左变道”两条轨迹，下游规划器再叠加基于规则的安全校验、驾驶员习惯模型、舒适度评估，就能在最后一步把住安全关。这个设计理念和传统规划模块的“多候选+代价函数仲裁”是一致的，本质上是用冗余换安全。

3.3 轨迹与规划的闭环：可检查接口的安全兜底

轨迹接口还承担着一个任务：让系统可以被人检查和干预。

我见过太多端到端模型，输入图像直接输出方向盘转角。这种方案的问题在于，一旦模型在复杂路口表现异常，工程师根本没法判断——到底是模型对场景的理解错了，还是轨迹生成错了，还是映射到控制指令的时候错了？整个系统像个熔岩灯，内部永远在变化，出了问题你无法定位。

Qwen-Drive-1.0的思路是把这个流程拆开，保留可检查的中间结果。视觉语言模型输出3D障碍物结果，再生成语义级的驾驶意图和轨迹候选，最后由下游的规则规划器或安全层做校验。哪一层出了问题，都能通过中间接口快速定位。某段轨迹的曲率突变、某个障碍物的3D框和真值偏差过大，都能单独排查。

我在实际测试中比较关注三个轨迹指标：碰撞率（生成的轨迹是否和障碍物相交）、乘坐舒适度（横向加速度和纵向冲击度是否超标）、以及与规则规划器的轨迹离散度（如果VLM输出和传统规划器输出差距过大，说明模型对场景的理解可能有问题）。这三个指标可以做成实时监控，只要任何一项超出阈值，就自动降级到保守策略——减速、靠边、请求接管。这比让模型直接“盲操”要稳健得多。

注意：接口层才是安全的核心，不是模型本身。VLM的推理能力再强，也可能在某些罕见场景下出错，但只要接口层的校验和降级机制够扎实，模型犯点小错并不会酿成灾难。反过来，再强的模型只要直接输出方向盘指令，一旦出问题就是不可回退的。

4. 评测与数据：没有可检查的接口，就没有可靠的自动驾驶测试

4.1 场景库评价：从ISO 34505说起

聊到评测，就绕不开自动驾驶测试场景的标准文件。ISO 34505:2025《自动驾驶测试场景评价与用例测试生成》是国内和国际自动驾驶测试领域都会参考的框架性文件。ISO 34505的核心思想，是把自动驾驶测试场景拆分成功能场景、逻辑场景、具体场景三个层次来管理——功能场景描述“发生了什么”的抽象场景，逻辑场景给出参数空间（比如车速范围、障碍物距离范围），具体场景则是一组可执行的具体参数组合。

VLM落地的测试完全可以借鉴这套框架。比如要让模型处理“前车急刹”场景，先定义功能场景：前车在自车前方行驶，以一定减速度减速至停车；再定义逻辑场景：前车初速度30至60km/h，自车车距10至30米，减速度4至8m/s²；最后用参数采样方法，在逻辑场景的参数空间里生成成百上千条具体测试用例。

有了ISO 34505这种结构化的场景定义方式，可检查的3D与轨迹接口的价值就体现出来了——对场景库里的每一帧数据，模型输出的3D检测框、轨迹预测值，都可以和真值做量化对比，测试人员可以逐帧检查失败案例。如果没有结构化接口，大模型在这种评测框架下根本无从评估。

4.2 数据集与数据闭环：光靠公开数据集跑不通

现在很多团队拿公开数据集（比如nuScenes、Waymo Open Dataset）来训练VLM的自动驾驶能力。这些数据集有传感器数据、3D标注、地图信息，质量确实不错，但直接用于训练一套面向自动驾驶的VLM远远不够。

第一个问题在于数据多样性和场景覆盖。公开数据集里的天气、时段、城市分布相对平均，但真实自动驾驶最怕的恰恰是极端天气、夜间暗光、施工改道、事故现场这类长尾场景。公开数据集里这些场景非常稀疏，模型学了等于没学。

第二个问题是标注粒度和接口不匹配。VLM要学的是“从语义到3D到轨迹”的完整映射，而公开数据集往往只有感知标注，缺少驾驶行为标签和轨迹真值，更缺少“文字问答+几何标注+轨迹标注”对齐的多模态数据。所以真正做项目时，我一般建议走数据闭环路线：在道路上运行的测试车，持续把corner case数据回传到云端，云端触发自动标注管线——3D框自动跟踪、轨迹自动拟合、场景文字描述自动生成。再经过人工抽检后，变成下一轮模型训练的增量数据。

数据闭环这件事，听上去容易，做起来是个系统工程，牵扯到数据筛选、自动标注、人工复审、版本管理一整套流程。但想达到量产级的性能，这条路是绕不开的。

4.3 评测链路：分模块评测加端到端闭环评测

评测VLM在自动驾驶上的表现，我建议分两层。

第一层是分模块评测。感知层面重点看3D目标检测的AP值、BEV下的定位误差；预测层面重点看轨迹未来5秒内的ADE（平均位移误差）和FDE（最终位移误差）；语义层面看意图分类的准确率、场景描述的语义相似度。每一个模块都有中间接口可以汇报指标，哪根短板一眼就看到。

第二层是端到端闭环评测。在仿真环境里把模型接入完整的规控链路，记录安全性指标、任务完成率、平均接管里程。仿真评测的好处是可以低成本跑几千万公里的虚拟里程，快速暴露边界问题。但仿真再逼真也有domain gap，最终还得靠实际道路测试来收尾。

我在项目里经常用一张汇总表来跟踪模型的评测进度，给读者参考：

注意，最后一项“接口可检查性”往往不在常规评测清单里，但我认为它是最重要的。自动驾驶是安全攸关系统，再好的数据指标如果没有经过逐帧视觉检查确认，都有可能存在系统性的理解误区——比如模型对某些罕见标志牌视而不见，但数据集里恰好这类样本偏少，指标完全暴露不了问题。

5. 工程落地中的常见问题与排查实录

5.1 相机和激光雷达时间不同步导致的3D漂移

我参与的项目里，第一次把VLM的3D接口接到实车数据上，跑出来的BEV可视化结果明显“重影”——物体的3D框和点云轮廓是错位的，车明明是直线行驶，框却像在左右摇晃。

排查过程从标定参数开始：先确认相机内参、外参没有问题；然后检查是时间同步问题——对比每帧图像和点云的时间戳，发现两者相差大概80毫秒。车辆在40km/h行驶时，80毫秒意味着前进将近0.9米，这就解释了3D框为何前后偏移。

解决方案不复杂：对点云做线性插值运动补偿，把所有传感器数据统一到同一个参考时刻；或者在硬件层面用触发线把相机曝光时刻和激光雷达扫描时刻对齐。从那以后我养成一个习惯：任何多传感器融合项目的第一道验收标准，就是看时间戳对齐误差，这个不达标，后边做得再好也没用。

5.2 VLM轨迹输出抖动，如何做时序平滑

VLM输出的轨迹容易出现帧间抖动——上一帧说“保持车道稳定直行”，下一帧轨迹候选却往右偏了30厘米，再下一帧又偏回来。原因在于模型对每一帧图像独立作预测，单帧的语义理解会受光照、遮挡、视角变化的影响，输出的轨迹自然不够稳定。

我试过几种方案，最终觉得效果最好的是“预测+滤波”：让VLM在输出轨迹的同时，给出轨迹的时间序列特征，然后在时间上做一次平滑。类似卡尔曼滤波的思路，把当前帧的预测和上一帧的历史轨迹做加权融合。另外一点经验是：把轨迹接口和意图解耦，意图信号做滞后平滑（比如连续3帧都是“向左变道”才执行变道），而几何轨迹做逐点滤波。这样模型偶尔对某帧画面“多想了”，也不至于让车辆猛地抖一下。

5.3 模型幻觉和规则兜底：怎么防止VLM一本正经地胡说八道

VLM还有一个绕不开的问题是幻觉：场景里明明没有行人，模型却煞有介事地预测“行人横穿”。放到自动驾驶里，这种幻觉如果直接送给轨迹生成模块，可能会触发毫无理由的急刹车。

我的经验是一定要在轨迹接口之后加一层独立的规则安全层。这个安全层不依赖VLM的语义推理，而是用传统的几何和运动学方法，检查候选轨迹是否真的会碰撞障碍物。如果VLM说“前方有行人”但传感器和3D检测都没有对应的障碍物证据，安全层可以直接驳回这条轨迹。反过来，如果VLM漏检了一个真实存在的障碍物，但3D检测模块检测到了，安全层也能兜底。这套设计并不复杂，但它把“模型自信”和“实际安全”分开，不会因为模型的一次幻觉就产生灾难性后果。

5.4 算力受限：VLM很难原封不动跑在量产芯片上

最后说部署。VLM模型动辄几十亿参数，而量产车规级芯片的算力通常有限，还要给感知、规划、控制其他模块留余量。直接在车上跑原版大模型基本不现实。

我走通的一条路径是“云-端分离加模型蒸馏”：云端跑大参数VLM，用于数据标注、难例挖掘、离线评估；车端部署一个经过蒸馏和量化的小型化模型，保留3D接口和轨迹接口的关键能力，把算力消耗压到可控范围。任务级蒸馏比输出级蒸馏实用得多——不是让车端模型复现云端模型的每一个词，而是让车端模型学会在相同场景下输出一致的3D检测结果和轨迹分布。牺牲一点多样性，换来的是可部署性。

结尾

我一直在想，为什么很多团队做VLM自动驾驶做到最后，demo惊艳却迟迟无法量产落地。看了Qwen-Drive-1.0的方向后我更加确信——问题不在模型的推理能力，而在于缺少一层能被检查、能被验证、能和下游控制的接口。做模型的觉得我输出文字就够智能了，做规控的却在想这堆文字到底该怎么用。3D与轨迹接口，就是这两个世界之间的“翻译官”。

根据我个人的项目经验，如果你也想让视觉语言模型在自动驾驶上真正落地，建议别急着堆问答数据。先想清楚三件事：模型的输出能不能量化为自车坐标系下的3D几何？能不能生成满足车辆运动学约束的轨迹候选？这些中间结果能不能被工程师逐帧可视化检查？把这三点打通，模型离上路就不远了。反过来，这三个问题没想清楚，堆再多问答也只是让模型变成一个更聪明的“副驾驶解说员”，而不是真正握着方向盘的老司机。