摘要

实验 0338 发现原始残骸召唤数量与安装配置不一致。本批扩大检查到 80 条合法历史，并把“百分比加成如何取整”也纳入：两种召唤（星之子、原始残骸）× 四个熟练度 × 咒力 0/1/4/7/17 × 有无 Legion（数量 +30%）。结果 32 例符合配置候选，48 例复现系数或舍入差异。同时在内存中试了一个修复原型，80 例全部通过。生产规则、公开接口、AI 与状态估计算法均未改；正式修正见实验 0339。

要回答的问题

差异有多大、出现在哪些组合？怎样让“已知缺陷”的测试只在缺陷本身出现时才被视为预期失败，而不掩盖其他错误？修复原型是否需要新的规则身份？

方法

  • 预期数量写成字面值，包含向上、向下以及 19.5→20、32.5→32 这样的半整数例子。
  • 每条历史先完成以下检查再比较数量：预览不改状态且重复查询相同；预览、事件和出生队伍数量一致；耗蓝 20（300→280），对方资源不变；出生位置、阵营、兵种正确，整队生命 = 数量 × 单体生命；召唤加入本轮待行动队列；每步 JSON 续算一致，最后完整回放。
  • 失败分类：原 24 个数量对照不再使用宽泛的“任何断言错误都算预期失败”，只有精确匹配已记录历史数量的专用异常才可作为严格预期失败；资源、预览、状态、回放错误或第三种意外数量都会正常失败。另有 8 个分类/故障注入测试验证这一点。
  • 隔离修复：原始残骸系数 1/1/1/2，百分比先按 binary32 运算再最近偶数舍入，预览和执行同时改变。

结果

  • 80 条当前规则历史共 1840 次操作：32 例符合候选，48 例复现差异。全部回放一致，但这 48 例不能因此算作规则正确。
  • 修复原型：80 个数量及资源、状态、快照、回放断言全部通过（1840 次操作）；48 个结果改变的候选被旧引擎回放全部拒绝，说明修复需要新的规则身份。候选录像没有被导出为合法的旧版存档。
  • Simulator 全量 11767 通过、68 失败、0 准备错误、2 跳过、74 严格预期失败；新增 88 个节点 = 40 通过 + 48 预期差异，原 68 个坏节点无增减。Game Knowledge 全量 7596 通过、31 失败、7 准备错误，新增 171 个来源测试。
  • 来源/行为/索引专项 398 通过 + 56 严格预期失败；公共边界/依赖 31 通过。

失败与负结果

当前规则下的 48 个差异是真实的规则偏差，本批只固定、未修复。完整 Integration 未重复执行，上一批的环境/夹具错误尚未解决。

局限

原型只证明“在这批输入下修复有效”，不证明完整咒力来源、其他召唤能力或商业客户端一致；固定开局加跳过收尾，不计自然 AI 对局。公开版本修正的消费者决定当时仍待确认。

结论与下一步

差异被精确刻画，修复原型可行且必须作为新版本发布；随后正式实现为 Core385（实验 0339）。