摘要

状态估计模块（SE，负责根据屏幕上看到的数值推测对手看不见的构筑）有一个“自动来源路由”：当敌方单位面板的幸运、士气出现异常时，它会挑出几组可能造成这种变化的宝物（装备）候选。本实验检查这 5 组候选能否真的按游戏规则装备上身。结果：5 组都能完整装备，装备顺序与输入一致、背包为空、序列化往返校验通过；另做的一个“两件宝物抢同一个槽位”的反例被整组丢弃，没有偷偷换掉或只保留一部分。这份证据只证明“装备层面合规”，不包含任何数值效果。

要回答的问题

SE 原先只用自己编造的记录做软件测试，没有真正调用过 Simulator 的装备推导。问题是：路由器自动选出的分组，交给 Simulator 公开的装备接口时，结果是否和规则一致？装不下的组合会不会被悄悄改写？

方法

  • 用一份人为编造的面板 {幸运: 0, 士气: 0} 驱动路由器。这里的 0 只用来告诉路由器“这两个字段被读到了”，不是真实观察。
  • 对路由器给出的每一组，调用一次 Simulator 的公开装备推导（derive_artifact_equipment）。三件宝物的组合是独立推导的，不是把单件结果拼起来。
  • 另外人为构造一对都占“背部”槽位的宝物，检查 SE 的物化步骤如何处理装不下的组。

设置

路由顺序 宝物组 实际占用槽位
第 1 组 Sixth Finger 戒指
第 2 组 Shadow Bone Boots + Cursed Armor 靴子、护甲
第 3 组 Omencaller 背部
第 4 组 Soulless Sash 腰带
第 5 组 Sixth Finger + 完整 Shadow 两件套 戒指、靴子、护甲

一次运行共做了 6 次实际装备推导、2 次公开物品查询、1 次目录加载；数值查询、整场前向计算、模型、界面调用均为 0。软件耗时约 0.4007664 秒，只是诊断成本，不是实时验收。

结果

  • 5 组全部完整装备，返回 5 个 ID / 5 个组，equipment_queries=5、numerical_queries=0、搜索完整性标记为 false（如实表示没有穷举所有可能构筑）。
  • 同槽位反例：公开查询确认两件都占背部，推导把第一件装上、第二件放进背包；SE 的物化器随即返回空分组，并给出“未完整装备、不找替代”的明确说明，没有交换、取子集或重试。

失败与负结果

执行中没有失败。需要强调的是：同槽位反例是人为构造的，不是路由器真实产生的方向，也不能当作“对手可能带了什么”的提示。

局限

  • 不包含数值效果（幸运、士气具体加减多少），也没有确认真实来源、真实拥有者或界面执行。
  • 宝物规则仍基于旧安装版本的快照；另有当前版本配置的对照审计，但物品定义与游戏原生执行不在其范围内。
  • 保存的请求通过了既有编码器的格式检查，但从未被真正提交，不授权任何数值比较。

结论与下一步

自动路由与 Simulator 装备规则之间的“装备合规”缺口已补上，相关 5 组的装备结果可作为内部测试夹具使用。数值部分随后在实验 0301 中补齐；面向产品的公开自动规划器仍是提案状态，还需要 SE、Battle Notes 和独立验收各自完成接入。