用 /balance-check 做系统化游戏平衡审计：Claude Code Game Studios 六阶段平衡检查技能详解

用 /balance-check 做系统化游戏平衡审计Claude Code Game Studios 六阶段平衡检查技能详解【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios导读本文深入解析 Claude Code Game StudiosCCGS中负责游戏平衡审计的斜杠命令/balance-check。该技能以只读方式分析战斗、经济、进度与战利品四类平衡数据对照 GDD 设计基准输出异常定位、退化策略与修复建议并驱动修复—重检闭环。读完本文你将掌握 balance-check 的六阶段工作流、四类领域化检查清单、结构化报告模板以及它在 CCGS 技能测试框架下的行为验收标准可直接在你的项目里复现这套平衡审计流程。一、技能定位balance-check 在 CCGS 中的角色/balance-check是 CCGS 中 72 个技能之一属于Reviews Analysis评审与分析类别的分析型技能见 .claude/docs/skills-reference.md其技能定义文件位于 .claude/skills/balance-check/SKILL.md。技能文件头部frontmatterSKILL.md定义了该命令的关键元信息字段值含义namebalance-check命令名以/balance-check方式调用description分析平衡数据文件、公式与配置找出异常值、断裂的进度曲线、退化策略与经济失衡触发语义描述argument-hint[system-name\|path-to-data-file]可选参数系统名或数据文件路径user-invocabletrue用户可直接在对话中调用allowed-toolsRead, Glob, Grep只读工具集——该技能被设计为纯只读分析agenteconomy-designer由经济设计师 Agent 负责执行见 .claude/agents/economy-designer.md触发方式当用户在 Claude Code 对话中输入balance report、check game balance、run a balance check或直接键入/balance-check时技能被激活。它适用于任何修改平衡相关数据或设计之后的校验场景——例如调过武器数值、改过掉落表、动过经济公式之后用它对全量数据做一次体检。从技能测试框架看balance-check 被登记在 CCGS Skill Testing Framework/catalog.yaml 中category为analysis其行为规格文件是 CCGS Skill Testing Framework/skills/analysis/balance-check.md。该规格文件详细描述了 5 个验收测试用例后文第七章展开是理解技能行为的权威旁证。需要特别强调的是这是一个不触发任何导演门禁director gate的只读分析技能它不写文件、不调用导演评审、不读取review-mode.txt输出报告后是否落盘完全由用户决定。这使其可以被安全地高频执行。二、Phase 1确定平衡领域Identify Balance Domain技能的第一步是从$ARGUMENTS[0]解析调用参数确定本次审计的平衡领域SKILL.md。参数解析遵循以下规则Combat战斗→ 检查武器/技能 DPS、击杀时间time-to-kill、伤害类型相互作用Economy经济→ 检查资源产出端faucets/消耗端sinks、获取速率、物品定价Progression进度→ 检查经验/实力曲线、死区dead zones、实力突增power spikesLoot战利品→ 检查稀有度分布、保底计时器pity timers、背包压力File path given传入文件路径→ 直接加载该文件并从文件内容推断所属领域未传参数→ 主动询问用户要检查哪个系统。这里的参数设计很有工程价值argument-hint允许两种输入形态——要么给一个语义化的系统名如combat、economy要么直接给一个数据文件路径如assets/data/combat-balance.json。后者让技能具备文件驱动能力特别适合在已知问题文件时做定向审计而无需用户先理解领域分类。三、Phase 2 与 Phase 3数据源读取与设计基准建立3.1 读取平衡数据文件Phase 2技能从模板约定的两个目录读取平衡数据SKILL.mdassets/data/—— 存放实际的平衡数值数据JSON/YAML 格式的数值配置design/balance/—— 存放平衡公式与推导过程文档。每次读取的文件都会被记录并最终出现在报告的Data Sources Analyzed数据源分析小节中。这一设计保证了报告的可追溯性任何人拿到报告都能复现审计输入知道结论是基于哪些数据得出的。3.2 读取 GDD 建立基准Phase 3技能随后从design/gdd/读取对应系统的游戏设计文档GDD提取设计目标intended design targets、可调旋钮tuning knobs和期望数值范围SKILL.md。这一步是 balance-check 区别于拍脑袋式检查的核心GDD 中定义的公式与期望区间是判断正确行为的基线baseline。数据文件中的实际值必须对照 GDD 中的公式目标来评估偏差而不是孤立地看数值大小。这也与 CCGS 的路径规则一致——design/gdd/**路径强制要求8 个必需章节、公式格式、边界情况见 README.md 的路径规则表保证了 GDD 中确实存在可供校验的公式定义。值得一提的是CCGS 还提供实体注册表 design/registry/entities.yaml 作为跨系统事实的权威来源——economy-designer Agent 在定义物品数值前必须先查注册表见 .claude/agents/economy-designer.mdbalance-check 的校验基准同样可以与注册表配合使用。四、Phase 4领域化分析清单Perform Analysis这是技能的核心分析阶段SKILL.md按领域执行针对性检查。以下检查项是原文档定义的完整清单战斗平衡Combat balance计算所有武器/技能在每个实力层级power tier的 DPS检查每个层级的击杀时间time-to-kill识别严格支配选项——即某项选择在所有方面都优于其他选项strictly better导致其他选项无存在意义检查防御性选项是否可能构成不可击杀状态unkillable states验证伤害类型/抗性damage type/resistance交互是否平衡。经济平衡Economy balance映射所有资源产出端faucets与消耗端sinks并标注流速flow rates预测资源随时间的累积量project resource accumulation over time检查是否存在无限资源循环infinite resource loops验证金币消耗端gold sinks是否与金币产出规模gold generation同步增长检查是否存在任何永远不值得购买的物品。进度平衡Progression balance绘制经验曲线XP curve与实力曲线power curve检查死区dead zones——长时间没有有意义的进度推进检查实力突增power spikes——能力突然跳变验证内容关卡content gates与期望玩家实力是否对齐检查跳过/刷取策略skip/grind strategies是否破坏预期节奏。战利品平衡Loot balance计算获取每个稀有度层级的期望时间expected time to acquire each rarity tier检查保底计时器pity timer的数学计算是否正确验证任何阶段都不存在严格无用的战利品strictly useless loot检查背包压力inventory pressure与获取速率acquisition rate的匹配度。这些检查项与 economy-designer Agent 的核心职责高度呼应——资源流建模Resource Flow Modeling、战利品表设计、进度曲线设计、经济健康指标见 .claude/agents/economy-designer.md。也就是说balance-check 相当于把经济设计师的经验检查单形式化为可重复执行的审计流程。五、Phase 5结构化报告输出Output the Analysis分析完成后技能按照固定模板输出报告SKILL.md。该模板是原文档定义的完整输出契约值得逐节掌握## Balance Check: [System Name] ### Data Sources Analyzed - [List of files read] ### Health Summary: [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]模板的工程要点数据源可追溯Data Sources Analyzed列出所有读取过的文件——对应 Phase 2 的文件记录机制健康总览Health Summary给出三档结论——HEALTHY健康/CONCERNS有隐忧/CRITICAL ISSUES严重问题异常定位表Outliers Detected用四列表格项目 / 期望范围 / 实际值 / 问题精确指明偏差退化策略区Degenerate Strategies Found单独列出玩家可以利用的破坏性策略及其危害——这是平衡审计区别于单纯数值校验的关键维度进度分析区Progression Analysis允许用图表描述或表格呈现进度曲线健康状况建议分级表Recommendations按优先级Priority列出问题、建议修复方式与影响Impact为后续修复环节提供操作依据待关注数值Values That Need Attention给出具体数值的调整建议与理由。而行为规格文件 CCGS Skill Testing Framework/skills/analysis/balance-check.md 对报告的列结构做了更严格的约定findings 表格列应为Value → Formula → Deviation → Severity数值 / 公式目标 / 偏差 / 严重度并规定裁决结论verdict为三选一BALANCED平衡/CONCERNS隐忧/OUT OF BALANCE失衡。这与 SKILL.md 正文中的HEALTHY / CONCERNS / CRITICAL ISSUES措辞略有出入——按测试框架 CLAUDE.md 的说明规格文件描述的是当前行为而非理想行为CCGS Skill Testing Framework/CLAUDE.md因此在你的项目中具体使用哪组结论词应以实际技能行为为准但三档健康度结构化表格的报告骨架是稳定不变的。六、Phase 6修复与验证循环Fix Verify Cycle报告展示完毕后技能进入修复—验证的闭环流程SKILL.md征询修复意愿技能主动询问Would you like to fix any of these balance issues now?是否现在修复这些问题按优先级处理若用户同意先询问要优先处理哪个问题按 Recommendations 表的 Priority 行引用并引导用户更新assets/data/中的对应数据文件或design/balance/中的公式修复后复检每次修复后主动提议重跑相关平衡检查验证没有引入新的异常值设计变更传播提醒如果修复涉及 GDD 中定义的调校旋钮、或被 ADR 引用的数值技能会明确提醒This value is defined in a design document. Run/propagate-design-change [path]on the affected GDD to find downstream impacts before committing.这条提醒把 balance-check 与 CCGS 的设计变更传播技能.claude/skills/propagate-design-change/SKILL.md串成完整链路——平衡数值通常被多个系统文档共享改一处可能影响多处报告归档若用户暂不修复则汇总未决问题并建议将报告保存到design/balance/balance-check-[system]-[date].md供后续处理循环收尾以Re-run/balance-checkafter fixes to verify.修复后重跑验证作为收尾指令形成持续改进闭环。这个循环的设计哲学是协作式而非自治式技能只负责分析、建议与引导是否修改、改哪个、什么时候改决策权始终在用户手中。这与 CCGS 全局的Collaborative, Not Autonomous协作协议一致见 README.md——agents 提供结构与专业判断用户做最终决定。七、行为验收标准测试规格中的 5 个用例balance-check 的行为被 CCGS Skill Testing Framework/skills/analysis/balance-check.md 以 5 个测试用例Test Cases的形式固化这是理解技能边界的最直观材料用例场景期望行为Case 1Happy Path6 个数值全部落在 GDD 公式 ±10% 容差内输出 findings 表且全部 PASS裁决BALANCED未获批准不写任何文件Case 2Out of Balanceplayer_damage_base为 140公式目标 100±10%偏差 40%严重度标记 HIGH超出容差 2 倍以上裁决OUT OF BALANCEHIGH 项显式突出而非淹没在表格中Case 3No GDD Formulas存在经济数据但 GDD 无对应公式不臆造公式目标输出 Cannot validate economy stats — no formulas defined. Run /design-system first.裁决CONCERNSCase 4Orphan Reference数据文件含legacy_armor_mult: 1.5但 GDD 无其公式标记为 ORPHAN REFERENCE孤儿引用与公式偏差区分显示其他正常数值照常 PASS裁决CONCERNS不得静默跳过孤儿数值Case 5Gate Compliance任意 review-mode 下运行不触发任何导演门禁findings 表直接展示可选报告写入需 May I write 明确批准这些用例定义了几条重要的行为红线禁止臆造基准Case 3GDD 中没有公式定义时技能不得自行编造目标值而应明确告知缺失并引导运行/design-system补齐公式孤儿引用必须显式暴露Case 4数据文件里有、GDD 里没定义的数值必须以孤儿引用状态呈现防止无效数值悄悄漏检严重度分级Case 2偏差超出容差 2 倍以上即为 HIGH 严重度且 HIGH 项必须在表格前单独突出不允许埋在数据行里只读合规Case 5全程零门禁、零自动写入报告落盘必须走 May I write 批准流程。在技能测试框架中这些用例通过/skill-test spec balance-check逐条断言验证catalog 中登记了spec路径与测试追踪字段见 CCGS Skill Testing Framework/catalog.yaml静态结构断言frontmatter 必填字段、≥2 个 phase 标题、verdict 关键词、May I write 语言、下一步交接则由/skill-test static自动检查。八、实战建议把 balance-check 接入你的开发循环基于以上六阶段流程与验收标准在实际项目中使用 balance-check 时有几条经过验证的经验1. 把它作为改数必检的默认动作。技能描述明确指向修改任何平衡相关数据或设计之后的使用场景。养成每次调整数值后运行一次/balance-check [system]的习惯可在问题进入 QA 与玩家侧之前被拦截。2. 用文件路径参数做定向审计。当怀疑某个具体数据文件有问题时直接传路径/balance-check assets/data/combat-balance.json技能会自动从内容推断领域省去领域分类的沟通成本。3. 先建公式再谈平衡。Case 3 揭示了一个硬性前提没有 GDD 公式就没有校验基准。新系统上线前先用/design-system补齐公式定义包括期望值范围balance-check 才有正确的对照物。这正是 .claude/skills/design-system/SKILL.md 与 balance-check 的上下游关系。4. 重视退化策略与孤儿引用。数值合规 ≠ 系统平衡strictly better 选项、无限资源循环、不可击杀状态等退化策略是平衡审计的增值点不要只看偏差表孤儿引用则往往是数据残留信号应借此清理过时配置。5. 串起设计变更传播链路。当修复涉及 GDD/ADR 中的共享数值时务必按技能提醒运行/propagate-design-change评估下游影响避免修好战斗、炸了经济的局部优化。6. 沉淀报告资产。将审计报告按design/balance/balance-check-[system]-[date].md命名归档既形成平衡演进的历史基线也为后续consistency-check、review-all-gdds等跨文档评审提供素材。balance-check 的设计本质是把资深经济设计师的检查清单变成可重复、可追踪、可验收的工程化流程六阶段节奏清晰四领域清单完备输出模板即交付契约修复验证闭环保证问题闭环而只读合规与显式批准机制让它可以放心地高频运行。对任何以数据驱动平衡的 CCGS 项目而言它都是把 AI 会话组织成真工作室流程的关键一环。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考