用AI开发过程中，我学着说清需求

最近，我打算做一个网页小游戏：三消加肉鸽，玩家一关一关往前推。这个 Demo 几乎全程依靠 AI 开发，但最先让我卡住的，竟然不是代码。

之前在火车上，我看到一位开发者分享他的做法：动手之前，先和 AI 对一遍 PRD。我也照着试了试，然后很快发现了一个老问题——我说不清楚自己的需求。

“三消加肉鸽”听起来像是一个明确的方向，真正往下聊，却有一堆问题等着回答：三消怎样影响战斗？每一关要让玩家做什么选择？随机性放在哪里，才不会让人觉得只是碰运气？这些东西不想清楚，AI 就只能在我的模糊描述里猜。

我一直担心自己的认知会限制 AI 的发挥。如果我只知道自己想做一个“好玩的游戏”，却说不出什么叫好玩，再强的模型也很难替我做出准确的判断。所以这次我尽量让 AI 反过来问我：哪里还没定义，哪些决定会影响后面的设计？

这让我想到最近的一场面试。面试官给了一个具体的业务场景，问我怎么用 Skill 完成其中的自动化。我没答上来，并不是因为不知道 Skill 是什么，而是当时没意识到这个业务也可以用 Skill 来做，更不知道该怎样把业务拆成一个结构化的流程。

我说的“软实力”，大概就包括这种能力：先理解业务里的人在做什么、想解决什么，再找出哪些步骤能被明确描述、重复执行，最后才谈用什么工具去实现。会使用 AI 或 Skill，只是起点；把模糊的问题整理成可执行的需求，才是我现在想练习的事。

我们来回讨论玩法、流程和实现，才逐渐整理出一份勉强像样的 Demo PRD。说是 PRD，其实很多内容仍是等待验证的假设。开发过程中我又改过几次，因为真正看到游戏跑起来之后，我对它的理解也变了。现在想来，这或许正是做原型的意义：先把想法变成能玩的东西，再用体验修正想法。

开发时，我也模仿那位开发者，安排了多个 Agent：一个负责决策、审查和验收，其他负责实现。我把工作拆成交互与视觉资源、游戏逻辑两部分；GPT 负责前者，Claude 负责后者，想试试各自擅长的地方。不过有分工，不等于有并行。实际开发中，许多工作还是要等前一部分确定之后才能继续。

于是我对 subagent（子 Agent）产生了兴趣。我后来读了一些关于上下文设计的资料，才慢慢理解它和另外两种做法的区别：just-in-time 是需要什么信息时再去读取；compaction 是把过长的对话压缩成摘要，让任务继续；subagent 则是把边界清楚的任务交出去，让主 Agent 只接收整理后的结果。

我当时的理解很简单：让每个 Agent 少带一点无关信息，主 Agent 也不用把所有细节都塞进自己的上下文。听起来既能缓解上下文压力，也可能让工作更快。我还忍不住想：这些设计理解起来并不难，我怎么就没想到呢？当然，只是开个玩笑。我能做的是先学会在合适的地方用它们。

后来，我让 Agent 尝试调用子 Agent 并行开发，结果没有想象中顺利。Token 的消耗速度肉眼可见地增加，产出的效果也让我觉得差了点意思。是不是子 Agent 用了不同的模型？是不是任务拆得不够清楚？还是我又一次没把需求说清楚？我没有做对照实验，也没核实模型配置，所以现在不能把这些猜测当作原因。至少这次经历提醒我：子 Agent 可以减轻主 Agent 的上下文负担，但多个 Agent 同时工作，并不等于总 Token 用量一定更少。

说回游戏本身。Demo 玩下来还行，已经有了一个能体验的雏形；交互和演出仍有很大改进空间。比起完成了一个小游戏，我这次更在意的是自己走过的过程：先把需求拿出来讨论，先计划再执行，然后在开发中学着给 Agent 划分任务和上下文。

这些办法都不能替我决定什么样的游戏才好玩。最后还是得打开 Demo，亲自玩一局，再想清楚下一局为什么值得玩。