知道一张图是“选择技能”还不够。画面同时显示英雄身份、等级、属性和资源。选择技能之后数值可能改变；进入战场后还要区分自己和对方。读出数字、给数字找到字段、把字段绑定到正确英雄，是三个不同步骤。
现有 B023 主要处理选择卡的名称和图标。它尚未交付英雄攻击、防御、法力等字段的可靠提取与跨帧跟踪。本篇把这个缺口单独定义，避免场景分类完成以后，内部状态仍只有一个标签。
flowchart LR
A[场景及可见性] --> B[英雄面板及归属]
B --> C[字段图标与数字区域]
C --> D[原文及数值观测]
D --> E[时间更新与冲突]
E --> F[原图对照审核]图 1：每一步都应保留证据。此图描述目标流程，不表示当前已有字段识别准确率。
1. 场景 → 面板 → 对象 → 字段
| 层级 | 示例 | 必须区分 |
|---|---|---|
| 场景 | 技能选择、战场 | 当前画面与历史阶段 |
| 面板 | 选择过程的英雄卡、双方英雄边栏、英雄详情浮层 | 面板是否打开、是否被遮挡 |
| 对象 | 某个已识别英雄 | 玩家身份、队伍归属、界面左右位置 |
| 字段 | 等级、攻击、防御、法术相关属性、法力当前/上限 | 数字旁图标语义、基础值/显示总值/临时增益 |
| 观测 | 原文、解析值、矩形、时间、方法 | 本帧看到的数值与从历史保留的值 |
字段名应以当前版本游戏面板的实际含义为准。没有经过图标语义核对时，先记录“第 2 行左侧数值”，不要猜成攻击或法力。1、+1、1/20 也不能共享一个无单位数字字段。
英雄归属不能永久写成“左边=我方”。应结合玩家栏、队伍颜色、英雄身份、面板标题和进入面板的已知上下文；证据不够时 owner=UNKNOWN。同一个英雄可能出现在选择候选、选中英雄与敌方详情中，需要对象角色而不只是名字。
2. 先看真实画面里有哪些信息
技能页的英雄卡可用固定布局提取数值候选，但布局选择需要场景证据。战场侧栏可能只展示部分属性，详情面板才展示其余字段。缺少的字段应该记为未观测，不能从选择阶段的老值推断现在仍相同。
标题 OCR 通常识别中文名称；数值 OCR 还必须处理小数字、符号、分数、颜色变化和图标紧邻文字。可以比较整面板 OCR 与字段小裁图 OCR，输出 raw_text 后再做类型解析。一个高置信度的 4 仍可能来自错误的英雄、错误的行，或错误的字段图标。
3. 观测更新，不等于凭规则补全数值
下面是建议的记录结构。值用 null 表示尚未观测，不能把示例当成某张截图的实际预测。
{
"entity_role": "selected_hero",
"entity_id": null,
"owner": "UNKNOWN",
"field": "attack_displayed",
"raw_text": null,
"value": null,
"box": null,
"observed_at_seconds": null,
"status": "NOT_OBSERVED",
"source": "single_frame"
}只有字段含义、归属与像素证据相容时才提交观测。翻页期间保留上一条观测的时间，但当前值标为不可见或待确认；不能把历史值复制进“本帧检测结果”。观察到新数字时先保存原文与来源，异常跳变可以触发重读或下一帧确认，不能为了符合模拟器预期而强行改成旧值。
升级、技能、装备或战斗效果可能伴随数值变化。系统可以记录“前后发生变化”，但仅凭画面时序不能证明某个动作是唯一原因。基础属性、当前显示总值和临时修正要分开；首次实现可以只提取屏幕显示值，不推算隐藏规则。
切出游戏、断线、暂停时停止正常字段提交，但继续观察恢复。返回时重新识别英雄与面板；历史数据带年龄并标为可能过期。阈值、过期时间和连续确认次数要从序列验证中选择，不能作为已经可靠的默认保证。
4. 先做一个面板，再扩展双方英雄
第一步从现有技能、英雄信息、排兵布阵和战斗关键帧准备字段框与名称草稿。优先人工确认图标语义、所属英雄、字段类型与实际文字。随后比较整面板 OCR、小区域 OCR、位置约束及两者组合，按字段报告精确匹配、漏检、错误归属和拒识。
第二步在连续窗口比较数值变化时间、错误更新、过期值被误用，以及遮挡后的恢复。必须按视频隔离训练/开发/测试，不能用相邻帧的高度重复性制造高分。
现在可以先完成已准备好的场景审核和生物/英雄/技能身份审核。字段编辑器尚未上线，因此此刻不要求用户去一个不存在的入口填写属性。字段工具应显示原图、字段框、原文、归属和前后帧对照，再请用户核对真正不确定的部分。
B025 的验收是“每个字段知道属于谁、何时看见、哪里读到，以及何时未知”。它不包含战场生物定位，也不把 OCR 置信分数当作完整状态正确的概率。
Comments