识字、找身体和找面板各自跑通以后，还需要一个程序把它们放回同一帧。这一组负责汇总来源、处理时间、失败和未知项，不偷偷补上缺失的游戏状态。
先看下方同一张截图里哪些UI仍未读到，再看工程上的流式读取、续跑与缓存。后者避免重复工作，不会自动提高前者的准确率。
1. 先看一个例子
例如晚些时候打开日志，才看到先前一次攻击：系统可以在此刻增加一条观察，但不能假装早先那一帧就知道结果。组合正确和识别正确需要分别验收。
2. 同一张图，哪些内容还没读到？
现在我们把各组放在一起检查：从两段此前未用于本轮调试的录像中，先固定六个12秒区间，再运行已有算法，共留下32张候选。没有因为某段是选秀画面或结果不好，就换一段更容易的。
下面这张雪地战场很能说明问题：左右英雄数字之外，还有部队脚下的数量、上方行动卡、底栏图标和绿色移动范围。读对英雄数字，只完成了其中一部分。
图1：程序选中的原图。右侧部队互相遮挡；这些难处不能通过只检查容易读的英雄数字避开。点击图片可以放大。
我们先给四张战斗首帧录入可见字段，结果如下。参考由助手对照原图填写，仍待CTO审阅；其他图也全部可看，但没有逐项参考的部分不算正确。
| 同一批画面里的任务 | 实际结果 |
|---|---|
| 英雄数字和四角计时 | 48项全部相符 |
| 一本法术书的名称与角标 | 12个名称相符；36个角标中35个相符，1个因冲突拒识 |
| 部队脚下的数量 | 41个可读参考只输出16个；另2处遮挡保留未知 |
| 上方行动卡的数量 | 初次检查49个未结构化；随后接入同帧关联，47个相符、2个未知，见P80说明 |
| 玩家头像和底栏技能 | 32张中都还没有接入这两个模块 |
脚下数量的主要问题出在找框：旧方法依赖绿色血条，很多牌根本没进入读字步骤，还把书页下缘的四处装饰认成了牌。因此下一步不能只换文字模型，要先补定位和接线。全部32张图、逐字段结果和检测框已经放在同一标注网站。
上表是第一次整帧检查。后续换用已有找牌模型，同批四帧数量变为34/41相符、7拒识；其中一项来自修正参考框，不算算法提升，另一帧还发现21→211错读。新结果在P80逐项说明，原时间线尚未替换旧数量层。再往后的30图OCR比较在P912，数据分母不同，不能叠加成32帧全对。
六段共72秒源画面，包含模型启动的总处理时间为678.30秒；不是实时速度，也不是常驻模型延迟。没有生成代理视频，只保存选中图和结果，但产物仍有303.17MiB：法术书补读的多个阶段重复保存了完整JSON。后续需要减少这种重复，同时保留来源核对和续跑能力。
目前还不能报整帧准确率。 身体身份、全部图标、障碍、高亮和对象关系还没有完整参考；两段录像也没有达到原定的跨三录像验收范围。这次的收获，是明确了应该先补哪些缺口。
3. 已完成的工程整理
这次用统一环境直接处理了原录像里的 10 秒：100 个采样点留下两张原尺寸关键帧，文字、行动条、身体和数量牌的程序都运行了。没有生成采样视频，也没有把全部 100 张图存到磁盘。现在再次执行时，程序会核对输入，直接复用已完成结果；实测四个结果文件都没有被重写，文字识别记录也没有重复增加。
这里有个容易忽略的问题：原来的文字识别虽然没有重算，却每次都重写网站展示文件，导致后续程序误以为输入变了。现在内容不变就不写；图片、文字、模型或规则变了，则重新检查。失败会重试，但“没有认出来”仍如实保留，不会变成确定答案。
法术书的可选补读也接进来了：另一个 12 秒片段选出 7 张图，整屏读字后只对一张书页的 6 处小字补读。再次执行同一任务，46 个原图、记录和结果文件均未重写，识别记录没有重复追加；不过模型仍会启动并检查自身版本。这证明了这条路径可以复用已完成的工作，不证明画面读得完整。
这次运行的审阅页只载入这 7 张图，避免为看几张新图先扫描全部历史资料。旧的总览入口仍保留；新入口不会把算法结果算作人工标注，也不混入其他运行的参考答案。
长视频里最占空间的一步也改了：选帧按小批次计算，不再暂存整段像素和特征。10 分钟、6,000 个样本的单次检查中，Python 连同解码器的峰值内存约为 254 MiB。具体选帧变化见 p20 组报告。
局部计时也已接入同一流程：场景未知时，只尝试读取有明确位置依据的四个时钟，其他模块继续跳过。这段 6 秒视频的 4 张结果可以直接检查。再次执行时，20 份证据文件没有重写；旧 29 张的修复回归也保留了 76 份完成结果。图片、原始文字记录或规则改变后，网站会隐藏过期输出，而不是继续显示看似正常的旧数字。
还没做到的是“读到哪里，就把那里全部识别并发布”：程序仍先收集选中帧的时间等信息，再导出图片、执行识别。两张图的续跑检查也不证明内容读全了；输出仍明确记着五类模块未接入、完整标注帧数为零。
展开工程任务、各轮测量与接线明细
最后核对：2026-09-24 · 交付进度，不是完成证明
代码、历史报告与接线盘点；跨来源整帧验收未完成。统一环境的真实模型兼容检查见 p140，不计作准确率验收。
- 整帧准确率
- 未测
- 统一环境 p50 / p95 耗时
- 未测
- 独立录像 / 已审字段
- 未汇总
p50 是一半运行能达到的耗时，p95 是 95% 运行能达到的耗时。尚未在统一环境测量，不能用某个局部模型的速度替代。
p121 · 单帧组合与公共导出
已集成待验收
默认12类中5类未接入；显式开启可选分支的新两录像32帧已完成。27张运行战斗模块、5张选秀跳过；下栏技能/头像仍未接入，状态仅1图有受支持父面板。公共导出不等于全部worker结果，完成执行不等于读全。
p122 · 多帧读数与冲突
原型 / 待接入
已有趋势与冲突证据；不维护完整战斗状态。
p123 · 离线流式调度与续跑
原型 / 待接入
选帧不再保存代理视频或累积整段像素/特征；10 分钟、6,000 样本实跑。新增局部计时链的 76 份回归证据及原视频 20 份证据在续跑时不变；选中段元数据、准备中断续跑及其他可选链仍待完善。
p124 · 可用时间与不偷看未来
已集成待验收
已有回放边界和合同测试；不代表在线识别已经通过。
已有测量能说明什么
新两录像六个固定区间完整配置总耗时：678.3 seconds。 72秒源区间、32候选；各段冷启动所有显式可选阶段，不是默认性能或常驻p50/p95。输出303.17MiB；参考待CTO，整帧质量未测。
选帧 Python 与解码器合计峰值内存：254.02 MiB。 一个开发视频的 10 分钟 / 6,000 样本；只测选帧，不含 OCR；50ms 间隔采样。
下一步：行动卡数量已在完整视频及各续跑分支自动追加小文件，旧32帧仅增0.561MiB并可在时间线查看。继续补漏牌、底栏/头像和完整参考。原六段完整链678.30秒/303.17MiB，多级JSON重复仍待迁移，不能直接删父记录。
4. 接下来怎么推进
行动卡数量已通过小型附加记录连回卡片，脚下数量牌也已完成后续定位与读字对照。接下来应把这些候选放回同一批整帧上联合检查：漏检、假框、错字和错配是否真的减少，再接入底栏技能、玩家头像，并补齐其余候选帧的对象参考。书页顶部重复的魔法值不再单独投入。新的改动先在已曝光图上回归，正式验收另留新来源。
验收单位仍是一张完整图：不能把来自不同截图的最好成绩拼成“这张图已经全对”。
Comments