企业官网建设流程全解析

Claude-Code-Game-Studios 协作会话示例指南：从设计到发布的端到端 Agent 工作流实战

【免费下载链接】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

导读

本文以 docs/examples/README.md 为骨架，系统讲解 Claude-Code-Game-Studios 项目中 49 个 AI Agent 与 72 个工作流技能如何在真实会话中以协作顾问模式驱动游戏开发全流程：从概念、系统设计、技术搭建、预制作、生产、打磨到发布。你将读到 7 类共 9 个完整会话实录的核心脉络（GDD 撰写、故事生命周期、阶段门禁、UX 管线、存量项目接管、战斗实现、范围危机决策），掌握 "Question → Options → Decision → Draft → Approval" 协作协议，并看到这些行为如何落到 协作设计原则、技能定义文件（gate-check.md 等）与 catalog.yaml 的具体实现上。

一、示例目录在项目中的定位

docs/examples/是项目的会话实录库：它不像技能定义那样描述"应该怎么做"，而是展示"真实做出来长什么样"。目录入口文档 docs/examples/README.md 将全部示例按用途分为三类：

所有示例共享同一个协作模式，这正是整个项目区别于"让 AI 全自动写游戏"的关键。

二、贯穿所有会话的协作协议

2.1 统一模式：Question → Options → Decision → Draft → Approval

项目对 Agent 行为的核心要求记录在 docs/COLLABORATIVE-DESIGN-PRINCIPLE.md，其核心哲学是USER-DRIVEN COLLABORATION（用户驱动的协作），而非自主生成：

Agent = Expert Consultant（专家顾问） User = Creative Director（最终决策者） Agents: - Ask clarifying questions（先提问澄清） - Research and present options（调研并给出选项） - Explain trade-offs and reasoning（解释取舍与理由） - Draft proposals for review（起草方案供审阅） - Wait for user approval before writing（写文件前等用户批准） Users: - Make all creative and strategic decisions（做所有创意与战略决策） - Approve or reject agent suggestions（批准或否决建议） - Direct the design vision（把控设计愿景） - Sign off before anything is written to files（写文件前签字放行）

会话示例中的关键时刻几乎一一对应这五步。以 session-design-crafting-system.md 为例，12 个回合的节奏是：Turn 2 问 5 个澄清问题 → Turn 4 给出 3 个带优缺点的方案 → Turn 5 用户修改推荐方案 → Turn 6-9 逐节起草与确认 → Turn 10-12 请求许可后才写文件。

2.2 会话文本 vs. 结构化选择器

README 特别提醒：示例为了可读性以对话文本呈现协作模式，但实际运行中 Agent 在决策点使用AskUserQuestion工具呈现结构化选项选择器（带 label、description、多选），其模式是Explain → Capture：先在对话里解释分析，再用结构化 UI 让用户做决定。这一实现可以在技能定义文件中找到证据，例如团队技能 team-ui.md、team-combat.md 等 9 个技能文件都包含AskUserQuestion相关逻辑，阶段门禁技能 gate-check.md 中也要求"等待用户输入后才最终定稿判定"。

2.3 五类协作行为

三、技能链总览：零到发布的 7 个阶段

skill-flow-diagrams.md 提供了整条管线的"地图"，其关键链路如下（完整 ASCII 图见原文档）：

PHASE 1 CONCEPT /start → /brainstorm → /setup-engine → /design-review → /gate-check PHASE 2 SYSTEMS /map-systems → /design-system [name] ×N → /review-all-gdds → /gate-check PHASE 3 TECHNICAL /create-architecture → /architecture-decision ×N → /architecture-review → /create-control-manifest → /gate-check PHASE 4 PRE-PROD /ux-design → /ux-review ｜ /test-setup → /test-helpers → /create-epics → /create-stories → /prototype → /sprint-plan new → /gate-check PHASE 5 PRODUCTION /sprint-status → /story-readiness → /dev-story → /story-done ＋ QA 循环（/qa-plan → /smoke-check → /regression-suite ...）→ /gate-check PHASE 6 POLISH /perf-profile → /balance-check → /asset-audit → /tech-debt → /soak-test → /localize → /team-polish → /team-qa → /gate-check PHASE 7 RELEASE /launch-checklist → /release-checklist → /changelog → /patch-notes → /team-release →（上线后）/hotfix → /team-live-ops

