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 将全部示例按用途分为三类分类示例核心价值Visual Referenceskill-flow-diagrams.md7 阶段全管线总览 各技能链图解新手入口Core Workflow核心流程session-design-system-skill.md、session-story-lifecycle.md、session-gate-check-phase-transition.md、session-ux-pipeline.md、session-adopt-brownfield.md覆盖技能驱动设计、完整故事生命周期、阶段门禁、UX 管线、存量项目接管五条主线Foundational基础示例session-design-crafting-system.md、session-implement-combat-damage.md、session-scope-crisis-decision.md、reverse-document-workflow-example.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 五类协作行为行为含义示例出处先问后猜设计 Agent 问目标/约束/参考实现 Agent 澄清规格歧义领导 Agent 先收集上下文战斗实现 Turn 2、范围危机 Turn 2给选项而非命令2-4 个带利弊的方案基于理论/先例/项目支柱给出理由推荐但由用户拍板工艺系统 Turn 4、范围危机 Turn 5定稿前先展示设计草稿逐节展示、架构方案先于实现展示、战略分析先于决策展示GDD 撰写 Turn 3-10、战斗实现 Turn 4写文件前获批明确说 May I write to [file]?多文件变更先列出全部受影响文件所有示例的写文件回合迭代反馈用户修改立即吸收推荐被改时不辩解用户改进方案时给予认可工艺系统 Turn 5-6三、技能链总览零到发布的 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-ops3.1 图解符号约定符号含义──►产出该产物artifact│ ▼流入下一步├──分支多种可能结果×N执行 N 次每个系统、故事各一次(input)技能读取但不在本步产出[optional]门禁通过不强制要求WRITE大写立即写入磁盘3.2 按当前位置选择入口技能你在哪里运行什么全新项目、毫无头绪/start→/brainstorm有概念、没引擎/setup-engine有概念引擎/map-systems系统设计中途/design-system [next system]或/map-systems next所有 GDD 完成/review-all-gdds→/gate-check技术搭建中/create-architecture→/architecture-decision开始 UX 设计/ux-design screen [name]或/ux-design hud脚手架测试/test-setup→/test-helpers有故事、可编码/story-readiness [story]→/dev-story [story]故事完成/story-done [story]冲刺 QA/qa-plan→/smoke-check→/regression-suite已有存量项目/adopt四、核心流程示例详解4.1 GDD 撰写/design-system约 60 分钟14 回合session-design-system-skill.md 展示了技能驱动的系统设计开发者在/map-systems产出 systems-index 后运行/design-system movementAgent 从游戏概念与依赖 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_speed120 px/s、run_multiplier1.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中交叉印证。3COMPLETE 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.md6 阶段情绪弧与战斗/背包 GDD再抛出 HUD 哲学三选项——Diegetic低存在感/ Persistent Minimal常驻极简/ Full Tactical全战术信息。用户基于生存游戏孤独幸存者幻想选择 BAgent 将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 材料组合掷随机——涌现最强但挫败完成型玩家、技巧表达低、易逼玩家查 wikiB 标签推理Potion Craft 式材料带隐藏标签配方需特定标签组合技能等级解锁逐级查看标签——推荐因系统交互产生真正的涌现发现且渐进揭示同时服务探索者与成就者C 兼容性矩阵实现简单、反馈公平但更处方化、涌现性较弱。用户选择 B 并追加失败时提示哪个标签是错的如 This needs Water, not FireAgent 立即吸收并升级了反馈循环设计。Turn 8 主动抛边界问题——发现不在配方库的标签组合怎么办用户裁决选项 C程序化生成次要药水如 FireWater → 恢复 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_multiplier2.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 总结了跨所有示例的回合规律可作为健康的协作会话判据回合段行为Turn 1-2先理解再行动读上下文设计文档/规格/约束、问澄清问题、零假设Turn 3-5带推理给选项2-4 条路径、各自利弊、理论/先例支撑、推荐后交还决策权Turn 6-8迭代草稿增量展示、立即吸收反馈、主动标记边界情况与歧义Turn 9-10批准与收尾May I write to [file]? → 用户 Yes → 写文件 → 提供后续选项测试/评审/集成训练他人使用本系统时可挑一个示例逐回合走查重点演示好问题长什么样、如何评估选项、何时批准/何时要求修改、如何在利用 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.mdAgent 驱动设计系统→ 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.mdAgent 名册49 个 Agent 的分层与职责.claude/docs/agent-roster.md技能目录与优先级72 个技能的注册信息gate 类为 criticalCCGS 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考