摘要
在《英雄无敌：上古纪元》的战场上，每个兵堆（同一种生物的一组单位）脚下都有一块小小的数量牌，写着这一堆还剩多少个单位，并用红色或蓝色表示属于哪一方。读准数量牌是计算伤亡、推断对手的基础。
本实验在不改任何参数的前提下，用项目原有的数量牌读取方法（下称“原方法”）在 8 张已有的原生 2560×1440 截图上做一次性测量。结果：98 个可读数量中 95 个读对（96.94%），没有一个输出“未知”，2 个数量牌根本没被找到，1 个读错（150 读成 4150）；8 张图中有 5 张所有可读数量全对（62.5%）。颜色 105 个中 101 个对。
这 8 个来源都是历史上已经看过的开发 / 诊断数据，不是盲测留出集；结果不能证明项目更广泛的 95% 验收目标，也不涉及兵堆身份或关联。
要回答的问题
不做任何改进，原方法在 8 个已曝光来源上读数量牌的真实水平是多少？错误发生在“找牌子”还是“读数字”？
数据与来源
- 8 张已有的原生 2560×1440 PNG，来自前一阶段已接受的参考：前 4 张是开发扩充（54 个可读数量），后 4 张是已曝光来源的诊断（44 个可读数量）。按日期分别是 10 月 1 日的四张、9 月 30 日一张、9 月 29 日一张、两张熔岩地图相关的截图。
- 人工参考：105 个可见数量字面区域，其中 98 个可读、7 个不可读；105 个颜色都已知。
- 来源分组在测量前固定，不根据结果重新分类。
方法
原方法（冻结）： 先用纯图像几何找到可能的数量牌（不导入任何模型），再把原有的扩展 4 个像素的裁图在内存里交给 OCR（PP-OCRv6 中等识别模型，CPU）。每个裁图读两种版本：原图和放大 3 倍。两次读出的文字都必须是 1–4 位数字、彼此相同、且每次得分 ≥0.80 才接受。不使用掩码、回退、数值范围、行动卡或身体身份等额外信息。
执行约束： 协议、来源列表、运行和评分代码在看任何像素之前单独提交冻结。几何进程禁止导入任何模型；每张图最多 64 个裁图，总共最多 512 个裁图 / 1,024 个变体；OCR 子进程只用缓存模型、CPU、最多 2 线程、禁网；总时限 15 分钟；开始后不允许重试。预测先保存，评分程序之后才读人工参考。
评分： 沿用之前的评估器：算法找到的牌子覆盖人工字面区域（加边距后）≥0.5、且包含字面中心，就算匹配；用确定性的一对一最大匹配。人工区域不是精确掩码，所以这不是 IoU 检测基准。每个可读目标都进入“对 / 未知 / 漏 / 错”分母；不可读目标上的输出单独记录；多出来的输出计入精确率。
设置
| 项目 | 设置 |
|---|---|
| 运行次数 | 1 次（获批的唯一一次） |
| 设备 | CPU，OpenCV 与预测器各 2 线程 |
| 规模 | 8 次几何调用、102 个裁图、204 个变体 |
结果
| 来源 | 分组 | 找到的牌子 | 可读 | 对 | 未知 | 漏 | 错 | 全对 |
|---|---|---|---|---|---|---|---|---|
| 10-01 18:13 | 开发 | 13 | 13 | 13 | 0 | 0 | 0 | 是 |
| 10-01 17:49 | 开发 | 14 | 13 | 12 | 0 | 0 | 1 | 否 |
| 10-01 00:44 | 开发 | 14 | 14 | 13 | 0 | 1 | 0 | 否 |
| 10-01 00:23 | 开发 | 14 | 14 | 14 | 0 | 0 | 0 | 是 |
| 09-30 23:33 | 已曝光诊断 | 14 | 14 | 14 | 0 | 0 | 0 | 是 |
| 09-29 22:15 | 已曝光诊断 | 14 | 13 | 13 | 0 | 0 | 0 | 是 |
| 熔岩地图 440 秒 | 已曝光诊断 | 6 | 6 | 6 | 0 | 0 | 0 | 是 |
| 熔岩地图开局 405 秒 | 已曝光诊断 | 13 | 11 | 10 | 0 | 1 | 0 | 否 |
| 合计 | 102 | 98 | 95 | 0 | 2 | 1 | 5/8 |
- 开发组：52/54（96.30%），1 漏、1 错，全对 2/4。
- 已曝光诊断组：43/44（97.73%），1 漏，全对 3/4。
- 几何匹配覆盖 96/98 个可读区域（97.96%）、101/105 个全部区域（96.19%）。所以两个漏读都是“没找到牌子”；每个找到的可读目标都实际 OCR 了两次，95 对、1 错，没有一个可读目标被拒读。
- 颜色：101/105 正确（96.19%），4 个漏、0 个未知或错。
数值输出共 99 个：95 个匹配且正确、1 个匹配但错误、1 个重复的多余输出、2 个落在不可读参考上。精确率的下界 95/99 = 95.96%，上界 97/99 = 97.98%（两个不可读位置的读数无法核实）；在可判定的输出中为 95/97 = 97.94%。只看匹配输出的 95/96 = 98.96% 排除了多余输出和不可读位置，不能当作整体输出精确率宣传。
耗时（本地测量，不是 App 端到端延迟）：
| 阶段 | 秒 |
|---|---|
| 几何：原生图解码 | 0.323 |
| 几何：8 次牌子提议 | 0.315 |
| 几何进程合计 | 0.915 |
| 模型导入 / 加载 | 8.467 |
| OCR：原生图解码 | 0.354 |
| OCR：实际识别批次 | 12.775 |
| OCR 进程合计 | 21.671 |
| 几何与 OCR 进程合计 | 22.586 |
失败与负结果
- 唯一的读错： 一个蓝色的 150 被两次都读成 4150（得分 0.956 和 0.901）。扩展后的裁图包含了牌子边缘旁边的前景像素。“两次一致且 ≥0.80”的规则接受了这个共同的错误；没有用“挑高分”“删掉开头的 4”或借用行动卡数值来纠正，原始读数保留。
- 两个没找到的牌子： 红色 50 和蓝色 26 没有任何提议和 OCR 尝试。现有原始提议无法说明是内部哪一道几何关卡导致的，没有断言具体原因。
- 重复提议： 一张图（10-01 00:44）里对同一个“215”的牌子提了两个框，两次 OCR 都读出 215。读完后人工看原图，确认只有一块 215 的牌子，这是重复提议；它保留在预测中，没有删除，也没有在一对一匹配中给它额外加分。
- 7 个不可读参考全部保留： 有的被身体完全挡住、有的首位或末位字形被盾牌 / 鹿角 / 翅膀 / 鼠标指针遮住。其中两处读出了得分较高的数字（24、40），但它们不能反过来让参考变成“可读”，也不能算对或错。
局限
- 8 个来源都已曝光，不是盲测；测量后它们仍然是已曝光数据。
- 只测数量和颜色，不涉及兵堆身份、与身体的关联、十场独立对战或六类完整界面场景。
- 软件检查（12 项评估器测试、元数据校验）通过，但没有跑完整模块测试、界面、安装包或真实会话验收。
结论与下一步
原方法在这批已曝光数据上读得相当准，主要缺陷在“找牌子”这一步（漏找和重复）。报告提出的唯一下一步改进是：在输出独立牌子之前，先把破碎的候选按牌子分组，OCR 保持不变。重复的 215 是这个改进的具体证据；两个漏找是否也能被它修好，需要先做阶段审计再说。该改进需要重新冻结方法和授权，本实验没有实现，也不预测它能提高准确率。4150 这个共同识别错误作为已知局限保留。
Comments