Claude Code Game Studios：49 个 AI agent 凑成一家游戏工作室

Claude Code Game Studios：49 个 AI agent 凑成一家游戏工作室

一个人加一个 Claude Code，怎么模拟出整家游戏公司的协作？这个仓库给了一份可抄的答案。

独立游戏开发最缺的从来不是创意，是人手：策划、程序、美术、音频、QA、制作人，真实工作室里六七个岗位的活，indie 开发者往往一个人全扛。Donchitos/Claude-Code-Game-Studios 的思路是把这些岗位做成 Claude Code 里的 agent，用一套工作流把它们编排成虚拟工作室。2026-02-12 创建，到 2026-11-10 攒了 37,221 star、4,896 fork、96 个未关闭 issue，MIT 协议，仓库标记为 template，最后一次代码推送在 2026-10-19。

我通读了 README、目录结构、49 个 agent 的命名清单和 hooks 说明。这篇按四个问题展开：它到底是什么、怎么跑起来、哪些编排设计值得做 agent 系统的人抄走、以及它和裸 Claude Code、SaaS 游戏生成器怎么选。先说一个观察：这个仓库 GitHub 语言统计第一是 Shell，因为它本质上不是代码项目，是一套配置和流程资产。

本文提纲

1. 是什么：Claude Code 的工作室模板，不是游戏引擎
2. 怎么用：前置条件、/prototype 流程、引擎选择与 rigor 三档
3. 值得学习的五个设计
4. 同类比较：裸 Claude Code、通用 agent 合集、SaaS 生成器怎么选

是什么：Claude Code 的工作室模板，不是游戏引擎

一句话定位：Claude Code Game Studios 是一个 Claude Code 项目模板，用 49 个岗位化 agent、75 个 workflow skill、18 个 hook 脚本和 14 条路径规则，把一个 Claude Code 会话编排成按真实工作室 hierarchy 协作的开发团队。它不是游戏引擎（引擎用 Godot、Unity、Unreal 或 Web 技术栈），不附带任何成品游戏（README 明确说别人的游戏放在你的仓库里是 clutter 不是 evidence），也不是托管服务，没有云端，所有东西跑在你本地的 Claude Code 里。

仓库在 GitHub 上 is_template 为 true，标准用法是 clone 或 use template 生成一个你自己的游戏项目。核心资产全部在 .claude/ 目录下：

目录/文件	内容	数量
.claude/agents/	岗位化 agent 定义，Markdown 加 YAML frontmatter	49 个
.claude/skills/	工作流 skill，每个一个子目录	75 个
.claude/hooks/	bash 事件钩子，15 个事件钩子加 2 个 helper	18 个脚本
.claude/rules/	按路径生效的编码规范	14 条
.claude/docs/	workflow-catalog.yaml 定义 7 阶段流水线，加 62 个文档模板	—
project.yaml	项目唯一配置源：引擎、命名约定、modes	1 个

49 个 agent 的命名直接照抄真实工作室岗位，看文件名就能读出组织架构：creative-director、game-designer、systems-designer、level-designer、economy-designer、narrative-director、art-director、technical-artist、audio-director、gameplay-programmer、engine-programmer、network-programmer、tools-programmer、qa-lead、qa-tester、producer、release-manager、community-manager、localization-lead，外加 Godot/Unity/Unreal 各引擎的专项 specialist（比如 ue-gas-specialist、unity-dots-specialist、godot-shader-specialist）。这和通用 agent 包里清一色的 coder/reviewer 角色是两种设计取向。

它的主工作流围绕 /prototype 命令展开，四个阶段每个都有明确的人工检查点：

MERMAID_BLOCK_0

注意交付环节的措辞：handover card 把 brief 里每条要求标记为 built、missing、broken 或 not assessed，结尾固定写一句 "Not yet played by a person"。自动检查只证明游戏能打开、有响应，真人试玩才是最终测试，这个边界它划得很清楚。

