从状态图标读到法术效果

P68 / P86 · 状态图标与时间 · 实验记录与相关篇目

P68 / P86 · 状态图标与时间采集 → 提示文字／状态图标 → 局部读字与字形 → 原图审核

图标与OCR已接视频链。字形对照找回8个开发参考中的∞（5个来自设计录像），118数字和448未占用槽位未误报；不覆盖原OCR。仍有父面板漏检，规范身份和可靠剩余回合未知。

在《英雄无敌：上古纪元》的战斗中，日志会记录施法和伤害；打开生物面板，还能看到状态小图标。鼠标停到小图标附近时，会弹出效果说明。我们想从录像读懂这些状态，第一件事却是：别把只出现一会儿的说明漏掉。

这条路线先找回短暂的悬浮画面，再自动寻找说明文字、状态小图标和下面的数字。视频流程可以直接运行图标定位和角标读取。普通数字已有局部开发结果，∞却被多个OCR读法同时误认；字形对照补上了这批可见符号。下面解释为什么看清数字、读对符号、知道可靠的剩余回合，是不同的问题。

9月23日更新：局部面板的状态行和悬浮说明，都已接到可选视频流程。 整图仍可保留未知；通过局部检查的面板单独进入读取。两张圣骑兵面板的角标读到“2”，进一步回放53张旧图，15张读到提示标题和正文，并显示同帧图标位置候选。新增接线结果也保留两张半透明失败，不等于关键帧质量、效果身份或剩余回合已经可靠。下文的历史测量各自保留，不把成绩相加。

flowchart LR
 A[Recorded video] --> B[Offline frame sampling]
 B --> C[Candidate frames]
 C --> D[Find panel, status row and tooltip]
 D --> E[Read text and inspect counter shapes]
 E --> F[Review images and raw readings]

图 1：从候选截图找到面板、状态行和提示，再读取局部文字。图标框与字面读数现在都有自动候选；人工参考独立保留，供最后核对。图标的规范身份仍未知。

1. 施法记录，不等于当前剩余时间

假设一个正面效果原本持续 10 回合，之后又被“断援”缩短。只读最初的施法记录，就未必知道现在剩多少。减少负面效果持续时间的法术也有同样的问题：日志是否会另写一条更新？写的是减少量，还是新的剩余量？

本次还没有找到能核对这个问题的完整前后画面，因此答案仍然未知。已有日志中，有的效果写出持续时间，有的截图只显示施法和伤害。两种现象都不能推出“日志总会写”或“日志从来不写”。

我们要分开保存三种信息：日志当时写了什么、当前图标旁显示什么数字、悬浮说明解释什么效果。这样即使日志缺少某个字段，也能继续从实际界面找证据，而不是根据初始时长猜答案。

2. 录像里确实有可读的状态悬浮画面

此前的 OCR 数据里，有一张生物面板显示四个状态小图标及数字 2 / 6 / 3 / 7，却没有显示说明。回到同一视频附近逐帧检查，就找到了下面这张图。

图 2：录像 2026-09-08T02-42-52.657Z 的约 1647.5 秒。说明写着“先攻值提升 2，生命值上限提升 20%。”鼠标靠近第二个状态槽，其下显示 6。原生分辨率裁图，保留游戏文字；文件名含 UTC 标记，秒数是近似媒体时间。

再往后几秒，另一个单位的面板出现了另一种状态说明。

图 3：同一录像约 1655.4 秒。说明写着“受到的魔法伤害提升 50%。”鼠标在第四个小图标边缘，其下显示 2。这里读到的是“寒霜刺骨”，不能因为它与寒冰有关，就把它当成另一种法术的先攻减益。

这两张图合计标出 9 个小图标、9 个数字和两段说明的文字框。参考保留原图、时间与同帧位置关系，等待用户审核；没有把相似图标直接认成游戏数据库中的某个 ID，也没有把 6 和 2 自动写成“已验证的剩余回合”。要验证后者，还需观察回合推进或缩短效果前后的变化。

在本机的语义时间线中，可以查看这批原图、人工参考与 OCR 预测。图标位于 UI 文字/控件图层，数字与说明位于面板字段图层；只覆盖列出的部分，不代表整张图已经标完。

从“看到文字”到自动找到这块提示

整屏 OCR 可以读到“寒霜刺骨”，但还不知道这句话属于哪里。这一轮先沿用自动生物面板，再在模型下方附近寻找金色标题、左边缘对齐的正文和暗色背景。提示的文字和位置都来自当前截图；没有把上面的参考框或效果名字交给算法。

