企业官网建设流程全解析

Qwen-Drive-1.0这个方向最近讨论度很高。它把通用视觉语言模型（VLM）拉进了自动驾驶的核心流程，但真正让我觉得值得写一篇长文的，不是它又刷了多少榜单，而是它把问题定义换了：一个能上车的视觉语言模型，缺的不是更多问答能力，而是可检查的3D与轨迹接口。

如果你跟我一样，过去两年既在追多模态大模型，又没少被端到端自动驾驶的黑盒问题折磨，那你应该能立刻get到这个变化的重量。以前我们看VLM+自动驾驶的demo，基本都是让模型对着一张路测图回答“前方有没有行人”“能不能变道”，模型答得头头是道，可一旦要把它接进真实规控管线，马上发现无从下手：输出的文字没有坐标、没有时间戳、没有可量化的置信度，更没有可以被下游模块直接消费的结构化接口。

Qwen-Drive-1.0想做的是另一件事：让视觉语言模型不仅能“看懂”场景，还能直接吐出任一步骤都能回放的3D感知结果和多模态轨迹预测结果。这篇文章就围绕这个点展开，聊聊它为什么卡在“3D与轨迹接口”上，以及我们做工程落地时，该怎么理解、验证、使用这类接口。适合正在研究多模态大模型、端到端自动驾驶、数据闭环，或者被“黑盒模型能否上车”这个问题困扰的同行一起讨论。

1. 先聊清楚：VLM上车，为什么光会“答问题”远远不够

1.1 Qwen-Drive-1.0在做什么

先说结论：Qwen-Drive-1.0不是又一个“看图说话”的驾驶问答模型，而是把视觉语言理解与自动驾驶的结构化输出结合在了一起。它仍然保留了VLM的场景理解、常识推理、复杂指令跟随能力，但更重要的是，它在模型输出侧增加了可被自动驾驶系统直接读取的接口，其中最关键的就是3D感知接口和轨迹预测接口。

这么说可能有点抽象，我拆开讲。视觉语言模型本质上是一个多模态Transformer，输入是图像/视频加文本，输出是文本，这是大家熟悉的范式。但自动驾驶场景里，文本输出只能用于人机交互、离线分析、知识问答，它没有办法直接变成方向盘的转角、刹车踏板的力度。Qwen-Drive-1.0这类模型的设计思路，是在VLM主干之上增加专门的输出头，把“对场景的理解”转成“对驾驶有用的一系列数值和结构化数据”，比如3D目标框、占用网格、未来轨迹点序列。

这类设计在业界其实已经有一些探索，比如把VLM当作“感知增强器”，在传统规控管线上做辅助决策；也有把大模型当成“端到端决策器”，直接输出轨迹。Qwen-Drive-1.0更接近后者，但它特别强调了一个词：可检查（inspectable）。这意味着模型的每一项关键输出，都能被开发人员“打开看一看”，能回放、能验证、能干预，而不是丢给你一个神经网络内部的隐向量。

1.2 问答式VLM在真实驾驶场景里为什么不好使

很多刚接触这个方向的同学会疑惑：让模型多回答几个问题，比如“前方是什么车”“这个路口能不能左转”，难道不是也能辅助驾驶吗？我的经验是，这类“问答式”输出在真实驾驶任务中有三重结构性短板。

第一，没有几何信息。自然语言说“前方有一辆车”，但规控模块需要知道这辆车在哪：距离多远、横向偏移多少、朝向如何、速度多快。语言描述可以给出相对位置，却给不出精确的几何参数。前方是一辆停在路边的车还是一辆正在汇入我车道的车，对决策的影响完全不同，只靠问答根本没法区分清楚。

第二，没有时序信息。自动驾驶是做预测和规划的，模型需要回答的不是“此刻图里有什么”，而是“接下来三到五秒会发生什么、我该怎么办”。单帧问答顶多描述当前场景，无法给出未来轨迹。十字路口是直行还是左转、前车会不会急刹、行人会不会横穿，这些决策不仅依赖当前帧，更依赖对未来的估计。

第三，没有闭环接口。就算模型用自然语言说出了“应该减速”，直接把这个文本发给下游控制器也是不可行的。真实自动驾驶系统有用例驱动的接口约定，规划模块能消费的是轨迹点、速度曲线、目标框列表，不是一句话。问答式输出只能做展示和人机交互，无法参与实车闭环。这也是很多演示项目“看起来酷、用不起来”的根本原因。

