摘要

在《英雄无敌：上古纪元》的战斗中，把鼠标移到可攻击的目标上，游戏会显示一个攻击预览：预计造成的伤害范围、可能消灭的单位数等；治疗时则显示绿色的治疗数值。预览数字直接反映双方的属性和技能，是推断对手构筑的好证据。但预览有好几种（近战、远程、延展攻击、法术伤害、多目标、治疗），光看数字的形状分不清种类。

本实验原计划在全部准入录像的战斗画面里系统地找出攻击预览，建立一个“预览种类”数据集，并把项目现有的公共读取器（read_attack）与这些样本对比。这是一个计划：工具和测试已经写好，但全量扫描、GPU OCR、读取器对比和审核页面验证都没有执行。 这一批数据工作在 2026 年 10 月 9 日被用户要求暂停，之后标记为“等机器空闲时再做”。

要回答的问题

  1. 准入录像的战斗画面里出现过哪些种类的攻击预览？每种有多少样本？
  2. 现有公共读取器在这些预览上读出的数值是否与参考一致？
  3. 在有限的 GPU 机时下，怎样尽量不漏掉预览、又不把大量无关画面存成整帧？

数据与来源

  • 计划核实过的来源：49 段准入录像，另有 2 段被拒绝。冻结测试来源、九月两段留出录像和另一组排除录像都不打开。来源划分沿用既有登记：例如某段测试录像始终属于测试，更新前的材料只能用作开发。
  • 每段录像中“战斗进行中”的画面，在源时间上按 500 毫秒网格请求帧，共 108,994 个请求点。
  • 机时估计：整帧 OCR 按每帧 0.3 秒算约 32,698 秒，远超单个部分约 7,200 秒的 GPU 壁钟预算。

方法（计划）

  1. 扫描。 每个网格点取之后的第一张原生帧，只记录实际时间戳。可变帧率导致多个请求点落到同一帧时，保留同一实际时间戳和各自的帧计数；实际场景已经变了的点记为“源场景不同，不可用”。每个请求点都有“有提议 / 未知 / 不可用”记录；“没有提议”不等于已确认没有预览。
  2. 先找数字区域，再 OCR。 不做整帧 OCR，而是用“原生亮色字形、相邻成行、暗背景”的规则提出可能的数字区域；连续帧同一位置、像素几乎不变的裁图合并成一个出现列表。这个提议器的召回率尚未验证，不能说“全部预览都找到了”。
  3. 拼图 OCR。 最多 16 个原生裁图排在一张四列、带间隔的图上一起 OCR，再按每块的位置精确映射回原坐标；跨块的文字不归入任何裁图。这种 OCR 结果明确标为“只限区域”，不冒充整帧缓存。
  4. 抽查无提议帧。 每个整分钟没有提议的帧额外保留原图，做真实整帧 OCR 和公共读取器对比；抽查不能证明其余无提议帧都对。
  5. 与公共读取器对比。 只有读到数值的提议才补存原生整帧，并要求重新提取的对应裁图与原裁图逐像素完全相同；对比时使用真实的整帧 OCR、卡片数量 OCR 和图标匹配。
  6. 种类预标注。 数字形状、括号百分比、多对数字都不能决定是近战、远程、法术伤害还是多目标。绿色两行只按已有实验的模式给“治疗”候选；少量此前实验中动作与位置 / 数值明确对应的例子给种类预标注，其余记“其他 / 未知”。目标只有在能引用明确日志关联时才给候选。
  7. 人工审核与合并。 审核页每批 500 项，先确认是不是预览，再确认种类、数字、图标、目标和依据；逐字段导出时带原始值快照，合并脚本会拒绝异源、旧快照、非法值、冲突和未知字段。所有机器字段在用户确认前都是预标注（PRELABEL）。
  8. 评分。 按种类列出数值与参考一致 / 不一致 / 未读 / 未对比，不把机器一致率叫准确率；人工审核分母为 0 时比率为空值。治疗被公共读取器主动跳过的，仍记为“治疗数值未读”。

GPU 引擎启动和常驻处理的累计壁钟上限为 7,200 秒；每次 OCR 前检查游戏是否在运行，运行时暂停，之后沿用累计预算恢复。不安装新软件包。

设置

所有耗时命令计划通过一个限制在 8 个 CPU 核上的包装器运行。解码默认用 CPU，也可选用有保护的 GPU 解码；解码耗时单列，不算 OCR 机时。

结果

已经完成的只有：

  • 扫描计划文件：49 段准入录像、108,994 个请求点、整帧 OCR 估计 32,698 秒。
  • 13 项专项测试通过（每个实验在独立的 Python 进程中运行）。
  • 对 5 张已有的开发集原生图做了目视诊断（远程、治疗、延展、近战，以及目标已离开的一帧）。发现：淡出中的预览帧亮度低于普通白字；500 毫秒网格可能错过很短的预览。计划把已记录的短预览单独列为补充样例，不混入每秒 2 帧的覆盖计数。这是助手目视诊断（CODEX_VISUAL），不是人工审核。

失败与负结果

  • 一次把多个自包含的实验目录放在同一个 pytest 进程里运行时，同名模块（common、merge）的缓存互相串用，造成 2 项失败；分别在独立进程中运行后全部通过。
  • 法术伤害和多目标预览的种类判断方法仍然没有。

局限

  • 全量扫描、GPU OCR、实际读取器表现和审核页面质检都没有执行，所以没有任何覆盖或准确率结果。
  • 数字区域提议器的召回率未验证。
  • 软件测试和诊断拼图不能代替实机字段验收。

结论与下一步

本实验交付的是一份可执行的计划和工具：在机时预算内覆盖大量战斗画面、保留所有未知和未读、不把无提议当作负样本。下一步是在机器空闲、并获得用户同意后执行全量扫描与 OCR，再做读取器对比和人工审核。