还没有执行攻击，只是把鼠标移到敌方单位上，游戏便可能显示伤害和预计击杀。魔法、英雄技能和生物技能也可能有类似的目标预览。读取这些信息，可以让后续AI比较行动选项；但程序必须区分“将要发生什么”和“已经发生什么”。
我们先从三段现有录像建立参考：50张不同原图，30张包含目标预览，20张只有说明、日志或其他对照。 对全部原图运行或复用OCR后，两行数字的位置规则找到了30个完整预览区域中的29个；同时定位且选对两行文字的只有25个。它已经可以辅助找训练样本，距离直接作为决策输入还有差距。
1. 输入和输出到底是什么
输入是一张2560×1440的完整游戏截图、原视频路径与时间。必要时回看前后几秒，确认玩家之前选择了哪种动作。目标输出包含当前面板、预览区域、可见数字、动作类别、发起者和目标实例。缺证据的字段保留未知，尤其不能从一串数字猜出具体技能。
图1：普通攻击的原图，点击可打开原尺寸。目标上方显示预计击杀8–11、伤害1131–1508；剑形光标、目标格和当前单位提供动作证据。这张图没有证明攻击已执行。
上图只是便于阅读的放大裁图。本次基线的OCR输入仍是完整原图，并未先给它这个裁图或场景标签。
flowchart LR
F[Native screenshot] --> O[Full-frame OCR]
O --> P[Numeric row-pair proposals]
F --> C[Panel and action evidence]
P --> R[Visible preview or unknown]
C --> R
R --> A[Action and target association]
A --> D[Reviewed data]图2：本轮实际实现了OCR后的数字候选定位；动作与目标关联目前由审核提供参考，没有把它们的人工结果作为定位算法输入。
2. 同一张图可以有多种标注
| 当前内容 | 这轮记录什么 | 不能混成什么 |
|---|---|---|
| 单位上方的预览 | 伤害、击杀、对应区域及目标证据 | 已经造成的伤害 |
| 魔法书或技能说明 | 原文、描述数值及所属面板 | 当前目标一定会承受的伤害 |
| 战斗日志 | 某行实际显示的结果 | 之前预览的“正确答案” |
| 被面板遮住的预览 | 可见部分、遮挡范围、未知完整值 | 完整可读的数字 |
图3：范围魔法同时给两个单位显示预览：18 / 830和27 / 830。我们回看537–541秒的5fps上下文，看到鼠标停在“寒冬循环”图标上，随后魔法书收起、范围指示随鼠标移动。因此动作标为SPELL，依据是连续画面，不是单张图里的830。
这张原图还标了双方计时、攻击/防御/法强和魔法量。首批数据中共有24组这样的HUD读数，以及3个帮助关联目标的区域框。这3个框是目标定位参考，不是紧贴生物全身的检测训练框。 其他生物与身份没有顺带标成已检查。
图4：稍后的日志显示870伤害，而前面的预览是830。两处都按实际可见内容保存；本实验不推断差异机制，也不拿日志数值覆盖预览标注。
3. 数据覆盖到哪里
三段来源为9月7日07:19、9月7日23:07和9月8日02:42的录屏。先检查已有原图/两秒预览，再仅对候选附近补原图和短上下文，没有重算全部视频。
| 目标预览类别 | 原图数 | 保守归并后的决策组 |
|---|---|---|
| 普通攻击 ATTACK | 21 | 14 |
| 魔法 SPELL | 5 | 5 |
| 动作来源未知 | 4 | 4 |
| 技能 ABILITY | 0 | 0 |
30张预览图中有29张可读、1张部分遮挡；范围魔法有两个数字区域，因此合计31个区域，其中30个完整。另有20张纯对照：5张无预览、3张过渡、10张说明、2张日志。一个预览样本还可以同时带属性或说明标注；同一原图不会因为两种用途变成两个独立样本。
所有标签经过助手目视审核，属于开发参考。候选筛选、误例分析都看过这些数据，本轮没有训练动作分类器，也没有独立留出测试；表中的多张相邻图不能当成同等数量的独立事件。
图5：生物面板右缘仍露出预览尾部7 / 420，但左侧被挡住，不能保证没有其他数字。它被标为PARTIAL，完整伤害和击杀字段为空；只参与部分区域定位检查，不参与完整数字正确率。
标注入口在本机的战斗详情网站。可切换文字、单位和HUD图层，查看原分辨率图片和来源视频；此前22张面板详情参考仍在原批次中。
4. 为什么“有OCR”仍会漏掉它
最初在三份稀疏OCR缓存里搜索“预计”“伤害：”“击杀：”等词，未确认目标预览正例。回到原图后发现，许多预览只有骷髅图标、伤害图标与两行数字，根本没有这些关键词。关键词没有命中，不等于OCR没有读到数字。
本轮使用已有PP-OCRv6 medium检测与识别模型。50张完整原图中，30张复用匹配的缓存，20张补跑；每张均保存原图与1.5倍增强版本的结果。以下定位基线只读取ORIGINAL，避免把两种版本重复计成两份证据。
第一步严格解析整数、范围和可选百分比，例如1131-1508、112(50%)，不把正文或2/4塞进伤害字段。第二步筛选在纵向相邻、横向相近的两行数字，暂时排除顶部和底部主要HUD带。它不看参考框，也不输入人工场景/动作标签。百分比后缀原样保留，其机制含义本轮没有标注。
数字候选依然输出UNKNOWN动作、UNKNOWN语义角色和UNKNOWN目标。只有形状和位置，不能证明它一定是伤害。
5. 两个问题分开计分
给定正确框能不能读到文字，与不提供框时能不能找到它，是两个不同问题。
| 测量 | 本轮结果 | 分母与限制 |
|---|---|---|
| 给定参考区域，在OCR结果中找回完整原文 | 57 / 60条 | 30个完整区域，每区两条；这是已知区域诊断 |
| 给定区域，两条文字都找回 | 27 / 30区 | 不表示自动定位已成功 |
| 全图规则定位完整区域 | 29 / 30区 | 输入全图OCR；不提供参考框 |
| 全图定位并选对两行文字 | 25 / 30区 | 自动选择的配对必须两行都精确 |
| 部分遮挡区域定位 | 1 / 1区 | 不计完整数字正确率 |
| 纯对照上产生候选 | 0 / 20图 | 仅限这批已看过的对照 |
全图共提出32组数字对；其中2组是同一位置的备用错误配对。定位匹配按几何与确定顺序处理，不用参考文字挑出“恰好正确”的那组。因为这些是挑选过的开发图，以上结果不代表全视频召回率，也不代表“动作、目标、数字全部正确”的成功率。
图6：三处原图错误。左边上行9被漏掉；中间OCR把预览15和后面的单位数量46粘成1546；右边把7和背景38粘成738。后两项引擎分数分别约0.99956、0.99838，仍然很高。高分不能证明数字属于同一个UI字段。另两处配对错误来自图标附近被识别出的多余0。
这也解释了为什么下一步需要前景文字与背景数量的分离、区域可读性判断，以及目标数量等独立证据。当前遇到这类矛盾应拒绝把候选直接用于决策；不能仅靠OCR分数自动放行。
6. 速度：这次实际测了什么
补跑20张图时使用一次常驻GPU进程，Paddle3.3.1、PaddleOCR3.7.0、PP-OCRv6 medium det/rec。模型已在本地缓存，未计下载。原始截图2560×1440；增强输入3840×2160。每张原图检测到27–86条文字，不只是一个预览框。
| 步骤 | 时间 |
|---|---|
| 导入依赖与模型初始化 | 8.37秒，一次 |
| 原图完整画面OCR | 平均0.214秒/图 |
| 1.5倍增强完整画面OCR | 平均0.351秒/图 |
| 两次OCR、图片读取与增强等合计 | 平均0.600秒/图；中位0.544秒 |
这不是单个文字裁图的速度，也不是完整视频端到端速度。数字配对的缓存回放很轻，但没有包含视频解码和OCR推理；不能拿缓存回放时间宣称实时能力。我们没有在固定图片内容下单独控制文字数量，因此本轮也不能量化“每多一行文字增加多少耗时”。详细计时和引擎版本保存在B034运行记录中。
7. 关键帧只是获取数据的方法
五帧稳定、按5fps采样、找到一张清晰图，是三种不同条件。本轮用5fps短上下文确认了五次魔法选择来源，却没有要求这些上下文全部稳定。清晰的预览帧可以立即用于文字标注；待机动画、面板翻转和字段可读性各自记录。
现有证据说明：关键词检索会漏掉无关键词数字预览；稳定帧路线是否已经足够、独立变化路线能增加多少覆盖，还没有在同一批完整时段上比较。因此暂时保留这些采样入口，不宣称它们都必需，也不为了统一流程丢掉清晰短提示。B033负责进一步验证长段去重和采样覆盖；B034负责这些图上到底显示了什么。
下一步优先补技能释放前的目标预览，并扩充魔法到不同目标、不同伤害结果。最小补录方式是：打开技能说明→选择技能→依次悬浮两个目标→取消；魔法和普通攻击也各做一次，保留一次短悬浮、一次较长停留及明确取消。无需为了满足采样器而强制每次停一秒。
数据补足后，再比较数字区域分离、OCR和动作/目标关联。在此之前，这轮交付的是可查看的标注与可复现的候选基线，暂不训练一个缺少技能正例的三类动作模型。
Comments