摘要
说明：这个实验目录里没有书面报告。本文是根据实验的脚本、帧选择决定、标注文件和已保存的评分结果补记（retrospective write-up）的，只写数据里能查到的内容。
开局选秀结束时，游戏会显示一个“全部确定”页，完整展示我方英雄：属性（攻击、防御、法力强度、知识、士气、幸运等）、主技能及等级（基础/高级/专家）、子技能、宝物、军队和法术。布阵和战斗中也能打开英雄窗口看到类似信息。这些决定了整场的构筑推断，漏一项就会影响后面的状态估计（SE）。
本实验（B185）是一组并行标注任务中的一项：为三段训练录像里的英雄窗口画面建立逐字段标注，再拿生产读取器（screenshot router 的 preparation 任务）逐字段打分。保存下来的评分覆盖 23 帧中的 16 帧：所有静止画面上被计分的字段全部读对；有悬停说明遮住部分区域时，读取器按设计整页拒读，另有一帧悬停画面没有检出英雄窗口。
要回答的问题
生产读取器在英雄窗口和确认页上，哪些字段读得对、哪些读不出、哪些是设计上不读的？
数据与来源
三段用户选定的训练录像：
| 简称 | 录像 | 角色 |
|---|---|---|
| 16:57 | 10 月 10 日 16:57 那局（前 23 分钟） | 开发集：读取器的很多规则在这段上定 |
| 01:39 | 10 月 10 日 01:39 那局 | 检验来源 |
| 08:38 | 10 月 9 日 08:38 与官方 AI 的对局 | 检验来源 |
16:57 和 01:39 已有按 2 fps 整理的画面时间线，从中取英雄窗口三类片段：确认页、布阵英雄面板、战斗英雄面板。08:38 没有现成时间线，本实验自己扫了一遍：整段解码 1,530 帧（到 764.5 秒），用生产的英雄窗口配准分数找候选，再逐个目视，只找到 75.5–96.0 秒之间的一个确认页和两次布阵面板。
标注等级：机器输出记为 PRELABEL，助手目视核对记为 MODEL_VISUAL_CHECKED，只有用户在审核页确认过的才是 REVIEWED。本实验的标注全部是 MODEL_VISUAL_CHECKED（1,698 项），外加 18 条 PRELABEL，没有 REVIEWED。
方法
- 选帧：把每个片段内每 0.5 秒一帧的英雄窗口区域分组成“视觉状态”（静止、某个悬停说明、淡入淡出），同一片段里重复的状态合并，生成联系表目视。每个片段取一帧静止画面（不取淡入淡出帧），每种不同的悬停说明再取一帧。悬停说明很短，2 fps 帧库的时刻与原生帧有约 0.25 秒偏差，所以几帧悬停被挪后 0.25 秒到说明框完整显示的位置。最终 23 帧：16:57 9 帧、01:39 10 帧、08:38 4 帧。
- 标注：在 2560×1440 原生帧上标英雄名、各项属性（确认页显示值可能是截断值，按画面写）、法力、主技能及等级、子技能、宝物按槽位、军队、法术、悬停说明全文。
- 评分：只调用、不修改生产读取器，CPU 运行。每个字段的结果分为：
| 结果 | 含义 |
|---|---|
| 正确 | 读数等于标注（空槽读成空也算） |
| 错误 | 读出了不同的值 |
| 未读 | 读取器有这个字段但没给值 |
| 漏检 | 读取器没有这个字段：没找到窗口或任务没跑 |
| 拒页 | 悬停说明盖住了要读的区域，读取器有意整页拒读 |
| 不计 | 设计上不读（例如英雄面板布局上的军队数量；三个等级共用一个图标的化身召唤法术等级） |
| 看不清 | 标注本身是 UNKNOWN，不计分 |
开发录像和检验录像分开统计。
设置
保存的评分文件生成时，23 帧里只有 16 帧读完（16:57 全部 9 帧、01:39 的 7 帧）；剩下 7 帧（01:39 的 3 帧和 08:38 的 4 帧）在评分之后才读完，没有重新计分。下面的数字只覆盖这 16 帧。
结果
按画面角色汇总（已计分的 16 帧）：
| 录像 | 画面 | 正确 | 不计 | 拒页 | 漏检 | 看不清 |
|---|---|---|---|---|---|---|
| 16:57（开发） | 静止 | 335 | 30 | 0 | 0 | 0 |
| 16:57（开发） | 悬停 | 65 | 7 | 169 | 0 | 35 |
| 01:39（检验） | 静止 | 350 | 30 | 0 | 0 | 0 |
| 01:39（检验） | 悬停 | 1 | 0 | 63 | 63 | 17 |
在已计分的帧上，没有出现“错误”或“未读”。静止画面里，确认页、布阵面板、战斗面板三种布局都覆盖到了（例如 01:39 战斗面板 195 项正确、确认页 90 项正确）。
01:39 的两张悬停帧：一张被读取器检测到悬停而整页拒读（63 项拒页），另一张读取器根本没检测到英雄窗口（63 项漏检）——这 63 项是错例清单里的全部条目。
每次完整读取（整个路由，不只英雄窗口）的耗时：热启动 14 次调用中位数 56.4 秒、最大 105.9 秒；其中英雄窗口这一步在读成功时约 13–34 秒。这是 CPU 上、整屏所有任务一起跑的数字，与实时要求相差很远，也可能受同时运行的其他任务影响（未记录）。
失败与负结果
- 一张检验录像的悬停帧，读取器没有检出英雄窗口（整页 63 项漏检）。
- 悬停说明出现时，读取器整页拒读，这是设计行为，但意味着有悬停的帧上什么都读不到。
- 评分没有覆盖最后读完的 7 帧，其中包括 08:38 整段录像；所以检验来源实际只有 01:39 一段被计分。
局限
- 原实验没有写报告；本文只根据代码和保存数据整理。
- 标注是助手目视核对（MODEL_VISUAL_CHECKED），不是人工审核；不能把“全部正确”说成准确率。
- 帧数很少（每段录像几个片段），同一英雄、同一构筑在多个帧中重复出现。
- 悬停说明全文只作标注，读取器不读它们，没有计分。
结论与下一步
在已计分的静止画面上，生产读取器对英雄窗口和确认页的各字段没有发现读错；主要问题出在悬停说明遮挡和一帧没检出窗口。需要补的工作：对剩下 7 帧（尤其 08:38 录像）重新计分，写出正式报告，并由用户审核标注。
Comments