怎么用：前置条件、/prototype 流程、引擎选择与 rigor 三档

前置条件和启动

README 把依赖分成必需和推荐两档，这个区分本身就值得学：

• 必需：Git、Claude Code（推荐原生安装器，npm 方式需要 Node.js 22+）、Python 3、Bash、Chrome/Edge/Chromium 之一
• 推荐：Node.js（把原型成长为正式 web 项目、three.js、构建测试用）和 jq（hook 校验用）

每个缺失依赖的降级行为都写明了：没有 Python，所有 skill 和 hook 静默回退默认值；Windows 上没有 Bash，hook 自动跳过，会话启动时提示检查关闭；没有浏览器，/prototype 的自动试玩降级为 not assessed 而不是报错。只有一个故意的例外：没有 Python 时，暂存 data JSON 的 commit 会被直接阻止，因为这类文件无法校验。

启动就是标准模板流程：

git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game
cd my-game
claude

然后在会话里输入 /prototype 加一句话创意，或者先跑 /start 让它问你处在什么阶段（全新想法、清晰设计、已有作品）再分流。有个容易踩的坑 README 专门提醒：必须在根目录（持有 CLAUDE.md 和 project.yaml 的地方）启动，在 src/ 之类的子目录启动会跳过全部 hooks、deny 规则和 ask-first 权限模式。

一次完整的 /prototype

以 README 里的例子 /prototype a fishing game where the rare fish only bite at dusk 为例。第一步是一轮按类型裁剪的提问，覆盖影响游戏形态的关键选择，每个问题都有默认答案，说"you pick"就能过；如果创意太模糊（只说"a racing game"），它先给两三个一句话 pitch 让你选。

第二步产出 design/game-brief.md，一页纸，保留你的原话，写清视觉风格、第一分钟体验、挑战、功能和留到以后的部分。人看完说 Build it 才进入下一步。

第三步在 prototypes/<name>/ 产出一个双击即开的浏览器游戏，约束包括：所有图形手绘、不用 emoji 当美术、不抄袭现有游戏、不能简单到没有挑战。还可以指定投入程度，"build it at medium" 产出更轻更省。

第四步是 headless 浏览器里的脚本化按键测试，确认无报错、有响应；文字过小、元素重叠、出屏、画面冻结这类问题一轮内修复，然后对照截图和代码逐条核对 brief。

原型之后是三条成长路径：口头要求改动（每次接受的改动都是可回退的 checkpoint，要求 tune 会生成带滑块的 tweak panel）、一键导出干净版本发 itch.io、或者 PROCEED 进入正式项目形态（Vite 加 TypeScript、数值进 data 文件、带测试和构建），之后每次会话只做一个 feature，做完即测即提交，并用相同种子的回放验证改动没有破坏旧行为。已有浏览器游戏可以用 /prototype --from <path> 接管。

引擎与 rigor：一张表和一个前门

引擎支持 Web、Godot 4、Unity、Unreal Engine 5，差异收敛在一张 .claude/engines/engines.tsv 表里，包括代码根目录（Unity 只编译 Assets/，Unreal 从 Source/<Module>/ 构建）和默认命令。不预设引擎时 /prototype 先做浏览器原型，玩过之后再选，/setup-engine godot 4.7 会钉住版本并写入参考文档。

配置上最关键的设计是 modes.rigor，分 minimal、standard、full 三档。它是六个独立旋钮的统一前门：workflow（GDD 必需章节数）、docs.density、qa.level、story_granularity、review_mode（几个 director agent 评审）、team.size。minimal 是默认值，不要求 GDD、文档精简、QA 证据最少、单人评审；standard 要求 5 个 GDD 章节；full 要求全部 8 个章节和完整 director 评审。README 给的默认理由很直白：更重的流程在没带来更好结果时，只会拖慢到达可玩代码的速度，对新人接手也没有回报。项目长大之后，/next-step 和 /gate-check 会主动建议升档。