在已扫描的 467 张短悬停图中，程序找到了 4 张提示候选：一张“阿丽娜之触”，三张相邻的“寒霜刺骨”。它们只来自同一录像，所以是两种内容，不是四种效果。对另 513 张历史图回放时没有输出提示；那些图尚未逐张标全，不能据此声称没有误报。

这里出现了一次值得保留的失败。图 2 的说明分成两行，末行只有 20%。。最初程序只选含汉字的正文行，把这几个字符漏掉，却仍输出了前半段。修复后，数字行也进入完整段落，但旧读法因分数不够而拒识。第一步修掉的是“把截断文字当成完整答案”；接下来才是从像素中读回缺失的文字。

本轮用三张原图的稀疏参考核对：每张一个标题、一个整段正文，共六项。只采用完整覆盖该字段的 OCR 切块时，五项精确、一项拒识；汇集所有切块的严格读法只有三项精确、三项拒识。第三张参考在图 3 后 0.1 秒，属于同一次悬停。这些结果用于开发排错，不是独立准确率验收。

把自动找到的整段文字，单独再读一次

这次不再要求整屏 OCR 兼顾所有角落，而是把上一步找到的标题和整段正文分别裁出，交给本地 PaddleOCR-VL-1.6。它收到的只有图片，不含正确文字、人工框或效果目录。四张候选共产生八个裁图；每个裁图都试原尺寸，以及四周补八像素后放大四倍的版本。

“先攻值提升2，生命值上限提升20%。”完整读回来了。 两种尺寸的结果相同，均保留了末行数字。在有人工参考的三张图上，结果如下；一段多行正文只算一个字段。

读法	六项文字的结果
原整屏 OCR，只采用完整覆盖字段的切块	5 项匹配，1 项拒识
自动裁图，本地 VL 原尺寸	6 项匹配
同样裁图，补边后放大四倍	6 项匹配

这次不能说明放大更好：原尺寸已经读对，放大没有新增收益。也不能把六项匹配写成通用准确率；参考仍来自同一录像的两种说明，且参与过开发。网站保留旧拒识和两种新读数，不挑与答案一致的版本，也不覆盖旧字段。文字读对仍不等于知道它对应哪个图标，或当前还剩几回合。

打开候选与参考，可以左右切换原图，也可以只看本地预测。后续补扫又找出一张同次“寒霜刺骨”悬停，当时共五张；本节局部重读对应冻结的四张，不把第五张计入六项参考评分。这个汇总入口也包含下文继续扩充的录像，旧结果不会被覆盖。全部处理状态另列未扫描、场景跳过和没有找到支持布局的图片。这些状态都不等于“生物没有状态效果”。本节的方法只定位说明文字；后文再介绍图标与角标。文字到具体图标、单位或剩余回合的可靠绑定尚未完成。

展开视频接线与局部入口记录：流程可运行不等于全部读对

视频流程也能自动做这一步了

上面的实验需要单独运行局部读字。现在，启用这项可选步骤后，视频程序会从自动生物面板继续寻找状态提示，把标题和整段正文送给同一本地模型，再把结果放回语义时间线。不需要人工先画框，也不需要提供效果名字。

这次在四个既有开发运行的 328 张图上续接，找到两张提示，合计四个文字区域、八次原尺寸／放大读取。其余 182 张被场景判断跳过，144 张没有找到支持布局的提示。后两种状态仍可浏览；“没有找到”不等于画面没有状态效果。这是接线检查，不是新增328张数据，也不是新的准确率测试。

例如，“阿丽娜之触”的旧正文因末行分数偏低而留空，新局部读法则返回完整的“先攻值提升2，生命值上限提升20%。”网站把旧拒识、原尺寸与放大结果放在同一张卡里，不用新答案抹掉旧问题。来源文件或上游结果变化时，旧候选会失效；中断也会留下待处理状态。

为了检查这一步能否真正跟随视频程序运行，我们又从同一已曝光录像取20秒，用一个命令从原视频重新选帧和识别，而不是复制旧输出。11张代表图跑完了已配置的OCR、数字补读、行动条、生物与数量牌、面板和状态提示步骤，其中两张找到状态提示。这是端到端接线回归，不是新的独立视频；这11张有单独入口，可以看所有模块，不只看读得出的文字。

查看当前视频候选，或切到全部处理状态。加上这次回归，当时共339张图、四张提示候选，但仍只是同一录像的两种内容。读到标题和正文，还没有解决“属于哪个图标、哪个单位、还剩几回合”；这些字段继续留空。原有识别字段和在线接口没有改变。

