项目背景
GVCLab 为游戏世界模型研究采集第一人称游戏画面与同步键鼠输入。和普通录屏不同，这批数据不仅要保留连续的游戏过程，还要经过清洗、时序对齐和动作标注，让画面与操作事件能够准确对应，供后续模型训练和评测使用。
我一方面负责数据采集团队的日常组织，把实验室的研究需求转成采集者能够稳定执行的任务；另一方面参与数据进入研究环节后的工程处理，为不同游戏开发 Stage 1a/1b 标注流水线。
数据采集与团队组织
- 拆解采集目标，制定游戏范围、场景要求、单次时长和提交规则；
- 招募并培训采集者，安排人员与游戏任务，持续处理设备、录制和提交问题；
- 把容易产生歧义的研究需求整理成可执行 SOP，统一文件、录制、隐私和质量要求；
- 跟踪每周采集进度、账号产量和游戏覆盖，及时调整排班与激励；
- 组织自动检查与人工抽查，区分原始录制时长和真正可用于研究的有效时长；
- 与实验室研究和工程成员协作，把采集端暴露的问题反馈到工具、流程与质量标准中。
数据清洗与标注流水线
我还参与开发了配套的 GVCLab Data Annotation Pipeline，把原始录屏和同步键鼠事件转换为可追溯、可质检的结构化标注数据。我的工作集中在各游戏的 Stage 1a/1b 适配：
- 建立原始 MKV 视频与 MCAP 操作记录的清洗流程，输出按场景、按帧组织的数据，同时保留视频时间戳、来源文件和处理记录；
- 在 Stage 1a 中以真实键鼠事件为依据切分连续动作，统一按键名称、修复按下与释放状态，并避免仅凭画面猜测玩家操作；
- 在 Stage 1b 中抽取关键画面，结合视觉模型进一步识别动作语义、场景上下文和控制目标，并通过候选范围、校验与回退机制减少不可靠标注；
- 为《鸣潮》《巫师 3》《洛克王国：世界》《看门狗 2》《幻兽帕鲁》《异环》和《逃离塔科夫》建立或适配独立的 Stage 1a/1b 流水线；
- 支持断点续跑、分游戏缓存、处理清单和质量报告，使批量任务能够复现，并区分通过质检的正式结果与仅供开发验证的输出；
- 按统一的数据契约衔接团队后续的 Stage 1c–4a 流程；后续阶段及统一路由由实验室资深成员负责。
这部分工作解决的是采集数据的“可用性”问题：原始视频规模再大，如果画面、时间和操作无法可靠对齐，就难以直接成为模型训练数据。目前七款游戏已完成不同程度的流水线适配与验证，但不将开发验证结果等同于全部数据已完成正式标注。
当前数据规模
截至 2026 年 8 月 29 日：
- 5,150 小时 51 分录制总时长；
- 4,174 小时 09 分质检有效时长；
- 8,646 段录制，合计 33.65 TB；
- 采集任务覆盖 20 余款游戏，由 73 个采集账号共同完成。
规模增长之外，我更关注“有效时长”而不是只看原始小时数。坏文件、挂机、切出游戏、画面与操作不同步等问题都会让录制失去训练价值，因此质量控制始终和扩充规模同等重要。
论文署名
这批数据成为 GameHorizon Suite: Multi-Horizon Data and Evaluation in Gameplay 的组成部分。我以 Kaifeng Li、GVC Lab, Great Bay University 的身份列入当前论文作者名单。
这意味着数据采集不再只是一次幕后支持工作，而是成为了可被研究成果明确追溯的贡献。当前材料只确认作者署名，不在论文正式公开前提前宣称发表或录用状态。
这段经历
当数据规模从几十小时增长到数千小时时，项目的核心问题会从“能不能采到”变成“能不能持续、稳定地采到合格数据”。人员沟通、任务分配、质量反馈和异常处理，都会直接影响最后的数据可用性。
这段经历让我真正体会到，大规模研究数据背后既有大量不显眼的组织工作，也有把原始记录转成训练数据的工程工作。采集解决规模，清洗与标注解决可用性；把模糊需求转成清楚的流程，并让人员、数据和代码在较长周期内保持一致，本身就是研究工程的一部分。