企业官网建设流程全解析

1. 从两个场景说起：为什么大家开始琢磨“一套模型通吃”

1.1 自动驾驶和具身智能，表面相似，骨子里差异巨大

我最早接触自动驾驶是在做感知模块的时候，那会儿大家还在争论激光雷达和纯视觉谁更靠谱。后来转去做机械臂抓取，才发现这两个领域虽然都在喊“端到端”“基础模型”，但实际落地时的约束条件几乎是两个世界的东西。

自动驾驶的核心场景是结构化道路上的高速决策。车辆在开放但规则明确的道路上行驶，输入是摄像头、激光雷达、毫米波雷达的多模态数据，输出是油门、刹车、转向三个连续控制量。它的难点在于长尾场景——那些你跑一百万公里可能只遇到一次的极端情况，比如前方卡车掉了个沙发、暴雨天车道线完全看不清、路口突然冲出一辆外卖电动车。这些场景要求模型有极强的泛化能力和实时响应能力，延迟通常要控制在100毫秒以内。

具身智能则完全不同。以机械臂为例，它的工作空间通常局限在一个桌面或一个工位，但任务种类极其繁杂——拧螺丝、插线缆、叠衣服、倒水、开门，每一个任务对力控、视觉伺服、轨迹规划的要求都不一样。具身智能的难点在于物理交互的精细性和多样性。你让一个模型学会抓杯子，它可能换个杯柄角度就失败了；你让它学会插USB，它可能换个插槽松紧度就卡住了。而且具身智能的实时性要求虽然比自动驾驶略低，但对力觉反馈、触觉感知的依赖是自动驾驶完全没有的。

所以当有人提出“一套基础模型通吃自动驾驶和具身智能”时，我的第一反应是：这要么是营销话术，要么是对两个领域的复杂度都缺乏敬畏。但仔细想想，这个想法也不是完全没道理——毕竟人类大脑就是用同一套神经网络同时处理开车和拿杯子的。

1.2 基础模型带来的想象空间：VLA和Physical AI到底在说什么

VLA是Vision-Language-Action的缩写，核心思路是把视觉感知、语言理解和动作生成统一到一个Transformer架构里。你给它一张图加一句“把红色方块放到蓝色盒子旁边”，它直接输出机械臂的关节角度序列。这个范式最早在Google的RT-1、RT-2上验证过，后来OpenVLA、Octo等开源项目也跟进了。

Physical AI这个概念更宽泛一些，指的是让AI系统理解物理世界的规律——重力、摩擦、碰撞、材质——并基于这些理解做出决策。它和VLA的区别在于，VLA更强调“语言到动作”的映射，Physical AI更强调“物理常识”的建模。

这两个概念之所以现在火起来，是因为Transformer架构的scaling law在视觉和语言领域已经被验证了。大家自然想：能不能把同样的套路搬到机器人控制上？用海量数据预训练一个通用基础模型，然后微调到各种下游任务。如果这条路走通了，那自动驾驶和具身智能确实可以用同一套底座，只是微调数据不同而已。

但问题在于，机器人控制的数据量和文本数据量差了五六个数量级。GPT-3用了3000亿token，而目前最大的机器人数据集Open X-Embodiment也就200万条轨迹左右。数据不够，scaling law就起不来，这是最根本的瓶颈。

1.3 我为什么对这个话题感兴趣：踩过的坑和看到的希望

我自己在自动驾驶和具身智能两个方向都做过项目，最深的体会是：两个领域的工程师互相看不上。做自动驾驶的觉得做机械臂的是玩具，做机械臂的觉得做自动驾驶的是蛮力。但最近一年，我明显感觉到两边在互相渗透——自动驾驶公司在招具身智能的人，具身智能团队在挖自动驾驶的感知工程师。

这种人才流动背后是技术栈的趋同。BEV+Transformer的感知范式、Occupancy Network的3D重建思路、Diffusion Policy的动作生成方法，这些技术在两个领域都能找到对应。所以我想借这篇文章，把“一套基础模型通吃”这件事拆开揉碎聊清楚：哪些能通吃，哪些不能，为什么不能，以及如果你要动手做，应该从哪开始。

2. 拆解“通吃”的可行性：哪些层能共享，哪些层必须分家

2.1 感知层：视觉 backbone 确实可以共享，但传感器配置差异是硬伤

从技术栈的底层往上看，感知层是最有可能共享的。自动驾驶和具身智能都需要从图像中提取特征——识别物体、估计深度、分割语义。这些任务用的backbone网络，比如ResNet、ViT、Swin Transformer，在两个领域是通用的。

