devgo.cn如果你让 AI 写代码，它写出来的代码能跑，但游戏好不好玩它根本不在乎。这是我在两个月里踩过最大的坑，也是我最终把整个开发流程拆成 15 个 AI 部门的原因。
我的本职工作是漏洞评估，游戏是业余项目。过去两个月，我用 Claude Code 做了 7 款 Android 游戏，大部分代码不是我写的。整个系统是一个主会话当"制作人"，下面挂 15 个子代理，每个扮演一个部门：游戏设计、编程、QA、试玩评论、发布、广告、数据分析等等。当我说"第三关太简单了"，制作人会安排设计师改数值，程序员把数值写进代码，QA 用自动玩家跑通关率，评论员以"冷启动"状态试玩。我最后在真机上跑一遍，说行或不行。
这套系统从 8 月 23 日启动，最初 10 个部门，现在 15 个。先说数字：7 款游戏，有的已上 Google Play，有的还在封闭测试。第一次跑完整流程时，一个推币机游戏的经济系统在 10 分钟模拟里产出了 315 万枚金币，三轮调整后中位数降到 1 万，落在目标区间内。有一次子代理在用量限制时挂掉，一条消息就把它连同完整上下文拉回来了，什么都没丢。过去 30 天广告收入是 152 日元，差不多 1 美元。我故意把最后这个数字写出来——部门化让开发变快了，但对"被发现"毫无帮助。
为什么要把流程拆开？一开始我把所有事交给一个会话，出了两个问题。第一，它给自己批改作业。让写代码的会话同时写测试，测试必然通过，因为测试就是照着代码写的。第二，没人问"这游戏好玩吗"。写完代码后，Claude 关心的是代码是否符合规格，不关心关卡是否无聊。要让这个问题被问出来，必须有个站在别处的人。
所以我把每个视角拆成独立子代理。在 Claude Code 里，.claude/agents/ 下的一个 Markdown 文件就是一个子代理，每次启动都是空白上下文。对评论者来说这正好——它看不到作者的假设，因为根本没接触过。
最关键的决定是按问题拆分，而不是按产出拆分。我第一次尝试按产出分：一个写代码，一个做图，一个写文案，几天就崩了。拿球的弹射角度举例：原版游戏用什么角度？我们该用什么角度？角度怎么进代码？弹跳时放什么音效？这个角度对通关率有什么影响？这是五个问题，按产出拆分会把五个问题全塞进一个部门。
于是每个部门只负责一个问题：规格分析师负责"原版游戏到底怎么运作"，游戏设计师负责"什么适合我们的游戏"，程序员负责"怎么实现"，UI 和手感部门负责"应该是什么感觉"，QA 负责"有没有坏、数据怎么说"，试玩评论员负责"好不好玩"。拿不准该交给谁时，就问谁回答这个问题。部门之间的地盘之争基本消失了。
后来我加了五个部门。最初十个部门全在"制作"侧，跑了一阵发现发布后没人管。测试员给一款游戏发了九条反馈，我一条都没看到，因为没人负责读反馈。广告连续两天零展示，原因是自己代码里的一道闸门，没人跨应用看数据。一款游戏每天两个新安装，但没人管商店页面。所以我加了商店优化、运营和玩家支持，还加了网络研究员和浏览器操作员来处理没有 API 的管理后台。
制作侧第一天就齐了，漏洞全在发布之后。我觉得能看到这个洞，纯粹因为部门被写成了一张表，空行很难忽略。
这套思路最值钱的地方在于：把"质量"拆成"符合规格"和"好玩"两个独立问题，让不同上下文的人分别回答。你不需要 15 个部门，但至少需要一个"没看过代码"的评论者。这个模式能直接用到任何 AI 辅助开发流程里——写代码的、写测试的、写文档的，各用各的会话，别让一个人既当运动员又当裁判。坑在于：部门越多，协调成本越高，而且 AI 不会帮你解决"没人知道你的产品存在"这件事。我的广告收入 1 美元就是证明。
完整配置、具体步骤和踩过的坑，我发在 newsletter 里了。这里讲的是思路，不是教程。如果你也在用 AI 做产品，试试把"好不好玩"这个问题交给一个从没见过代码的家伙。
内容与图片版权归原作者所有 · 原文: https://dev.to/rudycandy/i-run-a-one-person-game-studio-on-claude-code-two-months-7-games-about-1-in-ad-revenue-4j37