用途
该技能用于评估并改善游戏玩法平衡，判断游戏是否奖励有技巧的玩法，并提出结构性改进建议。它不绑定特定引擎，可用于任何引擎的项目。
核心契约
该技能要求产出可比的运行结果，用于对比两类策略：单调策略（monotonous policies）和探索策略（exploratory policies）。需要定义策略可用的公共输入模式与可见状态特征。跨运行需保持一致的要素包括：随机种子、tick 速率、最大时长、策略定义、搜索预算、聚合逻辑。
需要记录的遥测内容包括：得分、耗时、结束状态，以及死亡、生成、计分、输入和使用行为。其中「使用」指实际游戏行为构成：核心机制贡献了多少动作与得分、玩法空间中哪些区域被占据、每种威胁触发的频率与命中情况。
当游戏存在存活之外的目标时，应加入忽略目标的策略用于对比：一种为维持得分而拖延，一种在不追求目标的前提下存活。拖延策略得分更高是一个信号，提示检查其上限、成本与全局影响，但本身不算缺陷。
计算方式：exploratory_ratio = exploratory.best.score / monotonous.max_score。该比率是质量检测器，不是优化目标。
执行配置（Execution Profile）
每个非基线策略都需声明执行配置及其可见状态特征，分为三类：oracle（允许隐藏信息，作为上界）、precise（可见状态、近乎完美的时机与注意力）、human-limited（可见状态加上 references/simulation-harness.md 中的人类限制）。比率应基于 precise 策略计算（包含基于搜索的运行器，除非标记为 oracle）；它检测的是漏洞利用，不是难度。
难度、计时、节奏与进程目标只能依据 human-limited 运行设定。每条结论都需标注其所依赖的配置。若没有 human-limited 运行，不得给出难度或节奏判断，应报告为「尚未测量」。
关于某策略占优或某权衡是否平衡的论断，必须说明其测试所在配置。若排名在不同配置间翻转，这本身不是平衡缺陷，应报告为「依赖技巧」，但仍需对每个配置的最优策略应用体验护栏（human-limited 最优策略是闲置或等待，即属缺陷）。
非确定性测试台
上述契约假定存在带种子的前向模型。有些测试装置无法提供：例如在挂钟窗口内驱动的真实浏览器、无法控制 RNG 的引擎、对着实时渲染运行的策略对比。带种子仍是首选；当确实不可用时，用以下方式替代：
- 对每个策略报告 n ≥ 3 次运行的最小—最大区间，绝不使用点估计。长尾分布的单一运行无法证明任一策略的优劣。
- 要声称区间发生变化，需 n ≥ 5 且与已记录的历史区间不重叠。与先前区间重叠的样本不构成发现。
- 将接受的区间及其已知尾部记录在项目规格中，以便后续运行与历史比较。若某策略在部分运行中已知会落到某个不佳数值附近，该尾部应被记录并定论——不再每次出现都重新争论。
撤回是有效且预期的输出。基于小样本发表、而更大样本不支持的结论应就地撤回：若机制真实则保留机制，并说明其效应大小与噪声无法区分。
体验护栏
- 拒绝即使指标改善但降低游戏体验的改动。
- 只对游戏内的因果事件计分；不为原始输入事实给分。
- 游戏结束应关联危险或世界状态崩溃。
- 不要添加只帮助或伤害测试代理的隐藏行为。
- 避免以纯数值调优、仅分支修复、添加随机性作为主要答案。
- 将实机试玩报告视为 human-limited 配置的校准数据。当报告与模拟结果冲突时，先检查测试台缺陷，再将配置向报告方向调整、重跑并记录调整，不要仅凭机器人数据否定报告。
- 不要用其行为由该参数定义的策略来调优参数（例如「计时器高于 80% 时等待」）；测量会随调优移动。
工作流
- 定位现有模拟测试台。若不存在，先按测试台契约设计一个，再进行平衡判断。
- 选择对比协议：若有种子，使用相同确定性种子运行可比的单调与探索策略；若确实无种子，使用上述非确定性区间协议，并保持运行次数、挂钟窗口、策略定义与采样节奏可比。
- 校验报告包含运行配置及死亡、生成、计分、输入和使用遥测。若遥测不完整，报告缺口并请求插桩／重跑，而不是仅凭得分判断平衡。
- 分析游戏前，先对非平凡策略做健全性检查。检查失败即测试台缺陷：修复策略、重跑并报告缺陷。这包括上限检查：当强策略表现不优于 human-limited 策略时，先排除指标饱和与游戏不奖励精确度的可能，再寻找人会避免的失败。
- 分析死亡、生成、计分、输入与使用模式。在读取得分比率前，先将使用情况与设计声明的核心交互对比。
- 在规则或生成逻辑中定位根因。
- 提出至少三种候选修复，含预期影响、风险与复杂度。
- 实施后用相同策略、预算、聚合与对比协议复测。确定性运行保留相同种子；非确定性运行保留相同运行次数与采样设置。
项目检查器分诊（当报告包含 ratio.diagnostic）
应用任何结论前，先用独立于最终得分对比的证据检查仪器置信度。只有当探索搜索可证明地玩了游戏时，结论才可信：其最佳得分随搜索迭代提升而非一开始就持平，或其运行触及了单调策略从未触及的计分机会与机制。若两个信号都不存在，视为仪器失败（搜索器找不到有技巧的玩法），而非关于设计的证据：将游戏转交人工或 LLM 审查。
- mono_dominant：单调策略得分高于探索玩法。检查输入与计分遥测是否存在缺失的权衡、可复用的计分脉冲、安全计分或原始输入奖励。若 README 不变量未阻止闲置、仅保持或安全等待占优，这是设计问题，应如此报告以便调用方修订 README 并重新实现。否则优先结构性代码级修复。
- tied：探索玩法无法实质性超过单调基线。除非遥测清楚显示单一不公平危险同时阻挡两类策略，否则这是设计问题，应如此报告，不要尝试代码级修复。
- marginal：探索玩法领先但不够。确定是具体代码级原因（实现问题）还是计分／权衡结构本身缺失（设计问题）。
放弃标准
若根因需要更改核心体验或放弃标签关系才能修复，或已用尽 3 次改进尝试，应报告该设计无法在框架约束内挽救，并建议产出一份失败报告，而不是强行再次重设计。不要为通过门槛而提出在同一 slug 下发明新游戏的修复。
当该技能运行在筛选漏斗内（大量候选被生成、排名、淘汰而非修复）时，失败报告路径不适用：报告诊断并让排名淘汰该产物。修复尝试与 3 次限制保留给筛选后的赢家。
遥测稀疏时的探针
当遥测被汇总或稀疏时，在编辑前请求或添加最小的聚焦探针。有用探针包括：死亡危险 id／类型／年龄与玩家输入窗口、生成位置与安全距离、计分原因／目标 id／风险上下文、计分／死亡附近的输入节奏、活动实体数量、每唯一机会得分、每来源动作与得分、在玩法空间各区域花费的时间、每种威胁的开火与命中次数、无主要威胁存在的最长时段。
参考文档
- references/simulation-harness.md：设计确定性模拟器、输入策略、执行配置、健全性检查与遥测发射器。
- references/log-contract.md：引擎中立的遥测模式。
- references/improvement-analysis.md：分析视角与报告模板。
- references/balance-patterns.md：结构性平衡模式。
- references/godot-implementation-notes.md：将常见平衡修复翻译为 Godot/GDScript。
配套技能
对 Godot 项目，使用 scaffolding-godot-mini-games 进行项目搭建，使用 running-headless-godot 进行模拟器执行、测试、日志与导出检查。
触及规则的结构性修复属于设计变更，不是数值调优；不要在不重访设计的情况下静默重新调数值。
限制
- 无 human-limited 运行时，不得给出难度或节奏判断，只能报告为尚未测量。
- 非确定性环境下必须使用区间协议，不得用单次运行得出结论。
- 不得添加只影响测试代理的隐藏行为。
- 该技能的官方文档与价格信息暂未提供，具体以对应参考文档为准。