B027：自动找到战斗面板，再读出属性

在《英雄无敌：上古纪元》的战斗中，打开一个生物的资料，会出现数量、生命、攻击、防御等数字。整张截图里还有英雄、其他部队和技能栏的数字。AI 要读懂这些信息，首先必须找到正确的面板和字段，不能看到一个 25 就把它当成攻击力。

前一篇实现了“给定正确区域后读取字段”。这一篇让程序从整张截图已有的文字识别结果中自动找区域：先确认几处名称和布局线索，再把区域交给同一个严格读取器。实验单独放在 B027，便于把定位效果与文字读取效果分别记录。

首轮在另外 4 段录像的 26 张原图上测试：42 个允许读取的数字字段中，21 个精确读对、21 个没有输出，没有接受错误数字。但也发现一个关键问题：淡出面板上的文字可以完全读对，面板却还不应该放行。 固定坐标与锚点平移的成绩相同，当前证据尚未显示平移方案更好。

随后冻结 V2，在另外4段录像的24张图上检查：数值精确匹配为26/46，同一批图上的冻结 V1 为19/46。新版本改善了部分区域和字段接口，但仍漏放行同一张翻页魔法书上的两个字段。本文保留首轮结果，在第二轮说明修改、独立检查和失败，避免把开发回归误当新测试。

最新的第三轮加入合并文字的布局线索和魔法书排列检查。在再次更换的4个视频、24张图中，V3数值精确32/41，同组V2为31/41；仍有一张半透明生物面板的5个字段不该提交却被放行。它们文字都读对了，说明下一步不能只靠OCR精度或背景颜色判断可用性。

flowchart TB
 A[Full-frame OCR] --> C[Panel anchors]
 B[Battle context] --> C
 C --> D[Generated field regions]
 D --> E[Strict field reader]
 E --> F[Values or abstentions]
 F --> G[Names and video evidence]

图 1：子场景名称和人工字段框不进入这条推理链。上游仍提供“当前属于战场”以及过渡、断线等画面条件。

1. 全图 OCR 已经读了文字，还缺什么？

OCR 输出每段文字、它在原图中的矩形位置和引擎分数。它可以读出 42/68、19/25、24、25，但不会自动知道第一项是部队数量显示、第二项是单体生命、后两项是攻击和防御。也不能因为两处都写着同一个生物名称，就认定它们是同一支部队。

这里的输入是 2560 × 1440 原图对应的缓存全图 PP-OCRv6 结果，包括原始图与放大增强两个预处理分支。实验没有再次解码视频或运行 OCR，也没有把人工选定的小裁图交给识别器。程序只在这些既有文字上做位置分析和字段解析。

以上是 V1 的输入范围。V2 另读取同一张原图的 RGB 像素，检查生物面板内部的背景外观；文字仍来自原有全图 OCR，没有对小框重新识字。

上游提供大场景与画面条件；具体打开的是英雄资料、生物资料、魔法书还是日志，由本实验查找。名称目录只提供已有英雄、生物、法术与能力的名字和别名，不能提供这张图应有的攻击力或生命值。期待值只在推理结束后用于评分。

2. 用多个线索确认面板，再放置字段区域

一个名称不够可靠：它也可能出现在战斗日志或悬浮说明里。我们要求几个线索的位置相互符合，才产生面板候选。

面板	共同出现的线索
生物资料	阶级文字、上方名称、左侧数量分数及下一行生命分数
英雄资料	目录里唯一的英雄名称、其下职业名称、下方两处资源分数
魔法书	多个法术名称沿水平行排列，并有书内资源分数
战斗日志	多条带时钟的长文字，左边缘基本对齐

找到线索之后，两种方法使用相同的读取器。固定坐标保留开发图中的英雄、生物数值区域；锚点平移根据当前标题的位置整体移动这些区域。比如生物面板下移时，生命、攻击和防御的小框应随它一起下移，而不是继续读原来的战场位置。

这是一项局部对照：两种方法共用面板存在判断，以及魔法书、日志和侧栏分支。它们不是两种训练好的目标检测器，也没有学习所有可能的窗口缩放。当前模板假定完整的 16:9 游戏画面；其他宽高比会明确拒绝。

返回的面板大框用于圈定布局范围，不能作为面板边缘分割结果。读取器实际使用内部的小字段框。它保留两个 OCR 分支的原始读法，冲突或缺字时输出拒识，不从知识库补一个看似合理的数值。

