用 Claude Code 组织游戏开发团队

把一次 Claude Code 会话变成游戏工作室，靠的不是让模型多写几段代码，而是给它安排角色、权限、交接流程和验收标准。Claude Code Game Studios 提供了 49 个代理、74 个技能，以及配套的规则和检查脚本，试图把个人 AI 开发变成有分工的协作。

但原文最有价值的结论，反而是流程不能越重越好：作者用同一份需求做了四个游戏，较重流程没有换来更好的评价。因此，这个项目默认选择轻流程，同时坚持一条底线：玩家看得见的改动，必须实际运行并留下截图。

49 个代理，解决的是谁负责、谁拍板

普通 AI 编程会话容易把设计、实现、测试混在一起。功能能跑，就可能被当作已经完成；某次局部修改是否偏离游戏方向，也缺少专门的检查环节。

这个模板把职责分成三层：顶层是 creative-director、technical-director 和 producer，分别负责创意、技术与生产协调；中层是设计、编程、美术、音频、叙事、QA、发布和本地化负责人；底层再分出玩法、引擎、网络、UI、性能、安全、无障碍等专员。

关键不只是角色名称，还有决策边界。同级代理可以互相咨询，但不能替其他领域做有约束力的决定；争议向共同上级升级，跨部门变更由 producer 协调。没有明确委派，代理不能修改职责范围之外的文件。

角色数量是配置规模，职责和验收边界才是协作机制。

模型分配也需要看清：三个总监在 frontmatter 中指定 Opus，lead-programmer 和另外十五个专员指定 Sonnet，其余三十个代理继承当前会话的模型。它不是同时启动 49 个高价模型的固定套餐，层级也不等于计费档位。

默认协作协议要求代理先提问，再给出 2-4 个带优缺点的选项，由用户决定，展示草稿并获得确认后才写入。不过，guided、autonomous 自动化配置以及 Claude Code 自身的 auto mode，会减少部分确认。原文强调的用户控制，需要结合实际配置理解。

为什么默认选 minimal，而不是把流程拉满

项目根目录的 project.yaml 是共享配置来源，记录引擎、命名约定和流程要求。/start 会根据项目处于没想法、模糊构思、明确设计还是已有代码等阶段，引导进入合适的工作流。

其中最重要的参数是 modes.rigor，提供 minimal、standard、full 三档。它同时控制六项设置：workflow、docs.density、qa.level、story_granularity、review_mode 和 team.size，分别涉及设计文档要求、文档密度、测试证据、任务粒度、评审范围和团队规模。

minimal 是默认值，不要求 GDD，也就是游戏设计文档，采用简短文档、最少 QA 证据和单人评审。standard 要求 5 个 GDD 章节，full 要求全部 8 个章节，并提高文档、证据和总监评审要求。

默认轻量不是单纯追求速度。作者按不同 modes.rigor 档位，用同一份需求制作了四个游戏，并统计写出第一行游戏代码前产生的文档。四个版本都做出了可运行、经过测试的游戏，但两位盲评者和一次人工试玩都把 standard 版本排在最后。原文称，额外的 29 份文档带来的是可追溯性，而不是更好的游戏。

这组结果支持谨慎增加流程，但不能证明文档普遍无用。给定材料没有展示完整档位数据、评价标准和成本记录，也没有提供游戏成品供复核。

流程还可以局部加码。system_overrides 能让战斗系统执行更严格的要求，其余部分保持轻量；testing.strict 则按 logic、integration、visual、UI、config 分别决定缺少证据时阻断还是警告。

下面这组命令解决共享配置与个人偏好分别存放的问题：

/settings                              # 查看生效配置
/settings modes.review_mode            # 查看单项设置
/settings modes.rigor=full             # 写入 project.yaml，团队共享
/settings --local modes.review_mode=solo   # 写入 project.local.yaml，仅个人使用

