上个月跟一个做机器人底盘的朋友喝酒，他刚从一个数据供应商那儿买了2000条"训练数据"，花了小二十万。结果数据部把包拆开一看——全是ROS bag原始流，别说训练了，连标注工具都没法直接读。跟供应商扯了两周皮，对方一句话把他噎住了："合同上写的就是'数据'，我又没说'训练就绪数据'。"

他后来复盘这件事的时候跟我说了一句话，我觉得值一整篇文章的价——"这行最贵的不是数据，是你以为你买的和你实际拿到的不一样。"

核数聚做AI数据服务15年，从语音标注一路做到具身智能、大模型、自动驾驶，接过的方案、翻过的车、救过的急，归结起来就一条经验：甲方和乙方之间的信息差，十个有九个藏在术语里。同一个词，销售嘴里是一个意思，工程师脑子里是另一个意思，合同上又写着第三个意思。等你发现不对，钱已经花出去了。

这一篇不打算炒术语冷饭，而是挑五组——从数据计量单位到坐标系、从交付格式到质量定义、从仿真承诺到落地差距——你日常方案里大概率见过、但很少有人跟你讲清楚的东西。全篇每组黑话都是甲方真金白银踩出来的坑，没有一条是从别处搬来的。

黑话一：Episode / Trajectory / Demonstration — 合同上只有两个字"数据"，成本却差五倍

具身智能数据采购合同里，最经典的写法是"采集XX条数据"或者"交付XX小时数据"。看起来清清楚楚，实际上这句话什么都没说——因为它没有告诉你计量单位是什么。同一个任务、同一批采集作业，用三个不同的计量单位报给你，数字可以差出一个数量级，背后的成本结构也根本不一样。

Episode：一个完整任务，从开始到结束

一个episode指的是机器人从初始状态出发，完成一次完整任务，到回到初始状态（或被判定为失败）的全过程。比如"拿起杯子放到桌上"，从机械臂开始移动到放下杯子，这算一个episode。一个episode里可能包含几百上千帧的状态-动作对，时长可能从几秒到几分钟不等。

坑在哪？不同任务、不同难度的episode，数据量和采集团队投入完全不同。一个"拧瓶盖"的episode可能15秒搞定，一个"叠衣服"的episode可能要两分钟以上。合同上写"1000个episode"，如果不约定任务类型和难度分布，你拿到手很可能是1000个拧瓶盖——便宜、快、但对你自己的训练场景几乎没用。

Trajectory：工程层面的"状态-动作序列流"

trajectory是个纯工程概念，指的是一段时间内机器人状态（关节角、位姿、图像观测等）和动作（控制指令）构成的连续序列。同一个episode里可以切出多段trajectory；反过来，几个短episode也可以拼成一段长trajectory。切分方式的决定权在数据处理工程师手里，不是任务本身决定的。

最隐蔽的坑：trajectory可以被任意切分和合并。一个供应商报出"5000条trajectory"，你没法判断这5000条对应多少真实任务、覆盖了多少场景。他完全可以把3个episode切碎成30条trajectory来报——数字翻了十倍，信息量原地踏步。

Demonstration：谁来做、做得多好，直接决定训练价值

demonstration指的是人类操作员通过遥操作、拖动示教、VR手柄等方式完成一次任务示范。它和episode的关键区别在于：demonstration强调"谁来教"以及"教得多好"，episode只关心任务的边界。

同一条demonstration，不同操作员做出来质量差距可能是数量级的。熟练操作员的一次示范，动作流畅、轨迹合理、时间紧凑；新手操作员同样完成一个任务，可能拖拖拉拉、反复修正、中间还多了很多无效动作——两段数据表面上都叫"demonstration"，训练价值完全不在一个档次。

核数聚怎么做：每一个项目启动前，核数聚会和客户明确约定三个维度的计量方式——按episode、按trajectory还是按demonstration报价，每种计量方式下面再约定任务类型、难度分布和质量基准线。合同上不写"1000条数据"，而是写"1000个episode，覆盖A/B/C三类任务各N个，单条episode时长范围X-Y秒，质量基准线不低于Z"。数字不玩虚的，是因为核数聚的交付体系本身就能度量到这些维度。

黑话二：末端位姿 / 关节角 / 任务空间坐标 —— "位置"这个词至少指三种东西

方案里最常见的一个词就是"位置数据"——"我们交付位置数据""这批数据包含位置信息"。但具身智能里的"位置"，至少指三样东西，不能互换，串错了参照系整个数据集可能全废。

末端位姿（End-effector Pose）：xyz + 旋转 + 参照系