局部面板找到后，继续读旁边的状态说明

旧视频入口还存在一个断点：生物面板已经通过自己的位置和外观检查，但整张图的场景仍是未知，因此旁边的提示没有进入读取。现在启用局部生物面板和状态提示两个可选步骤后，提示读取器可以使用这个已检查面板；暂停、断线和父面板质量检查仍然有效。

程序从当前原图自动找提示标题与整段正文，分别用既有 PaddleOCR-VL-1.6 读取原尺寸及四倍放大图。它还在同一原图定位状态槽，按事先固定的位置规则，记录提示可能对应哪一槽。不把参考答案交给算法，也不凭效果名称反选图标。

这次复用同一旧录像三个片段的全部53张候选：15张找到提示，共30个文字区域；23张未找到支持的提示布局，15张被场景检查跳过。逐图报告和实际时间线都能查看原图、两种读法和位置候选，旧读数没有被覆盖。

已有参考里7张清楚提示共14项，原尺寸和四倍读法各有14项相符，旧完整切块为11项。三个差异全是英文逗号与中文逗号，汉字和数字本来就一致。 因此本轮不能宣称读字内容变准了；真正改善的是文字能进入实际步骤，并与图标位置一起展示。15次位置关联虽都只有一个候选，仍没有明确关系标签来计算准确率，更不代表效果或剩余回合已确认。

另外两张参考标为半透明，也被入口接受了。即使四项文字都读对，按当前选帧要求仍是质量失败，不能混进清楚帧成绩。四张有“无提示”参考的图没有多报，其余未标注帧不算正确或负例。所有参考仍待CTO审阅，这不是独立录像验收。

本轮实际处理约148秒，包含模型启动，不包含之前的视频采样和整屏OCR；同时还有软件测试运行，不能当受控速度基准。只新增约21.7 MB结构化记录，没有复制图片或生成视频。续跑保留了117个证据文件，但仍需加载模型。下一步应优先复用已完整读出的文字，只在真缺字或冲突时补读，避免为标点差异重复计算。

3. 五张图不变，但把间隔缩短

原来的候选筛选器比较连续五张图，判断它们是否足够稳定，再合并相近画面并选出较清晰的代表图。每秒采 5 张时，五张图的首尾相隔 0.8 秒；每秒采 10 张时，相隔 0.4 秒。缩短这个窗口，有机会留下停留时间较短的说明。

我们固定了四个已看过的录像中的八段一分钟片段，共八分钟，覆盖状态面板、法术书、技能说明、攻击相关操作和日志。三个方案使用同一稳定性模型，没有新增训练；主要对照只改变采样频率。第三个方案另外加强了局部变化检查，并限制合并片段的长度。

离线方案	留下的候选图	13 个已检查机会中留住多少
5 fps，连续五张	148	8
10 fps，连续五张	235	11
10 fps，另加局部细节保护	1,814	11

这 13 个机会来自原视频画面检查，不是通过 OCR 成功与否来定义；但它们不是全部事件的清单，也不是盲测集。同类内容再次打开也单独算了一次，因此不能把 11/13 宣传成整套视频的召回率。

普通 10 fps 新保住了图 2 的状态说明、一处法术说明和一次重新打开的技能提示。图 2 的说明在密集检查中只见于 1647.3–1647.6 秒的四个采样点。稳定性模型允许小范围变化，所以它能保留这张图；“五帧稳定”并不要求所有像素一动不动。还有两个仅见于两三个采样点的极短提示，三个方案都没留下。

局部细节保护则留下太多图：生物模型的待机动画也会触发变化。在这 13 个例子里，它没有多找回一个机会，却明显增加了 OCR 工作量。因此，下一批离线采集采用普通 10 fps、连续五帧；不启用细节保护作为默认方案。

三个方案合计产生 1,868 个不重复时间点。首批安排的 403 张高精度 OCR 已全部完成：包括两个普通方案留下的全部 339 个不同时间点，再加 64 张按时间分散选出的细节方案独有图。首批结束时还有 1,465 张待处理。OCR 沿用此前选出的全图、多尺度局部扫描组合，没有根据这两张参考重新调参。

这批 OCR 产生了 20,116 条可搜索读数，单图处理耗时合计约 20 分钟。两张状态参考中的 9 个数字与 5 行标题／正文都在相应位置读到了；但“寒霜刺骨”图的第一个图标里还误读出 2S。所以这只能说明示例文字可读，不能写成“全图 100% 准确”。

