📌 项目地址：Donchitos/Claude-Code-Game-Studios | ⭐ 20,344 颗星 | 🔧 Shell | 📜 MIT
为什么单条Prompt不够用
拿Claude直接写游戏代码，常见流程是：发一句“帮我写个平台跳跃游戏”，然后不断来回修改。几个回合后，代码里硬编码一堆魔法数字，没有设计文档，没有测试，你想加个存档功能发现自己都看不懂之前的逻辑了。
问题不在AI能力，在流程缺失。真实游戏公司有策划定需求、主程审查代码、QA跑测试——不是因为他们笨，是因为一个人同时写代码、设计系统、测试质量，脑容量根本不够。Claude在单次对话里也是一样，它会顺着你的话跑偏，不会主动拦你写烂代码。
Donchitos/Claude-Code-Game-Studios（后文简称CCGS）的做法是把一个AI会话拆成49个有明确分工的“员工”，再加73个斜杠命令来驱动他们的工作流。它不改变Claude的能力，而是改变了AI的工作方式。
三层结构：让AI自己管自己
CCGS按照游戏公司的汇报关系，把49个代理分成三层：
Tier 1 – 导演层（使用Opus模型）
创意总监、技术总监、制作人。他们不写代码不画图，职责是“守卫愿景”——比如技术总监会拦截违反架构设计的代码，制作人会检查进度是否偏离计划。
Tier 2 – 部门主管层（Sonnet）
游戏策划、主程、美术总监、音频导演、叙事导演、QA主管、发布经理、本地化负责人。每个主管有自己的领域，他们负责把导演层的意图翻译成具体任务，监督执行质量。
Tier 3 – 执行专家层（Sonnet或Haiku）
玩法程序员、引擎程序员、AI程序员、网络程序员、工具程序员、UI程序员、系统设计师、关卡设计师、经济设计师、技术美术、音效设计师、编剧、世界构建师、UX设计师等14个角色。
关键设计是：每个代理有定义好的职责边界和汇报路径。比如“engine-programmer”只处理引擎相关代码，如果收到UI任务，它会拒绝并上报给lead-programmer。这比给AI一个“你是个全栈开发者”的Prompt可靠得多——后者会让AI既写UI又改物理引擎，最后所有代码混在一起。
73个斜杠命令：从想法到上线的完整管线
这些命令不是随便写的，它们对应了游戏开发的标准阶段。我整理了几个关键命令的作用链：
/start [项目名称]：初始化工作室结构，创建目录、规则文件、模板。相当于新公司开张，人事行政到位。/design-system：触发创意总监和游戏策划，产出一份系统设计文档（System Design Document），定义核心机制和数值框架。/create-epics//create-stories：把高层设计拆成史诗任务和用户故事，每个故事都有验收标准。这是Scrum里的经典做法。/dev-story：分配一个故事给执行专家。比如“玩家可以跳跃”这个故事会交给gameplay-programmer，同时lead-programmer会定义代码规范，qa-lead会准备测试用例。/story-done：标记完成，触发QA验证。如果测试不通过，故事退回开发阶段。/qa-pass：通过后，游戏设计师/制作人做最终验收。/release-candidate//ship-it：冻结代码，生成发布候选，最终上线。
每个命令背后不是简单的AI生成，而是一个多代理协作流程。比如你执行/dev-story，背后可能依次调用：game-designer检查故事是否合理 → lead-programmer分派任务 → gameplay-programmer写代码 → tools-programmer检查是否需要自动化测试 → 最后qa-lead标记状态。这些流程写死在Hook和Rules文件里。
12个钩子和11条规则：比CI还严格的质量门禁
CCGS在.claude/hooks/目录下放了12个自动化脚本，会在特定事件触发时运行：
- pre-commit：提交前检查代码是否包含TODO、硬编码参数、缺少错误处理等。
- post-push：推送后检查是否有未通过QA的故事。
- asset-validate：当图片、音频等资产变更时，检查命名规范、分辨率、格式。
- session-lifecycle：会话开始/结束时，自动加载/清理上下文。
- agent-audit（日志审计）：记录每个代理在会话中的行为，方便回溯谁做了什么。
11条Rules（路径规则）是在Claude响应时强制触发的。比如你在编辑src/gameplay/下的代码时，会自动激活“Gameplay Coding Standards”规则，要求所有函数必须有单元测试，UI逻辑不能放在这里。这些规则存在.claude/rules/里，可以自己调。
效果相当于：你让AI写代码时，背后有个自动代码审查工具在实时检查。这比人工Review要快得多（当然它也有Claude的错误率）。
实际使用：别想着开箱即用
说几个我试用后的感觉：
上手成本不低。 你需要先安装Claude Code（CLI工具），然后执行/start命令。但49个代理的配置、73个命令的触发词、12个hooks的逻辑，都深度绑定了Claude Code的工作流。如果你还没用Claude Code，这个项目的作用会打折扣。
模型消耗翻倍。 一次/dev-story可能调用3-4个代理，每个代理都消耗token。Opus模型贵，Sonnet中等，Haiku便宜。如果你是Pro用户（每月20刀），可能很快用完额度。建议用API Key按量付费，并调低Haiku的比例。
自定义是核心能力。 官方README写了“Customization”一节，你可以修改agent定义、添加新命令、调整hook规则。如果你真想做商业游戏，必须根据自己项目类型（比如2D像素 vs 3A）去调整代理分工和规则。开箱默认更适合中型以上的团队（3-10人独立游戏团队最合适）。
这不是魔术，是管理框架。 它不会让Claude突然写出《黑神话：悟空》，但能让你在3个月内，一个人把一个小型Roguelike从原型做到发布。缺点是你需要花1-2天学习配置，并且接受AI在某些任务上仍然会犯错（比如物理碰撞的边界案例）。
和直接写Prompt比，价值在哪
直接写Prompt：/start 写一个2D平台跳跃 → 然后自己不断提要求。
CCGS：/start SuperJump → /design-system → /create-epics → /create-stories → 自动拆出“玩家移动”、“跳跃物理”、“敌人AI”、“关卡设计”等多个故事 → 分别执行/dev-story → 每个故事有独立上下文和质量门禁。
区别在于可维护性。游戏项目随着代码量增长，容易变成一团乱麻。CCGS把“写代码”和“管理代码”的职责分开了，AI的上下文也切得更小——一个agent只关注一小块代码，减少了幻觉和遗忘。而且如果你中途换人（或者几个月后自己回来看），所有的设计文档（GDD、UX spec、ADR）已经自动生成好了，不用重写。
谁应该试试这个项目
- 单人独立开发者，想用AI做出完整度高的游戏
- 3-5人小团队，没有专门去建流程体系
- 已经用AI写过游戏的代码片段，但无法收尾的
不适合谁？只写个简单原型，不需要流程管理的（直接写Prompt更快）；或者你完全不想接触命令行和配置文件。
一小部分值得关注的数据
| 类型 | 数量 | 说明 |
|---|---|---|
| Agents | 49 | 实际可调用的角色 |
| Slash Commands | 73 | 覆盖设计、开发、测试、发布 |
| Hooks | 12 | 自动触发验证 |
| Rules | 11 | 路径级编码标准 |
| Templates | 41 | 各类文档模板 |
结尾
这个项目的20443颗星不是因为它能自动生成游戏，而是因为它给AI游戏开发这件事补上了最缺的一环：流程。它把游戏行业积累几十年的管理经验——分层架构、设计文档、代码审查、质量门禁——翻译成了Claude能理解的指令集。你不需要在开发过程中反复提醒自己“先写设计文档”，这些已经固化在命令链里了。
如果你想在AI辅助下，有条理地做出一个完整的游戏，而不是一堆代码碎片，CCGS值得你花一个下午去调试。