一个人开发游戏太难？这个开源项目给 Claude Code 配了 49 个 AI 员工，组建完整游戏工作室

一个人开发游戏，最难的地方可能不是写代码，而是你必须同时扮演程序员、游戏策划、美术设计师、测试工程师，甚至还要负责项目管理。

比如你准备开发一款 2D Roguelike 游戏。

刚开始，你可以让 Claude Code 帮忙编写角色移动、敌人 AI、技能系统。代码生成得很快，几个小时就能搭出一个原型。

但项目稍微复杂一点，问题就来了：

战斗系统写好了，却发现数值设计没有统一标准。
新增一个技能，可能影响装备、敌人和 UI 等多个模块。
AI 不断生成代码，却没人检查架构是否合理。
游戏功能越来越多，设计文档却一直没有更新。
单元测试通过了，实际运行时界面可能还是错位的。

这些问题并不是单纯增加几个 Prompt 就能解决的。

游戏开发本身就是一项需要多角色协作的工程。即使 AI 能够完成大量编码工作，也需要有人负责设计决策、任务拆分、质量检查和进度管理。

最近看到一个挺有意思的开源项目：Claude Code Game Studios。

它尝试把一套完整的游戏工作室组织结构搬进 Claude Code，让一个开发者也能调用不同职责的 AI Agent，按照游戏开发流程协作。

项目提供了 49 个专业 AI Agent、74 个工作流 Skills，覆盖游戏策划、程序开发、美术、音频、剧情、测试和发布等环节。

不过，这里的“49 个 AI 员工”需要正确理解：它们是 49 个预定义的专业 Agent 角色，并不意味着同时运行 49 个独立模型实例。

一、给 Claude Code 建立一套游戏工作室组织架构

项目最有意思的设计，是把传统游戏工作室的管理结构映射到了 AI Agent 系统。

一般使用 Claude Code 时，我们习惯直接提出需求：

“帮我实现一个角色技能系统。”

AI 可能立即开始分析文件、编写代码、修改配置。

但在实际游戏项目里，技能系统往往涉及多个专业领域。

策划需要确定技能规则，程序员需要考虑系统架构，UI 设计师需要处理技能显示，测试人员还要验证各种边界情况。

Claude Code Game Studios 为这些职责设计了三层组织结构。

第一层：工作室总监

最高层设置了三个核心角色：

Agent	主要职责
creative-director	负责创意方向和游戏整体体验
technical-director	负责技术架构和工程决策
producer	负责项目推进和跨部门协调

例如，当开发者准备加入一个复杂的新玩法时，创意总监可以从游戏整体设计角度审查这个需求，技术总监则负责评估实现方案。

如果一个修改同时影响多个部门，可以通过 Producer 协调相关工作。

第二层：部门负责人

这一层包括游戏设计、程序、美术、音频、叙事、QA、发布管理、本地化等负责人。

比如：

game-designer：负责游戏机制和系统设计。
lead-programmer：负责程序开发与技术实现。
art-director：负责美术方向。
qa-lead：负责测试质量。
narrative-director：负责叙事设计。

它们负责各自领域的工作组织和专业判断。

第三层：专业执行人员

真正执行具体任务的是各类 Specialist。

例如：

gameplay-programmer 负责游戏玩法代码，level-designer 负责关卡设计，ui-programmer 负责界面实现，performance-analyst 负责性能分析。

还有网络程序员、工具程序员、技术美术、音效设计师、安全工程师、无障碍设计专家等角色。

这套结构解决的核心问题，是让不同类型的任务拥有明确的责任边界。

AI 不再只是接到需求就写代码，而是先确定谁负责设计、谁负责实现、谁负责检查。

二、49 个 Agent 如何协作？关键是任务委派机制

如果只是定义 49 个角色 Prompt，其实意义有限。

真正有价值的地方，是项目设计了 Agent 之间的协作规则。

主要包括四种机制。

垂直委派

总监可以将任务交给部门负责人，部门负责人再委派给专业执行 Agent。

例如，开发一个战斗系统时，可以由技术负责人协调相关程序开发任务。

同级协商

同一级别的 Agent 可以互相咨询，但不能随意替其他部门作出最终决定。

比如，程序 Agent 可以咨询 UI Agent 的意见，但不能直接决定整个界面的设计规范。

冲突升级

当不同角色出现意见冲突时，可以交给共同的上级处理。

设计问题交由创意方向负责人协调，技术问题交由技术负责人协调。

跨部门变更传播

游戏开发中，一个设计修改经常影响多个模块。

项目通过 Producer 协调跨部门变更，避免不同角色只关注自己的局部任务。

此外，Agent 还受到职责边界约束，未经明确委派，不应随意修改其他领域的文件。

这类机制的意义在于减少多 Agent 开发中的责任混乱。

不过，它仍然依赖 Claude Code 对角色指令的执行，不能等同于传统软件系统中的强制权限隔离。

三、74 个 Skills：把游戏开发流程变成可调用的命令

除了 Agent 角色，项目还提供了一整套工作流 Skills。

