说明：这个实验目录里只有处理脚本和登记文件，没有书面报告。本文是根据脚本、登记文件和保存的处理结果做的回顾性补记，内容只限于这些材料能证明的部分。

摘要

10 月 9 日凌晨，用户使用战斗记录 App（Battle Notes）的一个预览版本实时对战电脑，并录下了这一局。用户要求把这段录像作为训练数据。本实验（内部编号 B153）没有开发新方法，而是原样复用旧录像截图包的流程（见 P125）：登记录像 → 5 帧/秒场景扫描 → 按局选帧 → 助手像素精审 → 打包成 App 可导入的按时间排列的截图文件夹。

最终产出 1 个训练截图包，8 张图，覆盖选秀、最终确认、布阵和战斗第 1 回合。

要回答的问题

这不是一个检验假设的实验，而是一次数据入库：能否把用户新录的实战片段，按与旧数据相同的规则和划分，整理成训练用的截图包并留下精审记录？

数据与来源

  • 一段 2560×1440 的原生录像，约 2.1 分钟、272 MB，来自 10 月 9 日 01:11 的实战。
  • 录像经过无损剪辑，只保留第 10–136 秒：去掉了开头的静止画面和第 136 秒之后的空闲尾巴（直接复制视频流，并通过编辑列表让剪辑后的时钟从零开始）。
  • 登记为训练池，单独成一个来源组。登记规则沿用旧数据：整段录像只属于一个池，测试录像绝不用于训练。

方法

处理脚本只是把旧截图包流程的各步骤指向新的数据目录，算法本身不变：

  1. 登记：写入登记文件；若已有内容不同的登记则拒绝覆盖。
  2. 扫描：5 帧/秒场景/稳定性扫描，使用 GPU 硬件解码。
  3. 选帧：按“战斗段 + 之前的选秀”切局，用生产的离线选帧挑图。
  4. 精审：一个标注助手逐帧像素复核，写入每局的精审记录（不是人工真值）。
  5. 打包：只用接收的帧生成截图包，并把包说明里的来源描述改为“用户 10 月 9 日实战”、曝光状态标为训练来源。

因为用户当时可能开着游戏，脚本以低于正常的进程优先级运行，并把数学库和图像库的线程数限制为 4。

设置

保存数据里有两套扫描/选帧目录：一套是最终使用的，一套标注为“偏移时钟”的版本——推测与剪辑后录像时钟是否从零开始有关；保存材料没有说明后者的具体结论，此处不做推断。

结果

选帧：识别出 1 局，选秀阶段约 0.4–63.8 秒，战斗段约 64.4–125.4 秒，选出 8 张。

精审（助手像素复核，8 张全部接收）：

场景 张数
主技能选择 1
宝物（神器）选择 1
生物选择 1
最终确认 1
布阵 1
战斗进行中 1
生物信息面板 2

精审记录了：我方在左侧（依据选秀名牌、战斗 HUD 头像和行动条颜色一致）、双方英雄、对手是电脑玩家；我方完整构筑（技能、子技能、装备、10 个可见法术、7 队军队及数量）；第一张战斗画面的双方 HUD（我方攻 6、防 3、法强 17、法力 50/50；对方攻 5、防 5、法强 6、法力 259/286）；两块生物面板（一个敌方、一个我方）。

打包：生成 1 个训练包（8 张），状态为已构建。

失败与负结果

  • 片段内只有战斗第 1 回合，没有任何战斗日志截图，因此双方施法无法观察——精审把施法事件留空，并明确注明这是“未知”，不是“没有施法”。
  • 敌方技能、装备、法术、知识/运气/士气全部不可见，只看到英雄头像、HUD 攻防法强和战场上 7 队生物。
  • 一些项目只能推断：某个子技能图标与知识库中另一子技能逐像素相同，按法术列表里出现的法术推断；完整法术书没有一帧全部显示；敌方一只凤凰的战场数量牌被遮挡；两个界面小图标含义未确认。

局限

单局、单一来源，只有 8 张图，且只覆盖开局；精审是助手复核而非人工真值；原报告缺失，本文只能复述保存材料。

结论与下一步

用户的实战录像已按与旧数据一致的规则入库为训练数据，并留下可追溯的精审记录。它的价值主要在于是一场真实的“对战电脑”对局，补充了训练池的来源多样性；但由于只覆盖开局、没有日志，对施法和中后段状态的训练帮助有限。