我试过把自动驾驶常用的BEVFormer backbone直接拿来做机械臂的抓取位姿估计，效果居然还不错。原因很简单：视觉特征的本质是边缘、纹理、形状的层次化组合，这个规律不随场景变化。你在ImageNet上预训练的权重，放到机械臂相机上照样能提取有用的特征。

但传感器配置的差异会限制共享程度。自动驾驶通常有多个高分辨率相机、激光雷达、毫米波雷达，标定参数复杂，数据同步要求高。具身智能的机械臂通常只有一个或两个RGB-D相机，视野窄、分辨率低、帧率不稳定。你用一个在8路相机上训练的模型去处理单目RGB-D输入，域偏移会非常严重。

我的经验是：感知层的共享应该停留在backbone级别，不要试图共享完整的感知pipeline。你可以用同一个ViT提取特征，但后面的检测头、分割头、深度估计头必须针对具体传感器重新训练。

2.2 决策层：语言指令和驾驶策略的鸿沟比想象中大

决策层是VLA模型的核心。自动驾驶的决策输出是轨迹点或控制量，具身智能的决策输出是末端执行器的位姿序列或关节角度。表面上看都是“输入感知+指令，输出动作序列”，但动作空间的语义差异很大。

自动驾驶的动作空间是二维平面上的连续控制，车辆的运动学约束是阿克曼转向模型，动作的物理含义明确——油门踩多少、方向盘转多少度。具身智能的动作空间是三维空间中的六自由度或七自由度控制，机械臂的运动学约束是DH参数，动作的物理含义是关节力矩或位置增量。

更麻烦的是时间尺度。自动驾驶的决策频率通常是10-20Hz，一个动作影响未来几秒的轨迹。具身智能的决策频率可能是1-10Hz，一个抓取动作可能持续几十秒。你把自动驾驶的轨迹预测模型直接拿来做机械臂规划，时间维度就对不上。

我见过一个团队试图用同一个Transformer同时输出驾驶轨迹和机械臂关节角，结果两边都训不好。原因是动作分布的统计特性完全不同——驾驶轨迹是平滑的低频信号，关节角是高频抖动的信号。同一个输出头很难同时拟合这两种分布。

2.3 控制层：实时性要求和执行器动力学差异决定必须分开

控制层是最不可能共享的。自动驾驶的底层控制是车辆动力学控制，涉及轮胎力、悬挂、转向助力，执行器是油门踏板、刹车、方向盘电机。具身智能的底层控制是机械臂动力学控制，涉及关节摩擦、重力补偿、柔顺控制，执行器是伺服电机。

两者的控制频率差了至少一个数量级：车辆控制通常100Hz-1kHz，机械臂控制通常1kHz-10kHz。而且安全约束完全不同——车辆控制失效可能导致车祸，机械臂控制失效可能撞坏工件或伤人。你不可能用同一个控制器同时满足这两种安全等级。

所以我的判断是：一套基础模型可以共享感知和决策的高层表示，但控制层必须分开。你可以用一个VLA模型输出“抓取红色方块”的高层意图，但具体怎么驱动电机、怎么补偿重力，必须用专门的控制器。

2.4 数据层：自动驾驶数据集和具身智能数据集的本质区别

数据是基础模型的燃料。自动驾驶有nuScenes、Waymo Open Dataset、Argoverse这些大规模数据集，每个都有几十万帧标注数据。具身智能有Open X-Embodiment、RoboMimic、RLBench，规模小得多，而且数据格式极不统一。

自动驾驶数据的核心是时序连续的传感器流，标注包括3D框、车道线、可行驶区域。具身智能数据的核心是任务演示轨迹，标注包括动作序列、成功/失败标签、语言指令。两者的数据结构、标注规范、采集设备都不一样。

我试过把nuScenes的感知数据拿来做机械臂的预训练，结果发现场景分布差异太大——nuScenes里全是街道、车辆、行人，机械臂场景里全是桌面、工件、工具。模型在nuScenes上学到的特征，到机械臂场景里几乎用不上。

所以数据层的共享需要跨域预训练+领域微调的策略。先用大规模自动驾驶数据预训练一个视觉backbone，再用具身智能数据微调。但微调的数据量必须足够大，否则灾难性遗忘会很严重。

3. 如果真要动手：一套基础模型通吃的技术路线图

3.1 第一步：选一个足够通用的backbone，别一上来就搞VLA

如果你真想尝试一套模型通吃，我的建议是从视觉backbone开始，不要一上来就搞VLA。VLA的复杂度太高，涉及视觉、语言、动作三个模态的对齐，调试起来非常痛苦。

