一个人用 AI 做游戏，最大的问题从来不是"AI 会不会写代码"，而是"没人管你"。我试过让 Claude Code 从零开始搭一个玩法原型，前两天效率高得吓人，第三天开始失控：魔法数字散落在十几个文件里，设计文档只存在于聊天记录里，改一个数值要翻半天上下文。这不是模型能力的问题，是会话本身没有结构。
Claude-Code-Game-Studios 这个项目解决的正是这件事。它把单次 Claude Code 会话组织成一支有层级的游戏工作室，原项目 Donchitos/Claude-Code-Game-Studios 目前 31393 stars，主语言是 Shell，MIT 协议。我这次看的是它的中文翻译版 yangshun2005/Claude-Code-Game-Studios-cn，翻译日期标注为 2026-11-01，需要说明的是中文版刚发布，star 数为 0，热度完全来自原项目，这一点先讲清楚，免得有人误会。
它到底给了你什么
按 README 的清单，这套模板包含五类东西：
- 49 个智能体，覆盖设计、编程、美术、音频、叙事、QA、制作
- 74 项技能，也就是斜杠命令，覆盖每个工作流阶段
- 15 个 Hook，在提交、推送、资源变更、设计文档读写、会话生命周期等节点自动校验
- 14 条规则，按路径生效，编辑玩法、引擎、AI、UI、网络代码时强制执行
- 62 个文档模板，GDD、UX 规格、ADR、冲刺计划、HUD 设计、无障碍之类
这些数字不是我编的，是 README 里明确列的表格。我比较在意的是那个"按路径生效"的规则设计------它不是靠提示词求你遵守，而是你一旦动到 gameplay 目录下的文件，对应的编码标准就被挂上去。这个思路在工程治理上是对的，靠自觉永远不如靠卡点。
三层结构，和真实工作室一个逻辑
智能体分三层，README 里的层级图是这样的：
第 1 层是总监：creative-director、technical-director、producer。
第 2 层是部门主管：game-designer、lead-programmer、art-director、audio-director、narrative-director、qa-lead、release-manager、localization-lead。
第 3 层是专员：gameplay-programmer、engine-programmer、ai-programmer、network-programmer、tools-programmer、ui-programmer、systems-designer、level-designer、economy-designer、technical-artist、sound-designer、writer、world-builder、ux-designer、prototyper、performance-analyst 等。
这个层级不是摆设。它的实际作用是给"谁该说话"定了个顺序：你做玩法决策时，creative-director 会先问这符不符合游戏愿景，然后才轮到 gameplay-programmer 动手。真实工作室里设计评审存在的意义就是拦住那些"看起来能跑但方向错了"的东西，这套模板把评审做成了流程的一部分。
模型成本这件事，得提前算
README 里有一条很实在的信息：三个总监 agent 要求 Opus，lead-programmer 以及 15 个专员指定 Sonnet，其余 30 个继承你当前会话的模型。
这意味着如果你全程用低配模型跑，那些被指定 Opus 的角色可能根本按预期工作不了。我的判断是，这套东西不适合"随手试试"的场景，它更适合你已经决定要认真做一个项目、并且愿意为关键角色付模型成本的时候。反过来说，如果你只是想验证一下流程，可以先只用 Sonnet 层的角色跑通主线，总监层暂时跳过，等方向定了再上。
上手路径
README 的快速上手部分给的是最短路径，我照着梳理一遍：
第一步，克隆仓库。原文没有直接给出克隆命令，按项目信息推断是 git clone https://github.com/Donchitos/Claude-Code-Game-Studios，中文版则换成 git clone https://github.com/yangshun2005/Claude-Code-Game-Studios-cn。
第二步，在 Claude Code 里打开这个项目目录。
第三步，输入 /start，走引导流程。
第四步，用 /setup-engine 选引擎，可选 Godot 4、Unity、Unreal Engine 5。
第五步，之后按需用 /brainstorm、/design-system、/create-epics、/create-stories、/dev-story、/story-done 这些命令往下推。
这里有个坑我得提醒：三套引擎的 agent 集是分开的，/setup-engine 必须选对。选错了不会报错，但专员会对不上你的项目，比如你明明用 Unity，结果挂了一堆 Godot 相关的角色，后面全是噪音。
还有一点，README 里明确写了它是流程模板，不是游戏生成器。产出以设计文档、架构、故事、评审这些流程产物为主。别指望一键出可玩的游戏，这个预期一定要摆正。
中文版的价值在哪
原项目是英文的，49 个 agent 的职责描述、74 个命令的说明、62 个模板、14 条规则，全是英文。对英文阅读没障碍的人这不算事，但实际使用中，你会在很短时间内反复查阅这些定义------尤其是刚开始不熟悉层级的时候，一天翻十几次很正常。中文版把 README 正文做了完整翻译，并且额外加了一段"中文快速上手"的补充导读，明确标注了非原文内容，目的是让人不用读完整篇 README 就能先把项目跑起来。
这个处理方式我觉得挺克制：翻译部分力求忠于原文，补充部分单独标出来，不混在一起。README 里也写了，翻译不准确的地方欢迎提 Issue 或 PR。
需要客观说一句，中文版目前只是文档中文化，agent 定义、命令、模板这些实际配置文件是否也做了本地化，README 材料里没有明确说明，我这边没法确认。如果你的项目需要英文产出物（比如要给海外团队看），用之前最好先确认一下。
升级前先看 UPGRADING.md
仓库里有 UPGRADING.md，README 提到升级前应该查阅，避免覆盖自定义配置。具体升级步骤原文没展开，但这个提醒本身说明了一件事：这套模板是会被你改的。49 个 agent 你不可能全都用得上，实际项目里大概率会裁剪一部分、调整一部分。一旦改过，直接拉新版本就会冲突。
我的建议是，第一次用就把自己的改动单独记一份，或者用 git 分支管理，别在原文件上直接改完就忘了。
选型上的几点判断
基于我自己在企业里推 AI 工程落地的经验，这类"给会话加结构"的模板，评估顺序应该是这样的：
先看它卡的是不是你真的会犯的错。这套模板的 14 条规则是按路径生效的，如果你做的项目根本不涉及网络代码，那 network-programmer 和相关规则对你就是纯负担。先想清楚自己的痛点在哪，再决定启用哪几层。
再看流程产物的维护成本。62 个文档模板听起来很全，但每个模板都要人填。如果团队只有你一个人，全量启用会把你埋进文档里。我的做法是先用 /brainstorm 和 /design-system 把方向定下来，epics 和 stories 按需生成，不要一上来就全铺开。
最后看模型成本的分配。总监层用 Opus、执行层用 Sonnet 这个设计是合理的，但你要接受它带来的账单。如果预算紧，可以只在关键决策节点切到 Opus，日常开发用 Sonnet 跑。
适合谁，不适合谁
适合的：已经决定用 Claude Code 认真做一个游戏项目、并且吃过"没结构"苦头的人。你至少做过一次原型，知道失控是什么感觉，这套模板的每一层你都能对上号。
不太适合的：想快速验证一个点子的人。这套东西的前置成本不低，/start 走完、引擎选完、方向定完，可能半天就过去了。如果你只是想看看 AI 能不能写个贪吃蛇，直接用 Claude Code 裸跑更快。
另外，它的产出偏文档和流程，如果你要的是"能跑起来的代码"，得自己心里有数，agent 是帮你把决策做扎实，不是替你把游戏做完。
最后
原项目 31393 stars 说明这个方向是被验证过的------用 AI 做游戏的人确实需要结构。中文版把门槛降了一截，尤其是对不习惯读长篇英文文档的人。翻译质量我看了 README 部分，术语处理得比较稳，没有那种机翻的生硬感。
至于它能不能真的帮你做出一个游戏，我的样本不多，只能说流程这一层它是扎实的，剩下的还是看你自己愿不愿意在每个关卡上认真做决定。工具能拦住硬编码，拦不住你想偷懒的心。