两个逃生舱防止单一刻度变成钝器：system_overrides 可以只给战斗系统开 full 待遇、其余保持轻量；testing.strict 按测试类型（逻辑、集成、视觉、UI、配置）决定缺证据是阻断还是警告。review_mode 和 team.size 还是个人级设置，可在 gitignore 的 project.local.yaml 里覆盖，不动团队共享配置。

值得学习的五个设计

1. 用真实组织 hierarchy 做 agent 分工，而不是造抽象角色

多数 agent 模板包的角色是技术动作的拟人化（coder、reviewer、debugger），这个仓库直接复刻游戏公司的岗位树。好处在协作语义上：producer 管节奏、creative-director 管 vision、qa-lead 对质量有否决权、release-manager 管上架，agent 之间的交接关系和真实工作室一致，开发者用行业直觉就能编排，不需要先学一套自定义抽象。引擎 specialist 进一步按技术栈细分，UE 的 GAS、Unity 的 DOTS、Godot 的 shader 各有专属 agent，等于把"招什么人"的决策固化进了文件命名。

2. 一个前门管六个旋钮，默认选最轻的档

把流程严格度做成六个独立配置项是工程师的本能，但对用户是六个决策负担。rigor 的做法是提供一个有语义的三档前门，一次问答替代六次配置，同时保留逐个旋钮覆盖和局部 override 的能力。更值得抄的是默认值哲学：minimal 当默认，因为流程成本是确定的、收益是不确定的，让重流程成为项目长大之后的主动升级，而不是新项目的入场税。/next-step 观察到项目迹象后再建议升档，把配置时机推迟到信息充分的时候。

3. hooks 把治理做成强制约束，不依赖 agent 自觉

Claude Code 的系统提示词可以被长上下文冲掉，但 hook 是机器执行的硬约束。这个仓库的 15 个事件钩子覆盖了几个真实事故面：validate-commit.sh 拦硬编码值、TODO 格式、JSON 合法性；validate-push.sh 对保护分支推送和 tag、merge、release、butler、steamcmd 等危险操作警告；validate-read.sh 拒绝整文件读取超过 40KB 的设计文档，改为返回标题让下次按节读取，直接治理上下文浪费；validate-write.sh 对覆盖受保护文件、跨越 prototype 边界、违反本地化冻结的写入发出警告。

设计上还有两个分寸感。一是写操作的 hook 只警告不阻断，读和提交才用硬拦截，避免工具和人对着干；二是依赖缺失时优雅降级并明确告知损失了什么校验，而不是神秘失败。

4. 给框架本身建测试体系，而不只测产出的游戏

studio-tests/ 是这个仓库区别于普通 prompt 合集的地方。它提供 /skill-test static（7 项结构合规 lint）、/skill-test category（分类质量评分卡）、/skill-test spec（行为规格断言）、/skill-test audit（skill 和 agent 的覆盖率报告），以及 /skill-improve 的测试-修复-回归闭环，分数不升就回退。测试对象是 75 个 skill 和 49 个 agent 本身，游戏测试明确划归 tests/。当你的产品就是一堆 Markdown 指令时，给指令建 lint 和行为 spec，是把"配置工程"当软件工程做的信号。

5. 对能力边界保持异常诚实

README 的 "What it has been shown to do" 一节没有营销话术：blind comparison 只有三个游戏想法，结果是它的提问式 brief 三次都赢了手写 brief，但基于两种 brief 做出的六个游戏测试者都愿意继续做，游戏本体打平；成长流程只在一个游戏上跑通了六个 story，原文写明 "that is one game, not yet a pattern"；Godot/Unity/Unreal 引擎路线和单系统深度设计文档虽然建好且通过框架自检，但没有经过同等实测，直接标成 Not yet shown。这种把样本量、测试条件和未验证项摊开的写法，在万星级项目里不多见，也让前面的正面结论更可信。

同类比较：裸 Claude Code、通用 agent 合集、SaaS 生成器怎么选

