balance-check

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

平衡性检查

每次调用 AskUserQuestion 都遵循 .claude/docs/automation-modes.md （协作模式始终提问 · 引导模式仅对重大事项提问 · 自主模式记录并继续； automation_always_ask 类别始终提问）。

输入不足——生成任何报告前先检查

如果此技能所需的输入不存在，答案应为“无法运行”—— 而不是一份填好的报告。 先检查；如果检查未通过，就停止。

1. 列出此技能读取的输入（数据文件、先前的报告、分析器输出、 测试结果、注册表、源代码）。
2. 对每项记录 FOUND 或 ABSENT——不可“假设存在”。
3. 如果某个部分所需的任何输入为 ABSENT，该部分应标记为 NOT ASSESSED — NO DATA。不要估算，不要根据相邻的材料推断，也不要把必须填写的单元格留给之后阅读模板的人。
4. 如果所有必需输入均为 ABSENT，停止并将 NOT ASSESSED — NO DATA 作为整体判定，指出缺失的内容以及负责生成这些内容的技能。

判定为 NOT ASSESSED 也算成功。当没有数据时，这是对“数据说明了什么？”这一问题正确且有用的回答。 这可以防止一种特定的失败模式：判定枚举中没有“无法运行”状态的报告会产生 错误的通过结果——例如，在项目没有资源也没有标准时，资源审计仍返回 COMPLIANT；或者在没有任何分析器数据、且从未设定预算时，性能分析仍报告“相对于 16.67ms 预算有 >99% 的余量”。

没有证据绝不代表不存在。 如果没有可扫描的文件，因此扫描未发现匹配项，这并不等于验证了任何内容。请说明究竟发生了哪一种情况——仅凭绿色结果，读者无法判断。

---

第 1 阶段：确定平衡领域

根据 $ARGUMENTS 确定平衡领域——检查整个字符串，因为数据文件路径可能包含空格：

• 战斗 → 武器/技能 DPS、击杀时间、伤害类型交互
• 经济 → 资源产出/消耗、获取速率、物品定价
• 成长进度 → XP/强度曲线、空档期、强度峰值
• 战利品 → 稀有度分布、保底计时器、库存压力
• 提供了文件路径 → 直接加载该文件，并根据内容推断领域

如果没有参数，询问用户要检查哪个系统。

---

第 2 阶段：读取数据文件

从 assets/data/ 和 design/balance/ 中读取与已确定领域相关的文件。 记录读取的每个文件——它们将列在报告的“数据来源”部分。

第 3 阶段：阅读设计文档

先读注册表。 如果存在 design/registry/entities.yaml，请先于 GDD 阅读。其 constants 和 formulas 部分包含跨 GDD 的命名值和输出范围——即平衡目标——这些内容已提炼完成，并分别标注了 source: GDD 和任何 revised: 日期：

Grep pattern="^  - name:" path="design/registry/entities.yaml" output_mode="content" -A 6

对于注册表中列出的任何常量或公式（constants: 和 formulas: 块），请采用注册表中的预期值；这些是跨文档的权威数据，GDD 不得与之矛盾。如果 design/registry/entities.yaml 不存在或没有条目（在 /design-system 填充之前，该文件会作为空存根提供），则跳过此步骤，仅使用 GDD。

然后阅读 design/gdd/ 中该系统的 GDD，了解预期设计目标、调节参数和预期值范围——仅限注册表尚未提供的内容。这是判断行为是否“正确”的基准。按章节阅读： 使用 Grep 工具（模式 ^#，内容模式）查找所需标题，再用 offset 和 limit 读取相应范围。

如果数据文件已找到，但这两个来源都没有提供该领域的目标值，则针对目标值进行判断的章节（检测到的异常，以及当该领域存在曲线时的进度分析）均标记为 NOT ASSESSED — NO DATA。每个章节都要说明缺少了什么——查找的 design/gdd/ 中的 GDD，以及注册表是缺失还是为空——并注明负责编写这两项内容的 /design-system。

---

第 4 阶段：执行分析

每个领域：将每个值与其目标值进行比较。 对于数据文件中的每个命名值，采用第 3 阶段确定的目标值——注册表常量的 value、注册表公式的 output_range，或 GDD 中说明的范围——并进行比较。超出目标范围的值应列为“检测到的异常”（例如，player_damage_base 为 140，而目标范围是 90–110）。完全没有目标值的值既不属于范围内，也不算异常：请在“需要关注的值”下列出为 no stated range — not judged。

