最近总有人问我一句话：你们做自动驾驶那套基础模型，能不能直接搬过去做具身智能？问的人多了，我意识到这不是个别人的想法，而是行业里普遍存在的期待——一套模型通吃自动驾驶和机器人操作，省数据、省算力、省人力，听起来确实诱人。但每次听到这个问题，我都忍不住先反问一句：你说的“通吃”，是指用同一套权重跑两个任务，还是指用同一套架构和训练管线适配两个场景？这两种理解，难度差了十倍不止。
先说结论：目前没有任何公开的、可验证的基础模型能在自动驾驶和具身智能这两件事上端到端通吃，而且我认为短期内也不会出现。但这个结论并不悲观，因为“不能通吃”不代表“不能共享”，恰恰相反，这两条赛道在数据表征、世界模型、仿真迁移等层面有大量可以复用的技术底座。这篇文章我想拆开来讲清楚：为什么大家会产生“通吃”的念头，技术上卡在哪几个关键环节，以及现实中更值得走的路径是什么。内容偏工程实践，很多细节是从我实际的跑实验、调模型、修bug经历里捞出来的，希望能帮在这个路口徘徊的团队省点试错成本。
1. “通吃”的诱惑：从自动驾驶到具身智能的逻辑链条
1.1 技术外溢的必然性：数据、架构与人才的三重驱动
“一套模型通吃”这种想法不是凭空冒出来的，它有非常现实的技术外溢背景。过去五年自动驾驶在环境感知、端到端规划、仿真闭环这些环节积累了大量的技术资产，而具身智能恰好也需要这些能力——机械臂要理解场景，得先看懂物体在三维空间里的位置；机器人要在家庭或工厂环境里移动，需要做和车辆类似的避障决策。这种能力需求上的高度重叠，让很多人自然产生了一个推断：既然两者都依赖视觉语言模型做感知理解，都依赖世界模型做状态预测，干脆做一个统一模型，岂不美哉。
资本和人才流向也在强化这个推断。自动驾驶融资进入冷静期之后，一批原本做感知、仿真的工程师转投具身智能赛道，他们带过去的不仅是代码库，还有一整套“用大模型解决感知规划问题”的思维范式。我认识好几个团队，做具身智能时直接套用了自动驾驶的BEV感知架构，再叠加一个语言指令接口，效果居然还不错——这反过来又给“通吃论”添了一把火。
但这里有个关键区分：共享技术栈和共享模型权重完全是两码事。你可以用同一套Transformer训练管线、同一套点云处理流程、甚至同一个基础设施平台去支撑两个项目，这没问题。但要让一个模型在给车规划变道的同时，还在脑海里计算机械臂抓取一个玻璃杯的接触力，这属于模型容量和任务耦合的问题，远不是“共享技术栈”能cover住的。
1.2 “基础模型”的三个层次：别把三件事混为一谈
讨论“通吃”之前，我建议先把“基础模型”这个词拆成三个层次，否则对话没法进行。第一层是架构基础模型，指代同一个骨干网络（backbone），比如用ViT做视觉编码器，无论是给自动驾驶看路况还是给机械臂看桌面，都用同一个编码器抽取特征。第二层是预训练基础模型，指在一批大规模混合数据上做预训练，然后下游任务微调同一个初始权重。第三层是部署态通用模型，指同一个权重文件直接跑多种任务，不做任何微调或只挂轻量适配器。
这三层难度是递进的。架构共享现在就能做，成本极低；预训练共享已经有些团队在尝试，需要仔细平衡驾驶数据和操作数据，但可行；部署态通用模型我认为在当前的算力和数据条件下，硬凑只会两头不讨好。很多时候大家争论“能不能通吃”，其实是在不同层次上自说自话——说的是一回事，想的是另一回事。先把层次厘清，再谈技术方案，争论就能减少大半。
1.3 仿真与数据侧的共同语言：从欧卡2到开源社区
还有一个被低估的共性层在数据侧。相关热词里的“欧卡2自动驾驶”很多人不了解，它其实是个特别有意思的现象——欧洲卡车模拟器欧卡2虽然是个游戏，但它的道路拓扑、交通流动态、天气切换都有较高的物理和规则保真度，不少自动驾驶团队拿它做数据扩充和模型鲁棒性测试。这件事给我最大的启发不是“游戏数据能用于驾驶”，而是“仿真环境和真实任务之间，存在一个可以迁移的中间表征层”。
具身智能社区也在做同样的事，比如xbotics这类开源社区，已经在生态层面沟通自动驾驶和机器人的数据标准。我实际体验下来的结论是：如果两边的数据都转成统一的token序列格式，那同一个预训练模型确实可以在“表征层面”共享权重。但注意，这里共享的是编码器往前的部分，解码器和任务头还是各做各的。所以数据侧虽然成了打通两边的桥梁，但桥面之下，任务侧的隔阂依然深厚。
2. 拆开看本质：驾驶任务与操作任务到底差在哪里
2.1 任务空间差异：从“不接触”到“必须接触”
要理解为什么部署态通吃这么难，得先看清楚自动驾驶和具身智能在任务空间上的本质差异。自动驾驶的核心是非接触式控制——车辆在地面移动，绝大多数动作是通过转向、油门、刹车来实现的，车辆与物体之间要么保持距离，要么以非接触的方式通过。即便遇到紧急情况，自动驾驶系统也几乎不会做“推开障碍物”这类动作，它的任务是预测和规避，而不是干预和操作。
具身智能恰恰相反，它的核心能力恰恰是接触式操作——机械臂要握住、提起、旋转、推开、按压物体，每一件事都依赖准确的力量控制、摩擦估算和接触状态切换。你让一个自动驾驶模型去规划变道，它只需要输出一条平滑的轨迹；你让同一个模型去规划“把杯子拿起来放在托盘里”，它得同时考虑末端执行器的抓取位姿、夹爪闭合力学模型、以及被抓物体被破坏的阈值——这已经完全超出了防碰撞轨迹规划的范畴。
这个差异会直接渗透到模型架构的底层。自动驾驶的主流方案输出的是轨迹点或速度指令，参数空间基本在几十维以内；机器人操作则要输出末端位姿序列、关节力矩、有时候还要输出接触力反馈，具有明显的多模态控制特征。让一个模型同时输出这两类完全不同量纲的指令，架构上不是不能做，而是需要加一大批任务特定的接口和正则项，加完之后你发现这个模型已经不是一个模型了，而是一个插着好几个不同脑袋的共享躯干。
2.2 数据格式与token流：物体级与实体级的落差
自动驾驶数据集里最常见的佛像是物体框、车道线、轨迹预测标签，一切都被简化成“物体级（object-level）”的抽象。物体框很好用，因为车、人、路障这些都在道路平面上运动，一个二维框加一个速度向量基本够用。具身智能数据集完全不是这个路数，“xbotics具身智能机械臂”这种场景里的数据，粗粒度的物体框根本不够，你需要像素级分割、深度图、法向量、抓取点标注，甚至物体内部材质的信息——这是“实体级（entity-level）”的颗粒度需求。
在落地模型的时候，颗粒度差异会变成一个很痛苦的工程问题。我们曾经尝试把一套自动驾驶的BEV感知模型直接用在桌面机器人的场景理解上，跑出来的识别精度其实不差，但下游仍然无法完成抓取——因为BEV特征天然对“高度”信息的表征是压缩过的，而机械臂规划最看重的恰恰是垂直方向上的几何信息。最后我们不得不给模型加了一个额外的点云编码分支，这等于给“共享”打了个补丁，效率远远低于直接在具身数据上训一个新的感知头。
更麻烦的是token流的结构差异。现在做多模态大模型，大家都喜欢用token统一一切。自动驾驶这边业界探索的Scene/Motion2Token方案，把场景和运动信息都token化，形成所谓的token flow，这个思路在驾驶域内是自洽的——场景小、结构清晰、实体有限。但到了具身智能，token要描述的东西数量级不同，而且要描述接触力学和物理状态转移，这些信息很难在离散token里不丢精度地编码。强行统一token的结果是：自动驾驶这边跑得欢，具身智能这边要么token数量爆炸，要么接触信息被严重量化损失。
2.3 交互对象与语义复杂度：从交通规则到人的意图
再往深一层看，两个领域对“智能”的定义也不太一样。自动驾驶面对的世界虽然复杂，但语义规则是高度结构化的——红绿灯的含义是全局约定好的，车道线的语义是标准化的，行人的意图虽然不确定，但运动模式有统计规律可循。这意味着自动驾驶模型可以大量依赖“地图语义+交通规则嵌入”来降低不确定性，很多方案里把静态车道图编码进embedding，就构成模型的一条主要先验路径。
具身智能面对的是高度非结构化的开放世界。同样是“把杯子拿给我”这个指令，在厨房、办公室、车间三个环境下，杯子的位置、周边的障碍物、可用的抓取策略完全不同；更要命的是，物理世界不存在“全局约定好的规则”，你对一个物体的力学理解稍有偏差，任务就直接失败。这种高语义不确定性不只在感知层，还深入到规划和执行层。
有人可能觉得，可以用语言模型来统一这种语义理解，让两者都变成“多模态指令跟随”。但我实际测试的经验是：语言大模型确实能统一指令侧的表达形式，却统一不了物理侧的dynamics。你的模型可以说得头头是道，但真正输出关节力矩控制机器臂去抓一个易碎物体时，语言知识帮不了什么忙——这件事必须靠真实物理交互数据的学习才能做到。
3. 世界模型能否一鱼两吃：关键技术拆解与算力真相
3.1 “世界模型”不只是预测：场景重建与行为预测的分野
世界模型是当前自动驾驶和具身智能都在押注的技术方向，也是“通吃论”最后的大本营。主张通吃的人会说：既然自动驾驶的世界模型能预测车辆周围未来几秒的场景演变，具身智能也能用同样的模型预测机械臂操作后物体的状态变化，这不就统一了吗？
这话说的理论逻辑没错，但落地的难度在于“世界”的定义不同。自动驾驶的世界模型本质上是场景重建+行为预测的组合，它要重建的是道路拓扑和交通参与者的运动状态，要预测的是红绿灯切换、前车刹车、行人横穿这一类宏观行为；很多方案用5D flow（三维空间加时间加流场）来表示这个动态世界，这个表示对驾驶任务来说是恰到好处的。然而在机械臂操作系统里，需要预测的是橡胶球的形变、纸杯的滑移、软体物体在夹爪压力下的状态变化，这属于物理接触动力学的范畴，复杂度比驾驶场景的行为预测高了好几个数量级。
我见过有人试图在这两个方向共用一个预训练的世界模型，做法是先在驾驶数据上做自监督，再在操作数据上微调。结果很有意思：微调之后，驾驶域性能掉10%，操作域性能也达不到直训的水平。后来排查发现，问题出在预测loss的设计上——驾驶场景的loss偏重轨迹预测和occupancy预测，优化方向与操作领域的接触状态预测存在根本冲突。强行共享权重，等同于拿一个学了中国象棋的模型去学国际象棋，虽然棋盘画得很像，棋子的走法完全不同。
3.2 自回归生成loss与动作token设计：共享架构的真实上限
从实现层面看，世界模型要让两个领域共用，最关键的技术点是动作token的设计。自动驾驶的动作token相对简单——受到“minimal speed commands”（最小速度指令）思路的影响，不少团队把动作输出降维成极低的指令空间，只输出几个离散的加速度和转向档位，剩下的交给底层控制器去平滑。这也是为什么在很多自动驾驶数据集评测里，模型看起来简单利落、指标漂亮。
但具身智能的动作token要复杂得多。一个机械臂的动作通常包含末端位置、姿态、开合状态、速度和力控信号，如果考虑灵巧手，自由度更加爆炸。硬要用一套离散动作token同时覆盖“方向盘转角”和“关节力矩”，结果就是自动驾驶这边动作空间浪费、具身智能这边动作空间不足。有人说可以把动作空间统一到一个高维连续空间，理论上成立，但训练难度会呈指数级上升。
我统计过一个小规模的对比实验：分别用同一个8卡训练管线训练两个模型，一个专用自动驾驶，一个专用机械臂抓取，再训练一个混合模型同时学两个任务。混合模型的收敛速度比专用模型慢了约60%，而在线性能只有专用模型的75%左右——但它的参数量只节省了不到18%。这个效率差距足以劝退大多数工程团队，因为省下来的那点内存和显存，根本抵不过训一个弱智模型带来的损失。
3.3 mAP52.7的陷阱：离线指标无法覆盖闭环评测
聊到技术挑战，就不能不提评测机制。很多团队被“通吃”说服，是因为在离线公共数据集上看到了漂亮数字——比如某个混合模型在驾驶感知任务上达到了mAP52.7，在机器人物体识别上也表现不俗，于是得出“通吃可行”的结论。我劝大家看到这种数字时先冷静一下：mAP这类基于感知框的离线指标，衡量的是“模型能不能认出场景中的物体”，但它衡量不了“模型能不能在闭环环境中完成一连串决策动作”。
做完技术拆解，我倾向于一个更冷静的判断：端到端共享模型在可见未来只能存在于“认知侧”（感知、理解、常识推理），而“物理侧”（运动控制、接触操作、动力学预测）必须依赖专用模型，除非长期坚持这个常识型路径规划，否则终究会被落地场景的现实打回来。这话不好听，但跑过产线、跑过路测的人应该懂我在说什么。
4. 现实路径：一套基础模型加多套任务的工程化落地
4.1 共享预训练：到底共享什么，不共享什么
既然部署态通吃不现实，那退一步的共享预训练值不值得做？我的答案是：值得，但要像做菜一样分清主料和辅料。可以共享的是感知编码器——视觉、语言、点云这些跨任务通用的特征提取模块；不建议共享的是规划解码器和控制输出头——这两者恰恰是任务差异最集中的地方，把它们锁死在同一个模型里，等于逼一个厨师同时做川菜和粤菜，还只给一把勺子。
实操层面，我建议采用“一个底座，两个分支，三层释放”的结构。底座是共享的多模态编码器，在大量混合数据上预训练；两个分支一个是自动驾驶输出头（输出轨迹、速度指令），一个是操作输出头（输出位姿、力控信号）；三层释放指在部署时，底座和分支按需冻结或微调——固定场景用冻结推理，数据漂移大时只解冻部分参数做轻量微调。这种设计的好处是：模型文件只有一个，但内部模块按需优化，既保住了共享的参数量优势，又留住了任务特化的精确度。
4.2 接口标准化：把多模态处理做成“shared user interface”
这个架构里最考验设计功力的是任务分支和共享底座之间的接口。打个不恰当的比方，一个好的接口应当像一个“shared user interface”——用户（下游任务）不关心底座内部的实现细节，只需要通过一套标准化的API拿到想要的特征即可。驾驶任务可能需要的是“场景级特征+物体级状态”，操作任务可能需要的是“实体级特征+空间几何信息”，这两者都可以通过同一套接口语言描述，但内部特征抽取深度可以不同。
我在工程实现中比较青睐的做法是引入Scene/Motion2Token类似的token flow作为接口标准。感知底座输出一个统一的、带空间和时间语义的token序列，下游任务各自按需从序列里采样、聚合、解码。这个方案的好处是接口们与具体任务解耦，底层架构升级不会引发下游地震；坏处是token流的定义和压缩比需要反复调，搞不好就会成为性能瓶颈。我亲眼见过一个团队在token流表示上磨了半年，最终靠着一个更精细的时空特征对齐方案才跑通。
4.3 仿真数据迁移的真实作用：先别急着上真机真车
数据层面，欧卡2这类游戏仿真器给了我们一个非常重要的启发：仿真与真实之间的鸿沟，可以用共享表示来缩小，但完全消除是不现实的。对具身智能团队来说，类似xbotics开源社区提供的仿真环境，价值不只是帮你白嫖数据，而是让你在真实设备烧钱之前，先低成本验证“策略的泛化边界”。同样的道理反过来也适用：自动驾驶团队如果先在一个高保真仿真器里验证新版模型在数据分布外的表现，往往能省下几个月路测返工的成本。
但这里有个必须警惕的坑：仿真迁移不能把“仿真里work”当成“真实中一定work”。我做自动驾驶评测时踩过的坑是，模型在仿真环境下表现极佳，一到真实道路就被各种低概率事件击穿。这类问题的根源在于仿真器里的传感器噪声模型和真实硬件存在系统性偏差，解决方式只能是分级验证——先在仿真里做大数据量筛选，再在真实环境里做小数据量精修。别指望有一套通吃的仿真到真实验证管线，那比通用模型还遥远。
4.4 从共享到协同：两个团队跑一套代码库的协作实战
现实中，如果一个团队既要交付自动驾驶项目又要交付机械臂项目，最现实的方案不是合并模型，而是合并基建。我跟一个朋友的公司交流过他们的实操：两条业务线共用一套数据管理平台、一套分布式训练框架、一套评测底座，但模型权重和实验计划完全分开管理。这样做的好处是训练基础设施的投入double省，散伙风险也低——任何一个任务出问题，不会拖垮另一条线。
实际操作中，我强烈建议两件事。第一，共享代码库里所有涉及任务特定逻辑的部分必须用插件化接口隔离，绝不允许自动驾驶的代码直接调用机械臂的控制器接口，否则第三周开始就会出现互相踩脚的情况。第二，两条线共用一套CI/CD训练流水线，但模型发布权限必须分开，否则一个任务升级导致另一个任务回归，那种锅谁都不愿背。
5. 实操中的血泪经验：训练、评测与团队协作
5.1 训练节奏设计：混合数据调度远比模型架构重要
很多团队拿到一个混合模型方案，第一反应是去调模型架构，但我实际经验是，混合数据调度对最终效果的影响，通常比架构改动来得更明显。驾驶数据和操作数据的样本量级、难易程度、信息密度完全不一样，放在同一个采样器里均匀采样，几乎没有好结果。我们最后摸索出来的一套方法是“动态比例采样”：训练初期让驾驶数据占大头（因为场景状态空间更规整，学得快），中期逐渐增大操作数据比例（引入物理接触带来的复杂特征），后期两者交替峰值，逼迫模型不断切换特征空间，反而能增强共享层的鲁棒性。
配套的做法是分阶段冻结与解冻。初期整体训练，中期冻结解码器单独训两层任务头，后期解冻共享编码器的浅层做精调。这个节奏用的是“先学通用，再学专精，最后微调底层”的思路，踩坑之后发现它也能帮助感知底座学习到兼顾两个域的通用表示，而不是被某个任务“带偏”。
5.2 评测体系陷阱排查：别把A/B测试做成焦虑测试
混合模型的评测比单任务模型难得多，最容易出现的情况是“各项离线指标都涨，闭环一测就崩”。我在实操过程中确定的排查流程如下：先做一个基线模型的两次独立评测，确认指标波动范围；再测混合模型在单任务上的指标，看是否显著低于基线；最后做跨任务对抗性评测——拿自动驾驶的难例去测机械臂分支，拿抓取的奇葩场景去测驾驶分支。这个对抗性评测启动很慢，但真的能暴露不少共享特征层互相干扰的问题。
还建议加一个“紧急回滚”机制。混合模型训练过程中经常出现的情况是中段表现优异，后段突然开始蹦极，这通常源于某个任务的数据被另一个任务的数据“淹没”。我们每次跑混合训练都强制存下中间checkpoint，并且每周挑一个checkpoint做一次全量闭环评测——这个机制看着笨，实际拯救过我们至少两次发布周期。
5.3 团队协作模式：不要让一个模型背两个KPI
最后讲一个最容易忽略的坑：组织架构问题。搞混合模型生命周期评估，建议始终先回答几个基础问题——你的交付物到底是什么？是必须现网两个场景都成功的统一交付，还是允许两条线各自精调后续发布？我发现，当两个业务线同时考核一个混合模型的时候，很容易出现“都没人愿意让步”的僵局：自动驾驶团队不敢改共享层，担心影响路测表现；机械臂团队不敢动解码器，怕抓取又翻车。最后整个模型进入“谁也动不了”的冻结状态。
实操中比较好的做法是设立一个独立的“底座团队”，专门负责共享层和对齐层的质量，它的KPI不是单任务性能，而是“底座在两边做回归时都不产生显著掉点”。这个团队负责维护共享层接口和预训练节奏，两个业务团队则在这个底座之上独立迭代任务头。这个角色划分听上去简单，但很多团队做不到，最后都死在了“谁都有权改共享层”的混乱协作里。
写到这儿，把我看下来的一点个人体会放最后。想清楚这个问题，其实不在于纠结“一套模型彻底通吃”这个宏大命题，而在于想明白你到底要节省什么成本。如果目标是省训练算力，那共享底座加特化分支是比较明确的路线；如果目标是省人员开支和运维成本，那反而要慎重，因为混合模型的调试复杂度通常会把省下来的那点人力和算力再吃回去。
我个人的建议是：先别急着追求“同一个权重干两件事”，而是先让两个团队用同一套代码栈、同一个数据管线、同一套评测框架跑起来——这种基建层面的“通吃”，性价比远高于模型层面的“通吃”。等底座和接口稳定下来，如果你还真的需要跨领域的统一部署，再逐步把共享层扩大，这条路走起来会顺得多。当前阶段，拿“通吃”当方向感是可以的，拿它当交付标准则大可不必。真干过两个领域的人都知道，通用是理想，适配才是日常。