9 月 19 日先在八段素材里各补扫八张，得到 467 张已扫图；上面的四张自动提示和局部重读使用这个冻结批次。随后又按时间分散各取十六张，新增 128 张，当前是 595 张已扫、1,273 张待扫，共 29,552 条可搜索文字候选。本轮补扫入口与上一轮分开，旧输入不覆盖。这仍是原来四个开发视频的覆盖扩展，不是新增独立视频，更不是新增人工真值。

这次只改变录像的离线采集。在线系统什么时候截图、OCR 每秒能处理几张，需要单独设计；这里的 10 fps 不要求在线 OCR 也达到 10 fps。

4. 换录像后，漏检发生在读字之前

为了扩充素材，我们先扫描了其他开发录像中97张开局附近候选，又扫描158张较晚窗口的候选，都没有找到新的状态悬浮说明。后来发现，较晚窗口有的已进入下一局选秀或结算。直接把采样时间往后移，并不能保证采到交战后的状态检查。

于是改为先检索已有场景索引中的生物面板，再看原图，找到右侧状态条附近确实弹出说明的位置。这里的索引只是找图线索，不是正确标签。确认后，在三段开发录像中固定六个短窗口，共142秒，再用不变的10 fps五帧算法选出88张图，全部完成OCR；它们独立于前面的旧批次保存。

这次收获了两段录像中的13张可读状态提示，包含八种标题，例如“注能盔甲”“多里斯之潮”“天堂之刃”和“厚皮”。我们逐原图标出标题与整段正文，共26项；还选了六张容易混淆的画面，包括左侧能力说明、英雄装备说明、魔法书，以及有状态条但没有悬浮框的生物面板。它们是开发参考，含重复悬停，也有半透明但文字可读的情况，均待用户确认。

固定13张正例，26项标题／正文	精确匹配	拒识	因场景门控未处理
汇集所有整屏OCR切块，严格检查冲突	10	10	6
只用完整覆盖文字的切块	20	0	6
自动裁图，本地VL原尺寸	20	0	6
相同裁图，补边后放大四倍	20	0	6

有10张图读全了，但不能只报“20项全对”。 另外三张正例，在进入提示检测之前就被场景判断跳过。它们的布局接近旧参考中的“过渡画面”，即使当前文字可读，也没有得到局部裁图。下面就是其中一张。

图4：录像2026-09-07T07-19-51.684Z的1799.8秒。标题“厚皮”、正文“受到的近战伤害减少30%。”都可读，却被上游场景门跳过。下方显示10 / ∞ / 10；逐项保存字面，不把∞强行转成整数，也不凭这张图断言数字的变化规则。原图局部直接裁出，没有放大或改写像素。

不能为了这三张图取消场景检查：它也在过滤选秀、结算和真正的过渡画面。下面单独比较“是否可能是战斗界面”和“这块文字能不能读”，同时检查负例。更强的OCR或更大的裁图，无法补回一个根本没有被送去识别的区域。

六张相似画面负例中，五张进入流程后没有被误报为状态悬浮；另一张被场景门跳过，不能算作检测器判对的负例。未做参考的其余图片也不计入准确率。在五张图上另补了27组图标框与原始角标，加上面板、文字和负例记录，合计104项稀疏标注；这不是104种状态，也不是19张整图全部标完。

打开这88张及参考对照，可分别查看自动候选、局部两种读法和参考；也可只审19张稀疏参考。整屏OCR检索保留4660条未经逐项审核的读数。自动局部OCR实际跑了16张候选、32个文字区域；评分只使用其中与参考对应的10张，其他六张不能算作已验证成功。

5. 修入口，不需要先换OCR模型

原规则把历史参考图的“转场”条件当作拒绝当前图的理由。但“与一张转场图相似”，并不能证明眼前的文字也不可读。新对照仍要求颜色与边缘都同意这是战场生物面板；只有一方最像转场、另一方最像普通或遮挡面板时，才额外允许尝试读局部文字。两边都像转场，或当前OCR明确发现暂停、断线等情况，仍然拒绝。局部质量检查也没有取消。

先在原有2,630张开发图上检查风险：新增9张战场候选，其中6张原标转场；没有新增非战场误收。这正说明它不能升级成“画面已稳定”的判断。另158张含选秀、结算的窗口，处理与跳过状态均未改变。场景文章保留了完整比较。

再重跑全部88张，而不是只跑已知漏检的三张。程序找到19张状态提示候选，比旧入口多三张；同一组13张正例的26项参考结果如下。

