摘要
战斗开始前，游戏会显示准备页（确认页和布阵阶段的英雄窗口），列出英雄的主技能、子技能、装备和军队。读取器读出后，战斗记录 App 会先做严格校验：每个身份都必须在 App 的“笔记目录”里，否则整页拒收。
在一局 10 月 9 日 08:38 的打电脑训练录像的已存会话中，3 次准备页读取都被拒，理由是“不在竞技场目录中的身份”。后果很严重：状态估计（SE）拿不到我方英雄，我方屏幕侧一直未知，整局减员时间线为空，结算画面 14 行全部无法对应。
查明：读取器读出的“属性加成”是真实的竞技场子技能，游戏安装资源里有它；但 App 的笔记目录来自 8 月底游戏更新前的网站资料，缺少这一行。此前 Perception 为补这类新子技能，让读取器改用安装资源图匹配并输出新身份，但 App 的严格校验没有同步放行。本轮只在 App 中放行这 9 个已知未收录的子技能、按未知处理，三页随即恢复。插回 SE 后又暴露出另一个缺陷：头像环颜色让双方阵营判反了。
要回答的问题
- 三张准备页为什么被拒？是读取器错误、官方 AI 的特殊身份，还是目录缺口？
- 最小、安全的修复是什么？修复后 SE 能否恢复我方信息？
数据与来源
只读一局打电脑训练录像的已存会话（3 张被拒的准备页原图和 App 最后保存的 SE 请求，共 242 帧）；没有改动会话，没有读冻结来源。
方法
- 复现：用每次尝试冻结的路由请求（同一原图、自动模式、同一头像参考）在常驻生产路由器上用 CPU 重读三张图——三张都处理成功，只有准备页任务读出内容（每张 35–58 秒，CPU 冷启动，不是实时耗时）。原会话可能是 GPU 读取，当时结果未保存，只能用 CPU 重读对照。再用 App 的校验函数检查，三页都报同一错误。
- 定位字段：三页都是同两个槽，值为“属性加成”，父技能分别是虫群召唤和领导力，英雄是蕾拉。模板分 0.74–0.83，与第二候选差 0.47–0.57，三页一致，是可信读数。
- 根因核对：属性加成在游戏安装资源表里有 15 个变体；笔记目录缺这一类共 9 个子技能（属性加成、战斗技艺、生命之系、转化、魔法稳定性、坚韧不屈、天赐礼物、魔法影响、魔力之野）。另两局训练录像没有出现这些子技能，所以之前没报错。
修改（只在 App）：
- 从游戏安装资源表算出“没有参考目录行的竞技场子技能”的身份（与读取器同一命名规则），只有当值恰好是这 9 个之一、位于子技能槽、是字符串时才放行这一槽；其他一切照旧严格——任意其他目录外身份、把这个名字放进技能或装备槽、字典形式的值、状态不一致，仍整页拒收；战斗截图仍不允许子技能字段。
- 放行的槽在笔记中按未知处理：不写入、不计入已应用、不编造编号；界面显示“属性加成（笔记目录未收录，按未知处理，不填入）”，手动导入时不可勾选。
- 路由原文不改：SE 仍能看到原始身份（规则模拟器的开局预测已认识它）。
设置
新增 10 项测试和一个真实读数夹具（确认页的准备页读数，只有读数、没有像素）。用 App 最后保存的 SE 请求，把 3 个重读结果按截图顺序插回（共 245 帧），在 core 环境重算 SE。
结果
- 修改前（原代码副本）：3 项新测试失败，失败信息正是“不在竞技场目录中的身份”。修改后 10/10 通过；准备页相关 5 个文件 51/51 通过。
- 受影响的 21 个 App 测试文件 307 项：306 通过，1 项失败；换回原文件同样失败、在主工作区通过，与本改动无关（原因未查）。
SE 重算：
| 我方屏幕侧 | 我方英雄 | 敌方英雄 | 减员时间线 | 结算画面 14 行 | |
|---|---|---|---|---|---|
| 原请求（复现已存结果） | 未知 | 未知 | 无 | 0 堆 | 14 行无法对应 |
| 插回 3 页 | 左 | 蕾拉 | 已识别 | 26 堆 | 5 行缺结束读数、9 行无法对应 |
失败与负结果
阵营判反：插回后我方屏幕侧确定了，但归属是反的——结算画面左边 7 行（都是红方、蕾拉的部队）被标为敌方，时间线中红方部队 24 次读数也记在敌方名下。原因是第二个缺陷：这局录像中每帧的头像环颜色两侧都读成红色（55/55 帧），SE 用它逐帧覆盖“屏幕侧 → 颜色”的映射，而 HUD 英雄颜色（左红、右蓝，各 191 帧）只在没有值时才写入，于是敌方颜色被定成红色。
诊断（只把头像环颜色置空，不是修复）：我方左侧，红方 16 堆记为我方、蓝方 16 堆记为敌方；结算画面 12 行对应、1 行缺结束读数、2 行无法对应（左边两堆开局都是 52，按数量无法唯一对应，属预期的保守行为）。不插回 3 页时即使置空环颜色，我方屏幕侧仍未知——准备页修复是前提。
另外，SE 把对手类型判成了“玩家”（日志里敌方名字读成“AI英雄”和“英雄”，后者不符合电脑名规则），而这局实际是官方 AI；这是日志名读取问题，本轮未处理。
局限
- 已存会话中这 3 次尝试仍记为错误，修复不追溯；需要在 App 里重读或重跑离线视频。
- 只用 CPU 重读，无法与原会话可能的 GPU 读数逐字段对照。
- 笔记目录本身仍缺这 9 个子技能，笔记里这些槽只能是未知；补目录属于游戏资料模块的工作。
- App 的放行集合与读取器的命名规则是两处实现（都来自同一资源表）；若读取器改命名规则，这里需同步，否则会退回整页拒收（不会误收）。
结论与下一步
整页被拒的根因是目录缺口而不是识别错误，最小修复让三页恢复，SE 得以确定我方屏幕侧和英雄。但这立即暴露出“头像环颜色两侧同色时阵营映射被带偏”的问题：建议 SE 让 HUD 英雄颜色优先，或两侧环颜色相同时不用环颜色；同时查清读取器为何在这局把右侧环颜色读成红色。另需为游戏资料模块提交工单，评估为这 9 个子技能补参考目录行或稳定的公开身份映射。
Comments