Qwen-Drive-1.0出来之后我朋友圈里做自动驾驶的朋友分成了两拨一拨觉得通用视觉语言模型终于要接管驾驶了另一拨看了演示视频后冷冷地说了句“这跟之前那些能聊天的VLM有什么区别”。两边吵得不可开交但我注意到一个有意思的现象——真正在一线做感知融合和规划控制的工程师关注点反而不在问答质量上而在一个很工程化的词上可检查的3D与轨迹接口。这其实才是通用视觉语言模型走向自动驾驶的关键转折点也是这篇博文想展开聊透的事。1. Qwen-Drive-1.0发布之后自动驾驶圈真正在讨论什么1.1 一个反直觉的判断驾驶场景下VLM不是话太多而是眼和手不够过去一年几乎所有主流大模型团队都在给视觉语言模型VLM加能力更强的OCR、更细粒度的物体指代、更能扛多轮对话。但把这类模型放到自动驾驶域你会发现真正卡脖子的不是“它认不认识红绿灯”也不是“它能不能解释为什么要踩刹车”而是它给出的所有认知结果都停留在自然语言描述层面没法被下游规划控制模块直接消费。Qwen-Drive-1.0在标题里强调“缺的不是更多问答而是可检查的3D与轨迹接口”这句话我特别认同。一个会说话的副驾驶和一套能接管的驾驶系统之间差的不是知识量而是对三维空间和运动时序的表达能力。也就是说模型需要输出的是能放进坐标系、能求交、能碰撞检测、能被规划器调用的结构化数据而不是“前方有危险建议减速”这种正确的废话。1.2 从Chat式问答到驾驶智能VLM在车端的三种存在形态我在和不少朋友讨论时发现大家经常把VLM在车上的用法混在一起聊所以要先把形态拆开。第一种是Copilot形态模型负责语音交互、解释仪表盘、给驾驶员提示这种形态输出自然语言完全没问题因为最终决策的是人。第二种是辅助标注形态模型在离线环境下帮忙生成场景描述、挖掘corner case、生成测试用例这种形态对输出精度要求不高甚至可以容忍幻觉。第三种是端到端驾驶形态模型直接输出控制量或者轨迹这种形态对结构化程度、可验证性、实时性的要求完全不是一个量级。Qwen-Drive-1.0指向的显然是第三种。可现实是大量研究团队还在拿第一种形态的评测方法去衡量第三种形态的模型最后当然会出现“问答表现挺好但车根本没法开”的尴尬。1.3 为什么“可检查性”成了关键词而不是接管率过去我们衡量自动驾驶系统主要看接管率、MPIMiles Per Intervention这类指标。但到了VLM时代“可检查性”显得前所未有的重要。原因很简单通用视觉语言模型本身是概率生成模型你不知道它哪一次会在没见过的场景里冒出一段幻觉。对于车规级系统你不能靠“相信模型”来保证安全你必须在每个关键输出上都能回溯、能校验、能干预。可检查性体现在三个层面第一3D感知结果必须可投影到图像上与原始像素对齐让工程师能直观确认“模型说这里有车到底是不是真的有”第二轨迹输出必须能在仿真环境中重放检查是否与障碍物碰撞、是否符合交规第三模型的决策依据必须能被提取出来哪怕是近似提取否则出了事故连取证都做不到。这三点都是接口层面的问题不是把模型再调大一点就能解决的。2. 纯问答式VLM的四个天花板语言理解替代不了空间推理2.1 目标检测与车道拓扑VLM能描述但不能给出可求交的几何如果让Qwen-Drive这类通用视觉语言模型回答“前方场景里有什么”它能给你一段结构完整的自然语言描述甚至带上情绪“前方有一辆白色轿车正在缓慢汇入注意避让。”听起来很聪明但下游模块没法用它做任何几何计算。白车的3D包围框中心坐标是多少朝向角是多少速度矢量是什么车道线的多项式方程长什么样前车的宽度在图像上占多少像素与真实米制的换算关系如何这些问题在自然语言里往往被模糊化处理而自动驾驶必须精确到厘米级和毫秒级。你可以说“那我让模型输出结构化JSON格式不就行了”理论上可以但VLM生成JSON字段时仍然经常出现自相矛盾3D框中心、尺寸、朝向三个字段分别生成合在一起却无法构成一个物理上可行的包围盒带标签的车道线在BEV视角下叠在一起。这说明模型只是“记住了那个形状”并没有真正理解物体在三维空间中的占位关系。可检查的3D接口要解决的正是这类一致性问题。2.2 轨迹预测是连续函数不是离散答案问答式模型擅长离散化表达比如“左变道”“加速通过”“让行”这种驾驶行为标签。但实际的轨迹是连续函数x(t)、y(t)、v(t)、a(t)一个离散的行为标签根本不足以支撑控制。举个例子模型预测“前车将直行”这个标签看似明确但直行的加速度是0.1m/s²还是0.8m/s²对自车脑内规划的影响天差地别。两辆车如果都按“直行”标签处理实际可能会发生碰撞。轨迹接口要求模型输出一组带时间戳的路径采样点每个点都包含位置、速度、加速度、概率分布、语义置信度等信息。这比生成“前车直行”四个字难得多因为连续输出的每一个采样点都要在物理上合理并且整条轨迹的平滑性、动力学可行性都必须得到保证。大多数VLM根本没有经过这种运动学约束的训练它们只会“猜一个走向”而不是“沿时间轴推演”。2.3 闭环控制缺少一个“可编译”的输出接口自动驾驶系统通常有清晰的上下游感知节点输出目标列表和占用栅格预测模块输出轨迹预测规划模块生成自车轨迹控制模块跟踪轨迹。VLM如果扮演感知和预测的融合角色它的输出必须能被这些模块以确定的接口解析。自然语言不行松散的JSON也危险最好是protobuf或IDL定义好的结构化消息字段类型、坐标系、时间戳统统有严格约定。很多做VLM的研究者会忽略这一点总觉得只要能生成正确的内容就行。但工程上“正确的数据以错误的格式输出”等于没有输出。Qwen-Drive-1.0强调的是3D与轨迹接口其实就是把“可编译性”提到了和模型能力同等重要的位置。一个只能被人类阅读、不能被机器编译的接口落地就是零。2.4 安全验证的困境没有结构化输出就无法解释和取证自动驾驶出了事故第一步不是吵架而是查日志感知模块当时识别了什么预测模块给了什么假设规划模块为什么选这条路径这套溯源链路的起点就是结构化感知输出。VLM如果只输出一句“我当时觉得前方有障碍物”对不起这在安全审查里没有任何价值。你需要的是障碍物3D检测框序列、时间戳、置信度、遮挡状态、语义类别。只有可检查的结构化接口才能支撑完整的验证链。ISO 34505:2025这类标准之所以被热议就是因为行业已经意识到光测模型“聪不聪明”没有用要测它在指定场景下做了什么决策、输出的接口数据是否满足预设条件。3. 可检查的3D接口把视觉Token变成能对齐坐标系的空间语义3.1 不是端到端黑箱而是“中间层显式化”BEV表达回到舞台中央有人会以为做通用VLM驾驶版本就是直接端到端输入图像输出方向盘转角把一切都压进网络权重里。但Qwen-Drive-1.0这类项目告诉我们真正可落地的方式是让模型在内部形成显式的3D中间表达其中最典型的代表就是BEVBirds Eye View鸟瞰图。在BEV空间里目标检测、车道线、可行驶区域都被投影到了统一的自车坐标系下数据天然具备几何一致性也方便下游做碰撞检测和路径规划。我在实际项目里发现BEV表达还有一个隐藏优势它天然给了模型一个“视觉Tokenizer”让多模态大模型和传统感知模块能共享同一套特征空间。Qwen-Drive-1.0如果能把图像Token映射到BEV网格上再用跨注意力机制去查询“这个网格里有没有物体”就会比直接让模型从像素猜坐标可靠得多。关键点是BEV不是只能给人类看它同时也是一种“可检查”的中间表示——你可以任意时刻把BEV提取出来叠加到高清地图上检查错位情况。3.2 3D高斯溅射与新视角合成提供可检查的几何先验最近相关热词里频繁出现3D Gaussian Splatting这并非巧合。通用VLM如果想获得更强的3D理解最直接的办法是让它具备一种“可微分渲染”的几何先验从单目或多目图像重建出场景的三维表示然后任意切换视角去验证感知结果。3D高斯溅射把场景表示为一系列带位置、协方差、颜色、不透明度的3D高斯体渲染速度快显存占用可控非常适合作为VLM的空间推理底座。假设Qwen-Drive-1.0在训练时加入了3D高斯重建的辅助任务模型就不是单纯“看图说话”了而是隐式地学会了从图像反推三维结构。推理时你可以对模型说“请把左前方车辆的3D位置输出”模型会通过内部的可微渲染将其对齐到一个连续几何表征里而不是从语言Token里猜一个坐标。这种可检查性还体现在你可以把模型预测的3D框反向渲染回原图看它是否与像素轮廓吻合。凡是不能通过这种几何一致性检查的预测都应该被拒绝而不是被信任。3.3 3D结构光与车辆数据集真实数据侧如何配合光靠模型结构改进还不够数据侧必须跟上。热词里出现了“工业3D结构光相机”“3D汽车模型数据集”“3D卷积自编码器”这些其实都指向同一个趋势我们需要更多精确的3D真值才能让VLM学会输出可靠的空间接口。结构光相机在近距离能够获得高精度的稠密深度图用在车辆周围近距离盲区感知、自动泊车、车内人员检测上非常合适。虽然它不适合远距离但可以作为传感器融合的一路补充尤其用于给VLM生成精确的3D监督信号。3D汽车模型数据集则是另一个方向大量高精度车型3D模型让模型不用只靠2D照片来想象车辆形状而是掌握真实的体积、门缝、车窗反光等几何细节。我自己的经验是在训练阶段把这类3D数据以渲染多视角图片的形式加入预训练模型对车辆3D包围盒的回归精度提升非常明显尤其在异形车型上不再轻易出现“把卡车当轿车”的荒谬推断。3.4 语义几何的联合损失让模型输出既自洽又可通过常规几何检查要让模型真正输出“可检查的3D接口”训练损失的设计必须同时包含语义和几何两个维度。语义损失就是常规的分类loss、属性loss告诉模型“这是什么类别”。几何损失则包括3D框回归、深度估计、BEV占用栅格交叉熵等。更关键的是要设计一个一致性损失用来惩罚语义与几何互相矛盾的输出。比如如果一个目标被分类为“行人”那么它的3D包围盒高度不能大于2米、体积不能超过某个阈值如果一个区域被语义分割为“可行驶路面”那么它的BEV占用大概率不能是障碍物。这种联合损失实际操作起来有点trick容易变成多个任务loss的简单加权和导致某个任务主导。我建议用不确定性加权或者基于梯度幅度的动态权重来平衡。另外一个很容易踩的坑是语义分支和几何分支如果共用同一个特征提取器早期收敛会有冲突最好在前几个epoch固定图像Backbone只训练投影头等几何分支稳定后再一起微调。这样训练出来的模型输出的3D接口才能经得起“把检测框投影回像素”这类几何检查。4. 轨迹接口设计从“说方案”到“给轨迹”4.1 轨迹头需要输出什么位置、速度、加速度、置信度与语义标签轨迹接口是Qwen-Drive-1.0强调的另一半。一个合格的轨迹输出头至少需要包含五组字段轨迹点序列在自车坐标系下的x、y坐标时间戳、每个点对应的速度和加速度、整条轨迹的置信度分布、驾驶意图的语义标签以及轨迹与周围障碍物的最小距离或碰撞概率。之所以要带语义标签是为了让安全层能够快速判断模型的“物理意图”——是先减速再变道还是先变道再减速这在时序上差别很大。我画过一份推荐的消息结构大致长这样{ agent_id: vehicle_12, prediction_horizon_ms: 3000, trajectory: [ {t_ms: 0, x_m: 1.2, y_m: 0.3, v_mps: 8.5, a_mps2: 0.0}, {t_ms: 500, x_m: 5.4, y_m: 0.2, v_mps: 8.6, a_mps2: 0.2}, {t_ms: 1000, x_m: 9.7, y_m: 0.1, v_mps: 8.8, a_mps2: 0.3} ], confidence: 0.92, semantic_label: lane_follow, min_distance_to_obstacle_m: 3.1 }这看起来是工程常识但很多VLM模型默认不会这么输出需要额外加一个“轨迹解码头”来做。轨迹头可以很简单就是一个MLP累加器也可以很复杂比如基于自回归逐点生成。但从可检查性角度看我强烈建议整条轨迹一次性输出而不是逐点自回归生成——自回归会放大累积误差而且很难做动力学可行性约束。4.2 时间对齐与坐标变换工程里最繁琐但决定生死的一步轨迹接口真正难的不是网络结构而是时序和坐标系。感知模块推理需要几十毫秒模型输出轨迹的时刻和物体真实位置的时刻之间存在延迟。如果直接把输出轨迹当成当前状态送给规划模块在高车速下会出大问题。所以接口里必须包含两个时间戳数据采集时刻和模型推理结束时刻。下游拿到轨迹后需要通过状态估计做时间对齐才能正确判断碰撞风险。坐标变换也是老生常谈但永远容易出错。VLM生输出的轨迹通常定义在自车坐标系通常以后轴中心或IMU位置为原点但下游规划器可能使用世界坐标系或道路坐标系。一个细微的平移偏差在高速场景下会被放大成致命的横向偏移。我建议在接口层统一使用一个高精度的TF树并且对每个轨迹点都标记它的参考坐标系ID这样即使两套坐标系存在微小变换误差也能在离线回放时查出来。4.3 与规划控制模块的对接接口不是模型内部的事很多研究项目跑到这里就停了仿佛模型能输出一条漂亮的轨迹就大功告成。但在量产系统里模型输出的轨迹只是“提议”需要交给安全层过滤、规划器优化、控制器跟踪。这里就轮到接口的另一个作用上场接口约束越多越容易接入现有模块。我见过一个团队把VLM生成的轨迹直接喂给MPC控制器但MPC要求轨迹满足车辆运动学约束比如曲率连续、加速度变化有界。VLM生成的原始轨迹根本不满足这些约束结果控制器直接抖动系统完全不可用。后来他们在接口上加了后处理做了平滑和运动学投影问题才解决。这件事给我的教训是接口的设计必须考虑到下游消费方的约束最好在输出之前就通过一个“可执行性过滤器”——如果轨迹不满足最大转向角限制就在接口层打上invalid标记宁可空输出也不要给规划器一个危险的幻觉轨迹。4.4 可干预性人类能在运行中检查并覆盖模型输出可检查的最终目的是可干预。接口不只是给机器用的也要给人看。Qwen-Drive-1.0这类系统若真要上路车上必须有一个监督者——可以是安全驾驶员也可以是远程监控员。监督者需要某个可视化界面能够看到模型输出的3D框和轨迹并且随时可以按键覆盖模型的建议轨迹。这是接口设计中最容易被忽略的产品化需求。我在测试中会强制在每次输出时保存一个“检查快照”包含原始图像、BEV结果、轨迹投影、模型置信度。这个快照既用于事后分析也用于在线审查。如果人类监督者在某个场景里覆盖了模型输出这条数据会立刻进到难例挖掘库成为下一轮微调的训练样本。通过这种“接口即产品”的思路模型会越开越稳。可以说没有可干预接口的VLM驾驶系统和没有安全网的杂技表演没区别。5. 验证体系从数据集到ISO 34505:2025的落地思路5.1 现有自动驾驶数据集为什么不够用很多人问为什么不直接用nuScenes、Waymo Open Dataset这些数据集来训练和评测Qwen-Drive-1.0我的回答是这些数据集是为传统感知算法设计的不是为VLM接口设计的。它们有标注好的3D框和轨迹但缺少“自然语言指令与轨迹的匹配标注”也缺少“可检查性”的评价协议。你要评测一个VLM输出的轨迹是否合理不能只算一个最小附加距离就完事还需要检查它是否在语义上与用户指令一致。比如你说“靠边停车”模型生成的轨迹确实向右靠了但最终停的位置跨越了实线这在传统数据集里根本找不到对应约束。所以我们需要新的数据集和新的评测任务输入多视角图像、高清地图、历史轨迹、一个自然语言驾驶指令输出对应的3D感知和轨迹并且要求接口层附带可解释性信息。相关信息在热词里对应的就是“自动驾驶数据集”和“自动驾驶算法”这两个高频词但严格来说目前还没有一个公开数据集专门支持这种VLM-接口-闭环评测很多团队只能自己造这也是我目前看到Qwen-Drive-1.0这波讨论中最值得投入的地方之一。5.2 ISO 34505:2025核心思想场景评价与用例测试生成最近热词里出现“iso 34505:2025《自动驾驶测试场景评价与用例测试生成》”正好搭上了这个话题。我简单翻了一下标准框架它的核心思想不复杂不再只依赖真实道路测试里程而是通过系统化的场景分类、参数化用例生成和关键场景评价来证明自动驾驶系统在目标交通环境中的安全性。这套方法特别适合VLM驾驶系统因为VLM的黑箱性导致传统里程累积法的说服力越来越弱业界必须使用“场景探索接口检查”的闭环验证。具体落地时ISO 34505思路可以拆成三步第一步基于危险事件、特征场景生成一批初始的场景描述第二步用参数扰动工具对道路结构、天气、交通流密度、目标车辆初始位置等进行大规模扩展第三步在仿真环境中跑模型并实时检查VLM输出的3D与轨迹接口是否违反安全条件。这套流程如果要自动化还需要一个场景生成器能读懂模型输出并判断“这个场景有没有真正被测试到”。这正是VLM可以反过来帮忙的地方用VLM离线生成更多更合理的驾驶指令和场景组合再交给传统工具做参数化。5.3 针对VLM输出接口的自动化检查工具链没有工具链的可检查性都是空谈。我理想中的检查工具链至少有四个环节接口Schema校验、几何一致性校验、动力学可行性校验、语义场景一致性校验。Schema校验最简单就是检查字段是否齐全、类型是否正确、时间戳是否单调递增。几何一致性校验会把3D框投影回图像计算IoU或边界对齐误差同时检查BEV上不同物体的包围盒是否互相重叠。动力学可行性校验则对预测轨迹做转向角限制、加速度限制检查凡是超出车辆物理极限的轨迹直接标记。这四个环节可以做成一个离线回放工具也可以做成一个实时监督节点。我自己在实际项目中是先把离线工具跑通把之前积累的10万条模型输出全部回放一遍找出那些“似懂非懂”的失败样本再根据失败模式调整模型结构和训练目标。这种“接口先定义、验证同步做、模型最后调”的顺序比先调模型再补验证要高效得多。6. 实战建议如果要在你的感知栈里集成类似Qwen-Drive的接口6.1 最小可用版本怎么搭建如果你现在想在业余项目或者毕业论文里做一个带“3D与轨迹接口”的视觉语言自动驾驶Demo我建议先别碰那些动辄几十亿参数的大模型。一个最小可用版本可以由三部分构成一个轻量的2D检测模型如RTMDet或YOLOv8负责出框一个单目深度估计模型如Depth Anything负责出深度图一个轨迹预测头和一个图像特征编码器组成轻量VLM底座。先把2D框和深度图融合成伪3D框在自车坐标系下生成目标列表再通过一个简单的规则模型生成候选轨迹。这个大杂烩方案在性能上肯定不如端到端大模型但它能让你快速把接口联调跑通。等你把接口定义清楚后再把中间的规则模型替换成真正的VLM轨迹头。我始终认为做这类系统的正确姿势是“接口驱动模型”而不是“模型驱动接口”。先定义好输出格式和可检查性指标剩下的模型选型都围绕这个接口来做。6.2 评估指标不要只看mAP要看接口可被下游使用的比例传统感知团队习惯用mAP、NDS这些指标评估模型。但对于带接口的系统我建议增加一个更关键的指标接口可用率。它的定义是模型输出能被下游模块直接使用而不触发错误处理逻辑的比例。比如输出轨迹的时序戳没有出现倒挂、3D框的尺寸全部为正、预测置信度分布在正常区间、轨迹点经过运动学过滤后仍然保留80%以上。接口可用率低意味着模型即使某些指标很漂亮真正落地时依然是废的。我记得有一次实验中一个VLM模型的3D目标检测mAP提升了3个点所有人都很高兴但一测接口可用率反而降了5%。原因是模型开始输出一些“过度自信但几何上不合法”的框被下游安全层拦截了。如果只看mAP你会被误导但看接口可用率就能一眼发现问题。这个指标也适合加入CI/CD自动化流程在每次模型更新后跑一遍离线回放确保接口可用率不下降。6.3 踩坑实录输出越“聪明”越要防幻觉接下来聊几个我实际踩过的坑。第一个坑是关于自然语言指令的过度泛化。模型在训练时看到过“前方有行人减速”这样的指令于是到实际场景中即使行人已经远离模型仍然会生成一条激进的减速轨迹。不是它看不见行人而是它把“行人”这个词的权重看得太重。解决方式是在轨迹头的语义标签预测里增加一个“消失概率”或“动态置信度”并把它传给下游让规划器知道“这条轨迹的减速理由正在衰减”。第二个坑是3D接口的自相矛盾。模型可能同时输出“前方可通行”的语义和一条向左变道的轨迹但左变道方向明明有连续障碍物。这是语义分支和轨迹分支没有共享空间特征导致的。后来我们在共享BEV特征后强制语义分支的注意力图谱去响应障碍物位置情况才好转。第三个坑是时间戳错位。VLM推理速度不稳定偶尔会有长尾延迟导致输出的轨迹时间戳并不是当前时刻。如果在接口里不做“过期保护”下游很可能会用三百毫秒前的轨迹去做当前控制这非常危险。我的经验是在接口层加一个“max_latency_ms”字段超过阈值就直接拒绝输出。6.4 我对这类系统演进的判断接口即产品回到标题里的那个论断通用视觉语言模型走向自动驾驶缺的不是更多问答而是可检查的3D与轨迹接口。我个人的看法是这不仅仅是模型架构的问题更是产品定义的问题。未来的智能驾驶系统不会只有一套传统感知、预测、规划代码而是多模态大模型与安全算子库共存。大模型负责提供高层的场景理解和长尾推理安全算子库负责用可检查的接口约束大模型输出。两者之间如果接口设计得清晰系统会越用越稳如果接口是糊的整个系统就是一团浆糊。最后说一个我最近在尝试的思路把这类可检查接口延伸到离线仿真中让VLM在仿真环境里不断“脑补”前方路况然后自动生成训练数据。Qwen-Drive-1.0提出的方向给我最大的启发不是某个具体指标多高而是它把“接口”这个概念提到了核心位置。能落地的AI永远是输出稳定、可检查、可干预的AI不是只会讲漂亮话的AI。往后不管这个命名具体指哪一版模型接口化的趋势已经非常明确了。
通用视觉语言模型落地自动驾驶：可检查的3D与轨迹接口是关键
Qwen-Drive-1.0出来之后我朋友圈里做自动驾驶的朋友分成了两拨一拨觉得通用视觉语言模型终于要接管驾驶了另一拨看了演示视频后冷冷地说了句“这跟之前那些能聊天的VLM有什么区别”。两边吵得不可开交但我注意到一个有意思的现象——真正在一线做感知融合和规划控制的工程师关注点反而不在问答质量上而在一个很工程化的词上可检查的3D与轨迹接口。这其实才是通用视觉语言模型走向自动驾驶的关键转折点也是这篇博文想展开聊透的事。1. Qwen-Drive-1.0发布之后自动驾驶圈真正在讨论什么1.1 一个反直觉的判断驾驶场景下VLM不是话太多而是眼和手不够过去一年几乎所有主流大模型团队都在给视觉语言模型VLM加能力更强的OCR、更细粒度的物体指代、更能扛多轮对话。但把这类模型放到自动驾驶域你会发现真正卡脖子的不是“它认不认识红绿灯”也不是“它能不能解释为什么要踩刹车”而是它给出的所有认知结果都停留在自然语言描述层面没法被下游规划控制模块直接消费。Qwen-Drive-1.0在标题里强调“缺的不是更多问答而是可检查的3D与轨迹接口”这句话我特别认同。一个会说话的副驾驶和一套能接管的驾驶系统之间差的不是知识量而是对三维空间和运动时序的表达能力。也就是说模型需要输出的是能放进坐标系、能求交、能碰撞检测、能被规划器调用的结构化数据而不是“前方有危险建议减速”这种正确的废话。1.2 从Chat式问答到驾驶智能VLM在车端的三种存在形态我在和不少朋友讨论时发现大家经常把VLM在车上的用法混在一起聊所以要先把形态拆开。第一种是Copilot形态模型负责语音交互、解释仪表盘、给驾驶员提示这种形态输出自然语言完全没问题因为最终决策的是人。第二种是辅助标注形态模型在离线环境下帮忙生成场景描述、挖掘corner case、生成测试用例这种形态对输出精度要求不高甚至可以容忍幻觉。第三种是端到端驾驶形态模型直接输出控制量或者轨迹这种形态对结构化程度、可验证性、实时性的要求完全不是一个量级。Qwen-Drive-1.0指向的显然是第三种。可现实是大量研究团队还在拿第一种形态的评测方法去衡量第三种形态的模型最后当然会出现“问答表现挺好但车根本没法开”的尴尬。1.3 为什么“可检查性”成了关键词而不是接管率过去我们衡量自动驾驶系统主要看接管率、MPIMiles Per Intervention这类指标。但到了VLM时代“可检查性”显得前所未有的重要。原因很简单通用视觉语言模型本身是概率生成模型你不知道它哪一次会在没见过的场景里冒出一段幻觉。对于车规级系统你不能靠“相信模型”来保证安全你必须在每个关键输出上都能回溯、能校验、能干预。可检查性体现在三个层面第一3D感知结果必须可投影到图像上与原始像素对齐让工程师能直观确认“模型说这里有车到底是不是真的有”第二轨迹输出必须能在仿真环境中重放检查是否与障碍物碰撞、是否符合交规第三模型的决策依据必须能被提取出来哪怕是近似提取否则出了事故连取证都做不到。这三点都是接口层面的问题不是把模型再调大一点就能解决的。2. 纯问答式VLM的四个天花板语言理解替代不了空间推理2.1 目标检测与车道拓扑VLM能描述但不能给出可求交的几何如果让Qwen-Drive这类通用视觉语言模型回答“前方场景里有什么”它能给你一段结构完整的自然语言描述甚至带上情绪“前方有一辆白色轿车正在缓慢汇入注意避让。”听起来很聪明但下游模块没法用它做任何几何计算。白车的3D包围框中心坐标是多少朝向角是多少速度矢量是什么车道线的多项式方程长什么样前车的宽度在图像上占多少像素与真实米制的换算关系如何这些问题在自然语言里往往被模糊化处理而自动驾驶必须精确到厘米级和毫秒级。你可以说“那我让模型输出结构化JSON格式不就行了”理论上可以但VLM生成JSON字段时仍然经常出现自相矛盾3D框中心、尺寸、朝向三个字段分别生成合在一起却无法构成一个物理上可行的包围盒带标签的车道线在BEV视角下叠在一起。这说明模型只是“记住了那个形状”并没有真正理解物体在三维空间中的占位关系。可检查的3D接口要解决的正是这类一致性问题。2.2 轨迹预测是连续函数不是离散答案问答式模型擅长离散化表达比如“左变道”“加速通过”“让行”这种驾驶行为标签。但实际的轨迹是连续函数x(t)、y(t)、v(t)、a(t)一个离散的行为标签根本不足以支撑控制。举个例子模型预测“前车将直行”这个标签看似明确但直行的加速度是0.1m/s²还是0.8m/s²对自车脑内规划的影响天差地别。两辆车如果都按“直行”标签处理实际可能会发生碰撞。轨迹接口要求模型输出一组带时间戳的路径采样点每个点都包含位置、速度、加速度、概率分布、语义置信度等信息。这比生成“前车直行”四个字难得多因为连续输出的每一个采样点都要在物理上合理并且整条轨迹的平滑性、动力学可行性都必须得到保证。大多数VLM根本没有经过这种运动学约束的训练它们只会“猜一个走向”而不是“沿时间轴推演”。2.3 闭环控制缺少一个“可编译”的输出接口自动驾驶系统通常有清晰的上下游感知节点输出目标列表和占用栅格预测模块输出轨迹预测规划模块生成自车轨迹控制模块跟踪轨迹。VLM如果扮演感知和预测的融合角色它的输出必须能被这些模块以确定的接口解析。自然语言不行松散的JSON也危险最好是protobuf或IDL定义好的结构化消息字段类型、坐标系、时间戳统统有严格约定。很多做VLM的研究者会忽略这一点总觉得只要能生成正确的内容就行。但工程上“正确的数据以错误的格式输出”等于没有输出。Qwen-Drive-1.0强调的是3D与轨迹接口其实就是把“可编译性”提到了和模型能力同等重要的位置。一个只能被人类阅读、不能被机器编译的接口落地就是零。2.4 安全验证的困境没有结构化输出就无法解释和取证自动驾驶出了事故第一步不是吵架而是查日志感知模块当时识别了什么预测模块给了什么假设规划模块为什么选这条路径这套溯源链路的起点就是结构化感知输出。VLM如果只输出一句“我当时觉得前方有障碍物”对不起这在安全审查里没有任何价值。你需要的是障碍物3D检测框序列、时间戳、置信度、遮挡状态、语义类别。只有可检查的结构化接口才能支撑完整的验证链。ISO 34505:2025这类标准之所以被热议就是因为行业已经意识到光测模型“聪不聪明”没有用要测它在指定场景下做了什么决策、输出的接口数据是否满足预设条件。3. 可检查的3D接口把视觉Token变成能对齐坐标系的空间语义3.1 不是端到端黑箱而是“中间层显式化”BEV表达回到舞台中央有人会以为做通用VLM驾驶版本就是直接端到端输入图像输出方向盘转角把一切都压进网络权重里。但Qwen-Drive-1.0这类项目告诉我们真正可落地的方式是让模型在内部形成显式的3D中间表达其中最典型的代表就是BEVBirds Eye View鸟瞰图。在BEV空间里目标检测、车道线、可行驶区域都被投影到了统一的自车坐标系下数据天然具备几何一致性也方便下游做碰撞检测和路径规划。我在实际项目里发现BEV表达还有一个隐藏优势它天然给了模型一个“视觉Tokenizer”让多模态大模型和传统感知模块能共享同一套特征空间。Qwen-Drive-1.0如果能把图像Token映射到BEV网格上再用跨注意力机制去查询“这个网格里有没有物体”就会比直接让模型从像素猜坐标可靠得多。关键点是BEV不是只能给人类看它同时也是一种“可检查”的中间表示——你可以任意时刻把BEV提取出来叠加到高清地图上检查错位情况。3.2 3D高斯溅射与新视角合成提供可检查的几何先验最近相关热词里频繁出现3D Gaussian Splatting这并非巧合。通用VLM如果想获得更强的3D理解最直接的办法是让它具备一种“可微分渲染”的几何先验从单目或多目图像重建出场景的三维表示然后任意切换视角去验证感知结果。3D高斯溅射把场景表示为一系列带位置、协方差、颜色、不透明度的3D高斯体渲染速度快显存占用可控非常适合作为VLM的空间推理底座。假设Qwen-Drive-1.0在训练时加入了3D高斯重建的辅助任务模型就不是单纯“看图说话”了而是隐式地学会了从图像反推三维结构。推理时你可以对模型说“请把左前方车辆的3D位置输出”模型会通过内部的可微渲染将其对齐到一个连续几何表征里而不是从语言Token里猜一个坐标。这种可检查性还体现在你可以把模型预测的3D框反向渲染回原图看它是否与像素轮廓吻合。凡是不能通过这种几何一致性检查的预测都应该被拒绝而不是被信任。3.3 3D结构光与车辆数据集真实数据侧如何配合光靠模型结构改进还不够数据侧必须跟上。热词里出现了“工业3D结构光相机”“3D汽车模型数据集”“3D卷积自编码器”这些其实都指向同一个趋势我们需要更多精确的3D真值才能让VLM学会输出可靠的空间接口。结构光相机在近距离能够获得高精度的稠密深度图用在车辆周围近距离盲区感知、自动泊车、车内人员检测上非常合适。虽然它不适合远距离但可以作为传感器融合的一路补充尤其用于给VLM生成精确的3D监督信号。3D汽车模型数据集则是另一个方向大量高精度车型3D模型让模型不用只靠2D照片来想象车辆形状而是掌握真实的体积、门缝、车窗反光等几何细节。我自己的经验是在训练阶段把这类3D数据以渲染多视角图片的形式加入预训练模型对车辆3D包围盒的回归精度提升非常明显尤其在异形车型上不再轻易出现“把卡车当轿车”的荒谬推断。3.4 语义几何的联合损失让模型输出既自洽又可通过常规几何检查要让模型真正输出“可检查的3D接口”训练损失的设计必须同时包含语义和几何两个维度。语义损失就是常规的分类loss、属性loss告诉模型“这是什么类别”。几何损失则包括3D框回归、深度估计、BEV占用栅格交叉熵等。更关键的是要设计一个一致性损失用来惩罚语义与几何互相矛盾的输出。比如如果一个目标被分类为“行人”那么它的3D包围盒高度不能大于2米、体积不能超过某个阈值如果一个区域被语义分割为“可行驶路面”那么它的BEV占用大概率不能是障碍物。这种联合损失实际操作起来有点trick容易变成多个任务loss的简单加权和导致某个任务主导。我建议用不确定性加权或者基于梯度幅度的动态权重来平衡。另外一个很容易踩的坑是语义分支和几何分支如果共用同一个特征提取器早期收敛会有冲突最好在前几个epoch固定图像Backbone只训练投影头等几何分支稳定后再一起微调。这样训练出来的模型输出的3D接口才能经得起“把检测框投影回像素”这类几何检查。4. 轨迹接口设计从“说方案”到“给轨迹”4.1 轨迹头需要输出什么位置、速度、加速度、置信度与语义标签轨迹接口是Qwen-Drive-1.0强调的另一半。一个合格的轨迹输出头至少需要包含五组字段轨迹点序列在自车坐标系下的x、y坐标时间戳、每个点对应的速度和加速度、整条轨迹的置信度分布、驾驶意图的语义标签以及轨迹与周围障碍物的最小距离或碰撞概率。之所以要带语义标签是为了让安全层能够快速判断模型的“物理意图”——是先减速再变道还是先变道再减速这在时序上差别很大。我画过一份推荐的消息结构大致长这样{ agent_id: vehicle_12, prediction_horizon_ms: 3000, trajectory: [ {t_ms: 0, x_m: 1.2, y_m: 0.3, v_mps: 8.5, a_mps2: 0.0}, {t_ms: 500, x_m: 5.4, y_m: 0.2, v_mps: 8.6, a_mps2: 0.2}, {t_ms: 1000, x_m: 9.7, y_m: 0.1, v_mps: 8.8, a_mps2: 0.3} ], confidence: 0.92, semantic_label: lane_follow, min_distance_to_obstacle_m: 3.1 }这看起来是工程常识但很多VLM模型默认不会这么输出需要额外加一个“轨迹解码头”来做。轨迹头可以很简单就是一个MLP累加器也可以很复杂比如基于自回归逐点生成。但从可检查性角度看我强烈建议整条轨迹一次性输出而不是逐点自回归生成——自回归会放大累积误差而且很难做动力学可行性约束。4.2 时间对齐与坐标变换工程里最繁琐但决定生死的一步轨迹接口真正难的不是网络结构而是时序和坐标系。感知模块推理需要几十毫秒模型输出轨迹的时刻和物体真实位置的时刻之间存在延迟。如果直接把输出轨迹当成当前状态送给规划模块在高车速下会出大问题。所以接口里必须包含两个时间戳数据采集时刻和模型推理结束时刻。下游拿到轨迹后需要通过状态估计做时间对齐才能正确判断碰撞风险。坐标变换也是老生常谈但永远容易出错。VLM生输出的轨迹通常定义在自车坐标系通常以后轴中心或IMU位置为原点但下游规划器可能使用世界坐标系或道路坐标系。一个细微的平移偏差在高速场景下会被放大成致命的横向偏移。我建议在接口层统一使用一个高精度的TF树并且对每个轨迹点都标记它的参考坐标系ID这样即使两套坐标系存在微小变换误差也能在离线回放时查出来。4.3 与规划控制模块的对接接口不是模型内部的事很多研究项目跑到这里就停了仿佛模型能输出一条漂亮的轨迹就大功告成。但在量产系统里模型输出的轨迹只是“提议”需要交给安全层过滤、规划器优化、控制器跟踪。这里就轮到接口的另一个作用上场接口约束越多越容易接入现有模块。我见过一个团队把VLM生成的轨迹直接喂给MPC控制器但MPC要求轨迹满足车辆运动学约束比如曲率连续、加速度变化有界。VLM生成的原始轨迹根本不满足这些约束结果控制器直接抖动系统完全不可用。后来他们在接口上加了后处理做了平滑和运动学投影问题才解决。这件事给我的教训是接口的设计必须考虑到下游消费方的约束最好在输出之前就通过一个“可执行性过滤器”——如果轨迹不满足最大转向角限制就在接口层打上invalid标记宁可空输出也不要给规划器一个危险的幻觉轨迹。4.4 可干预性人类能在运行中检查并覆盖模型输出可检查的最终目的是可干预。接口不只是给机器用的也要给人看。Qwen-Drive-1.0这类系统若真要上路车上必须有一个监督者——可以是安全驾驶员也可以是远程监控员。监督者需要某个可视化界面能够看到模型输出的3D框和轨迹并且随时可以按键覆盖模型的建议轨迹。这是接口设计中最容易被忽略的产品化需求。我在测试中会强制在每次输出时保存一个“检查快照”包含原始图像、BEV结果、轨迹投影、模型置信度。这个快照既用于事后分析也用于在线审查。如果人类监督者在某个场景里覆盖了模型输出这条数据会立刻进到难例挖掘库成为下一轮微调的训练样本。通过这种“接口即产品”的思路模型会越开越稳。可以说没有可干预接口的VLM驾驶系统和没有安全网的杂技表演没区别。5. 验证体系从数据集到ISO 34505:2025的落地思路5.1 现有自动驾驶数据集为什么不够用很多人问为什么不直接用nuScenes、Waymo Open Dataset这些数据集来训练和评测Qwen-Drive-1.0我的回答是这些数据集是为传统感知算法设计的不是为VLM接口设计的。它们有标注好的3D框和轨迹但缺少“自然语言指令与轨迹的匹配标注”也缺少“可检查性”的评价协议。你要评测一个VLM输出的轨迹是否合理不能只算一个最小附加距离就完事还需要检查它是否在语义上与用户指令一致。比如你说“靠边停车”模型生成的轨迹确实向右靠了但最终停的位置跨越了实线这在传统数据集里根本找不到对应约束。所以我们需要新的数据集和新的评测任务输入多视角图像、高清地图、历史轨迹、一个自然语言驾驶指令输出对应的3D感知和轨迹并且要求接口层附带可解释性信息。相关信息在热词里对应的就是“自动驾驶数据集”和“自动驾驶算法”这两个高频词但严格来说目前还没有一个公开数据集专门支持这种VLM-接口-闭环评测很多团队只能自己造这也是我目前看到Qwen-Drive-1.0这波讨论中最值得投入的地方之一。5.2 ISO 34505:2025核心思想场景评价与用例测试生成最近热词里出现“iso 34505:2025《自动驾驶测试场景评价与用例测试生成》”正好搭上了这个话题。我简单翻了一下标准框架它的核心思想不复杂不再只依赖真实道路测试里程而是通过系统化的场景分类、参数化用例生成和关键场景评价来证明自动驾驶系统在目标交通环境中的安全性。这套方法特别适合VLM驾驶系统因为VLM的黑箱性导致传统里程累积法的说服力越来越弱业界必须使用“场景探索接口检查”的闭环验证。具体落地时ISO 34505思路可以拆成三步第一步基于危险事件、特征场景生成一批初始的场景描述第二步用参数扰动工具对道路结构、天气、交通流密度、目标车辆初始位置等进行大规模扩展第三步在仿真环境中跑模型并实时检查VLM输出的3D与轨迹接口是否违反安全条件。这套流程如果要自动化还需要一个场景生成器能读懂模型输出并判断“这个场景有没有真正被测试到”。这正是VLM可以反过来帮忙的地方用VLM离线生成更多更合理的驾驶指令和场景组合再交给传统工具做参数化。5.3 针对VLM输出接口的自动化检查工具链没有工具链的可检查性都是空谈。我理想中的检查工具链至少有四个环节接口Schema校验、几何一致性校验、动力学可行性校验、语义场景一致性校验。Schema校验最简单就是检查字段是否齐全、类型是否正确、时间戳是否单调递增。几何一致性校验会把3D框投影回图像计算IoU或边界对齐误差同时检查BEV上不同物体的包围盒是否互相重叠。动力学可行性校验则对预测轨迹做转向角限制、加速度限制检查凡是超出车辆物理极限的轨迹直接标记。这四个环节可以做成一个离线回放工具也可以做成一个实时监督节点。我自己在实际项目中是先把离线工具跑通把之前积累的10万条模型输出全部回放一遍找出那些“似懂非懂”的失败样本再根据失败模式调整模型结构和训练目标。这种“接口先定义、验证同步做、模型最后调”的顺序比先调模型再补验证要高效得多。6. 实战建议如果要在你的感知栈里集成类似Qwen-Drive的接口6.1 最小可用版本怎么搭建如果你现在想在业余项目或者毕业论文里做一个带“3D与轨迹接口”的视觉语言自动驾驶Demo我建议先别碰那些动辄几十亿参数的大模型。一个最小可用版本可以由三部分构成一个轻量的2D检测模型如RTMDet或YOLOv8负责出框一个单目深度估计模型如Depth Anything负责出深度图一个轨迹预测头和一个图像特征编码器组成轻量VLM底座。先把2D框和深度图融合成伪3D框在自车坐标系下生成目标列表再通过一个简单的规则模型生成候选轨迹。这个大杂烩方案在性能上肯定不如端到端大模型但它能让你快速把接口联调跑通。等你把接口定义清楚后再把中间的规则模型替换成真正的VLM轨迹头。我始终认为做这类系统的正确姿势是“接口驱动模型”而不是“模型驱动接口”。先定义好输出格式和可检查性指标剩下的模型选型都围绕这个接口来做。6.2 评估指标不要只看mAP要看接口可被下游使用的比例传统感知团队习惯用mAP、NDS这些指标评估模型。但对于带接口的系统我建议增加一个更关键的指标接口可用率。它的定义是模型输出能被下游模块直接使用而不触发错误处理逻辑的比例。比如输出轨迹的时序戳没有出现倒挂、3D框的尺寸全部为正、预测置信度分布在正常区间、轨迹点经过运动学过滤后仍然保留80%以上。接口可用率低意味着模型即使某些指标很漂亮真正落地时依然是废的。我记得有一次实验中一个VLM模型的3D目标检测mAP提升了3个点所有人都很高兴但一测接口可用率反而降了5%。原因是模型开始输出一些“过度自信但几何上不合法”的框被下游安全层拦截了。如果只看mAP你会被误导但看接口可用率就能一眼发现问题。这个指标也适合加入CI/CD自动化流程在每次模型更新后跑一遍离线回放确保接口可用率不下降。6.3 踩坑实录输出越“聪明”越要防幻觉接下来聊几个我实际踩过的坑。第一个坑是关于自然语言指令的过度泛化。模型在训练时看到过“前方有行人减速”这样的指令于是到实际场景中即使行人已经远离模型仍然会生成一条激进的减速轨迹。不是它看不见行人而是它把“行人”这个词的权重看得太重。解决方式是在轨迹头的语义标签预测里增加一个“消失概率”或“动态置信度”并把它传给下游让规划器知道“这条轨迹的减速理由正在衰减”。第二个坑是3D接口的自相矛盾。模型可能同时输出“前方可通行”的语义和一条向左变道的轨迹但左变道方向明明有连续障碍物。这是语义分支和轨迹分支没有共享空间特征导致的。后来我们在共享BEV特征后强制语义分支的注意力图谱去响应障碍物位置情况才好转。第三个坑是时间戳错位。VLM推理速度不稳定偶尔会有长尾延迟导致输出的轨迹时间戳并不是当前时刻。如果在接口里不做“过期保护”下游很可能会用三百毫秒前的轨迹去做当前控制这非常危险。我的经验是在接口层加一个“max_latency_ms”字段超过阈值就直接拒绝输出。6.4 我对这类系统演进的判断接口即产品回到标题里的那个论断通用视觉语言模型走向自动驾驶缺的不是更多问答而是可检查的3D与轨迹接口。我个人的看法是这不仅仅是模型架构的问题更是产品定义的问题。未来的智能驾驶系统不会只有一套传统感知、预测、规划代码而是多模态大模型与安全算子库共存。大模型负责提供高层的场景理解和长尾推理安全算子库负责用可检查的接口约束大模型输出。两者之间如果接口设计得清晰系统会越用越稳如果接口是糊的整个系统就是一团浆糊。最后说一个我最近在尝试的思路把这类可检查接口延伸到离线仿真中让VLM在仿真环境里不断“脑补”前方路况然后自动生成训练数据。Qwen-Drive-1.0提出的方向给我最大的启发不是某个具体指标多高而是它把“接口”这个概念提到了核心位置。能落地的AI永远是输出稳定、可检查、可干预的AI不是只会讲漂亮话的AI。往后不管这个命名具体指哪一版模型接口化的趋势已经非常明确了。