hyperframes：从视频到三维重建数据集的自动化预处理管线

作为一个常年在三维视觉方向折腾的人，我太清楚从一段手机视频到一份能用的重建数据集有多折磨了。视频里的动态行人要不得，模糊帧混进去会让位姿估计直接飘，光照突变更是能把重建结果毁得干干净净。我最早做 NeRF 和 3D Gaussian Splatting 的时候，光是在数据预处理上就反复重来，不是抽帧抽多了就是深度估计对不齐，后来认真研究了 Meta 开源的 hyperframes 这套工具，才把整个流程真正理顺。这篇文章就围绕 hyperframes，把我自己的理解、上手过程和实际踩过的坑完整写出来，给正在被数据预处理折磨的朋友一个参考。

hyperframes 本质上是一套“视频进、数据集出”的自动化数据处理管线，它把原始视频加工成三维重建、SLAM、语义场景理解等下游任务可直接使用的数据格式。你可以把它理解成一个中央厨房：送进去的是生鲜视频，出来的是按菜单切好、洗好、配好料的净菜，下游算法就像大厨，拿到就能开火，不用再从洗菜切菜开始折腾。这篇文章适合正在做 NeRF、3D Gaussian Splatting、SLAM 相关研究或落地项目的朋友，也适合刚接触三维重建、想知道一条靠谱数据管线长什么样的人。

1. 项目定位：一台视频进、干净数据集出的“数据加工厂”

1.1 hyperframes 到底是什么

hyperframes 是 Meta 开源的一套视频数据预处理工具集，它的核心目标非常聚焦：把一段原始视频（通常来自手机、无人机、运动相机）自动转换成后续重建算法需要的高质量数据集。这里说的“高质量”不是玄学，而是有具体标准的：帧与帧之间的运动足够且不过度模糊、相机位姿精确、深度图与光流场对齐、动态物体被识别并剔除。

我第一次看到这个工具名的时候，以为它只是做了个帧采样加 COLMAP 的简单封装，后来仔细跑完发现事情没那么简单。它把整个数据制作流程拆成了多个模块，包括运动补偿、帧质量筛选、位姿估计、深度估计、光流估计、语义分割等，每个模块都可以独立配置、替换、开关。这意味着它不是一条写死的流水线，而更像一个带标准化接口的数据加工厂，你可以根据下游任务的需求自由组合模块。

这个定位非常符合实际生产环境的需求。因为真实场景里的数据不太可能是完美拍摄的，视频难免有抖动、模糊、动态物体、重复纹理，这套工具就是为处理这些实际问题而设计的。它不是给你一个魔法模型，而是给你一套工程化的容错机制。

1.2 为什么这套管线值得关注

在三维视觉领域，大家经常说一句话：数据决定了结果的上限，模型只负责逼近这个上限。这个论断在 NeRF 和 3D Gaussian Splatting 上体现得尤其明显。以我自己做 3DGS 的经验为例，同样的场景，用粗糙处理的数据训练可能要调半天参数，结果还是到处是“雾状”伪影；而用干净的数据跑一遍默认参数，重建质量直接上一个台阶。

hyperframes 的价值就在这里：它把数据预处理过程中容易出错、需要反复试错的环节系统化了。比如位姿初始化，传统做法是直接对全部帧跑 COLMAP，视频一旦长一点、帧数多一点，特征匹配矩阵就爆炸，跑几个小时是常有的事。hyperframes 的做法更讲究，它会先做运动补偿和帧筛选，剔除低质量帧，再配合合理的匹配策略，让后续重建所需的位姿估计以更小的代价、更高的成功率完成。

另一个让我觉得值得推荐的点，是它对深度和光流的支持。很多三维重建任务不仅需要 RGB 图像和相机位姿，还需要几何信息作为监督或先验。hyperframes 把 DPT、RAFT 这类成熟预训练模型集成进管线，自动生成对齐好的深度图和光流场，省去了自己找模型、凑环境、对齐坐标系的一堆麻烦。

1.3 它解决的真实痛点与适用人群

