摘要

Public Quick 是只用玩家可见信息的一步搜索：先用公开观察构造当前局面的快照（实验 0078），用悬停攻击预览校准伤害，再像研究搜索 quick 一样把每个合法动作真实结算一次挑最好的；快照失败时交给英雄无敌三式规则 AI H3。本实验在开发来源上检查原型能否稳定打完整局、回退多少、耗时多少。不做棋力结论：来源是 0077/0078 用过的开发来源，样本也小。

两轮结果：16 局都 0 崩溃、0 非法动作、严格重放一致。第一轮约一半的局在出现召唤或镜像单位后整局回退 H3；补上这类单位后，Public Quick 决定了 94.9% 的决策，但核心最长耗时 5.789 秒，超过 4 秒。

要回答的问题

原型能否稳定打完整局？回退比例与耗时如何？

方法

  • 信息边界：只有一个函数接触真实状态，它只返回公开观察、公开菜单、公开历史摘要（对手本回合施法次数）和当前行动单位对每个敌方目标的悬停攻击预览，并经过一次 JSON 往返；决策核心只接收这些数据、公开开局观察和己方构筑。
  • 按审阅建议改名为“Public Quick — Local UI Preview Assisted（本地 UI 预览辅助）”：悬停预览来自本地 Simulator，尚未与商业客户端对照。预览必须属于当前决策，否则不用。
  • 测试：核心输入可完整 JSON 序列化，同一输入两次决策相同。

设置

种子 70800–70807（8 个开发来源），每来源 Public Quick 执蓝、执红各一局对 H3，进程内运行（不走实时 worker），镜像开局、20 回合、规则版本 Core453。

结果

run-1（158 秒）：

  • 850 次决策中 Public Quick 决定 453 次（53.3%），回退 H3 397 次——快照里没有召唤/镜像新单位 388 次、其它校验错误 9 次；召唤一出现，这局之后都回退。
  • 由 Public Quick 决定时菜单覆盖均为 1.0（快照合法动作覆盖整个公开菜单）；悬停校准 1,436 个目标。
  • 核心耗时（进程内）：p50 0.155 秒、p95 1.355 秒、最长 3.72 秒。
  • 描述性胜负：12 胜、3 负、1 双输。无召唤回退的 8 局全胜；有召唤回退的 8 局 4 胜。

run-2（构造器补上战斗中生成的单位等之后，同种子同设置；候选已变，属开发迭代，不是重复）：

  • 828 次决策中 Public Quick 决定 786 次（94.9%），回退 42 次（全是快照被引擎校验拒绝）；悬停校准 2,165 个目标。
  • 核心耗时：p50 0.389 秒、p95 1.842 秒、最长 5.789 秒——超过 4 秒，实时路径下这类步骤会到截止并回退。
  • 描述性胜负：16 局全胜（开发来源、样本小，非棋力结论）。

局限

开发来源、样本小；进程内耗时不含实时 worker 的进程启动（约 0.7 秒）。

结论与下一步

原型能稳定打完整局。下一步接一个与 Arena 实时路径同结构的执行器，再在 64 个全新来源上冻结正式评测（实验 0076 阶段二），同时压缩耗时尾部（实验 0080）。