3.1 图解符号约定

3.2 按当前位置选择入口技能

四、核心流程示例详解

4.1 GDD 撰写：/design-system（约 60 分钟，14 回合）

session-design-system-skill.md 展示了技能驱动的系统设计：开发者在/map-systems产出 systems-index 后运行/design-system movement，Agent 从游戏概念与依赖 GDD 加载上下文，先做技术可行性预检，再逐节推进 8 个 GDD 章节。

开场即展示预检价值：Agent 在动笔前给出可行性表——Godot 4.6 的CharacterBody2D + move_and_slide()对 2D 移动完全支持；同时指出4.6 中 Jolt 成为默认物理引擎，2D 移动不受影响但需为未来 3D 工作记录；并且发现下游依赖（耐力系统）要求移动系统暴露耐力回调钩子。

8 个必需章节按固定顺序逐个处理：

Overview → Player Fantasy → Detailed Rules → Formulas → Edge Cases → Dependencies → Tuning Knobs → Acceptance Criteria

每节流程均为question → options → decision → draft → approval → WRITE，一节获批立即写盘再进入下一节。示例中有三处值得注意的实战细节：

• 增量写盘 + 崩溃恢复：第 5 节时会话崩溃，Agent 重启后重读文件，从第一个空节继续——崩溃最多丢失一个进行中的小节。
• 依赖信号契约：Dependencies 节中 Agent 主动暴露下游契约——耐力系统需on_stamina_event(type: String, amount: float)信号，背包系统监听carrying_heavy_object_changed(is_heavy: bool)信号。
• 可调旋钮落地：Tuning Knobs 节给出带默认值的参数表（base_walk_speed=120 px/s、run_multiplier=1.7、四种地形的速度/消耗倍率、stamina_drain_walk/run、stamina_cost_roll），并要求"所有移动数值来自导出变量，代码零硬编码"。

结束时 Agent 给出推荐下一步：先运行/design-review design/gdd/movement-system.md再进入下一个依赖顺序中的系统（耐力）。

4.2 故事全生命周期：/story-readiness → 实现 → /story-done（约 50 分钟，13 回合）

session-story-lifecycle.md 完整走通"积压 → 实现 → 关闭"闭环，三个关键机制值得展开：

1）就绪检查的 4 项验证：/story-readiness对 STORY-MOV-001 做设计完备性（GDD 章节覆盖、TR-ID 嵌入）、架构完备性（ADR 被引用且状态为 Accepted、控制清单版本一致）、范围清晰性（9 条验收标准可测量、列出范围外项、发现歧义）、完成定义（单元测试 + 信号集成）检查。第 2 回合发现滚动方向歧义——故事写"滚动方向跟随最后输入方向"，GDD 写"向移动方向滚动"，在站立即滚的边界场景冲突。用户 Turn 3 裁决"站立时用面朝方向"，故事随即被标记ready-for-dev。

2）硬门禁规则：如果 ADR 状态仍是 Proposed 而非 Accepted，故事直接判BLOCKED且不进入实现；控制清单版本不匹配则说明故事指导已与当前架构漂移。这些规则可在技能定义（如 story-readiness.md、story-done.md）中交叉印证。

3）COMPLETE WITH NOTES vs. BLOCKED：/story-done对 9 条验收标准逐条核验（AUTO=自动化测试证明、MANUAL=人工确认、DEFERRED=因集成未就绪延迟）。背包重物禁用跑步、耐力信号集成测试两条因"背包/耐力尚未集成"标为DEFERRED 而非 BLOCKED——完成报告为COMPLETE WITH NOTES，延迟项被记录并自动在对应集成故事中重新浮现，而不是阻塞当前故事关闭。关闭时production/sprint-status.yaml被更新为done，下一个就绪故事（STORY-MOV-002 耐力系统）自动浮出。

