物理AI从模型竞赛转向经验竞赛：全链路数据基建成为新壁垒

如果要给“Physical AI”这几个字找一个最准的落点，我的判断是：它已经从“模型竞赛”进入“经验竞赛”。

过去两年我们见证了大模型在文本、图像、代码上的爆发，核心范式是“参数够大、算力够多、数据够宽”。但到了机器人、自动驾驶、工业控制这类要跟真实物理世界打交道的场景，情况完全变了。你没法靠堆参数让机械臂学会打螺丝，也没法靠生成式预训练让移动机器人在陌生车间里自主避障。物理 AI 要解决的不是“理解世界”，而是“作用于世界”。而作用于世界这件事，拼的不是模型灵光一现，而是能不能把人类操作员、仿真环境、真实设备反馈中的“经验”快速变成可训练、可复用、可迭代的数据资产。

这篇文章想讨论的不只是某个机器人项目的实操，而是围绕一个正在被资本和技术团队重新定义的赛道：经验工程（Experience Engineering）。我们以刚完成数千万美元融资的 Ropedia 为切入点，拆解物理 AI 背景下“全链路数据基建”到底在做什么，为什么它可能比模型本身更早成为行业壁垒，以及作为开发者，我们该如何在自己团队里搭建一条可落地的最小数据闭环。

1. Physical AI 为什么从“模型竞赛”转向“经验竞赛”

先看一个常见的认知误区：很多人以为 Physical AI 的难点在算法，比如强化学习、模仿学习、世界模型、端到端控制。但实际上，这类项目从论文 Demo 走到产线验证时，卡点往往不在算法，而在“没有数据可用”。

大模型时代的文本数据可以靠爬虫和人工标注规模化获取，图像数据可以靠互联网海量积累。但物理交互数据不行。机器人抓取一个杯子、拧一颗螺丝、在湿滑地面上走一步，这类数据必须从真实设备或高保真仿真环境中获取，采集成本高、标注难度大、场景分散，而且单条样本的价值密度远高于一条文本。

更关键的是，物理 AI 对数据的要求不是“多”，而是“对”。

训练一个抓取模型，你可能需要包含不同材质、不同光照、不同遮挡程度、不同力反馈特征的数据；训练一个移动机器人策略，你需要覆盖长尾危险场景，比如突然出现的行人、湿滑地面、黑暗角落。这些数据很难靠公开数据集获得，必须由团队针对自己的设备和场景持续采集、清洗、筛选、回流。

当一个团队的模型结构趋于一致，训练框架趋于同质化时，决定模型上限的就是经验数据的质量和迭代速度。这就是“经验竞赛”的起点：谁能更快地把真实世界里的物理过程转化为可用经验，谁就能让模型更早收敛、更稳落地。

所以，与其说 Physical AI 是一场算法竞赛，不如说它是一场数据和经验工厂的竞赛。模型是放大器，经验数据才是被放大的底层信号。

从行业信号看，资本也开始认可这个判断。Ropedia 完成数千万美元融资，对外口径是“聚焦全链路数据基建”。这意味着投资方并不认为 Physical AI 的胜负手只在模型端，他们认为数据采集、数据清洗、场景生成、仿真回流、评测管理这一整条链路，本身就是值得单独投入的基础设施。

2. 经验工程到底是什么

“经验工程”这个词还不是业界统一术语，但它的指向很明确：把人类或仿真环境中的“操作经验”变成 AI 可学习、可复用的系统性数据资产。

为了理解这个概念，我们把它和数据工程、特征工程放在一起对比。

传统数据工程解决的是“数据能不能拿到、能不能存好”的问题。比如日志采集、数仓建模、ETL、数据治理，目标是让数据可用、稳定、可追溯。

特征工程解决的是“数据能不能被模型有效利用”的问题。比如从原始数据中提取特征、做归一化、组合特征，目标是提升模型训练效果。

经验工程解决的问题是“物理交互中的一类特殊数据如何被系统化产生、标注、验证和回流”。它比数据工程更进一步：

• 数据不是被动采集，而是有目的地设计采集方案。
• 数据中不仅包含传感器读数，还包含动作指令、成功/失败标签、物理约束、语义指令、环境上下文。
• 数据不仅用于一次训练，还要不断回流、扩展、去重、筛选，形成可持续进化的经验库。

举一个具体例子。

