最近一段时间关于“新造车”的讨论已经不再局限于续航、补能、智能驾驶这些常规话题。行业里开始频繁出现一个颇具科幻感的表达车企要“造人”。乍一听像是在讨论某种虚构概念实际上这里的“造人”指的是人形机器人更准确的技术表述是“具身智能”——让 AI 拥有物理身体能够感知、决策、执行并与真实世界交互。多家新造车企业以及传统主机厂正在把研发资源、资本和供应链能力向这条赛道倾斜。本文不打算做行业八卦式盘点而是希望以技术教程和工程复盘的方式帮读者看清“车企造人”背后的能力迁移逻辑、技术栈构成、真正的难点以及可行的落地路径。无论你是从事自动驾驶开发的工程师还是对具身智能感兴趣的初学者这篇文章都可以作为一张系统的认知地图。1. 背景与核心概念车企“造人”到底是什么1.1 “造人”不是造人而是布局具身智能如果把“车企造人”理解成去制造一个生物意义上的人类那就完全跑偏了。车企要造的是具备感知、认知、运动和操作能力的人形机器人。这种机器人的核心不只是“长得像人”而是拥有通用的物理交互能力能理解你说了什么能看到周围环境能规划出先做什么后做什么还能用机械臂和灵巧手把动作真正执行出来。用一个更严谨的概念来概括就是“具身智能”。传统 AI 更像是活在服务器里的“大脑”只负责处理文本、图片、语音等数字信息而具身智能要求 AI 必须有一个“身体”让模型与物理世界直接接触在真实环境中通过试错、反馈、重复操作来学习和执行任务。汽车本身从广义上也是一种具身智能体但它是高度受限的主要运行在结构化的道路上形态固定交互对象也有限。而人形机器人面对的则是完全开放的场景楼梯、门把手、桌面、工具、人体甚至各类非标物体。所以“车企造人”的本质是汽车企业从“四个轮子的机器人”向“两条腿、两只手的通用机器人”方向进化。这个进化不是换个外形而是整体技术栈和人机交互能力的重大升级。1.2 为什么新造车企业会加码“造人”新造车企业押注“造人”有三个非常现实的原因。第一技术栈高度可复用。智能汽车本身就是一台装备了大量传感器、计算平台和控制系统的机器人。感知用摄像头、激光雷达、毫米波雷达决策用行为预测、路径规划、运动控制云端还有数据闭环和仿真体系。人形机器人同样需要这些能力。比如自动驾驶中的视觉感知网络经过少量改造就能迁移到机器人上用于物体识别和避障再比如车端的高性能计算平台和中间件架构也可以承接机器人的实时推理任务。第二需要寻找“第二增长曲线”。国内新能源汽车市场的竞争已经进入白热化阶段单车利润被严重压缩。车企需要找到一个新的硬件品类去承接已经积累的供应链、研发团队和品牌势能。人形机器人虽然短期无法贡献利润但在资本市场和技术趋势上的想象空间足够大。对于新势力品牌来说提前卡位也能增强自身的科技属性。第三制造本身就有巨大需求。车企在工厂里要搬运物料、检测质量、执行精密装配。传统工业机器人往往固定在产线上无法灵活移动而人形机器人天然适合“进入现有工业场景做通用操作”。所以很多车企布局“造人”的第一站就是自己的工厂。先让机器人在车间里打工既真实解决了成本问题又积累了数据和场景经验。1.3 从“造车”到“造人”不是能力叠加而是能力跃迁虽然自动驾驶和机器人技术高度相关但从“造车”到“造人”并不是简单地把四个轮子换成两条腿。汽车的行驶环境相对可控道路有车道线、红绿灯和交通规则而人形机器人要面对的是极度开放、非结构化、不可完全预测的物理世界。举个例子自动驾驶可以做到“在高速公路上安全行驶几十公里”但很难要求它“走进一间堆满杂物的厨房拉开冰箱取出一罐饮料再关门”。这两类任务对泛化性、精细操作、多模态理解的要求完全不同。因此车企造人之路必然是长期投入、持续迭代的过程发布会上的原型机只是万里长征第一步。所谓“道阻且长”恰恰体现在工程化、量产、安全、场景验证等真正难啃的环节。2. 入场条件车企做机器人需要具备哪些基础如果把“造人”当作一个系统工程那它和搭建一个大型软件开发项目类似也需要明确“环境准备”。对车企来说这个“环境准备”不是装一个 Python 环境而是从团队、数据、算力和供应链四个维度补齐基础设施。2.1 组织与人才复合型团队是前提人形机器人是一个典型的多学科交叉领域需要的角色远不止传统汽车工程师感知算法工程师负责视觉、激光雷达、多传感器融合让人形机器人“看得见”。运控算法工程师负责步态规划、全身动力学控制、平衡控制让机器人“站得住、走得稳”。大模型与决策工程师负责自然语言理解、视觉语言模型、任务规划让机器人“懂得做什么”。机械结构工程师负责手臂、腿部、腰部、灵巧手的结构设计让机器人“动得灵活”。嵌入式与系统工程师负责实时操作系统、中间件、底层驱动让软硬件协同工作。由于这类人才在市场上仍然稀缺很多车企并不是直接在母公司下面组建团队而是成立独立公司、设立专项基金或者通过与高校实验室、创业公司合作的方式快速组建团队。组织架构上的灵活性往往比技术上的投入更早决定项目成败。2.2 数据与数据闭环机器人的“燃料”自动驾驶行业有一句经典的话“数据是自动驾驶的燃料。”这句话同样适用于具身智能。但两者的数据形态有很大差异。自动驾驶采集的主要是道路场景数据通过大量量产车在路上行驶即可获得数据来源丰富、成本相对可控。而人形机器人需要的数据更多是人类在物理世界中的操作数据拿起杯子、拧紧螺丝、折叠衣物、开门、搬运箱子……这类数据目前在真实环境中只能通过动作捕捉、遥操作、人工标注等方式采集成本高、效率低还没有形成像“道路车队采集”那样成熟的规模化方案。数据闭环也同样重要车端采集数据后上传到云端进行标注、训练、评测再通过 OTA 把新模型部署到车上。机器人也需要类似的闭环——真机操作数据回流到云端经过仿真训练和强化学习后迭代出更优策略再下发到下一代机器人本体中。谁能先把数据闭环跑通谁就更有可能在真实场景中快速迭代。2.3 算力与训练基础设施大模型时代的入场券人形机器人的智能程度和它的“训练算力”强相关。无论是视觉感知模型、运动控制策略还是多模态大模型都需要大规模 GPU 集群进行训练。也就是说车企造人并不是只做“硬件外壳”或“整机组装”而是要在云端搭建一套完整的 AI 训练基础设施。这个基础设施包括高性能计算集群用于训练感知、决策、规划等深度神经网络模型。仿真平台在虚拟环境中进行海量训练避免真机训练的高成本和风险。数据管理与标注平台对原始传感器数据、操作数据进行清洗、标注、扩增。模型评测体系在统一指标下评估模型在真实环境中的表现。算力基础设施的重资产属性也意味着这条赛道天然向头部玩家集中。没有足够资金和技术积累的企业很难从一开始就建立起完整的训练体系。2.4 供应链与量产能力从样机到商品的鸿沟做出一台原型机器人和量产一万台机器人是两个完全不同的难度等级。人形机器人的硬件涉及关节电机、谐波减速器、行星滚柱丝杠、力矩传感器、IMU、计算平台、电池包等一系列零部件。其中很多零部件在汽车供应链中不常见成本和产能都有待成熟。车企的一个明显优势是过去十几年积累的供应链管理经验、工装设计能力、量产爬坡方法、品质管理流程。这些方法论是可以复用到机器人产线上的。但需要注意的是汽车和机器人在零部件类型、失效模式、装配工艺上仍有明显差异不能简单照搬。车企需要建设新的供应链生态并与机器人零部件厂商深度协作才能逐步把核心零部件的价格打下来。3. 核心技术与原理拆解具身智能背后的技术栈从技术视角来看“车企造人”可以被拆解成五个核心模块感知、决策规划、运动控制、大模型与仿真训练。下面逐一展开并解释每个模块与自动驾驶技术之间的“复用”与“差异”。3.1 感知层从 BEV 感知到多模态空间理解自动驾驶中感知层的核心任务是让车辆理解周围环境包括车道线、障碍物、交通标志、行人等。目前主流方案已经从前些年基于目标检测的 2D 感知转向基于 Transformer 的 BEV 感知把多个摄像头视角的图像统一投影到鸟瞰视角空间再生成可供规划模块直接使用的结构化表示。人形机器人的感知需求要更复杂一些。它不仅需要识别“这是什么物体”还需要知道物体的三维位置、朝向、可抓取姿态、材质特性以及在操作过程中物体是否会滑动、旋转、变形。所以机器人感知通常采用“多模态融合”的方式视觉给出语义信息深度相机或激光雷达提供三维几何信息触觉传感器提供接触反馈IMU 提供本体姿态参考。代码层面一个简化版的多传感器对齐与融合管线可以写成下面这样它可以帮助理解“自动驾驶数据如何迁移到机器人训练集”# 示意多源感知数据统一处理的伪代码 # 实际项目中需要结合传感器驱动与具体模型框架实现 def preprocess_multi_source_data(camera_views, depth_maps, joint_states): # 1. 时间戳对齐相机、深度、关节角数据必须同步到同一时刻 aligned_data align_timestamp(camera_views, depth_maps, joint_states) # 2. 坐标变换把相机坐标转换到机器人本体坐标系 obs_in_robot_frame transform_to_robot_frame(aligned_data) # 3. 数据增强对视觉输入做随机裁剪、亮度扰动提升泛化性 augmented_data augmentation(obs_in_robot_frame) return augmented_data这里的核心思想是不是把传感器的数据直接硬塞给模型而是先通过时间同步、坐标变换和数据增强建立一个统一的空间表示。自动驾驶和机器人感知在这条链路上非常相似差异在于机器人还要额外考虑“可操作性”也就是在感知结果中显式地输出可供机械臂抓取和操作的位姿信息。3.2 决策与规划从导航路径到任务规划自动驾驶的规划模块通常可以分为全局路径规划和局部轨迹规划。全局规划决定车辆走哪条路局部规划决定车辆在接下来几秒钟内如何避障、变道、加减速。决策问题相对集中前方有障碍物就停车、绕行或并线意图相对明确。人形机器人的规划则是分层的任务规划层比如用户下达指令“把桌上的杯子拿给我”机器人需要先理解这个指令再拆解为“走向桌子”“伸出右手”“抓取杯子”“移动到用户身边”“释放杯子”等子任务。运动规划层对应于每个子任务机器人需要规划机械臂的轨迹、身体的重心位置、双足迈步的落脚点。底层控制层把规划出来的目标位姿转化为关节力矩指令实时补偿外部扰动。在任务规划层最近几年的技术趋势是利用大语言模型LLM和视觉语言模型VLM来充当“机器人大脑”。模型可以理解自然语言指令并结合当前画面输出可执行的子任务序列。但大模型输出的是高层语义动作不能直接下发给关节电机必须经过一个“动作解释器”把高层动作映射到运动规划器的具体参数上。举个例子下面这段伪代码展示了一个简化版的任务编排流程# 示意具身智能任务编排的伪代码 class RobotTaskPipeline: def __init__(self, vlm, controller): self.vlm vlm # 视觉语言模型负责理解指令与场景 self.controller controller # 底层运动控制器负责执行动作 def execute(self, instruction: str, sensor_data: dict): # 1. 通过视觉语言模型理解任务并生成子动作序列 plan self.vlm.plan(instruction, sensor_data) # 2. 逐个执行子动作 for step in plan.actions: if not self.controller.check_condition(step.precondition): # 如果前置条件不满足跳过或重新规划 self.handle_failure(step) continue self.controller.execute(step.primitive, step.target) def handle_failure(self, step): # 实际项目中需要结合重规划策略这里仅示意 print(fTask step failed: {step})这种“大模型生成高层计划 传统运动规划器执行底层动作”的混合架构是目前行业普遍采用的工程方案。它既利用了深度模型的泛化能力又避免了端到端模型在真实物理世界中的不可控风险。3.3 运动控制从控制汽车到控制双足与灵巧手运动控制是汽车与机器人差异最大的模块之一。汽车的运动学相对简单四个轮子、转向角、油门、刹车控制周期在几十毫秒到百毫秒级别。人形机器人则是典型的高维、非线性、强耦合系统。以双足行走为例机器人既要考虑每条腿多个关节的角度、角速度和力矩还要保证整体重心落在支撑多边形内。遇到不平整地面、外部推搡时需要根据足底力传感器反馈实时调整步态甚至通过全身协调动作恢复平衡。控制周期往往要求达到 1000Hz 甚至更高。而臂部操作则是另一种挑战。机械臂运动学相对清晰但一旦加上灵巧手自由度会迅速增加。每根手指有多个自由度如何协调全部关节完成一个精细操作如何控制抓取力不损坏物体都是工程难题。从技术路径上看运动控制正在从经典建模方法向“基于强化学习的仿真训练”迁移。具体做法是先在仿真环境中定义机器人的动力学模型、任务奖励函数、随机扰动分布然后通过强化学习算法训练一个神经网络策略让机器人学会在各种扰动下保持平衡或完成操作。训练好的策略再迁移到真机并在真机上做进一步微调。这个范式与自动驾驶中“在仿真环境中训练决策模型再迁移到车端”的思路高度一致但机器人领域对物理逼真度的要求更高。3.4 大模型与“机器人的大脑”人形机器人要真正走向通用需要一个能理解任务、理解场景、产生常识推理能力的“大脑”。这正是大模型发挥作用的地方。大语言模型擅长理解和生成文本可以把自然语言指令翻译成结构化任务视觉语言模型可以结合图像内容理解“桌上有一个红色杯子”“门口有一把扫帚”这类视觉概念多模态大模型还能把语音、文字、图像融合在一起让人与机器人的交互变得更自然。但大模型的输出往往是语义级别的不能直接作为关节电机的期望力矩。因此工程上需要做“分层架构”大脑层多模态大模型负责常识理解、任务规划、人机对话。小脑层负责把任务规划转化为具体的运动轨迹和步态。脊髓层负责高频的控制响应比如关节伺服、力控制、姿态稳定。这样分层的意义在于大脑层可以接受“百人齐唱祝福歌”这种开放性目标小脑层将其分解为可执行的运动序列脊髓层保证底层控制稳定可靠。每一层有自己的时间尺度和计算资源要求彼此解耦才能让系统在真实环境中既灵活又安全。3.5 仿真训练与 Sim2Real真实机器人训练有两个致命约束一是慢迭代一个策略可能需要上百万次试错真机根本跑不完二是危险机器人一旦失控可能损坏本体甚至伤害周围人员。因此仿真训练成为必经之路。当前人形机器人开发中常用的仿真工具包括 MuJoCo、Isaac Sim、PyBullet 等它们可以导入机器人 URDF 模型、构建虚拟场景、设置物理属性并在虚拟环境中训练深度强化学习策略。训练流程通常是导入机器人模型与场景模型。定义观测空间、动作空间和奖励函数。启动一个分布式训练任务让大量虚拟机器人在并行环境中试错。通过强化学习算法优化策略直到虚拟环境中的任务成功率达标。将策略部署到真机并针对真实环境差别做微调。下面给出一个简化版的仿真训练命令示意帮助你理解整体流程# 示意启动机器人策略训练任务的通用流程 # 具体框架和参数请根据你的仿真环境与算法库版本调整 conda create -n robot_ai python3.10 -y conda activate robot_ai pip install torch torchvision # 训练操作策略指定使用仿真环境作为数据来源 python train_manipulation.py \ --env sim \ --algorithm rl \ --task pick_and_place \ --epochs 200训练完成后还需要解决 Sim2Real从仿真到真实的迁移问题。仿真环境中的物理参数、摩擦力、传感器噪声与真实世界总有差距。为了缩小这个差距常见的做法包括 domain randomization域随机化在训练过程中随机改变物体的质量、摩擦系数、材质颜色、光照条件让模型学到更鲁棒的策略。4. 实战案例代表性玩家的技术路线盘点“车企造人”不是纸上谈兵行业里已经出现了一批值得关注的技术玩家。下面以公开信息为基础从技术路线角度做简要盘点。这里不评价谁一定能成功只分析各自的特点和卡位。4.1 特斯拉从 FSD 到 Optimus 的技术复利特斯拉是“车企造人”讨论中绕不开的标杆。据公开信息特斯拉在 2021 年 AI Day 上提出 Tesla Bot 概念后续陆续展示过 Optimus 原型机。从技术逻辑看Optimus 与特斯拉的 FSD 智能驾驶系统共享大量底层资产。在感知端Optimus 延续了纯视觉路线试图复用 FSD 中经过大数据训练的视觉神经网络识别物体、空间位置和交互关系。在训练端特斯拉建成的数据中心和自动驾驶仿真体系也可以复用于机器人模型训练。这种“用一套 AI 基础设施同时支撑自动驾驶和机器人”的做法是特斯拉最核心的差异化优势。不过Optimus 从实验室原型到真正能胜任工厂任务还有很长的路。它的每一次迭代收益不仅是“发布一个产品”更是验证“FSD 技术资产能否跨越到通用机器人领域”。这条技术路径如果能跑通就会有巨大的规模效应如果跑不通成本也会非常高昂。4.2 新势力玩家与智驾体系同源的探索国内新势力车企中已有部分品牌公开了自己的机器人产品。比如小鹏汽车在 2024 年前后发布了自研机器人产品强调与智能驾驶同源的感知架构并尝试把智驾上的多传感器融合、端到端模型训练经验复用过来。从技术路线上看这类新势力玩家的普遍思路是“先复用再独立”先用智驾团队的感知算法、数据平台、仿真平台做机器人的地基再逐步构建运控算法、灵巧操作和具身交互能力。这样做的好处是起步快、投入可控潜在的问题是机器人场景与汽车场景在操作端差异明显如果组织架构上仍然完全依赖智驾团队可能会导致机器人的运控和硬件优化进度滞后。4.3 传统车企与供应链先让机器人在工厂干活相比新势力的高调亮相更多传统车企选择了更低调的路线先在工厂里部署人形机器人用于搬运、检测、上下料等相对固定的场景。这类企业不一定立刻发布消费级人形机器人而是把“工厂打工”作为机器人从实验室走向商品的第一步。工厂场景的价值在于环境相对结构化、任务边界清晰、安全措施容易设计并且可以直接计算经济收益。比如机器人能完成产线上的取料放料任务就能替代一部分重复性人力。同时机器人在工厂执行任务过程中积累的真实操作数据将为后续更复杂场景的迭代提供燃料。4.4 车企“造人”能力迁移地图能力模块汽车领域积累机器人领域需求复用程度环境感知摄像头、雷达、BEV 感知模型物体识别、三维几何理解、场景语义高需扩展决策规划路径规划、行为预测任务规划、运动规划、操作规划中差异大运动控制车辆横纵向控制双足平衡、全身动力学、灵巧手控制低需重建大模型能力智驾多模态模型、语音交互语言理解、任务拆解、常识推理高可复用仿真训练自动驾驶仿真测试强化学习、Sim2Real 迁移中需强化供应链量产成熟质量管理体系关节电机、减速器、传感器量产中需重构数据闭环车队数据采集、标注、OTA遥操作采集、人机交互数据回传中模式不同从表格可以看出真正能够快速复用的是感知、大模型和云端基础设施而运动控制、硬件供应链和机器人专属数据闭环才是“造人”之路最需要补课的部分。5. 常见卡点与排查思路为什么“道阻且长”在做技术规划时提前识别“坑”比想象中的“爽点”更重要。下面把车企造人过程中最常见的卡点整理成一份“排查清单”每一条都对应真实工程中会遇到的问题。5.1 卡点一硬件成本降不下来人形机器人的硬件成本一直居高不下。核心部件中行星滚柱丝杠、高精度力矩传感器、谐波减速器、高功率密度电机单颗价格都不低且很多部件尚未形成大规模供给。开发一个完整人形机器人硬件成本往往超过一辆入门级汽车。排查思路先确认产品定义是“科研演示”还是“量产商品”。如果目标是量产就要尽早和核心零部件供应商深度绑定甚至考虑自研关键部件同时通过平台化设计减少零件种类用更多共模零件拉高采购规模。5.2 卡点二机器人操作数据从哪里来自动驾驶可以靠量产车回传道路数据而机器人操作数据目前没有一个低成本、大流量的规模化采集方案。想让机器人学会“叠衣服”“插充电头”“打开瓶盖”这类操作最原始的方式是“遥操作”由操作员戴上动作捕捉设备或者通过手柄遥控机械臂把每一个动作记录下来作为训练数据。这种做法效率低一条动作数据往往需要数百次重复演示。而且很多精细动作需要触觉反馈现有遥操作设备不一定能完整记录“用了多大的力”这会导致数据质量不足。解决方向主要有三个一是远程遥操作大规模采集在数据采集站中让大量操作员并行产出数据二是从互联网视频中挖掘人类动作信息用大模型自动生成训练数据三是提高仿真数据比重在虚拟环境中自动生成海量带标注数据再通过 Sim2Real 迁移到真机。5.3 卡点三可靠性与安全生产事故风险人形机器人在实验室里跑通一个 demo 并不难难的是在连续生产 8 小时、12 小时甚至更长时间内保持稳定。真实场景中温度变化、线缆磨损、关节老化、传感器漂移都会导致任务失败。更严重的是一个重达几十公斤的机器人一旦失控会对周围的人和设备造成威胁。排查思路在部署到真实场景之前必须建立完善的安全评估体系。包括机械安全设计、急停逻辑、力矩限制、速度限制、碰撞检测与力反馈控制。凡是涉及机器人与人协作的场景都应该先做离线仿真验证再小范围灰度测试最后再逐步扩大部署范围。5.4 卡点四场景与商业模式不清晰目前人形机器人的典型场景可分为工业场景、商业服务场景和家庭服务场景。工业场景相对容易落地但单台价值量有天花板家庭服务场景想象空间巨大但技术难度和安全要求极高短期内很难达到可商用程度。很多车企在做商业化规划时容易陷入“既想快速出货又找不到真正高毛利刚需场景”的困境。比较务实的路径是选择两三个能够快速闭环的场景比如“工厂上下料”“实验室无人搬运”“科研教学平台”在场景里把成本、可靠性、效率打磨到客户愿意买单再逐步向更复杂的通用场景扩展。5.5 卡点五标准、安全与责任边界不完善人形机器人作为一个新品类目前还缺乏统一的安全标准、性能评测方法和责任认定机制。机器人如果在真实场景中出现事故责任是该由机器人制造方承担、算法提供方承担还是场景运营方承担这类问题在法规层面还没有形成成熟共识。对从业者来说这一步不能等法规成熟之后再行动。更可行的方案是在内部主动制定高于行业平均水平的安全标准包括碰撞伤害度量、力矩限制、制动距离、数据隐私保护等并建立完整的事故日志与追查机制。这样既能保护用户也能在监管框架落地时占据主动权。6. 工程化与产业建议车企如何把“造人”从发布会推向量产结合上述技术栈和卡点下面给出几条更落地的工程与产业建议。6.1 先做“工业人形”再谈“家庭服务”人形机器人最容易出成绩的战场不是科幻电影里的“家庭管家”而是真实工厂里的“重复操作”。工厂环境相对结构化有固定流程、固定工位、固定工具而且人工招聘难、人员流动大更适合用机器人替代部分重复性工作。车企应该优先把机器人投入到自有工厂验证比如物料搬运、零件分拣、质量检测协助、自动化上下料。这样做有三重收益一是降低工厂运营成本二是获得真实场景数据三是培养团队对机器人可靠性的理解。等工业场景跑通后再向服务场景和家庭场景扩展。6.2 分层架构避免“大模型直接驱动电机”很多团队在早期喜欢追求“端到端”的酷炫 demo把传感器数据直接送入大模型让模型输出关节控制信号看起来技术非常前沿但真实落地时往往不可控、不可解释、难调试。更稳妥的做法是分层设计大脑层处理自然语言理解与任务规划小脑层把任务规划转成运动轨迹脊髓层负责高频电机控制。每一层保留自己的 debug 接口和降级策略一旦上层模型失效底层仍然可以保证机器人安全停止或执行默认动作。这种架构可能看起来不够“酷”但在工程上是最可维护、最可迭代的选择。6.3 建立“仿真 真机”双数据闭环如果只依赖真机采集数据迭代速度会非常慢如果只依赖仿真训练又会因为 Sim2Real 差距导致真机表现不佳。正确的做法是建立双数据闭环真机数据驱动仿真把真机采集到的操作数据放回仿真环境中用于构建更真实的动力学模型和任务场景。仿真数据驱动真机在仿真环境中大规模训练策略然后把策略部署到真机执行真机反馈的失败数据继续回流到仿真中。只有让仿真和真机互相“喂养”机器人的能力才会持续提升。6.4 安全设计前置而不是后补安全不能等产品接近量产时才开始考虑。从硬件设计阶段就必须加入机械限位、急停开关、碰撞吸收结构在软件架构中任何上层规划指令都必须经过安全过滤器确保关节力矩、电机温度、速度等关键指标不越界。一个可行的安全机制是“影子模式”在机器人执行任务时后台同时运行一个只读的安全监督模型它不直接输出动作只负责检查当前策略的执行结果是否安全。如果发现异常安全监督模型可以发出中断指令将系统切换到安全状态。这比事后检测碰撞更主动。6.5 用开放生态降低研发成本人形机器人的技术栈太宽没有一家公司能够独立完成全部中底层能力。更现实的做法是在非核心领域尽量使用成熟组件与开源框架比如机器人操作系统、运动规划库、仿真器、感知模型把内部研发资源集中到最关键的差异化能力上比如面向特定场景的运控算法、任务级大模型、数据闭环工具链等。同时车企可以考虑以投资或战略合作的方式与机器人创业公司、高校实验室、零部件厂商形成生态联盟。不是所有东西都要自研但关键的数据平台、训练体系和核心硬件设计必须掌握在自己手里。7. 总结与后续学习路线从“造车”到“造人”本质上是一次从结构化交通场景向非结构化物理世界跨越的技术长征。车企的优势在于已经拥有感知算法、算力基础设施、供应链管理和量产制造经验这些资产能够被复用但不能被直接照搬。真正的差距集中在运动控制、机器人专属数据、灵巧操作、可靠性和安全设计这些需要长期投入的领域。对开发者来说如果想要进入这条赛道建议从三件事入手第一扎实掌握机器人的感知与运动规划基础尤其是 ROS、PyTorch、Simulink 这类常用工具第二深入理解仿真训练与 Sim2Real 的流程如果在校或业余时间可以尝试在 MuJoCo 或 Isaac Sim 中训练一个简单的机器人操作策略第三关注大模型与机器人结合的工程落地方式不要只停留在 demo 层面多思考“模型输出如何转换成安全、可靠、可解释的物理动作”。车企“造人”这条路短期看是技术竞赛中期看是供应链与量产能力竞赛长期看是数据闭环与安全体系竞赛。谁能在这些维度上持续迭代谁才有机会把“道阻且长”的终局走成“行则将至”。如果你此前还没有接触过机器人开发可以先从安装一个仿真环境、加载一个人形机器人模型开始跑通一次最简单的运动控制示例再逐步深入更复杂的强化学习策略。纸上得来终觉浅动手实践才是理解“车企造人”背后技术难度的最好方式。如果本文对你理解“车企造人”和具身智能的工程脉络有帮助可以收藏备用后续遇到相关技术细节也欢迎在评论区交流讨论。 车企造人：从自动驾驶到具身智能的技术跃迁
最近一段时间关于“新造车”的讨论已经不再局限于续航、补能、智能驾驶这些常规话题。行业里开始频繁出现一个颇具科幻感的表达车企要“造人”。乍一听像是在讨论某种虚构概念实际上这里的“造人”指的是人形机器人更准确的技术表述是“具身智能”——让 AI 拥有物理身体能够感知、决策、执行并与真实世界交互。多家新造车企业以及传统主机厂正在把研发资源、资本和供应链能力向这条赛道倾斜。本文不打算做行业八卦式盘点而是希望以技术教程和工程复盘的方式帮读者看清“车企造人”背后的能力迁移逻辑、技术栈构成、真正的难点以及可行的落地路径。无论你是从事自动驾驶开发的工程师还是对具身智能感兴趣的初学者这篇文章都可以作为一张系统的认知地图。1. 背景与核心概念车企“造人”到底是什么1.1 “造人”不是造人而是布局具身智能如果把“车企造人”理解成去制造一个生物意义上的人类那就完全跑偏了。车企要造的是具备感知、认知、运动和操作能力的人形机器人。这种机器人的核心不只是“长得像人”而是拥有通用的物理交互能力能理解你说了什么能看到周围环境能规划出先做什么后做什么还能用机械臂和灵巧手把动作真正执行出来。用一个更严谨的概念来概括就是“具身智能”。传统 AI 更像是活在服务器里的“大脑”只负责处理文本、图片、语音等数字信息而具身智能要求 AI 必须有一个“身体”让模型与物理世界直接接触在真实环境中通过试错、反馈、重复操作来学习和执行任务。汽车本身从广义上也是一种具身智能体但它是高度受限的主要运行在结构化的道路上形态固定交互对象也有限。而人形机器人面对的则是完全开放的场景楼梯、门把手、桌面、工具、人体甚至各类非标物体。所以“车企造人”的本质是汽车企业从“四个轮子的机器人”向“两条腿、两只手的通用机器人”方向进化。这个进化不是换个外形而是整体技术栈和人机交互能力的重大升级。1.2 为什么新造车企业会加码“造人”新造车企业押注“造人”有三个非常现实的原因。第一技术栈高度可复用。智能汽车本身就是一台装备了大量传感器、计算平台和控制系统的机器人。感知用摄像头、激光雷达、毫米波雷达决策用行为预测、路径规划、运动控制云端还有数据闭环和仿真体系。人形机器人同样需要这些能力。比如自动驾驶中的视觉感知网络经过少量改造就能迁移到机器人上用于物体识别和避障再比如车端的高性能计算平台和中间件架构也可以承接机器人的实时推理任务。第二需要寻找“第二增长曲线”。国内新能源汽车市场的竞争已经进入白热化阶段单车利润被严重压缩。车企需要找到一个新的硬件品类去承接已经积累的供应链、研发团队和品牌势能。人形机器人虽然短期无法贡献利润但在资本市场和技术趋势上的想象空间足够大。对于新势力品牌来说提前卡位也能增强自身的科技属性。第三制造本身就有巨大需求。车企在工厂里要搬运物料、检测质量、执行精密装配。传统工业机器人往往固定在产线上无法灵活移动而人形机器人天然适合“进入现有工业场景做通用操作”。所以很多车企布局“造人”的第一站就是自己的工厂。先让机器人在车间里打工既真实解决了成本问题又积累了数据和场景经验。1.3 从“造车”到“造人”不是能力叠加而是能力跃迁虽然自动驾驶和机器人技术高度相关但从“造车”到“造人”并不是简单地把四个轮子换成两条腿。汽车的行驶环境相对可控道路有车道线、红绿灯和交通规则而人形机器人要面对的是极度开放、非结构化、不可完全预测的物理世界。举个例子自动驾驶可以做到“在高速公路上安全行驶几十公里”但很难要求它“走进一间堆满杂物的厨房拉开冰箱取出一罐饮料再关门”。这两类任务对泛化性、精细操作、多模态理解的要求完全不同。因此车企造人之路必然是长期投入、持续迭代的过程发布会上的原型机只是万里长征第一步。所谓“道阻且长”恰恰体现在工程化、量产、安全、场景验证等真正难啃的环节。2. 入场条件车企做机器人需要具备哪些基础如果把“造人”当作一个系统工程那它和搭建一个大型软件开发项目类似也需要明确“环境准备”。对车企来说这个“环境准备”不是装一个 Python 环境而是从团队、数据、算力和供应链四个维度补齐基础设施。2.1 组织与人才复合型团队是前提人形机器人是一个典型的多学科交叉领域需要的角色远不止传统汽车工程师感知算法工程师负责视觉、激光雷达、多传感器融合让人形机器人“看得见”。运控算法工程师负责步态规划、全身动力学控制、平衡控制让机器人“站得住、走得稳”。大模型与决策工程师负责自然语言理解、视觉语言模型、任务规划让机器人“懂得做什么”。机械结构工程师负责手臂、腿部、腰部、灵巧手的结构设计让机器人“动得灵活”。嵌入式与系统工程师负责实时操作系统、中间件、底层驱动让软硬件协同工作。由于这类人才在市场上仍然稀缺很多车企并不是直接在母公司下面组建团队而是成立独立公司、设立专项基金或者通过与高校实验室、创业公司合作的方式快速组建团队。组织架构上的灵活性往往比技术上的投入更早决定项目成败。2.2 数据与数据闭环机器人的“燃料”自动驾驶行业有一句经典的话“数据是自动驾驶的燃料。”这句话同样适用于具身智能。但两者的数据形态有很大差异。自动驾驶采集的主要是道路场景数据通过大量量产车在路上行驶即可获得数据来源丰富、成本相对可控。而人形机器人需要的数据更多是人类在物理世界中的操作数据拿起杯子、拧紧螺丝、折叠衣物、开门、搬运箱子……这类数据目前在真实环境中只能通过动作捕捉、遥操作、人工标注等方式采集成本高、效率低还没有形成像“道路车队采集”那样成熟的规模化方案。数据闭环也同样重要车端采集数据后上传到云端进行标注、训练、评测再通过 OTA 把新模型部署到车上。机器人也需要类似的闭环——真机操作数据回流到云端经过仿真训练和强化学习后迭代出更优策略再下发到下一代机器人本体中。谁能先把数据闭环跑通谁就更有可能在真实场景中快速迭代。2.3 算力与训练基础设施大模型时代的入场券人形机器人的智能程度和它的“训练算力”强相关。无论是视觉感知模型、运动控制策略还是多模态大模型都需要大规模 GPU 集群进行训练。也就是说车企造人并不是只做“硬件外壳”或“整机组装”而是要在云端搭建一套完整的 AI 训练基础设施。这个基础设施包括高性能计算集群用于训练感知、决策、规划等深度神经网络模型。仿真平台在虚拟环境中进行海量训练避免真机训练的高成本和风险。数据管理与标注平台对原始传感器数据、操作数据进行清洗、标注、扩增。模型评测体系在统一指标下评估模型在真实环境中的表现。算力基础设施的重资产属性也意味着这条赛道天然向头部玩家集中。没有足够资金和技术积累的企业很难从一开始就建立起完整的训练体系。2.4 供应链与量产能力从样机到商品的鸿沟做出一台原型机器人和量产一万台机器人是两个完全不同的难度等级。人形机器人的硬件涉及关节电机、谐波减速器、行星滚柱丝杠、力矩传感器、IMU、计算平台、电池包等一系列零部件。其中很多零部件在汽车供应链中不常见成本和产能都有待成熟。车企的一个明显优势是过去十几年积累的供应链管理经验、工装设计能力、量产爬坡方法、品质管理流程。这些方法论是可以复用到机器人产线上的。但需要注意的是汽车和机器人在零部件类型、失效模式、装配工艺上仍有明显差异不能简单照搬。车企需要建设新的供应链生态并与机器人零部件厂商深度协作才能逐步把核心零部件的价格打下来。3. 核心技术与原理拆解具身智能背后的技术栈从技术视角来看“车企造人”可以被拆解成五个核心模块感知、决策规划、运动控制、大模型与仿真训练。下面逐一展开并解释每个模块与自动驾驶技术之间的“复用”与“差异”。3.1 感知层从 BEV 感知到多模态空间理解自动驾驶中感知层的核心任务是让车辆理解周围环境包括车道线、障碍物、交通标志、行人等。目前主流方案已经从前些年基于目标检测的 2D 感知转向基于 Transformer 的 BEV 感知把多个摄像头视角的图像统一投影到鸟瞰视角空间再生成可供规划模块直接使用的结构化表示。人形机器人的感知需求要更复杂一些。它不仅需要识别“这是什么物体”还需要知道物体的三维位置、朝向、可抓取姿态、材质特性以及在操作过程中物体是否会滑动、旋转、变形。所以机器人感知通常采用“多模态融合”的方式视觉给出语义信息深度相机或激光雷达提供三维几何信息触觉传感器提供接触反馈IMU 提供本体姿态参考。代码层面一个简化版的多传感器对齐与融合管线可以写成下面这样它可以帮助理解“自动驾驶数据如何迁移到机器人训练集”# 示意多源感知数据统一处理的伪代码 # 实际项目中需要结合传感器驱动与具体模型框架实现 def preprocess_multi_source_data(camera_views, depth_maps, joint_states): # 1. 时间戳对齐相机、深度、关节角数据必须同步到同一时刻 aligned_data align_timestamp(camera_views, depth_maps, joint_states) # 2. 坐标变换把相机坐标转换到机器人本体坐标系 obs_in_robot_frame transform_to_robot_frame(aligned_data) # 3. 数据增强对视觉输入做随机裁剪、亮度扰动提升泛化性 augmented_data augmentation(obs_in_robot_frame) return augmented_data这里的核心思想是不是把传感器的数据直接硬塞给模型而是先通过时间同步、坐标变换和数据增强建立一个统一的空间表示。自动驾驶和机器人感知在这条链路上非常相似差异在于机器人还要额外考虑“可操作性”也就是在感知结果中显式地输出可供机械臂抓取和操作的位姿信息。3.2 决策与规划从导航路径到任务规划自动驾驶的规划模块通常可以分为全局路径规划和局部轨迹规划。全局规划决定车辆走哪条路局部规划决定车辆在接下来几秒钟内如何避障、变道、加减速。决策问题相对集中前方有障碍物就停车、绕行或并线意图相对明确。人形机器人的规划则是分层的任务规划层比如用户下达指令“把桌上的杯子拿给我”机器人需要先理解这个指令再拆解为“走向桌子”“伸出右手”“抓取杯子”“移动到用户身边”“释放杯子”等子任务。运动规划层对应于每个子任务机器人需要规划机械臂的轨迹、身体的重心位置、双足迈步的落脚点。底层控制层把规划出来的目标位姿转化为关节力矩指令实时补偿外部扰动。在任务规划层最近几年的技术趋势是利用大语言模型LLM和视觉语言模型VLM来充当“机器人大脑”。模型可以理解自然语言指令并结合当前画面输出可执行的子任务序列。但大模型输出的是高层语义动作不能直接下发给关节电机必须经过一个“动作解释器”把高层动作映射到运动规划器的具体参数上。举个例子下面这段伪代码展示了一个简化版的任务编排流程# 示意具身智能任务编排的伪代码 class RobotTaskPipeline: def __init__(self, vlm, controller): self.vlm vlm # 视觉语言模型负责理解指令与场景 self.controller controller # 底层运动控制器负责执行动作 def execute(self, instruction: str, sensor_data: dict): # 1. 通过视觉语言模型理解任务并生成子动作序列 plan self.vlm.plan(instruction, sensor_data) # 2. 逐个执行子动作 for step in plan.actions: if not self.controller.check_condition(step.precondition): # 如果前置条件不满足跳过或重新规划 self.handle_failure(step) continue self.controller.execute(step.primitive, step.target) def handle_failure(self, step): # 实际项目中需要结合重规划策略这里仅示意 print(fTask step failed: {step})这种“大模型生成高层计划 传统运动规划器执行底层动作”的混合架构是目前行业普遍采用的工程方案。它既利用了深度模型的泛化能力又避免了端到端模型在真实物理世界中的不可控风险。3.3 运动控制从控制汽车到控制双足与灵巧手运动控制是汽车与机器人差异最大的模块之一。汽车的运动学相对简单四个轮子、转向角、油门、刹车控制周期在几十毫秒到百毫秒级别。人形机器人则是典型的高维、非线性、强耦合系统。以双足行走为例机器人既要考虑每条腿多个关节的角度、角速度和力矩还要保证整体重心落在支撑多边形内。遇到不平整地面、外部推搡时需要根据足底力传感器反馈实时调整步态甚至通过全身协调动作恢复平衡。控制周期往往要求达到 1000Hz 甚至更高。而臂部操作则是另一种挑战。机械臂运动学相对清晰但一旦加上灵巧手自由度会迅速增加。每根手指有多个自由度如何协调全部关节完成一个精细操作如何控制抓取力不损坏物体都是工程难题。从技术路径上看运动控制正在从经典建模方法向“基于强化学习的仿真训练”迁移。具体做法是先在仿真环境中定义机器人的动力学模型、任务奖励函数、随机扰动分布然后通过强化学习算法训练一个神经网络策略让机器人学会在各种扰动下保持平衡或完成操作。训练好的策略再迁移到真机并在真机上做进一步微调。这个范式与自动驾驶中“在仿真环境中训练决策模型再迁移到车端”的思路高度一致但机器人领域对物理逼真度的要求更高。3.4 大模型与“机器人的大脑”人形机器人要真正走向通用需要一个能理解任务、理解场景、产生常识推理能力的“大脑”。这正是大模型发挥作用的地方。大语言模型擅长理解和生成文本可以把自然语言指令翻译成结构化任务视觉语言模型可以结合图像内容理解“桌上有一个红色杯子”“门口有一把扫帚”这类视觉概念多模态大模型还能把语音、文字、图像融合在一起让人与机器人的交互变得更自然。但大模型的输出往往是语义级别的不能直接作为关节电机的期望力矩。因此工程上需要做“分层架构”大脑层多模态大模型负责常识理解、任务规划、人机对话。小脑层负责把任务规划转化为具体的运动轨迹和步态。脊髓层负责高频的控制响应比如关节伺服、力控制、姿态稳定。这样分层的意义在于大脑层可以接受“百人齐唱祝福歌”这种开放性目标小脑层将其分解为可执行的运动序列脊髓层保证底层控制稳定可靠。每一层有自己的时间尺度和计算资源要求彼此解耦才能让系统在真实环境中既灵活又安全。3.5 仿真训练与 Sim2Real真实机器人训练有两个致命约束一是慢迭代一个策略可能需要上百万次试错真机根本跑不完二是危险机器人一旦失控可能损坏本体甚至伤害周围人员。因此仿真训练成为必经之路。当前人形机器人开发中常用的仿真工具包括 MuJoCo、Isaac Sim、PyBullet 等它们可以导入机器人 URDF 模型、构建虚拟场景、设置物理属性并在虚拟环境中训练深度强化学习策略。训练流程通常是导入机器人模型与场景模型。定义观测空间、动作空间和奖励函数。启动一个分布式训练任务让大量虚拟机器人在并行环境中试错。通过强化学习算法优化策略直到虚拟环境中的任务成功率达标。将策略部署到真机并针对真实环境差别做微调。下面给出一个简化版的仿真训练命令示意帮助你理解整体流程# 示意启动机器人策略训练任务的通用流程 # 具体框架和参数请根据你的仿真环境与算法库版本调整 conda create -n robot_ai python3.10 -y conda activate robot_ai pip install torch torchvision # 训练操作策略指定使用仿真环境作为数据来源 python train_manipulation.py \ --env sim \ --algorithm rl \ --task pick_and_place \ --epochs 200训练完成后还需要解决 Sim2Real从仿真到真实的迁移问题。仿真环境中的物理参数、摩擦力、传感器噪声与真实世界总有差距。为了缩小这个差距常见的做法包括 domain randomization域随机化在训练过程中随机改变物体的质量、摩擦系数、材质颜色、光照条件让模型学到更鲁棒的策略。4. 实战案例代表性玩家的技术路线盘点“车企造人”不是纸上谈兵行业里已经出现了一批值得关注的技术玩家。下面以公开信息为基础从技术路线角度做简要盘点。这里不评价谁一定能成功只分析各自的特点和卡位。4.1 特斯拉从 FSD 到 Optimus 的技术复利特斯拉是“车企造人”讨论中绕不开的标杆。据公开信息特斯拉在 2021 年 AI Day 上提出 Tesla Bot 概念后续陆续展示过 Optimus 原型机。从技术逻辑看Optimus 与特斯拉的 FSD 智能驾驶系统共享大量底层资产。在感知端Optimus 延续了纯视觉路线试图复用 FSD 中经过大数据训练的视觉神经网络识别物体、空间位置和交互关系。在训练端特斯拉建成的数据中心和自动驾驶仿真体系也可以复用于机器人模型训练。这种“用一套 AI 基础设施同时支撑自动驾驶和机器人”的做法是特斯拉最核心的差异化优势。不过Optimus 从实验室原型到真正能胜任工厂任务还有很长的路。它的每一次迭代收益不仅是“发布一个产品”更是验证“FSD 技术资产能否跨越到通用机器人领域”。这条技术路径如果能跑通就会有巨大的规模效应如果跑不通成本也会非常高昂。4.2 新势力玩家与智驾体系同源的探索国内新势力车企中已有部分品牌公开了自己的机器人产品。比如小鹏汽车在 2024 年前后发布了自研机器人产品强调与智能驾驶同源的感知架构并尝试把智驾上的多传感器融合、端到端模型训练经验复用过来。从技术路线上看这类新势力玩家的普遍思路是“先复用再独立”先用智驾团队的感知算法、数据平台、仿真平台做机器人的地基再逐步构建运控算法、灵巧操作和具身交互能力。这样做的好处是起步快、投入可控潜在的问题是机器人场景与汽车场景在操作端差异明显如果组织架构上仍然完全依赖智驾团队可能会导致机器人的运控和硬件优化进度滞后。4.3 传统车企与供应链先让机器人在工厂干活相比新势力的高调亮相更多传统车企选择了更低调的路线先在工厂里部署人形机器人用于搬运、检测、上下料等相对固定的场景。这类企业不一定立刻发布消费级人形机器人而是把“工厂打工”作为机器人从实验室走向商品的第一步。工厂场景的价值在于环境相对结构化、任务边界清晰、安全措施容易设计并且可以直接计算经济收益。比如机器人能完成产线上的取料放料任务就能替代一部分重复性人力。同时机器人在工厂执行任务过程中积累的真实操作数据将为后续更复杂场景的迭代提供燃料。4.4 车企“造人”能力迁移地图能力模块汽车领域积累机器人领域需求复用程度环境感知摄像头、雷达、BEV 感知模型物体识别、三维几何理解、场景语义高需扩展决策规划路径规划、行为预测任务规划、运动规划、操作规划中差异大运动控制车辆横纵向控制双足平衡、全身动力学、灵巧手控制低需重建大模型能力智驾多模态模型、语音交互语言理解、任务拆解、常识推理高可复用仿真训练自动驾驶仿真测试强化学习、Sim2Real 迁移中需强化供应链量产成熟质量管理体系关节电机、减速器、传感器量产中需重构数据闭环车队数据采集、标注、OTA遥操作采集、人机交互数据回传中模式不同从表格可以看出真正能够快速复用的是感知、大模型和云端基础设施而运动控制、硬件供应链和机器人专属数据闭环才是“造人”之路最需要补课的部分。5. 常见卡点与排查思路为什么“道阻且长”在做技术规划时提前识别“坑”比想象中的“爽点”更重要。下面把车企造人过程中最常见的卡点整理成一份“排查清单”每一条都对应真实工程中会遇到的问题。5.1 卡点一硬件成本降不下来人形机器人的硬件成本一直居高不下。核心部件中行星滚柱丝杠、高精度力矩传感器、谐波减速器、高功率密度电机单颗价格都不低且很多部件尚未形成大规模供给。开发一个完整人形机器人硬件成本往往超过一辆入门级汽车。排查思路先确认产品定义是“科研演示”还是“量产商品”。如果目标是量产就要尽早和核心零部件供应商深度绑定甚至考虑自研关键部件同时通过平台化设计减少零件种类用更多共模零件拉高采购规模。5.2 卡点二机器人操作数据从哪里来自动驾驶可以靠量产车回传道路数据而机器人操作数据目前没有一个低成本、大流量的规模化采集方案。想让机器人学会“叠衣服”“插充电头”“打开瓶盖”这类操作最原始的方式是“遥操作”由操作员戴上动作捕捉设备或者通过手柄遥控机械臂把每一个动作记录下来作为训练数据。这种做法效率低一条动作数据往往需要数百次重复演示。而且很多精细动作需要触觉反馈现有遥操作设备不一定能完整记录“用了多大的力”这会导致数据质量不足。解决方向主要有三个一是远程遥操作大规模采集在数据采集站中让大量操作员并行产出数据二是从互联网视频中挖掘人类动作信息用大模型自动生成训练数据三是提高仿真数据比重在虚拟环境中自动生成海量带标注数据再通过 Sim2Real 迁移到真机。5.3 卡点三可靠性与安全生产事故风险人形机器人在实验室里跑通一个 demo 并不难难的是在连续生产 8 小时、12 小时甚至更长时间内保持稳定。真实场景中温度变化、线缆磨损、关节老化、传感器漂移都会导致任务失败。更严重的是一个重达几十公斤的机器人一旦失控会对周围的人和设备造成威胁。排查思路在部署到真实场景之前必须建立完善的安全评估体系。包括机械安全设计、急停逻辑、力矩限制、速度限制、碰撞检测与力反馈控制。凡是涉及机器人与人协作的场景都应该先做离线仿真验证再小范围灰度测试最后再逐步扩大部署范围。5.4 卡点四场景与商业模式不清晰目前人形机器人的典型场景可分为工业场景、商业服务场景和家庭服务场景。工业场景相对容易落地但单台价值量有天花板家庭服务场景想象空间巨大但技术难度和安全要求极高短期内很难达到可商用程度。很多车企在做商业化规划时容易陷入“既想快速出货又找不到真正高毛利刚需场景”的困境。比较务实的路径是选择两三个能够快速闭环的场景比如“工厂上下料”“实验室无人搬运”“科研教学平台”在场景里把成本、可靠性、效率打磨到客户愿意买单再逐步向更复杂的通用场景扩展。5.5 卡点五标准、安全与责任边界不完善人形机器人作为一个新品类目前还缺乏统一的安全标准、性能评测方法和责任认定机制。机器人如果在真实场景中出现事故责任是该由机器人制造方承担、算法提供方承担还是场景运营方承担这类问题在法规层面还没有形成成熟共识。对从业者来说这一步不能等法规成熟之后再行动。更可行的方案是在内部主动制定高于行业平均水平的安全标准包括碰撞伤害度量、力矩限制、制动距离、数据隐私保护等并建立完整的事故日志与追查机制。这样既能保护用户也能在监管框架落地时占据主动权。6. 工程化与产业建议车企如何把“造人”从发布会推向量产结合上述技术栈和卡点下面给出几条更落地的工程与产业建议。6.1 先做“工业人形”再谈“家庭服务”人形机器人最容易出成绩的战场不是科幻电影里的“家庭管家”而是真实工厂里的“重复操作”。工厂环境相对结构化有固定流程、固定工位、固定工具而且人工招聘难、人员流动大更适合用机器人替代部分重复性工作。车企应该优先把机器人投入到自有工厂验证比如物料搬运、零件分拣、质量检测协助、自动化上下料。这样做有三重收益一是降低工厂运营成本二是获得真实场景数据三是培养团队对机器人可靠性的理解。等工业场景跑通后再向服务场景和家庭场景扩展。6.2 分层架构避免“大模型直接驱动电机”很多团队在早期喜欢追求“端到端”的酷炫 demo把传感器数据直接送入大模型让模型输出关节控制信号看起来技术非常前沿但真实落地时往往不可控、不可解释、难调试。更稳妥的做法是分层设计大脑层处理自然语言理解与任务规划小脑层把任务规划转成运动轨迹脊髓层负责高频电机控制。每一层保留自己的 debug 接口和降级策略一旦上层模型失效底层仍然可以保证机器人安全停止或执行默认动作。这种架构可能看起来不够“酷”但在工程上是最可维护、最可迭代的选择。6.3 建立“仿真 真机”双数据闭环如果只依赖真机采集数据迭代速度会非常慢如果只依赖仿真训练又会因为 Sim2Real 差距导致真机表现不佳。正确的做法是建立双数据闭环真机数据驱动仿真把真机采集到的操作数据放回仿真环境中用于构建更真实的动力学模型和任务场景。仿真数据驱动真机在仿真环境中大规模训练策略然后把策略部署到真机执行真机反馈的失败数据继续回流到仿真中。只有让仿真和真机互相“喂养”机器人的能力才会持续提升。6.4 安全设计前置而不是后补安全不能等产品接近量产时才开始考虑。从硬件设计阶段就必须加入机械限位、急停开关、碰撞吸收结构在软件架构中任何上层规划指令都必须经过安全过滤器确保关节力矩、电机温度、速度等关键指标不越界。一个可行的安全机制是“影子模式”在机器人执行任务时后台同时运行一个只读的安全监督模型它不直接输出动作只负责检查当前策略的执行结果是否安全。如果发现异常安全监督模型可以发出中断指令将系统切换到安全状态。这比事后检测碰撞更主动。6.5 用开放生态降低研发成本人形机器人的技术栈太宽没有一家公司能够独立完成全部中底层能力。更现实的做法是在非核心领域尽量使用成熟组件与开源框架比如机器人操作系统、运动规划库、仿真器、感知模型把内部研发资源集中到最关键的差异化能力上比如面向特定场景的运控算法、任务级大模型、数据闭环工具链等。同时车企可以考虑以投资或战略合作的方式与机器人创业公司、高校实验室、零部件厂商形成生态联盟。不是所有东西都要自研但关键的数据平台、训练体系和核心硬件设计必须掌握在自己手里。7. 总结与后续学习路线从“造车”到“造人”本质上是一次从结构化交通场景向非结构化物理世界跨越的技术长征。车企的优势在于已经拥有感知算法、算力基础设施、供应链管理和量产制造经验这些资产能够被复用但不能被直接照搬。真正的差距集中在运动控制、机器人专属数据、灵巧操作、可靠性和安全设计这些需要长期投入的领域。对开发者来说如果想要进入这条赛道建议从三件事入手第一扎实掌握机器人的感知与运动规划基础尤其是 ROS、PyTorch、Simulink 这类常用工具第二深入理解仿真训练与 Sim2Real 的流程如果在校或业余时间可以尝试在 MuJoCo 或 Isaac Sim 中训练一个简单的机器人操作策略第三关注大模型与机器人结合的工程落地方式不要只停留在 demo 层面多思考“模型输出如何转换成安全、可靠、可解释的物理动作”。车企“造人”这条路短期看是技术竞赛中期看是供应链与量产能力竞赛长期看是数据闭环与安全体系竞赛。谁能在这些维度上持续迭代谁才有机会把“道阻且长”的终局走成“行则将至”。如果你此前还没有接触过机器人开发可以先从安装一个仿真环境、加载一个人形机器人模型开始跑通一次最简单的运动控制示例再逐步深入更复杂的强化学习策略。纸上得来终觉浅动手实践才是理解“车企造人”背后技术难度的最好方式。如果本文对你理解“车企造人”和具身智能的工程脉络有帮助可以收藏备用后续遇到相关技术细节也欢迎在评论区交流讨论。