3. 从生物资料读到一个有来源的值

下面是开发录像第 502.061 秒的原图。名称下面有“阶级：3”，左侧有数量和生命两处分数；这些共同建立生物面板候选。

读出“阿迦索斯马塔哈”后，名称组件到既有知识库中做按类型限定的精确名称或别名匹配。成功后得到一个生物种类ID；画面时间、原图路径、OCR行和字段区域也一起保留。因此以后可以沿着结果返回这张原图，核查 24 读自哪里。

这里仍不能确定打开的是我方还是敌方同种生物，也没有建立它与战场上某个框的唯一对应。这些字段先属于“当前打开的生物资料面板”，与底部当前行动单位的生命值分别保存。

4. 在未参与调参的视频上检查

开发使用一个录像中的9张原图。另一位助手先从其他4段录像的缓存交集中固定26张候选图，再逐张看原图写参考；实现者在冻结算法之前没有读取这些图的字段答案。候选中有普通面板，也保留动画、没有详情的战场与非战斗控制图。冻结版本的本地提交为 3ad2d495。

这种隔离可以检查是否只记住了开发录像的位置，但26张主动选择的图不代表所有游戏视频。参考字段也是稀疏的：没有人工核对的生成字段不自动算对。面板是否出现、字段是否读对、错误值是否被接受，需要分别计数。

先检查面板有没有被找到

参考里共有22次详情面板出现。下表的“找到”指算法生成了该类面板的可读候选；它没有另一个只判断“面板正出现在动画中”的输出。因此，本来应该等待的翻页面板，也会在“物理存在”这一指标下成为漏检。

面板	参考中出现	找到	漏检	无中生有
英雄资料	4	4	0	0
生物资料	8	3	5	0
魔法书	7	3	4	0
战斗日志	3	3	0	0

两种方法结果相同。4张没有这些详情面板的控制图均未生成虚假的详情候选。以上样本数很小，尤其不能把英雄和日志的命中解释为已解决全部版本或布局。

如果改问“现在应不应该提交这块面板的读数”，结果会不同：生物资料有4次被参考允许提交，程序找到其中2次，漏掉2次，另外错误放行1次淡出面板；魔法书只有3次稳定出现，3次都找到，另4次动画没有放行。看到了面板，与面板现在可用，必须分别判断。

再检查字段和值

参考一共标了83次字段机会：42个应读取的数字、35段应读取的文字，以及6个应等待或没有目标读数的负控。评分首先要求面板类型、字段语义与数据类型相同，再按位置做一对一关联，最后比较值。关联使用字段框 IoU ≥ 0.10，目的是容纳紧贴文字的参考框与算法搜索框；这不是精确定位的合格线，也没有测面板边缘的检测AP。

检查对象	固定坐标	锚点平移
42个数字字段	21精确，21未输出，0错误数字被接受	相同
35段文字	22逐字精确，3仅空格不同，10未输出，0其他错文	相同
6个应拒绝的字段机会	5拒绝，1错误放行	相同
参考未覆盖的生成字段	300个未评估	300个未评估

“未输出”包括根本没找到面板、没有同语义字段、低分和没有合格文字等情况，不等于OCR全部没认出来。数字读取覆盖率只有 21/42 = 50%；即使这一小组被接受的数字都正确，也不能据此宣称完整链路准确率为100%。额外300个字段没有逐项核对，更不能算入正确数。

冻结的预测先保存，之后才载入参考评分。本地逐帧结果报告展示原图、自动区域、实际值和拒识原因；该入口需要本机标注服务。实验目录的 RESULTS.json 与 README.md 保存完整运行路径、协议和命令。

5. 拒识、错误接受与运行耗时

把一张可读图片拒绝，通常还能等下一帧再读。把错误数字接受，则可能让后续AI使用错误状态。所以实验把“错误接受”单独列出，不只给一个总体正确率。

文字正确，面板仍应等待

这里OCR读出“无话索斯”，与画面相符，目录也存在这个别名。它成功关联到同一种生物，不是错字或错身份。问题在于，名称、阶级和两个分数同时成立，就足以让当前定位器生成一个可用候选；上游又没有标出这次淡出，于是本该暂停的面板被放行。

评分后又查看了相邻缓存原图：524.013秒的同一面板完整、不透明且有生物模型，527.983秒已关闭。中间这张逐渐透出战场的图与关闭淡出过程相符。邻帧用于解释失败，没有倒灌进冻结版的单帧预测。

