很多团队做 humanoid 时，一上来就把注意力放在“要不要抢一个明星科学家”上，但真正决定项目能不能往前走的，往往不是头衔，而是有没有把系统负责人、数据采集、验证回放和现场问题闭环先搭起来。这篇文章想解决的就是这个问题：如果你准备做一支能把 humanoid 从 demo 推到可复现迭代的团队，第一批关键岗位应该怎么排，模块边界怎么划，怎么判断团队配置是不是已经能支撑真实开发。
这篇适合谁
- 正在组建 humanoid 创业团队、实验室平台团队或企业内部机器人专项组的人
- 已经有机械、电控或算法成员，但项目推进总被“谁来收口”卡住的人
- 想把遥操作、数据采集、训练、验证、上线维护连成一条闭环，而不是停在零散 demo 的团队
先纠正几个很常见的误区
- 误区 1：先招最强模型研究员，其他岗位后面再补。
如果你的机器人还没有稳定的观测、动作接口、日志回放和失败复现路径，再强的模型人也只能在不稳定地基上反复试错。 - 误区 2：机械、控制、AI、软件各干各的，最后自然能拼起来。
humanoid 的难点恰恰在接口处。没有明确系统负责人，问题会永远在“是传感器不稳”“是控制太激进”“是策略不会用”之间踢来踢去。 - 误区 3：能录数据就行，数据团队可以后补。
很多项目不是缺数据量，而是缺可复用的数据结构、统一 episode 边界、失败标签和回放证据链。 - 误区 4：测试和运维是上线前再考虑的事。
如果验证岗位太晚介入，团队前期每次演示成功都像一次性运气，后面很难积累成稳定能力。
关键实现判断
对大多数早期 humanoid 团队来说，第一优先级通常不是抢一个最耀眼的头衔，而是尽快形成下面四条闭环：
1）任务定义与系统收口闭环；2）遥操作与数据采集闭环；3）日志回放与问题复现闭环；4）验证准入与版本回退闭环。
这四条闭环不通，团队规模越大，返工越多。
分步实践指南：第一批关键岗位怎么排
第 1 步，先定目标任务，再定岗位，不要反过来
先写清楚机器人未来 3 到 6 个月只做哪 1 到 2 类任务，比如料箱搬运、双手分拣、工具递送、门把操作或家庭收纳。没有任务边界，招聘就会变成抽象许愿。
这一步至少要产出 4 个东西：任务脚本、成功标准、失败桶、人工接管点。之后每个岗位都围绕这 4 个对象展开，而不是围绕“我们也想做通用智能”展开。
第 2 步，最先补的是系统负责人，不是职能最炫的人
系统负责人不一定是最会写模型的人，但必须能跨机械、电控、感知、控制和任务层做取舍，明确接口冻结点，知道今天该修控制抖动还是先补标定，知道什么问题该进硬件迭代，什么问题该进数据回流。
如果没有这个角色，团队常见症状是：
- 每个人都很忙，但没人能回答“为什么这个任务今天还不稳定”
- 版本很多，但没有一条清楚的回归主线
- 每次演示前都在手工调参，演示后无法复现
这个角色本质上是项目的“系统裁判”，不是行政管理岗。早期最好让他直接拥有任务定义、接口边界和回归门槛的最后拍板权。
第 3 步，尽早补齐遥操作与数据基础设施
如果你要做操作型 humanoid，遥操作不是“过渡手段”，而是前期最重要的数据入口之一。LeRobot 把机器人控制接口和数据集格式分开，统一了 robot interface、state/action 记录和训练入口，这种做法很值得借鉴。它的价值不在某个具体模型，而在于让硬件、采集、训练三类人可以围绕同一份数据契约协作，而不是每人维护一套私有格式。
Open-TeleVision 更进一步，强调沉浸式主动视觉反馈对高质量示教的重要性，并用长时程精细任务验证了遥操作采集对 imitation learning 的直接价值。对团队建设的启发很直接：如果你的目标任务依赖精细抓取、插入、折叠或双手协同，那么“数据/示教基础设施负责人”应该比“泛泛的 AI 研究岗”更早到位。
这一块最少要有人负责下面几件事：
- 定义 episode 开始、结束、重置和异常中断规则
- 统一相机、关节、力觉、模式切换和人工标注的时间戳
- 明确哪些失败要保留，哪些数据要剔除
- 把“能采”升级成“能复训、能复盘、能对比版本”
第 4 步，平台与运行时岗位要负责把系统变成可管理对象
很多团队把平台软件理解成“把代码跑起来”，这太浅了。真正有用的平台岗位，要能把机器人各模块变成可管理、可重启、可替换的组件。
ROS 2 managed lifecycle 的思路很适合这里参考。它强调节点应有明确状态机，例如 unconfigured、inactive、active，并由外部监督过程来驱动切换。对 humanoid 团队来说，这意味着你最好有人专门负责：
- 模块启动顺序和依赖关系
- 故障后是重启感知、降级控制还是切回人工接管
- 哪些接口可以热替换，哪些必须冻结
- 仿真、台架和真机是否共用同一套接口契约
如果没有这类平台角色，团队规模一变大，系统稳定性会比算法迭代速度更先塌掉。
第 5 步，验证与日志回放岗位不要后置
机器人项目最怕“出问题时只剩口述”。MCAP 这类日志格式之所以值得参考，是因为它能把多种时间戳数据流放进同一个可回放容器里，适合把相机、状态、动作、告警、人工接管事件放到一条证据链上。你不一定非得用 MCAP，但必须尽早有人负责“统一记录与复现”。
这个岗位不是 QA 文员，而是工程验证角色，至少要能做 4 件事：
- 把每次失败归到固定 failure bucket，而不是只写“本次不稳定”
- 维护最小回归集合，保证版本更新后能快速复测
- 把现场 bug 转成可离线重放的案例
- 为上线、灰度、回滚提供客观证据
没有这层，团队会长期被 demo 文化绑架，看起来热闹，实际上无法积累可靠性。
第 6 步，什么时候才需要重押“顶尖研究岗”
当下面 4 个条件已经基本成立时，再去大力押注高阶模型研究会更划算：
- 机器人观测与动作接口已经相对稳定
- 示教与自动记录链路可持续运行
- 失败案例能稳定回放并形成训练集
- 每次版本更新都有明确回归门槛
这时候引入更强的策略学习、VLA 或世界模型人才，才是真正往前推系统，而不是让他们花大部分时间做数据清洗、接口对齐和现场救火。
一个更实用的 6 人到 12 人早期配置思路
- 1 名系统负责人：任务边界、接口冻结、版本优先级
- 2 到 3 名机器人基础栈工程师：感知、控制、状态估计、硬件联调
- 1 到 2 名数据/遥操作工程师：示教链路、episode 规范、数据清洗与回放
- 1 名平台/运行时工程师：生命周期管理、部署、监控、回滚
- 1 名验证工程师：回归集、失败桶、现场复盘
- 随后再按任务压力补模型训练、末端执行器或场景集成人员
如果你只有 4 到 5 个人，也不要把这些职能完全省掉，而是应该明确谁临时兼任哪条闭环，不要让关键职责处于真空状态。
最容易翻车的地方
- 只盯“明星岗位”，忽略系统收口和现场问题闭环
- 采了很多数据，但 episode 结构、时间戳和失败标签不统一
- 平台层没人负责，导致每次启动顺序和配置都靠口头经验
- 验证岗位太晚加入，团队长期没有客观回归标准
- 研究人员被迫长期做集成救火，真正高价值研究时间被吞掉
怎么验证你真的搭对了
看团队配置，不要只看简历数量，直接做下面 5 个检查：
- 换一个人值班，能否按 runbook 独立拉起系统？
- 同一个失败案例，能否在 24 小时内复现并定位到模块边界？
- 新采一批数据后，能否无手工改格式地进入训练或评估流程？
- 上线一个新版本时，是否有固定回归任务、固定证据和回滚条件？
- 如果系统退化，是否能明确切到 safer mode 或人工接管，而不是现场 improvisation？
这 5 个问题里只要有 2 个答不上来，说明你缺的不是更多人，而是团队结构还没有形成工程闭环。
下一步怎么做
如果你正在搭第一支 humanoid 团队，我建议不要先从“招谁最有面子”开始，而是先画出一张闭环图：任务定义、系统负责人、遥操作与数据、平台生命周期、验证回放、现场运维。然后逐一检查哪些职责已经有人真实承担，哪些只是默认“以后再说”。
把这张图补齐之后，再去扩招更强的模型、硬件或场景专家，团队效率通常会比单纯堆头衔高得多。
Sources / Further Reading
- LeRobot 官方仓库，可参考其 robot interface、数据集格式与训练入口如何解耦。
- Open-TeleVision 项目页，可参考沉浸式遥操作如何服务高质量长时程示教采集。
- ROS 2 Managed Lifecycle，可参考模块生命周期和外部监督的状态机设计。
- MCAP 官方文档，可参考多模态日志记录、回放和跨工具链可读性设计。