摘要
前几轮已经训练好两个模型：一个在整张战斗截图上框出生物“身体”（战场上的角色形象）的检测器，一个判断身体属于 144 种生物中哪一种的身份模型。但它们只在实验脚本里运行。本实验（内部编号 B090）把它们接进项目的单张截图读取工具，让一次读取就同时输出界面字段和战场生物候选，并检查三件事：输出是否与实验一致、是否影响已有输出、整次读取要多久。
结论：组合没有改变模型输出，也没有改变其他界面输出；但一个“被面板挡住就排除”的简单规则会误伤半露的真实生物，魔法书的装饰也会产生错误候选。
要回答的问题
- 接入后，生物候选是否与冻结的实验结果完全一致？
- 未启用时、以及启用后的其他界面字段，是否保持不变？
- 菜单、选择页、各种面板上会不会误报“生物”？
- 一次完整读取的耗时是多少？
数据与来源
组合集 30 张图，来自 5 个已开放的来源组：12 张近期带攻击预览的战斗图，加训练集里 9 类场景各 2 张（菜单、选择页、英雄/生物面板、魔法书、日志等）作为控制图。全部是开发/回归材料，没有新的独立测试，封存来源未打开。
方法
- 新的私有读取器常驻检测器（YOLO26s，输入 960，置信度 0.40）和身份模型，复用现有的检测适配、裁剪和身份运行时代码；不输入真实框、标签、未来帧、军队名单或场景答案。
- 读取工具新增一对必须同时给出的参数：检测器权重和身份权重。结果放在
battlefield_bodies字段：定位框、裁图框、未校准的前 5 个身份候选、排除原因和计时。 - 不填“确认身份”、阵营、数量、行动者，也不自动把身体和攻击预览目标绑定。身份读取失败时保留定位；检测失败时保留其他界面结果；只请求局部面板时不启动整图身体扫描。
- 遮挡规则：如果本帧检测到的面板覆盖某个身体候选面积的一半以上，就把它放进
excluded（排除列表），不当作“没有生物”。
设置
串行运行，没有并行的训练或测试；外部系统负载未控制。成本测量启用当前所有显式功能（面板、英雄/装备/军队、身份核对、子技能参考、日志、数值 OCR、伤害预览、书页角标、身体），先用 5 张不同场景预热，再对 30 张图各跑两次，包含文件解码、OCR 进程通信和 JSON 保存。
结果
一致性：
- 12 张近期战斗图共 169 个身体候选，重新跑检测和身份后，框、裁剪和首选身份与冻结结果全部一致。这只说明接入没有改变模型输出，不说明 169 个都认对。
- 30 张图分别启用/关闭对照：除新增的身体分支和配方标记外，原有界面输出全部保持。
- 6 张技能/宝物/最终确认的纯界面图，身体候选均为 0。这不是一般菜单的误报率，生物选择页仍未覆盖。
完整单图读取耗时（60 次热调用）：
| 指标 | p50 | p95 | 最大值 |
|---|---|---|---|
| 完整返回 | 1.161 秒 | 2.188 秒 | 2.386 秒 |
| 加 JSON 保存 | 1.165 秒 | 2.196 秒 | 2.392 秒 |
近期战斗图 24 次 p95 为 1.500 秒，魔法书 4 次为 2.241 秒（分母很小）。命令行冷启动一次完整读取 30.05 秒，其中 OCR 首次加载 20.61 秒。
失败与负结果
- 遮挡规则误伤：生物面板内的展示插画（一条龙）被正确排除；但另一个真实生物被面板挡住一半，也被保守排除。这是可用信息的损失，不能算排除规则成功。
- 魔法书装饰：两个区域里书签、皮带等装饰占了框的大部分，背后又露出真实生物的一部分；首选身份是错的且分数很低（0.032、0.066）。它们不是干净的背景负例，不能直接标“无生物”，也不能盲目扩大遮挡区域而挡住旁边的真实身体。
- 成本汇总里原本叫“冷模型加载”的 4.48 秒实际只计了界面配置，OCR 是在预热时才懒加载的；已更正字段解释，不把它当总冷启动。
局限
这是私有读取入口的工程速度样本，不是 App“截图→显示”的端到端时延，也不是十场质量验收。身份候选未校准。控制图复核有限，不是完整的身体/身份精标。全模块测试本轮未重跑，既有 2 个失败仍未解决；16 个相关测试文件 184 项通过。
结论与下一步
生物候选现在能通过单一入口和其他界面字段一起读出，接入本身不改变任何已有结果。下一步回到质量：定向补三种训练中身体样本为 0 的生物（臃肿仲裁者、虫巢之母、地狱九头蛇）和食尸鬼；同时补“当前像素被遮挡”的对照，改进面板遮挡判断，不把模糊块当背景负例。
Comments