摘要

战斗日志读取的结果会保存成 JSON：每一行有原生图片中的框、三次 OCR 尝试的原文和分数、解析出的内容，以及是“输出”还是“未知”。之前有一个基线读取器和一个私有候选规则各自产生过 6 个案例的结果。历史上的审阅脚本只能生成快照报告，自动化调用方需要一个能返回明确“通过/不通过”的命令。

本实验做了这样一个只读检查命令：它把已有的输出完整性校验器（第 3 版）和不依赖参考答案的读取诊断组合起来，不生成候选、不修字、不评准确率、不打开原图。对 6 对已有结果做一次正式检查：全部通过，退出码 0。

要回答的问题

能否用一个只读命令，对已保存的日志读取结果做严格的结构和证据检查，并把“证据有问题”和“输入有问题”用不同退出码区分开？

数据与来源

6 个固定案例的基线输出和候选输出（共 12 个 JSON 文件）：一个 5 行短日志、一个 29 行滚动日志、另一个 6 行日志案例，以及 3 个负例（按案例名分别是战场、英雄和说明文字画面，不应有日志行）。命令只读这些 JSON，其中记录的原图路径只是元数据，不会被打开。

方法

  1. 每个文件最多读 4 MiB；拒绝重复 JSON 键、非有限数值、非法 UTF-8/JSON。
  2. 预检：基线必须是路由器第 1 版格式、只有一个日志任务、每个文件最多 64 行；拒绝重复选择、身份混用和重复使用的输出路径。
  3. 每对文件调用一次完整性校验器，并对原始日志尝试做一次诊断。两者结果分开报告：解析完整不能抵消证据无效，“未知”也不算完整性失败。
  4. 只报告行编号、诊断标记和原因，不复制原文或解析内容。
  5. 退出码：0 = 所有选中对都通过；1 = 至少一对证据无效；2 = 输入、选择或输出出错。

设置

命令和合成测试在检查前冻结。新增 24 项命令测试，加上 558 项相关回归，共 582 项通过（0.80 秒），覆盖真实子进程对无效证据返回 1、严格 JSON、读取上限、保留“未知”、不覆盖已有文件等。

结果

一次正式检查读取 12 个文件、校验 6 对，退出码 0。

项目 数量
保留的原始行和框 42
原始读取尝试 126
基线输出的行 24
已有的私有候选提升 13
保持未变的行 29

40 个日志行的诊断分类：三次完整且内容相同 24 行，两次完整且相同 13 行，只有一次完整 3 行（这 3 行仍保持“未知”，诊断不会凭语法造出输出）。

实际文本解析调用：完整性 392 次、诊断 120 次。原图读取、解码、OCR、GPU、新候选生成、准确率重评和参考读取都是 0。

失败与负结果

本次检查没有发现无效证据。

局限

  • 退出码 0 不代表 OCR 正确、所有可见行都被输出、参考确定或已被独立验收。
  • 这是作者自己运行的软件/完整性检查，没有记录独立验收。
  • 只支持这种私有转换格式和基线策略；其他合法的公开路由输出需要自己的适配器。
  • 历史准确率不变：候选在 39 条可读完整行中正确 36 条，输出的 36 条可核实行全部正确，另有 1 条输出的完整参考不确定。

结论与下一步

已保存日志结果有了一个可被自动化调用的只读检查入口，能区分“证据无效”和“输入错误”。它适合作为后续流水线的守门检查，但不能替代真实图片上的准确率评估。