固定26项文字	旧入口	新离线入口
完整覆盖切块的原OCR	20匹配，6未处理	25匹配，1低分拒识
自动裁图，本地VL原尺寸	20匹配，6未处理	26匹配
自动裁图，放大四倍	20匹配，6未处理	26匹配

新增部分先靠入口修复读回五项，最后一项由局部重读补回；并不是放大四倍才读对。六张明确负例这次都进入流程，均没有被定位为状态提示。其余未逐项标全的图片不计正确，19张候选也不等于19种状态。

打开新入口与参考，可以在同一帧切回旧入口，看到原来的跳过或拒识。图4的“厚皮”现在已有标题和完整正文候选。这批参考参与了开发，26项匹配不是新视频的通用准确率；线上默认、图标身份与剩余回合语义均未改变。

6. 不认识图标，也可以先找到它下面的数字

生物面板右下角的小图标排成一行，间距基本固定。程序不必先知道“这是厚皮”才能找到那个位置：先沿用自动生物面板，在可能的九个槽位检查圆环，再把每个圆环下方的角标单独裁出。这也把两个问题分开了——找到图标，不依赖OCR是否已经读出了数字。

只按金色找圆环的第一版全漏了。看原图才发现，圆环外圈偏灰绿，并不是稳定的金色。改成检查圆周上的亮点，同时要求下方外围仍是暗背景后，才能排除空槽位和模型底座的亮纹理。位置规则来自两张已有开发图；后面的五张对照也已在此前实验中看过，因此只是开发排错，不是新视频盲测。

在同一88张图里，37张找到状态行，合计230个图标候选；其余51张没有支持的自动生物面板。五张已逐项标过的状态行里，共27个图标：新方法全部匹配，没有多框；如果把每张九个槽位都当图标，就会多出18个空框。另158张混合画面没有输出图标，但尚未穷尽标注，不能据此宣称没有误报。

接着把230个自动角标框交给本地PaddleOCR-VL-1.6，每框分别用原尺寸、补边放大四倍读一次，共460次。在已有参考的27个角标上：

读法	字面完全相同	读错	拒识
原整屏OCR	12	0	15
自动小图，原尺寸	26	1	0
同样小图，放大四倍	24	2	1

单独读小图有帮助，继续放大却不保证更好。 图4中的∞，原尺寸读成了00，放大后读成8；另一张图里的4被读成14，鼠标正靠近那个数字。我们没有根据参考把答案改回来，也没有从两次结果中挑一个“看起来正确”的版本。

打开自动状态条与参考，能看每个图标框、同槽数字框，以及整屏、原尺寸和放大三种读数。不一致时会提醒回看原图。这里建立的是“这个数字在这个槽位下面”的位置关系；尚未确认图标名字、所属单位，也不把读到的数字直接写成剩余回合。

再问一步：没有图标的地方，会不会也画框？

只有带图标的图片还不够：如果程序总把九个槽位全画出来，也能“找到所有图标”，却会制造许多假目标。所以我们从两批已有图片中，先取出全部23张自动生物面板，直接看原图标出5张有图标、18张空条，再运行上一轮冻结的算法。这些图来自七段已曝光录像；有的属于同次悬停，两张还接近此前制定位置规则的画面，因此仍是开发对照，不是新视频盲测。

12个可见图标全部找到，18张空条没有多画框。 相比之下，把所有槽位都当图标会多画195个框。随后对12个自动角标裁图读字，整屏OCR读对7个、拒识5个；本地原尺寸和放大四倍均读对12个。这轮没有改位置阈值或OCR模型，也没有根据参考选择读数。

打开这23张逐图对照，可以左右切换有图标的状态行与明确标过的空条。空条标注只表示“这个可见区域内没有图标”，不是断言该生物没有效果。程序实际处理了两批全部610张图，场景跳过、没有合适面板和不支持的分辨率也保留，不把这些未检测状态算成已审负例。

新读对的12个角标没有包含∞，不能算作修复了它。这个对照支持继续使用当前位置规则，但仍需要更多遮挡、不同布局和易错符号的例子。接下来先把已有方法接入视频流程，避免每次都要另外运行实验脚本。

展开状态行接入视频的运行记录

视频程序能直接找到图标，再读角标了

启用新的可选步骤后，程序沿用当前帧的自动生物面板，检查状态行的圆环，把每个图标下方的数字分别送给本地OCR。原尺寸和放大四倍的读数都保存；两者不同就并列显示，不根据参考答案挑选。即使某个数字还在等待或读取失败，已经找到的图标框也能查看。