机器人的末端执行器（夹爪、吸盘、灵巧手）在空间坐标系中的位姿，包含三维位置（x,y,z）和三维姿态（通常用四元数）。这是最直观的一种——训练时以末端位姿为参考，相当于告诉机器人"把你的手放在空间中的这个位置、这个角度"。

但必须追问：这个位姿的参照系是什么？是世界坐标系（以机器人的基座为零点）、还是相机坐标系（以传感器为零点）？不同参照系之间需要变换矩阵。搞错了参照系，整批数据的坐标全偏了。

关节角（Joint Angles）：每个关节的旋转角度值

机械臂的每一个关节都有一个角度值，六轴机械臂就是六个角度。关节角的好处是不需要解逆运动学——直接把关节角喂给控制器就能复现运动。但换一台不同构型的机器人，同样的关节角可能对应完全不同的末端位姿，甚至目标位置根本不可达。

关节角数据和机器人本体强绑定。你在A机器人上采集的关节角数据，给B机器人用之前必须重映射，重映射的结果可能丢失精度甚至不可行。这也是为什么具身智能行业越来越强调跨本体数据适配——不是所有数据都能在不同机器人之间"即插即用"。

任务空间坐标（Task Space）：以操作对象为中心

不关心机械臂的关节在哪、末端在哪，只关心操作对象的位置。比如"杯子在桌面上的坐标是(x,y,z)，杯口朝向是(θ)"。这种坐标最通用——不管是什么构型的机器人，"杯子在桌子的左前方"这个事实是不变的。但把任务空间坐标翻译成具体机器人的控制指令，还需要感知、定位和规划三道工序。

核数聚的交付标准：每一批数据都附带坐标系元信息文档——参照系定义、变换矩阵、关节-位姿对应关系、以及跨本体适配建议。核数聚服务了乐聚、穹彻、自变量等多个机器人本体厂商，深知坐标系不统一是数据"串不起来"的第一大根因。交付数据的时候，元信息和数据包一起交，不让你自己猜参照系。

黑话三：ROS Bag / 标准化数据集 / 训练就绪数据 —— "能打开"不等于"能训练"

这一组可能是被误解最多的。很多甲方验收的实质标准就是"文件能打开，播放器能看到画面"——然后觉得数据到手了。但"能打开"离"能训练"，中间可能有几周甚至几个月的工程差距。同样一批原始信号，交付形态不同，甲方的后续投入差出一个数量级。

ROS Bag：生肉，离下锅还远

ROS Bag是机器人操作系统（ROS）的原生数据记录格式。它把传感器话题——相机画面、激光雷达点云、IMU惯性数据、关节状态等等——按时间戳一股脑全记下来。好处是一帧不丢、信息全；缺点是脏——掉帧、时间戳漂移、传感器噪声、无效片段全堆在里面。处理一个小时的ROS Bag，把各话题对齐、去噪、切片、打时间戳，一个数据工程师可能要干一整天。

很多报价单上的"交付数据"就是ROS Bag——你买到的是一堆原材料，加工费和加工周期全部另算。很多人以为买了训练数据，实际上只买了个源码仓库。

标准化数据集：切好、洗净、码齐了

这一层开始进入"半成品"阶段。各传感器的时间戳已经对齐了，无效片段已经剔除了，数据按episode或task切好了，元信息——任务类型、场景编号、操作员ID、设备型号——全都挂上了。拿到这种数据，数据工程师可以直接写预处理脚本，不用先花一周做清洗和对齐。

训练就绪数据（Training-Ready）：拆了包装就能下锅

数据已经和训练框架的输入格式对齐好了。观测-动作对已经提取完毕，归一化参数已经算好，训练/验证/测试集已经划分好。拿到之后解压、配置路径、直接跑train.py。

三种格式的单价可能差出1:3:10甚至更高。供应商报低价往往报的是ROS Bag的价——因为这一步成本最低，只负责"录"；但甲方心理预期的是训练就绪数据——能直接"练"。中间的工程差距，就是验收时争议最大的地方。

核数聚的交付层级：从需求对接到最终交付，核数聚提供从ROS Bag原始数据到训练就绪数据集的完整谱系，客户可以按需选择交付层级。每一种格式都有对应的SOP、质检标准和交付时间表——核数聚的"采标训一体化平台"天然覆盖了从原始信号到训练就绪的全链路，不需要把三个段拆给三家供应商去对接。一个环节三家供应商之间踢皮球是行业里的经典死局；一家全包，责任边界直接就兜住了。

黑话四：成功率 / 完成率 / 轨迹质量分 —— "数据没问题"是句最危险的话

