摘要

在查看实验 0216 的一段中途回放时，截图里蓝方剑士总生命 66、单体生命 12，界面却显示 20 个单位——显然不可能。原因是回放展示读的是兵堆的开局/容量数量，而不是当前存活数量。修复后同一例显示 6。本轮 970 份已导入的回放展示缓存全部离线重建并逐一核对。这是展示缺陷，修好数量不代表 AI 变强。

（编号说明：初稿用过 0410，与已有的另一条记录冲突，改用未占用的 0421；旧 0410 记录保留。）

要回答的问题

回放显示的数量从哪里来？改正后，已经导入的旧回放能否在不改动原始记录的前提下显示正确数量？

方法

  • Simulator 的兵堆有两个字段：quantity 是开局/容量数量；count 才是当前数量（永久完整生物 + 临时完整生物 + 还活着的残血那一个）。回放展示层现在读 count，不在界面上用总生命自行推算。
  • 已导入回放的展示缓存用一个内部版本标记区分。同规则版本的旧缓存首次读取时，从原始记录重放生成新的帧文件并原子替换，保留 ID、创建时间和源记录；以后读取不再运行 Simulator。不同历史规则版本仍按原样读取，不擅自重新解释。
  • 不改战斗日志、训练数据、结果、回放接口字段，也不碰用户的主服务。

设置

重启本任务预览服务的命令被自动审批拒绝，没有绕过；改为离线重建本轮 970 份已导入的展示缓存，再逐份通过 HTTP 读取核对。这是生成文件的修正，不是进程热替换：现有预览进程以后导入新文件时，仍需正常加载新代码。

结果

检查 结果
970 份记录 / 31606 帧 / 126424 个单位数量 全部与原保存战斗状态里的 count 一致
修正的旧容量数量 120331 个
源记录、ID、创建时间及其它展示字段 保持不变
同一中途例 剑士 20→6（总生命 66、单体 12），弩手 9；阵亡仍显示“已阵亡”
桌面 1440×1080 / 窄屏 390×844 六组交互 通过，控制台 0 错误，截图已目视
回放检查 + Ruff 27 项通过（新增 4 项：普通、永久/临时混合、死亡数量、兼容缓存）

失败与负结果

两次界面测试脚本出错：一次点击了本来就处在开局、已禁用的按钮；一次把“已阵亡”文案当成 0 个单位。两次都只修测试期望并保留原日志，没有为了过检查而改产品。修复前的截图和导入记录作为失败证据保留。

局限

  • 修复发生在该批 GPT 结果摘要发出之后，没有经过 GPT 独立审查这段界面代码。
  • 不能宣称运行中的预览进程已部署新 Python 逻辑。

结论与下一步

回放数量现在反映真实存活数，旧缓存已全部修正。之后导入的新回放需要在正常重启后由新代码处理。