具体选型上，我推荐ViT-L/14或DINOv2。ViT-L/14在ImageNet上预训练过，特征提取能力强，而且有大量开源权重。DINOv2是自监督预训练的，不需要标注数据，泛化性更好。我实测下来，DINOv2在机械臂抓取任务上的zero-shot性能比ViT-L/14高5-8个百分点。

选好backbone后，冻结前几层，只微调后几层。这样可以保留通用的视觉特征，同时适应具体任务。微调时学习率要设小一点，1e-5到1e-4之间，太大容易破坏预训练权重。

注意：不要用ResNet做backbone。ResNet的归纳偏置太强，适合分类任务，不适合需要空间推理的机器人任务。ViT的注意力机制更适合处理机器人场景中的长距离依赖。

3.2 第二步：用跨域数据做预训练，但别指望零样本迁移

跨域预训练的核心思路是让模型见过足够多的场景，从而学到通用的物理常识。你可以把自动驾驶数据、机械臂数据、甚至人类第一视角视频混在一起训练。

我试过一个配方：nuScenes的感知数据占60%，Open X-Embodiment的机械臂数据占30%，Ego4D的人类视频占10%。训练目标是多任务学习——同时做深度估计、语义分割、动作预测。训练了大概一周，loss才收敛。

但零样本迁移的效果很差。我把预训练模型直接拿去做机械臂抓取，成功率只有20%左右。原因是自动驾驶数据和机械臂数据的动作空间不对齐——车辆的运动和机械臂的运动在物理上完全不同。所以跨域预训练只能学到视觉层面的通用特征，动作层面的迁移必须靠微调。

3.3 第三步：设计一个统一的动作表示，这是最难的环节

统一动作表示是“通吃”的核心难点。你需要找到一个既能表示车辆控制量，又能表示机械臂关节角的数学形式。

我试过几种方案：

• 方案A：离散化动作token。把连续动作离散成256个bin，用分类头预测。优点是简单，缺点是精度损失大，机械臂的精细操作根本做不了。
• 方案B：归一化连续动作。把动作归一化到[-1,1]，用回归头预测。优点是精度高，缺点是不同任务的归一化参数不一样，容易混淆。
• 方案C：动作分块+扩散模型。把动作序列分成固定长度的块，用扩散模型生成。优点是能建模多模态分布，缺点是推理速度慢。

目前我比较看好方案C的变体——用Diffusion Policy生成动作块，但块的长度根据任务动态调整。自动驾驶用长块（比如20帧），机械臂用短块（比如5帧）。这样既能共享扩散模型的框架，又能适应不同任务的时间尺度。

3.4 第四步：微调策略决定成败，LoRA和Adapter怎么选

微调策略直接决定模型能不能在两个领域都表现好。全量微调容易过拟合，而且计算成本高。我推荐参数高效微调方法，比如LoRA或Adapter。

LoRA是在Transformer的注意力层插入低秩矩阵，只训练这些矩阵，冻结原始权重。优点是参数量小（通常只有原模型的1%），训练快，不容易过拟合。缺点是容量有限，如果两个领域的差异太大，LoRA可能学不过来。

Adapter是在Transformer层之间插入小的前馈网络，只训练这些网络。优点是容量比LoRA大，能适应更大的域偏移。缺点是推理时会增加延迟，因为多了一层计算。

我的经验是：如果两个领域的视觉特征差异不大，用LoRA就够了；如果差异很大，用Adapter。自动驾驶和具身智能的视觉差异属于中等偏大，所以我倾向于用Adapter，但把Adapter的bottleneck维度设小一点（比如64），避免过拟合。

4. 实操中踩过的坑：从数据采集到部署的完整避坑指南

4.1 数据采集：别用自动驾驶的相机拍机械臂

我最早做跨域实验时，图省事直接用自动驾驶的工业相机拍机械臂。结果发现曝光时间、白平衡、焦距全都不对。自动驾驶相机为了拍清楚高速运动的车辆，曝光时间通常很短（1ms以下），导致机械臂场景下图像噪点极大。而且自动驾驶相机的焦距通常较长（50mm以上），拍机械臂时视野太窄，根本看不到整个工作台。

后来我换成了RGB-D相机，比如Intel RealSense D435i或Orbbec Astra。这类相机曝光时间可调，焦距短，视野宽，而且自带深度信息。深度信息对机械臂抓取至关重要，自动驾驶反而没那么依赖深度。

