摘要

游戏里点开英雄会弹出一个覆盖整块画面的英雄面板，上面有英雄名称、职业、等级、攻防、法强、知识、魔力（如 0/310）、8 个主技能及其子技能、装备和背包、7 个兵槽。它在布阵和战斗中都可能出现。与此同时，屏幕两侧的英雄界面（HUD）也显示一部分数值。

本文是一份提案：现有的截图分析格式只认六类画面，英雄面板放不进去；如果硬把它标成“准备页”，下游会把读数当成准备页的开局数值，含义就错了。提案给出一个独立的最小观察格式和每个字段“必须保留什么、不得暗示什么”，并用项目已有的公开数据类型写了一个合成示例证明可以承载。本轮没有读取任何原图，没有 OCR、模型或训练，也没有修改任何下游模块。

要回答的问题

不改动旧格式、不让下游误解含义，英雄面板的观察最少需要记录哪些东西？现有的公开类型能否承载？

数据与来源

只读取了另一份数据资料中已有的 4 张曝光参考的 JSON 记录，没有打开图像。合成示例中的数值是构造的测试值。

方法

为什么旧格式不行。 当前截图路由器只有六类任务；状态估计（SE）的校验只接受准备页、战场、面板、法术书、攻击、日志六种；App 的保存格式也只允许“面板/法术书”模式。改名或偷偷加一个枚举值都会被严格的读取器拒绝，或者被误解为准备页数值。

最小形状与字面语义（摘要）：

项 必须保留 不得暗示
来源 完整原图、原生尺寸；有录像时点就记，没有则为空 不捏造录像 ID 或时间 0
面板 帧内局部对象引用、独立的英雄覆盖区域、可见/遮挡/过渡 左/中/右位置不等于我方/敌方
上下文 阶段、本地玩家角色、头像与 HUD 是否相似，各带状态和证据 缺证据就是未知；头像相似不确认归属
标量字段 名称、等级、攻防、法强、知识、资源原文，每项独立的框、原始读数和分数 不当作基础值、装备增益或敌方削减
成对字段 如 0/310 的原文和“当前/上限”两个整数子项 0 不是未知，也不自动当可用魔力
技能槽 8 个主技能及子槽，可见/未读/无法定位分开记录 未审核的子槽不算“空”
装备/背包 每个可见槽的占用证据和候选身份 空白不证明没有装备
军队 7 个可见槽的单位候选和数量 身份未知仍保留数量，不跨帧合并
HUD 作为另一个区域独立保留 不用 HUD 替换面板数字，差值不是效果
覆盖与诊断 已扫/未扫/未知分开，失败原样保存 “未读”不计为空或正确

现有类型的验证。 项目的公共类型层已经导出了“界面元素观察帧”一组类型和编解码函数。提案用它们构造了一个明确标为合成测试的示例：面板法强 26 与 HUD 法强 22 各自独立保留；0/310 保留文字父项和两个整数子项；阶段、归属和主子技能身份为未知/未读；没有实时时钟。

设置

无实验运行；只运行示例的软件回归。

结果

10 项回归测试通过：包括保存后的 JSON 编解码往返、不同对象不合并、零值保留、角色未知时不擦除局部读数、缺父项时拒绝、不能当实时数据使用。这只证明现有格式“装得下”，不代表 SE 或 App 已同意新的英雄角色语义或输入格式。

提案还列出了受影响的消费者（SE 的原生投影、App 的保存/恢复和构筑填充、公共编解码、通用观察消费者、已安装的旧版工具）以及兼容矩阵：旧生产者对新旧消费者必须保持；新生产者对旧读取器必须明确拒绝而不是冒充旧格式。

失败与负结果

不适用：本轮没有执行读取实验。需要强调的是，现有感知的字段提取函数要求必须有录像 ID 和非负时点，真实单张截图没有这些信息时不能编造 0 去复用它。

局限

  • 提案尚未获得提供方和消费方的共同批准，也没有实现新的公共格式。
  • 4 张参考图是曝光过的开发数据，独立验收对局为 0。

结论与下一步

英雄面板需要一个独立版本的观察格式，现有公共类型足以承载它的字面内容。下一步（需另行冻结预算和协议）：只在这 4 张参考图上做一次私有读取，每张图一次请求、失败不追加调用，读取器不接收参考值；数字、身份、占用、显示等级、阶段/角色、区域/质量分别评分。公共格式仍等待正式审阅。