1.3 “可检查的3D与轨迹接口”到底指什么

把这个问题想透之后，你就能理解标题里那句判断的真正分量：通用视觉语言模型走向自动驾驶，缺的不是更多问答，而是可检查的3D与轨迹接口。

这里的“3D接口”指模型能输出带三维几何意义的感知结果，比如3D目标框、BEV栅格、占用网格、深度估计等。有了这些输出，系统才能在一个统一的三维空间里讨论“我”和“其他物体”的相对关系。光有2D检测框是远远不够的，因为2D框没有深度，无法知道前车距离是10米还是50米。

“轨迹接口”指模型能输出未来一段时间内自车的行驶轨迹，通常是一串带时间戳的waypoint，也可能是多条候选轨迹和对应的置信度。轨迹接口是连接感知与决策的桥梁，有了它，下游控制模块才能执行“向左变道”“跟车减速”等具体操作。

“可检查”要更细一层。它意味着每个输出都有明确坐标系、时间戳、物理单位，可以回放到原始传感器数据上进行验证。3D框可以投影回图像里看对不对，轨迹预测可以跟真实人类驾驶轨迹做对比，还可以在仿真环境里闭环测试。这种“能验证、能调试、能干预”的特征，是量产自动驾驶工程最看重的东西。

2. 核心设计思路拆解：从“图片+文本”到“3D空间+预测轨迹”

2.1 3D感知分支怎么构建“带坐标的视觉”

我见过不少团队尝试把VLM用于驾驶理解，最常见的方式是把图像直接扔进Transformer，让模型输出自然语言。这种路子对封闭数据集有效，但一到开放道路就露馅，根本原因是没有几何坐标系的概念。

Qwen-Drive-1.0在架构上很关键的思路，是在VLM主干之上接一个3D感知头。这个感知头会把多视角摄像机图像、自车姿态、可选的点云信息融合起来，生成BEV（鸟瞰图）特征，然后在这个特征基础上输出3D目标框列表和占用网格。BEV之所以重要，是因为它把所有检测结果都投影到了自车坐标系下的一个水平平面上，上游感知和下游规控能共用同一套空间语言。

具体到输出项，3D接口至少包括这几类：目标类别、3D中心坐标（通常以自车为原点，x为前向，y为左侧，单位米）、目标长宽高、朝向角（yaw角）、速度估计。此外，很多方案还会输出带语义的占用栅格（occupancy grid），把可行驶区域、障碍物、未知区域都画到一个栅格上。

这里有一个值得注意的技术细节：为了得到高质量的BEV特征，很多模型会用到3D卷积或者3D卷积自编码器这类结构。因为BEV特征本身是H×W×C的立体张量，如果在空间维度上只用2D卷积，很难捕捉物体遮挡、竖向上的结构信息。3D卷积自编码器可以学到一个紧凑的场景表示，把多帧观测压缩成更容易被轨迹解码器使用的特征。

2.2 轨迹接口为什么不是“输出一条线”那么简单

很多非自动驾驶背景的人第一次听到“轨迹接口”，会以为就是一个简单的坐标序列。实际远不是这么回事。一个合格的轨迹接口，必须同时表达“我想怎么走”和“我有多确定”。

Qwen-Drive-1.0这类模型在轨迹分支上通常输出多条候选轨迹，每条轨迹由未来若干时刻的waypoint组成，每个waypoint包含位置坐标、朝向、速度等。为什么要多条？因为驾驶决策本身是多模态的，同一个路口，我可以直行，也可以左转，这是两种完全合法的行为。只给一条轨迹，等于强行砍掉了决策的多样性，遇到突发事件很难有备选方案。

每条候选轨迹会带一个概率或分数，表示模型认为这条轨迹的合理程度。更重要的一点是，轨迹分支应该能让开发人员看到“模型是依据哪些场景特征做出这个判断的”。比如模型预测前车会减速，那这个预测应该能追溯到前车的3D位置、相对速度、刹车灯状态等具体线索。这样一来，轨迹输出就不再是黑盒里的一个向量，而是一个可解释、可审计的决策结果。

这也是我在实操中最看重的一点：轨迹接口和自然语言解释最好同时给出，且相互对齐。自然语言说“我要变道”，轨迹接口就必须真的输出一条变道曲线，两条输出不能打架。一旦语言描述和轨迹出现不一致，测试阶段还能接受，实车阶段就是安全风险。

2.3 统一接口架构怎么把VLM“接进”自动驾驶系统

