Claude-Code-Game-Studios
业精于勤，荒于嬉；行成于思，毁于随。——韩愈
49 个 AI 下属，74 项技能，还有一份把自己判了输的实验报告
先算一笔账
一个人做游戏，通常缺的是时间。
这个项目给你的解决方案是：给你 49 个下属。
四十九个。你要是个真正的工作室制作人，手底下有这么多人，第一件事就是去订一间更大的会议室。
项目地址：https://github.com/Donchitos/Claude-Code-Game-Studios
它自称能把一次 Claude Code 会话变成一整间游戏开发工作室：49 个 agent、74 项技能、一套完整的协作系统，照着真实工作室的层级搭建。
听起来像是把「人多好办事」这句话，硬塞进了一个终端窗口。
它真正提供的是结构
先把话说清楚：它不生产代码，它生产结构。
文档里那段「为什么存在」，写得比大多数同类项目诚实得多，也难听得多。大意是：一个人用 AI 做游戏很强大，但一次聊天没有任何结构——没人拦着你把魔法数字硬编码进逻辑，没人拦着你跳过设计文档，没人拦着你写一坨意大利面。没有 QA 环节，没有设计评审，也没有人问你一句「这东西真的符合游戏的愿景吗」。
这段话的妙处在于，它骂的是「你现在的工作方式」，而不是别人。
而它的解法是给这个会话装上真实工作室的骨架：49 个专门化的 agent，分三层——总监守在愿景那一层，部门主管管自己的领域，专家干具体的活。每个 agent 都有明确的职责、升级路径和质量门。
最后一句是最关键的：决定权还是你的，但你身边多了一支会问对问题、会早点抓错、会把项目从第一张脑图管到上线的队伍。
换句话说，它给你的是一个不会替你拍板、但会一直问你「你确定吗」的团队。
在现实里，这种同事通常让人烦。在项目里，这种同事救命。
数字汇总
它把自己的配置做成了徽章，一排挂在那里，就像一份体检报告：
| 项目 | 数量 |
|---|---|
| Agent | 49 |
| 技能 | 74 |
| Hooks | 15 |
| 规则 | 14 |
四个数字，四种东西。49 个角色、74 套流程、15 个钩子、14 条规则。这套配置的规模已经不像一个「提示词合集」，更像一份真的组织架构图加员工手册。
但这里有个细节，我得指出来。仓库描述里写的是 72 项工作流技能，文档标题下写的是 74 项技能，徽章也是 74。
两个数字，差了 2。可能是描述忘了更新，可能是数错了，也可能是有两项技能不太好归类，索性就先这么放着。
一个卖「结构」的项目，在自己的门牌上挂着两个不一样的数字。这不致命，但很说明问题：它管得住 49 个 agent，管不住自己的元数据。
顺便说，除了技能，还有九个「团队编排」的斜杠命令，用来协调多个 agent 干同一件事：
1 | /team-combat /team-narrative /team-ui /team-release /team-polish |
战斗、叙事、UI、发布、打磨、音频、关卡、线上运营、QA。
看着挺全。但请注意最后那个 /team-qa——在一个连自己文档里的数字都对不齐的项目里，QA 这个岗位显得格外有存在必要。
最值得佩服的一节：它拿自己做了对照实验
如果这份文档只有前面那些，我会把它归到「AI 套壳组织架构图」那一类，看完就忘。
但它有一节叫：它产出的是游戏，还是文档？
这个问题问得好，因为大多数这类项目的实际产出就是一堆 Markdown：设计文档、技术方案、代码规范、评审记录，写得漂亮，游戏没有。
它的回答方式很硬：不做示例项目，做测量。
四个游戏，同一份需求简报，用不同的 modes.rigor 档位来做，然后统计在写下第一行游戏代码之前，各自写了多少份文档。
modes.rigor |
写第一行代码前的文档数 | 耗时 |
|---|---|---|
minimal |
1 份，就是那份一页纸的需求简报 | 0 分钟 |
standard |
30 份 | 58 分钟 |
结果呢？四个都产出了能跑、被测过的游戏。
然后是全文最精彩的一句：两位盲评评审加一次真人试玩，把 standard 那一版排在了最后一名。
多出来的 29 份文档，买到的是可追溯性，不是一个更好的游戏。
这句话要是被哪个咨询公司看到，大概会气得把 PPT 撕了。一个项目愿意在首页承认「我这套流程的重档位，做出来的东西更差」，这需要的不是勇气，是一种很少见的、对自己产品的冷静。
当然，也可以反过来说：既然重档位更差，那你为什么还把它做成默认选项之一？
它自己也想到了这一层——modes.rigor 是可调的，而且任何技能都能用 --review solo 单次覆盖。
通过测试不等于菜单没有被画到屏幕外
紧接着还有一节，标题很像一句吐槽：它会把游戏跑起来，然后看一眼。
原话更狠：一个通过的测试，并不能说明菜单没有被画到屏幕外面去。
所以规则是：任何一个改变了玩家可见内容的 story，在游戏被启动、被观察、截图被存进 production/qa/evidence/ 之前，都不算关闭。
它还专门补了一句：解析通过不等于跑过。
这话在游戏开发里是常识，在 AI 辅助开发里是奢侈品。因为让 agent 真的去启动一个游戏、等它渲染、截一张图、再判断这张图对不对，比让它跑一遍单元测试贵得多，也麻烦得多。
更值得注意的是它的适用范围：这条规矩在每一个 rigor 档位都成立，包括 minimal。在 minimal 档里，自动化测试可以豁免，但「看一眼」不行。
这个取舍很懂行。测试可以省，眼睛不能省——因为游戏是做给人看的，不是做给断言看的。
至于为什么仓库里一个游戏都没有，文档也给了解释：这是给你克隆去开自己项目的模板，别人的游戏躺在你的仓库里，那叫杂物，不叫证据。
这话说得挺刻薄，但我同意。
它想解决的问题，其实是「没人管你」
把上面几节串起来看，这个项目的真正卖点不是 49 个 agent，而是那套约束。
15 个 hook，14 条规则，一堆质量门，一套「你不跑起来看一眼就不许关 story」的规矩。这些全是刹车。
而单人开发的通病，恰恰是刹车失灵：没有代码评审，因为你既是作者又是评审；没有设计评审，因为设计文档只有你会看；没有 QA，因为 QA 的时间不如拿来加功能。
一个人做项目，最容易发生的不是「做不出来」，是「做出来一堆没人拦着的东西」。
所以这个项目的价值主张可以压缩成一句话：在你一个人干活的时候，假装有人管着你。
这个需求真实存在，而且比「AI 帮我写代码」深一层。写代码的 AI 满地都是，愿意在你硬编码一个 0.37f 的时候问一句「这个数哪来的」的 AI，不多。
对数量的推崇，以及它的代价
AI 工具这一行有个奇怪的计量单位：数量。
多少 agent、多少技能、多少工具、多少行提示词。数字越大，看起来越厉害，至于这些数字之间是不是互相重复、有没有一半用不上，没人问。
这个项目也没能免俗，49 和 74 就这么挂在最上面。
但它是少数几个愿意给数字配上代价的。那个 rigor 实验本质上就是在算账：多 29 份文档，换来的是什么？答案是「可追溯性」，代价是 58 分钟和一次垫底。
这个算法比数字本身有价值得多。因为「49 个 agent」听起来是资产，实际上也可能是负债——每一个 agent 都要读上下文、都要产出意见、都可能在你不想听的时候说话。
而 74 项技能意味着 74 条可能被误触发的路径。技能越多，越需要那 14 条规则去约束它们。
一个健康的配置，从来不是「我能加多少」，而是「我能删掉多少还照样跑」。
49 个意见，一个决定
文档里那句「你仍然做每一个决定」，是整份材料的定盘星，也是最容易被违背的一句。
想象一下真实场景：你只是想给跳跃手感调个数，结果总监 agent 问这符不符合愿景，主管 agent 问这会不会影响关卡节奏，QA agent 问你有没有截图证据。
三个问题都合理。三个问题加起来，你今天的进度是零。
这就是「给一个人配 49 个下属」的真实摩擦：瓶颈从产能转移到了决策带宽。
它对此的处理办法是给流程分级——就是那个 modes.rigor，以及 --review solo 这种临时降档的开关。这套设计承认了一个残酷的事实：不是每个改动都值得开一场评审会。
一个只有一种严格度的协作系统，最后一定会被人绕过。能调，才有人真的用。
配置与自定义
自定义那部分列了六件事：增删 agent、改 agent 提示词、改技能、加规则、调 hook 的严格度、选引擎。
引擎这一条值得单说：它给了 Godot、Unity、Unreal 三套 agent 配置，也可以一套都不用。
「一套都不用」这个选项很关键。它承认了不是所有人都用这三大引擎，也承认了硬塞一套引擎专属的 agent 反而会碍事。
另一条是流程重量：modes.rigor 和它底下的一堆旋钮放在 project.yaml 里。配合刚才那个实验一起看，这个设计就不只是配置项，而是一个明确的表态——重流程是可选项，不是正确选项。
平台支持：一段很实在的坦白
这一段把自己的实际情况都写了出来。
主要开发环境是 Windows 10 配 Git Bash。hooks 和脚本同时在 macOS 上测过——包括系统自带的 bash 3.2 和 BSD 那套工具，带 jq 和不带 jq 都算——以及在 Linux 上测过。
所有 hook 都用 POSIX 兼容的写法，比如用 grep -E 而不是 grep -P，缺工具的地方还留了兜底。
然后是一句让人意外又诚实的坦白：notify.sh 用 PowerShell 发 Windows 通知，在其他平台上是个空操作——macOS 和 Linux 的桌面通知还没接。
翻译一下：在 Mac 上，那个负责提醒你的东西，安安静静，什么都不做，也不报错。
这不算 bug，这是「还没做」，而且它老老实实写在文档里。很多项目会在这里写一句「跨平台支持」，然后让你自己去发现通知从来没响过。
许可与费用
MIT。赞助两个入口，一次性打赏和 GitHub 的持续赞助。
用途写得很具体：维护技能、加新 agent、跟上 Claude Code 和引擎 API 的变化、回社区的问题。
最后这条「跟上 API 变化」才是这类项目真正的成本所在。49 个 agent、74 项技能，全靠提示词和脚本撑着，上游改一次工具调用格式，这边就得跟着改一圈。这不是一锤子买卖，是一直要人盯着的活。
最后
回到开头那笔账：49 个下属。
大多数人看到这个数字的第一反应是「哇」，第二反应是「我用得上吗」。
它自己的实验给了答案的一半：把流程调到最重，你得到的是一堆可追溯的文档，和一个被盲评排到最后的游戏。
另一半答案是那条规定：改了玩家能看到的东西，就得把游戏跑起来看一眼。
这两条放在一起，其实已经把这个项目说完了——它不是让你多雇 49 个人，它是让你没法一个人糊弄过去。
至于那 72 和 74 的差额，我建议下次更新时顺手对齐一下。毕竟一个连门牌都写错的工作室，再怎么有 49 个员工，也会有人在背后嘀咕。