摘要

九头蛇的“生齿不息”能力会在受伤后提高攻击。Simulator 原先在整次行动结束后，按净损血统一结算一次增攻，导致反击使用的攻击力时机不对。本批做的是基础重构：把受伤增攻、特技抑制、攻击刷新等逻辑集中到一个共享函数中，它只接收“已经扣过血的单位”和“本次实际损血量”，返回新的单位与结算结果。同时让“文字场景”测试工具（用中文句子描述战斗和断言的测试格式）可以选择最新的规则版本。本批行为不变，逐伤害包迁移和九头蛇反击时序修复留给后续（后续已由 Core386 接入）。

要回答的问题

能否先建立一个不重复扣血、不重复增攻的共享结算原语，在不改变历史语义的前提下，为后续“每个伤害包结算一次”铺路？

方法

  • 共享函数不把尝试伤害当真实受伤、不扣第二遍生命、不消耗反击次数、不隐式发事件。旧调度器仍在原时点把净损血送进同一函数，因此 Core380–385 的语义、事件结构全部保留。
  • 59 项机制检查：三种九头蛇、双方阵营、轻伤 / 整只减员 / 只剩 1 生命；零损血、致死、镜像复制的特技抑制；攻击跨过敌方 -10% 取整边界的立即刷新；以及“先扣血、增攻、回血，再扣下一包”的组合。用共享查询读取新攻击，字面预期 84 / 88、63 / 66、21 / 22，没有在反击公式里特判九头蛇。
  • 文字场景支持 Core380–385，未知、未来版本和“latest”一律拒绝；新增“攻击”“有效攻击”“召唤数量”断言，有效攻击按精确小数比较，不加容差。
  • 用语法树清点 30 处扣血调用，作为后续迁移工作清单（不代表 30 处都是真实伤害事件）。

结果

  • 修改前保存的 60 份 Core380–385 完整历史（912 次操作）在重构后重新生成的事件 JSON 与原件一致，原件也逐份精确回放。
  • 文字场景：龙息在 Core383 保持单格、384 / 385 后格实际扣 20 生命；原始残骸召唤数量一级 20→16、四级 28→20；同一段奈拉之吻文字在 383–385 通过、382 仍报告旧缺陷。正式文字批 37 个正常场景通过、10 个已知缺陷场景如实失败。
  • 最终专项 238 通过；Simulator 全量 12513 通过、65 个既有失败、2 跳过、152 严格预期失败（253.20 秒），补充 4 项后按节点 12517 通过。新增 91 个节点，旧节点遗漏 0、结果变化 0、新坏节点 0。

失败与负结果

九头蛇反击增攻的 6 个场景仍按独立预期失败——诊断工具通过只说明它如实报告了缺陷，不代表九头蛇已正确。验证中出现过三个测试编写问题（伤害查询漏了参数、浮点与整数类型不符、镜像法术 ID 笔误），都只改了测试调用或语法，没有修改独立预期，初轮失败日志保留。

局限

公共合同不变；本批不是逐包迁移，也不是 Simulator 完全正确的结论。致死不触发增攻沿用项目约定，不是商业客户端认证。没有重跑其它模块全量。

结论与下一步

共享结算原语和版本可选的文字场景已就绪。下一步按调用链逐条确认普通 / 先制 / 第二击 / 范围包、附加伤害、法术等入口的接入顺序，新逐包分支与旧净损血分支必须互斥，避免同一次损血增攻两次。