4.3 阶段门禁与阶段切换：/gate-check（约 20 分钟，7 回合）

session-gate-check-phase-transition.md 演示系统设计阶段→技术搭建阶段的切换。/gate-check不是"文件存在性检查"，而是工件存在 + 内部完备性双重校验：

• 6 个 MVP GDD 逐一扫描8 个必需章节的缺失情况（本示例全部无缺失）；
• 每份 GDD 的/design-review评论须存在；
• 跨 GDD 评审报告存在且判定为 PASS 或 CONCERNS（非 FAIL）。

示例展示了CONCERNS ≠ FAIL的核心语义：跨评审发现"工艺与背包各自独立定义堆叠上限（99 vs 64）"这一LOW 级问题，门禁判定仍为PASS，但要求该问题在技术搭建阶段转化为具体 ADR 而不是丢失。用户确认后production/stage.txt更新为technical-setup。

为什么 stage.txt 是权威：技能定义 gate-check.md 明确其"管辖全部 6 次阶段切换"，包含判定关键词 PASS/CONCERNS/FAIL、"May I updateproduction/stage.txt"的询问要求、以及 FAIL 时不写 stage.txt 的约束。stage.txt 更新后，/help、/sprint-status以及所有技能看到的阶段上下文全部随之改变。同时，门禁不会自动推进——每个门都需要用户显式确认（"Yes, advance it"）。

切换后 Agent 给出具体且有序的下阶段清单：/create-architecture→/architecture-decision（含跨评审遗留的堆叠上限问题）→/architecture-review→/create-control-manifest→ 下一次/gate-check，并建议用 ADR 快速关闭遗留问题（Turn 6 还示范了"库存拥有 vs. 共享 ItemData 资源"两种 ADR 方案的取舍分析）。

4.4 UX 管线：/ux-design → /ux-review → /team-ui（约 90 分钟，16 回合）

session-ux-pipeline.md 分三部分展示 UX 设计→评审→实现交接：

HUD 设计以玩家情感状态为锚：/ux-design hud先读design/player-journey.md（6 阶段情绪弧）与战斗/背包 GDD，再抛出 HUD 哲学三选项——Diegetic（低存在感）/ Persistent Minimal（常驻极简）/ Full Tactical（全战术信息）。用户基于生存游戏"孤独幸存者"幻想选择 B，Agent 将"HP 低于 30% 脉冲、耐力归零闪烁后回归极简"写入 Philosophy 节，随后逐节完成 Info Architecture、Zones、Element Specs、State Machine、Visual Budget（≤8% 屏占比、同时最多 3 个动画）、Platform Adaptation。

/ux-review 区分 BLOCKING 与 ADVISORY：评审发现背包界面缺少拖拽的键盘替代方案——判定为BLOCKING（停止交接）；HUD 仅用颜色传达 HP/耐力状态（色盲问题）与背包满时拖放行为未定义——判定为ADVISORY（可在视觉打磨或 GDD 中解决）。用户一条指令（按 F 拾取/再按 F 放置）补齐键盘路径后，评审重跑通过。

/team-ui 以通过的评审为硬门禁：交接时/team-ui首先核查两份 UX 文档均已 APPROVED，才进入视觉设计（art-director）→ 布局实现（ui-programmer）→ 无障碍审计（accessibility-specialist）→ 终审的 5 阶段流程。技能定义 team-ui.md 中存在AskUserQuestion等结构化交互实现，印证了这一交接由技能驱动。此外，本会话产出的拖拽交互会成为design/ux/interaction-patterns.md中的模式，供后续所有界面引用。

4.5 存量项目接管：/adopt（约 30 分钟，8 回合）

session-adopt-brownfield.md 面向已有 3 个月代码、格式不对的开发者，展示"不丢存量、只补缺口"的接管流程，核心是格式审计而非存在审计：