先在五个既有开发运行的339张图上续接：10帧找到44个图标候选，88次局部读取完成；145帧没有支持的自动面板，184帧被场景判断跳过。程序没有重写旧识别字段，也没有读取人工参考。这里验证的是流程接通，不是新标注了44个图标，更不是44个都读对；有些画面来自同一录像的重复运行。

随后从同一已曝光录像的6秒片段重新选帧，用一个命令跑完配置的识别步骤。7张代表图中，3张找到12个图标，24次角标读取完成；另3张没有支持面板，1张没有找到圆环。再次续跑时，35份上游文件保持不变。这7张有单独入口。加上这次回归，汇总入口是346帧、13帧含56个图标候选；它仍不是未见视频验收。

打开视频流程的图标与角标，可查看图标框、数字框、整屏OCR与两种局部读法。全部处理状态还包括没有候选的帧。来源图片、上游面板或原始OCR变化时，网站会隐藏旧结果并提示重新处理；中断后则从保存的最后一步继续。

这一步只建立“数字在这个图标槽位下方”的位置关系。图标是什么效果、属于哪个具体单位，以及数字能否当作剩余回合，仍需后续证据；原来的∞误读也仍然存在。

鼠标挡住数字时，参考答案也应该是未知

接通流程后，继续重复干净截图的价值有限。我们转向四段已有开发录像，先从场景索引找生物面板，再看原图选定八个窗口，共78秒。采样和识别参数不变，得到66张新候选，全部完成整屏OCR；随后在其中32张原图上，独立标出63个图标、61个可读角标，以及两处被鼠标挡住的角标。另六张是可见状态条为空的对照。32张包含同次悬停的相邻画面，不是32个独立事件；这些仍是待用户确认的局部参考。

图5：录像2026-09-07T03-16-25.445Z的1349.6秒和1350.0秒，原尺寸裁图。上图第二个角标的关键笔画被鼠标挡住，下图才清楚显示6。我们不能拿下图的答案补进上图：当前评价的是单张图片能够提供什么证据，而不是凭前后文猜数字。

冻结的检测方法找到了63个图标，没有漏框或多框。六张空条没有误报，但它们都因缺少自动父面板而没有进入圆环检测，不能算作圆环检测器判对了六张负例。只对61个能从原图读清的数字评分，两处未知另列、不算对错：

读法	字面匹配	拒识
原整屏OCR	42	19
自动小图，原尺寸	60	1
自动小图，放大四倍	59	2

拒识不全是图像不清楚。一处1紧挨鼠标，两种局部读法都返回了字母I；另一处清晰的1，放大后返回带下划线的公式写法，当前数字解析器没有采用。这轮保留失败，不根据参考改答案，也没有调整模型或阈值。小图重读继续有用，但“再放大一些就一定更准”仍不成立。

打开32张参考与预测，可以看到图标、可读数字和“角标被遮挡”三种记录；全部66张还保留未找到面板的画面。整屏OCR入口包含3364条可检索候选，它们不是新增真值。这批没有找到新的∞或不同分辨率布局，因此这两项缺口仍然保留。

为什么多个模型都把∞读成8？

前几批普通数字比较容易读对，却只有一个∞样例。为了不被总体成绩掩盖，我们从另外四段开发录像的场景索引中，提取并查看205张原尺寸状态行。在两段录像里找到了更多∞，也找到了11 / 12 / 13和数字8。随后固定七个短窗口，共54秒；不变的10 fps五帧筛选留下41张图，全部完成OCR。

这一次先看原图，再运行识别：14张状态条共标28个图标和角标，其中7个∞、4个8、5个双位数字。参考含相邻悬停画面，仍用于开发，不是独立测试集。下面的横向∞和竖向8，人眼能分开；我们想知道模型是否也能保留这种差别。

图6：从上到下为两段9月5日录像的4760.4秒、2962.4秒，以及9月6日录像的599.9秒。原像素裁图以最近邻放大两倍展示，没有修改符号。这里比较的是可见字形，不推断图标对应的法术或持续时间。

程序找到26个图标，另外两个没有获得可用的自动父面板。进一步检查发现，原因并不相同：一张的标题附近被悬浮提示挡住，缺少定位用的文字；另一张其实已找到面板，但左侧提示覆盖了质量检查区域，因此被拒绝。两张右下方的角标仍可见，这提示我们：以后应单独判断状态行是否可读，而不是直接降低整个面板的质量门槛。

