verifying-turn-based-games

用途

本技能为双人、严格交替回合制游戏提供一套可复用的引擎接口契约与质量度量方法。它规定“做什么”（契约与指标定义），不规定语言、运行时、文件布局、构建系统、工具命令、创意或标签工作流、面向玩家的文档格式，也不生成引擎代码——这些属于项目本地选择。

适用：双人、严格交替回合；完全或不完全信息；有限回合上限；通过显式种子实现确定性随机（无副作用随机）。

不适用（不要套用）：同时行动、反应/打断窗口；3 人及以上；实时/非回合制；单人解谜。若目标游戏不符合适用范围，应停止并告知用户本技能不适用，而不是强行套用契约。

引擎必须暴露以下纯函数（签名以 TypeScript 风格表示，可按宿主语言翻译）：

init(config?: Config, seed?: number): State
step(state: State, action: Action): { state: State, reward?: number, done: boolean, info: object }
getLegalActions(state: State): Action[]
getObservation(state: State, playerId: PlayerId): State
getResult(state: State): { done: boolean, winners: PlayerId[], reason: string, scores?: Record<PlayerId, number> }
scoreState(state: State, playerId: PlayerId): number
replayLog(state: State): string
cloneState?(state: State): State

契约说明：

getLegalActions 与 step 隐式使用 state.currentPlayer。契约假设严格交替回合，不要扩展到同时行动。
state.history: Event[] 必须存在，且必须在 step 内追加。replayLog 是对 state.history 的纯格式化器，不需要外部收集器。
state.rngSeed 必须存在；step 内所有随机性都由它确定性派生。不得使用 Math.random()、读取时钟或其他副作用随机。
getObservation 返回同一 State 类型，将隐藏字段置空或掩码，而不是返回不同的观察类型。这样机器人可与引擎保持类型兼容。
getResult 取代更简单的 getWinner，使调用方能区分按生命值获胜、按牌库耗尽获胜、按回合上限平局等。reason 字符串为必需。
scoreState 是度量层（第二部分）所必需的。省略 scoreState 的引擎无法被本技能做质量评估。
仅当 State 不是完全不可变时才需要 cloneState。若宿主语言保证不可变性（或使用结构共享），可省略。

必需不变量：

无全局可变状态。
step 不修改其输入状态。分支搜索通过 step(cloneState(s), a) 或依赖不可变性。
重放确定性：给定固定种子与固定动作序列，init 后重复 step 在多次运行中产生逐字节相同的状态。
单一非法动作策略：在引擎中选定一种并记录——抛出异常、返回 { state: s, done: false, info: { illegal: true } } 且不改变状态、或自动跳过。不要混用策略。
Action 与 State 必须可 JSON 序列化（重放、持久化、搜索缓存都依赖此点）。

实现前检查清单：在编写引擎之前，规则文档必须明确：

若上述任一项未明确，不要开始引擎实现——先回到规则设计。

当引擎满足第一部分后，从两层评估质量。

当问题本身就是质量时运行第二部分：新规则集或重做规则集、明确的平衡性或机器人强度评估，或对 scoreState、动作合法性、机器人逻辑的改动。UI、措辞、渲染以及不触及规则语义的纯序列化改动只需第一部分契约检查——不要为它们重跑阶梯与指标套件。

在契约之上实现三种机器人：

每场对局测量 N ≥ 200 局，交换座位以控制先手优势。

指标与目标：

每局每回合对 scoreState 做快照。推导 WP（胜率）为 WP = sigmoid((score0 − score1) / T)。按游戏校准温度 T，使随机对强在终局时强的 WP 平均约为 0.9。

指标与目标：

失败模式检查清单：当指标未达标时，查找：

改进循环纪律：