验收的时候最常听到的一句话就是"这批数据没问题，都能跑通"。这句话的信息量约等于零——因为它没告诉你"没问题"的判断标准是什么。同一个"没问题"，对初级质检员和算法工程师来说完全可能是两个判断。

成功率（Success Rate）：二元判断，过了就算

最简单的指标：任务完成了没有。机械臂把杯子放到了指定位置——成功；杯子掉了——失败。但问题是，成功的数据不等于好的训练数据。一条轨迹目标完成了，但过程中经历了三次险些碰撞、五次超速、末端抖动——模型学了这条轨迹，学会的不只是"完成任务"，还有"怎么在快撞的时候侥幸躲过去"。这种数据放进训练集，效果可能适得其反。

完成率（Completion Rate）：模糊地带最大

比成功率更模糊的概念。"擦桌子"擦了80%，算完成吗？"叠衣服"叠歪了但叠上了，算完成吗？完成率的主观判断空间极大，不同标注员对同一段数据的判定一致性可能低于60%——六成的人说"完成了"，四成说"没完成"，这条数据到底是有效还是无效？

轨迹质量分（Trajectory Quality Score）：多维度的综合评估

这才是真正的准绳。综合评估轨迹的平滑度（加速度突变少）、安全性（与障碍物的最小距离）、效率（路径长度与最优路径的比值）、可复现性（在相似初始条件下能否稳定复现）等多个维度。一个0.9分的"失败了但优雅"的轨迹，在学习纠错和超出分布恢复行为时，可能比一个0.4分的"成功了但全程走钢丝"的轨迹更有训练价值。

行业里有句话说得不好听但很真实：失败数据不是废数据，失败数据往往是最贵的——它包含了成功数据里没有的纠错信号。但在模糊的验收条款下，失败数据常被一刀切当废品扔了，等于白白扔掉了一半可能有极高训练价值的样本。

核数聚的质量体系：不是"做完就算"，而是每一批数据都附带多维质量报告——成功率只是一个统计数字，轨迹质量分、操作员一致性、场景覆盖度、困难样本占比、失败样本的保留策略，全都在报告里有据可查。核数聚的"AI预标注+人工精修+三重质检"体系，质量控制从采集阶段就开始介入，不是等到交付前才抽检几个样本了事。对核数聚来说，99%+的精度不是在口头承诺里，而是在每次交付的质量报告的白纸黑字里。

黑话五：仿真数据 / Sim-to-Real / Domain Randomization —— "我们有仿真"不等于"仿真数据能用"

近两年，几乎每一份具身数据方案都会提一嘴"仿真数据"。这三个字听着很厉害——在虚拟世界里无限采、零成本、零风险。但仿真数据和真机能用的训练数据之间，隔着的不是一个按钮，而是一整套技术栈。同一个"仿真"，不同团队走的是完全不同的技术路线，落地的可靠程度也天差地别。

仿真数据 ≠ 真机数据

在Isaac Sim、MuJoCo、PyBullet这类仿真环境里，虚拟机器人一天能跑几万次任务。但仿真里完美的物理规律、理想的光照和零噪声的传感器，和真实世界之间存在着所谓的Sim-to-Real Gap——摩擦力偏差、接触动力学误差、材质的反射特性差异、传感器噪声模型不准……每一项都可能让在仿真里99%成功的策略，一到真机上就崩溃。

Sim-to-Real Transfer：一座还在修、还没修完的桥

Sim-to-Real指的是一套让仿真学到的策略在真机上同样有效的技术体系。常用手段包括：Domain Randomization（在训练时随机化仿真环境的视觉和物理参数）、系统辨识（先精确测量真机参数再在仿真里复现）、以及混合训练（真机数据和仿真数据混着喂）。但这些方法都有适用范围——尤其是涉及精细接触操作的任务，目前几乎没有纯仿真方案能真正替代真机数据。

Domain Randomization ≠ Digital Twin

Domain Randomization的思路是"我不追求仿真完美，我让它足够多变，让模型见多识广"。而Digital Twin恰恰相反——它追求1:1复现真实环境，包括精确的CAD模型、纹理材质、光照参数、物理动力学。前者省了建模成本但牺牲了精度，后者建得准但投入巨大——一个精确的数字孪生，建模成本可能和真机数据采集成本不相上下。

买方需要判断的是：供应商的仿真方案到底走的是哪条路线？敢不敢把真机和仿真的配比写进合同？Sim-to-Real的验证实验有没有做过、结果能不能拿出来？只甩一句"我们有仿真"，跟没说一样。