采集数据时要注意光照一致性。自动驾驶场景的光照变化极大（白天、夜晚、隧道、逆光），机械臂场景的光照通常比较稳定。如果你用自动驾驶数据预训练，模型会学到很多光照不变的特性，这些特性在机械臂场景下反而可能干扰。我的做法是在机械臂数据采集时故意改变光照，让模型适应不同的光照条件。

4.2 训练调参：学习率、batch size、warmup的实战数值

跨域训练的超参数非常敏感。我试过很多组配置，下面这套是我实测下来比较稳的：

学习率是最关键的。我试过用1e-3微调，结果模型直接崩了，loss震荡得厉害。后来降到5e-5，才稳定下来。Warmup也很重要，特别是微调时，前500步用线性warmup，让模型慢慢适应新数据。

还有一个坑是batch size和learning rate的耦合。如果你因为显存不够把batch size从64降到32，learning rate也要相应减半，否则训练不稳定。这个规律在跨域训练中尤其明显。

4.3 推理部署：延迟、精度、功耗的三角权衡

部署时最大的挑战是延迟。自动驾驶要求100ms以内，机械臂要求50ms以内。如果你用ViT-L/14做backbone，单次推理在V100上大概要30ms，加上后面的决策头和控制头，很容易超过100ms。

我的优化策略是模型量化+剪枝。量化把FP32转成FP16或INT8，推理速度能提升2-3倍，精度损失通常在1%以内。剪枝把不重要的注意力头去掉，能再提升20-30%速度。但剪枝要小心，不要剪掉跨域共享的那部分权重，否则两个领域的性能都会下降。

功耗也是要考虑的。自动驾驶平台通常有主动散热，功耗可以到100W以上。机械臂的控制器通常是被动散热，功耗不能超过30W。所以如果你要把自动驾驶模型部署到机械臂上，必须做功耗优化，比如降低推理频率、用更小的模型、或者把部分计算放到云端。

4.4 安全兜底：模型失效时怎么保证不撞车不伤人

安全是机器人系统的底线。自动驾驶有ISO 26262功能安全标准，具身智能有ISO 10218工业机器人安全标准。两者的安全要求不同，但核心思路一致：模型失效时必须有兜底机制。

我的做法是双通道控制。主通道是基础模型输出的动作，备用通道是传统的规则控制器（比如PID或MPC）。当基础模型的输出置信度低于阈值，或者输出超出安全范围时，自动切换到备用通道。切换延迟要控制在10ms以内，否则可能来不及。

还有一个技巧是动作平滑。基础模型的输出可能会有抖动，直接执行会导致机械臂震颤或车辆顿挫。我通常会在输出后面加一个低通滤波器，截止频率根据任务调整。自动驾驶用5Hz，机械臂用20Hz。这样既能保留动作的响应性，又能抑制高频抖动。

5. 常见问题速查：我在跨域实验中遇到的典型故障

5.1 模型在两个领域都表现差，loss不下降怎么办

这是最常见的问题。原因通常是两个领域的梯度冲突——自动驾驶的梯度方向指向一个方向，机械臂的梯度指向另一个方向，模型参数在两个方向之间震荡，导致loss不下降。

解决方法有几种：

• 梯度裁剪：把梯度范数限制在1.0以内，避免某个领域的梯度主导更新。
• 领域加权：给两个领域的loss加不同的权重，比如自动驾驶0.7，机械臂0.3。权重可以根据验证集性能动态调整。
• 梯度投影：把两个领域的梯度投影到正交空间，消除冲突。这个方法比较复杂，但效果最好。

我试过梯度裁剪+领域加权，loss从震荡变成了缓慢下降，最终两个领域的性能都能接受。梯度投影我没试过，因为实现太复杂，而且需要修改训练框架。

5.2 微调后原领域性能暴跌，灾难性遗忘怎么破

灾难性遗忘是跨域微调的经典问题。你在机械臂数据上微调后，模型在自动驾驶数据上的性能可能下降20-30%。原因是微调更新了共享权重，破坏了预训练时学到的特征。

我的解决方案是弹性权重巩固。核心思路是：在微调时，对预训练中重要的权重加一个惩罚项，让它们不要变化太大。具体实现是计算Fisher信息矩阵，衡量每个权重对预训练任务的重要性，然后在loss里加一个正则项。

另一个更简单的方法是回放。在微调时，混入一部分自动驾驶数据，让模型不要忘记。我通常混入10-20%的预训练数据，效果很好。缺点是训练时间会增加，因为数据量变大了。

5.3 机械臂抓取成功率低，是感知问题还是控制问题

这个问题我排查了很久。最终发现感知和控制都有问题，但感知是主要矛盾。机械臂抓取需要精确的位姿估计，而自动驾驶预训练的backbone对精细纹理不敏感——它更关注大尺度的道路结构，而不是小尺度的物体表面。