假设你想让机械臂学会“把螺丝刀放到工具架的第三格”。传统数据工程会记录 RGB 图像、关节角度、末端位姿、力矩信息。但经验工程还需要记录：

• 操作员是用什么方式抓取螺丝刀的，正手还是反手？
• 放置过程中是否碰到工具架边缘？
• 这个动作是否因为在第三格已经被占用时失败了？
• 人类操作员的路径规划意图是什么？
• 如果换一把不同重量的螺丝刀，策略是否需要调整？

这类信息的本质是“经验”，而不是单纯的数据。它们共同构成一个可复用的经验单元：感知输入、动作输出、环境状态、结果反馈、语义解释。

如果把模型训练看作“让 AI 从经验中归纳规律”，那么经验工程就是“决定 AI 能获得哪些经验”的上游环节。上游环节的质量直接决定模型能力的上限。

从开发视角看，经验工程通常包括五个环节：

• 数据采集：从真实设备或仿真环境获取多模态原始数据。
• 数据清洗与结构化：剔除异常片段、统一格式、对齐时间戳。
• 经验标注：为数据添加指令语义、成功/失败标签、约束条件。
• 数据回流：把仿真数据和真实数据混合，扩充长尾场景。
• 评估与迭代：用固定评测集衡量数据质量，反推采集方案。

这五个环节形成一个闭环，而支撑这个闭环运行的基础设施，就是业界越来越关注的全链路数据基建。

3. 全链路数据基建：Physical AI 的“经验工厂”

为什么传统的数据平台很难直接支撑 Physical AI？因为在物理 AI 场景里，数据链路更长、实时性要求更高、数据模态更多、标注复杂度也完全不同。

一条典型的 Physical AI 数据链路通常是下面这样的：

1. 部署在边缘设备上的数据采集程序，持续记录相机图像、LiDAR 点云、IMU、关节状态、力矩、机器人控制指令。
2. 采集到的原始数据经过初步清洗，剔除掉设备掉线、传感器遮罩、任务中断导致的无效片段。
3. 清洗后的数据先做粗标注，区分任务类型和大致结果。
4. 经验级细标注，包括物体位姿、操作轨迹、环境语义、成功与否、安全约束是否被满足。
5. 数据统一转成结构化格式，进入数据湖或文件系统。
6. 训练平台从数据湖中按场景分布采样，生成训练集和评测集。
7. 训练后的模型在仿真环境或小规模真实设备上验证。
8. 验证失败的数据回流到采集团队，反向指导下一轮数据采集。

这听起来和传统 MLOps 有些相似，但关键差异在于：

• 物理数据依赖真实或仿真设备，采集过程本身是工程问题。
• 一条成功经验往往需要多次尝试，失败数据同样重要。
• 标注需要融合传感器数据和语义指令，难度高于纯文本或图像标注。
• 数据回流必须考虑仿真与真实的域差距，不能简单合并。

Ropedia 强调的“全链路数据基建”，正是针对这条长链路提供一体化方案。从公开信息看，它的定位不是只做一个标注平台或一个仿真引擎，而是把采集、清洗、标注、场景生成、仿真回流、评测管理这些分散环节串起来，为 Physical AI 团队提供一条顺畅的数据流水线。

这种定位背后的行业逻辑很清晰：物理 AI 团队通常规模不大，模型工程能力并不弱，但数据团队却要同时应对硬件调试、传感器同步、标注系统、仿真环境多个技术栈。把数据基建单独封装成平台能力，可以大幅降低团队的重复建设成本。

4. Ropedia 融资信号背后：数据基建是物理 AI 的“卖水人”

从淘金热的角度看，真正稳定赚钱的往往不是淘金者，而是卖水人。物理 AI 赛道上，卖水人的角色正在从 GPU 算力转向数据基建。

前几年做机器人数据平台的公司，更多被视为“外包标注公司”或“数据服务商”。但 Ropedia 完成数千万美元融资这件事，从行业视角看有几个信号值得注意。

第一个信号是数据基建开始独立于具体模型和具体硬件。过去很多团队认为，数据平台应该跟着自己家的机器人系统走，自己写采集脚本、自己搭标注平台。但一个统一的、标准化的数据基建产品，可以服务多个硬件平台和多个模型架构，这种中立性让它具备了平台型公司的潜质。