• 做 NeRF / 3DGS 但被数据预处理折磨的人：手工抽帧、跑 COLMAP、清洗数据这套流程，在项目多的时候特别耗时，hyperframes 可以自动化大部分环节。
• 做 SLAM / 具身智能数据集的团队：需要大规模、一致性好、带深度和位姿标注的数据，手工标注不现实，hyperframes 的模块化设计非常适合批量生产。
• 做自动驾驶或机器人的感知数据清洗：动态物体识别与剔除、帧质量评估这些能力，在真实场景数据里非常有用。
• 刚入门三维重建、还不清楚一条标准数据管线长什么样的新手：hyperframes 很适合当成一个学习框架。它的配置体系清晰，每个环节负责什么一目了然，跑一遍基本就能理解从视频到数据的完整链路。

适用人群广不代表没有门槛，它需要一定的 Linux 操作经验、Python 环境配置能力和对深度学习模型的基本了解，但相比从零开始搭一条数据管线，门槛已经低很多了。

2. 核心模块拆解：从原始视频到训练数据，中间发生了什么

2.1 整体架构与数据流

hyperframes 的数据流可以概括为一条单向管道：原始视频进入后，先经过视频解码与运动补偿，得到稳定化后的视频帧；然后进入帧质量筛选环节，把模糊、过曝、运动过大的问题帧淘汰掉；剩下的关键帧进入位姿估计模块，算出每一帧对应的相机内外参数；同时，深度估计模块为每一帧生成深度图，光流估计模块计算相邻帧像素级运动场，语义分割模块标记出场景中的动态物体和特定类别。

以上这些模块的输出不是孤立的，它们会在后处理阶段统一对齐到同一个坐标系和时间戳上。比如深度图和位姿必须是严格对齐的，否则下游训练时模型会学到错误的空间关系，表现为重建场景扭曲、尺度漂移。光流的符号方向也必须和相机运动约定一致，我曾经因为光流方向反了，导致训练出来的时序模型在一个方向上疯狂“漂”，排查了很久才发现是预处理时通道顺序写反了。

整体架构上，hyperframes 采用了类似插件的设计。每个处理步骤都是一个独立模块，模块之间通过标准化的输入输出格式进行交互。这种设计带来一个很实际的好处：你想换一个更好的深度模型，或者改用自己训练的语义分割网络，只需要替换对应模块即可，不需要动其他部分。这也是我后来在自己的项目里坚持使用它的重要原因。

2.2 帧质量筛选与运动补偿

视频里不是每一帧都值得用，这是做过重建的人都知道的常识。手持手机拍一段视频，不可避免会有手抖造成的运动模糊、突然转向造成的拖影、以及长时间停留在同一个构图形成的冗余帧。如果把这些问题帧都塞给后续的重建算法，不仅浪费计算资源，还会明显降低位姿估计的稳定性。hyperframes 在帧质量筛选环节做的事情，就是自动识别这些“危险分子”并把它们剔除。

筛选策略通常同时考虑几个指标：图像清晰度（模糊程度）、帧间重叠度、曝光异常程度以及运动幅度。这里面比较关键的是帧间重叠度。重建算法要求相邻帧之间有足够大的共同可视区域，重叠太少会导致特征匹配失败，重叠太多又会造成冗余、拖慢速度。所以筛选器会结合光流结果估算每帧的新信息量，优先保留有效运动覆盖充分的帧，这比单纯按固定间隔抽帧科学得多。

运动补偿模块解决的是另一个问题：某些视频整体是平滑运动的，但由于相机优先级优先的自动曝光或滚动快门效应，图像之间存在明显的亮度闪烁或几何畸变。运动补偿会对这些帧做对齐和校正，让后续特征匹配更稳定。在室内场景、低光环境下，这步的作用非常明显。我的习惯是在拍摄条件不太理想时开启运动补偿，如果场景光照稳定、相机运动也稳当，则可以选择关掉以节省整体时间。

2.3 位姿估计、深度估计、光流估计与语义分割

位姿估计是重建管线的核心环节，说白了就是回答“相机在哪儿、朝哪儿看”这个问题。hyperframes 默认会调用 COLMAP 进行运动恢复结构（SfM）计算。为了提升效率和成功率，它在送入 COLMAP 之前就已经完成了帧筛选，因此 COLMAP 处理的是相对干净的数据。这样不仅速度快了，因为参与匹配的帧数量减少，位姿失败的概率也低很多。

