一队 100 只的兵先攻击，遭反击后只剩 60 只，再进行第二击。第二击应由 60 只兵打出。如果程序直接把第一击伤害乘二，即使动画和按钮都正常，战斗结果也已经错了。
Simulator 的输入是一份战斗状态、一个动作及受控的随机输入，输出是更新后的状态和发生过的事件。核心设计是：按真实顺序处理每个效果，在下一步之前更新受影响的状态。 回放则用保存的动作和版本重新执行，检查同一场模拟能否得到同样结果。
flowchart TD
A["State, action<br/>and random input"] --> B["Validate the action"]
B --> C["Resolve movement<br/>and interruptions"]
C --> D["Resolve next packet"]
D --> E["Update health, counts<br/>and reactions"]
E --> F{"More legal<br/>packets?"}
F -->|"Yes"| D
F -->|"No"| G["Finish activation"]
G --> H["New state<br/>and replay record"]图 1：后续伤害包读取前一个包结算后的状态。这里的循环概括顺序处理；某个具体动作是否有反击、追加击，取决于规则和当时状态。
1. 为什么先更新兵力，再算下一击？
已有一个开发场景给出了直接反例：100 只弑神者普攻第一击造成 7093 伤害，随后受到 1840 反击伤害，数量从 100 降到 60，第二击伤害为 3990。它展示的是这次受控执行的顺序与结果，不是所有兵力和随机结果下都适用的固定伤害表。
一个“伤害包”就是一次需要独立处理伤害及其后果的结算步骤。第一击、反击、第二击是三个包。每个包可能改变存活数量、反击次数和状态；下一个包必须读取更新后的值。如果反击杀死攻击者，第二击就不存在。如果第一击已经消灭目标，后续针对该目标的攻击也不能继续计算。
对普通整数组兵，若每只生命为 h，剩余总生命为 H > 0，存活数量为 ceil(H / h)；最后一只可以残血。引擎内部还要保留正确精度与额外生命来源，不能把界面四舍五入后的数字写回真实状态。
2. 一次攻击的顺序由什么决定？
动作先通过合法性检查，包括行动者、目标、资源和位置。需要移动的攻击再处理路径：途中若被已知效果截停，原来计划在终点发生的攻击不能照常兑现。
接下来依实际规则安排先制反击、主击、目标反击、协助反击和追加击。并非所有动作都包含这些步骤。例如疾速猛攻有自己的能力绑定与标签；普通攻击的“狂暴追加击”不能自动套给它。另一方面，不适用于本次技能的加成也不能通过删除整个状态来实现。
顺序还影响死亡后的反应。判断依据是具体触发规则，不是简单地在“目标死亡”时跳出所有处理。开发测试需要覆盖目标死亡但其他来源仍可能反应，以及更早的反击杀死攻击者后后续动作取消这两种不同情况。
这就是集中维护执行规则的原因。界面可以展示伤害，AI 可以查询预计结果，但它们不各写一份攻击顺序。相同规则由 Simulator 负责执行和公开查询，二者再通过离线对照检查实现是否一致。
血量算对了，下一次技能仍可能算错
兵种攻击和受伤会产生全军共享的集能，每6点组成一充能，部分能力消耗这些充能。因此，一次交换还会改变下一支兵能用什么技能。以攻击集能为2、受伤集能为1的近战兵为例：主动攻击一次给己方2点；如果受到目标反击和另一队的协助反击，两个正伤害包分别再给己方1点。若它具有双击且两击都造成伤害，受击方得到两次受伤收益，攻击方不会因此重复获得主动攻击收益。
日记核对发现，旧实现扣除了第二击和协助反击的血量，却漏掉对应集能；先制反击击杀攻击者后，取消主击还会连带漏算已发生的受伤收益。当前实现已补齐这些分支，并检查屏障挡伤、集能上限和禁止集能的状态。资源在一次攻击结算后统一入账，下一行动读取更新后的共享池。这沿用项目已经采用的正伤害包规则；安装配置和回放一致性尚不能证明商业客户端每个内部回调的精确时点。
横扫漏掉友军，也会漏掉下一次技能
凤凰的横扫可以同时打到主目标和两个侧面格，侧面有友军也会受伤。游戏的三种凤凰都把普通攻击和反击绑定到这个模板。一次主动攻击的集能按动作获得，受伤集能则来自各个正伤害包；两者计数不同。
| 玩家确认的命中情景 | 己方获得的集能 |
|---|---|
| 一次攻击命中两个敌人 | 主动攻击共2点 |
| 一次攻击命中一个敌人和一个友军 | 攻击2点，加友军受伤1点，共3点 |
日记驱动的检查发现，Simulator曾经只伤主目标。修复需要让每个目标的屏障、受伤反应和集能都参与结算，反击和追加攻击再读取更新后的状态。当前已将审核后的模板接入单位和可攻击物件共同参与的横扫。
继续追踪实际扣血路径后，确认同一次横扫共用幸运倍率，每个目标分别抽基础伤害；抽样偏向伤害区间中部，乘幸运倍率后向上取整。当时Simulator使用的均匀抽样和取整方式存在差异，直接给侧面格复制旧伤害还不能完成修复。六个攻击方向的格子投影已经与原生整数函数逐项对齐。
私有数值阶段也已实现：先接收整组兵对当前目标的伤害上下限，乘模板倍率并截断，再抽基础伤害，最后乘整次攻击共用的幸运倍率并向上取整。例如，上下限为1000与2000、幸运倍率为1时，居中的抽样得到1500。伤害上下限由上游计算，抽样函数只负责这段数值过程。
| 基础抽样发生的情况 | 消耗的均匀随机数 |
|---|---|
| 第一次尝试就在有效区间内 | 2个 |
| 连续10次越界，随后回退一次均匀抽样 | 21个 |
| 上下限相同，第一次尝试有效 | 仍为2个 |
固定伤害也消耗随机数，会影响后续目标的结果，因此确定性验证还要比较随机流的位置。按已审核原生指令构造的对照中，4096组输入的伤害和随机消耗与私有实现一致。
凤凰普攻和反击已经使用这套抽样，追加击、监视攻击也经过同一条数值路径。每次攻击先选幸运，再为各个目标计算当前的整组上下限并抽基础伤害。强制最大或最小伤害仍抽样；伤害预览使用同一份上下限。例如单兵伤害3、数量7、全出伤加成10%，先把23.1截断成23；再乘1.5的标签倍率，34.5按中点取偶舍入成34。省掉这两个边界就可能算出不同结果。
旧概率接口只能表示单兵均匀分布，现在明确拒绝凤凰这类查询。Web和终端继续展示伤害区间，不再附上错误的均匀概率表。属性投影、被动因素和本地随机流仍有明确的适配范围；完整原生回调与死亡复生行为还需要继续核对。
单位横扫按模板顺序逐个结算。主目标可能排在中间，因此程序先锁定目标名单，抽一次全体共用的幸运，再处理第一位受击者的扣血和受伤反应，之后才处理第二位。如果前一个目标的反伤让施法者减员，后一个目标必须使用剩余数量重新计算伤害。
flowchart TD
A["Lock ordered recipients"] --> B["Draw shared cast Luck"]
B --> C["Sample damage for next live recipient"]
C --> D["Apply unit damage or object HP cap"]
D --> E["Settle recipient reactions"]
E --> F{"More live recipients?"}
F -->|"Yes"| C
F -->|"No"| G["Counter or additional cast"]图2：每个受击者的状态变化完成后，才开始下一个目标。
横扫中的每个正伤害包都让受击者获得受伤集能，友军也一样；屏障完全挡下的包不会获得。主动攻击集能仍只获得一次。侧目标被击败时，杀手来自实际致死包；反射击杀也由反射者负责。界面原有的主伤害数字继续表示主目标，完整波次另行记录，避免把三位目标的总损血混进一个数字。
看似一击就碎的物件，也会消耗随机数
横扫的目标还可以是可攻击水晶、岩石、凤凰复生留下的物件或召唤用的卵。当前审核的六种物件每个伤害包最多扣1点耐久，但这不表示它们跳过伤害计算。游戏先用物件自己的属性算伤害区间，独立抽伤害并应用本次幸运，再限制最终扣掉的耐久。
例如，按模板顺序有两个单位，中间夹着一个只剩1点耐久的物件。程序仍然抽三次基础伤害；中间的抽样即使得到50，物件也只掉1点耐久。若直接扣耐久而省掉这次抽样，第三个目标会读到不同位置的随机数，后续战斗就可能偏离。这与固定伤害仍抽样是同一个问题。
| 目标 | 单包结算 | 资源变化 |
|---|---|---|
| 单位 | 扣实际生命，处理屏障和受伤反应 | 正伤害包产生受伤集能 |
| 可攻击物件 | 独立抽伤害，再按上限扣耐久 | 不产生单位受伤或击杀收益 |
现在选择物件为主目标时，也会执行完整横扫；旁边的敌我单位照常受伤并结算资源。追加攻击重新检查当时的目标：1点耐久物件已消失，2点或3点耐久物件可能继续受击。物件的原始耐久与运行中的剩余耐久分开保存，带英雄生命加成的来源也不能直接当成固定1点耐久。
配置和独立原生指令检查支持这段抽样、扣血上限及物件事件路径；合法行动与JSON回放检查实现中的混合目标顺序和资源变化。它们还不能证明商业客户端全部事件订阅者、死亡复生调度或随机流都已复现。
前一目标死亡，后一目标的防御也可能变化
“人人为我”按当前范围内的己方兵团数增加防御，计入受击兵团自身。若范围内原有3组，每组提供2点防御，加成就是6。横扫先杀死其中一组后，下一目标只应保留4点加成。
旧执行路径已经扣除了第一目标的生命，却没有及时刷新第二目标的动态属性。在一个实际合法行动的开发构造局面里，第二包因此仍读到防御6、造成769伤害。现在每个目标的伤害与反应处理完毕后，都会刷新已有动态加成；第二包读到防御4，伤害变为833。没有死亡的对照仍是防御6、伤害769，两种局面都完成了终局JSON回放。
当前游戏配置和独立原生检查分别支持这项加成条件与死亡后同步刷新的调用链。上面的伤害数值来自开发局面；它检验了实现中的前后包衔接，尚不代表商业客户端同局实测或全部死亡回调已经复现。
公开查询还需要区分可计算和不可计算的属性变化。己方公开状态写明了“人人为我”的倍率，就能随兵团死亡刷新；只看见敌方防御加成6，却不知道它来自哪里，便不能推断死亡后一定变成4。这类隐藏来源和未支持的死亡连锁仍返回“未知”，损血合计留空。
公开数据也要分别计算敌军、友军和物件
Simulator现在提供可选的公开范围序列查询。它按同一攻击模板锁定受击对象，再为每个对象计算条件伤害，分别记录敌军生命、友军生命和物件耐久。新的AI私有候选对不同兵团分别估值；物件的耐久不能混进单位损血。
在每包固定50伤害的开发局面里，横扫命中一个敌军、一支友军和一块1点耐久物件，输出是敌军损血50、友军损血50、物件耐久减少1。三项分开，才能看出这次攻击也伤了友军。普通与反击模板、六个方向、两种行奇偶及物件主目标都有实际波次对照。
查询沿路线依次处理已观察到的监视攻击和可见场地伤害，再处理先制反击、主击、普通或协助反击及追加攻击。每次损失都会更新剩余兵数；下一次攻击重新读取，追加波次也重新枚举存活对象。已知屏障、临时生命和未投影死亡连锁仍使完整合计保持未知，已计算的前缀只用于诊断。
固定输入的完整行动对照检查了这些顺序与逐组损失。对伤害区间取中点只是一个条件输入，并不是整个随机行动的平均收益；实际随机抽样和连锁仍可能改变选择。新候选尚未完成独立整局评测，默认AI和界面也尚未使用这份新版范围报告。
幸运的概率加成也要按点数算
横扫共用一次幸运判定，首先就得把这次判定的概率算对。当前游戏代码把正幸运的概率修正值乘以幸运点数。例如“骑士荣耀”五件套的配置值为0.03，表示每点正幸运再增加3个百分点。幸运为3时，基础24%加上额外9%，得到33%；旧实现把额外部分固定成3%，只算到了27%。
| 幸运点数 | 旧实现的触发概率 | 修正后的触发概率 |
|---|---|---|
| 0 | 3% | 0% |
| 1 | 11% | 11% |
| 3 | 27% | 33% |
零幸运在游戏代码中直接返回普通倍率，不抽幸运；负幸运使用自己的概率修正字段，不能受到正侧套装加成影响。当前Simulator已经同步修正执行、能力快照、公开攻击序列和AI的幸运免反击估值。快照保存的是乘过点数的概率加量，读取时不再乘一次；不允许手工给零或负幸运塞进正侧概率。
这次核对覆盖当前安装的概率参数、零幸运分支和原生调用，实际动作与JSON回放用于检查修正后的实现。凤凰以外的普通攻击仍保留原有整数阈值和随机流，单位横扫已经接通，商业随机流与完整原生状态构造仍需继续迁移。
法术幸运，要分清每次伤害和整次施法
凤凰横扫共用一次幸运，不能据此让所有范围法术都共用一次。玩家在10月1日 直接确认了三个法术的区别，Simulator已据此修正：
| 法术 | 幸运判定范围 |
|---|---|
| 天罚 | 对每支受击兵团分别判定 |
| 连锁闪电 | 首击与每个续跳分别判定 |
| 黑洞 | 整次施法判定一次，所有受击者共用倍率 |
用一个简化例子说明：三支目标原本各受100伤害，逐目标判定可以得到 200、100、200；共享一次判定则三支一起普通或一起幸运。这里省略减伤、 衰减和生命上限，用来展示判定范围，并非一场实战记录。
每包的幸运结果也要分别保留。否则回放无法重现混合结果，AI还会把第一包 的倍率错误地套给后面目标。单目标的伤害期望仍可逐项相加，但整次施法的 结果组合与波动已经不同；公开预览显示单次伤害的幸运概率，不能把它写成 整次法术只有“全普通／全幸运”两个分支。其他法术与延迟陷阱仍需逐项确认。
游戏更新后，触发条件也要重新检查
反击次数要在反击开始时更新
当前安装的普通和先制反击命令先检查双方存活及能力可用，再扣有限反击次数，随后开始伤害结算。伤害被屏障完全挡住也已经使用了这次反击。Simulator原来在伤害后扣次，当前已调整这两个入口；协助反击使用另一类命令，它的扣次时点还需继续追踪。
这次检查也找到一个实际执行错误：Simulator用−1表示无限反击，但“觉醒：地属性”只改变有效容量和当前次数，基础次数字段仍是1。旧程序检查基础字段，因此第一次反击后把−1扣成了−2。修复后检查当前次数并保留负值；真实觉醒行动、同回合连续两次受击和JSON回放都保持−1，公开观察也能继续表示正确的无限次数。
游戏配置中该Buff实际写的是反击次数加量999，不是−1；后者是Simulator已有的状态表示。这些测试检查当前实现和回放，不能认证商业客户端在超过这个实际预算后的行为。监视则有自己的次数，不从普通反击次数扣除。
凶残喜悦只奖励当前行动者的击杀
0.81.02 的凶残喜悦增加了“击杀者正在行动”这一条件。旧 Simulator 会把提前发生的反击击杀记成本轮已经触发，并保留一次额外行动。新版配置和公告要求重新处理这条路径：行动外反击击杀不奖励额外行动，也不消耗随后主动击杀的机会。
| 同一回合发生的事 | 当前实现 |
|---|---|
| 尚未轮到自己，反击消灭一队敌军 | 不触发凶残喜悦，保留本轮机会 |
| 轮到自己，主动消灭另一队敌军 | 获得一次额外行动 |
| 额外行动又消灭一队敌军 | 本轮次数已用完，不再次奖励 |
这次迁移保留独立的击杀集能规则，更新了界面说明和规则版本。测试从真实合法动作依次执行前两次击杀，再保存和重放完整事件；另外检查旧规则存档会被拒绝且内容不被修改。这样的回归能验证实现遵守新条件；其规则依据仍来自安装配置和官方更新公告。禁疗和凤凰等新版修复还需要各自完成审核。
一起移动的单位，要先全部落地再引爆陷阱
黑洞可以把多队兵拉近，时间领域则会伤害踩中它的单位及邻格单位。如果程序每拉动一队就立即引爆，它看到的其他单位还在旧位置，可能漏算本应发生的邻格伤害。
本次安装代码把整批移动排在陷阱命令之前。Simulator据此改为：先完成这一批推拉，再依次处理落点陷阱。一个回归场景中，原有1000生命的第二队先受黑洞140伤害，移动后进入另一处时间领域的邻格，再受100伤害，最后剩760生命。如果最初只有200生命，它同样先完成移动，然后被爆炸消灭；它落点上的另一个圈套不会再被尸体消耗。
这还要求区分移动方式。普通步行停在空间圈套格上，与被黑洞拉到该格，是不同的触发入口；单位平时会飞，也不能据此跳过推拉落点检查。当前实现已把这几类情况分开，保留各陷阱的免疫判断，并用合法动作、隐藏信息检查和保存回放验证。其他位移机制仍需分别核对。
先分清入格和离格，才能比较监视与陷阱
监视让等待中的兵在敌人离开相邻格时攻击它。敌人尚在起点时，起点监视先发生；敌人随后走进中途格，才检查那一格的陷阱。如果继续移动，中途格的离格监视又是下一步。这几个时点不能合成一个笼统的“移动时触发”。
flowchart TD
A["Overwatch at origin"] --> B["Enter middle cell"]
B --> C["Resolve trap"]
C --> D{"Can continue?"}
D -->|"Yes"| E["Overwatch at departure"]
E --> F["Enter next cell"]
D -->|"No"| G["Cancel remaining route<br/>and planned attack"]图 3：普通步行先到达中途格并处理陷阱，随后才可能离开该格。移动者若在起点已经被杀死，就不会进入图中的后续步骤。
例如一队兵有250生命，起点监视造成10伤害，进入下一格的火墙再造成80伤害；该格的监视攻击开始时，它已经只剩160生命。如果起初只有85生命，它会在火墙上死亡，后面的监视和计划攻击都被取消。若踩中空间圈套，则在那一格停下，后续离格监视同样没有机会发生。
本次安装的路径与命令队列支持这个普通步行顺序，Simulator的实际行动与保存回放也符合这些例子。时间领域还能伤及邻格监视者；新的可选公开查询会先扣除已知旁伤，再用剩余兵数计算后续攻击。缺少公开伤害依据或涉及未支持的死亡连锁时，完整合计仍未知。取消的预排监视是否退回次数、死亡复生以及其他移动方式，仍需另外核对。
没有打出的监视，也可能已经预扣次数
游戏先把路线转换成待执行命令，排入监视命令时就扣一次次数。之后移动者可能先被陷阱杀死，原本排好的监视便打不出来。Simulator目前是在实际监视结算时扣次数。要判断两者是否留下不同结果，还必须查清取消后有没有退还。
当前安装代码已经核清：普通新回合开始会用当前上限补满监视次数；一般属性刷新则只把现值限制在合法范围内。后者不会自动补回已经用掉的次数。匹配的状态变化还有单独的次数增减路径，也要按其触发条件判断。
取消命令本身没有直接退还次数，仍不足以给出结论，因为整段命令完成后还会派发事件，让其他处理继续运行。新回合补满和命令完成使用不同的事件，但完成事件的间接处理尚未核清。因此，这轮增加了安装代码的漂移检查，保留取消策略为未知，继续追踪后续处理；Simulator的消费时点暂时保持。这也说明，一条生命周期规则需要查到最终状态，不能只看中途的一次扣减。
同样叫陷阱，增伤也可能走不同的分支
0.81.02 的秘术修复需要再细分。安装代码给火墙的基础伤害乘秘术倍率，时间领域的血量比例伤害则在另一条分支计算。假如把全部陷阱的最终伤害都乘1.4，修好了火墙，却会错误地增强时间领域。
火墙还同时使用两种时间点：法强在放置时保存，秘术从所属英雄当前属性读取。例如放置时法强为1，基础伤害为80 + 10 × 1 = 90；踩中时英雄的秘术为40%，这一包基础伤害是126。之后英雄法强变成9，也不能把已放置的火墙重新算成238。
| 伤害计算的步骤 | 火墙例子 | 时间领域例子 |
|---|---|---|
| 本例基础项 | 80 | 单兵最大生命100，法强0 |
| 秘术40%后的伤害包 | 112 | 100 |
| 魔法减免35%、全伤害增加20%，依次相乘 | 112 × 0.65 × 1.20 | 100 × 0.65 × 1.20 |
| 按安装代码的数值顺序取整 | 87 | 78 |
两层入伤修饰要相乘。把−35% + 20%合成一个−15%，会得到另一套结果。取整也属于规则：当前陷阱路径使用单精度运算，恰好处于两个整数之间时取偶数。例如110 × 0.75 = 82.5变成82，119 × 0.5 = 59.5变成60。不能凭经验把所有伤害都统一为“半进一”。
Simulator 已据此修正火墙和两种场地伤害的入伤步骤。AI 的公开预估共用这些数值运算，但只有己方可见信息能提供秘术；敌方火墙可见，也不代表其所属英雄的加成已知。这些例子来自当前安装代码的算式审核和执行回归；完整百分比浮点边界、其他出伤来源以及同条件商业客户端对照仍需继续验收。
3. 状态消失、死亡和复活为什么要单独设计？
“持续两回合”还不足以说明一个效果：它什么时候开始计时，死亡后是否暂停，复活后是否继续，提供者死亡时是否消失，都可能改变结果。把这些情况压成一个整数倒计时，会让表面相似的效果错误地共享生命周期。
空间圈套已有玩家确认的具体边界：第N回合触发，持续到第N+1回合结束，第N+2回合开始失效。配置中的duration=2在这里包含触发当回合。回归分别从第1和第3回合实际踩中圈套，检查中间回合与到期后的状态；这个定义不直接外推到其他效果。
隐藏状态的几个属性要分开处理
当前安装里，phoenix_upg 开战时会给自己一个隐藏状态。它只禁用主动能力，带 neverDisable 的觉醒仍可使用；普攻、反击和集能也保留。第一次真正反击时，程序在幸运抽样和伤害之前执行自身驱散。若只检查受击后的状态，就可能把清除误放到反击结束。
| 看起来相近的属性 | 这条状态的实际区别 |
|---|---|
| 正面状态与触发标签 | 状态标为正面，但标签只有 wisp_silence，不补一个正面 Buff 获得触发 |
| 可驱散与可复制 | 它可被驱散，同时配置明确禁止复制 |
| 开战与复生 | 开战只加一次；后来新生成的复生单位不重新执行开战被动 |
| 两种驱散保护 | 自身机制检查 dispel 机制免疫，通用的正负状态驱散保护是另一条路径 |
Simulator 已连接这些区别，并用实际觉醒、普通反击、先制反击、监视和复生检查生命周期，保存事件后再逐项回放。核对时还发现：内层删除函数没有免疫检查，外层调用者却会先检查机制免疫。这要求沿调用链核对执行条件，不能只读删除函数就得出“无条件清除”。完整状态事件订阅者仍需继续审核。
因此需要区分效果来源和作用阶段。低语力量的开局来源与提供者存活时的光环就是不同问题；尸体上的治疗阻断也不能未经依据就随着普通回合计时消失。当前项目已有相关规则与可选状态版本，但每条路径仍应按自己的来源和测试核销。
日记也会带来需要保留的客户端 Bug。玩家确认的“奈拉之吻消失→下一敌方行动跳过”应作为一个具体问题跟踪。0.81.02 公告的能量凤凰跳过行动修复，不能证明这条奈拉连锁也已修好。检查时绑定同一次状态移除、接下来的行动者及跳过事件；找到原因后才决定如何模拟该版本行为。它不能变成“任意负面效果结束都跳过下一行动”的全局规则。
4. 确定性与回放分别保证什么？
额外行动选择等待时，士气检查要等到什么时候？
完整对局曾暴露一个队列错误：一队兵击杀敌军，获得额外行动，然后选择等待。 等待把它放进稍后恢复行动的队列；旧程序却立即检查正士气。若士气触发， 它又被放进立即行动的队列，同一队兵同时占了两个位置，对局因此中断。
现在符合正士气条件的等待都推迟检查。等待时保留它的队列位置，不抽随机数， 也不提前标记本轮已检查；真正恢复行动并完成后，才按原有优先顺序判断是否 还有士气机会。同一单位每轮最多检查一次。测试从真实击杀走到等待、恢复， 分别检查触发与不触发，并保存、重放整局。
这个修正保证Simulator自己的等待与队列语义一致。商业游戏里额外行动等待后 何时判士气仍需独立核对。因为推迟抽样还会改变后续随机输入，程序使用新的 规则身份，拒绝把旧身份的存档直接按新规则继续；旧概率接口保留历史语义， 界面显式采用新的版本。
确定性表示：同样的初始输入、规则版本、动作序列和随机输入，得到同样的模拟结果。它让失败可复现，也让策略对照能固定局面，只改变策略。
保存时需要保留足够的语义信息，包括规则与状态版本、初态、已提交动作和必要随机状态。恢复时先确认版本能否读取，再重放并核对状态。旧存档不应在用户只是打开它时被静默改写成新版本；不支持的格式需要明确拒绝或显式迁移。
回放能找出执行遗漏和保存恢复问题，却不能证明游戏本身就是这样结算。若原引擎一直用了错误公式，原局和回放可以一致地错。因此商业游戏配置、玩家实测和独立客户端观察仍承担规则依据的角色。
5. 用哪些反例验收？
| 检查层 | 代表性问题 | 能说明什么 |
|---|---|---|
| 单个效果 | 狂暴是否错误加成疾速猛攻？ | 例外规则是否实现 |
| 一次完整行动 | 反击减员后第二击是否降伤，死亡后是否取消？ | 包之间是否正确传递状态 |
| 跨行动生命周期 | 状态移除、尸体、复活是否保留正确来源和时钟？ | 后续行动是否读到正确状态 |
| 保存与回放 | JSON 保存再加载后能否重现终局？ | 序列化和确定性是否可靠 |
| 商业客户端对照 | 同条件在实际游戏里发生了什么？ | 模拟规则是否符合对应游戏版本 |
当前已有针对疾速猛攻、反击、协助和幸运情景的执行对照。集能修正与圣洗礼对象限制的14项定向检查还覆盖了终局回放、旧版本拒绝和观察者资源隔离：普通可治疗兵上的奈拉之吻能被圣洗礼清除，化体则既不被驱散也不被治疗。
日记也帮助定位凤凰横扫曾经只让主目标掉血的问题。现在三种凤凰的六个方向、友军受伤、屏障、反击、追加击和监视都经过实际行动与JSON回放检查，混合目标保留物件的独立抽样和耐久上限，后续包也会读取刷新后的已有动态属性。公开范围查询已交给私有AI候选逐组比较，界面也已提供按需预估；新的64局对照修正后都能回放，但仍有基线回合截断与压力预算失败，默认策略保持。完整原生回调、妖精巨龙的首击无伤记录与奈拉之吻移除后的跳行动连锁，也仍需定位完整条件。
继续阅读：s40：AI 怎样公平比较普攻、猛攻和等待；返回 s00 总览。
Comments