模型设计得再好，如果不能融入现有自动驾驶软件栈，价值也大打折扣。这里说的软件栈，通常包括感知（perception）、预测（prediction）、规划（planning）、控制（control）四个模块。

Qwen-Drive-1.0给出的方案，是把VLM的输出设计成下游模块可以直接消费的标准格式。3D感知接口对接的是传统的感知模块和Fusion模块，轨迹接口对接的是规划和控制模块。换句话说，它不是在旁边外挂一个“智能问答盒子”，而是让自己成为新的感知与决策主干。

我在工程实践里有一个很深的体会：接口设计决定了模型能被工程接受的下限。如果接口是自定义的私有格式，团队就得专门写一堆适配代码；如果接口贴近行业通用标准，例如类似Apollo、Autoware这类开源框架的消息格式，那集成成本会低很多。Qwen-Drive-1.0至少在接口形态上走了对的方向，3D输出与轨迹输出从数据结构上看，都是可反序列化、可记录、可回放的。这对后续的数据闭环和测试验证非常友好。

3. 实操落地视角：数据、时间同步与仿真评测是三道硬门槛

3.1 数据闭环里最容易被低估的事：3D标注质量

做这类模型，数据质量几乎决定上限。我可以负责任地说，绝大多数团队跑不通VLM+自动驾驶，不是模型实现不了，而是数据准备阶段就垮了。

训练3D感知分支和轨迹分支，需要海量带精确3D标注的自动驾驶数据。传统自动驾驶数据集，比如nuScenes、Waymo Open Dataset、Argoverse，都提供了3D框、轨迹真值、传感器标定和时间戳信息，是很好的训练底座。但对于VLM模型的特殊之处在于，它还需要同时提供自然语言描述或问答标注，这就是很多研究团队会用DriveLM、NuScenes-QA这类驾驶语言数据集的原因。

真正容易踩坑的是3D标注噪声。自动驾驶数据集里，远处小目标经常漏标，遮挡严重的物体边界框不稳，激光雷达盲区里的目标可能干脆没有标注。如果模型在全是漏标的区域被训练出来，感知结果就会显得“有选择地失明”。我曾经在调试一个模型时发现，它对右侧相邻车道的大货车检测极不稳定，后来查数据才发现，数据集中货车类别的3D框标注本身就前后不一致。这个问题不解决，后面的轨迹预测再漂亮都白搭。

3.2 时间同步：3D感知和轨迹预测绕不开的坑

说到做自动驾驶数据处理，时间同步绝对是被新手忽略最多、却最容易引发诡异问题的一环。

3D感知通常融合多路传感器：摄像头、毫米波雷达、激光雷达。各路传感器采样频率不同，延迟也不同，如果时间戳没有对齐，就会出现一个很尴尬的现象：摄像头看到的是t时刻的场面，激光雷达扫描的已经是t+30ms的场面，融合出的3D框在高速场景下直接“飘”出去。轨迹预测对时间同步更敏感，模型要预测的是“当前时刻之后3秒”的轨迹，如果当前时刻本身就不准，那预测结果就成了“对错误时刻的准确预测”。

实践中做时间同步，最基本的是把毫米波雷达、激光雷达点云、图像都外推到统一时间戳，通常以控制器或融合模块的主时钟为基准。更成熟的做法是引入协方差插值、动态延迟补偿，在传感器驱动层面就算好每一帧数据的“有效时刻”。

我还想提醒一点：时间同步不只是传感器之间的事，模型输出的轨迹时间戳也得和传感器时间基准对齐。如果模型输出的waypoint是基于“收到图像那一刻”的，而下游规划模块计算时用的是“当前控制周期开始”的时刻，两者之间差出几十毫秒到上百毫秒，在高速变道场景就是半米到几米的偏差。

3.3 模型的仿真与闭环评测该怎么做

接口可检查的好处，在测试阶段体现得最充分。我做这类模型验证时，习惯分成两个阶段：开环测试和闭环测试。

开环测试阶段，把测试数据跑一遍，比较模型的3D检测与真值框的重合度，比较轨迹预测与人类驾驶轨迹的误差。常用指标包括3D目标检测的mAP、平均位移误差ADE、最终位移误差FDE、碰撞率等。这些指标能快速暴露模型在感知和预测上的明显缺陷，优点是快、可控、可复现。