深度估计模块为每一帧生成像素级深度图。这一环节直接决定下游模型能否学习到正确的三维几何关系。hyperframes 集成的 DPT 这类模型在通用场景下表现不错，能输出相对准确的单目深度估计结果。不过需要注意的是，单目深度估计得到的深度和真实尺度之间没有绝对关系，它是一个相对的预测值。在我实际使用中，这个相对深度对监督法向估计、场景流学习等任务已经足够，但如果你需要绝对尺度，还是要引入额外的尺度恢复手段，比如多视角三角化或者激光雷达点云对齐。

光流估计模块则计算相邻帧之间的稠密像素运动场，这个信息在场景流、动态物体过滤、时序一致性约束中非常重要。hyperframes 集成的是 RAFT 这类高精度稠密光流模型，输出质量在当前预训练模型里属于比较能打的那一档。唯一需要注意的是，光流在遮挡区域、无纹理区域会产生较大的估计误差，这部分位置的输出在使用时需要设一个可信度阈值。

语义分割模块负责给每一帧的像素打上类别标签，比如行人、车辆、天空、建筑等。这个信息的核心用途是识别动态物体和不良区域。重建算法通常假设场景是静态的，如果画面里跑来跑去的人和车被当成静态特征点参与位姿估计，结果大概率会崩。通过语义分割先识别出这些区域，可以在后续处理中把对应的特征点过滤掉，或者给这些像素降低权重，从而保证重建几何的干净。

2.4 输出格式与下游兼容性

一套工具值不值得用，除了看效果，还得看出来的东西好不好用。hyperframes 在设计时就考虑了和主流重建框架的衔接，输出的数据结构对下游非常友好。它会生成标准的 COLMAP 格式位姿文件，也就是说像 NeRF、3DGS、DROID-SLAM 这类依赖 COLMAP 输出的项目，基本可以直接把结果喂进去，省去了各种格式转换的心智负担。

深度图和光流图的输出也按照统一的文件组织方式保存，每个文件夹对应一套输出来源，文件名和图像索引严格对应。这个看似简单的细节在实际项目中很有价值。我见过不少自研管线，位姿、深度、语义结果各存各的，命名规则对不上，每次用数据前都得写一堆对齐脚本。hyperframes 直接把这些问题处理掉了，整个数据集的路径结构和命名规范在跑完一遍之后非常清晰，人也能看懂，脚本也能直接遍历。

对于需要自定义格式的团队，它模块化的设计也留了口子，你可以在拿到标准输出之后做一层转换，封装成自己内部的数据格式。我后面在自己项目里就是用一套简单脚本，把 COLMAP 格式转成了自己训练框架的通用格式，整个过程几乎没有阻碍。

3. 实操记录：安装配置与完整跑通一条数据任务

3.1 环境准备与安装

hyperframes 的环境配置整体不算复杂，但对版本比较敏感。官方建议基于 conda 来管理依赖，我在一台 Ubuntu 20.04、RTX 3090 的机器上配置过一次，过程还算顺利，不过也踩了些小坑。建议提前装好 CUDA 工具链，然后用 conda 创建一个独立环境，按仓库里的 environment.yaml 安装依赖。注意这里的时间成本主要消耗在编译一些 PyTorch 扩展或安装特定版本的库上，建议用稳定的网络环境，尽量安装固定版本号，不要随手升级成 latest。

安装完成后，记得先跑一遍官方提供的小型测试数据或者自带示例，确认整个管线在你的机器上能完整跑通，再处理自己的真实数据。我第一次图省事直接拿自己的一段大视频跑，结果 COLMAP 跑到一半卡死，排查了很久才发现是整个环境没有配好，后来规规矩矩先跑通示例，反而节约了时间。

机器配置方面，一块显存足够大的 GPU 很关键。我自己的经验是，深度估计模型和光流模型在 1080p 分辨率下单卡显存占用会在 6GB 到 12GB 之间浮动，如果同时加载语义分割模型，显存压力会更明显。建议至少准备 16GB 显存的显卡，12GB 的 3060 或 3080 也可以跑，但一些高分辨率数据就需要适当下调处理分辨率来换取稳定性。

3.2 配置文件结构与关键参数

hyperframes 使用 Hydra 作为配置管理框架，这个选择对使用者来说很友好。它把整个管线的所有可调参数都收敛到一个配置系统里，你通过一条命令就能覆盖任意层级的参数，不需要到代码里去改硬编码。配置文件里涉及的关键参数主要有几类：输入源参数（视频路径、目标帧率、缩放比例）、各模块开关（是否启用语义分割、是否做运动补偿）、模型参数（深度模型选择、光流模型分辨率限制）、输出路径参数（实验根目录、数据存放目录）。