对找到的26个角标，用同样裁框比较两种本地模型：先前的PaddleOCR-VL-1.6，以及专门读文字的PP-OCRv6_medium_rec。原尺寸、补边四倍、灰度补边两倍分别保存；文字识别器低于0.90分就拒识。没有把参考答案交给模型，也没有把8或00替换成∞。

自动裁图的读法	精确	读错	拒识
VL原尺寸	19	7	0
VL四倍	19	7	0
VL灰度两倍	18	7	1
文字识别器原尺寸	19	7	0
文字识别器四倍	18	0	8
文字识别器灰度两倍	19	0	7

没有一种读法读对这7个∞。 VL把它们读成8、00或80；文字识别器原尺寸全部读成8，分数仍高达约0.95–0.98。灰度两倍能让文字识别器拒识这七处错误，但“知道读不准”不是“读出了∞”。上表只评价已找到的26框，漏掉的2框也不能从端到端结果中消失。

这还不能解释模型内部为什么犯错，但足以否定两个捷径：放大不保证变准，两个模型给出相同答案也不保证正确。于是我们转向下面的字形对照，让程序重新看像素，而不是把所有8改成∞。

打开14张参考及六种局部读法，可同时看原始文字、分数和拒识原因；全部41张保留漏掉父面板的画面。整屏OCR入口另有2080条可检索候选，不是人工标注。

不猜OCR想写什么，直接检查两个孔的方向

在这套界面里，∞较矮而宽，两个孔横着排；8较高，两个孔竖着排。这个区别还留在原始像素里。新程序接收同一个自动角标裁图，只留下较亮的灰白笔画，再检查图形是否连在一起、是否有两个横向排列的孔。它在三个亮度阈值下各做一次，至少两次通过，才给出∞候选；其他情况不作判断。

图7：左列是自动裁出的原像素，最近邻放大四倍；右列只显示亮度阈值140下保留的笔画。前两行来自不同录像，孔都横着排；第三行是真实8，第四行被鼠标挡住。右列不是重新生成的文字，也没有补笔画。

规则先用一段9月5日录像确定，再固定下来检查其他已有开发图。五批共805张旧图被回放，其中有自动面板的部分产生882个槽位裁图；这不是新增805张标注。只对已有明确参考的部分评分，结果如下：

检查对象	结果
设计录像中的∞	5个，全部给出∞候选
其他已曝光录像中的∞	3个，全部给出∞候选
普通数字	118个，没有误报为∞
明确标过状态行中的未占用槽位	448个，没有误报为∞
被遮挡、参考为未知的角标	2个，均拒识；不算识别正确

这说明原像素中的形状线索，能补上这次OCR反复犯的错误。但八个正例仍很少，包含同次悬停，也都不是盲测；真实游戏里的00、不同字号和缩放还没有验证。单元测试中的合成00不能代替真实数据。其他四个相邻帧也输出了∞候选，但没有参考，不计入成功数。

审核网站把“独立字形对照”放在原OCR旁边，并能展开每个阈值的诊断。原来读成8或00的结果仍然保留，没有被悄悄改掉。字形识别也补不了上游漏检：这批仍只有26/28个角标获得裁图。读出∞依然不等于证明效果的持续机制。

展开字形检查接入视频的历史记录

从录像开始，字形检查也能自动跟着运行

现在，视频程序可以在图标定位与角标OCR之后，再运行一次可选的字形检查。它只接收自动找到的小图，不需要人工先框出∞。六个既有运行的346张图已经续接，原56个角标读数、各模块结果和未处理状态都保留；这是接线检查，不是新增标注。

为确认程序真的能从录像走完这条路，我们又对已用过的8秒片段重新选帧和识别。留下的8张图中，3张找到9个角标；其中3处原OCR仍写00，字形检查在旁边给出∞候选。另外3张没有合适的父面板，2张被场景门跳过，也都记在结果里。这段素材此前参与过开发，因此不能算作新视频验收。

当时的新视频变体已通过离线审核页面数据检查，但该次记录时标注服务尚未重启，还没有切换到网站；上面的字形实验对照仍可查看。下一步继续补局部面板遮挡和不同布局的例子，避免把“某一块被挡住”误当成“整张面板都不能读”。

左侧被提示挡住，右侧也必须放弃吗？

不一定。下面这张图左侧正在显示技能说明，右下的两个状态图标及数字1、3却很清楚。原程序检查的是左侧面板底色，因此连右边也一起跳过了。更合理的问题是：能否只给清楚的局部再一次机会，同时保持被遮挡属性的原有拒识？