这次错误不能靠提高名称OCR分数修好：两次读法已经一致且高分。需要补局部面板质量与时序证据，同时保留另一个区别：没有绘制生物模型，并不总意味着旁边的不透明数值条不可读。下一版必须对照正负例判断，不能用“模型缺失”一条规则拒绝所有面板。

多一个标题，会让整块面板漏掉

冻结版要求阶级上方恰好只有一个标题候选。这张图出现两个，程序便拒绝整个生物面板，连清楚的37/37、54/54等字段也一起漏掉。拒绝含混定位符合我们的错误成本，但下一版应结合目录名称和布局排除横幅，减少这种本可避免的等待。

另一张“太阳圣盾”面板有同样的问题。两次面板漏检合计丢失10个数字机会；此外7个数字已被读对，却因输出叫“右侧资源”或没有字段名，无法与参考要求的语义字段对应。这7项仍按原合同记为未输出，不在看过答案后改名补分。余下4个数字机会涉及2个攻击值的低分／缺字，以及2个伤害范围的文字框没有完整落入读取区域。扩大框也要谨慎：其中一条增强OCR把防御和伤害合成了同一行，放宽后可能从漏读变成混读。

当前系统还会整帧拒绝已经标为过渡的图片，可能连仍清楚的侧栏一起挡住。法术图标不同位置的数字也仍分开保存，未显示的中央数字不补成冷却0。

本轮究竟测了哪一段速度？

测量对象是CPU上的位置分析和严格解析，输入为已存在的2560×1440全图OCR；没有新载入OCR模型，也没有裁图重读。26张图共包含2587个OCR行条目，单图1～146个，包含两个预处理分支的重复读法，不能当作2587段不同文字。

测量范围	实测
新进程中导入本实验Python模块	138.90 ms
载入并建立639个规范身份的名称索引	84.63 ms
固定坐标：每帧定位＋字段解析，中位数 / P95	2.81 / 6.47 ms
锚点平移：每帧定位＋字段解析，中位数 / P95	2.62 / 6.30 ms

这是一次新进程、每张图每种方法执行一次的观察结果，不是稳定微基准；不到0.2毫秒的中位数差距不能证明哪个方案更快。名称查询包含在定位中，读出字段之后的身份关联另行计时；空标题较多，使其全帧中位数非常小。源文件验证与读取也单独记录。

表中初始化两项不包含Python解释器启动，因此也不是完整冷启动耗时。视频解码、PNG读取与验证、历史全图OCR耗时，都不在每帧定位＋解析的毫秒数里。OCR行越多，位置筛选通常需要处理更多候选；但本轮没有控制文字量或重复测量，不能据此给出“每增加一行多花多少时间”，更不能换算整张截图OCR的FPS。

6. 第二轮：修标题歧义，再用新视频检查

第一轮结束后，原9张开发图和已看过答案的26张图一起成为开发集。V2 将生物标题候选与已有生物目录做精确名称检查：横幅和生物名称并存时，只有唯一的目录名称可以消解歧义；多个名称仍拒绝。伤害区域可以随当前文字框扩展，但两个 OCR 分支中只要有跨入邻列的合并文字，就保留 UNLOCATED，不删掉坏分支凑答案。

字段命名也做了整理。法术槽位的数字统一叫 positional_counter，继续保留上方、中央或右下角的位置，不叫“冷却”。英雄面板的 resource_right 仍保留通用名称：复核发现，早期资源审核里的“魔法量”角色来自一个尚未证实语义的既有字段，不能拿这个循环引用当独立依据。该读数即使正确，也不为补分而强行改名。

局部外观检查能做什么

V2 在自动定位的生物面板内，检查左侧内部区域：面板宽度的7%～47%、高度的35%～92%。开发版不透明面板的背景偏暗蓝；过渡时露出褐色地形，会降低这类像素的比例。规则为 B-G > 5、B-R > 8、max(R,G,B) < 100，符合的像素至少占85%，且区域每边至少32像素。

这个阈值仅用旧开发数据确定。旧11个参考生物区域里，稳定例的比例约0.852～0.969，淡出例约0.00005～0.741。这是针对当前皮肤的外观筛选，不是不透明度测量，也不是正确概率。 蓝色地形、其他皮肤或遮挡都可能破坏它；右侧有没有生物模型不参与这个判断。

