很多人看一台人形机器人样机，最先盯的是“像不像人”“动作顺不顺”“演示酷不酷”。但如果你真要把一台样机推进到下一阶段，真正该证明的不是这些，而是它能不能在明确任务边界内稳定重复、出错后可恢复、问题能复盘、版本切换后不退化。这篇文章解决的就是“人形机器人样机到底该证明什么”这个问题。它适合正在做原型机、二次开发平台、工位验证或部署前验收的团队。最关键的工程判断是：别把样机验证理解成一次 demo 成功，而要把它做成一套可重复的证据链。
这篇适合谁
- 已经做出基本行走、抓取、搬运、巡检或双臂操作能力，准备进入连续测试的人。
- 正在评估一台外购人形机器人平台，想知道“能演示”和“能接项目”到底差多远的人。
- 准备给团队、客户、合作方或内部决策层做样机阶段评审的人。
- 总觉得问题很多，却说不清到底该先补稳定性、日志、测试还是恢复链路的人。
先纠正几个很常见的误区
误区 1：样机能完成一次完整 demo，就说明核心能力已经成立
不对。一次 demo 最容易隐藏的问题，恰恰是部署里最致命的问题，比如传感器热漂、母线压降、临时重定位失败、夹持姿态累计偏差、人工干预后状态不一致、软件重启后任务上下文丢失。样机阶段最值钱的，不是最好的一次，而是第 20 次、第 50 次还能不能做对。
误区 2：只要模型更强，验证问题自然会消失
也不对。很多失败不是“智能不够”，而是接口契约不稳、状态机不清、日志不齐、控制和任务层边界模糊。你连失败发生在哪一层都说不清时，继续堆模型只会让问题更难定位。
误区 3：验证就是列一张成功率表
成功率当然要看，但单一成功率远远不够。你至少还要看连续运行时长、单次恢复耗时、失败是否可归类、回放能不能复现、版本切换后是否退化、异常情况下是否能安全降级。
关键实现判断：样机阶段真正要证明的 5 件事
- 任务边界清楚。 你必须能说清楚机器人在哪种场景、拿什么物体、接受什么干扰、允许什么人工介入。
- 链路可重复。 同一任务不是偶尔成功，而是在明确初始条件下重复成功。
- 失败可定位。 一旦翻车，团队能快速判断是感知、状态估计、规划、控制、执行器、通信，还是运维链路的问题。
- 恢复可执行。 不是“出问题了人工重来”，而是有明确的暂停、接管、回原点、重新同步、继续执行流程。
- 证据可沉淀。 每一轮验证都能留下可比较、可回放、可复查的数据，而不是靠现场印象做决策。
一台人形机器人样机值不值得继续投，不取决于它有没有做出最惊艳的一次动作，而取决于它有没有形成“任务定义 → 执行 → 失败归因 → 回放复盘 → 修复回归”的闭环。
分步实践指南：把“样机要证明什么”落成一套验证流程
第 1 步：先冻结你要证明的任务，不要先追求通用性
样机阶段最怕的，是演示内容一直变。今天搬箱子，明天整理台面，后天又换成开门，这样永远得不到有意义的证据。更稳的做法是先冻结 1 到 2 个代表性任务，给每个任务定义以下内容：
- 起始状态，比如机器人站位、物体位置、光照、台面高度。
- 成功标准，比如放置误差、节拍范围、是否允许二次调整。
- 允许干扰，比如轻微物体偏移、局部遮挡、操作者经过。
- 禁止条件，比如超力、失步、急停、越界、超时。
NIST 的 ARIAC 长期有一个很值得借鉴的思路，不是只看“能不能做任务”，而是把动态环境、扰动、任务规则和成功条件写得很清楚。对人形样机也一样，先把任务写清楚，后面的成功率才有意义。
第 2 步：把验证对象拆成 4 层，不要混着看
建议把样机验证拆成四层分别记录：
- 任务层： 任务是否完成，是否超时，是否需要人工确认。
- 行为层： 抓取、抬臂、转身、行走、放置、交接等子动作在哪一步失败。
- 系统层： 感知延迟、状态估计漂移、规划取消、控制饱和、总线错误、温升触发降额。
- 运维层： 是否告警、谁接管、恢复用了多久、是否需要重启或回零。
这一步决定了你后面能不能快速排错。很多团队表面上在做“验证”，实际上只记录一个最终成败，最后谁也说不清到底坏在什么地方。
第 3 步：先把日志和回放做扎实，再谈规模测试
样机阶段如果没有统一记录格式，测试轮次越多，信息损失越严重。一个很实用的做法，是统一把关键 topic、状态事件、动作请求、告警、人工接管记录到同一条回放链路里。ROS 2 现在已经能比较方便地直接记录为 MCAP，后续查看、转换和校验都更顺手。重点不是追求“记录所有东西”，而是先保证下面这些最关键的数据能对齐时间线：
- 任务开始、暂停、恢复、结束事件
- 感知输出和目标对象选择结果
- 状态估计、关键控制命令和接触/夹持状态
- 异常告警、急停、降级、人工接管记录
- 版本号、配置号、任务脚本版本
如果这条链路缺失，你看到的就只是“它刚才又失败了”；如果这条链路齐全，你才能回答“它为什么在这个版本、这个初始条件、这个延迟水平下失败了”。
第 4 步：给样机建立自动化回归，而不是靠人工盯演示
真正能节省团队时间的，不是多拍几个 demo，而是把最容易反复出问题的链路做成自动化回归。ROS 2 的 launch_testing 就很适合拿来做系统级集成测试，把多个节点一起拉起，验证接口交互、超时、退出码和关键信号是否符合预期。对人形机器人项目，它至少可以先覆盖这些内容：
- 任务下发后，状态机是否按预期切到执行态
- 关键感知节点缺失时，系统是否进入降级而不是继续盲动
- 人工接管触发后，自动控制链路是否正确释放
- 回放日志时，核心指标是否和上个稳定版本一致
如果你只靠现场看一遍，很多回归退化会被忽略。自动化回归的价值，不在于它像 demo 一样好看，而在于它能尽早发现“这次改动虽然修好了 A，却悄悄打坏了 B”。
第 5 步：故意设计“连续运行挑战”，别只做单轮成功率
样机到底靠不靠谱，连续运行最诚实。建议你至少设计三类挑战：
- 重复挑战： 同一任务连续执行 20 到 50 轮，看成功率和节拍漂移。
- 扰动挑战： 在小范围内改变物体摆放、起始姿态、照明、网络抖动，观察鲁棒性。
- 恢复挑战： 人为插入暂停、感知丢失、临时接管、电源波动或节点重启，验证恢复路径。
像 Isaac Lab 近年的一些闭环评测任务，就很强调“标准任务 + 明确成功条件 + 可重复 benchmark”的组合，而不是只展示一条最顺的视频。对人形样机来说，这种思路尤其重要，因为你要证明的是能不能被工程团队稳定复现。
第 6 步：把失败桶定义出来，避免每次开会都重新解释一遍
建议最少建立一版失败桶：
- 感知失败，没看到、看错、坐标漂了。
- 状态估计失败，身体位姿、接触、抓持状态判断不准。
- 规划失败，动作序列不成立、约束没满足、重规划超时。
- 控制执行失败，轨迹跟踪差、关节饱和、温升降额、夹持滑脱。
- 系统工程失败，节点重启、消息超时、版本不兼容、配置漂移。
- 运维流程失败，告警太晚、接管不顺、恢复不完整、证据缺失。
失败桶的作用，不只是复盘好看，而是帮助你决定下一周该投哪里。是补标定流程、补夹具设计、补日志字段，还是补恢复状态机，这些都要靠失败分类来决定。
第 7 步：给样机设一个“升级门槛”，不过门槛就别急着扩大场景
一个实用的门槛示例是：
- 固定场景 30 轮连续执行成功率达到目标线。
- 关键失败都能归入已有失败桶，且没有大量“未知原因”。
- 随机抽样失败 case 可以完成日志回放和问题定位。
- 人工接管后能在规定时间内恢复任务或安全退出。
- 新版本上线前，自动化回归不过线就不进入现场测试。
这类门槛看起来保守，但它能防止团队被“今天拍出来一个很好的视频”带偏。样机真正的升级依据，应该是证据密度，不是情绪热度。
最容易翻车的地方
- 任务定义经常改。 这样你永远分不清是系统变强了，还是题目变简单了。
- 只记最终结果，不记过程状态。 最终只会得到一堆“偶发问题”。
- 日志时间线对不齐。 感知、控制、运维记录各写各的，复盘时无法串起来。
- 恢复流程靠最熟练的工程师临场发挥。 人一换班，系统就不会恢复了。
- 回归测试只测快乐路径。 真正的退化常常出在异常路径和降级路径。
- 过早扩大场景。 固定工位都还没稳定，就急着去更复杂环境，只会把问题叠起来。
怎么验证你真的搭对了
如果下面大多数问题你都能正面回答，说明这套样机验证框架已经开始成型：
- 你能否用一页文档讲清楚当前样机到底在证明哪 1 到 2 个任务？
- 同一任务连续执行时，你能否同时给出成功率、平均耗时、恢复耗时和主要失败桶分布？
- 随机抽一条失败 case，你能否在回放里看到任务事件、感知结果、控制命令和接管记录？
- 系统改了一个节点或一个模型后，你是否有自动化方式确认没有打坏已有流程？
- 遇到传感器缺失、网络波动或人工接管时，机器人是否会进入明确降级，而不是输出不可预测行为？
如果这些还做不到，别急着问“这台机器人离量产还有多远”，先把样机阶段最基本的证据链补齐。
下一步怎么做
- 先选一个最重要的任务，把成功标准和禁止条件写成文档。
- 补齐统一日志，把任务事件、控制、异常和接管对到同一时间线。
- 挑 3 类最常见失败，先把失败桶和恢复流程写出来。
- 把最关键的一条流程做成自动化回归，而不是靠人肉看 demo。
- 等固定任务稳定以后，再扩大场景、增加扰动和提高节拍要求。