• 三个既有设计文件被逐份检查内部结构：design/combat-notes.md缺 6/8 节、design/crafting-ideas.md是头脑风暴笔记（只能当新 GDD 的输入）、design/inventory.md最接近但缺 5/8 节；
• 缺口按严重度分类：无 systems-index 为 BLOCKING（/design-system、/create-stories、/gate-check全部依赖它）、GDD 格式不符与无架构文档为 HIGH、无生产跟踪为 MEDIUM、pre-GDD 内容为 LOW；
• 产出 7 步有序迁移计划（先 BLOCKING 后 HIGH 再 MEDIUM），绝不覆盖现有内容；
• 最关键的是：Agent 直接读取src/gameplay/代码结构，从代码反推系统边界，当场生成 systems-index 草案（movement / world-terrain / combat / inventory / crafting / ui-hud，用户补充 stamina 并修正依赖），获批后写盘——BLOCKING 缺口当场解除，4+ 个技能立即可用。

文档还提示/adopt运行在fork 上下文（context: fork），避免大范围文件读取污染主会话。/design-system retrofit [path]与全新撰写/design-system [name]的差异也在计划中明确：retrofit 只跑缺失章节的循环，保留既有内容。

五、基础示例：设计与实现的单点能力

5.1 设计类：工艺系统（约 45 分钟，12 回合）

session-design-crafting-system.md 是"Pillar 2：通过实验进行涌现式发现"驱动的设计会话。五个澄清问题（发现方式、失败惩罚、成长解锁、系统地位、参考游戏）引出三方案对比：

• A 纯随机发现：2-4 材料组合掷随机——涌现最强但挫败完成型玩家、技巧表达低、易"逼玩家查 wiki"；
• B 标签推理（Potion Craft 式）：材料带隐藏标签，配方需特定标签组合，技能等级解锁逐级查看标签——推荐，因系统交互产生真正的涌现发现，且渐进揭示同时服务探索者与成就者；
• C 兼容性矩阵：实现简单、反馈公平，但更处方化、涌现性较弱。

用户选择 B 并追加"失败时提示哪个标签是错的"（如 "This needs Water, not Fire"），Agent 立即吸收并升级了反馈循环设计。Turn 8 主动抛边界问题——"发现不在配方库的标签组合怎么办"，用户裁决选项 C（程序化生成次要药水，如 Fire+Water → 恢复 5 HP 的 Warm Water），保持探索永远有回报。会话中 Agent 还委派了 systems-designer 校验 XP 曲线公式、economy-designer 平衡材料成本，体现层级协作。

5.2 实现类：战斗伤害计算（约 30 分钟，10 回合）

session-implement-combat-damage.md 展示实现 Agent 如何"先澄清、后架构、再编码"：

• 读取 GDD 后识别7 处规格缺口（架构选择、base_damage 来源、type_effectiveness 存放、attack_stat 钳制、暴击取整、defense≥1.0 行为、HP 系统缺失），全部提问而非猜测；
• 提出可测试架构（DamageCalculator纯静态类 +HealthComponent信号组件 +Weapon资源 +assets/data/combat_damage.json数据文件）供批准；
• 用户要求类型安全后，Agent 将未类型化 Dictionary 升级为CharacterStats资源并重新提案；
• 规则自动拦截：gameplay-code规则自动标记硬编码crit_multiplier=2.0与print()调试输出，Agent 透明修复（移入 JSON、改用信号）；data-files规则校验 JSON 合法性、命名约定与注释文档；
• 验证驱动开发：8 个单元测试覆盖基础计算、暴击、防御、类型克制、最小伤害钳制（永不低于 1）、攻击属性钳制（0-100）、缺失类型默认 1.0、floor 取整，全部通过（12ms），并给出可直接提交的 git 命令与validate-commit钩子校验项。

5.3 战略决策类：范围危机（约 25 分钟，8 回合）

session-scope-crisis-decision.md 是 creative-director 处理"Alpha 在 2 周、完整工艺需 3 周、投资人演示成败攸关"的经典场景：