要看最后一行的 --local：个人评审偏好写入被 Git 忽略的 project.local.yaml，不必改动团队配置。modes.automation 独立于 rigor，也允许个人覆盖；流程严谨程度与 AI 多久停下来询问，是两件事。

测试通过之后，还得把游戏打开看一眼

对 UI 开发者而言，原文最值得借鉴的是完成标准：只要任务改变了玩家能看见的内容，就必须启动游戏、观察效果，并把截图留在 production/qa/evidence/。

解析检查通过，不算实际运行。自动化测试通过，也不能证明菜单没有画到屏幕外。这条要求覆盖所有 rigor 档位，包括可以豁免自动化测试的 minimal。

可以减少文档，不能省掉对实际画面的检查。

模板还提供 15 个事件钩子、14 条按路径匹配的规则和 62 份文档模板。hooks 目录里的 18 个 Bash 脚本，包括上述 15 个钩子、两个辅助脚本，以及一个需要自行接入的诊断脚本，不能把两组数字当作矛盾。

使用时有几处会直接影响机制是否生效。Claude Code 应从包含 CLAUDE.md 和 project.yaml 的项目根目录启动；原文称，从 src/ 等子目录启动会跳过项目钩子、禁止规则和先询问权限模式。Python 3 负责为每个技能和钩子读取配置，缺失时设置会静默回退到默认值；提交暂存的数据 JSON 时，则会因无法验证而被阻断。

运行还需要 Bash，推荐安装 jq。Claude Code 推荐使用原生安装器，也支持 npm install -g @anthropic-ai/claude-code，后者要求 Node.js 22+。引擎配置示例为 /setup-engine godot 4.7，另有 Unity 和 Unreal 对应代理集。

模板自身也能测试。下面的命令用于检查修改后的技能和代理：

/skill-test static [name]     # 结构检查器，执行 7 项合规检查
/skill-test category [name]   # 按类别评估质量
/skill-test spec [name]       # 检查行为规格断言
/skill-test audit             # 查看技能与代理的覆盖报告
/skill-improve [name]         # 测试、修复、重测，根据评分变化保留或回退

注意 /skill-test 的检查对象是框架配置。游戏测试仍然放在 tests/，两者不能互相替代。

我的判断

我认可它把职责、配置和验收标准写进仓库的方向。尤其是可见改动必须运行观察，以及共享配置与个人配置分离，都比要求 AI「认真检查」更具体，也更方便追查问题。

但 49 个代理不会自动带来 49 人团队的判断力。原文没有提供角色越多、缺陷越少的对照证据，也没有给出多代理协调的完整耗时和调用成本。这部分应当视为一种组织方案，而不是已经验证的效率结论。

同样，四个游戏的比较更适合提醒我们控制流程成本，尚不足以支持所有团队都选 minimal。长期维护、多人交接、复杂联机项目可能需要更多可追溯信息，而文中实验并未充分检验这些收益。

与单代理配合少量规则和任务清单相比，这套模板提供了更完整的分工与检查入口，也增加了配置和维护负担。个人原型可以先借用轻流程与验收规则；等职责冲突、跨系统修改成为真实问题，再增加专门角色更合理。

能拿来做什么

• 如果你正在用 Claude Code 做独立游戏，可以从 /start 和默认 minimal 开始，先完成可玩的闭环，再对复杂系统使用 system_overrides 提高要求。
• 如果任务涉及菜单、HUD 或交互界面，可以把启动运行、观察画面、保存截图写进完成条件，同时用测试覆盖逻辑，分别验证行为和显示结果。
• 如果团队成员对 AI 确认频率、评审参与方式有不同偏好，可以参考 project.yaml 与 project.local.yaml 的分层方式，明确哪些要求共享、哪些设置允许个人调整。
• 如果要裁剪或新增技能，可以用 /skill-test 和 /skill-improve 检查模板行为，再运行游戏自身的测试，避免配置看起来完整却没有正确执行。