闭环测试阶段，把轨迹接口插到仿真器里跑。常用的有CARLA这类高保真驾驶仿真器，模型输出的3D感知结果作为仿真器的“虚拟传感器输入”或真值替换，轨迹输出直接驱动虚拟车辆。重点观察模型在连续场景里能不能稳定行驶：变道会不会压线、路口起步会不会犹豫、面对突然切入的车辆会不会急刹。开环我见过模型单帧指标很漂亮，可一进闭环就频繁被后方来车逼停，原因往往是轨迹多模态不够丰富，只预测了“前车保持车道”这一种未来，没有给“前车变道”留候选。

仿真评测阶段最重要的一个原则，是接口日志必须齐全。每个决策点对应的3D目标框、候选轨迹、最终选中的轨迹，都要能逐帧回放。否则出了问题，你想查是感知错了还是决策错了，根本无从下手。

4. 行业路线观察：为什么“可检查接口”是量产的关键分水岭

4.1 端到端与模块化之争，接口是最大公约数

自动驾驶行业这两年争论最多的话题之一，就是端到端大模型方案和传统规则模块化方案到底谁更优。端到端方案的优势是决策流畅、系统简单、能学习复杂交互，缺点是解释性差、安全验证难、遇到分布外场景没有兜底。模块化方案可控性强、容易验证，但工程浩大、规则之间打架严重。

Qwen-Drive-1.0走了一条很有意思的中间路线：底层依然是VLM这种端到端的大模型表现形式，但输出层固定为结构化接口。这种做法相当于把“模型内部的自由发挥”限制在了3D框和轨迹这个语义层，保住了神经网络的模式识别能力，又给了工程师一个可以介入、校验、监督的抓手。

从我的实际经验来看，这种“可控式端到端”是当前最有可能落地的方向。纯黑盒端到端，安全评审委员会大概率一票否决；纯规则系统，又很难覆盖长尾场景。把大模型输出统一成可检查的结构化接口，等于告诉所有利益相关方：我在黑盒和透明之间找了个折中点，你想看细节随时可以看，你想干预随时可以接。

4.2 周边技术生态：3D高斯泼溅、占用网络和数据集进化

可检查的3D接口能成为趋势，离不开周边技术的共振。占用网格（occupancy grid）这几年已经成为自动驾驶感知的主流表示，它把场景切分成均匀网格，每个网格标注是否被占用、被什么东西占用。Qwen-Drive-1.0用BEV和体素化的思路，本质上是同一套语言，所以天然容易融合。

另一个值得关注的是3D高斯泼溅。这个技术本来主要应用于三维重建和渲染，现在也被一些团队用来表示动态场景。如果未来VLM可以用3D高斯泼溅生成可查询的场景表示，那“3D接口”从技术形态上还会有一次升级：模型输出的不再只是一个网格，而是一个连续、可渲染、可动态更新的场景模型。这种表示比固定栅格更细腻，也更适合做决策层的空间推理。

我还想强调数据集进化的方向。现有的驾驶问答数据集，比如DriveLM、NuScenes-QA，主要提供图像+问题的文本答案，这对VLM的对话能力有帮助，但对驾驶任务的直接帮助有限。下一阶段的驾驶语言数据集，必须把自然语言问题和3D框、轨迹真值绑在一起，甚至要做到“同一段数据，既有问答标注，又有轨迹标注”。模型才能真正学会把语言理解和结构化输出统一起来，而不是两条腿走路。

4.3 对研发团队的影响：岗位和流程都会跟着变

这个话题看起来偏管理，但实际上对每个做技术的人都有影响。过去自动驾驶团队分工很清晰：感知组交付目标框，预测组交付轨迹，规划组负责决策。VLM带着可检查接口进来之后，这种边界会被打散。

VLM团队和感知团队对接的是“3D接口的精度和召回”；和预测团队对接的是“多模态轨迹的分布合理性”；和规划团队对接的是“候选轨迹是否满足安全约束”。如果一个团队只把自己当成“做模型发论文的”，不关心接口能不能被下游消费，很快就会被替换掉。这也是我在带项目时反复强调的一点：模型输出必须像API一样设计，明确输入、输出、异常处理、版本兼容。

4.4 它会不会替代传统规控模块

很多人问，既然VLM都能输出轨迹了，那是不是传统规划控制模块就没用了？我的看法是，短中期内不会，也不应该。轨迹接口提供的是“行为建议”，不是“控制指令”。它缺少安全兜底，没有碰撞检测和最小风险机动策略，遇到完全超出训练分布的极端场景，没有人敢把方向盘完全交给一个1050亿参数的大模型。

