用 AI 做 游戏 ，光写需求就很累？我想到一个省力的办法

最近，我和 AI 聊了一个做游戏时很实际的问题：我该怎么写提示词？

它给了我一个建议：把“感觉词”换成“可观察的行为”。

比如，“Boss 更有压迫感”，可以拆成起跳前蓄力、地面出现预警、落地时产生冲击波。这样一看，确实比一句“帮我优化一下”清楚多了。

但我接着问了一句：

你说得对，但是一下打这么多字很累的。

我知道需求应该具体，可让我每次都从头写清楚触发条件、执行流程、数值和验收标准，还是挺费劲。尤其有时候，我自己也只有一个大概的感觉。

于是，我们聊出了一个我准备尝试的流程：

我先说想法，让 AI 给出具体大纲；我挑选和修改，再让它整理成开发需求。

先交代一下进度：这套流程是刚聊出来的，我还没在游戏项目里完整验证。下面的 Boss 案例是演示，想和大家分享的是这次对话带给我的思路。

一、先给我一个能修改的方案

以前想到“让 AI 帮我开发”，我很容易直接跳到写代码这一步。

但在写代码之前，其实还可以让它帮我做一件事：把脑子里模糊的想法展开，摆在我面前。

比如，我只说：

Boss 二阶段太平淡了，我想让它更有压迫感，但别做得太复杂。先给功能大纲，暂时不要写代码。

这里的“先不要写代码”很关键。我还在选方案，得先弄清楚自己到底想做什么。

大纲也不用写成几十页策划案。先回答几个问题就够了：什么时候触发、发生什么、玩家怎么看出来、怎么判断做成功了。

二、拿“Boss 更有压迫感”走一遍

假设 AI 给出这样一版候选大纲：

触发： Boss 首次降到半血时，进入转阶段流程。

动作： 暂停当前攻击，Boss 飞离画面。

预警： 玩家脚下出现红圈，追踪一段时间后固定。

落地： Boss 落向红圈，产生冲击波和轻微震屏。

强化： 落地后缩短技能冷却。

可选： 全屏闪光、专属音效、召唤额外小怪。

这时，我终于有东西可以选了。

我可以直接回复：

保留飞天、红圈和落地冲击波。删掉全屏闪光和额外小怪。红圈追踪 1 秒，固定 0.5 秒后落地。二阶段只缩短技能冷却，具体比例先给建议。

这段回复就比从零写整套规则轻松得多。

有些选择，我在看到候选方案以前，根本想不到。看到“全屏闪光”以后，却能马上判断：这个效果我不想要。

修改完，再让 AI 把确认的内容整理成开发提示词。涉及现有项目时，还要补上引擎版本、相关脚本和节点结构，让执行代码的 AI 核对。

这样交过去的内容，既有我最初想要的体验，也有逐步确认下来的行为和规则。

三、为什么我觉得这个流程值得试

从空白开始描述，和对着方案提意见，是两种不同的负担。

让我直接回答“你想要什么样的 Boss”，我可能只能说：凶一点，出场有气势一点。

但给我几个具体选项，我就能说：这个可以，那个太花了，这一步太快，玩家可能来不及躲。

这些判断，其实也在表达需求。

所以，我想把 AI 的作用往前挪一步：让它先帮我列出可能的实现方式，再由我决定哪些进入游戏。

我也不必一开始就装作什么都想清楚了。没想清楚的地方，可以在看方案、改方案的过程中慢慢补齐。

四、AI 写得很详细，也要自己筛一遍

这里有个我会特别留意的问题：AI 可能顺着一句“更有压迫感”，越加越多。

飞天、变身、召唤、场景破坏……看着挺热闹，但做一个二阶段，可能就扩成了半个新系统。

所以，拿到大纲以后，我会先检查三件事。

第一，方向对不对。 我想要的是攻击前的紧张感，还是更快的战斗节奏？效果多，不一定符合目标。

第二，范围大不大。 哪些是这次必须做的，哪些可以以后再加？先选一个能跑起来的版本。

第三，能不能检查。 “成功进入二阶段”还是太宽泛，可以继续写成：半血时只触发一次，转阶段期间不释放其他技能，落地伤害只结算一次。

具体数值也一样。AI 可以建议，但伤害高不高、预警够不够，最后还得放进游戏里试。

五、我准备保存下来的提示词

每次重新组织这些要求也挺麻烦，所以我把它整理成了一段可以重复用的话：

你是我的游戏需求整理助手。我会用简短、口语化的方式描述想法，请先整理功能大纲，暂时不要写代码。

把“更爽、更好看、更有压迫感”等描述，转成玩家能看到、听到或操作到的具体行为。

大纲包含：目标、触发条件、执行流程、关键参数、视听反馈、验收标准。

我没说明的内容可以提出建议，但请标明“建议”或“待确认”。

优先给出工作量较小、能先跑起来的版本，额外效果列为可选项。

每条需求编号，方便我回复保留、删除或修改哪一条。

只问会明显影响方案的问题，每轮最多三个；不要擅自增加系统。

我的想法是：【在这里描述想法】

看完大纲，我只要继续说：

保留第 2、3、4 条，删除第 6 条。把需要我决定的数值单独列出来。

确认以后，再补一句：

根据确认后的大纲，整理成可交给开发 AI 的完整提示词，包含背景、需求、修改范围和验收标准。未知的引擎版本、节点及代码结构列为待补充，不要编造；建议里未被我确认的内容不要加入。

同一段对话里，后续可以直接继续描述和修改。换一个 AI 执行时，就把最终需求和相关项目资料一起带过去。

六、下一步，拿一个小功能试试

我现在还不能说，这套流程一定能省多少时间。

但这次聊天让我意识到：写需求的过程，也可以让 AI 参与。自己一时说不清楚，可以先请它给一个可修改的版本。

下一次修改游戏时，我准备先挑一个小功能试试，记录大纲哪里跑偏、我删掉了什么，以及实际做出来是不是想要的效果。

先从一句话开始：

“这是我的想法。你先给大纲，我来选。”