然后执行特定领域的检查：

战斗平衡：

• 计算每个威力等级下所有武器／能力的 DPS
• 检查每个等级下的击杀时间
• 找出是否有选项优于其他所有选项（绝对占优）
• 检查防御选项是否会导致无法被击杀的状态
• 验证伤害类型与抗性之间的相互作用是否平衡

经济平衡：

• 列出所有资源来源和消耗，并标明流速
• 预测资源随时间的累积情况
• 检查是否存在无限资源循环
• 验证金币消耗是否随金币产出而增长
• 检查是否有任何物品永远不值得购买

进度平衡：

• 绘制 XP 曲线和威力曲线
• 检查是否存在停滞区（长时间没有有意义的进度）
• 检查是否存在威力骤增（能力突然跃升）
• 验证内容门槛是否与预期玩家威力相符
• 检查跳过／刷取策略是否破坏预期节奏

战利品平衡：

• 计算获得各稀有度等级物品的预期时间
• 检查保底计时器的计算
• 验证任何阶段都没有完全无用的战利品
• 检查库存压力与获取速率是否相称

---

第 5 阶段：输出分析

## Balance Check: [System Name]

### Data Sources Analyzed
- [List of files read]

### Health Summary: [NOT ASSESSED / HEALTHY / CONCERNS / CRITICAL ISSUES]

### Outliers Detected
| Item/Value | Expected Range | Actual | Issue |
|-----------|---------------|--------|-------|

### Degenerate Strategies Found
- [Strategy description and why it is problematic]

### Progression Analysis
[Graph description or table showing progression curve health]

### Recommendations
| Priority | Issue | Suggested Fix | Impact |
|----------|-------|--------------|--------|

### Values That Need Attention
[Specific values with suggested adjustments and rationale]

根据最严重的发现选择健康摘要，按顺序匹配，命中第一项即停止：

• CRITICAL ISSUES — 存在退化策略（一种选择优于所有其他选项）、进度停滞或无法完成，或经济系统存在没有消耗途径的循环
• CONCERNS — 存在可通过调优解决的异常或曲线问题，且没有严重程度达到关键级别的发现
• NOT ASSESSED — 没有可分析的内容（上述无数据路径）、需要目标值的章节为 NOT ASSESSED — NO DATA，或某个值没有明确范围可供判断；请注明具体情况。其级别低于两种问题判定，因为已测得的问题比信息缺口更便于采取行动；但高于 HEALTHY
• HEALTHY — 每个值都依据明确目标值进行了判断，没有异常、没有退化策略，且进度符合所述目标

---

阶段 6：修复与验证循环

呈现报告后，使用 AskUserQuestion：

• 提示词："平衡性检查已完成。接下来你想做什么？"
• 选项：
  • [A] 立即修复优先级最高的问题 — 引导我完成
  • [B] 将报告保存到 design/balance/balance-check-[system]-[date].md
  • [C] 到此为止 — 我会手动查看检查结果

作为子 Agent 运行？ game-designer 会预加载此技能，而子 Agent 无法使用 AskUserQuestion。请在回复末尾以一个问题和以下三个选项的简短列表结束，然后停止：由调用你的人询问用户，并将答案传回。

如果选择 [A]：

• 询问要先处理哪个问题（参照 Recommendations 表格中的优先级行）
• 引导用户更新 assets/data/ 中的相关数据文件，或更新 design/balance/ 中的公式
• 每次修复后，询问是否重新运行相关的平衡性检查，以确认没有引入新的异常值
• 如果修复更改了 GDD 中定义或 ADR 中引用的调优参数，请提醒用户：

  "此值定义在设计文档中。提交前，请对受影响的 GDD 运行 /propagate-design-change [path]，以查找下游影响。"

如果选择 [B]：

• 将报告写入 design/balance/balance-check-[system]-[date].md（如有需要，请创建目录）。将当前日期用作 [date]，格式为 YYYY-MM-DD。
• 确认文件已写入，然后以此结束："修复后重新运行 /balance-check 进行验证。"

如果选择 [C]：

• 总结尚未解决的问题，并以此结束："修复后重新运行 /balance-check 进行验证。"