摘要
一局竞技场对战要经过很多画面：主菜单、选英雄、选主技能和子技能、选神器、选法术、选生物、确认属性、排兵布阵、战斗、结算。后面所有“读数”程序都需要先知道当前是哪个画面，才知道该去读什么。
本实验做了一个基于文字识别（OCR，Optical Character Recognition，把图中的字读成文本并给出位置框）的场景分类原型：先读出整张截图上的文字和位置，再用可编辑的“文字 + 位置”规则判断当前画面；另外用一个只看过去帧的小型状态机（阶段解码器）给出整局进行到哪一步。
在两段开发录像共 640 张关键帧上，高精度 OCR 路线让 467 张得到了具体场景、173 张保持“未知”；只用 Windows 自带 OCR 时是 457 张和 183 张。这些都只是有多少张给出了判断的计数，不是准确率：截至报告时，没有一张关键帧有人工确认的场景标签。
要回答的问题
- 只看截图上的文字和它们的位置，能否可靠地判断当前处在哪个画面、有没有弹出层（例如提示框、法术书、暂停菜单）？
- 能否在不看未来帧的前提下，给出“整局进行到哪个大阶段”的连续判断，并在画面跳回早先界面时不胡乱改写？
- 要让人工核对这些判断，需要什么样的标注与评估流程？
数据与来源
- 两段用户自己录的开发录像（下称“录像一”和“录像二”），时长分别约 38 分 29 秒和 48 分 29 秒。两段录像都参与了规则的设计，因此都不能当独立测试集。
- 关键帧：每秒解码一帧做候选，按画面局部变化挑选，每段录像保留 320 张，共 640 张（录像一扫描 2,311 帧、录像二 2,910 帧，解码失败 0）。挑选时会看前后帧的变化，属于事后挑帧，不能当作实时策略。
- 早期还有一个按 5 秒间隔采样的视频基线：录像一采 462 帧，其中 60 帧给出场景、402 帧未知；录像二采 582 帧，35 帧给出场景、547 帧未知。
方法
整体数据流：
截图 → OCR 文字和位置框 → 文字元素
→ “文字 + 位置”规则 → 当前场景 / 弹出层
过去的观察 → 阶段解码器 → 整局大阶段
人工更正 → 规则编辑器 / 单独的参考标签 → 评估1. 读文字。 每张 2560×1440 的关键帧跑两遍 PP-OCRv6 中等模型（一个开源 OCR 模型，在 GPU 上运行）：一遍用原图，一遍放大 1.5 倍并做局部对比度增强。重复的同文字框只保留得分高的。Windows 自带 OCR 的结果只在不与 PP-OCRv6 任何框重叠的地方补充进来。每个输出都记录引擎、图像版本、模型得分和位置。
2. 文字到场景的规则。 一条规则写明：要求哪些文字（可有多个备选写法）出现在屏幕的哪个归一化区域，以及哪些文字出现就排除。例如：
- “选择英雄”出现在上方中间 → 选英雄画面；
- 右下角“全部确定”加上三个不同区域里的技能等级名 → 选主技能画面；
- 子技能画面没有固定标题，就用“父技能一行 + 三个不同位置的选项名”的版面判断；
- 多人游戏子菜单用多个子项文字和位置判断，不假设旧的按钮坐标。
所有必需文字都匹配才算命中，互相冲突的规则打平时就弃权，输出“未知”。规则得分不是校准过的置信度。
3. 分层的场景结构。 一个“基础场景”（整屏的状态，如主菜单、选主技能、布阵、战斗中）加一个“弹出层”（如法术书、提示框）。每个基础场景只允许特定的弹出层，例如法术书只能出现在战斗中。后来这套结构整理成一张有 22 个节点、30 条有向边的场景图。
4. 只看过去的阶段解码器。 大阶段按一局的顺序排列（游戏准备 → 选英雄 → 选技能 → 选神器 → 选法术 → 选生物 → 属性与确认 → 布阵 → 战斗 → 结算）。从第一次明确的阶段证据开始；向前切换（或回到主菜单）需要 45 秒内两次一致的观察；允许录像跳过某些阶段；回到明确识别的主菜单就视为新一段流程。识别不出的帧可以保留阶段上下文，但当前场景仍是“未知”，不会继承上一帧的弹出层。解码器不读未来帧，有专门的“只给前缀”测试。
5. 标注与评估工具。 在项目已有的数据审核网页里加了场景视图：显示原图、OCR 框、当前判断和用来判断的文字；可以直接把某个识别出的文字加进规则；也可以对单帧填写人工参考标签（草稿 / 确认 / 不确定）。评估程序先产出预测，再读已确认的标签，并分别报告阶段、基础场景、弹出层的分母；草稿和不确定的标注不计入，没有确认标签时准确率为空值（而不是 100%）。
设置
| 项目 | 设置 |
|---|---|
| 关键帧 | 2 段录像 × 320 张 |
| OCR | PP-OCRv6 中等模型双遍 + Windows OCR 补充；对照为仅 Windows OCR |
| 规则 | 开发版文字场景规则（两段录像上设计） |
| 阶段解码 | 45 秒内两次一致才前进；不读未来帧 |
结果
OCR 路线对比（640 张关键帧）：
| OCR 路线 | 完成帧 | 文字元素 | 给出具体场景 | 未知 |
|---|---|---|---|---|
| PP-OCRv6 双遍 + Windows 补充 | 640 | 28,962 | 467 | 173 |
| 仅 Windows OCR | 640 | 18,185 | 457 | 183 |
按录像拆分（高精度路线）：
| 录像 | OCR 帧 | 文字元素 | 已知当前场景 | 未知 |
|---|---|---|---|---|
| 录像一 | 320 | 14,240 | 253 | 67 |
| 录像二 | 320 | 14,722 | 214 | 106 |
换用高精度 OCR 后，有 17 张帧的判断发生变化；这 17 张都对照缩略图看过，新增的主菜单、技能、布阵、法术、暂停和信息面板判断与截图可见内容一致（这是模型/助手目视核对，不是人工审核）。
“每个场景需要标注几张？”的版面审计：两段录像里共匹配到 46 个规则锚点文字，其中 37 个的位置漂移（第 95 百分位）不超过屏幕的 3%，5 个需要更宽的区域，4 个是会移动的战斗日志或提示框文字。主菜单展开 / 收起会让部分文字移动约 8%，因此建模成两个不同的弹出层状态。结论是：每种不同版面标一张代表图足以起步写规则，但不足以估计准确率。
另一个审计查了更早的“标题文字识别给出实体候选”的待审对象：生物选择 1,815 个中 1,803 个由 OCR 给出了首选候选、12 个弃权；主技能 513 / 508 / 5；子技能 151 / 128 / 23；神器 2,514 / 1,341 / 1,173（神器弃权里 1,074 个是版面不匹配）。这些同样是覆盖计数，不是正确率。
失败与负结果
- 最早的视频基线（演示版 v1）把录像二 00:55 处暂停的战斗误判成了准备画面。v2 收紧了距离阈值，对不支持的弹出层判断改为输出“未知”，这个失败现在会弃权并留在审核队列里；v1 的错误结果保留并标记为已被取代。
- 用户指出过一个具体错误：多人游戏子菜单展开后，“寻找对手 / 大厅 / 排行榜 / 同机轮流模式”出现在“多人游戏”下方，把“其他”按钮往下挤；按固定坐标的基线把“其他”框到了“大厅”的位置。两张相关帧做了更正草稿，但当时固定版面识别器本身没有修好。
- 曾被当成独立画面的“英雄技能总览”，经用户确认其实是技能选择中的翻页过渡帧，已从场景图中删除，相关 5 个指针改为“过渡”。
- 第一次直接以脚本方式运行高精度 OCR 时，仓库里的同名模块遮住了 Python 标准库，导致导入失败；这次失败的运行目录保留。
- 有些场景规则在这两段录像里一个例子都没匹配到；战斗画面多是图标和数字，没有可读标题的法术书、标题被遮挡、艺术字、淡入淡出都可能保持“未知”；提示框里恰好出现某个关键词也可能造成误判。
局限
- 没有准确率。 截至报告时 B021 已确认的阶段 / 场景标签为 0；640 张都是助手生成的草稿。项目里旧的场景审核视图中有 17 条“审核正确”，但只有 1 条是用户明确审核，另 16 条是导入的助手审计参考，不能算 17 个独立人工确认。
- 两段录像都参与了规则设计，不能把其中一部分重新命名成“留出集”。
- 阶段解码器的 45 秒、两次一致等参数是开发期经验值，未在独立的连续窗口上验证。
- 场景图是一种暂定的分类体系和时间先验，不是经过验证的游戏状态追踪器。
- 报告当时请求的外部审阅一度因页面超时没有提交成功；之后的设计以后续收到的外部审阅意见和更新的路线图为准。
结论与下一步
这个实验交付的是一个可解释、可编辑、可评估的场景分类闭环：OCR 提取文字、按位置写规则、分层分类、只看过去的阶段上下文、规则编辑器、单帧参考标签和可复现的评估程序。它没有证明完整覆盖或生产可用的准确率。
报告给出的下一步是：
- 先就“没有弹出层”和“看不清弹出层”等语义达成一致，审核一小批多样的开发帧（计划约 60–90 张）和若干段跨越场景切换的短连续窗口，别只挑当前弃权的帧。
- 把错误归到具体层：比较真实 OCR 与人工更正后的关键文字、只用文字与文字加位置的规则、单帧判断与阶段解码，分别统计。
- 只针对这些已归因的失败去改阶段逻辑；在冻结规则之后再用新录像检验泛化。暂不引入大模型做运行时分类，也不先训练新的场景模型。
Comments