摘要

战斗日志（Logs）是游戏里记录每次攻击、施法、伤害的文字列表，每行以 [时:分:秒] 时间戳开头。项目的日志读取器对每一行做三次 OCR：整图原尺寸、面板原尺寸、面板放大 1.5 倍；然后用解析器把每次读到的文字解析成结构化事件，要求多次读法一致才接受。

上一轮难例评测（A31R）中，40 行可见日志有 3 行被拒、1 行参考答案不确定。本实验不跑任何新的识别，只诊断已保存的三次读数：每次读法是否能被完整解析？各读法之间是一致、矛盾还是缺失？

要回答的问题

日志行被拒，是因为不同读法互相矛盾，还是因为某些读法根本没能完整解析？哪种读法最容易失败？

数据与来源

  • 6 份已保存的难例读数：3 页有日志行（5 行、29 行、6 行，共 40 行），3 页是负例（战场、英雄面板、说明文字），没有日志行。
  • 这 40 行都已在之前的开发中曝光，是开发单位，不是 40 场独立战斗。

方法

  1. 只接收每行原有的三次尝试，分析时不读取参考答案或已有正确性标签。
  2. 每次尝试调用一次已有的文字解析器，记录：能否完整解析、解析出的事件类型、是否有“时间戳形状但缺右括号”的前缀、原始文字是否跨行、分数。
  3. 每行归类：三次完整且相同、两次完整且相同、只有一次完整、没有完整、完整但互相矛盾。分数低不改变“是否完整”，单独报告。
  4. 两两比较读法，结果分五种：同一完整事件、不同完整事件、都不完整、只有前者完整、只有后者完整。
  5. 所有诊断算完后，才读一次已有的评分输出，把历史状态（正确/被拒/参考不确定）挂到对应行上；不重新匹配、不重新计算正确性。

注意：语法上完整、读法一致，都不等于识别正确；同一引擎的不同预处理是相关的，不是独立投票；“缺右括号”只是字符串标记，不证明像素上真的缺了括号。

设置

诊断定义、实现和 15 个合成测试用例在分析前冻结。零新图、零解码、零 OCR、零 GPU；120 次解析器调用，总耗时约 8 毫秒。34 项新测试和 399 项相关回归通过。未改生产代码。

结果

每行分类（40 行）：

分类 行数
三次完整且相同 24
两次完整且相同 13
只有一次完整 3
没有完整读法 0
完整但互相矛盾 0

按读法统计：

读法 完整 不完整 不完整中“缺右括号” 分数 <0.90
整图原尺寸 34 6 6 0
面板原尺寸 38 2 2 0
面板放大 1.5 倍 29 11 11 0

所有不完整读数都伴随“时间戳缺右括号”的前缀，而且分数都 ≥0.90——也就是说，OCR 很有信心，但漏了一个括号，解析器因此判为不完整。

两两比较：三组读法对之间都没有出现“不同的完整事件”。例如整图原尺寸与面板原尺寸：34 行同一事件、2 行都不完整、4 行只有面板完整。

历史状态：36 行原为正确、3 行被拒、1 行参考不确定。3 行被拒的都属于“只有一次完整”：两行只有放大读法完整（另两种缺右括号），一行只有面板原尺寸完整。参考不确定的那一行有两次完整且相同的读法，但参考本身无法核实，诊断不改变它的状态。

失败与负结果

这是诊断，不是修复：没有尝试任何补救候选，也没有新的正确率。“缺右括号”只是字符串现象，像素层面的真实原因没有验证。Windows 计时器分辨率不足，CPU 时间报为 0，不代表没有工作量。

局限

40 行全部已曝光；三种读法来自同一引擎，相关性强；不完整与识别错误是两回事。

结论与下一步

日志被拒的主要原因不是读法互相矛盾，而是某些读法漏了时间戳的右括号导致解析失败，而且不同读法漏括号的行不同。这提示后续可以针对时间戳前缀做有界的处理，但任何新的获取或候选试验都需另行立项，诊断结果不自动推进到生产。