核数聚的建议：仿真数据是真机数据的有力补充，不是替代品。核数聚在给客户做方案时，从来不会把"仿真数据"当作降本的万能招牌——真机数据的精度和真实接触交互的动态特性，仿真目前还替代不了。但仿真在扩大场景覆盖、增加罕见事件样本、做预训练和数据增强方面，确实能帮大忙。关键是把真机数据和仿真数据的边界、配比、各自承担的角色写清楚——而不是拿一句"我们有仿真"把真机数据的缺口糊弄过去。

核数聚的解决方案：怎么判断一家数据服务商到底靠不靠谱

说了五组黑话，最终要落在最实际的问题上：看了这么多坑，怎么挑一家不会让你踩坑的？

核数聚在这行干了15年，从语音、图像做到大模型、具身智能，几万批数据交付下来，我们自己的经验是：靠谱不是嘴上说的，是五样"硬东西"撑起来的。

1. 采标训一体化，不分包。从采集、标注到训练数据供给，是核数聚一个团队从头跟到尾。不会出现"采完了标不了、标完了训不了、出了质量问题三方互相推"的经典死局。一个项目的坑，三个供应商之间踢皮球是常态；一家全包，责任边界直接就兜住了。
2. "AI预标注+人工精修"双引擎。不是纯AI跑量（质量不可控），也不是纯人力堆（效率和成本扛不住）。AI先批处理提效60%+，人工再精修纠错——语音准确率99.5%、NLP达98.5%，每个数字都有质检报告背书。
3. 交付不带模糊地带。每批数据附带完整元信息——坐标系定义、变换矩阵、计量单位说明、质量报告。合同上怎么写，交付就怎么交，不玩文字游戏。核数聚的客户里很多是跟了三轮供应商之后才找到我们的——不是因为核数聚最便宜，是因为核数聚最清楚。
4. 具身智能全生命周期覆盖。从场景搭建、多模态采集、标注质检到跨本体适配和数据集生产，核数聚在具身智能领域已经服务了乐聚、穹彻、自变量等头部客户——不是实验室里的demo，是产线上跑通的体系。
5. 合规有据可查。ISO27001、27701、ISO9001、测绘资质——每张证都能在项目启动时直接拿出来。核数聚支持平台私有化部署和数据本地化存储，数据权属条款在合同里单独约定，不把合规当口头禅。

拿着这五道题去问，别让术语替你省掉思考

下次再看具身数据采集方案，把下面五个问题挨个问一遍。对方答得利索，说明他清楚自己在卖什么；支支吾吾、绕圈子、用更新的术语来回答，说明他也在等你自己把坑踩一遍。

五个必问的硬问题

1、计量单位是什么——Episode、Trajectory还是Demonstration？"一条"怎么定义？任务类型和难度怎么分布？

问清楚计价单位和任务类型的对应关系。1000条拧瓶盖和1000条叠衣服不是一个东西。追加问题：不同难度的配比是多少？会不会用简单任务填数？

2、"位置"的参照系是什么——末端位姿、关节角还是任务空间坐标？参照系定义在文档的哪一页？

要一份坐标系元信息文档。如果对方反问"这也要写文档？"，说明之前没有客户跟他较过这个真——你也不该成为第一个踩坑的。

3、交付格式到哪个层级——ROS Bag、标准化数据集还是训练就绪？我拿到之后还要做多少工程才能跑train.py？

让对方列出从"收到文件"到"模型跑起来"的完整步骤清单。如果他说"打开就能用"，追问一句"用什么打开"——是rosbag play还是pytorch DataLoader，中间差着一座桥。

4、"数据没问题"的标准是什么——只有成功率一个数，还是带轨迹质量分？失败数据怎么处理的？

要求提供多维度质量报告。如果只有"成功率"一个数字，追加要轨迹平滑度、操作员一致性、困难样本占比的数据。没有就是没测；没测就不能叫"没问题"。

5、仿真数据的角色是什么——替代真机还是补充？Sim-to-Real验证做了没有、结果敢不敢写进合同？

看对方敢不敢把真机和仿真的配比、各自的适用边界、以及Sim-to-Real验证方案白纸黑字写进合同。敢写的值得深入谈，只说"我们有仿真"的，听听就算了。

行业里的术语不是敌人，它们本来是为了提效而出现的。但当术语变成挡在买卖双方之间的迷雾时，它就从工具变成了成本。把每句话翻译成能被验真、能被度量、能被写进合同的东西，是卖方的基本功；对报价单上的每一个字都追问到底，是买方的必修课。

核数聚做了15年AI数据服务，最深的一个体会是：一份写得清楚、问得明白的方案，和一份术语满天飞的方案，在客户那里的信任度差着一整个"踩坑→扯皮→补救"的周期。说人话这件事，省的不是口水，是真金白银。