摘要

这是一份计划与工具记录，不是结果报告。

游戏战斗画面底部有一条底栏：左边是当前行动单位的头像，中间是这个单位和英雄的若干能力槽（按钮，用过后中间会显示剩余冷却回合数），右边是法术书按钮，还有“等待”“跳过”等按钮。鼠标停在按钮上时，按钮上方会弹出悬停提示框写着按钮名和说明。

项目的长期目标之一是让程序自己玩真实游戏，每走一步都要能核对“界面现在处于什么状态”。本实验（内部批次 B170）计划对开发用录像逐帧（每秒 5 帧）记录底栏状态，形成每段录像一条时间线和一份“状态变化事件”列表，并做成审核页供用户确认。

实际进展：采集、标注、检查、审核、合并的全部脚本已写好，11 项独立测试通过；只在 4 张开发样例图上做过诊断。用户随后要求“不跑了”，实际 5 fps 时间线、OCR 和审核页 QA 都没有执行。因此本文没有任何识别准确率可报。

要回答的问题

  • 每一帧底栏处于什么状态？具体字段：底栏是否定位到；能力槽 1 外圈是否发光（表示“备用攻击方式”已开）；法术书按钮是否压着沙漏（本回合已施法）；等待按钮是否变灰；每个能力槽有没有图标、中间有没有冷却数字；悬停提示框是否出现、写着什么、属于哪个按钮；当前单位头像是否变化。
  • 这些状态如何随时间变化（例如“槽 1 发光 → 打开法术书 → 熄灭”）？
  • 每个状态检测器在预标注上是否稳定（相邻帧抖动、与悬停文字是否一致）？

数据与来源

  • 只处理登记为“开发（dev）”的录像；测试录像和冻结留出材料在读取扫描或图像之前就被拒绝。
  • 录像的划分与日期沿用整段登记。
  • 所有机器给出的值都标为预标注（PRELABEL）；在用户真实确认之前，“已人工审核（REVIEWED）”的数量为 0。
  • 外观参考样例取自一段开发录像（10 月 9 日 08:38）的 6 个原生分辨率裁图：法术书沙漏有/无、等待变灰有/无、单位槽空、英雄槽空。这些是助手目视选取（CODEX_VISUAL），不是人工审核。

方法（已写成代码，未在全量数据上运行）

运行顺序：准备参考样例 → 采集 → 悬停框准备与 OCR → 标注 → 完整性检查 → 生成审核页 →（用户导出后）合并。

  1. 采集：在原生分辨率底栏（纵向第 1240–1440 行）上，以 5 fps 请求时间点抽帧；实际解码到的帧时间（PTS）和请求时间分开保存。源视频缺帧超过 100 ms 的位置记为未知，不重复宣称为独立帧。
  2. 外观判断：
    • 槽 1 外圈亮度沿用之前布局表实验（B162）的阈值。
    • 法术书/等待按钮与空槽：和参考样例做像素模板比较。模板相似只是候选，不是置信度；最近两个模板距离太接近（平局）或都太远，就记为未知。
    • 单位头像变化只记作“外观变化”，不推断是哪个逻辑单位或哪一方。
    • 如果底栏没定位到，所有字段保持未知，不能当成“空槽”。
  3. 冷却数字：能力槽中心的白色字形按连续像素差异分组，在原生裁图放大 3 倍后做 OCR。没有数字或字形不唯一时保持空值（null），不能推断为 0。同一字形在其它时刻引用 OCR 结果时，要明确记录“传播”依据，不伪装成逐帧独立读数。
  4. 悬停提示：用 5 fps 缩略图上完整矩形框的中心关联到按钮（不用 OCR 行中心）。选中变化帧后，必须确认重新精确抽出的原生帧底栏与原采样像素完全相同，才读取提示框。后续同按钮、同框形、框内缩略图均值差 ≤3 的帧引用锚点 OCR，并标记为“缩略图外观传播”。找不到框不等于“确认没有悬停”；漏框率未经认证。
  5. 事件：记录已知与未知之间的状态变化；600 ms 内的 A→B→A 只标为“潜在抖动”，不等同错误。
  6. 审核与合并：审核页展示状态示例和原生底栏/悬停上下文；用户导出后，合并脚本只提升用户明确确认的字段，并检查来源身份和旧快照。可选的“鼠标光标聚类”不执行。

OCR 累计壁钟预算上限 7200 秒，解码耗时单列；长任务限制在部分 CPU 核心上运行，并在解码和 OCR 前检查游戏是否在运行。

设置

  • 工具代码自包含，不导入其它实验，只读生产模块，不删除或移动原媒体。
  • 测试单独运行本目录。原因：多个自包含实验共用 common、merge 这类同名模块，若放进同一个 pytest 进程会串用缓存（曾因此出现 2 项失败，分开运行后通过）。
  • 审核页的浏览器 QA 只允许修改一个标为 SYNTHETIC_QA_ONLY 的合成条目，不能合并进真实标签。

结果

  • 工具测试：11 项独立进程测试通过（0.15 秒）。覆盖的行为包括：底栏未定位不能制造空槽或冷却 0；没有字形时冷却为未知而非 0；模板平局或太远时拒识；冷却必须是唯一的字面数字；用户审核只能逐字段确认且绑定到快照；越界值被拒绝；测试/冻结来源不会被当作开发数据。
  • 准备阶段诊断：在 4 张开发样例图上运行状态检测（参考样例和阈值正是在这些图上准备的，所以不是独立验证）。4 张图都定位到底栏；槽 1 发光仅在 1 张为真；所有能力槽的冷却数字都是未知（大多“没有字形候选”，2 张图各有 2 个英雄槽“有字形候选但未 OCR”）。

这些是软件行为测试和准备诊断，不是状态识别的验收。

失败与负结果

  • 实际 5 fps 时间线、OCR、悬停关联和页面 QA 都没有执行；用户要求收尾后本批暂停。
  • 准备阶段发现的工程问题：多实验同名模块在同一 pytest 进程中串用，已改为分开运行。

局限

  • 没有全量数据，没有用户审核，REVIEWED = 0。
  • 参考样例只来自一段录像的少量裁图；阈值在同一批图上准备。
  • 悬停框漏检率、冷却字形 OCR 的可靠性都没有测量。

结论与下一步

底栏状态时间线的工具链已经具备，原则也定清楚了：未知不是空、没有数字不是 0、传播的读数要标明来源。但在执行之前就暂停了。底栏能力槽的身份识别（另一实验）、“行动条路由”合同草案都在等这批状态数据；若恢复，需要用户重新授权，再按计划运行采集、OCR 与审核。