以帧率的设置为例，这个参数直接影响后面的位姿估计耗时。目标帧率太高，帧之间的位移太小，特征匹配会大量冗余；目标帧率太低，帧之间的可视重叠不足，位姿估计容易断裂。一般我会按视频内容选择，稳定慢速扫描的场景 10 到 15 FPS 就够，快速移动的场景可以适当提高。这个没有绝对公式，最好先按一个初始帧率跑一遍，观察 COLMAP 重建出的相机轨迹是否平滑连续，再反过来微调帧率。

GPU 相关参数同样值得花时间调。batch size 太大容易显存溢出，太小又浪费并行能力。我在默认配置基础上把深度模型的分辨率上限控制在 1024 以内，batch size 控制在 2 到 4 之间，整体显存占用量稳定在 10GB 左右，速度也没有明显下降。如果显存比较紧张，优先降低光流模块的分辨率，因为光流模型的显存占用往往比单目深度模型更高。

3.3 跑通一条视频数据处理任务

下面是我实际执行过的一条命令形态，结合经验解释一下每条命令做了什么。先克隆仓库、创建环境：

git clone https://github.com/facebookresearch/hyperframes.git cd hyperframes conda env create -f environment.yaml conda activate hyperframes

然后跑一条具体的数据处理任务，命令大致长这样：

python tools/run.py +experiments=hyperframes \ experiment_root=/path/to/experiment \ dataset_root=/path/to/raw_video_file \ data_root=/path/to/output_data

这里的+experiments=hyperframes表示选用 hyperframes 这套完整的默认实验配置，experiment_root指定整个实验的根目录，dataset_root指向原始视频文件，data_root指向最终数据输出的位置。如果你只想跑其中一部分模块，比如只做深度估计或者只做帧采样，可以针对 experiment 配置里的模块开关进行覆盖，Hydra 的机制允许你用命令行追加参数的方式逐层覆盖配置。

跑通整条管线的耗时受视频长度、帧数、分辨率影响很大。我拿一段 2 分钟、1080p 的手机视频做过测试，在 3090 上从视频解码到最终输出全套数据，大约需要 20 到 40 分钟，其中有相当一部分时间花在 COLMAP 的特征提取和匹配上。如果场景纹理丰富、帧数量适中，这个时间还算可接受。如果你的场景纹理很差，或者视频很长，就要提前预估好挂机时间，必要时在配置里开启更激进的关键帧采样策略。

4. 核心环节实现细节与参数调优

4.1 帧采样策略怎么选

帧采样决定了后续所有环节的输入质量，也是整个管线里最值得花时间调的部分。常见的采样策略有固定间隔采样、按运动量采样、按信息量采样。固定间隔采样最简单，但在录制速度变化大的场景下不实用，快速移动时帧间重叠太少，慢速时又会产生大量冗余帧。按运动量采样会根据相邻帧的光流或特征匹配结果，动态决定是否保留当前帧，这样能保证帧与帧之间的基线比较均匀。

hyperframes 的做法偏向于按信息量和帧质量综合判断，这在大多数场景下都是最优解。实际操作中，我建议先跑一遍默认筛选逻辑，然后打开中间输出，观察被保留下来的帧索引分布。如果发现在某个时间段帧数明显过多，说明运动缓慢或出现了大量近似重复的画面，可以适当降低目标帧率或者提高帧间重叠阈值；如果某个时间段帧数过少，通常是运动过快，导致筛选器认为大部分帧质量不合格而丢弃，这时需要降低筛选阈值或提高输入视频帧率。

一个小技巧是：不要把筛选卡的太狠。保留一部分冗余帧对后续重建的鲁棒性是有帮助的，尤其是在场景重复纹理多、特征匹配容易歧义的区域。过度筛选会让最终数据集“看起来”干净，但相机轨迹可能因为帧间约束不足而产生漂移。我在一些纹理较弱的室内场景里，会主动把去重阈值放宽一些，让位姿优化有更多的约束边。

4.2 深度与光流的对齐问题

