如果你想把一台人形机器人从“能演示一次”推进到“能持续迭代、能定位问题、能比较版本、能交给团队协作开发”，你最该先补上的往往不是一个更炫的模型，而是一套可重复的测试工装。这篇文章面向正在搭建 humanoid 原型机、实验平台或子系统验证流程的团队，核心判断只有一句话：先把测试场景、通过标准、日志回放和失败分桶做扎实，再谈系统能力是否真的提升。
这篇适合谁
- 正在做人形机器人整机原型，希望建立稳定迭代流程的个人或小团队
- 已经有感知、规划、控制、执行器等模块，但每次联调都靠“现场看感觉”的开发者
- 想搭建 benchmark、回归测试、验收标准、版本对比流程的工程团队
- 准备从仿真走向实机，希望避免“每次改一点就不知道哪里退化了”的项目负责人
先纠正几个很常见的误区
误区 1：机器人能力强，测试自然就会好做
现实通常相反。能力越复杂，系统耦合越高，越需要把测试拆成可控的小单元。否则你会看到机器人“偶尔成功”，但完全不知道成功依赖了什么条件。
误区 2：多录几个 demo，就等于有了评测体系
demo 只能证明某一次成功发生过，不能证明系统稳定、不能比较版本、也不能帮助定位退化来源。评测体系的重点不是“展示最好结果”，而是“在同一标准下反复测”。
误区 3：只有大公司才需要 test harness
恰恰相反。团队越小，越需要把测试规则固化，否则知识全在个别工程师脑子里，一换人、一换硬件、一换场地，系统就重新变得不可控。
误区 4：等整机做得差不多了，再补测试
这是很常见的翻车点。等系统已经堆满历史包袱，再补测试，代价会比一开始高很多。更实际的做法是从最关键的 5 到 10 个任务开始，先搭最小可用测试工装。
关键实现判断：测试工装不是“附属品”，而是主系统的一部分
做人形机器人时，真正会吞掉时间的通常不是某个单点算法，而是以下这些问题：
- 同一个任务今天能过，明天不过
- 改了视觉后，抓取退化，但没人能快速复现
- 控制参数更新后，步态更稳还是更脆，没有量化证据
- 仿真表现很好，实机上线后异常大量增加
- 团队里每个人都说自己“感觉版本更好了”，但标准不一致
所以测试工装至少要回答四个问题：
- 你到底在测什么任务
- 什么叫通过，什么叫失败
- 失败后能不能复现和回放
- 新版本和旧版本能不能在同一条件下比较
如果这四件事没有固定下来，项目很容易长期停留在“经验驱动联调”阶段。
分步实践指南
第一步：先定义 3 层测试对象，不要一上来只测整机
比较稳妥的做法，是把测试分成三层：
- 模块层：相机标定、目标检测、抓取点生成、状态估计、关节跟踪、接触检测、语音理解等单模块测试
- 任务链路层：感知到规划、规划到执行、执行到确认的串联流程测试
- 整机场景层：在真实环境下执行完整任务，例如取放、开门、搬运、巡检、站起、避障、接管切换
很多团队的问题是只做第三层。结果一旦失败，就不知道问题来自感知、状态机、控制器、执行器还是环境变化。先把前两层补起来，后面的整机场景测试才有意义。
第二步：每个测试任务都要写清楚输入、动作、判定标准
一个可执行的 test case，至少应该包含：
- 任务名称，例如“从货架 A 取箱子并放入周转框”
- 初始条件，例如目标物位置范围、光照、起始姿态、地面条件
- 允许的感知输入和环境扰动范围
- 任务完成定义，例如是否抓起、是否放对位置、耗时上限、碰撞阈值、人工介入次数
- 失败判定，例如掉落、误抓、超时、越界、保护停机、状态丢失
不要把“工程师肉眼觉得差不多”当成通过标准。能量化的地方尽量量化，例如成功率、平均完成时间、最大关节温度、接触冲击峰值、重试次数、人工接管频次。
第三步：优先做“高频失败场景”，而不是平均场景
很多系统在理想条件下都能工作，真正拉开差距的是失败边界。所以测试集设计时，应该优先覆盖：
- 目标稍微偏位或姿态变化
- 背景杂乱、遮挡、反光、弱纹理
- 地面摩擦变化、坡度微变、软硬不一致
- 通信延迟、丢帧、传感器短时异常
- 执行器温升后性能衰减
- 任务执行中被人打断、重规划、接管恢复
这类场景更能逼出系统真实上限，也更适合用于版本回归。
第四步：把日志和视频回放当成最基本的测试资产
一套真正有用的测试工装，至少要保留以下记录：
- 传感器时间戳和同步状态
- 关键中间结果，例如检测框、目标 ID、地图状态、状态机节点、规划结果
- 控制输出、限幅、保护触发、错误码
- 任务级结果，例如成功、失败、超时、人工接管
- 第一视角或第三视角视频
如果失败发生后只能靠人回忆现场，那么这次失败基本等于白失败。你需要让任何一次关键异常都能被回放、复盘、分桶。
第五步：给失败做分桶，不要把所有失败都叫“没调好”
一个简单但非常实用的做法，是给失败建立固定分类：
- 感知失败：没看见、看错、跟丢、坐标漂移
- 规划失败：不可达、约束冲突、候选排序错误
- 控制失败：轨迹跟踪差、接触不稳、振荡、滑步
- 执行失败：夹爪打滑、电机保护、通信异常、动作中断
- 系统失败：状态机卡死、超时、模式切换错误、恢复逻辑失效
- 环境失败：测试布置变化、地面/光照超出假设、人为干扰
分桶之后，你才能知道下一周应该投资源补哪一层，而不是所有人一起盲调。
第六步：做版本对比时，先锁住环境和任务脚本
如果你今天用 A 场地、明天用 B 场地，今天测试 20 次、明天测试 5 次，今天是工程师甲操作、明天是工程师乙操作，那么所谓“版本提升”几乎没有统计意义。
更靠谱的做法是：
- 固定测试脚本和执行顺序
- 固定物体、位置范围、光照和地面条件
- 固定热机流程，例如先运行多久再开始正式测试
- 固定成功判定和人工接管规则
- 至少保留一组长期不变的回归基线任务
这样做的目的，不是追求绝对学术严谨，而是让工程判断尽量少被偶然条件污染。
第七步：仿真和实机要共用任务定义，但不要共用通过幻觉
仿真最大的价值，是更快地发现明显错误、做参数扫描、验证状态机和任务流程。但仿真最容易制造的错觉，是让团队高估系统已经准备好上实机。
更合理的做法是：
- 让仿真和实机尽量共用同一套任务描述、日志字段、成功判定结构
- 明确哪些指标只在仿真看，哪些必须在实机验
- 把 sim-to-real 差距本身作为一个被跟踪的指标
例如抓取任务里，仿真里成功率 95% 不代表实机就能接近这个水平。你更该关心的是：上实机后失败主要集中在哪一类，是否可以被日志直接解释。
一个够用的人形机器人测试工装，最少应包含什么
- 任务列表和 case 定义文档
- 可重复执行的测试脚本或操作清单
- 统一日志格式和事件编号
- 视频录制与关键帧标记
- 成功率、耗时、重试次数、人工接管次数等核心指标面板
- 失败分桶表和每周复盘节奏
- 至少一组固定的回归任务集
如果资源有限，不必一开始就做很复杂的平台。先把这几项最小化跑起来，价值已经很高。
最容易翻车的地方
- 只测成功率，不测恢复能力。 真实部署里，失败后的重试、回退、人工接管切换同样重要。
- 只看最终结果，不留中间状态。 这样出了问题几乎无法定位根因。
- 每次都临时改测试条件。 看起来灵活，实际上会让版本对比失真。
- 整机测试过多，模块测试过少。 团队会被联调噪声拖死。
- 把 benchmark 当宣传材料，而不是研发工具。 一旦测试目标变成“挑最漂亮的数据”，整套体系就会失真。
下一步怎么做
如果你现在还没有系统化测试流程，建议按这个顺序开始：
- 先选 1 个最关键任务和 3 个最常见失败场景
- 写清楚成功/失败判定
- 补齐日志、视频、错误码记录
- 建立失败分桶表
- 每次版本更新后固定跑一次回归
先把这 5 步跑顺，再扩展到更多任务。对大多数 humanoid 原型项目来说，这比继续堆更多“偶尔能成功”的 demo 更能提高研发效率。
延伸阅读方向
- 机器人 benchmark 设计方法
- 任务级评估与系统级评估的差异
- 多传感器日志同步与回放工具链
- 仿真到实机的一致性验证
- 面向安全与接管的异常分类方法