第二个信号是资本市场开始理解“经验数据”的稀缺性。Physical AI 公司之间的竞争，不只是模型效果竞争，更是每家公司手里的经验数据多少、数据质量高低、迭代速度快慢的竞争。一家公司积累了大量高质量操作经验数据，即使暂时模型效果不是最佳，也拥有后续追赶的底座。数据基建因此不再是成本中心，而是长期资产。

第三个信号是对长尾场景的重视。物理 AI 最难的不是实验室里的标准场景，而是真实世界里的长尾情况：雨天路面积水、货架上物体叠放、螺丝滑丝、光线不足。这些场景通过纯人工采集成本极高，通过仿真生成又容易失真。一个成熟的数据基建平台，需要在仿真数据生成、真实数据采集、数据回放与筛选之间找到平衡。Ropedia 的融资说明，资本愿意为这种高难度的平台型问题买单。

当然，这里也需要保持清醒。数千万美元融资只是起点，不代表产品已经完全成熟。更稳妥的判断是，物理 AI 数据基建正在成为一个独立赛道，但远没到格局已定的时候。对开发者来说，这意味着可以更多关注数据层面的工具选型和流程建设，而不是把所有精力都押在模型结构上。

5. 搭建 Physical AI 数据基建的最小闭环

不管 Ropedia 这类平台最终会提供多少功能，作为技术团队，我们仍然需要理解数据基建的原理和最小实现。下面我从工程角度，给出一个可以跑通的最小闭环。它不是生产级方案，但足够帮你理解整个链路是怎么串起来的。

5.1 多模态经验数据采集

物理 AI 经验数据的核心是多模态、时序对齐。ROS2 的 ros2 bag 是机器人领域最常用的采集方案之一，适合传感器类型多、需要高精度时间同步的场景。

# 文件路径: scripts/record_experience.sh ros2 bag record \ /camera/color/image_raw \ /camera/aligned_depth_to_color/image_raw \ /joint_states \ /wrist_ft \ /odom \ /cmd_vel \ /robot_status \ --output demo_episode_001

这段命令会把相机图像、深度图像、关节状态、腕部力传感器、里程计、控制指令统一录制到一个 bag 文件中。ros2 bag record 本身会为每个话题打上时间戳，但多个传感器之间的时钟同步仍然需要额外处理，比如使用 STOMP 或 NTP 同步设备时钟。

对于不是跑在 ROS 上的设备，可以用 Python 或其他语言实现一个简单的多模态记录器，核心思路是给每条数据都附加统一的采集时间戳和任务元信息。

# 文件路径: experience_capture/multimodal_recorder.py import json import time import h5py import numpy as np class MultimodalExperienceRecorder: """ 最小多模态经验记录器。 将相机图像、关节状态、动作指令保存为 h5 + json 元数据。 """ def __init__(self, output_path: str): self.output_path = output_path self.events = [] self.h5 = h5py.File(output_path, "w") def record(self, frame_id: str, rgb: np.ndarray, depth: np.ndarray, joint_state: dict, action: dict): # 为每条经验生成统一时间戳 timestamp = time.time() event_id = f"ep_{len(self.events):06d}" self.h5[f"{event_id}/rgb"] = rgb self.h5[f"{event_id}/depth"] = depth self.h5[f"{event_id}/joint_position"] = np.asarray(joint_state["position"]) self.h5[f"{event_id}/joint_velocity"] = np.asarray(joint_state["velocity"]) self.events.append({ "event_id": event_id, "frame_id": frame_id, "timestamp": timestamp, "action": action, }) def save_metadata(self, task_description: str, success: bool): metadata = { "task_description": task_description, "success": success, "total_events": len(self.events), "events": self.events, } with open(self.output_path.replace(".h5", ".json"), "w", encoding="utf-8") as f: json.dump(metadata, f, ensure_ascii=False, indent=2) def close(self): self.h5.close()

这个记录器的设计意图是：每个事件都记录了对应的视觉信息、关节信息和动作信息，同时事件与任务元数据分离。采集到的数据是一堆原始日志，下一环节需要把它们整理成结构化经验。

5.2 经验数据清洗与结构化

原始数据中往往包含设备启动阶段、任务中断、传感器失灵等情况，直接用于训练会导致模型学到无效特征。最简单的方式是建立一个数据清单，批量检查每个片段的时长、帧数、动作指令是否完整。