• 先读里程碑定义、pillars、工艺 GDD、当前冲刺，再问 5 个约束问题（日期是否硬性、最小可演示范围、砍掉工艺的后果、投资人关系重要性、团队状态）；
• 正确框定决策——核心问题、真正风险（愿景完整性/日程信任/项目生存/质量标准）、按优先级排序的决策标准（投资人信心 > 支柱呈现 > 日程完整 > 打磨质量）；
• 三个选项逐一给出执行方案、利弊、风险等级与明确推荐：A 全量实现（3 周，滑期 1 周，风险 CRITICAL，不推荐）；B 简化核心（1.5 周，10 配方垂直切片保住 Alpha 与两支柱，风险 MEDIUM，推荐）；C 砍掉工艺（0 周，只有战斗亮相，风险 HIGH，不推荐）；
• 推荐理由引用游戏史先例（Hades、Dead Cells、Slay the Spire 的早期垂直切片），但明确 "this is your call"；
• 用户选 B 后，决策被完整文档化：ADR-007（含决策/上下文/正负后果/验证标准）、GDD 加 Alpha/Beta 范围标记、里程碑成功标准更新、投资人演示脚本（"先展示 2 个配方现场推导 → 连接到支柱叙事 → 路线图 10→50→100+ 配方"），并级联通知 gameplay-programmer 与 producer。

5.4 逆向文档化（约 20 分钟）

reverse-document-workflow-example.md 针对"代码写好了但从未写设计文档"的场景：Agent 读取代码、推断设计意图、就模糊决策提问，最终补产出回溯性 GDD。完整流程可参考 reverse-document-workflow-example.md 与配套的 reverse-document-workflow-example.md 工作流说明。

六、全示例共有的回合节奏

README 总结了跨所有示例的回合规律，可作为"健康的协作会话"判据：

训练他人使用本系统时，可挑一个示例逐回合走查，重点演示：好问题长什么样、如何评估选项、何时批准/何时要求修改、如何在利用 AI 专业能力的同时保持创作主导权。

七、如何按需选用示例

• 系统新手→ 先读 skill-flow-diagrams.md，建立全管线心智模型；
• 首次运行 /design-system→ session-design-system-skill.md；
• 要接故事→ session-story-lifecycle.md；
• 阶段收尾→ session-gate-check-phase-transition.md；
• 开始 UI 工作→ session-ux-pipeline.md；
• 有存量项目→ session-adopt-brownfield.md；
• Agent 驱动设计系统→ session-design-crafting-system.md；
• 实现代码→ session-implement-combat-damage.md；
• 战略决策→ session-scope-crisis-decision.md。

八、动手练习与延伸资源

读完示例后，可做如下练习验证理解：挑一个自己的游戏系统（战斗/背包/成长等），让相关 Agent 设计或实现它，观察 Agent 是否——✅ 开场先问澄清问题、✅ 带推理给选项、✅ 定稿前展示草稿、✅ 写文件前请求批准。若 Agent 跳过了任何一条，可用 README 中的提醒语将其拉回协作协议：

"Please follow the collaborative protocol from docs/COLLABORATIVE-DESIGN-PRINCIPLE.md"

延伸阅读入口：

• 协作原则全文：docs/COLLABORATIVE-DESIGN-PRINCIPLE.md
• 工作流指南：docs/WORKFLOW-GUIDE.md
• Agent 名册（49 个 Agent 的分层与职责）：.claude/docs/agent-roster.md
• 技能目录与优先级（72 个技能的注册信息，gate 类为 critical）：CCGS Skill Testing Framework/catalog.yaml
• 技能定义示例：gate-check.md、story-readiness.md、story-done.md、team-ui.md
• 质量标准与测试规格：quality-rubric.md、skill-test-spec.md

结语

docs/examples/下的每一份会话实录都在回答同一个问题：AI Agent 参与游戏开发时，专业能力与创作控制权如何共存？答案不是让 Agent 全自动"做出一个游戏"，而是建立可复现的协作节奏——先问、给选项、展示草稿、获批再写盘、立即吸收反馈，并通过stage.txt、systems-index、ADR、TR-ID、sprint-status.yaml 等持久化工件让每一步决策可追溯。配合 skill-flow-diagrams.md 的管线地图与 COLLABORATIVE-DESIGN-PRINCIPLE.md 的原则定义，这套系统既可以引导零基础新用户从概念走到发布，也能以/adopt平滑接管已有代码的存量项目。

【免费下载链接】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