摘要
说明：这个实验目录里没有原始报告，只有一个脚本和它保存的结果文件。本文是根据代码与保存数据整理的补记（retrospective）。
项目的战斗记录 App 可以读取用户选中的一段游戏录像，按时间点取帧交给识别程序。在真正让 App 跑一遍之前，需要确认“参考答案”和“App 将要读的帧”在元数据上完全对得上——同一个视频、同一个时间点、同一张图。本实验就是这一步预检：把前一天准备好的 6 张参考帧（共 215 个目标字段）与交给 App 的 4 帧序列做元数据连接与断言检查。
结果：所有断言通过，状态记为“元数据连接通过，但这不是 App 或识别的验收”。全程没有新解码图像、没有调用 OCR、模型或视频（计数为 0）。真正的 App 选中视频读取运行没有在这一步执行——当时 GPU 时间窗口由另一项工作占用。
要回答的问题
在运行 App 读取之前，参考数据与 App 输入序列的元数据是否自洽：帧编号、源视频、解码时间、时间戳、图片文件都一一对应吗？
数据与来源
- 前一天（10 月 4 日）整理的参考数据：6 张已有帧的字段选择、字段复核和字段核对三个文件，复核状态为“等待主会话质检”。
- 其中 4 帧组成一个交给 App 的序列，都来自同一段训练录像（10 月 2 日 23:13 开始）；另 2 帧（布阵时的生物面板、战斗日志）只在参考中使用。
- 所有字段都标记为“不进入训练”。
方法
脚本只读 JSON 与检查文件是否存在，做以下断言：
- 字段核对文件状态为通过；选择与复核中的帧集合完全相同，均为 6 帧。
- 每帧的字段键无重复，且与选择时的目标字段集合一致；所有字段都指向本帧图片、都未准入训练。
- 用源时间戳 × 时间基换算的秒数，与记录的解码秒数相差小于 1e-8；图片文件存在。
- 总目标字段数为 215，且各状态计数在三份文件中一致。
- App 交接文件夹中的 4 帧与参考中的序列逐帧对应：原图路径、媒体秒数、解码秒数、时间戳、时间基、源视频全部一致，序列按时间严格递增。
设置
不解码图像，不运行任何读取器。结果写入一个元数据审计文件。
结果
参考字段状态（共 215 个）：
| 状态 | 数量 |
|---|---|
| 已知 | 169 |
| 未知 | 15 |
| 不可读 | 2 |
| 不可见 | 29 |
App 序列 4 帧：
| 帧 | 解码时刻（秒） | 名义时刻减解码时刻 | 目标字段 | 已知 / 未知 / 不可见 / 不可读 |
|---|---|---|---|---|
| 准备（确认页） | 359.957 | 17.5 ms | 36 | 33 / 2 / 0 / 1 |
| 布阵 | 374.970 | 16.7 ms | 34 | 16 / 2 / 16 / 0 |
| 战斗 | 689.973 | 17.5 ms | 40 | 35 / 2 / 2 / 1 |
| 生物面板 | 1004.975 | 17.3 ms | 33 | 28 / 3 / 2 / 0 |
其他汇总：主会话批准的新字段 0；我方/对方归属已知 0；单位实例已知 0；规范身份已知 0。
一个值得注意的细节：录像的“名义”时间与实际解码帧的时间普遍相差约 17 毫秒，脚本把它单独记录下来，而不是当作同一个数。
失败与负结果
没有断言失败。但本步骤没有完成它最终要服务的事情：App 选中视频的实际读取运行未执行。
局限
- 这是元数据层面的连接检查，不是 App 验收，也不是识别准确率。
- 参考字段的复核状态仍是“等待主会话质检”；归属、单位实例和规范身份在参考里都还是未知。
- 原始报告缺失，以上内容仅来自脚本与结果文件；脚本之外的决策背景无法从保存数据中还原。
结论与下一步
参考数据与 App 输入序列的元数据自洽，可以作为之后真实运行的对照基础。下一步是在 GPU 空闲时让 App 实际读取这段选中录像，并用这 215 个字段的参考逐项比较。
Comments