它们覆盖从游戏创意到正式发布的不同阶段。

开发者可以在 Claude Code 中通过斜杠命令调用。

例如：

命令	作用
/start	初始化并引导项目流程
/brainstorm	进行游戏创意讨论
/design-system	设计具体游戏系统
/create-architecture	制定技术架构
/create-epics	拆分大型开发任务
/create-stories	创建具体开发任务
/dev-story	执行开发任务
/code-review	进行代码审查
/qa-plan	制定测试计划
/release-checklist	检查发布准备工作

这里有一个重要变化。

传统 AI Coding 的工作方式通常是：

需求 → AI 生成代码 → 开发者检查。

而 Claude Code Game Studios 希望建立更完整的链路：

需求 → 设计 → 架构 → 任务拆分 → 实现 → 测试 → 审查 → 发布。

每个阶段都有对应的工作流，开发者不必反复编写长篇提示词来解释整个项目流程。

多 Agent 联合处理一个功能

项目还提供了专门的团队协作命令，例如：

/team-combat /team-narrative /team-ui /team-audio /team-level /team-qa /team-release

这些命令面向具体领域的跨角色协作。

例如，战斗系统涉及游戏机制、代码实现、视觉反馈和测试验证，使用团队工作流可以将相关专业角色组织起来。

它的价值不是让更多 AI 同时输出内容，而是让一个复杂功能拥有相对完整的开发与审查过程。

四、支持 Godot、Unity 和 Unreal Engine

游戏开发与普通 Web 开发有明显区别。

不同游戏引擎使用不同的编程语言、资源管理方式和工程结构。

Claude Code Game Studios 针对三种主流引擎准备了专业 Agent。

游戏引擎	专业支持方向
Godot 4	GDScript、Shader、GDExtension
Unity	DOTS/ECS、Shader/VFX、Addressables、UI Toolkit
Unreal Engine 5	GAS、Blueprints、Replication、UMG/CommonUI

比如，Godot 开发中会涉及场景文件、资源文件和 GDScript；Unity 项目可能需要处理 C#、ECS 和 Addressables；Unreal 项目则涉及 C++、Blueprints 和 Gameplay Ability System。

项目还针对不同引擎的目录结构配置了相应规则。

这比单纯要求一个通用 AI“熟悉所有游戏引擎”更具体。

但要注意，这些 Agent 提供的是面向引擎的开发指导与协作配置，并不能替代游戏引擎本身。

开发者仍然需要安装对应引擎，并通过实际运行验证游戏效果。

五、真正实用的部分：自动化质量检查

AI 生成代码的速度很快，但代码质量不一定稳定。

尤其在游戏项目中，很多问题不会立即表现为编译错误。

比如：

关键参数被直接硬编码。
资源文件命名不符合规范。
JSON 配置出现格式错误。
游戏逻辑与 UI 代码过度耦合。
修改了设计文档，却没有同步其他系统。

项目为此提供了 Hooks 和按路径生效的 Rules。

其中包括 15 个事件 Hooks 和 14 组路径范围规则。

例如：

validate-commit.sh 可以在相关 Git 提交操作前检查硬编码、TODO 格式、JSON 有效性等问题。

validate-assets.sh 可以在资源文件修改后执行相关验证。

validate-write.sh 可以对不符合项目规则的写入操作给出警告。

针对游戏代码，规则还会区分不同目录。

例如，玩法代码强调数据驱动和时间步长处理；网络代码关注服务端权威性、消息版本和安全；UI 代码关注状态管理、本地化和无障碍要求。

这些检查不能保证游戏没有 Bug，但能帮助开发者在日常修改中尽早发现一些常见工程问题。

测试通过，还不代表游戏真的正常

这个项目有一个比较符合游戏开发实际情况的要求：

玩家能看到的功能，必须通过实际运行和视觉检查。

原因很简单。

一段 UI 代码可能通过了静态检查，甚至单元测试也没有报错，但游戏启动后，菜单可能显示在屏幕外面。

因此，对于影响玩家可见内容的开发任务，工作流要求启动游戏、观察运行结果，并保留截图证据。

六、不是流程越多越好：项目提供三档开发模式

多 Agent 系统有一个容易被忽略的问题：流程本身也会产生成本。

如果每增加一个简单功能，都要经过完整设计、架构审查、文档生成和多角色讨论，独立开发者可能会把大量时间花在管理 AI 上。

Claude Code Game Studios 为此设计了三种严格程度。

模式	适用情况	流程特点
minimal	游戏原型、Game Jam	文档少，流程轻量
standard	常规项目开发	平衡设计、实现和测试
full	复杂或长期项目	更完整的文档与审查要求

默认采用 minimal。

这个选择其实很合理。

对于独立开发者，最初的目标通常是尽快做出可玩的原型，验证核心玩法是否有趣。

如果游戏机制还没有得到验证，就投入大量精力编写完整设计文档，可能并不划算。

项目还提供了一个有意思的实践对比：在不同流程严格程度下开发游戏时，更重的文档流程增加了前期成本，却没有必然带来更好的游戏体验。

