摘要
战斗记录 App 会把每张读取过的截图结果合成一个“对局视图”，左上角显示我方英雄的名字和属性。有人提交了一张界面截图来问：左上角的英雄是怎么来的？为什么之后会变成未知？
本实验是一次只读核查：读取一个固定对局保存下来的会话、请求上下文、路由（router，把一张截图分给各个读取器的程序）原始输出、关键帧和投影缓存，追溯每个字段的来源；不调用任何识别模型或 OCR，不修改会话。
结论：截图里的英雄名字来自第 297 秒准备页的候选；截图时第 420 秒的战场截图还在读取中。读完 420 秒后，左右两个头像的最佳匹配分数分别是 0.709 和 0.690，都低于 0.75 的门槛，所以身份为“未知”；但根据同图的头像角色线索，HUD 上的数字仍正确进入了我方和敌方对象。问题在匹配门槛和覆盖，不是界面没接线，也没有证据表明选错了英雄。
要回答的问题
截图中显示的英雄名字来自哪一次读取？读完下一张截图后为什么变成未知？是不是界面没有接线，或者选错了英雄？
数据与来源
- 一个固定对局（10 月 5 日 01:41 开始的会话，共 4 张截图）保存的会话、请求上下文、路由输出、关键帧和投影缓存。
- 用户提供的界面截图和原 420 秒截图，只做只读查看，不作为模型输入，也不算新的精度分母。
方法
一个只读脚本核对：对局、请求和来源是否一致；各个修订版本；字段的来源链；并在读取前后核对 JSON 文件的大小和修改时间，确保没有被改动。核查结果独占写入一份新的审计文件。脚本不导入识别、状态估计或界面模块，不请求 OCR、匹配或模型，不保存会话，也不确认身份。
设置
界面截图的底栏显示“已保存修订 3、正在读取第 4 张（420 秒）”。完成后保存的缓存是修订 4。
结果
截图时（修订 3）和完成 420 秒后（修订 4）不能混为一个状态：
| 项目 | 修订 3 | 修订 4（读完 420 秒） |
|---|---|---|
| 我方英雄 | 愤怒公爵克尔森，候选，来自 297 秒准备页 | 当前值为空、未知；来自 420 秒左侧头像；旧身份保留为“历史候选” |
| 我方魔力 | 0（297 秒准备页） | 242，上限 242（420 秒 HUD 候选） |
| 我方等级 / 知识 | 10 / 14（准备页候选） | 保留，标为历史（420 秒读取器不输出这两项） |
| 敌方英雄 | 没有对象 | 未知，来自 420 秒右侧头像，没有旧身份可保留 |
| 敌方 HUD | 未收集 | 攻击 12、防御 11、法力 29、魔力 250/250，候选 |
准备页的英雄字段：两种尺度下 OCR 原文都是“愤怒公爵克尔森”，分数约 0.99983 和 0.99984；状态是“候选”而不是“已确认”。这与之前另一份参考中同一张 297 秒截图的身份一致。会话中没有手工编辑、绑定或角色覆盖，因此没有“另一局”或“手工选错”的来源。
420 秒战场头像匹配：
| 头像 | 第一名 / 分数 | 第二名 / 分数 | 差距 | 结果 |
|---|---|---|---|---|
| 左侧 | 克尔森 / 0.70925 | 另一英雄 / 0.38056 | 0.32869 | 低于 0.75，身份为空 |
| 右侧 | 某亡灵英雄 / 0.68964 | 另一英雄 / 0.52405 | 0.16559 | 低于 0.75，身份为空 |
接受规则要求分数 ≥0.75 且领先差距 ≥0.08；两个差距都达标，分数都没达标。读取器使用原始 BGR 头像裁图和同为 BGR 的标准图库，没有发现颜色通道反转或门槛执行错误。看过原 420 秒截图，两个头像和数字都清楚可见，但这不等于当前图库匹配已经合格，也不能把右侧第一名直接当作已知的敌方英雄。
同一张图的头像角色线索（判断左侧是不是“我方”）是候选，唯一匹配为左侧（左 0.99167、右 0.067217）；状态估计据此把左侧 HUD 归到我方英雄、右侧归到敌方英雄。角色关联和英雄身份是两回事：身份未知不妨碍可读的 HUD 数字进入正确的一方。
界面接线：状态估计选择最新读取（即使新值为空），旧候选留在历史备选中；投影把当前选中的身份映射到界面行，界面据此画中文名和图标。修订 3 会显示克尔森，修订 4 当前值为空就显示“选择英雄”。当前语义是“最新身份未知，历史候选可查”，并没有删除 297 秒的原证据。已有单元测试中正好有“最新未知阻止旧英雄成为当前值、并保留历史备选”的用例，与这次保存的数据一致（本轮没有重跑测试）。
审计脚本首次实际运行通过，修订 3/4/4 核对一致，新的路由 / OCR / 模型 / 状态估计 / 界面调用为 0；代码检查通过。
失败与负结果
真正的缺口是战场头像身份匹配分数不足：两个清楚可见的头像都没过 0.75。但只有“覆盖 / 匹配不足”的证据，没有可以直接修的算法 bug，所以本轮不改源码、不改门槛、不做新识别。
局限
- 只核查了一个对局。
- 没有重跑测试、没有性能测量。
结论与下一步
最小的界面建议（由 App 负责方实施）：左上角把“当前身份未知”和“上次候选：克尔森 · 297 秒”分层显示，并标明来源修订和时间；不要把历史名字重新写成当前值或隐式确认。可以在折叠的来源信息里显示本图前三名和分数、以及未过 0.75 门槛；敌方显示“身份未知，HUD 已读”；读取 420 秒期间也标注当前显示的是修订 3。
视觉理解这边的后续：用一小批独立的同图身份参考，验证英雄头像原生圆形区域的位置和比例与标准资产内框的匹配，保留全图库、排序和 0.75 / 0.08 门槛；不能根据这张图的第一名、历史身份或头像角色去注入答案。
Comments