摘要
战斗记录 App（Battle Notes）把识别出的各类观察打包成一个请求，交给状态估计（SE，把观察累积成对局状态和对手构筑推断的模块）。攻击预览（悬停在敌方生物上时显示的击杀数和伤害范围）是 SE 很有用的条件伤害参考。
检查两段训练录像的已保存结果时发现：其中一段的原始识别会话里有 4 次攻击预览读取状态为 READ，但发给 SE 的 58 帧请求里一条攻击预览也没有。断点不在识别，而在 App 组装请求时的一个类型过滤列表（KINDS）——它没有包含攻击预览这一类。本实验修复了这个运输缺口，并在 SE 的推断说明和攻击详情里展示预览的原值和来源。
要回答的问题
已经读出的攻击预览为什么没进入 SE？修复运输后，SE 能保留什么、不能声称什么？
数据与来源
- 两段已选训练录像的原保存结果（58 帧和 49 帧），不新读视频、不新增 OCR。
- 16:57 那局：原会话 58 次路由结果中，第 19、25、57 帧保存了预览范围 406–677、845–1267、726–1089；第 50 帧数字核验未通过，预览为空。
- 01:39 那局：44 次没检测到预览，5 次被拒，没有可接受的预览。
方法
- App 端：过滤列表保留攻击预览任务，所有原字段原样深拷贝；旧请求和输出格式不变。
- SE 端（新增一个私有模块）：只消费唯一的 READ 任务、原生候选格式、同一张图的来源和合法的两行范围。每组保留行范围、原文、百分比、该组自己的目标候选和行动卡线索，不借用别的预览的目标。输出进入已有的“推断说明”（不作预测、不生成构筑候选、不调用规则查询）。
- App 攻击详情：单列这些说明；主体未知或没有面板时也能看到。
- 行动条首卡不被认证为攻击者，局部数量牌候选不被认证为目标；攻击方式（channel）仍为空，所以不能据此做伤害数值核对。
- 长序列最多展开 48 组，并注明未展开的数量；原任务全部留在请求里。
设置
用两段原保存结果，经生产的请求组装函数重建请求，再用实际 App 脚本启动隔离的核心进程，前后配对比较。
结果
| 录像 | 新增预览说明 | 其他结果 |
|---|---|---|
| 16:57（58 帧） | 3 条（528.0 秒、680.1 秒、1216.7 秒） | 全部严格相同 |
| 01:39（49 帧） | 0 条 | 全部严格相同 |
原攻击任务逐条精确保留；第 50 帧（993.4 秒）为空预览，不显示数值。原会话和原快照没有修改。App 攻击详情离屏渲染和保存的 HTML 页都能看到三项范围及来源。人工打开其中一张原图，上行 8–13、下行 845–1267 与自动保存结果一致——这是一帧的复核，不是独立测试集准确率。
失败与负结果
- 新 SE 测试修复前 12 个中 3 个失败；修复后与相关测试共 62 项通过（含 200 组候选的输出预算测试：48 组展开、152 组明确保留）。App 相关 53 项通过；其中 1 个旧测试按位置找 HUD 任务而失败，改为按类型定位，断言保持。
- 直接用实时识别会话类读取归档失败：归档 JSON 的换行格式不满足实时会话要求；规范换行后又因上下文路径不同被拒。没有放松生产验证，最终只用保存 JSON 解码器做诊断适配——这不证明旧归档能恢复成实时会话。
- 一次前后比较失败，原因是路径分隔符写法不同，且实验没有传入原战场部队数据；补传后、只在比较器里规范等价路径，最终配对通过。
局限
- 源码未安装到用户 App。未来正常请求会携带预览；但已有的“仅重算 SE”按钮仍使用旧快照原请求，不会自动补回当时被过滤的预览。
- 三项预览的攻击方式都为空，主体关联仍是候选，暂时不能做伤害数值核对。
- 外部审阅担心一处列表越界，审阅本身随后撤回，已有测试也覆盖；另提到的一组 2–3 伤害来自另一局录像，不能与本局拼接。
结论与下一步
问题出在“运输”而不是“识别”：一个过滤列表让已读出的预览从未到达 SE。修复后预览带着原值和来源进入推断说明，其他结果不变。下一步复用已有的预览关系核对入口，研究如何把用户明确确认的攻击者、目标和攻击方式交给现有的 SE 与规则模拟器接口，不把看图判断偷偷当作自动认证。
Comments