深度图、光流场、语义分割图最终都必须和 RG B 图像严格对齐，这个对齐不只是分辨率一致，还涉及原图像坐标系、通道顺序、时间戳对应关系。hyperframes 在这方面的处理总体是可靠的，但我在实践中发现几个容易出问题的点值得留意。

首先是深度图的尺度问题。DPT 这类单目深度模型输出的是相对距离，不是实际度量值。这意味着同一段视频里不同帧的深度尺度可能是不同的，直接拿来做跨帧几何约束会有隐患。如果要让深度参与多视角一致性的监督，最好在管线里加入尺度对齐步骤，比如利用 COLMAP 的稀疏点云对每帧深度做一个全局尺度拟合。

其次是光流在遮挡区域的误差。物体边缘、前后景交界处是光流估计最容易出错的位置，这些区域的光流往往会“拖尾”或者把背景运动误判为前景运动。我在下游用到光流时，一般会结合语义分割结果，把动态物体的边缘区域单独处理，或者直接裁剪掉这些不可信像素，避免错误光流污染训练。

最后是时间戳对齐。如果深度模型和光流模型处理的是插值后的帧，而位姿对应的是原始帧的时间点，就可能出现一个微小的偏移。这种偏移在单帧上几乎看不出来，但累积起来会让训练时的几何约束“共振”不起来。所以我建议在处理完成后，用脚本验证一下各输出文件大小和帧索引的一致性，确保每个文件夹里的对应关系完全正确。

4.3 与 NeRF、3D Gaussian Splatting 的衔接

hyperframes 输出的 COLMAP 格式位姿文件，可以直接当成主流 NeRF 和 3DGS 实现的输入。很多知名的框架读取数据集时都会先找sparse/0下的相机参数文件，hyperframes 生成的这个部分我用下来和这些框架兼容度很高，基本不需要手工改格式。

我用它准备过一段室外建筑的 3DGS 训练数据。当时按 hyperframes 的输出直接跑默认参数的 3DGS 训练，得到的结果非常稳，建筑结构清晰，远景也没有那种常见的高斯“飞絮”。对比之下，我之前手工清洗的一套数据，虽然看似帧数差不多，但因为有少量帧位姿不准确，训练出来的初始点云里混着不少错误的“飞点”，后期怎么调透明度都没有完全清干净。

和 NeRF 的衔接同样顺畅。因为位姿文件和帧索引是严格对应的，训练脚本不需要额外做索引重映射。但要注意，NeRF 训练通常需要保持一定的帧率均匀性，如果 hyperframes 筛选出的帧间距差别很大，比如有的地方密集、有的地方稀疏，可以在生成数据集之后再做一次轻量级的等间隔采样，确保训练时对场景不同区域的覆盖更均匀。

5. 常见问题与排查技巧实录

5.1 环境依赖的坑

这个工具对环境版本敏感，最常见的问题集中在 PyTorch、CUDA、以及一些 C++ 扩展的编译上。我在安装阶段碰到过一次编译某个扩展时 gcc 版本过高导致失败，解决办法是切换到系统自带的低版本 gcc。另外，PyTorch 和 CUDA 版本必须匹配，如果机器上有多个 CUDA 版本，一定要在创建环境时明确指定路径，否则模型可能在 GPU 上根本跑不起来。

还有一个容易忽略的点：environment.yaml里的包版本是项目发布时的版本，如果你手头 Python 版本太新，某些依赖可能根本找不到对应的 wheel。我的建议是严格按仓库要求创建 Python 版本环境，不要一上来就装最新的 Python。把依赖问题隔离好之后，后续模块的运行会顺很多。

排查环境问题的一个实用思路是：先看日志是从哪个模块开始报错的，然后再回查该模块对应的依赖版本。整套工具的输出日志会把当前正在执行的模块名和加载的模型种类都打印出来，根据日志信息定位依赖问题，往往比盲目按报错搜索更高效。

5.2 显存不足与性能调优

显存不足是跑视频数据时最高频的问题，多发生在同时加载深度估计、光流、语义分割三个模型的阶段。解决思路一般是逐模块削减：先看是不是所有模块都要执行，如果下游任务不需要语义分割，直接关掉能省下很大一块显存；如果还需要，则把处理分辨率下调，把模型输入的边长限制在 768 或者 512。

