摘要
在竞技场的选择阶段（例如选神器、选法术的页面），游戏会把当前英雄的预览面板放在屏幕左侧，右侧是待选的物品。英雄面板里有头像、主技能、子技能、穿戴的装备、兵种格子等。
上一个实验发现选择页上的圆形按钮被误当成了装备位。查看原图后找到更大的根因：面板检测器其实已经正确找到了左侧的英雄预览，但元素读取器总是固定裁屏幕中央的英雄窗口——于是漏掉真正的英雄和装备，又把右侧选项和控件混进结果。只删掉这些错误输出会继续漏读。
本实验新增一条显式路由：当图里只有一个符合左侧布局的英雄面板、并且头像位置登记成功时，就裁实际的左侧窗口，并把装备角色、身份、数值读取平移到这个位置。在 19 张左侧页面上，声明的界面框（IoU≥0.5）从 108 提到 608/741，召回 82.05%，多余的角色框从 26 降到 0。但 133 个空兵种格仍全部漏框，没有被当作“空槽读对”。
要回答的问题
如果按实际检测到的面板位置去裁图和读取，左侧英雄预览上的头像、技能、装备、数值能读对多少？会不会影响原本正确的中央面板和其他画面？
数据与来源
- 19 张左侧页面截图，来自已有的数据分组：7 个训练来源组共 11 张、2 个校准来源组共 3 张、1 个最新来源组 5 张。不是 19 段新视频。
- 每张图声明 39 个界面位置：1 个头像、8 个主技能槽、9 个可见子技能、14 个穿戴装备、7 个空兵种格；另有 10 个字面数值字段。
- 背包、分类按钮、职业 / 专长、右侧待选物品不在本轮实现范围。
- 最新组是已暴露的开发来源，没有打开冻结的测试素材。
- 回归对照：已有的 371 张原图（含中央面板、日志、HUD 等）。
方法
- 显式路由。 只有当前图只有一个符合原生左侧布局的英雄面板时才裁左侧窗口；还要本图的头像位置登记成功，才启用平移后的装备角色、身份和数值读取。输出框仍用原图坐标，保存原始提案和布局证据；不使用场景真值、前后帧或历史身份去填答案。
- 不重训现有模型。 元素检测器和身份模型保持不变。
- 左侧装备占用分类器。 左侧装备格另训一个局部“有 / 无装备”分类器（支持向量机 SVC，配方不变），训练数据为 434 张旧训练裁图加 154 张逐格审核的左侧裁图。七个训练来源整组留出时 588/588 正确，这只是训练诊断。
- 空槽参考库。 增加 66 个左侧训练空槽，合计 224 个，判定门槛仍为 0.02；中央面板继续用原模型和原参考库。
- 技能等级数字。 左侧技能数字更暗。扩大裁剪边界的尝试无效（保留为失败）。在训练的 68 个等级位置和 20 个空技能位置上，中性亮度门槛 90 能恢复 88/88，门槛 110 只有 67/88；因此只在登记成功的左侧使用 90，默认 145、字形模板和接受门槛不变。
- 以上配方冻结后才跑校准和最新来源，没有按它们的答案调参。
设置
| 项目 | 设置 |
|---|---|
| 定位判定 | 声明框与输出框 IoU（交并比，两框重叠面积 / 合并面积）≥0.5 算对 |
| 分母 | 包括漏框 |
| 计时 | 最新组 71 张图，热文件 → 检测 / 身份 / 跨进程 OCR / 日志 → JSON |
结果
| 声明范围 | 训练 11 张 | 校准 3 张 | 最新 5 张 |
|---|---|---|---|
| 界面框正确（含漏框分母） | 63→352/429 | 17→96/117 | 28→160/195 |
| 主技能有无 | 88/88 | 24/24 | 40/40 |
| 子技能有无 | 99/99 | 27/27 | 45/45 |
| 技能等级 | 68/68 | 18/18 | 27/27 |
| 装备有无 | 154/154 | 41/42 | 68/70 |
| 数值字段 | 109/110 | 30/30 | 50/50 |
| 空兵种格漏框 | 77 | 21 | 35 |
合计：界面声明框 IoU≥0.5 从 108 提到 608/741（召回 82.05%），多余的角色框 26→0；在更严格的 IoU≥0.75 下同样是 608/741。这不是全场景的 mAP，也不是所有界面元素的准确率。
身份：本轮接受的 414 项（19 个英雄、109 个主技能、150 件装备、136 个子技能）逐项对照原图与标准图案，都能对应。声明的 454 个有身份的可见位置中仍有 40 项未被接受（4 个主技能、1 件装备、35 个子技能）。这是对已接受输出的审核，不是独立盲审；“最新组 106/116”是候选覆盖与审核结果，不是校准过的置信度。
整图回归：串行重读 371 张原图，352 张非左侧图的输出除计时外逐字段相同；19 张左侧图的场景、面板、日志和非英雄字段保持，新增 190 个英雄字段。原 4,698 个数值观察保留，总数变为 4,888；元素 3,915→4,389，读取失败 0。
速度：最新组 71 张图 p95 1.085 秒，最大 1.185 秒；界面冷加载 3.833 秒、OCR 冷加载 5.101 秒。不含 App 截图、传输和展示，不是 App 整条链路的 3 秒验收。没有做交替对照实验，所以与上一实验的时间差不算算法提速。
测试：专项 39 项通过；Perception 全套 7,303 通过、6 跳过、2 个既有的冷导入顺序失败。
失败与负结果
- 133 个空兵种格全部漏框。 缺框不能当成空槽读对。
- 3 个清楚的空装备槽被误拒（校准一个鞋位、最新组一个副手和一个头盔位）；训练组一个攻击数字“1”拒读。都没有改标签掩盖。
- 标注几何错误。 第一次严格计分时所有子技能都失败；按像素边框复核，发现标注脚本把子技能框原点写成 (505,272)，正确应为 (506,265)。这是标注错误，模型没改。修正后，新输出 IoU≥0.5 的成绩不变，旧基线 93→108；严格成绩 437→608。原始计分结果保留。参考框采用重复布局，不能当独立的盲定位真值。
- 中间的一份审核记录误写“44 项未接受”，逐项重数后改为 40；测量输出本身没变。
- 扩大技能数字裁剪边界无效。
- 校验脚本第一次没有允许“数值覆盖状态从未请求变为候选”这一预期变化，修正后无非预期差异；旧校验报告保留。
- 上一实验遗留的身份 124/130、英雄 20/22 及淡入画面 4 个漏读没有改变。
局限
- 只覆盖声明的 39 个位置和 10 个数值字段，背包、职业专长、右侧待选物品不在范围。
- 最新组是已暴露的开发来源。
- 身份审核是看着输出做的，不是盲审，也没有给拒读的身份补真值。
- 没有接入战斗记录 App、状态估计、规则模拟器或 AI。
结论与下一步
问题的根因不是“误检太多”，而是“裁错了地方”。按实际面板位置读取后，左侧英雄预览从基本不可用变成大部分可读，同时不影响其他画面。
下一步：为训练来源补空兵种格和低对比度槽位的标注并训练检测，避免固定猜框或把漏框当空；处理三个左侧空槽误拒、上一实验的两个过渡页误拒和淡入缺框；然后按风险补子技能、魔法书、攻击预览和中央紧凑的技能选择页。十场独立真实对战、逐场景 / 字段 95%、App 整链路 3 秒的项目目标仍未达成。
Comments