# 文件路径: data_ops/build_manifest.py import argparse import json import hashlib from pathlib import Path def hash_file(path: Path) -> str: sha256 = hashlib.sha256() with open(path, "rb") as f: for chunk in iter(lambda: f.read(1024 * 1024), b""): sha256.update(chunk) return sha256.hexdigest() def build_manifest(raw_dir: Path): manifest = { "dataset_version": "1.0", "total_episodes": 0, "episodes": [] } for json_file in sorted(raw_dir.glob("*.json")): with open(json_file, "r", encoding="utf-8") as f: metadata = json.load(f) duration_sec = metadata["events"][-1]["timestamp"] - metadata["events"][0]["timestamp"] manifest["episodes"].append({ "episode_id": json_file.stem, "duration_sec": round(duration_sec, 2), "num_events": metadata["total_events"], "success": metadata["success"], "task_description": metadata["task_description"], "meta_hash": hash_file(json_file), }) manifest["total_episodes"] = len(manifest["episodes"]) return manifest if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--raw_dir", type=Path, required=True) parser.add_argument("--output", type=Path, default=Path("manifest.json")) args = parser.parse_args() manifest = build_manifest(args.raw_dir) with open(args.output, "w", encoding="utf-8") as f: json.dump(manifest, f, ensure_ascii=False, indent=2) print(f"manifest saved to {args.output}, episodes={manifest['total_episodes']}")

运行方式：

python scripts/build_manifest.py --raw_dir data/raw --output data/manifest.json

这个清单会告诉你数据集中有多少条有效经验、每条经验多长、是否成功、任务类型是什么。这是后续筛选训练集和排查数据偏置的基础。

5.3 经验数据集加载与训练接入

数据清洗完成之后，需要把经验数据变成模型可以直接读取的训练集。下面是一个基于 PyTorch 的最简数据集示例，假设已经将原始事件转换成了 h5 文件。

# 文件路径: data_ops/experience_dataset.py import h5py import torch from torch.utils.data import Dataset class ExperienceDataset(Dataset): """ 从 h5 文件加载经验数据。 每条样本包含视觉特征、关节状态和动作指令。 """ def __init__(self, h5_path: str, keys: tuple = ("rgb", "depth", "joint_state", "action")): self.h5 = h5py.File(h5_path, "r") self.keys = keys self.length = len(list(self.h5.keys())) def __len__(self): return self.length def __getitem__(self, index): event_id = f"ep_{index:06d}" sample = {} for key in self.keys: data = self.h5[f"{event_id}/{key}"][:] sample[key] = torch.from_numpy(data) return sample if __name__ == "__main__": dataset = ExperienceDataset("data/archive/kitchen_episodes.h5") sample = dataset[0] print(sample.keys()) print(sample["rgb"].shape) print(sample["action"])

关键点在于：数据集类只负责读取已经结构化好的经验数据，不需要关心原始 bag 文件和标注过程。这样训练代码与数据采集端逻辑解耦，不同机器人团队可以复用同一套训练代码。

5.4 仿真回流与长尾场景补充

真实数据很难覆盖所有边缘场景，所以经验工程里一个重要环节是仿真回流。简单理解就是把真实采集的经验片段导入仿真引擎，修改环境参数后生成新的变体数据。

# 文件路径: scripts/import_episode_to_sim.sh python tools/import_episode.py \ --source data/archive/kitchen_episodes.h5 \ --scene kitchen_A \ --domain_randomization True \ --output data/sim/kitchen_random_v1.h5

运行时建议先小批量测试，例如只导入 10 条经验，确认场景生成效果后再全量扩展。

6. 运行结果与效果验证

无论使用哪种数据基建方案，都需要建立一套可量化的验证方法。下面以最小闭环为例，说明如何判断数据基建是否跑通。

先看数据采集阶段。采集完成后，用 ros2 bag info 检查关键话题的消息数量：

ros2 bag info demo_episode_001

预期输出应包含每个话题的消息总数、起止时间和时长。如果某个高频传感器话题的消息数量明显低于其他话题，大概率是采集线程丢帧或传感器驱动异常。

再看数据清洗阶段。运行 build_manifest.py 后，打开 manifest.json，检查如下指标：

{ "dataset_version": "1.0", "total_episodes": 25, "episodes": [ { "episode_id": "ep_000001", "duration_sec": 12.35, "num_events": 120, "success": true, "task_description": "grab screwdriver from tray", "meta_hash": "7f6b3c2f..." } ] }