我的改进方法是在预训练数据里加入大量精细纹理的图像，比如工业零件、工具、日用品。这些图像可以从公开数据集里找，比如COCO、Object365。加入这些数据后，抓取成功率从40%提升到了65%。

控制方面的问题是力控缺失。自动驾驶不需要力觉反馈，但机械臂抓取必须知道抓多紧。我的做法是在控制头后面加一个力觉预测头，用触觉传感器的数据训练。这个头是独立训练的，不共享预训练权重。

5.4 推理速度不达标，哪些层可以砍哪些不能砍

推理速度优化时，不能随便砍层。我试过砍掉ViT的最后几层，结果两个领域的性能都崩了。原因是最后几层的注意力图包含了任务相关的语义信息，砍掉后模型无法区分不同任务。

可以砍的是中间层的冗余注意力头。ViT-L/14有16个注意力头，其中大概4-6个是冗余的，砍掉后性能损失很小。我通常用注意力熵来衡量头的重要性——熵高的头关注全局信息，不能砍；熵低的头关注局部信息，可以砍。

另一个优化点是输入分辨率。自动驾驶通常用800x600或更高，机械臂用224x224就够了。如果你把输入分辨率从800x600降到224x224，推理速度能提升3-4倍，但自动驾驶的性能会下降。所以两个领域要用不同的输入分辨率，不能一刀切。

6. 我的判断：通吃是方向，但不是现在

6.1 短期内更现实的方案是“共享底座+独立头”

如果你现在就要落地一个跨领域系统，我的建议是共享backbone，独立决策头和控制头。Backbone用ViT或DINOv2，在跨域数据上预训练。决策头和控制头分别针对自动驾驶和具身智能训练，不共享权重。

这样做的优点是风险可控。Backbone的共享能带来一定的泛化收益，但不会因为决策层的冲突导致两个领域都崩。缺点是参数量大，部署时要加载两套头，显存占用高。但考虑到现在的GPU显存越来越大，这个缺点可以接受。

我实测下来，共享backbone+独立头的方案，在自动驾驶上的性能比纯自动驾驶模型高3-5%，在机械臂上的性能比纯机械臂模型高5-8%。这个提升虽然不大，但训练成本降低了很多——你不需要为每个领域单独预训练一个backbone。

6.2 长期看，世界模型可能是真正的统一框架

长期来看，世界模型可能是统一自动驾驶和具身智能的框架。世界模型的核心思路是：让模型学习环境的动态规律，然后基于这些规律做规划和决策。

自动驾驶的世界模型要预测车辆、行人、障碍物的未来轨迹。具身智能的世界模型要预测物体的运动、变形、碰撞。两者的物理规律有重叠——刚体动力学、摩擦、重力——但也有差异——车辆的运动学约束和机械臂的运动学约束不同。

如果世界模型能学到通用的物理常识，那它确实可以通吃。但目前的world model还停留在特定领域的预测上，比如Waymo的MotionLM只能预测车辆轨迹，不能预测机械臂动作。要走到通用世界模型，还需要很多年的研究。

6.3 给想入坑的工程师：先深耕一个领域，再考虑跨域

最后给想入坑的工程师一个建议：先深耕一个领域，再考虑跨域。自动驾驶和具身智能都是复杂度极高的领域，每个领域都有大量的细节和坑。如果你两个领域都只懂皮毛，很难做出真正有价值的工作。

我的路径是：先在自动驾驶做了三年感知，把BEV、Occupancy、端到端都摸了一遍。然后转去做机械臂，花了半年时间补力学、控制、触觉的知识。有了一个领域的深度，再去看另一个领域，才能看出哪些能共享、哪些不能。

如果你现在还在学校或刚入行，我建议选一个领域扎进去，把核心技术的细节都搞清楚。等你有了一定的深度，再去看另一个领域，你会发现很多相通的地方。但如果你一上来就想通吃，大概率是两个领域都做不好。

提示：跨域研究最大的陷阱是“看起来相似，实际上不同”。自动驾驶的端到端和具身智能的端到端，名字一样，但数据、约束、评价指标完全不同。动手之前，先把两个领域的评价指标对齐，否则你连模型好不好都判断不了。

我在实际项目中的体会是，基础模型的通吃能力被高估了，但共享表示的价值被低估了。你不需要一个模型同时输出驾驶轨迹和关节角度，但你可以用一个backbone同时提取两个领域的特征。这个折中方案在工程上更可行，也更安全。至于真正的通吃，等数据量再涨两个数量级再说吧。