没通过时，只阻断该生物面板的候选字段，保留候选框和拒识原因，不牵连仍可读的 HUD。通过也不能绕过场景、OCR冲突、可见性和字段语义检查。旧26张上的开发回归从21/42提高到33/42，6个负控全部拒绝；这些数值不能再作为独立成绩。

新24张的结果

另一位助手预先固定4个新视频各6张候选图，逐张看原图编写参考，不根据预测挑图。V2 在提交 f26805e6 冻结，先从纯来源元数据生成预测，再读取参考。旧5个开发来源与这4个评估来源不重合。额外跑的 V1 对照使用未改动的旧算法。这是助手审核的小规模主动采样，不是公开基准。

同一批24张原图	冻结 V1	冻结 V2
数值精确 / 46个机会	19	26
数值拒识 / 错误接受	27 / 0	20 / 0
文本逐字精确 / 38个机会	27	28
仅空格不同 / 文本拒识 / 其他错文	1 / 10 / 0	1 / 9 / 0
应拒识的4个字段：拒绝 / 放行	2 / 2	2 / 2
额外未评估字段，每方法	368	367

每一版的固定坐标与锚点平移成绩仍相同，表中没有把两种方法的重复预测当成更多样本。完整参考有22次面板出现、88个稀疏字段机会。稳定面板中，V2找到全部4个英雄面板、2个日志、5个魔法书，以及4个生物面板中的2个；另误把1次翻页魔法书当成可提交面板。

新增的7个精确数值中，3个来自恢复“缟玛瑙舞者”面板的标题定位，4个来自法术数字的字段键显式化；这4个值在V1已读对，只是无法与参考字段关联，不能称作OCR改进。两个稳定生物面板仍漏检：OCR把生命与攻击合成 125/125 28、130/130 33，整行不再是单独的分数，定位器因缺少生命锚点而拒绝。它们合计占10个数值拒识机会；不能删除尾数后假装原OCR没有歧义。

新集只有2个生物面板实际走进外观检查，二者都是稳定正例并通过；其余生物候选已在定位阶段拒识。因此，这次独立检查没有新增证据证明外观规则能拒绝淡出，不能把总体没有放行淡出生物解释成质量门控已被充分验证。

这两项是质量门控漏放行，不是两个OCR错字或两张失败图。生物背景规则不会检查纸色魔法书；多个法术标题依然能满足现有水平排列条件，所以翻页没有被阻断。新参考保持原样，算法也没有在看到失败后偷偷重跑补分。下一版需要单独处理魔法书几何变化，或用有因果顺序的相邻帧证据。

V2复用了2560×1440原图和共2562个全图OCR条目，单图45～150条，含两种预处理的重复。一次新CLI中，基础模块导入138.74ms、额外V2模块导入45.76ms、目录加载81.46ms；不含Python解释器启动。PNG解码中位数/P95为29.48/30.79ms。定位、局部质量检查与严格读数合计中位数/P95：固定4.43/9.55ms，平移3.96/8.97ms。源验证与字段身份链接另外记录。每图每方法只跑一次，包含早期拒识；这些数字不含历史OCR，不能换算成整条视频链路FPS，也不据小差距选速度冠军。

第二轮逐帧原图与结果可检查未输出、负控和原视频时间。代码、协议、完整结果路径见实验目录的 PROTOCOL_V2.md 与 RESULTS_V2.json。

7. 第三轮：保留合并文字，检查书页排列

V3处理上一轮暴露的两个问题。首先，125/125 28仍可以证明这里有一行符合生物详情布局的文字。结合唯一生物名称、阶级、独立数量分数，可以恢复面板的位置；生命与攻击仍为未知，不把整行OCR框切成两个假定小框。即使另一个预处理分支给出清洁分数，只要有任一分支跨越两个字段格，也保守拒识这两个值。

其次，书页上的法术标题必须符合当前UI的两页排列。检查至少3个标题、分布于左右页和至少2行，再核对每个标题距预期行列及同一行的垂直偏差。3行的归一化纵坐标为0.356、0.533、0.718，随自动生成的资源锚点平移；行偏差最多0.012、列偏差最多0.016、同行高差最多0.009。完整列位置与抽样协议在 PROTOCOL_V3.md。这是本帧OCR区域几何检查，不需要再跑文字识别，也不是运动检测器。

