摘要
战斗日志（Logs）是游戏界面里逐行记录攻击、反击、施法等事件的文字面板，每行形如“[时钟]玩家名: 正文”。读取器对每张日志截图做三次 OCR（整图、日志面板原尺寸、面板放大），只有三次结果达成共识才接受一行。
在一局用户选入训练的录像（10 月 10 日 01:39）里，一张截图的第 9 行是一次反击，但旧的三次读取中：整图读漏了玩家名、把“凤凰”读错；两个面板读取的正文一致，玩家名却不同（类似“aaoca”和“akaoa”）。结果被判为“读取冲突”（READ_CONFLICT），这一行没有进入状态估计（SE）。
本实验对这一行做一次有界诊断：复用原自动行框、加固定边距，用现有 OCR 在三个尺度上各读一次。结果正文三次一致，玩家名三次仍不一致，原共识规则再次拒绝。因为原日志数据格式要求玩家名非空，也不能把“只有正文、没有玩家”的读数塞进去。结论是：已定位断点，未修复。
要回答的问题
这一行反击是识别不出来，还是共识/格式规则把它挡掉了？能否在不放宽规则的前提下恢复它？
数据与来源
- 只有一张已保存截图（来自上述训练录像的分析结果）。没有扫描视频，没有使用留出或冻结材料。
- 原图已目视核对：第 9 行确实是“观世者(8)反击了凤凰(10)”。玩家名前缀含有无法显示的缺字方框和西里尔字母，从像素上恢复不出完整的原始 Unicode 名字。
- 日志里的时钟 01:48:45 是游戏显示的时间，不是录像的媒体时间；这张截图在分析记录中没有匹配到媒体秒数，保持未知，没有从文件名猜。
方法
- 原自动行框 [659,448,1274,480] 加固定边距，得到 [647,444,1286,484]，只在内存中裁切。
- 用现有的 PP-OCRv6（CPU，限 8 核）对这一行分别以原尺度、1.5 倍、2 倍各读一次，保存完整输出、坐标和分数。
- 把三次结果交给原有共识算法——只作诊断，不替换旧结果或生产结果。三次局部读取用的是同一个模型，不是独立投票。
设置
不新增生产代码；另用一个脚本以 App 的严格数据消费者验证格式约束。
结果
| 尺度 | 读到的完整行 | 分数 | 耗时 |
|---|---|---|---|
| 1 | [01:48:45]: 观世者(8)反击了凤凰(10)。 |
0.94188 | 0.496 秒 |
| 1.5 | [01:48:45]kaca: 观世者(8)反击了凤凰(10)。 |
0.91102 | 0.574 秒 |
| 2 | [01:48:45]aa oc: 观世者(8)反击了凤凰(10)。 |
0.91771 | 0.695 秒 |
正文、时钟和括号数三次一致，玩家名三次不同。原共识再次返回“文字为空、结构为空、读取冲突”。合计 1.765 秒，不含模型初始化，也不是整帧或 App 的时延；分数不是准确率。
失败与负结果
逐层定位的断点：
- 识别：中文反击正文可以通过局部补读恢复；玩家名文字仍不可靠。
- 共识：旧三读既有正文分歧又有玩家分歧，新三读只有玩家分歧。两次拒绝都符合既有规则，这不是一个可以直接修的传输错误，也不能用“两票”代替“三票”。
- 数据格式：现有日志格式要求完整记录有非空的玩家名，并固定了三种 OCR 读法。不能塞入空玩家、伪造名字，或把新的单行读数标成原来的整图/面板读法。
- SE 消费：没有合法的完整记录，SE 不会把它当作事件。而且即使将来恢复这一动作，相邻行是“甲壳消失”而不是伤害，也不会因此自动恢复一条攻击—伤害配对。
验证脚本用 App 严格消费者接受了原截图结果，并在隔离副本上确认空玩家会被拒绝；旧结果和未知行没有改变。另外，单行裁图的做法在 10 月 2 日一次早期尝试中曾有漏括号的失败记录；本轮只是针对这一失败的固定边距诊断，没有重新推广那条路线。
局限
- 只有一行、一张已曝光截图，不能推断日志读取的整体水平。
- 一个允许“部分日志观察”（保留正文、玩家名未知）的兼容方案只写成了提案，未批准、未实施。
结论与下一步
本轮以“已定位、未修复”结束：正文可以恢复，但玩家名无法可靠读出，现有规则和格式正确地拒绝了这条不完整记录。外部审阅也支持暂缓修改公共格式——一条已曝光日志、且恢复后也不能配对伤害，不足以支持跨模块升级。下一步转向核对已保存的攻击预览能否提供有界的条件约束；随后的核对发现相关对照（缺目标防御、移除组件的参考）都已实现，没有找到新的合法候选域，因此也没有为了显示进展而把旧对照改称新结论。
Comments