摘要

用户在实际战斗记录 App 中对一局的四张截图做了分析，反馈界面上很多地方是空的。问题在哪：是视觉识别（Perception）没读出来，还是读出来后在“关联到哪个兵堆/槽位、再显示出来”的环节丢了？

本实验只做审计：先目视查看四张原图，然后用一个只读脚本读取 App 当时保存的生产回执和游戏资料库，统计每类字段有多少候选，不重新运行任何图像处理、OCR、模型或状态估计。结论是：识别端已经给出了大部分可读内容（准备页 6/9/8/7、开局图 13 张行动卡全部读出），空白主要发生在关联和显示链路；另外，准备页上可见的灰色空位在旧数据格式中只能写成“未知”，无法表达“确实是空的”。

要回答的问题

  • 四张截图中，识别端实际输出了什么？
  • App 上的空白是在哪个环节产生的？
  • 哪些缺口是识别能力不足，哪些是数据格式或支持范围的边界？

数据与来源

一局对战中按时间取的四张截图：

截图 目视可见 已保存的识别结果
准备页（297 秒） 6 个主技能图标 + 2 个空位，7 个军队头像/数量，8 个装备图标 + 6 个灰色占位 准备页读取成功：6 主技能、9 子技能、7 军队身份/数量、8 装备候选
生物面板（350 秒） 战术部署期间一个蝎子面板，没有行动条 面板读取成功：身份、数量 56/56、生命 40/40、攻 46、防 29、伤害 10–12 等；速度未知
战术部署（360 秒） 部署界面、红方 7 队；没有行动条，蓝方军队尚未出现 旧版路由器全部未检测（当时的战场读取要求有行动条和 HUD）
开局（420 秒） 双侧 HUD，13 张可见行动卡；右侧 7 个蓝方数量牌 战场读取成功：13 张卡全部有身份/颜色/数量（6 蓝、7 红），HUD 8 个字段已读

方法

脚本只读取保存的链路审计文件和资料库，核对各类计数，写出一份新的基线文件（重复运行拒绝覆盖）。脚本自身的“图像解码次数”为 0；人工/目视看原图不计入。

设置

不操作用户屏幕、原录屏或预留数据池。

结果

  • 计数核对：主技能 6/8、子技能 9/16、装备 8/14、军队 7/7；13 张行动卡、6 张蓝方。注意 8/16/14 是槽位总数，不是已拥有数量。
  • 6 张蓝方行动卡的身份和数量候选都已读出（例如鬼魂 200、两种升级鬼魂各 150 等），并传到了状态估计（SE）的“未关联”字段里——识别端没有丢值。
  • 13 张卡在下游全部处于“未关联”（SUBJECT_UNBOUND），4 个配置的对象槽位映射都是空的。代码显示，当时的自动关联只为英雄选择目标，所以“英雄关联成功”不代表“行动卡已被关联和展示”。

失败与负结果

各缺口分别记录，没有合并成“敌方军队全部不可识别”：

  • 速度字段未知：原裁图两次都读成“4”，但分数 0.8942 和 0.9509，其中一次低于 0.90 门槛，于是为未知。不改成 0，也不降低门槛。
  • 部署画面：当时路由器明确不支持无行动条的部署画面，这是支持范围缺口，不是“场上没有单位”。
  • 地面数量牌 72：开局图右侧有一个数量牌 72，没有对应的可见行动卡，当时的读取只覆盖行动卡，不为它猜身份。
  • “空槽”无法表达：旧准备页格式只允许“有值 = 候选、无值 = 未知”两种状态，没有“空”。所以目视可见的灰色空位只能写成未知；主技能空白、未识别的非空图标、遮挡和“没尝试”在这种格式下无法完整区分。

局限

  • 这是对已有回执的定位，不是新的 App 验收，也没有提高或改变任何识别输出。
  • 计数是已有候选数，不是身份准确率。

结论与下一步

App 上的空白主要不是识别问题：准备页和行动卡的内容已经读出，断点在关联和显示。下游可以直接展示已读的 6 主技能/9 子技能和 6 张蓝方可见行动卡（标明是“可见卡候选”、完整性未知），不能把卡片序号当作初始军队槽位。

关于空槽，后续获得授权做了一个私有的占用检测：只解码准备页原图一次，与资料库图标做 22 次像素匹配，剔除 4 个同帧校准区后剩 18 个槽：14/14 非空判为“有”，4 个空槽中 2 个判为“空”、2 个未定，0 个错误的“空”。这只是同源开发验证，没有独立来源；要正式在 App 中显示“未学/未装备”，还需要新的数据格式版本并与使用方达成一致。