摘要
Simulator 是本项目自己写的《英雄无敌：上古纪元》竞技场战斗规则引擎，对战 AI 在里面训练和比赛。实验 0225 的一局在第 96 步出现了不可能的局面：第 7 回合开始时，红方最后一只召唤来的幼虫到期消失，红方已经没有活着的部队，但引擎没有宣布蓝方获胜，反而又给了蓝方一次行动。
本实验在新规则版本 Core449 中补上“回合开始的生命周期处理之后，立即检查双方是否还有部队”，同时用显式的版本选择让旧版本 Core448 的存档继续按原时序逐事件回放。修复后同一局在第 96 步、第 7 回合直接判蓝方胜；738 项软件检查通过；原 0225 的历史记录全部严格重演一致。
要回答的问题
- 回合开始时召唤物到期、死亡、复活、延迟效果都处理完之后，能否在发出下一次行动之前正确结算胜负？
- 修规则会不会破坏已经保存的旧对局？旧存档必须仍能逐事件、逐终态完全相等地回放。
修复不能放在 AI 层自己判断胜负，也不能复制第二套规则；用户规定的“20 回合未决双方都输”“一方全灭而另一方只剩临时生物也双输”必须保持。
方法
- 复用 Simulator 已有的“军队是否还存在 / 是否终局”逻辑，只在回合开始边界多调用一次。
- 新加载器默认 Core449；Core448 存档通过显式版本入口保留旧时序。未知或缺失版本的存档继续拒绝，不做猜测。
- 用 0225 的同一公开构筑和同一策略重跑一次诊断，确认分叉只发生在第 96 步。
- 回放导入后在浏览器里检查终局切换、单步、拖动、8 倍速播放和双方英雄详情。
设置
- 预算：一次 150 分钟上限（入口与版本方案 30、修复 60、规则与旧回放 45、端到端 15 分钟）。
- 冻结的验收：覆盖最后召唤 / 镜像到期、双方同时到期、只剩临时单位双输、永久单位幸存、凤凰之心待复活、同一边界到期与复活、20 回合上限优先、终局动作集合为空且结算幂等。任一历史严格重演失败即停止。
- 历史样本：0225 的 19 份记录 1467 次状态转移，加上旧训练记录里各一份 100 回合上限和 20 回合上限的代表局。
结果
| 检查 | 结果 |
|---|---|
| 原故障第 96 步 | 修前复现（红方活体 0、无胜者、蓝方仍行动）；修后第 7 回合立即蓝胜，此前 95 次转移的动作与事件语义一致，终局后无新增行动 |
| 软件检查 | 共 738 项不同检查通过：基础/回放 72 项（173.15 秒）、旧存档消费者 419 项（28.28 秒）、生命周期/AI 169 项（35.63 秒）、存档工具 78 项（6.24 秒） |
| 0225 历史记录 | 8 个开局、19 份记录 1467 次转移全部严格重演一致；13 局终局、6 局未知、45 局未开始保持原样；19 份原始回放导入 1486 帧通过 |
| 旧代表局 | 100 回合上限局 147 步、第 14 回合蓝胜；20 回合上限局 142 步、第 13 回合红胜；均严格回放通过。历史审计用时 50.447946 秒 |
| 浏览器回放 | 桌面与 390 像素宽手机视图共 5 组检查通过，页面错误 0 |
失败与负结果
- 三次测试准备错误：一次从错误模块导入战斗阶段类型；一次测试误以为凤凰复活会沿用同一单位 ID（11 通过 / 2 失败）；一次导入回放模块路径错误。均修正测试，不涉及规则。
- 新旧语义对照脚本两次中途停止：先漏掉一个“动作后状态哈希”字段，后又在第 30 步漏掉三个“计划 / 回执哈希”字段。这些是随规则版本变化的派生校验字段，不是业务差异。补上这四个精确字段名后，从已写好的 30 步前缀严格恢复、追加第 31–96 步完成（8.365540 秒）。这是审计脚本的缺陷，如实记录，不说成一次成功。
局限
- 这次重跑只是诊断，不是给 0225 补赛；0225 的 6 局未知永远不替换成胜负，也不进入学习计分。
- 0225 其余 44 个来源的初始状态没有构造。
- 只修了这一处结算边界，不是重构整个调度器。
结论与下一步
Core449 修复了回合开始时的结算缺口，旧版本存档的严格回放保持不变，0344 关闭。后续在新规则下按 0225 的原协议和 52 个蓝图另立实验 0226 完整重跑，旧的 13 局胜负不混入（见实验 0226）。
Comments