摘要

实验 0077 证明“重演公开历史”走不通。本实验换一条路：不管过去发生了什么，只把当前公开观察写进一个合法的战斗状态（称为公开根节点快照），让搜索 AI 在上面把每个候选动作结算一步。这是公平搜索 Public Quick 的基础。

在 381 个开发决策点上迭代 12 轮后：347 个点能构造快照，其中 311 个的合法动作与真实公开菜单完全一致。一个关键发现是：卡面数值对齐后攻击预览仍常不同，差在卡面不显示的伤害修正；用玩家悬停目标时看到的攻击预览校准一个参数，预览一致率达到 96.4%——这是在同一批预览上拟合，不是独立预测准确率。研究诊断，没有棋力结论。

要回答的问题

当前局面能否只从公开信息构造、并支持一步结算？与真实状态的差距在哪里？

方法

  1. 模板：实验 0077 的开局公开世界（己方真实构筑，对手中性先验）。
  2. 用当前公开观察覆盖：每个兵组的位置、数量、当前总生命、剩余反击、是否已等待、可见状态（对手来源的状态只有公开效果数值）；行动队列、回合、场地效果；己方英雄字段；对手英雄的魔法与法强取界面 HUD 值，法术取已施放的。
  3. 用引擎自己的状态校验做判据：法术状态的施放法强、持续时间、对手法术等级只在“能复现公开参数”的范围里搜索，修不好的状态丢弃；迭代调整兵组基础攻防与伤害上下限，使卡面实际值与公开值一致。
  4. 真实状态只用于生成公开观察、菜单和对照。

检查项（只计数，不设门槛）：构造成功与失败原因、快照公开投影与真实观察的差异、合法菜单差异、攻击预览是否一致、耗时。

设置

与 0077 相同的 381 个开发点（0075 第 2 次对局，种子 70800–70819）。每次改构造器都在新目录完整重跑，旧结果保留。这些数字反映构造器的开发进度，不是冻结评估。

结果

运行 主要改动 构造成功 菜单完全一致
run-1 生命由公开总生命推出；法术状态补施放输入；对齐公开攻防 85/381 67
run-3 状态按编号排序 203/381 115
run-5 写入场地效果、待放置法术、己方集能与冷却 203/381 171
run-9 始终保留专精标记；统一最大生命类状态的基础生命 264/381 231
run-11 补上战斗中召唤/镜像出的兵组（按公开卡面与兵种目录新建） 339/381 301
run-12 法术施放等级与英雄当前等级同步；先验等级不合法时依次试其它等级 347/381 311

run-12 剩余失败：菜单校验 34、先验 8。构造中位约 0.14–0.16 秒。

攻击预览差异从哪来：对照组（真实状态只去掉对手装备和英雄技能状态）预览 77% 一致，快照只有 32%。逐项核对发现，卡面数值已对齐，差在单位层面的伤害修正，例如防守方的“基础攻击承受修正”、攻击方被对手削弱的输出修正——由对手隐藏技能和装备设定，卡面不显示。但玩家悬停目标时能看到攻击预览（伤害范围与击杀数），这是公开信息。把“快照预览与悬停预览之差”折算成目标的承受修正，一个参数就能同时复现最小伤害、最大伤害和击杀数：run-10 中 874 个不同预览里 827 个可精确复现，合计 1,247/1,294（96.4%）；run-12 校准后 1,603/1,662（96.4%）。

局限

  • 96.4% 是同批拟合，不是独立预测；校准只针对当前行动单位的普通攻击，反击、法术、单位技能伤害仍是估计；同一目标被其它己方单位攻击时，攻击方被削弱的部分被并进了目标修正，可能不准。
  • 真实游戏中每个目标都要悬停一次；悬停预览本身来自本地 Simulator，尚未与商业客户端对照。

结论与下一步

公开根节点快照可行，能覆盖约九成开发点。在它上面做一步搜索的原型试打见实验 0079。