更合理的做法，是VLM输出多条候选轨迹和理由，下层安全模块做碰撞检测、交规校验，最后由仲裁模块决定执行哪一条，或者是否转入安全停车。轨迹接口成了大模型和传统系统之间的“合同”：“我给你的是一系列可选行为，以及每个行为的依据，你来兜底。”这种分工，既保住了大模型的理解能力，也保住了系统安全性的底线。

5. 工程落地中的常见问题与避坑实录

5.1 常见问题速查表

这张表里的问题，我在不同项目里至少都撞到过一遍。尤其是第一行“坐标系搞混”，听起来很基础，但在实际开发中极其常见。相机坐标系、激光雷达坐标系、自车坐标系、世界坐标系，每经过一次变换都可能引入一次手误，没有可视化的投影校样，这类错误能潜伏很久。

5.2 我判断一个“可检查接口”是否合格的三个标准

面对任何一个宣称支持3D或轨迹输出的VLM模型，我拿到手的第一步不是跑榜，而是先看三个基本问题。

标准一：每个输出都能对应回输入空间。3D框能不能投影回原始图像？占用网格能不能和激光雷达点云叠加显示？如果能，说明系统在空间上是可验证的；如果不能，那么这个接口的可检查性就是纸上谈兵。

标准二：每个输出都有明确的物理单位。位置是米，速度是米/秒，朝向是弧度或角度，时间戳是哪一时刻。很多模型论文只给一个坐标数组，根本不标注单位，这种接口在工程上几乎不可用。没有物理单位的输出，连安全评审的门槛都迈不过去。

标准三：每个输出都有明确坐标系定义和时间戳。我在实际集成时吃过一次大亏，模型输出的轨迹点看着完整，后来才发现它用的是“接收图像时的自车坐标系”，而不是“当前时刻的自车坐标系”，在一段高速变道场景里直接偏出去两米。这个教训让我后来对所有接口都强制要求：坐标系和时间戳必须在消息结构里显式声明。

5.3 给正在做相关工作的工程师几条经验

第一句话：先跑通一条最小路径，再去追求模型大小。选一段简单的结构化道路场景，用现有数据集训练一个能输出3D框和轨迹的小模型，先把接口整条链路跑通，再谈增加参数量。

第二句话：把自然语言当作解释层，别当作控制层。语言输出适合做人机交互、离线分析、系统诊断，但它不应该成为唯一决策来源。控制层面必须依赖结构化接口，否则没有任何安全机制能兜底。

第三句话：做数据闭环时，把模型的“不确定帧”捞出来人工复核。模型在哪帧轨迹出现明显偏离、在哪帧3D检测漏报，这些就是数据闭环最值得回传的数据。回传后重新标注、增量训练，比一股脑堆数据效率高得多。

第四句话：不要忽略低算力设备上的实时性。模型设计的再花哨，上不了车也没有意义。Qwen-Drive-1.0这类视觉语言模型普遍参数规模不小，真正用起来还需要考虑量化、剪枝、计算图优化，以及和车端芯片的适配。我在实测中发现，接口设计如果能做成计算友好的形式，比如提前把3D检测和轨迹预测分成不同频率执行，实时性压力会小很多。

5.4 从研究到产品的后续扩展空间

如果你读到这里，想沿着这个方向继续做点什么，我个人觉得有四个可以深挖的点。一是把轨迹接口和自然语言解释做更深度的对齐，让模型不仅“会开车”，还能“会解释为什么这么开车”。二是在3D接口里引入更稠密的场景表示，比如体素占用加上语义类别，让模型对复杂城市障碍物有更细粒度的理解。三是做多传感器时间同步与建模的联合优化，把时间同步从“预处理环节”变成“可学习的环节”。四是构建更高质量的驾驶语言+轨迹联合数据集，这件事单独作为工程课题都有很大的价值。

我个人的体会是，这几年从大语言模型火到多模态大模型，再到VLM上车，技术迭代很快，很多团队容易陷入“追着参数和榜单跑”的惯性。但自动驾驶这个领域，真正的护城河不是模型能答多少问题，而是整个系统在复杂危险的世界里亏多少分可控。Qwen-Drive-1.0把“可检查的3D与轨迹接口”放到了台面上，等于给了所有做落地的人一个信号：大模型要上车，先得让系统看见它、验证它、管住它。接口的可检查性，不是学术洁癖，是工程底线。