这说明 AI Agent 的数量和流程复杂度，并不能直接代表最终产出质量。

如果只是开发一个简单的 2D 小游戏，轻量模式通常更合适。

当项目规模扩大、协作复杂度上升时，再逐步提高流程要求。

七、如何开始使用？

Claude Code Game Studios 本质上是一个项目模板，并不是需要单独运行的游戏开发平台。

使用前需要准备 Git、Claude Code、Python 3，以及用于执行 Hooks 的 Bash 环境。

首先克隆仓库：

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

然后在项目根目录启动 Claude Code：

claude

进入 Claude Code 后执行：

/start

系统会引导开发者确定当前项目阶段，例如只有初步想法、已经有明确设计，或者准备接入已有项目。

如果想从游戏创意开始，可以使用：

/brainstorm

如果已有项目，也可以通过：

/project-stage-detect

分析当前项目所处的阶段。

项目的主要配置集中在根目录的 project.yaml 中。

其中 modes.rigor 用于控制流程严格程度，还可以进一步调整文档密度、QA 级别、审查模式和团队规模等设置。

需要特别注意的是，Claude Code 应当从包含 CLAUDE.md 和 project.yaml 的项目根目录启动。

如果直接从 src/ 等子目录启动，可能无法正确加载项目配置的 Hooks 和权限规则。

八、49 个 AI 员工，能不能真正替代游戏开发团队？

这是理解这个项目时必须明确的问题。

Claude Code Game Studios 的定位是协作型开发框架，而不是完全自主运行的游戏制作系统。

默认工作方式强调由开发者掌握决策权。

Agent 会先提出问题，展示可选方案及其优缺点，再由开发者决定采用哪一种。

在默认协作流程下，关键修改需要获得确认。

项目也提供不同自动化程度的配置，但自动化程度越高，开发者越需要关注执行过程和结果检查。

另外还有几个现实限制。

首先，49 个 Agent 不代表 49 个真实专业人员。

这些角色共享大模型能力基础，通过不同的职责定义和工作流完成任务。

角色划分可以改善任务组织，但不能保证每个专业判断都正确。

其次，多 Agent 协作会增加模型调用和上下文成本。

复杂任务可能涉及多轮分析、讨论和审查。对于规模较小的项目，过多流程反而可能影响开发节奏。

第三，美术、音频和游戏体验仍然需要实际验证。

定义了美术总监或音效设计师 Agent，不意味着系统就具备完整的专业资产生产能力。

游戏是否好玩、操作手感是否合理、视觉风格是否统一，仍然需要开发者结合实际游戏进行判断。

最后，工作流规范不能替代真正的工程测试。

Hooks 和 Rules 能覆盖部分静态规则与操作检查，但运行时错误、性能问题、引擎兼容性以及复杂玩法 Bug，仍然需要相应测试和调试。

九、哪些开发者适合尝试？

我认为这个项目比较适合三类人。

第一类是正在使用 Claude Code 开发独立游戏的开发者。

如果你已经能够让 AI 编写代码，但项目逐渐出现设计混乱、模块耦合、文档缺失等问题，可以考虑引入部分 Agent 和 Skills。

第二类是希望学习规范化游戏开发流程的人。

项目把游戏设计、架构、任务管理、QA 和发布流程拆分成了明确的角色与操作步骤。

即使不启用全部 Agent，也能借此理解一套游戏开发流程应该包含哪些环节。

第三类是已经有游戏原型、准备长期维护项目的小团队。

随着项目扩大，统一的设计文档、编码规则和任务审查机制可能比单纯提升代码生成速度更有价值。

当然，如果只是想快速制作一个简单小游戏，完全没必要一开始就启用完整工作室结构。

可以先从 minimal 模式开始，只使用当前真正需要的工作流。

最后

Claude Code Game Studios 让我觉得有意思的地方，不是它定义了 49 个 AI 角色，而是它尝试解决 AI Coding 中一个更深层的问题：

当 AI 已经能够快速完成大量开发任务时，谁来负责组织这些任务，并保证它们最终组成一个一致、可维护、可运行的游戏？

单个 AI 助手擅长处理具体需求，但一个完整游戏项目还需要持续的设计管理、技术决策、质量检查和版本迭代。

这个开源项目提供了一种思路：把游戏工作室的组织方式、开发规范和协作流程编码成 Agent、Skills、Hooks 与 Rules，让开发者可以按需调用。

它不会让一个人瞬间拥有真正的 49 人团队，也不能保证自动生成一款高质量游戏。

但对于已经开始使用 AI 开发游戏的人来说，它提供了一个值得研究的方向。

未来个人开发者的能力，可能越来越取决于能否合理组织 AI 完成复杂工程，而不只是能否写出更好的提示词。

而 Claude Code Game Studios，正是在尝试把这种组织能力变成一套可以复用、可以修改的开源工作流。

一个人开发 游戏 太难？这个开源项目给 Claude Code 配了 49 个 AI 员工，组建完整 游戏 工作室