摘要
在这款游戏里点开英雄，会弹出一个英雄面板：上面有英雄名字和职业、等级、攻击/防御等属性、魔法值和经验值（写成“当前/上限”的分数）、8 个主技能槽和下属子技能、14 个装备槽、7 个部队槽及各自数量。战场两侧的 HUD 也显示双方英雄的法术强度和魔法值。这些信息对推断对局状态很有用。
本实验先做了一个私有读取器：复用已有的英雄面板定位、外观检查和 27 个按位置读取的字段，加上两侧 HUD 共 4 个字段。在冻结代码后才第一次读取原图，四张图各读一次，不重试、不调参。可评分的字面读数 83/103 正确、18 个未知、2 个错误；完整状态通过 0/4；装备/背包是否占用、对局阶段这两项根本没有实现。随后只做了一处很小的编码修复，并写出一份尚未批准的公开输出格式草案，供下游消费者评审。
要回答的问题
- 用现有组件拼成的英雄面板读取器，在真实截图上能可靠读出哪些字段？
- 失败主要来自哪里？是“数字认不出”，还是“缺乏第二路证据支持”？
- 下游模块需要一个什么样的、最小且严格的公开输出格式？
数据与来源
- 四张已经曝光过的开发截图（来自项目的数据整理），其中一张是 JPEG。独立验收对局数为 0，所以这不是留出测试。
- 参考值由数据负责方提供；参考给出的近似包围框不是检测真值，因此不计算 IoU。
- 读取器只接收图片路径、帧编号、来源编号和选择时间，不接收任何参考值、人工框或头像在哪一侧。
方法
- 定位：复用现有局部英雄面板定位和当前皮肤外观检查。定位器内部的“战场布局”开关只是几何提议，不当作阶段观察；四张图的上游场景都是“未知”，阶段、归属、当前行动者全部保持未知，不提交给游戏状态。
- 读字：整图做一次 OCR（PP-OCRv6），再把 27 个面板字段和 4 个 HUD 字段裁出来，以原尺寸和 3 倍放大两个尺度各读一次。面板字段要求：两个局部尺度分数都 ≥0.90、解析结果完全一致，并且整图 OCR 在同位置有一致读数。HUD 字段只要求两个局部尺度一致。不修字、不借其他区域、不降阈值。
- 分数字段（如魔法 0/310）：保留原文本作为父项，再拆出“分子字面”“分母字面”两个整数子项；不把它们解释为“当前魔法/最大魔法”这类游戏含义。
- 图标：现有模板排名保留，但只有主技能读出“高级”或“专家”这样的字面等级时才给身份；父技能未知则子技能身份也被阻断。装备占用和背包标为“未读”。
设置
每张图一次请求：共 4 次解码、4 次整图 OCR、4 批局部读取、124 个裁剪单元（248 个尺度变体）。私有结果每份不超过 4 MiB，实际 110–122 KB。评分规则在读图前冻结。
结果
| 分组 | 已知分母 | 正确 | 未知 | 错误/缺失 |
|---|---|---|---|---|
| 名字/职业、等级、六个位置数值、三个分数 | 48 | 36 | 10 | 2 错误 |
| 七个部队槽显示数量 | 28 | 28 | 0 | 0 |
| 非空主技能显示等级 | 21 | 13 | 8 | 0 |
| 三张战中图对应 HUD 法强/魔法 | 6 | 6 | 0 | 0 |
| 装备/背包占用（未实现） | 152 | 0 | 0 | 152 缺失 |
| 独立阶段判断（未实现） | 4 | 0 | 0 | 4 缺失 |
可评分字面读数合计 83/103 正确、18 未知、2 错误。11 个参考为空的主技能槽都没有被填值；20 个参考为空的装备槽中 19 个没填、1 个被错填了一件宝物身份。装备身份、技能身份、部队身份的规范 ID 参考都是未知，共 85 个位置不可评分；64 个子技能参考未审核，完全排除。
耗时：工作进程就绪 0.404 秒；第一次请求 9.815 秒（含模型初始化），后三张 3.917 / 3.849 / 3.741 秒。四个样本不能报 p95 或 App 时延。
失败与负结果
20 个未完成项（18 未知 + 2 错误）逐项拆分：
| 类别 | 数量 | 说明 |
|---|---|---|
| 整图 OCR 低分 | 2 | 局部两尺度都读对（如 8、26），但整图读成带杂字符的低分文本，按规则输出未知 |
| 整图 OCR 无法解析 | 1 | 局部读对 6 |
| 整图 OCR 没出字 | 8 | 局部两尺度都 ≥0.9 且与参考一致 |
| 局部 OCR 低分 | 5 | 如把“18”读成带前缀字母的低分文本；不删字母、不降阈值 |
| 经验值前缀/空格编码 | 4 | 读成“X 20500/26300”这样的整段文本，没形成纯分数字面（其中 2 个计为错误） |
也就是说，有 11 项其实局部数字读对了，只是缺少整图的第二路支持。但两个尺度来自同一张图、同一个 OCR 引擎，不是两份独立证据；没有整图支持就不能直接当作确认读数。
评分器还有一处错误：初版把参考的英文装备地址和输出的中文地址直接对接，把 20 个空装备槽都记成“缺失”。修正地址对应后另存评分，才发现上面那 1 个错填。这是评分修正，不是读取器改进。
后续：一处编码修复和公开格式草案
经验值编码修复：只针对经验值槽，允许把原文前导的“X”显示字符与分数字面分开，空格差异按相同整数对齐；原全文、分数、来源和尝试记录都不改。其他字段、低分、数字中间空格、不同数字都不放宽。用保存的结果回放（不重新读图）：4/4 经验槽生成了分子/分母，其他 104/104 个字段逐值不变。这是编码回放，不是重新实测或提分。
公开格式草案（未批准、未实现）：提出一个独立的单图读取入口和命令行，输出固定 8 个顶层键、48 个对象、31 条证据记录，只含字面值（整数/文本/未知），阶段、归属、当前行动者固定为未知，状态提交固定为“未授权”。草案规定了输入尺寸（只支持 2560×1440，先读文件头再决定是否解码）、预算（单次输出 1 MiB）、错误码和退出码，以及新旧生产者/消费者组合的兼容责任。用一个实验校验器检查了合成示例：最初 5 项、随后 8 个反例，独立静态审查后又补了 12 项聚焦检查（修正前 10 失败 2 通过，修正后 12 通过）。这些只是有限的结构检查，不是真实读取器或下游兼容的验证。
下一步建议（未执行）：只研究攻击、左下、底部左三个位置整数的“缺整图支持”问题，需要数据负责方提供 6 张未曝光、至少 4 个独立来源的新图和独立参考，缺整图支持时最多产生更弱的私有候选，不进入确认状态。
局限
- 只有四张已曝光的图，不能说明留出准确率、App 时延或游戏机制。
- 装备占用、阶段/归属、规范身份都没有生产者。
- 读取器私有，没有接入公共入口、状态估计或 App；公开格式草案等待各消费者确认。
- 新代码聚焦测试 35 项通过，受影响的 Perception 全套 6,339 项通过（修复后 6,350 项通过）；软件测试不是识别精度。
结论与下一步
拼装现有组件可以读出英雄面板的大部分字面数字，部队数量和 HUD 读得最稳；主要缺口是“局部读对但缺整图支持”、低分局部读数、装备占用和阶段判断。这四张图只能作为已保存诊断，不能再用同一批图追加 OCR 调参。下一批工作需要新的协议、新的独立图片和调用预算。
Comments