具身智能这个词最近频繁出现在机器人、自动驾驶、AI 基础设施、智能制造等话题里。落到工程现场真正的问题不是“实验室里能不能跑通一个机械臂抓取 demo”而是“一套模型方案能不能从实验室搬到仓库、车间、家庭并在几十台甚至几百台设备上保持一致的表现”。规模化落地和 demo 的最大区别就在这里模型要可复用、可部署、可回退、可观测。讨论具身智能“大概率从这样的模型开始”不是在押注某一家公司的某一个大模型而是在梳理模型的形态、分层、数据、部署和运维成本之后发现最先具备落地条件的往往是任务边界清晰、数据闭环完整、推理成本可控的分层模型而不是一开始就追求全能的端到端大模型。1. 先想清楚具身智能规模化落地模型要解决什么真实问题1.1 从 demo 到规模化模型面临四个变化实验室里的机械臂抓取 demo通常只需要在一个固定台上面对固定物体、固定光照、固定背景模型反复训练同一个任务。只要成功率超过 80%就可以录制视频。但规模化落地之后模型面对的是完全不同的环境第一运行环境从固定实验台变成多场景。同一个抓取模型上午在仓库 A 的货架上下午可能在仓库 B 的传送带旁。光照、遮挡、相机角度、物体摆放方式都在变化。第二输入从干净数据变成噪声数据。真实场景里的传感器会出现抖动、模糊、反光、延迟、丢帧。第三输出从单个动作变成完整任务闭环。模型不仅要识别“杯子在哪里”还要把“把杯子放到托盘”变成一条可执行的动作序列并处理执行过程中的失败重试。第四迭代从离线重训变成在线数据回流。设备部署后每天会产生大量真实轨迹数据这些数据如果不能回流到训练集模型就永远是发布时的样子无法适应现场变化。这些变化的本质是模型不能只追求“准确率”还要追求“可维护性”。一台设备上的模型出了问题团队要能快速定位是感知层、决策层还是控制层的问题现场新增了一个物体团队要能快速补充数据并发布新版本。如果一开始就把所有能力塞进一个不可拆分的端到端大模型这些问题都会被放大。1.2 四类模型路线端到端 VLA、模块化、世界模型、蒸馏小模型具身智能领域的模型路线并不只有一条。常见的选择可以分成四类端到端视觉语言动作模型一般称为 VLA输入摄像头图像和语言指令直接输出动作或动作 token。它的优势是模型可以自动学习“看到什么、听懂什么、该做什么”之间的联合表示泛化上限高劣势是数据需求极大训练成本高出问题时很难定位是哪一层产生了错误。模块化感知-规划-控制路线把系统拆成感知模型、决策模型、控制模型每个模块独立训练、独立推理、独立替换。感知模型负责输出目标检测、分割、位姿决策模型负责根据任务生成动作序列控制模型负责把动作序列映射成机器人真实关节指令或底盘速度。它的可解释性好工程调试方便数据需求也更分散是目前工业场景里最常见、也最容易先跑通的一条路线。世界模型路线目标是让模型学习环境的动态变化规律能预测“执行动作 A 之后世界会变成什么样”。它在仿真、规划、数据增强中很有价值但直接用于真实机器人控制时环境建模误差会被放大周期较长。蒸馏和量化后的小模型路线通常是前面几种模型的端侧压缩形态。用教师模型指导小模型训练再通过 INT8 量化、通道剪枝等方式降低算力需求适合部署到树莓派、Jetson、嵌入式平台。四类模型路线并不互斥实际项目里经常是混合使用。先有一个模块化系统作主干再逐步把高频、稳定的子任务改造成端到端模型最后将端到端模型蒸馏成端侧可运行的小模型。1.3 为什么优先选择“任务解耦的分层模型”从规模化落地的角度看第一版模型大概率不是大而全的 VLA而是任务解耦的分层模型。原因有三个第一数据获取成本可控。端到端 VLA 需要大量“图像 指令 动作”的配对轨迹数据这类数据在机器人场景里并不像互联网文本那样随处可得。分层模型可以把数据需求拆开感知层只需要目标标注数据决策层只需要任务序列数据控制层只需要运动轨迹数据。即使某个模块缺数据也可以单独补采不用整个系统重训。第二安全边界可以精确控制。分层模型里控制层和独立安全模块能够对最终执行指令做硬校验比如速度限制、力矩限制、关节角限制。如果模型输出一个越界动作安全层可以拦截。端到端模型直接把像素映射到动作一旦模型错误输出一个极端关节角度往往只能靠外部限位保护安全冗余更少。第三线上排障效率高。真机执行出错时分层模型可以直接对比感知输出、决策输出、控制输出判断是“没看见”“理解错”还是“动作映射错”。端到端模型只能看到输入和输出很难定位中间状态。当然分层模型也有代价模块间信息传递会损失上下文系统整体延迟更高每个模块的误差会累积。因此推荐的做法是“先分层跑通再选择高频稳定的子任务逐步端到端化”。2. 最小可运行架构从感知、决策到控制的模型链路2.1 三层模型链路的设计目标这里给出一个最小可运行的具身智能模型链路它适合学习验证也适合作为早期产品原型。系统分成四部分感知层负责从视觉输入中检测物体、判断物体类别和位置决策层负责把自然语言指令和感知结果转换成动作序列控制层负责把动作序列转成机器人可执行的速度或关节指令安全模块负责在控制层执行前校验速度、力矩、边界位置。这个设计目标不是“一次完成复杂任务”而是先保证一条链路的每个环节都可验证。感知层单独测试时只看检测结果决策层单独测试时输入固定的物体列表看它输出的动作序列是否合理控制层单独测试时输入固定动作看机器人是否按照预期运动。所有问题都能被隔离在某一层。2.2 环境准备环境准备方面并不需要一开始就买昂贵的工业机械臂。学习阶段可以用一台笔记本、一个 USB 摄像头、一台树莓派或 Jetson 设备再加一台小型机械臂或移动底盘。软件环境建议如下操作系统Ubuntu 22.04 或更新版本Python3.10 或 3.11深度学习框架PyTorch 2.x版本以项目实际依赖为准机器人通信ROS 2 Humble或直接用 Socket / WebSocket 自建通信部署目标树莓派 4B/5、Jetson Orin Nano或一台带 GPU 的边缘服务器。这里的版本不是绝对要求关键是先确认每个组件的兼容性。比如 PyTorch 版本、CUDA 版本、机器人 SDK 版本必须匹配否则后面部署时会出现“模型能训练但服务起不来”这类问题。2.3 项目结构一个可复现的分层项目目录结构可以这样组织embodied_robot/ ├── perception │ ├── detector.py │ └── config.yaml ├── decision │ ├── planner.py │ └── prompts.py ├── control │ ├── robot_interface.py │ └── safety.py ├── data │ ├── collect.py │ └── clean.py ├── deploy │ ├── server.py │ └── edge_client.py └── eval └── evaluate.py这个结构的核心逻辑是每一层目录只依赖自己所属的接口不跨层调用内部细节。感知层输出 JSON决策层接收 JSON控制层接收动作字典。层与层之间只通过标准数据结构通信这为后续替换模型提供了基础。2.4 感知层先输出结构化目标不直接透传图像感知层通常部署在机器人侧或边缘服务器上。代码如下import cv2 import numpy as np def detect_objects(frame, detector, target_classes): # detector 可以是 YOLO、DETR 或任意目标检测模型 results detector(frame) targets [] for det in results: label det[label] if label not in target_classes: continue targets.append({ label: label, bbox: det[bbox], score: float(det[score]), }) return targets感知层的关键不只是“检测出来”而是输出一个结构化结果。上层决策模型不需要看原始图像只需要看“哪个物体在哪个位置”。这样做能降低通信带宽也能让决策模型更容易对齐语言指令和视觉目标。这里要注意不要把感知层写成“把图片发到云端模型再把结果拿回来”的长同步调用。真实机器人场景里感知层最好是本地模型优先云端模型兜底。否则网络抖动一次机器人就会停在原地。2.5 决策层把语言指令变成动作序列决策层负责把人类指令转换成机器人可执行的动作序列。这里可以使用一个大语言模型或视觉语言模型但最好让模型输出结构化 JSON而不是自然语言。import json def plan_action(user_command, detected_objects): prompt build_prompt(user_command, detected_objects) plan_text llm_client.complete(prompt) try: actions json.loads(plan_text) except json.JSONDecodeError: # 结构化解析失败需要走重试或降级策略 raise RuntimeError(decision model output is not valid json) return actions[steps]对应的 prompt 模板可以设计成这样你是一个机器人任务规划器。 当前场景中检测到的物体如下 - red_cup: bbox center (0.5, 0.3) - blue_box: bbox center (0.7, -0.2) 用户指令把红色杯子放到右侧托盘。 请输出 JSON 动作序列格式如下 { steps: [ {action: move_to, target: red_cup, pose: [0.5, 0.3, 0.1]}, {action: grasp}, {action: move_to, target: tray, pose: [0.8, -0.3, 0.15]}, {action: release} ] }决策层输出的动作序列表示“想去哪里、做什么动作”但不关心机械臂每个关节转多少度。关节级运动规划交给控制层完成。这样设计的好处是即使换个机器人品牌决策层完全不用改。2.6 控制层把动作序列变成真实机器人指令控制层是连接决策模型和机器人硬件的最后一环。它接收动作字典调用机器人 SDK并在执行前经过安全模块校验。def execute_action(action, robot, safety): if not safety.verify(action): raise RuntimeError(action rejected by safety: {}.format(action)) if action[action] move_to: robot.move_to_pose(action[pose]) elif action[action] grasp: robot.gripper(True) elif action[action] release: robot.gripper(False) else: raise ValueError(unsupported action: {}.format(action[action]))这里的move_to_pose可以用 ROS 2 的MoveGroup接口也可以直接通过 TCP 发送到机械臂控制器。安全模块至少要检查三件事目标位置是否在机械臂工作空间内、速度是否超过阈值、夹爪动作是否与当前状态冲突。2.7 为什么这样设计可回退、可单测、可替换分层设计最直接的收益是“可回退”。假设现场发现“物体识别正确但机器人去错了位置”问题大概率在决策层的 pose 生成或控制层的坐标变换而感知层不用碰。再假设“物体识别漏检”那就只需要补感知层训练数据不需要重训大模型。学习阶段最容易犯的错误是跳过控制层直接在模型输出后拼一个机械臂 SDK 调用。看起来代码更少但一旦坐标系、单位、机械臂状态不一致问题会非常难排查。分层虽然多了一层数据结构转换但换来的是每一层都能独立验证。3. 边缘设备部署算力选型、模型压缩与推理后端3.1 树莓派到底选 4G 还是 8G“具身智能小车树莓派需要 4G 还是 8G”这个问题不能只回答“内存越大越好”。判断标准是你要在边缘端跑什么模型以及这些模型对内存的占用有多少。如果只跑传感器采集、灯控、简单的 PID 控制4G 足够。但加载一个量化后的目标检测模型再叠加机器人 SDK、ROS 节点、摄像头缓存内存很快就见底。实践中内存不足时系统不会直接报错而是表现为进程被杀、ROSCore 重启、树莓派假死。方案内存可运行模型示例适用场景注意事项树莓派 4B 4G4GBYOLOv8n 量化、MobileNet学习、传感器数据采集、简单控制内存紧张进程容易被 OOM Killer 杀掉树莓派 5 8G8GBYOLOv8s 半精度、小型 VLM学习、轻度产品原型发热明显需要主动散热Jetson Orin Nano8GB / 16GBYOLOv8m 量化、小型 VLA边缘产品原型、量产试点开发生态更接近 GPU 环境如果预算允许学习阶段直接选 8G 内存版本可以少踩很多坑。但不要认为换了 8G 就能运行未经压缩的端到端模型。真实瓶颈往往不只是内存还有 CPU 算力和内存带宽。3.2 模型压缩蒸馏、量化、剪枝怎么配合边缘设备通常无法运行一个大模型模型压缩是绕不开的环节。常用的三个手段分别是知识蒸馏、量化和剪枝。知识蒸馏的核心思路是让大模型当教师小模型当学生。小模型不仅要学习真实标签还要学习教师模型的输出概率分布。代码示意# 知识蒸馏损失示意 import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, labels, alpha0.5, temperature3.0): hard_loss F.cross_entropy(student_logits, labels) soft_loss F.kl_div( F.log_softmax(student_logits / temperature, dim-1), F.softmax(teacher_logits / temperature, dim-1), reductionbatchmean, ) return hard_loss alpha * temperature * temperature * soft_loss量化是把 FP32 权重转成 INT8 或 INT4降低模型体积和推理耗时。INT8 量化通常对精度影响较小INT4 则需要在精度和速度之间做取舍。剪枝是去掉模型中不重要的通道或注意力头可以减少计算量但需要重新微调。实际项目里推荐顺序是先蒸馏再剪枝最后量化。每一步都要重新跑评估集不能只看模型体积下降还要看任务完成率是否可接受。3.3 推理后端选择vLLM 不是所有模型都适合关于“昇腾 910B-A2 服务器上不能通过 vLLM 启动 embedding 向量和 reranker 模型”这个问题在具身智能的模型部署中同样存在。vLLM 主要面向 decoder-only 文本生成模型做了高度优化对 embedding 模型、reranker 模型的支持取决于具体版本和硬件插件。在一部分国产加速卡环境中直接通过 vLLM 启动向量模型会遇到算子不支持、启动失败或推理结果异常。原因不是“模型坏了”而是模型类型和推理后端不匹配。embedding 模型输出的是向量reranker 模型输出的是相关性分数它们的执行逻辑和生成模型不同。处理方式应该是遇到不支持的情况不要强行用 vLLM 硬扛embedding 和 reranker 拆成独立服务使用向量模型专用的推理后端在国产加速卡环境里优先确认推理框架是否提供对应硬件适配如果必须自建服务可以考虑 ONNX Runtime 或专用推理 SDK并把模型导出为对应格式。这样拆开之后生成模型、向量模型、reranker 模型各用最合适的推理服务维护时才不会互相拖累。3.4 端侧缓存与模型增量更新边缘设备上一旦部署模型就必然面临“模型需要更新”的问题。推荐在端侧设计一套模型版本目录models/ ├── perception_v1.2.0.onnx ├── perception_v1.3.0.onnx ├── decision_v0.9.0.json └── safety_rules_v1.0.0.yaml每次启动服务时服务只加载配置文件中指定的版本。发布新版本时先下载模型文件到本地临时目录做哈希校验再原子替换。不要在运行过程中直接覆盖正在被加载的模型文件否则会出现“模型加载一半进程崩溃”的情况。端侧还应保留“失败样本回传”通道。当安全模块拦截了异常动作或者任务执行失败时把当次的输入、输出、日志打包成一条样本回传到中心服务器。这是数据闭环最重要的来源之一。4. 数据闭环仿真、遥操作、清洗与评估4.1 数据从哪里来仿真采集和真实数据缺一不可具身智能模型不能只用公开数据集训练。真实机器人数据采集成本高、速度慢而且不同设备之间存在差异。常见的数据来源有四种仿真环境生成比如 Isaac Sim、MuJoCo、Gazebo遥操作采集操作员使用示教器、VR 手柄或空间鼠标控制机器人完成动作记录轨迹真实传感器日志回流设备上线后自动记录任务执行过程中的图像、指令、动作和控制反馈人工标注增强对不完整样本补充标签或修正动作序列。仿真数据量可以很大但和真实环境存在 sim-to-real gap。真实数据准确、贴近现场但规模有限。一个好的数据策略是“仿真数据做预训练真实数据做微调”并在仿真中引入光照、纹理、摄像机位姿上的随机化防止模型只记住仿真场景特征。4.2 数据清洗不是过滤越狠越好数据清洗的目标是去掉“把模型带偏”的样本而不是追求数据总量最大。常见的清洗规则包括时间戳对齐保证图像、控制指令、关节反馈来自同一时刻过滤机械臂低速抖动段避免模型学到无意义的微动过滤动作信息缺失帧防止行为克隆时学到一个空动作校验指令和动作序列是否匹配去掉重复度过高的轨迹保留多样性。一个简单的清洗示例def clean_trajectory(records, min_duration1.0, max_jerk10.0): cleaned [] for rec in records: if rec[duration] min_duration: continue if rec[max_jerk] max_jerk: continue if len(rec[actions]) ! rec[expected_action_count]: continue cleaned.append(rec) return cleaned注意清洗规则过多会把困难样本全部删掉导致模型在简单样本上表现很好、一到真实工况就失灵。保留一部分“难例”是必要的。4.3 数据版本管理模型可复现的前提模型训练必须关联到具体数据版本。否则复盘时会出现“同样的代码为什么这次训练效果好上次效果差”的问题。团队至少要做三件事每次采集数据后生成数据清单记录时间、场景、设备编号训练时把数据版本写入模型训练日志使用 DVC 或对象存储管理大规模数据集模型评估时能准确回到对应数据版本。学习阶段哪怕只用一个目录也要在文件名里保留日期和采集来源例如20250115_warehouse_pick_clean.csv。4.4 评估指标任务完成率、效率和安全评估具身智能模型不能只看“检测 mAP”或“语言模型准确率”。要围绕任务闭环设计指标指标计算方式说明任务完成率成功次数 / 总尝试次数核心指标反映模型能否完成任务平均完成步数成功任务的总步数 / 成功次数反映执行效率步数越少越好安全触发次数安全模块拦截次数越低越好同时也要关注拦截是否正确单次推理耗时感知 决策 控制总耗时影响生产节拍超时会导致任务失败真机与仿真差距真机成功率 - 仿真成功率反映 sim-to-real gap离线评估通过日志回放完成真机评估要安排固定场景和随机场景两组。固定场景验证模型没有退化随机场景验证模型泛化能力。5. 规模化落地前要解决的五个工程问题5.1 安全兜底不能只靠模型具身智能系统里模型输出只是“建议”不能当作最终执行值。控制层必须叠加独立于模型的安全规则。规则来自机器人硬件限制和现场环境而不是模型训练出来的概率。一个最小安全校验模块不需要复杂class Safety: def __init__(self, workspace, max_speed, max_joint): self.workspace workspace self.max_speed max_speed self.max_joint max_joint def verify(self, action): if action[action] move_to: pose action[pose] if not self.workspace.contains(pose): return False if self._speed_exceeds(action): return False return True安全规则、限位开关、急停按钮应该同时存在。模型可以不断升级但安全兜底要始终独立于模型迭代。5.2 影子模式与灰度发布大规模部署时不能直接在真机上运行新模型。推荐用影子模式新模型和旧模型同时接收输入但只有旧模型的输出会真正执行新模型输出被记录下来用于评估效果。影子模式通过后再进入灰度发布。灰度策略可以参考灰度阶段设备比例验证重点50 台以内10%模型稳定性、安全触发率100 台以内30%任务完成率、平均步数全量100%运维指标、成本指标每一阶段都必须有退出开关。如果发现新模型任务完成率显著下降要能立即回退到旧版本。5.3 模型路由与多模型调度具身智能场景里一个单一模型很难覆盖所有任务。更现实的方案是维护一组“专才模型”再通过一个路由层决定当前任务交给哪个模型。{ task: 捡起地面螺丝, intent: pick_industrial_part, model: pick_v2.1, fallback_model: pick_v1.9, params: { target_class: screw, max_height: 0.3 } }路由可以由规则触发也可以由一个轻量级意图分类模型触发。模型融合不是把多个模型参数平均而是用统一调度层管理它们的输入输出格式、模型版本、依赖资源。5.4 运维可观测性日志要能还原现场具身智能运维工程师日常最需要的能力是“通过日志还原现场”。每条任务日志至少包含以下字段{ timestamp: 2025-06-01T10:00:00.123Z, device_id: robot_001, task_id: task_889, model_versions: { perception: v1.3.0, decision: v0.9.0 }, user_command: 把红色杯子放到托盘, perception_output: [{label: red_cup, bbox: [0.5, 0.3]}], action_sequence: [{action: move_to, pose: [0.5, 0.3, 0.1]}], safety_triggered: false, task_success: true, latency_ms: 340 }日志字段不要随意改。一旦线上问题发生缺少版本号或缺少感知中间结果排查会直接卡住。5.5 成本模型单台设备要算清楚账规模化落地必须回答“每台设备每月的模型成本是多少”。需要纳入计算的成本包括训练成本包括算力资源、数据标注、人工核对推理成本边缘设备折旧、云端 GPU 调用费数据回传和存储成本运维人力成本现场调试、日志分析、版本发布。如果你计划用云端大模型作为决策层还要估算每台设备每天的 token 消耗。高频控制任务更适合端侧小模型低频复杂任务才交给云端大模型。成本模型做不清楚模型再好也很难规模化。6. 常见问题排查从现象倒推根因6.1 树莓派跑模型卡死或进程被杀现象树莓派运行目标检测模型和 ROS 节点后系统卡顿模型进程被终止。可能原因内存不足OOM Killer 杀掉了进程或 CPU 过热降频推理速度骤降。排查方式执行free -h查看内存余量执行dmesg | grep -i oom查看是否出现 OOM 记录执行vcgencmd measure_temp查看温度。解决方案换 8G 内存版本使用 INT8 量化模型关闭不必要桌面服务增加 swap 但注意不要长期依赖。6.2 本地模型下载慢或下载失败现象下载开源模型权重时速度慢长时间卡在某个文件。可能原因网络链路不稳定、源站点响应慢、模型文件过大。排查方式查看下载日志确认卡在哪个文件测试目标站点连通性检查磁盘剩余空间。解决方案优先使用官方客户端或镜像源在服务端提前下载离线包公司内网建立模型缓存仓库。不要从来源不明的第三方链接下载权重文件完整性无法保证。6.3 昇腾 910B-A2 上 vLLM 无法启动 embedding 和 reranker现象通过 vLLM 启动向量模型或 reranker 模型时报算子不支持或启动失败。可能原因vLLM 对向量模型、reranker 模型支持不足当前后端没有对应硬件算子。排查方式查看启动日志中的算子报错确认模型格式确认 vLLM 版本和硬件适配情况。解决方案不要把 embedding 和 reranker 塞进文本生成服务拆成独立向量服务选择与硬件匹配的推理后端如果用 ONNX Runtime需要先验证算子兼容性。6.4 机械臂识别正确但动作不对现象感知层已经检测到目标决策层也生成了动作但机械臂没有运动到预期位置。可能原因坐标系不一致、单位不一致、机械臂型号配置错误。排查方式打印感知坐标、决策层 pose、控制层最终下发数据逐层对比检查相机坐标系到机械臂基座坐标系的变换矩阵确认单位是米还是毫米。解决方案统一所有层使用机器人基座坐标系单位统一为米在控制层增加变换验证点输出最终目标坐标。6.5 数据清洗后模型效果反而变差现象清洗完数据、重训模型后评估指标下降。可能原因清洗规则过强删掉了困难样本正负样本比例失衡数据版本回退错误。排查方式对比清洗前后的样本数量、类别分布查看训练数据版本用清洗前的随机子集重新训练做对照实验。解决方案清洗规则逐步加严每一步都记录删除了多少样本保留一份未清洗数据用于对照实验不要一次性执行过多规则。7. 具身智能学习路线从模型基础到机器人系统7.1 一条可执行的学习路径具身智能涉及面很广从模型到机器人硬件到部署运维很难一步到位。推荐按下面的阶段推进阶段核心内容学习产出物Python 与 Linux语言基础、调试、脚本能写数据处理脚本机器学习和深度学习损失函数、反向传播、卷积、Transformer完成一个图像分类或回归小项目视觉模型YOLO、DETR、CLIP、SAM完成目标检测和分割任务大模型基础LLM、VLM、Prompt 工程完成一个指令解析服务机器人系统ROS 2、运动规划、PID、机械臂控制让机械臂完成固定动作具身智能项目VLA、模仿学习、数据闭环、边缘部署完成一个抓取或导航小任务学习时不要同时铺开太多方向。第一个项目建议做“用摄像头识别物体用机械臂抓取指定物体”虽然看起来很小但它覆盖了感知、决策、控制、部署、排错全链路。7.2 面试和团队协作中更看重什么在具身智能相关岗位的交流中面试官大概率不会只问“Transformer 的注意力机制怎么写”而是会关注下面几个工程问题你如何获取和清洗训练数据模型在真机上失败一次后你怎么定位问题端侧算力不足时你会怎么压缩模型你如何验证模型上线后没有退化。这些问题的核心不是背诵论文而是说明你能不能把模型放入一个可运行、可维护、可回退的系统中。7.3 发布前检查清单任何具身智能模型版本上线前建议至少确认下面这些项任务场景是否明确 评估集是否和发布场景一致 是否经过影子模式验证 安全规则是否独立于模型 日志是否记录模型版本和中间输出 端侧是否有旧版本回退路径 是否统计过单设备推理成本 新模型是否对异常输入有兜底策略这张清单可以贴在项目文档里每次发布前逐条核对。它不能保证模型一定成功但能避免很多低级失误。8. 落地建议第一版模型应该怎么选8.1 先选窄场景再谈通用能力具身智能规模化落地第一版不要试图“让机器人在任意场景完成任意任务”。更稳妥的做法是选一个明确、可验收、有数据来源的窄场景比如“仓库固定区域捡拾螺丝”“家庭桌面整理指定物品”。窄场景不代表模型简单而是让团队能把数据、评估、部署、运维整个链路打通。链路通了场景再扩只是不断加数据和模型切换的问题。8.2 用分层系统保底用端到端模型探索上限团队可以从分层模型开始保证产品能上线、问题能定位。当某个子任务积累了大量数据比如“从货架抓取指定盒子”可以训练一个专门的端到端 VLA 模型替代原来的感知-决策拼接并在影子模式中验证它是否优于原链路。这样既控制了整体风险也能逐步提升模型能力上限。8.3 为每一台设备建立数据账户每个真实场景的分布都不一样。一台仓库机器人的数据很可能不能直接用于另一台餐厅机器人。建议按设备编号或场景类型切分数据集在模型训练时记录“用哪些设备的数据训练、在哪些设备上评估”。设备数据回流后定期重训一小部分模型参数能让模型更贴合现场。8.4 安全与回退永远优先于模型性能具身智能模型输出的是物理世界中的真实动作一次错误判断可能造成设备损坏或人员受伤。所以无论模型能力多强安全规则、限位保护、急停机制都不能省略。新模型上线前至少要保证“模型失效时系统能安全停住”。从第一版分层模型到后面逐步引入端到端模型这是一条比较稳妥的落地路径。它不是最快的路线但它是数据、调试、运维和安全成本都相对可控的路线。具身智能要规模化本质上是让模型在真实环境中长期稳定运行而不是在一次 demo 中表现惊艳。