图8：录像2026-09-07T23-07-52.932Z的1009.5秒原图。左侧的说明框并没有覆盖右下状态行。点击图片可放大；这里的1、3是本轮人工参考字面，不是新OCR成绩，也未解释为剩余回合。

第一次尝试失败了：我们检查状态行脚下的一条窄带，但它实际落在面板底边装饰上，把全部图标都拒绝了。另一个取消外观检查的诊断又加了“标题必须唯一”的条件，反而漏掉原有图标。这说明改进不能只看是否救回已知坏例，还得检查原来成功的图片有没有退步。

修订版保留原来已通过的路径，只在“面板已定位、左侧质量检查失败”时，检查右下数字周围是否仍有清楚的暗底，再运行原圆环检测。它不修改左侧属性，也不借邻帧补出缺失的面板。四种方案在同一批984张旧开发图上回放；其中76张有逐行参考，共132个图标：

方案	找到的参考图标	漏掉
原整面板检查	128	4
第一版局部窄带，失败	0	132
无外观检查，但额外限制标题	121	11
保留旧路径，只补局部	131	1

局部补充找回两张图中的3个图标，没有丢掉旧候选。 剩下那张缺少自动面板定位，仍然漏检。明确标过的25张空条中，19张真正进入了圆环检查且没有多框；另6张没有父面板，不算检测器判对。已知半透明图仍会被原质量门放行，这轮没有修好稳定性判断。

这些图片都已用于开发，包含同次悬停；984张也不是新收集或完整标注的图片。因此先保留为实验，不替换视频默认。下一步应补真实右侧遮挡、淡入和不同缩放的画面，而不是继续在这几张成功例子上调参数。打开四方案逐图对照，可切换原图、参考框、失败方案和新增候选，半透明失败也单列保留。

换一段录像，再检查“看得清”与“已经稳定”

接下来没有继续调整那几张旧图，而是回到四段录像，另取21张原图。其中12张来自一段真实的1920×1080录屏，并非把原来的2560截图缩小；另9张补充半透明面板、鼠标遮字和∞、双位数。这次故意不先筛掉不稳定画面，否则恰好会把需要检查的反例藏起来。

先看原像素，标出28个图标框、27个可读角标和一处遮挡未知，再运行不变的算法。正常可读行里的18个图标，原方案和局部补充都找到了，包括1080p录像中的6个。8张空行里，7张确实完成检查且没有多框；另一张缺少自动面板，不能算检测器判对。这些是新采集的开发参考，不是独立验收，也不是整图标完。

更值得注意的是下面这张图。战场和高亮格子透过生物面板，标题还有重影，但右下的8依然能看清。

图9：录像2026-09-05T03-51-52.729Z约2380.029秒的原始截图。旧质量检查仍允许继续寻找右下图标；局部补充沿用旧的成功路径，因此也没有挡住它。能框到这个图标，不代表已经拿到稳定画面。

四张明确半透明的图中，旧方案有两张因质量检查被拒绝、一张在场景判断时跳过，仍有图9这一张继续输出图标。取消外观检查的诊断还能多框出五个半透明图标，但这不是质量改进：我们的目标本来就包括避开面板切换中的画面。

这轮当时提出回查连续邻帧。后续P20已做五帧局部质量和三帧对照：更短窗口补回一些提示，但仍选入过渡图，没有换默认。这里保留当时的21张原图与四方案结果，不把后来的成绩写回旧表。该页可筛半透明反例、展开OCR与框，仍是独立审阅页，尚未并入主语义时间线。

7. 接下来验证图标与状态如何变化

现在可以继续按索引寻找不同状态与位置，检查自动图标框在更多画面上是否可靠。尤其需要同一单位在效果缩短前后都打开面板、同时还能核对日志的连续片段。只有后一种证据，才能回答本文开头的剩余时间问题。

图标识别也不必从零收集所有资料。之前检查的游戏安装包有 420 条状态配置行，其中 367 行带图标键，共 196 个不同键；但含测试或非竞技场配置，不是 196 个已确认可见类别。资源键也不等于已经核对好的屏幕小图模板。后续由游戏知识库维护身份和资产映射，识别程序允许保留“不认识”。

现在，短暂画面已经留下，自动文字读取有了跨录像样例，图标位置与角标也有了可逐项检查的基线。字形对照补回了这批∞，但定位缺口、陌生布局和状态前后变化仍需继续采集；可靠剩余回合不能只靠一次读字给出。