摘要
用户录了一局与电脑对战的视频（10 月 9 日 08:38，约 12.75 分钟），专门展示生物面板的状态图标、悬停说明、远程攻击预览等，并要求把它加入训练集。整段只进训练池，不做测试。本文记录 10 月 12 日围绕这段录像中战斗日志（Logs，游戏里逐行记录攻击、施法、伤害的文字面板）做的三步工作：
- 建最小参考并实跑当前读取器：三张日志截图上标了 28 条日志关键字段、30 个 HUD 数值、3 个回合标记。当前读取器 28/28 条选定字段读对，但每张图 CPU 约 70 秒，“第 4 回合”标题被判为未知。
- 阶段计时：拆开测量一张图约 72 秒的去向，99.7% 以上在 OCR 本身；现有的整图缓存已经生效，没有找到能安全删掉的冗余 OCR。没有改生产配方。
- 定位并修复第 4 回合：保存完整中间结果后发现，第三次 OCR 其实读对了“第4回合”，只是它的框右边与定位框相差 16.667 像素，超过行匹配允许的 16 像素而被丢弃。只对回合标题增加一种受限的“居中”匹配后，三个标题全部保留，其它行和公开 SE 结果都不变。
要回答的问题
- 当前日志读取器在这段新录像上表现如何？
- 每张图约 70 秒花在哪里，有没有不改识别配方就能省掉的部分？
- “第 4 回合”为什么读不出来？是没检测到、被裁掉、认错字，还是匹配问题？
数据与来源
- 来源：一局打电脑的录像，用户选为训练来源。不是独立测试。
- 三张日志原图，媒体时间分别约 9:00.6、11:13.97、12:34.19；另有一张 220.6 秒处的日志图用于计时。注意：表中时间是“看到这页日志”的视频时间，不是每个动作发生的时间；日志里的游戏时钟也不等于视频时间。
- 参考标注：28 条日志、30 个 HUD 标量、3 个回合标记，由 AI 助手直接看原图写成（模型目视核对），未经用户逐项认证，不是独立真值。只标实际可见字段；隐藏技能/装备、命中时的攻防和状态、因果归属等一律未知。
方法
读取器实跑：使用当前生产日志读取器，开启与 App 相同的“宽松共识”和“扩展文法”选项，CPU 运行。读取器对一张图做三次 OCR：整图一次、日志面板原尺寸一次、面板放大 1.5 倍一次，三次结果通过“行匹配”对齐后取共识。先把输出全部写盘，再打开参考做对比，参考不进入模型输入。
阶段计时：对 220.6 秒那张图顺序跑两遍：一遍独立读取，一遍走路由读取器（先读整图填缓存，再读日志分支）。给模型对象加透明计时代理，分别记录检测和识别时间。
第 4 回合诊断：旧结果里没有完整的第三次 OCR 输出，因此按原设置只对该图复验一次，保存检测框、原始文本、分数和映射回原图的坐标，先诊断、后改算法。
设置
8 物理核、低于正常优先级；使用本机已有 OCR 模型缓存；本任务没有并发其他重任务，但不能证明全机无外部负载。
结果
读取器实跑：
| 参考项 | 实际结果 | 解释 |
|---|---|---|
| 28 条选定日志 | 28/28 选定字段匹配 | 一个已曝光训练来源的小切片，不是全行准确率 |
| 3 个回合标记 | 3 和 5 读出，4 为未知 | 未知不是“回合 0” |
| 两条“专注蓄能”记录 | 原文保留，结构解析为空 | 文法尚不支持这类记录，不在 28 条分母里 |
| 30 个 HUD 标量 | 未运行 HUD 评测 | 不计入成功数 |
初始化 4.428 秒，三张图分别 71.731、70.421、70.118 秒。
阶段计时（初始化 4.198 秒，不计入）：
| 调用 | 首遍：检测 / 识别 / 合计（秒） | 已加载模型再跑（秒） |
|---|---|---|
| 整图 2560×1440，63 条 OCR | 14.572 / 15.943 / 30.524 | 14.364 / 15.664 / 30.037 |
| 面板 1364×1080，30 条 | 5.652 / 11.589 / 17.248 | 5.562 / 11.263 / 16.833 |
| 面板 1.5 倍 2046×1620，31 条 | 13.516 / 11.889 / 25.424 | 13.209 / 11.371 / 24.597 |
| 整套墙钟 | 73.237 | 71.654 |
解码、场景判断、日志定位、29 行共识与文法合计只有几十毫秒。第二遍中整图缓存预填 30.042 秒，之后日志分支 41.472 秒，只再做两次面板 OCR——说明缓存已经在工作，而不是“从 72 秒优化到 41 秒”。两遍结果与上一轮保存结果逐字段相等。
第 4 回合诊断：
| 读取 | 原图坐标框 | 文字与 OCR 分数 | 与定位框的右边差 |
|---|---|---|---|
| 整图 | [1205,584,1330,612] | 第4回合，0.9999153 | 2 像素 |
| 面板原尺寸 | [1199,585,1347,613] | 第4回合，0.9999156 | 15 像素 |
| 面板 1.5 倍 | [1202,584.667,1348.667,612.667] | 第4回合，0.9999335 | 16.667 像素 |
定位框为 [1203,583,1332,613]；第三读垂直重叠 28 像素（要求 18）、左边差 1 像素。所以不是裁掉、漏检或认错字：原行匹配规则要求右边差最多 16 像素，第三读被挡在匹配阶段。最终的“低分”来自匹配失败后写入的空记录（0 分），并不是 OCR 真给了 0 分。这些都是引擎分数，不是校准概率。
修复：只对回合标题行增加一种匹配方式——中心差 ≤8 像素且宽度差 ≤24 像素也算同一行（24 沿用原来两边容差之和 8+16，没有针对本例把 16 改成 17）。普通日志正文仍用原规则；垂直重叠、三读数量、分数 ≥0.90、文字共识、单一匹配等要求全部保留。不按期望数字选框，多个框同时匹配仍拒绝。
修复后：
- 第 4 回合图：用刚保存的三次真实 OCR 重放，只有这一行从未知变为“第4回合”候选，其他行、来源、几何完全不变。
- 第 3、5 回合图：各按原配方真实重读一次，结果与旧值相等。
- 220.6 秒图：重放三份完整 OCR，结果相等。
- 公开 SE（状态估计）在“准备页 + 日志”的两个累计前缀中只替换这张图：日志事件数 54/54、80/80，完整 SE 结果完全相等。这两个前缀中没有敌方施法，所以回合边界没有可收紧的施法范围。
失败与负结果
- 第 4 回合在首次审计中被拒；修复只恢复了一个标题文字候选，日志章节标题不会自动成为“当前战斗回合”或事件。
- 计时没有找到可以安全删除的冗余 OCR。删某个尺度、换检测框、缩图、换模型或降低共识门槛都会改变识别配方，不能当作等价的小优化。这不等于证明性能无法改善——只是这次“配方不变”的尝试结束了，性能问题仍未解决。
- 外部审阅指出的风险保留：居中回退确实扩大了部分水平范围，最坏一侧偏差可约 20 像素；三次 OCR 同源同模型，不能排除相关误识别；“某段唯一的居中错误文字顶替标题”是潜在负例，目前没有真实失败样本。
局限
- 只有一个已曝光的训练来源、几张图；28/28 不是整体准确率，三个标题从 2/3 到 3/3 只是局部覆盖变化。
- CPU 计时只覆盖日志读取器，不含整帧路由、排队、SE、界面，不能估计 p95。
- 8 个新增负例测试和共 649 项不同软件检查通过（含 SE 与 App 的消费测试），只证明行为，不是识别准确率。
结论与下一步
清晰日志的关键字段已能读对，但 CPU 成本高（每张约 70 秒），且几乎全部在 OCR 本身。第 4 回合的失败是一个可以精确定位的几何匹配问题，已用局部、受限的修改修复，本例到此为止，不再围绕标题调参。下一步回到 SE 的属性目标：把同局已保存的准备页、面板、HUD 和这些日志按媒体时间合法累计成请求，检查新增真实观察能否解除归属和数值约束，并列明最接近合法属性查询还缺哪些具体字段（这项组合对照之后已完成，见 E003）。
Comments