摘要

一次对战 AI 确认批次（24 个新来源；“来源”指同一开局交换双方各打一局的一对对局）在某局第 115 步之后中断：下一次构造公开合法动作菜单时，引擎报“召唤虫群状态快照已变化”。排查发现这是 Simulator 自身读状态时的一致性错误，不是规则公式问题。修复后，原 115 步重放一致，从失败点继续执行一步成功。

要回答的问题

为什么引擎会拒绝自己产生的状态？修复是否会放过真正错误的数据？

方法与原因

第 10 回合红方部队全部阵亡，但保存的状态里仍有两只已死幼虫的寿命标记。红方英雄的技能配置带有“幼虫寿命 +1”的加成。旧读取器只从活着的单位上读这个加成，没有活体就返回 0；随后的来源校验拿这个错误的 0 去反查已经生成的寿命，于是拒绝了合法状态。

修复：有活体时仍按原路径读取；没有活体时，改为核对保留下来的同侧阵亡单位上的标记。重复、缺失、不一致、阵营和取值校验全部保留；没有配置标记时仍返回 0。

结果

  • 先写小场景重现 3 项失败：最后一个活体死亡后加成丢失、阵亡单位标记缺失未被发现、标记不一致未被发现。修复后三项通过；正常情况下的合法动作、公开菜单、状态恢复都正常，篡改寿命仍会被拒绝。
  • 原对局前缀 115 步重放一致；从失败点生成菜单、由 Fair（项目里只用公开信息做决策的基线 AI）选择并执行一步成功，这一步单独保存。
  • 相关召唤、技能、公开动作、回放与 AI 检查 364 通过、2 个原有跳过；其它受影响召唤套件 400 通过，累计 764 项不同检查通过。修复后该批 69 局已完成对局的 6,751 次转移、2,140 次保存的策略选择和 136 次隐藏输入扰动检查一致。

失败与负结果

被中断的那一批不补跑完整比赛：失败输入、115 条原转移和堆栈全部保留，单步修复不写回该批胜负。

局限

这是持久化状态读取一致性的修复，没有改变幼虫时长公式、法术规则或公共格式，也不是新的商业游戏规则认证。回放通过不代表任何棋力收益。

结论与下一步

引擎在“一方全灭但召唤加成仍需生效”的边界上不再误报。AI 确认实验本身的结果与后续安排见对应的 AI 实验记录。