另一个有效做法是把数据切段处理。不要一次性把整段视频的中间结果都保存在显存里，可以按时间段分段，每段处理完写入磁盘再处理下一段。这个思路尤其适合超长视频，否则即使显存够，长时间推理造成的显存碎片也可能导致运行期报错。我在处理 30 分钟以上的视频时基本都会切段，速度不仅没有明显变慢，稳定性反而高了。

如果训练数据对时效性要求不高，优先用性能模式、关闭可视化输出来换时间。把中间可视化结果关掉，既能省磁盘空间，又能减少大量 I/O 开销。我在跑批量实验时都会把可视化开关关闭，只保留数值型中间结果，整条管线的耗时能下降 20% 以上。

5.3 位姿估计失败的排查

位姿估计失败是整个管线里最让人头疼的环节，但大部分失败其实可以提前预判。一个典型的场景是低纹理环境，比如白墙、大片玻璃、空旷的走廊，COLMAP 因为找不到足够的特征点而无法生成有效的稀疏点云。处理办法是在拍摄阶段就尽量避免画面集中在无纹理区域，或者在配置里调低特征匹配阈值，允许更多的弱特征点参与匹配。

另外一类失败源于视频中的大范围动态物体。行人、车辆在画面里占比过高时，特征匹配会被大量动态特征点带偏，位姿结果会出现明显的“漂移”或突然跳变。我用 hyperframes 处理街景数据时遇到过几次，排查后确认是动态物体干扰导致。解决方案是开启语义分割，并在位姿估计前把动态物体的区域做掩膜处理，或用过滤后的特征点参与匹配，位姿质量会立刻改善。

还有一个经常被忽视的因素是重复纹理。比如瓷砖地面、百叶窗、整齐排列的围栏，这类场景的特征匹配容易出现歧义，导致 COLMAP 输出的相机位姿“跳变”到错误位置。如果场景中有大面积重复纹理，建议在拍摄时增加一些非重复特征的辅助信息，或者在帧筛选阶段多保留一些不同角度的帧，给匹配器更多约束条件。

5.4 常见问题速查表

6. 我的一些使用心得与扩展方向

6.1 实际项目中这三个细节最值得花时间

第一，一定要仔细看中间过程的输出。hyperframes 的好处在于它会保留各阶段的可视化结果，千万不要把这些输出直接删掉。我有一次就是因为懒得看中间的深度可视化，结果深度模型在逆光区域生成了一片错误深度，直到训练完出了大面积伪影才回头发现。浪费的时间远比提前看一眼前后多得多。

第二，处理好语义分割掩膜和位姿估计的顺序。如果场景里动态物体很多，一定要让语义分割模块先运行，这样后续位姿估计可以把动态区域的数据排除或降权。如果顺序反了，先跑位姿再跑分割，动态物体就可能已经污染了特征匹配结果，后面再怎么做掩膜都补不回来。

第三，如果你的项目需要输出绝对尺度的深度，不要指望默认的单目深度模型直接给你准确数值。我自己在室内机器人项目里，额外引入了深度相机采集的稀疏深度值做了尺度对齐，才真正让深度图可用。这个步骤不算复杂，但很有必要，效果提升也很明显。

6.2 可以怎么改造和扩展

hyperframes 的模块化设计很适合做二次开发。我在自己的项目里替换过深度估计模型，把原来默认的 DPT 换成了更适合室内小物体场景的轻量级模型，只需要把新模型包装成同样的输入输出接口，然后在配置里指定对应的模型名称即可。整个替换过程没有改动其他模块。

另外一个可行的扩展方向是把输出结果转成自己的自定义格式。比如你的训练框架需要生成带表面法线、语义标签、实例分割掩膜的复合数据，你完全可以在 hyperframes 输出基础数据之后，再接一个自定义后处理脚本。因为它的输出文件结构非常规范，写一个迭代遍历文件夹的脚本很轻松，不会在处理文件路径这种无聊问题上浪费精力。

此外，如果团队需要批量生产数据集，还可以写一层外层调度脚本，把多段视频的地址、输出路径、参数组合批量传入 hyperframes，实现一批任务自动排队处理。我在批量处理无人机采集的视频数据时就是这么干的，效果很好。它的核心价值不只是帮你处理一条视频，而是帮你建起了一条可以复制、可批量执行、可稳定产出的数据生产工序。这套工序一旦搭好，后续再做新的场景数据，就再也不用从头开始踩坑了。