摘要

战斗记录 App（Battle Notes）是一个陪玩工具：用户打游戏时，它截取画面、识别信息并给出对局简报。10 月 10 日，用户用 App 的第 13 个候选版本（RC13）实打了两局，认为这两局有参考价值，希望加入训练集，同时也同意删除不需要的数据。本实验把两局整理成标准的“训练截图包”，并修复了实时过程中暴露的一个录像问题。这是数据整理，不是识别准确率实验。

要回答的问题

两局实战能否按项目的来源隔离规则整理成可用的训练材料？没有录像的那一局怎么处理？

数据与来源

两局都只进入训练池，各自成为独立的来源组：

  • 第二局（16:57 开始）。 App 在 17:15:51 实时输入出错后，没有让录屏器停止，录屏器又把空闲的游戏画面录了约 1 小时 40 分钟（原文件 2 小时 4 分、16.8 GB）。按用户的意思，先通过录屏器接口正常停录封口，再无损剪出前 23 分钟（3.1 GB，只复制数据流、不重新编码），原文件移入回收站，由用户自己决定是否清空。对局在录像 5:00–21:44；22 分钟时已回到主菜单，25 分钟起画面全黑。
  • 第一局（16:31 开始）。 开局时录屏接口还没就绪，没有录像，只有 App 截下的 50 张图。

方法

  • 有录像的一局： 按已有的选帧流程，先以 5 fps 扫描，再选出候选帧，生成联系表（多张缩略图拼成的总览图）供目视复核，最后打包。
  • 只有截图的一局： 按路由器（把截图分给各读取器的程序）读到的画面类型——法术书、生物面板、攻击预览、英雄窗口、战场——均匀挑 20 张，打包成训练截图包。场景名是路由器给出的机器标签，没有复核。
  • 训练包里的文件用硬链接指向原文件，不复制媒体。

设置

所有步骤在训练池内进行，没有使用测试池或冻结材料。

结果

步骤 结果
扫描第二局录像 70.4 秒，6896 个 5 fps 采样
选帧 20 帧
目视复核 19 张接受、1 张拒绝（第 15 帧是生物面板淡入的过渡画面）
第二局训练包 19 张
第一局训练截图包 20 张
训练包结构检查 118/118 通过

复核是助手目视，不是用户的人工审核。

失败与负结果

  • 第一局没有录像，只能用 App 当时截下的图，场景标签也未经复核。
  • 暴露的 App 问题：实时输入出错时，App 自己开启的录像没有被正常封口，导致录屏器一直录下去。已修复：出错分支现在会调用录像的收尾流程，让录像正常结束。

局限

  • 两局都来自同一天、同一构筑的用户实战，属于训练来源，不能用来评测。
  • 训练包结构检查只说明打包格式正确，不说明标签正确。

结论与下一步

两局实战已以训练来源的身份入库，可以用于后续训练和开发；同时修复了“出错后录像不停”的问题，避免再产生巨大的空闲录像。