建议关注三类指标：

• 成功与失败样本比例。完全全是成功样本，训练出来的策略可能缺乏恢复能力。
• 每个任务类别的样本数量。避免某个任务占 80% 导致模型任务偏置。
• 平均时长和事件数。如果大量片段时长过短，可能是任务中断导致的不完整经验。

最后看训练接入阶段。运行 ExperienceDataset 脚本时，如果能正常输出样本形状，说明数据已经可以被训练代码读取。

如果某个环节失败，不要急着改模型。先确认数据链路本身是否通畅，再判断是否需要调整采集端或标注端。

7. 常见问题与排查思路

物理 AI 数据基建的坑比模型训练更难排查，因为它牵涉硬件、网络、存储、标注、仿真多个环节。下面列出实际项目中最常遇到的问题。

经验之谈：很多问题看起来像模型问题，实际是上游数据问题。建议团队在模型训练前先建立“数据健康报告”，包含有效样本数、任务分布、时长分布、标注一致性等基础指标，能省掉后面大量定位时间。

8. 工程化团队建议与最佳实践

数据基建不是一个人写几个脚本就能长期支撑的，它需要工程化规范和团队协作意识。以下几个建议来自物理 AI 项目实践，值得参考。

8.1 把数据当作产品来管理

数据集不应该是一堆文件，而应该是一个有版本、有文档、有评测协议的产品。每个数据集都应该有对应的 manifest、构建脚本、数据说明文档，以及一张明确的评测划分表。这样任何一名新成员都能快速理解数据集的来龙去脉。

8.2 失败经验比成功经验更值钱

很多采集团队只保存成功片段，这是物理 AI 数据基建里最常见也最可惜的浪费。失败经验告诉模型“哪些动作不能做”，在安全敏感场景中价值极高。建议在标注字段中增加 failure_type 和 constraint_violation，让失败经验可以被搜索、筛选和复用。

8.3 标注标准先于标注工具

标注工具五花八门，真正难的是定义标准。比如“抓取成功”在不同团队里的定义可能完全不同：是指物体离开桌面，还是指物体已经被稳定放置在目标位置，还是指整个任务流程完成且没有碰撞？团队应该先定义清楚经验标注标准，再选择工具，而不是先选工具再适应规则。

8.4 安全边界必须前置

物理 AI 数据采集涉及真实设备和人员安全，任何采集方案都应该先经过测试环境和仿真环境验证，再部署到真实设备。涉及生产数据或敏感场景时，必须遵循最小权限原则，确保只有授权人员可以访问数据链路和标注平台。不是所有数据都应该直接进入云端，边缘侧先脱敏、后上传往往更稳妥。

8.5 数据闭环比单次离线训练更重要

体现实力的不是某次训练用了多少数据，而是团队能否快速发现模型失败案例，并把它们转化为下一轮训练数据。建议在模型评估系统中，单独设立一个“bad case 数据库”，所有评测失败的样本都进入候选池，定期由数据团队补充标注并回流到训练集。

9. 给开发者的落地建议

从我们的角度看，Physical AI 正在经历的转变，和当年深度学习从图像识别走向工业落地时非常相似：模型结构会持续迭代，但主导工程进度的，越来越依赖数据获取和数据处理的能力。

如果你所在团队正在做相关项目，可以从这三个方向入手。

第一，先盘清自己的数据链路。把从传感器采集到训练数据接入的每一步列出来，找出最薄弱的环节。很多团队发现，瓶颈不一定在模型，而是在数据标注规范缺失、传感器时间戳不同步、失败数据被随意丢弃这些看起来很小的问题上。

第二，先小步跑通闭环，再优化单点。不要一开始就追求完美的标注系统或仿真环境。先用 ROS bag 或自己的记录器把几十条经验数据跑通全流程，能成功训练出一个小策略，就已经走完了最难的第一步。

第三，关注数据基建平台化趋势。Ropedia 等公司完成了融资，意味着未来会有更多成熟的数据基建工具可供选择。到时候，团队的差异化优势不再是会不会写数据脚本，而是能否把数据采集、经验标注、失败回流组织成一套高效的经验工厂。

物理 AI 的落地不会只靠天才的模型设计，它更会赢在成体系的经验工程能力上。把经验当作基础设施来建设，可能是未来几年这个赛道最重要的工程判断。