把 Xiaomi-Robotics-U0 当成“技能包”接入，通常会失望：它统一的是从数据组织、训练编排到评测入口的合成流程与约定，而不是某一台机器人的抓取、插装或导航技能。判断能不能用，先核对三件事：表征约定是否覆盖你手上的观测与控制量，流程编排能否在你的训练环境跑通，接口边界是否与你的控制器和评测脚本对得上。这三件事都能通过配置文件、运行日志和一次小规模跑通来验证，不需要先相信任何结论。
建议把 U0 定位成“流程与表征的公共约定层”：先核对表征、流程、接口，再估适配成本。通常能直接复用的是数据组织方式、训练编排入口和评测骨架；任务目标、成功判据、异常处理仍需团队自己定义。凡未在配置项、日志字段或接口签名中体现的能力，一律记入待验证清单，不写进排期承诺。
把“统一”拆成表征、流程、接口三件可核对的事
拆开看，“统一”不是一句能力声明，而是三层可检查的约定。表征层决定观测和动作长什么样；流程层决定数据怎么进、训练怎么排、结果怎么出；接口层决定外部控制器和评测脚本怎么接进来。三者混在一起谈，就会出现“以为接上就能出技能，实际连数据格式都对不上”的落差。
| 事项 | 定义 | 可验证表现 | 常见误解 |
|---|---|---|---|
| 表征约定 | 观测项、动作项、单位、坐标系、时间对齐方式的统一定义 | 配置文件里能看到字段清单与单位说明；同一段数据能被流程解析且不报维度错误 | 以为统一表征等于统一了机器人本体，实际仍需按形态做映射 |
| 流程编排 | 数据处理、训练、评测各阶段的顺序、入口与产物落盘规则 | 按入口脚本顺序执行后，中间产物和日志可在固定目录找到 | 以为流程跑通等于效果达标，实际只说明链路可执行 |
| 接口边界 | 对外暴露的输入输出契约：状态输入、动作输出、评测调用方式 | 接口签名与字段在代码或文档中可见；用一条构造样例能走通调用 | 以为接口对齐就不用写适配层，实际单位与频率转换常落在自己这边 |
先分清哪些是外部给的约定、哪些要自己补。判断方法很直接：能在仓库配置或接口定义里读到的，属于给定部分；需要写映射表、转换函数、评测脚本的，属于自己要补的部分。补的部分越多，适配成本越高，这与模型本身是否“强”无关。
列出不同机器人形态的差异会落在哪些文件上
把工作量落到文件上，排期才有讨论基础。下面这张对照表里的文件名是通用骨架，实际名称按你的仓库替换，重点是差异最终会出现在哪一类配置里。
| 差异项 | 典型差异 | 对应配置位置 | 核对方式 |
|---|---|---|---|
| 关节数 | 自由度数量、关节名与顺序不同 | 机器人描述文件与关节映射表（如 robot_profile、joint_map 一类） | 加载后打印关节列表，与控制器实际顺序逐项比对 |
| 控制频率 | 控制周期与数据采样周期不一致 | 控制配置中的频率字段与时间戳对齐逻辑 | 跑一次空动作，检查日志中相邻时间戳间隔是否符合预期 |
| 传感器配置 | 相机数量、内外参、通道或话题名不同 | 传感器配置与观测映射表 | 逐路确认通道可读，且观测项数量与配置一致 |
| 末端执行器 | 夹爪开合范围、动作空间定义不同 | 动作空间定义与限幅配置 | 发送边界动作，检查是否被限幅且不报错 |
| 单位与坐标系 | 米/弧度约定、基座与工具坐标系方向不同 | 单位声明与坐标系变换配置 | 用已知位姿做一次正逆变换，检查回读误差方向 |
下面是一段可替换的配置骨架，用途是固定“形态差异写在哪”，不是官方格式。把它放在机器人类配置文件里，作为适配层的入口。
robot_profile:
name: your_robot
dof: 7 # 关节数，按实际填写
joint_order: [j1, j2, j3, j4, j5, j6, j7]
control_hz: 100 # 控制频率，按控制器实际能力填写
action_space: {type: joint_position, unit: rad}
sensors:
- {name: wrist_cam, channel: cam0, type: rgb}
observability:
obs_keys: [joint_pos, joint_vel, wrist_cam]
align: timestamp # 时间对齐方式，跑通后回读日志确认用一张任务定义表说明边界外的工作
统一流程不替你决定“什么算成功”。下面这张表建议由做任务的人填写，字段名可自定，填不出来往往说明任务本身还没想清楚。
| 字段 | 说明 | 示例填写（需按你的场景改写） |
|---|---|---|
| task_id | 任务唯一标识 | pick_place_block_v1 |
| 任务目标 | 一句话描述要达成的状态 | 把方块从托盘移到指定区域并松开 |
| 初始条件 | 允许的起始分布与干扰 | 方块位于托盘内，位姿随机 |
| 成功判据 | 可程序化判断的条件 | 方块中心落在目标区域内且夹爪张开 |
| 超时与终止 | 最长执行步数或时长 | 超过设定步数判为失败 |
| 异常处理 | 抓空、碰撞、超限时的处理 | 抓空重试一次，碰撞立即终止 |
| 验收口径 | 用哪个评测入口、统计哪些指标 | 固定初始条件集合，统计判据通过率与终止原因分布 |
验收口径要写清楚“在什么条件下统计什么”，否则同一套流程跑出来的结果无法互相比较。建议把初始条件集合固定下来，把终止原因一并记录，便于区分是策略问题还是执行层问题。
给出适配成本估算的输入项清单
估算不要从“感觉难不难”出发，从下面这些可取的输入项出发。每一项都写明取值来源，估算时把假设单独记录，后面才能复盘偏差来自哪里。
- 机器人形态：关节数、末端类型。来源：机器人描述文件与控制器手册。
- 观测与控制频率是否一致：来源：控制配置与一次空跑日志的时间戳间隔。
- 传感器路数与标定状态：来源：传感器配置文件与标定记录。
- 现有数据规格与目标表征的字段差异数量：来源：逐字段比对数据样例与表征定义。
- 接口适配代码量：来源：控制器现有接口签名与目标契约的字段差集。
- 评测脚本改造点：来源：现有评测入口与目标验收口径的对照。
- 异常与安全策略：来源：团队既有的急停、限幅、超时约定。
记录假设时建议用固定三列：假设内容、依据、若不成立的影响。例如“假设控制频率与控制配置一致，依据为控制器文档，若不成立需要增加重采样适配层”。这样排期被质疑时，可以指回具体假设，而不是争辩难度。
把不确定项单独记成待验证清单
方案里最容易出问题的地方，是把没核对过的能力写成已有能力。建议单开一张表，验证前不进入承诺范围。
| 待验证项 | 验证方式 | 验证失败时的替代路径 |
|---|---|---|
| 目标表征是否覆盖全部观测 | 用一条真实数据走解析，检查字段与维度 | 在适配层增加字段映射与转换 |
| 流程能否在本地环境跑通 | 按入口顺序执行到评测阶段，检查产物与日志 | 逐阶段定位失败点，必要时只复用数据组织部分 |
| 接口契约是否与控制器一致 | 构造样例请求完成一次调用并回读 | 编写薄适配层做单位与频率转换 |
| 评测入口能否对接现有脚本 | 用少量初始条件跑一遍并输出终止原因 | 自建评测脚本，只沿用任务定义与判据口径 |
| 异常处理是否被流程感知 | 注入超时与越界动作，检查日志是否记录 | 在适配层与执行层各自兜底，并统一记录字段 |
这张清单建议随方案一起更新：验证通过的项移出清单并注明验证方式，未通过的项保留替代路径。读者据此可以判断，U0 提供的是可复用的流程骨架，具体到某台机器人能做什么，仍然取决于你补上的映射、任务定义和验收口径。