Claude Code Game Studios -- 完整工作流指南¶
如何借助 Agent 架构，从零开始打造并发布一款游戏。
本指南将带你走完游戏开发的每个阶段，使用 49 个 Agent 组成的系统、73 个斜杠命令和 12 个自动化钩子。它假定你已经安装 Claude Code，并从项目根目录开始工作。
流水线共有 7 个阶段。每个阶段都有一个正式门禁（
/gate-check），必须通过后才能继续前进。权威的阶段顺序定义在.claude/docs/workflow-catalog.yaml中，并由/help读取。
目录¶
- 快速开始
- 阶段 1：概念
- 阶段 2：系统设计
- 阶段 3：技术设置
- 阶段 4：前期制作
- 阶段 5：正式制作
- 阶段 6：打磨
- 阶段 7：发布
- 横切关注点
- 附录 A：Agent 快速参考
- 附录 B：斜杠命令快速参考
- 附录 C：常见工作流
快速开始¶
你需要什么¶
在开始之前，请确保你已具备以下条件：
- Claude Code 已安装并可正常工作
- Git，以及 Git Bash（Windows）或标准终端（Mac/Linux）
- jq（可选，但推荐——如果缺失，钩子会回退到
grep） - Python 3（可选——部分钩子使用它进行 JSON 校验）
第 1 步：克隆并打开¶
第 2 步：运行 /start¶
如果这是你的首次会话：
这个引导式入门流程会询问你目前所处的位置，并将你路由到正确的阶段：
- 路径 A —— 还没有想法：路由到
/brainstorm - 路径 B —— 想法模糊：带种子信息路由到
/brainstorm - 路径 C —— 概念明确：路由到
/setup-engine和/map-systems - 路径 D1 —— 已有项目，几乎没有任何产物：正常运行流程
- 路径 D2 —— 已有项目，且存在 GDD/ADR：运行
/project-stage-detect，然后运行/adopt进行棕地迁移
第 3 步：验证钩子是否正常工作¶
启动一个新的 Claude Code 会话。你应该会看到来自 session-start.sh 钩子的输出：
=== Claude Code Game Studios -- Session Context ===
Branch: main
Recent commits:
abc1234 Initial commit
===================================
如果你看到了以上内容，说明钩子正常工作。如果没有，请检查 .claude/settings.json，确保钩子路径在你的操作系统上正确无误。
第 4 步：随时寻求帮助¶
在任何时候，运行：
它会从 project.yaml 中的 project.stage 读取你当前的阶段（回退到 production/stage.txt），检查哪些产物已经存在，并明确告诉你接下来该做什么。它会区分“必需”的下一步和“可选”的机会。
第 5 步：创建你的目录结构¶
目录会根据需要创建。系统期望的布局如下：
src/ # Game source code
core/ # Engine/framework code
gameplay/ # Gameplay systems
ai/ # AI systems
networking/ # Multiplayer code
ui/ # UI code
tools/ # Dev tools
assets/ # Game assets
art/ # Sprites, models, textures
audio/ # Music, SFX
vfx/ # Particle effects
shaders/ # Shader files
data/ # JSON config/balance data
design/ # Design documents
gdd/ # Game design documents
narrative/ # Story, lore, dialogue
levels/ # Level design documents
balance/ # Balance spreadsheets and data
ux/ # UX specifications
docs/ # Technical documentation
architecture/ # Architecture Decision Records
api/ # API documentation
postmortems/ # Post-mortems
tests/ # Test suites
prototypes/ # Throwaway prototypes
production/ # Sprint plans, milestones, releases
sprints/
milestones/
releases/
epics/ # Epic and story files (from /create-epics + /create-stories)
playtests/ # Playtest reports
session-state/ # Ephemeral session state (gitignored)
session-logs/ # Session audit trail (gitignored)
提示： 你不需要在第一天就创建所有这些目录。当你进入需要它们的阶段时再创建即可。重要的是在创建时遵循这个结构，因为规则系统会根据文件路径强制执行标准。
src/gameplay/下的代码会应用游戏玩法规则，src/ai/下的代码会应用 AI 规则，依此类推。
阶段 1：概念¶
本阶段会发生什么¶
你会从“没有想法”或“模糊想法”出发，最终形成一份结构化的游戏概念文档，其中包含明确的支柱（pillars）和玩家旅程。这个阶段就是要弄清楚你在做什么以及为什么做。
阶段 1 流水线¶
/brainstorm --> game-concept.md --> /design-review --> /setup-engine
| | |
v v v
10 concepts Concept doc with Validation Engine pinned in
MDA analysis pillars, MDA, of concept project.yaml
Player motiv. core loop, USP document
|
v
/prototype
(concept prototype — 1-3 days)
PROCEED ↓ PIVOT → /brainstorm
|
v (PROCEED)
/map-systems
|
v
systems-index.md
(all systems, deps,
priority tiers)
步骤 1.1：使用 /brainstorm 进行头脑风暴¶
这是你的起点。运行头脑风暴技能：
或加上类型提示：
效果： 头脑风暴技能将引导你完成为期 6 个阶段、基于专业工作室技巧的协作式构思流程：
- 询问你的兴趣、主题和约束条件
- 生成 10 个概念种子，并进行 MDA（机制、动态、美学）分析
- 你挑选 2-3 个最喜欢的概念做深入分析
- 进行玩家动机映射与受众定位
- 你选定胜出概念
- 将其正式写入
design/gdd/game-concept.md
概念文档包含：
- 电梯陈述（一句话）
- 核心幻想（玩家想象自己在做什么）
- MDA 拆解
- 目标受众（巴特尔玩家类型、人口统计特征）
- 核心循环图
- 独特卖点
- 对标作品与差异化
- 游戏支柱（3-5 项不可妥协的设计价值观）
- 反支柱（游戏有意避开的元素）
步骤 1.2：审查概念（可选但推荐）¶
在你继续之前，校验文档结构与完整性。
步骤 1.3：选择你的引擎¶
或指定具体引擎：
/setup-engine 会做什么：
- 将引擎、语言、专家、命名约定和性能预算写入
project.yaml（事实来源），并同步到.claude/docs/technical-preferences.md（人类可读的旧版回退文档） - 检测知识缺口（引擎版本新于 LLM 训练数据）并建议交叉参考
docs/engine-reference/ - 在
docs/engine-reference/中创建锁定版本的参考文档
为什么这很重要： 一旦你设置好引擎，系统就知道该使用哪些引擎专家代理。如果你选择 Godot，godot-specialist、godot-gdscript-specialist 和 godot-shader-specialist 等代理就会成为你的首选专家。
步骤 1.4：将概念拆解为系统¶
在编写各个 GDD 之前，先枚举你的游戏所需的全部系统：
这会创建 design/gdd/systems-index.md——一份主跟踪文档，用于：
- 列出你的游戏所需的所有系统（战斗、移动、UI 等）
- 绘制系统之间的依赖关系
- 分配优先级层级（MVP、Vertical Slice、Alpha、Full Vision）
- 确定设计顺序（Foundation > Core > Feature > Presentation > Polish）
在进入第二阶段之前，必须完成此步骤。对 155 款游戏复盘的研究证实，跳过系统枚举会让制作阶段的成本增加 5-10 倍。
第一阶段闸门¶
通过要求：
- 在
project.yaml中配置好引擎（engine.*） - 存在包含游戏支柱的
design/gdd/game-concept.md - 存在包含依赖顺序的
design/gdd/systems-index.md
结论： PASS / CONCERNS / FAIL。CONCERNS 可在已知风险下通过；FAIL 则会阻止继续推进。
第二阶段：系统设计¶
本阶段会发生什么¶
你将创建所有定义游戏运作方式的设计文档。此时还不会编写任何代码——这是纯设计阶段。系统索引中确定的每个系统都会有对应的 GDD，逐节编写、单独审查，然后对所有 GDD 进行一致性交叉检查。
第二阶段流程¶
/map-systems next --> /design-system --> /design-review
| | |
v v v
Picks next system Section-by-section Validates 8
from systems-index GDD authoring required sections
(incremental writes) APPROVED/NEEDS REVISION
|
| (repeat for each MVP system)
v
/review-all-gdds
|
v
Cross-GDD consistency + design theory review
PASS / CONCERNS / FAIL
步骤 2.1：编写系统 GDD¶
按照依赖顺序，使用引导式工作流设计每个系统：
这将选出优先级最高的未设计系统，并移交给 /design-system，由其引导你逐节创建该系统的 GDD。
你也可以直接指定某个系统进行设计：
/design-system 会做什么：
- 读取你的游戏概念、系统索引以及所有上游/下游 GDD
- 执行技术可行性预检（领域映射 + 可行性简报）
- 逐一引导你完成 8 个必需的 GDD 章节
- 每个章节遵循：背景 > 问题 > 选项 > 决策 > 草稿 > 批准 > 写入
- 每个章节在批准后立即写入文件（可抵御崩溃）
- 标记与已批准 GDD 之间的冲突
- 按类别路由到专家代理（systems-designer 负责数值，economy-designer 负责经济，narrative-director 负责剧情系统）
8 个必需的 GDD 章节：
| # | 章节 | 此处应包含 |
|---|---|---|
| 1 | 概览 | 系统的单段摘要 |
| 2 | 玩家幻想 | 玩家在使用此系统时想象/感受到的内容 |
| 3 | 详细规则 | 无歧义的机制规则 |
| 4 | 公式 | 所有计算，包含变量定义和取值范围 |
| 5 | 边界情况 | 在异常情况下会发生什么？需明确解决。 |
| 6 | 依赖关系 | 此系统连接的其他系统（双向） |
| 7 | 调优旋钮 | 设计师可以安全修改哪些数值，以及安全范围 |
| 8 | 验收标准 | 如何测试此系统有效？需要具体且可衡量。 |
此外还有一个游戏手感章节：手感参考、输入响应（毫秒/帧）、动画手感目标（启动/持续/恢复）、冲击时刻、重量配置。
步骤 2.2：审查每个 GDD¶
在开始下一个系统之前，先校验当前系统：
检查你的 modes.workflow 层级所要求的章节（full 为全部 8 个，standard 为 5 个），以确保内容完整、公式清晰、边界情况已解决、依赖关系双向明确，并具备可测试的验收标准。
结论： APPROVED / NEEDS REVISION / MAJOR REVISION。只有 APPROVED 的 GDD 才应继续推进。
步骤 2.3：无需完整 GDD 的小改动¶
对于调参类改动、小型增补或不值得撰写完整 GDD 的微调：
这会创建一份轻量级规格说明到 design/quick-specs/，而不是一份完整的 8 节 GDD。它适用于调参、数值改动和小型增补。
步骤 2.4：跨 GDD 一致性审查¶
在所有 MVP 系统 GDD 分别获批之后：
该命令会同时读取所有 GDD，并运行两个分析阶段：
阶段 1 —— 跨 GDD 一致性：
- 依赖双向性（A 引用 B，B 是否也引用 A？）
- 系统之间的规则矛盾
- 对已重命名或已移除系统的过期引用
- 所有权冲突（两个系统声称拥有同一职责）
- 公式取值范围兼容性（系统 A 的输出是否适配系统 B 的输入？）
- 验收标准交叉检查
阶段 2 —— 设计理论（游戏设计整体性）：
- 相互竞争的系统成长循环（两个系统是否在争夺同一奖励空间？）
- 认知负荷（是否同时有超过 4 个活跃系统？）
- 支配性策略（某一种做法让所有其他做法都变得无关紧要）
- 经济循环分析（产出与消耗是否平衡？）
- 跨系统的难度曲线一致性
- 设计支柱对齐与反支柱违规
- 玩家幻想一致性
输出： 生成带结论的 design/gdd/gdd-cross-review-[date].md。
步骤 2.5：叙事设计（如适用）¶
如果你的游戏包含故事、世界观或对话，那么就在这一阶段构建它们：
- 世界观构建（World-building） —— 使用
world-builder定义世界观中的阵营、历史、地理与规则 - 故事结构 —— 使用
narrative-director设计故事弧、角色弧与叙事节拍 - 角色表 —— 使用
narrative-character-sheet.md模板
阶段 2 门禁¶
通过要求：
systems-index.md中的所有 MVP 系统均为Status: Approved- 每个 MVP 系统都有一份已审查的 GDD
- 存在跨 GDD 审查报告（
design/gdd/gdd-cross-review-*.md），且结论为 PASS 或 CONCERNS（不能是 FAIL）
阶段 3：技术设置¶
本阶段内容¶
你要做出关键技术决策，将其记录为架构决策记录（ADR），通过审查进行验证，并产出一份控制清单（control manifest），为程序员提供扁平、可操作的规则。同时你还需要建立 UX 基础。
阶段 3 管线¶
/create-architecture --> /architecture-decision (x N) --> /architecture-review
| | |
v v v
Master architecture Per-decision ADRs Validates completeness,
document covering in docs/architecture/ dependency ordering,
all systems adr-*.md engine compatibility
|
v
/create-control-manifest
|
v
Flat programmer rules
docs/architecture/
control-manifest.md
Also in this phase:
-------------------
/ux-design --> /ux-review
Accessibility requirements doc
Interaction pattern library
步骤 3.1：总体架构文档¶
在 docs/architecture/architecture.md 中创建统领全局的架构文档，涵盖系统边界、数据流和集成点。
步骤 3.2：架构决策记录（ADR）¶
针对每一项重大技术决策：
流程说明： 该技能会引导你创建一份 ADR，其中包含：
- 背景与决策驱动因素
- 所有可选方案及其优缺点和引擎兼容性
- 所选方案及其理由
- 后果（正面、负面、风险）
- 依赖关系（Depends On、Enables、Blocks、Ordering Note）
- 所满足的 GDD 需求（通过 TR-ID 关联）
ADR 会经历一个生命周期：Proposed > Accepted > Superseded/Deprecated。
在门禁检查之前，至少需要 3 份 Foundation 层 ADR。
为既有 ADR 进行改造： 如果你是在既有项目（brownfield project）中已经有 ADR：
它会检测模板中缺失了哪些小节，并且只补充这些缺失部分，绝不会覆盖既有内容。
步骤 3.3：架构审查¶
将所有 ADR 放在一起校验：
- 对 ADR 依赖关系进行拓扑排序（检测循环依赖）
- 引擎兼容性验证
- GDD 修订标记（标出因 ADR 决策而需要更新的 GDD 小节）
- TR-ID 注册表维护（
docs/architecture/tr-registry.yaml）
步骤 3.4：控制清单（Control Manifest）¶
获取所有已接受（Accepted）的 ADR，并生成一份扁平的编程人员规则表：
其中包含按代码层组织的必需模式（Required patterns）、禁止模式（Forbidden patterns）和护栏（Guardrails）。之后创建的用户故事会嵌入清单版本日期，以便检测过期情况。
步骤 3.5：无障碍需求¶
使用模板创建 design/accessibility-requirements.md。承诺一个层级（Basic / Standard / Comprehensive / Exemplary），并填写四轴功能矩阵（视觉、运动、认知、听觉）。
该文档在阶段 3 中为必需项，因为阶段 4 撰写的 UX 规格会引用此层级——它是设计前置条件，而非 UX 交付物。
Phase 3 Gate¶
通过要求：
docs/architecture/architecture.md存在- 至少存在 3 个 ADR，且状态为 Accepted
- 架构审查报告存在
docs/architecture/control-manifest.md存在design/accessibility-requirements.md存在
第四阶段：前期制作¶
本阶段内容¶
你需要为关键界面编写 UX 规格，为高风险机制制作原型，将设计文档转化为可实现的 Story，规划你的第一个 Sprint，并构建一个垂直切片（Vertical Slice），证明核心循环是有趣的。
第四阶段流程¶
/ux-design --> /vertical-slice --> /create-epics --> /create-stories --> /sprint-plan
| | | | |
v v v v v
UX specs Production-quality Epic files in Story files in First sprint with
design/ux/ end-to-end build production/ production/ prioritized stories
in prototypes/ epics/*/EPIC.md epics/*/story-*.md production/sprints/
PROCEED/PIVOT/KILL (one per module) (one per behaviour) sprint-*.md
| |
v v
/ux-review /story-readiness
(validates specs (validates each story
before epics) before pickup)
|
v
/dev-story
(implements the story,
routes to right agent)
步骤 4.1：关键界面的 UX 规格¶
在编写 Epic 之前，先创建 UX 规格，以便 Story 作者知道存在哪些界面，以及他们必须支持哪些玩家交互。
UX 规格：
三种模式：屏幕/流程、HUD 和交互模式。输出存放在 design/ux/。每个规格包括：玩家需求、布局区域、状态、交互映射、数据需求、触发的事件、无障碍、本地化。
它会读取你在 Phase 3 编写的 accessibility-requirements.md，以及 project.yaml 中的输入方式配置（platform.* 块，回退到 technical-preferences.md），以驱动无障碍和输入覆盖检查——无需在每个界面中重新定义这些内容。
提示：
/design-system会为每个有 UI 需求的系统输出一个 📌 UX Flag。将这些 Flag 作为检查清单，确定哪些界面需要规格。
交互模式库：
创建 design/ux/interaction-patterns.md——包含 16 种标准控件以及游戏专属模式（物品栏槽位、技能图标、HUD 条、对话盒等），并附带动画和声音标准。
UX 审查：
验证 UX 规格是否与 GDD 对齐，以及是否符合无障碍层级要求。最终给出 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED 结论。
步骤 4.2：构建垂直切片¶
垂直切片是生产级质量的证明，表明你可以在全面投入 Production 之前端到端地构建完整游戏循环。
它证明的是什么： 一个玩家能否从零开始，在不需要开发人员引导的情况下，于几分钟内体验到核心愿景？
它构建的是什么： 一个接近生产质量的可玩构建，覆盖至少一个完整的 [开始 → 挑战 → 解决] 循环。使用真实的架构层、真实的命名规范，没有硬编码值——但不使用最终美术或音频。这不是像概念原型那样的一次性产物；它验证了生产管线的可行性。
关于概念原型的说明： 如果你在 Phase 1（概念）中运行过 /prototype，你已经验证了核心想法是有趣的。现在，垂直切片验证的是你能否正确地构建它。它们回答的是不同的问题。如果你跳过了概念原型，现在是在投入完整切片之前先运行一个的合理时机。
结论： 垂直切片会产生 PROCEED / PIVOT / KILL 结论。
- PROCEED → 进入步骤 4.3（Epic 和 Story）
- PIVOT → 使用
/design-system [mechanic]修改受影响的 GDD，然后重新运行/vertical-slice - KILL → 带着你学到的经验返回
/brainstorm
步骤 4.3：根据设计产物创建 Epic 和 Story¶
/create-epics layer: foundation
/create-stories [epic-slug] # repeat for each epic
/create-epics layer: core
/create-stories [epic-slug] # repeat for each core epic
/create-epics 会读取你的 GDD、ADR 和架构，以定义 Epic 范围——每个架构模块对应一个 Epic。然后，/create-stories 会将每个 Epic 分解为 production/epics/[slug]/ 下可实现的 Story 文件。每个 Story 都嵌入了：
- GDD 需求引用（TR-ID，而不是引用的文本——保持时效性）
- ADR 引用（仅引用 Accepted 状态的 ADR；Proposed 状态的 ADR 会导致
Status: Blocked） - 控件清单版本日期（用于过时检测）
- 引擎特定的实现说明
- 来自 GDD 的验收标准
一旦 Story 创建完成，运行 /dev-story [story-path] 来实现其中一个——它会自动路由到正确的程序员智能体。
步骤 4.4：在领取前验证 Story¶
检查项：设计完整性、架构覆盖、范围清晰度、完成定义。结论：READY / NEEDS WORK / BLOCKED。
步骤 4.5：工作量估算¶
提供带有风险评估的工作量估算。
步骤 4.6：规划你的第一个 Sprint¶
会发生什么： producer 智能体将协作进行 Sprint 规划：
- 询问冲刺目标和可用时间
- 将目标拆分为必须有 / 应该有 / 可以有的任务
- 识别风险和阻碍项
- 创建
production/sprints/sprint-01.md - 填充
production/sprint-status.yaml（机器可读的故事跟踪）
Step 4.7：纵向切片（硬性门禁）¶
在进入生产阶段之前，你必须构建并试玩一个纵向切片（Vertical Slice）：
- 一个完整的端到端核心循环，可从始至终游玩
- 具有代表性质量（而非全部占位内容）
- 在至少 3 次会话中无引导试玩
- 撰写试玩报告（
/playtest-report）
这是一个硬性门禁——如果人类没有在无引导情况下试玩该构建，/gate-check 将自动 FAIL。
Phase 4 Gate¶
通过要求：
- 至少 1 份 UX 规范已在
design/ux/中评审 - UX 评审已完成（APPROVED 或 NEEDS REVISION，且已记录风险）
- 至少 1 个带有 README 的原型
- 故事文件存在于
production/epics/[epic-slug]/ - 至少存在 1 个冲刺计划
- 至少存在 1 份试玩报告（纵向切片已在 3 次以上会话中试玩）
Phase 5：生产阶段¶
本阶段会发生什么¶
这是核心生产循环。你以冲刺（通常 1-2 周）为单位工作，逐故事实现功能、跟踪进度，并通过结构化的完成评审来收官故事。此阶段会持续重复，直到你的游戏内容完备。
第 5 阶段管线（每个冲刺）¶
/sprint-plan new --> /story-readiness --> implement --> /story-done
| | | |
v v v v
Sprint created Story validated Code written 8-phase review:
sprint-status.yaml READY verdict Tests pass verify criteria,
populated check deviations,
update story status
|
| (repeat per story until sprint complete)
v
/sprint-status (quick 30-line snapshot anytime)
/scope-check (if scope is growing)
/retrospective (at sprint end)
Step 5.1：故事生命周期¶
生产阶段以故事生命周期为核心：
1. 故事就绪检查： 在开始一个故事之前，先对其进行验证：
这会检查设计完整性、架构覆盖范围、ADR 状态（如果 ADR 仍为 Proposed 则阻止）、控制清单版本（有过期则警告）以及范围清晰度。判定：READY / NEEDS WORK / BLOCKED。
2. 实现： 与相应的代理协作：
gameplay-programmer：负责游戏玩法系统engine-programmer：负责核心引擎工作ai-programmer：负责 AI 行为network-programmer：负责多人游戏ui-programmer：负责 UI 代码tools-programmer：负责开发工具
所有代理都遵循协作协议：阅读设计文档、提出澄清问题、呈现架构选项、获得你的批准，然后实现。
3. 故事完成： 当一个故事完成时：
这将运行一个 8 阶段完成评审：
- 查找并阅读故事文件
- 加载所引用的 GDD、ADR 和控制清单
- 验证验收标准（可自动检查、手动、已延期）
- 检查 GDD/ADR 偏差（BLOCKING / ADVISORY / OUT OF SCOPE）
- 提示进行代码评审
- 生成完成报告（COMPLETE / COMPLETE WITH NOTES / BLOCKED）
- 将故事状态更新为
Status: Complete，并附上完成说明 - 展示下一个已就绪的故事
评审期间发现的技术债务会记录到 docs/tech-debt-register.md。
Step 5.2：冲刺跟踪¶
随时检查进度：
快速读取 production/sprint-status.yaml 的 30 行快照。
如果范围在扩大：
这将当前范围与原始计划进行比较，标记范围扩大，并建议削减。
Step 5.3：内容跟踪¶
将 GDD 规定的内容与已实现的内容进行比较，尽早发现内容缺口。
Step 5.4：设计变更传播¶
当故事创建之后 GDD 发生变更时：
对 GDD 执行 Git 差异比较，找出受影响的 ADR，生成影响报告，并引导你做出 Superseded / 更新 / 保留 决策。
Step 5.5：多系统功能（团队编排）¶
对于跨越多个域的功能，请使用团队技能：
/team-combat "healing ability with HoT and cleanse"
/team-narrative "Act 2 story content"
/team-ui "inventory screen redesign"
/team-level "forest dungeon level"
/team-audio "combat audio pass"
每个团队技能都会协调一个 6 阶段协作工作流：
- 设计——游戏设计师提出问题、呈现选项
- 架构——主程序员提出代码结构
- 并行实现——专家同时工作
- 集成——gameplay-programmer 将所有内容连接起来
- 验证——qa-tester 依据验收标准进行测试
- 报告——协调者总结状态
编排是自动化的，但决策点仍由你掌控。
Step 5.6：冲刺评审与下一个冲刺¶
在冲刺结束时：
分析计划与实际完成情况、速度、阻碍项以及可执行的改进项。
然后规划下一个冲刺：
Step 5.7：里程碑评审¶
在里程碑检查点：
生成功能完备度、质量指标、风险评估以及 go/no-go 建议。
Phase 5 Gate¶
通过要求：
- 所有 MVP 故事均已完成
- 试玩：3 次会话，覆盖新玩家、游戏中期和难度曲线
- 趣味假设已得到验证
- 试玩数据中没有困惑循环（confusion loops）
阶段 6：打磨¶
本阶段内容¶
你的游戏功能已经完整。现在你要让它变得更好。本阶段聚焦于性能、平衡性、无障碍支持、音频、视觉打磨和试玩测试。
阶段 6 流水线¶
/perf-profile --> /balance-check --> /asset-audit --> /playtest-report (x3)
| | | |
v v v v
Profile CPU/GPU Analyze formulas Verify naming, Cover: new player,
memory, optimize and data for formats, sizes mid-game, difficulty
bottlenecks broken progressions curve
/tech-debt --> /team-polish
| |
v v
Track and Coordinated pass:
prioritize performance + art +
debt items audio + UX + QA
步骤 6.1：性能剖析¶
引导你完成结构化的性能剖析：
- 设定目标（帧率、内存、平台）
- 按影响程度对性能瓶颈进行排序
- 生成可执行的优化任务，包含代码位置和预期收益
步骤 6.2：平衡性分析¶
分析平衡数据中的统计离群值、断裂的成长曲线、退化策略和经济失衡。
步骤 6.3：资源审计¶
验证所有资源的命名规范、文件格式标准和大小预算。
步骤 6.4：试玩测试（必选：3 次）{#step-64-playtesting-required-3-sessions}¶
生成结构化的试玩报告。需要三次测试，覆盖：
- 新玩家体验
- 中期系统
- 难度曲线
步骤 6.5：技术债务评估¶
扫描 TODO/FIXME/HACK 注释、代码重复、过于复杂的函数、缺失的测试和过时的依赖。每个条目都会进行分类和优先级排序。
步骤 6.6：协调式打磨环节¶
并行协调 4 名专家：
- 性能优化（performance-analyst）
- 视觉打磨（technical-artist）
- 音频打磨（sound-designer）
- 手感/Juice（gameplay-programmer + technical-artist）
由你设定优先级；团队在每一步都需经你批准后执行。
步骤 6.7：本地化与无障碍支持¶
扫描硬编码字符串、会破坏翻译的字符串拼接、未考虑文本扩展的情况，以及缺失的语言环境文件。
无障碍支持将根据阶段 3 的无障碍需求文档中所承诺的层级进行审计。
阶段 6 门禁¶
通过要求：
- 至少存在 3 份试玩测试报告
- 已完成协调式打磨环节（
/team-polish） - 没有阻塞性性能问题
- 满足无障碍层级要求
阶段 7：发布¶
本阶段内容¶
你的游戏已经打磨完毕、通过测试、准备就绪。现在正式发布它。
阶段 7 流水线¶
/release-checklist --> /launch-checklist --> /team-release
| | |
v v v
Pre-release Full cross-department Coordinate:
validation across validation (Go/No-Go build, QA sign-off,
code, content, per department) deployment, launch
store, legal
Also: /changelog, /patch-notes, /hotfix
步骤 7.1：发布清单¶
生成一份全面的发布前检查清单，涵盖：
- 构建验证（所有平台均可编译和运行）
- 认证要求（平台特定）
- 商店元数据（描述、截图、预告片）
- 法律合规（EULA、隐私政策、年龄分级）
- 存档兼容性
- 分析验证
步骤 7.2：发布就绪（全面验证）{#step-72-launch-readiness-full-validation}¶
跨部门全面验证：
| 部门 | 检查内容 |
|---|---|
| 工程 | 构建稳定性、崩溃率、内存泄漏、加载时间 |
| 设计 | 功能完整性、教程流程、难度曲线 |
| 美术 | 资源质量、缺失纹理、LOD 级别 |
| 音频 | 缺失音效、混音电平、空间音频 |
| QA | 按严重程度统计的未关闭缺陷数、回归测试套件通过率 |
| 叙事 | 对话完整性、世界观一致性、错别字 |
| 本地化 | 所有字符串均已翻译、无截断、语言环境测试 |
| 无障碍支持 | 合规检查清单、辅助功能测试 |
| 商店 | 元数据完整、截图已批准、定价已设定 |
| 市场营销 | 媒体资料包就绪、发布预告片、社交媒体已排期 |
| 社区 | 补丁说明草稿、FAQ 已准备、支持渠道就绪 |
| 基础设施 | 服务器已扩容、CDN 已配置、监控已启用 |
| 法律 | EULA 已定稿、隐私政策、COPPA/GDPR 合规 |
每个条目都会获得通过（Go）/不通过（No-Go）状态。所有条目都必须为"通过（Go）"才能发布。
步骤 7.3：生成面向玩家的内容¶
根据 git 历史和冲刺数据生成玩家友好的补丁说明。将开发者语言转换为玩家语言。
生成内部变更日志（更偏技术性，供团队使用）。
步骤 7.4：协调发布¶
协调 release-manager、QA 和 DevOps，完成以下工作：
- 发布前验证
- 构建管理
- QA 最终签核
- 部署准备
- 通过/不通过（Go/No-Go）决策
步骤 7.5：发布¶
validate-push 钩子会在你推送到 main 或 develop 分支时发出警告。这是有意为之——发布推送应该是深思熟虑的：
步骤 7.6：发布后¶
针对关键生产缺陷的热修复流程：
绕过常规冲刺流程，同时保留完整的审计跟踪：
- 创建热修复分支
- 实施修复
- 确保回移植到开发分支
- 记录事件
复盘（发布稳定后）：
横切关注点¶
这些主题适用于所有阶段。
总监评审模式¶
总监门禁（Director gates）是专业智能体，会在关键工作流步骤审查你的工作。 默认情况下，它们会在每个检查点运行。你可以控制获得多少审查。
在 /start 过程中设置一次你的评审强度。 保存到 project.yaml 中的 modes.review_mode（并镜像到 production/review-mode.txt 作为旧版回退）。
| 模式 | 运行内容 | 最适合 |
|---|---|---|
full |
每一步都运行所有总监门禁 | 新项目、学习本系统 |
lean |
仅在阶段转换时运行总监门禁（/gate-check） |
经验丰富的开发者 |
solo |
不运行总监评审 | Game Jam、原型、追求最快速度 |
在单次运行中覆盖设置，无需更改全局设置：
--review 标志适用于所有使用门禁的技能。你可以随时通过编辑 project.yaml 中的 modes.review_mode 或重新运行 /start 来更改全局模式。
完整门禁定义和检查模式：.claude/docs/director-gates.md
协作协议¶
本系统是用户驱动的协作，而非自主运行。
模式： 提问 > 选项 > 决策 > 草稿 > 批准
每次智能体交互都遵循此模式：
- 智能体提出澄清性问题
- 智能体提供 2-4 个选项，并说明权衡与理由
- 你来决策
- 智能体根据你的决策起草方案
- 你进行审查和优化
- 智能体在写入前会询问“我可以将其写入 [filepath] 吗？”
完整协议及示例请参阅 docs/COLLABORATIVE-DESIGN-PRINCIPLE.md。
AskUserQuestion 工具¶
智能体使用 AskUserQuestion 工具进行结构化选项呈现。
模式是“先解释后捕获”：先在对话文本中给出完整分析，然后使用简洁的 UI 选择器进行决策。将其用于设计选择、架构决策和战略性问题。不要将其用于开放式探索性问题或简单的是/否确认。
智能体协调（三层层级结构）¶
Tier 1 (Directors): creative-director, technical-director, producer
|
Tier 2 (Leads): game-designer, lead-programmer, art-director,
audio-director, narrative-director, qa-lead,
release-manager, localization-lead
|
Tier 3 (Specialists): gameplay-programmer, engine-programmer,
ai-programmer, network-programmer, ui-programmer,
tools-programmer, systems-designer, level-designer,
economy-designer, world-builder, writer,
technical-artist, sound-designer, ux-designer,
qa-tester, performance-analyst, devops-engineer,
analytics-engineer, accessibility-specialist,
live-ops-designer, prototyper, security-engineer,
community-manager, godot-specialist,
godot-gdscript-specialist, godot-shader-specialist,
godot-csharp-specialist, godot-gdextension-specialist,
unity-specialist, unity-dots-specialist,
unity-shader-specialist, unity-addressables-specialist,
unity-ui-specialist, unreal-specialist,
ue-blueprint-specialist, ue-gas-specialist,
ue-replication-specialist, ue-umg-specialist
协调规则：
- 垂直委派：总监（Directors）> 主管（Leads）> 专家（Specialists）。涉及复杂决策时切勿跳级。
- 水平咨询：同一层级的智能体可以相互咨询，但不得在其领域之外做出具有约束力的决策。
- 冲突解决：设计冲突提交给
creative-director。技术冲突提交给technical-director。范围冲突提交给producer。 - 不得单方面进行跨领域更改。
自动化钩子（安全网）¶
系统有 12 个自动运行的钩子：
| 钩子 | 触发时机 | 作用 |
|---|---|---|
session-start.sh |
会话启动 | 显示分支、最近的提交，检测 active.md 以进行恢复 |
detect-gaps.sh |
会话启动 | 检测全新项目（没有引擎、没有概念）并建议运行 /start |
pre-compact.sh |
压缩前 | 将会话状态转储到对话中，用于自动恢复 |
post-compact.sh |
压缩后 | 提醒 Claude 从 active.md 恢复会话状态 |
notify.sh |
通知事件 | 通过 PowerShell 显示 Windows 通知（toast） |
validate-commit.sh |
提交前 | 检查设计文档引用、JSON 是否有效、是否存在硬编码值 |
validate-push.sh |
推送前 | 在推送到 main/develop 分支时发出警告 |
validate-assets.sh |
提交前 | 检查资源命名和大小 |
validate-skill-change.sh |
写入技能文件时 | 建议在 .claude/skills/ 变更后运行 /skill-test |
log-agent.sh |
智能体启动 | 记录智能体调用以形成审计追踪 |
log-agent-stop.sh |
智能体停止 | 补全智能体审计追踪（启动 + 停止） |
session-stop.sh |
每次响应结束时 | 会话日志和子智能体生成计数。尽管名称如此，它在每次响应时触发一次，而非每个会话一次。 |
上下文韧性¶
会话状态文件： production/session-state/active.md 是一个动态检查点。在完成每个重要里程碑后更新它。发生任何中断（压缩、崩溃、/clear）后，请先读取此文件。
增量写入： 创建多章节文档时，在每节获得批准后立即写入文件。这意味着已完成的章节能够在崩溃和上下文压缩后保留下来。关于已写入章节的先前讨论可以安全地被压缩。
自动恢复： session-start.sh 钩子会自动检测并预览 active.md。pre-compact.sh 钩子会在压缩前将状态转储到对话中。
Sprint 状态跟踪：production/sprint-status.yaml 是机器可读的故事追踪器。由 /sprint-plan（初始化）和 /story-done（状态更新）写入。由 /sprint-status、/help 和 /story-done（下一个故事）读取。消除了脆弱的 Markdown 扫描。
既有项目采用¶
对于已经拥有部分工件的现有项目：
或定向采用：
这会审计现有工件的格式（而非是否存在），将差距分类为 BLOCKING/HIGH/MEDIUM/LOW，构建有序的迁移计划，并写入 docs/adoption-plan-[date].md。核心原则：迁移而非替换——它从不重新生成已有工作，只填补缺口。
单个技能也支持改造模式：
/design-system retrofit design/gdd/combat-system.md
/architecture-decision retrofit docs/architecture/adr-005.md
这些命令会检测哪些章节存在、哪些缺失，并只填补缺口。
门禁系统¶
阶段门禁是正式的检查点。使用转换名称运行 /gate-check：
/gate-check concept # Concept -> Systems Design
/gate-check systems-design # Systems Design -> Technical Setup
/gate-check technical-setup # Technical Setup -> Pre-Production
/gate-check pre-production # Pre-Production -> Production
/gate-check production # Production -> Polish
/gate-check polish # Polish -> Release
判定：
- PASS —— 所有要求均已满足，进入下一阶段
- CONCERNS —— 要求已满足但存在已确认的风险，可通过
- FAIL —— 要求未满足，阻止推进并附带具体整改措施
当门禁通过时，project.yaml 中的 project.stage 才会被更新——并镜像到 production/stage.txt——这控制着状态行和 /help 行为。
逆向文档¶
对于没有设计文档的已有代码（在既有项目采用后很常见）：
读取现有代码并从中生成 GDD 格式的设计文档。
附录 A：代理快速参考¶
“我需要做 X——该使用哪个代理？”¶
| 我需要… | 代理 | 级别 |
|---|---|---|
| 构思一个游戏创意 | /brainstorm 技能 |
-- |
| 设计一个游戏机制 | game-designer |
2 |
| 设计具体的公式/数值 | systems-designer |
3 |
| 设计一个游戏关卡 | level-designer |
3 |
| 设计掉落表 / 经济系统 | economy-designer |
3 |
| 构建世界观设定 | world-builder |
3 |
| 编写对话 | writer |
3 |
| 规划故事剧情 | narrative-director |
2 |
| 规划一个 Sprint | producer |
1 |
| 做出创意决策 | creative-director |
1 |
| 做出技术决策 | technical-director |
1 |
| 实现游戏玩法代码 | gameplay-programmer |
3 |
| 实现核心引擎系统 | engine-programmer |
3 |
| 实现 AI 行为 | ai-programmer |
3 |
| 实现多人游戏 | network-programmer |
3 |
| 实现 UI | ui-programmer |
3 |
| 构建开发工具 | tools-programmer |
3 |
| 审查代码架构 | lead-programmer |
2 |
| 创建着色器 / VFX | technical-artist |
3 |
| 定义视觉风格 | art-director |
2 |
| 定义音频风格 | audio-director |
2 |
| 设计音效 | sound-designer |
3 |
| 设计 UX 流程 | ux-designer |
3 |
| 编写测试用例 | qa-tester |
3 |
| 规划测试策略 | qa-lead |
2 |
| 分析性能 | performance-analyst |
3 |
| 搭建 CI/CD | devops-engineer |
3 |
| 设计数据分析 | analytics-engineer |
3 |
| 检查无障碍性 | accessibility-specialist |
3 |
| 规划游戏运营 | live-ops-designer |
3 |
| 管理版本发布 | release-manager |
2 |
| 管理本地化 | localization-lead |
2 |
| 快速原型验证 | prototyper |
3 |
| 审计安全性 | security-engineer |
3 |
| 与玩家沟通 | community-manager |
3 |
| Godot 专项帮助 | godot-specialist |
3 |
| GDScript 专项帮助 | godot-gdscript-specialist |
3 |
| Godot 着色器帮助 | godot-shader-specialist |
3 |
| GDExtension 模块 | godot-gdextension-specialist |
3 |
| Unity 专项帮助 | unity-specialist |
3 |
| Unity DOTS/ECS | unity-dots-specialist |
3 |
| Unity 着色器/VFX | unity-shader-specialist |
3 |
| Unity Addressables | unity-addressables-specialist |
3 |
| Unity UI Toolkit | unity-ui-specialist |
3 |
| Unreal 专项帮助 | unreal-specialist |
3 |
| Unreal GAS | ue-gas-specialist |
3 |
| Unreal Blueprints | ue-blueprint-specialist |
3 |
| Unreal 复制 | ue-replication-specialist |
3 |
| Unreal UMG/CommonUI | ue-umg-specialist |
3 |
代理层级¶
creative-director / technical-director / producer
|
---------------------------------------------------------------
| | | | | | |
game-designer lead-prog art-dir audio-dir narr-dir qa-lead release-mgr
| | | | | | |
specialists programmers tech-art snd-design writer qa-tester devops
(systems, (gameplay, (sound) (world- (perf, (analytics,
economy, engine, builder) access.) security)
level) ai, net,
ui, tools)
升级规则： 如果两个代理意见不一致，就向上升级。设计冲突交由 creative-director。技术冲突交由 technical-director。范围冲突交由 producer。
附录 B：斜杠命令快速参考¶
全部 73 条命令（按类别）¶
入门与导航（6）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/start |
有引导的入门流程，路由到正确的工作流 | 任何（首次会话） |
/help |
上下文感知的“接下来我该做什么？” | 任何 |
/project-stage-detect |
完整项目审计，确定当前阶段 | 任何 |
/setup-engine |
配置引擎，固定版本，设置偏好 | 1 |
/adopt |
遗留项目审计与迁移计划 | 任意（现有项目） |
/skill-improve |
通过测试-修复-重测循环改进技能 | 任意 |
游戏设计（6）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/brainstorm |
协作构思，附带 MDA 分析 | 1 |
/map-systems |
将概念分解为系统索引 | 1-2 |
/design-system |
引导式逐章节 GDD 撰写 | 2 |
/quick-design |
小型变更的轻量级规格 | 2+ |
/review-all-gdds |
跨 GDD 一致性与设计理论评审 | 2 |
/propagate-design-change |
查找受 GDD 变更影响的 ADR/故事 | 5 |
UX 与界面（2）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/ux-design |
撰写 UX 规格（界面/流程、HUD、模式） | 4 |
/ux-review |
验证 UX 规格的无障碍性与 GDD 对齐 | 4 |
架构（4）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/create-architecture |
架构主文档 | 3 |
/architecture-decision |
创建或改造 ADR | 3 |
/architecture-review |
验证所有 ADR 及依赖顺序 | 3 |
/create-control-manifest |
从已接受的 ADR 生成扁平化程序员规则 | 3 |
故事与冲刺（8）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/create-epics |
将 GDD 和 ADR 转化为史诗（每个模块一个） | 4 |
/create-stories |
将单个史诗拆分为故事文件 | 4 |
/dev-story |
实现一个故事——路由到正确的程序员代理 | 5 |
/sprint-plan |
创建或管理冲刺计划 | 4-5 |
/sprint-status |
快速 30 行冲刺快照 | 5 |
/story-readiness |
验证故事已具备实施就绪条件 | 4-5 |
/story-done |
8 阶段故事完成评审 | 5 |
/estimate |
带风险评估的工作量估算 | 4-5 |
评审与分析（13）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/design-review |
按 8 节标准验证 GDD | 1-2 |
/code-review |
架构性代码评审 | 5+ |
/balance-check |
游戏平衡公式分析 | 5-6 |
/asset-audit |
资源命名、格式、大小验证 | 6 |
/asset-spec |
逐资源的视觉规格与 AI 生成提示词 | 5-6 |
/content-audit |
GDD 指定内容与已实现内容对照 | 5 |
/consistency-check |
跨 GDD 实体与公式不一致性扫描 | 2+ |
/scope-check |
范围蔓延检测 | 5 |
/perf-profile |
性能剖析工作流 | 6 |
/tech-debt |
技术债务扫描与优先级排序 | 6 |
/gate-check |
正式阶段门禁（通过/关注/失败） | 所有阶段转换 |
/reverse-document |
从现有代码生成设计文档 | 任意 |
/security-audit |
安全漏洞审计（存档、网络、输入） | 6-7 |
QA 与测试（9）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/qa-plan |
为冲刺或功能生成 QA 测试计划 | 5 |
/smoke-check |
QA 交接前的关键路径冒烟测试门禁 | 5-6 |
/soak-test |
长时间游玩会话的浸泡测试协议 | 6 |
/regression-suite |
映射测试覆盖率，识别缺少回归测试的已修复缺陷 | 5-6 |
/test-setup |
搭建测试框架与 CI/CD 流水线 | 4 |
/test-helpers |
生成引擎特定的测试辅助库 | 4-5 |
/test-evidence-review |
测试文件与人工证据的质量评审 | 5 |
/test-flakiness |
从 CI 日志中检测非确定性测试 | 5-6 |
/skill-test |
验证技能文件的结构与行为正确性 | 任意 |
生产管理（6）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/milestone-review |
里程碑进度与 go/no-go 决策 | 5 |
/retrospective |
冲刺回顾分析 | 5 |
/bug-report |
结构化缺陷报告创建 | 5+ |
/bug-triage |
重新评估未关闭缺陷的优先级、严重性与负责人 | 5+ |
/playtest-report |
结构化试玩会话报告 | 4-6 |
/onboard |
新团队成员入职引导 | 任意 |
发布（6）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/release-checklist |
发布前验证 | 7 |
/launch-checklist |
跨部门全面启动就绪检查 | 7 |
/changelog |
自动生成内部变更日志 | 7 |
/patch-notes |
面向玩家的补丁说明 | 7 |
/hotfix |
紧急修复工作流 | 7+ |
/day-one-patch |
针对黄金母盘后发现问题的小范围补丁 | 7+ |
创意（4）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/prototype |
概念原型——在编写 GDD 前验证核心创意 | 1 |
/art-bible |
引导式 Art Bible 撰写——视觉标识规格 | 1-2 |
/vertical-slice |
进入生产阶段前的生产品质端到端构建 | 4 |
/localize |
字符串提取与验证 | 6-7 |
团队编排（9）¶
| 命令 | 用途 | 阶段 |
|---|---|---|
/team-combat |
战斗功能：从设计到实现 | 5 |
/team-narrative |
叙事内容：从结构到对话 | 5 |
/team-ui |
UI 功能：从 UX 规格到精修后的实现 | 5 |
/team-level |
关卡：从布局到装饰完备的遭遇战 | 5 |
/team-audio |
音频：从方向设定到已实现的事件 | 5-6 |
/team-polish |
协调打磨：性能 + 美术 + 音频 + QA | 6 |
/team-release |
发布协调：构建 + QA + 部署 | 7 |
/team-live-ops |
实时运营规划：季节活动、战斗通行证、留存 | 7+ |
/team-qa |
完整 QA 周期：策略、执行、覆盖率、签核 | 6-7 |
附录 C：常见工作流¶
工作流 1：“我刚开始且没有任何游戏创意”¶
1. /start (routes you based on where you are)
2. /brainstorm (collaborative ideation, pick a concept)
3. /setup-engine (pin engine and version)
4. /design-review on concept doc (optional, recommended)
5. /map-systems (decompose concept into systems with deps and priorities)
6. /gate-check concept (verify you're ready for Systems Design)
7. /design-system per system (guided GDD authoring)
工作流 2：“我有设计方案，想要开始写代码”¶
1. /design-review on each GDD (make sure they're solid)
2. /review-all-gdds (cross-GDD consistency)
3. /gate-check systems-design
4. /create-architecture + /architecture-decision (per major decision)
5. /architecture-review
6. /create-control-manifest
7. /gate-check technical-setup
8. /create-epics layer: foundation + /create-stories [slug] (define epics, break into stories)
9. /sprint-plan new
10. /story-readiness -> implement -> /story-done (story lifecycle)
工作流 3：“我需要在制作中期添加一个复杂功能”¶
1. /design-system or /quick-design (depending on scope)
2. /design-review to validate
3. /propagate-design-change if modifying existing GDDs
4. /estimate for effort and risk
5. /team-combat, /team-narrative, /team-ui, etc. (appropriate team skill)
6. /story-done when complete
7. /balance-check if it affects game balance
工作流 4：“制作过程中出了问题”¶
1. /hotfix "description of the issue"
2. Fix is implemented on hotfix branch
3. /code-review the fix
4. Run tests
5. /release-checklist for hotfix build
6. Deploy and backport
工作流 5：“我有一个现有项目，想使用这套系统”¶
1. /start (choose Path D -- existing work)
2. /project-stage-detect (determines current phase)
3. /adopt (audits existing artifacts, builds migration plan)
4. /design-system retrofit [path] (fill GDD gaps)
5. /architecture-decision retrofit [path] (fill ADR gaps)
6. /gate-check at appropriate transition
工作流 6：“开始一个新的 Sprint”¶
1. /retrospective (review last sprint)
2. /sprint-plan new (create next sprint)
3. /scope-check (ensure scope is manageable)
4. /story-readiness per story before pickup
5. Implement stories
6. /story-done per completed story
7. /sprint-status for quick progress checks
工作流 7：“发布游戏”¶
1. /gate-check polish (verify Polish phase is complete)
2. /tech-debt (decide what's acceptable at launch)
3. /localize (final localization pass)
4. /release-checklist v1.0.0
5. /launch-checklist (full cross-department validation)
6. /team-release (coordinate the release)
7. /patch-notes and /changelog
8. Ship!
9. /hotfix if anything breaks post-launch
10. Post-mortem after launch stabilizes
工作流 8：“我迷失了方向 / 不知道下一步该做什么”¶
1. /help (reads your phase, checks artifacts, tells you what's next)
2. If /help doesn't help: /project-stage-detect (full audit)
3. If stage seems wrong: /gate-check at the transition you think you're at
充分利用本系统的技巧¶
-
始终先设计，再实现。智能体系统建立在“先有设计文档，后有代码”的假设之上。智能体会持续引用 GDD。
-
使用团队技能处理跨领域功能。不要试图自己手动协调 4 个智能体——让
/team-combat、/team-narrative等命令来处理编排工作。 -
信任规则系统。当规则在你的代码中标出问题时，就去修复它。规则中编码了来之不易的游戏开发智慧（数据驱动的数值、delta time、可访问性等）。
-
主动压缩上下文。当上下文使用量达到约 65-70% 时，执行 compact 或使用
/clear。预压缩钩子会保存你的进度。不要等到达到上限再行动。 -
使用正确层级的智能体。不要要求
creative-director编写 shader，也不要要求qa-tester做设计决策。这个层级结构的存在自有其道理。 -
不确定时运行 /help。它会读取你的实际项目状态，并告诉你最重要的下一步该做什么。
-
在把设计交给程序员之前，先运行
/design-review。这样可以及早发现不完整的规格，避免返工。 -
在每个主要功能完成后运行
/code-review。及早发现架构问题，避免其扩散。 -
先为高风险机制制作原型。一天的原型验证，可以为一个行不通的机制节省一周的制作时间。
-
保持 Sprint 计划切合实际。定期使用
/scope-check。范围蔓延是独立游戏的头号杀手。 -
使用 ADR 记录决策。未来的你会感谢现在的你，因为你记录下了事情为什么要这样构建。
-
严格遵守 story 生命周期。领取前运行
/story-readiness，完成后运行/story-done。这样可以及早发现偏差，并确保流程真实可信。 -
及早并频繁地写入文件。增量式分节写入意味着你的设计决策能在崩溃和上下文压缩中幸存。文件才是记忆，而不是对话。
本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 cl/Claude-Code-Game-Studios