摘要
SE（状态估计）把一局里多次截图读到的观察累积起来，推断对局状态和对手构筑。一个自然的想法是：同一种生物的面板攻击值前后变化了，应该能推出“发生了什么”。本实验用一局用户选入训练的打电脑录像（10 月 9 日 08:38）检验这个想法，事先只固定一个标题、一个字段、两帧：真菌伊利亚德的生物面板攻击值，在 92.2 秒读到 19、在 223.8 秒读到 21；两者之间 220.6 秒的战斗日志（Logs）写着另一个生物“使用升华”、真菌伊利亚德“获得升华，持续 2”。
逐步把真实观察按时间顺序加入 SE 请求后：
- 加入完整读取的日志 → SE 识别出对手是电脑，并关闭了不适用的竞技场英雄栏解释；
- 加入后一帧的 HUD（战场上方英雄信息条）→ 确定我方在左侧；
- 再补一张已有的无遮挡战场图（含行动条）→ 两张面板被推断为我方。
但始终无法认证“两张面板是同一个兵堆”，也无法把攻击 +2 归因给升华——因为没有兵堆实例身份，状态图标对应的规则查询也只是部分支持。本轮实际交付的代码修改只有一处：SE 把“第一次读到的 HUD 数值”标成“开战时”，已改为“首次战斗读数”。
要回答的问题
- 两次面板攻击读数之间的差值，能不能（在现有程序中）合法地归因？
- 缺的到底是识别能力、数据传递，还是身份/规则合同？
数据与来源
- 唯一来源：用户选入训练的一局打电脑录像。不是独立测试。
- 两张面板图使用已有截图（JPEG，取帧时间为当时请求的毫秒数，没有重新核验解码时间）；路由器只接受 PNG，所以另存了逐像素相同的 PNG 副本，仍源自有损 JPEG。
- 直接看图的参考（攻击 19/21、状态图标、日志内容）由 AI 助手逐图核对，待用户复核，不作为推断输入。
- 后续步骤复用同局已保存的准备页（76.18 秒）、三份日志截图，以及一张 98.40 秒的已有战场图。
方法
- 先只按面板标题出现顺序选出两帧，再查看数值，不换字段找“成功样例”。
- 用当前生产面板读取器和完整自动路由（auto）重读两张图，区分“诊断输入缺项”和“实际路由缺项”。
- 按媒体时间顺序把真实读数装入 SE 公开入口，每次只加一种观察，保存完整请求和结果做前后对比；不加人工归属、堆编号或命中条件。
- 对状态图标候选，通过规则模拟器的公开查询看它是否支持属性解释。
设置
重任务在 8 核限制下串行运行；没有训练、没有重扫录像、没有启动或安装用户的 App，也没有修改规则模拟器或对战 AI。
结果
两帧读取：
| 图像 / 时间 | 看图参考 | 当前读取器 |
|---|---|---|
| 92.2 秒 | 攻击 19；“战术阶段”；无状态图标 | 攻击 19；状态“无图标” |
| 223.8 秒 | 攻击 21；一枚状态图标，角标 2 | 攻击 21；状态候选 lightweaver_buff_2 |
自动路由两图分别 25.151 和 34.094 秒（CPU，不是热身后的整帧 p95）。223.8 秒那帧同时读到双方 HUD，但因为画面有覆盖层，路由器按既有策略只读 HUD、不读行动条。
状态图标的规则查询：公开查询返回“部分支持”、没有解释出任何属性、有一个未解释的键（alwaysMaxDmg），且注明只是安装基础值、未含运行时缩放。这既不是“效果不改属性”，也不是“加攻击 2”。
逐步加入观察后的 SE 变化：
| 累积到 | 新加入 | 对手类型 | 我方屏幕侧 | 两张面板归属 | 日志计数 / 攻击关联 |
|---|---|---|---|---|---|
| 92.2 秒 | 准备页 + 攻击 19 面板 | 未知 | 未知 | 未知 | 0 / 0 |
| 220.6 秒 | 完整日志 29 条（含两条升华） | 电脑 | 未知 | 未知 | 29 / 3 |
| 223.8 秒 | 攻击 21 面板 + HUD | 电脑 | 左 | 未知 | 29 / 3 |
| 754.19 秒 | 再加三份后期日志 | 电脑 | 左 | 未知 | 109 / 8 |
| 补 98.40 秒战场图 | 13 张行动卡（7 红 6 蓝） | — | — | 我方 / 我方 | 攻击关联完全不变 |
- 日志让 SE 识别出对手是电脑，于是不再对它套用“10 级竞技场英雄”的解释栏——这是前提适用性的变化，不是攻防范围缩小。
- 战场图那次：8 个 HUD 字段、13 张行动卡的数量和颜色与看图参考一致。SE 用“该兵种只出现在一侧的可见行动卡中”推断面板归属。注意这是用整个请求的集合做的回顾性推断：98 秒的观察会影响 92 秒面板的归属，不能说 92 秒当时就已知；也不能证明另一侧没有同种生物。
- 一条日志明确写着“缟玛瑙舞者攻击真菌伊利亚德，后者受到 774 伤害、死亡 12”。攻击兵种是已知的；不知道的是历史面板是否属于这一个兵堆，以及面板数值在命中那一刻是否有效。所有攻击关联仍然“条件为空、未确认、未查询规则”。
本轮修正：SE 原先把第一次可用的 HUD 读数显示为“开战时”，但 223.8 秒之前画面里已经发生过多次行动，不能证明那是开战值。现改为“首次战斗读数”，并在说明中写明“首次读到不等于开战值”；数值、计算和数据字段不变（旧字段名为兼容保留）。修正后用同样的自动输出重跑：观察、候选、攻击证据等完全相等，只有这句文字变化。进度提示中的“开战时没有被降低”等措辞一并改为“首次战斗读数”“读数降低”。相关测试 SE 65 项、App 80 项通过。
失败与负结果
- 两面板同堆、+2 归因都没有成立：同名、同外观、括号数 52/52 都只是支持“可能同堆”，没有实例编号或连续身份记录。
- 旧的单次 OCR 漏了右括号，导致纯文本解析失败；改用完整三次读取后两条升华都结构化成功，没有手工补括号。
- 对“显式指定面板所属侧”的接口判断曾不完整：实际验证发现只有模拟器专用的请求格式接受这个字段，真实截图格式会拒绝；App 中“用户绑定观察对象”的保存路径与“构筑推断”请求也是两条独立链路，前者能保存和撤销，并不代表已接入后者。
- 攻击查询有模式限制：即使补齐所有命中条件，当前 SE 对“对手为电脑”的结果也不执行竞技场构筑查询；现有规则查询需要已知的攻防条件，并不是从伤害反解未知属性的通用接口。App 文本据此加了一句“当前版本尚不支持对此类结果执行竞技场攻击构筑查询”（措辞经外部审阅建议收窄，避免被理解为游戏事实）。
- 一张日志图的完整读取用时约 72 秒（CPU），是明显的性能风险，留作后续分阶段计时。
局限
- 一局已曝光训练录像、少量帧；所有参考是模型目视，不是人工审核。
- 软件测试数量只说明行为，不是识别准确率；没有在用户安装版上验收。
- 战场图带来的面板归属是现有推断规则的输出，不是游戏认证的归属。
结论与下一步
这组实验把“读到 → 保存 → 计数 → 主体关联 → 有规则条件的推断”分成了不同的验收层次：真实观察确实改变了对手类型、屏幕侧和面板归属，但要把数值差归因，还缺兵堆实例身份、命中时刻的有效属性和规则支持。继续补零散截图已没有收益。下一步是让一条攻击的一个参与者与一张历史面板建立可撤销的、明确标注为用户声明的关联，并把“身份声明”和“属性在当时是否有效”分开（后续发现现有观察投影接口已支持日志参与者与面板的用户绑定，界面随后实现）。
Comments