开发集的11个书本候选中，10个通过，前文734.007秒的翻页例被拒绝。完整组合在旧9张、旧26张、旧24张上分别读对28/47、31/42、32/46个数字；相应V2为30/47、33/42、26/46。前两组各少读2项，是跨栏分支检查的代价；这三组负控分别4/4、6/6、4/4拒绝。这些都是已经看过答案的开发回归，不能当新准确率。

再换四个来源，结果改善了多少？

V3于提交64e0c113冻结。另一位助手先按旧导航元数据选图，再逐张看原图写参考；主算法先保存预测，之后才打开答案。第三批来自09-04T07-21、09-06T06-20、09-06T22-46、09-07T23-07四段录屏，每段6张。它们没有进入前两轮面板实验，但项目此前已对这些视频做过场景索引；这是本实验的来源隔离，不是全项目从未看过的材料。

候选包含英雄、生物、书页、日志与可能的关闭/遮挡画面，选择错误也保留。这是定向挑战集，不代表正常视频里的类别比例。24张中有17次详情面板出现、14次稳定面板，78个稀疏字段机会。

同一批第三轮24张原图	冻结 V2	冻结 V3
数值精确 / 41个可读机会	31	32
数值拒识 / 错误数值接受	10 / 0	9 / 0
文本逐字精确 / 25个可读机会	21	22
仅空格不同 / 文本拒识 / 其他错文	2 / 2 / 0	2 / 1 / 0
应等待的12个字段：拒绝 / 放行	7 / 5	7 / 5
额外未评估字段，每方法	410	415

固定坐标与锚点平移仍同分，不把重复预测计为更多数据。V3找到全部14个稳定面板，但额外放行1个半透明生物面板；两个未找到的物理面板均为非稳定书页。额外415个字段没有完整参考，不能据此计算整个输出的precision。

净增1个数值不等于只改进了一处：353.968秒“独角兽”面板恢复后，名称与数量、防御、伤害读数新增正确；624.016秒“绝罚者”的生命、攻击则因跨栏规则从正确读取变为拒识。也就是数值新增3项、少读2项，文字新增1项。两种代价都保留在表里。

原图能看到战场透过面板。它的暗蓝背景比例仍达0.9006，超过V2沿用的0.85阈值；这个特征不是不透明度。本轮4个生物候选都进入该检查：3个稳定正例和这个负例全部通过。提高阈值也不是现成答案，因为先前稳定图的比例可以更低。单帧的透明外观不单独证明它正处于打开或关闭过程，参考中的等待策略与具体动画原因应分开。

本轮7个书页候选都是稳定正例，都通过新布局检查；两个非稳定书页先在定位阶段拒识。因此，新集验证了这7个正例没有新增拒识，还没有检验新布局门拒绝翻页的能力。已知翻页例的修复仍属于开发证据，不能换一种说法当作独立成绩。

这次仍输入2560×1440原图，复用完整截图OCR：合计2604条、单图24～155条，包含预处理分支的重复。新CLI基础模块导入147.20ms、额外V3导入52.13ms、目录加载86.51ms；不含解释器启动。PNG解码中位数/P95为31.41/33.08ms；驻留定位＋局部检查＋严格读取，固定方案6.76/13.87ms，平移方案5.91/13.77ms。源验证和身份链接另计，历史OCR和视频解码不在其中。每图每方法只测一次，无法据此宣称速度胜出或端到端FPS。

第三轮逐帧报告保留全部原图、参考、预测和未评估字段。第三轮原结果不在失败分析后重写，后续改动用新版本记录。

8. 从字段区域走向完整战斗观察

这条路线已经把人工给框改成程序根据文字和位置生成框；三轮检查也把问题分清了：面板可能没找到，字段可能没读到，读对的字段仍可能暂时不该提交。下一步需要更可靠的局部可用性证据，并建立字段与战场单位的对应，连接日志和地图占位。固定坐标和平移方案暂时没有准确性差异，不会据此选出所谓优胜算法。

三轮的26、24、24张图现在都已用于失败分析，今后可作为开发回归集；下一版需要明确新的验证方案，不能反复修到已看过答案的样本全对后，仍把它称为独立测试。

资源与技能的语义也要靠原图核对：同一个法术提示框明确显示的“等级”和“魔力”可以帮助解释旁边的数字；无标签的中央数字、条形填充和按钮变暗仍需额外证据。不会因为数字识别成功，就宣称已经理解冷却、可用性或某次行动。