先声明口径：这个领域没有统一 benchmark，仓库自己的测试也只是个位数样本，下面只比架构定位和适用场景，不编准确率。

维度	Game Studios	裸 Claude Code	通用 agent/skill 合集	AI 游戏生成 SaaS
核心定位	游戏工作室流程模板	通用编码 agent	通用角色/技能资产包	托管式游戏生成平台
领域流程	7 阶段游戏开发流水线	无	无或泛化	平台固定流程
多 agent 协作	49 岗位化 agent + hierarchy	单会话为主	有角色但缺编排	黑盒，不可见
强制治理	15 个 hook + 权限 + 路径规则	基础权限	通常无	平台侧承担
引擎路线	Web/Godot/Unity/Unreal	任意	任意	多为自有 web 运行时
可定制性	完全可改，带自测体系	完全自建	高但需自己整合	低，受平台约束
数据与成本	本地，消耗 Claude 额度	本地	本地	订阅制，数据过平台

逐个说分工。裸 Claude Code 适合流程简单、一次性的游戏 jam 原型，零学习成本，但所有规范、检查、岗位分工都要你每次口头重建，上下文一长就漂移。通用 agent 合集（各类 agents、skills 仓库）解决的是"角色定义不想自己写"，拿来即用，但它们是零件不是流水线，没有 hooks 治理、没有阶段门禁、没有框架自测，拼装成本仍然在你这边。

Rosebud 一类 AI 游戏生成 SaaS 的优势是打开浏览器就能出游戏、自带托管和分享，适合非程序员和快速验证玩法；代价是技术栈和运行时锁在平台内，Godot/Unity 路线、深度定制、私有化都谈不上，订阅和数据归属也是长期成本。传统引擎加 AI 助手（Godot 配 Copilot、Unity Muse 之类）则是另一条路：引擎能力最完整，但 AI 只做局部补全，没有工作室级的流程编排和 QA 门禁。

我的选型判断：想认真做一个会长期迭代、可能上架的游戏，且团队愿意接受 Claude Code 的工作方式，Game Studios 是目前把流程、治理、自测整合得最完整的开源选择，clone 下来按自己岗位裁剪 agent 即可；只想周末玩个 jam，裸 Claude Code 或 SaaS 生成器更轻；需要 Unity/Unreal 重度引擎能力，先接受它自己声明的"引擎路线尚未经实测"这个前提，把 studio-tests 跑通再上生产。另外两个现实因素：96 个未关闭 issue 和停在 2026-10-19 的最后推送，说明维护节奏不算快，模板类项目这通常可以接受，但升级前记得读 UPGRADING.md，里面标了哪些文件能覆盖、哪些要手工合并。

参考文档与链接

• Donchitos/Claude-Code-Game-Studios（GitHub） — 仓库主体，MIT，37,221 star / 4,896 fork / 96 open issue（2026-11-10 GitHub API 快照），标记为 template
• README — /prototype 四阶段、rigor 三档、hooks 表、引擎表、自测命令与小样本实测结论
• .claude/agents 目录 — 49 个岗位化 agent 定义
• UPGRADING.md — 版本迁移、可覆盖文件与需手工合并文件清单
• CONTRIBUTING.md — 模板定制与贡献规范
• Claude Code 官方文档 — subagents、hooks、skills、权限模式的官方说明
• Godot Engine — 支持的引擎路线之一，GDScript/C#/GDExtension
• Unity — 支持的引擎路线之一，代码根在 Assets/
• Unreal Engine 5 — 支持的引擎路线之一，C++ 与 Blueprints
• itch.io — README 推荐的独立游戏分发目标，导出干净版本后可直接上架
• Rosebud — AI 游戏生成 SaaS 代表，对照托管式生成路线

你用 Claude Code 或其他 agent 做过游戏吗？49 个 agent 这种重编排是真提效还是增加沟通开销？评论区聊聊你的实际体验。觉得有帮助点个赞，让更多独立开发者看到。

---

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。