这是欧米的第414篇游戏开发原创分享。

点击关注↑ 解锁价值百万的「灵感生产线」

---

上一篇我们聊到，AI 做游戏，第一步最好不是直接写代码。

因为游戏开发里很多麻烦，并不是代码本身有多难，而是需求一开始没说清楚。你让 AI “帮我做一个塔防”，它确实能写出东西，但它写出来的东西，可能只是它脑子里默认的塔防。

敌人怎么走。塔怎么摆。子弹怎么命中。关卡怎么配置。数值怎么扩展。胜负怎么判断。

这些东西你不说，它就会自己补。

补得对，看起来就像它很懂你。补得不对，后面就会变成你不断返工。

所以我现在更倾向于一种做法：先别让 AI 开工，先让它帮你拆需求。

这一步看起来没有写代码那么有成就感，但往往决定后面能不能顺着做下去。

很多游戏想法，一开始都不是开发需求

我们平时说一个游戏想法，通常会说得很自然。

比如：

“我想做一个肉鸽塔防。”“我想做一个弹幕互动的战斗游戏。”“我想做一个像 Fez 那样的视错觉解谜。”“我想做一个休闲合成加经营的小游戏。”

这些话用来聊天没问题，用来介绍项目也没问题。

但它们还不是开发需求。

真正落到开发时，这里面几乎每个词都要继续拆。

“肉鸽”是什么意思？是随机地图，随机奖励，随机敌人，还是随机塔？是局内随机，还是局外养成？玩家每局失败后保留什么？随机内容来自配置表，还是运行时生成？有没有保底机制？有没有重复过滤？

你会发现，一个看起来很熟的词，落到开发里，可能对应很多种完全不同的做法。

“塔防”也是一样。

有些塔防是固定路线。有些塔防是自由寻路。有些塔只能摆在固定格子上。有些塔可以自由摆放。有些塔攻击是子弹飞行命中。有些塔其实是立即结算伤害，只是表现上播一个攻击动画。

玩家嘴里都是“塔防”，但程序实现完全可能不是一套东西。

所以直接让 AI 开工的问题就在这里。

你以为你说的是一个很明确的类型。但 AI 接收到的，其实是一堆没有展开的默认假设。

AI很适合帮你把模糊想法问细

这里反而是 AI 很好用的地方。

它不一定适合一上来就替你写完整系统，但它很适合先帮你把一个想法拆成问题。

比如你可以这样问它：

我想做一个竖屏 2D 塔防游戏，核心是固定路线、格子建塔、关卡推进。请你先不要写代码。先帮我把这个游戏想法拆成开发前必须确认的问题，按下面几类整理：1. 核心玩法2. 地图与路径3. 塔与子弹4. 敌人与波次5. 关卡配置6. UI 与结算7. 后续扩展风险每一类只列真正会影响开发结构的问题。

这个提示词里面最重要的一句，其实是：

请你先不要写代码。

这句话很有用。

因为很多时候你问 AI 一个开发问题，它会本能地往代码上走。你只是想讨论一下方案，它已经开始给你生成类、接口、方法了。

但在需求还没拆清楚之前，这些代码反而会干扰判断。

先把问题列出来，等于先把模糊的想法摊开。

你可能会看到类似这样的问题：

地图是固定路径还是自由寻路？塔是固定格子建造还是任意位置建造？敌人是否有飞行单位？子弹是否需要真实飞行过程？波次是否由配置表控制？关卡失败后是否保留收益？塔升级是局内升级还是局外养成？

这些问题本身不复杂，但它们会让你必须做选择。

而游戏开发早期最需要的，恰恰就是做选择。

拆需求不是越细越好，而是先拆到能开工

这里也要注意一点。

让 AI 拆需求，不是让它写一份几万字的策划案。

很多人一开始会让 AI 生成：

“完整游戏设计文档”“完整系统架构方案”“完整数值设计方案”“完整开发计划”

结果看起来很丰富，实际上很难用。

因为它会把所有可能性都列出来，什么都考虑一点，最后变成一份很大的文档。

但你真正要开工时，反而不知道第一步该做什么。

所以我觉得拆需求的目标其实很简单：拆到能开工就行。

比如第一版只是想验证塔防核心循环，那需求不用覆盖所有内容。

不需要一开始就讨论：

赛季系统。每日任务。皮肤系统。复杂天赋树。多章节剧情。新手七日目标。排行榜和社交。

这些都可以先放后面。

第一版真正要确认的，可能只有这些：

1. 敌人是否沿固定路径移动？2. 玩家是否只能在固定格子建塔？3. 第一版是否只做一种塔？4. 第一版是否只做一种敌人？5. 波次是否先写在简单配置里？6. 敌人到达终点是否扣除基地血量？7. 清完所有波次是否胜利？

这几个问题回答完，项目基本就可以开第一步了。

不完美，但够用。

AI 拆需求的时候，很容易把事情拆得很完整。人要做的，是把里面真正适合当前阶段的部分挑出来。

先拆“必须有”，再拆“以后可能有”

需求拆分里，一个很实用的方法是分层。

不要把所有需求放在一起。

可以先让 AI 按这几层拆：

第一层：DEMO 必须有第二层：第一版可以有第三层：后续版本再考虑第四层：现在明确不做

比如还是塔防项目，可以拆成这样：

DEMO 必须有：- 一张地图- 一条路径- 一种敌人- 一种塔- 基础攻击- 基地血量- 胜负判断第一版可以有：- 两到三种塔- 简单塔升级- 三到五种敌人- 关卡配置读取- 基础结算界面后续版本再考虑：- 天赋系统- 局外养成- 多章节地图- 特殊敌人机制- 随机奖励现在明确不做：- 联机- 排行榜- 复杂剧情- 皮肤系统

这个分层很重要。

因为 AI 很容易把事情往完整系统上扩展。

你说你要做塔防，它可能会顺手把商店、成就、存档、升级、技能、音效、设置界面都规划进去。

这些东西不是不能做，但不应该一开始就混进核心开发里。

对于独立开发者来说，早期最怕的不是想得不够多，而是第一版就被太多东西拖住。

先把“必须有”和“以后再说”分开，项目会清楚很多。

还要拆“玩法需求”和“工程需求”

很多需求看起来是玩法问题，最后会变成工程问题。

比如：

“塔可以升级。”

这句话听起来很简单，但开发时要继续拆：

塔升级是局内升级，还是局外升级？升级后是只加数值，还是会改变攻击方式？升级数据从哪里读取？升级消耗金币还是材料？升级按钮显示在哪里？升级时子弹表现要不要变化？升级是否影响已经发出去的子弹？

如果不拆，AI 可能会直接在塔脚本里写：

Tower.Upgrade:    level += 1    damage += 10

这当然能跑。

但如果你的项目后面要接配置表，这种写法很快就会不够用。

更稳一点的需求描述应该是：

塔支持局内升级。每座塔最高 5 级。升级消耗金币。每级的伤害、射程、攻速从 TowerLevelData 中读取。升级后只影响之后发起的攻击，不追溯已经发射出去的子弹。第一版升级后不改变外观，只刷新数值和 UI。

这里特意写“只影响之后发起的攻击”，是为了避免已经飞出去的子弹突然因为塔升级而改变伤害。这种细节如果一开始不说清楚，AI 通常就会按最省事的写法处理。

这段话不算长，但它已经把玩法和工程都说清楚了。

AI 拿到这样的需求，再写代码就会稳定很多。

所以拆需求时，不要只拆“玩家能做什么”，还要拆“数据从哪里来”“状态怎么存”“哪些地方要刷新”“哪些东西先不做”。

这些才是真正影响代码结构的部分。

拆到最后，要变成任务单

需求拆完之后，不要直接让 AI “根据上面的内容开始写代码”。

最好再把它整理成一个小任务单。

因为一大段需求文档丢给 AI，它也可能抓不住重点。

任务单要短一点，边界要清楚一点。

比如我们已经确认了“塔升级”的需求，可以整理成这样：

任务：实现塔的局内升级逻辑。已有结构：- TowerBase：负责塔的攻击逻辑- TowerData：负责塔的基础配置- PlayerBattleState：记录当前金币- BattleUI：负责显示金币与塔信息本次要做：1. 给 TowerBase 增加 level 字段，默认 1 级。2. 增加 TryUpgrade() 方法。3. 升级前检查金币是否足够。4. 升级成功后扣除金币。5. 从 TowerLevelData 读取当前等级对应的 damage、range、attackInterval。6. 通知 BattleUI 刷新当前塔信息。本次不做：1. 不做外观变化。2. 不做升级特效。3. 不做局外养成。4. 不修改敌人逻辑和子弹命中逻辑。验收：1. 金币足够时，点击升级按钮，塔等级提升。2. 金币不足时，升级失败，不扣金币。3. 升级后新一轮攻击使用新数值。4. 原有普通攻击逻辑不受影响。

这就是一个比较适合交给 AI 的任务。

它不大。它有上下文。它有边界。它知道什么不做。它也知道做完之后怎么验收。

AI 在这种任务里，会比直接面对一个“帮我做塔升级系统”稳定得多。

“不做什么”有时候比“做什么”更重要

很多人给 AI 提需求时，只写要做什么，不写不做什么。

但在项目里，不做什么其实很关键。

比如你让 AI 做一个“关卡系统”，如果没说边界，它可能顺手给你加：

关卡解锁。星级评价。章节分页。存档记录。奖励结算。UI 动画。关卡预览图。失败重试。

这些东西看起来都合理，但可能不是你这次想做的。

更麻烦的是，它可能会为了实现这些功能，顺手改很多已有结构。

所以任务单里最好明确写“不做什么”。

比如：

本次只实现关卡数据读取和进入关卡。不做关卡星级。不做章节分页。不做关卡奖励。不做存档。不改战斗结算逻辑。

这种限制不是为了束缚 AI，而是为了保护项目。

因为 AI 很擅长补全，它经常会把一个小功能扩成一套系统。但真实开发经常不是这样。

真实开发里，很多时候我们只想先补当前缺的那一块，让项目能继续往下走就行。不需要每次都顺手开一个大系统。

也可以让 AI 先帮你挑问题

除了让 AI 拆需求，我还挺建议让它做一次“挑刺”。

比如你可以把自己写的需求发给它，然后问：

请你先不要写代码。只审查这份需求说明。重点看：1. 有没有描述不清的地方？2. 有没有容易导致代码结构混乱的地方？3. 有没有后续扩展会踩坑的地方？4. 有没有本阶段不该做、但被我提前写进去的内容？5. 哪些地方需要补充验收标准？

这个用法很实在。

因为我们自己写需求时，很容易默认一些背景。

比如你自己知道“敌人路径是 Tilemap 上预设好的”，但需求里没写。你自己知道“第一版没有存档”，但任务里没说。你自己知道“子弹命中是逻辑结算，不走物理碰撞”，但 AI 不知道。

让 AI 挑一遍，至少能帮你把这些隐含前提翻出来。

当然，它挑出来的问题不一定都要改。

有些问题确实重要。有些问题只是它想得太复杂。你还是要自己判断哪些采纳，哪些忽略。

但这个过程通常很有价值。

一个比较顺手的使用流程

如果把这件事整理成一个实际流程，我现在会比较推荐这样用。

先把游戏想法写成一段普通描述。不用太正式，就像跟朋友解释项目一样。

比如：

我想做一个竖屏 2D 塔防游戏，玩家在固定格子上建塔，敌人沿路径从起点走到终点。第一版只验证建塔、攻击、波次、胜负，不做养成和存档。

然后让 AI 只拆问题，不写代码。

接下来你自己从问题里做选择。比如确定固定路径、固定格子建塔、子弹逻辑命中、波次由配置控制，第一版只有一种塔和一种敌人。

这些选择定下来以后，再让 AI 整理 DEMO 范围，把内容分成“必须做”“暂不做”“后续再做”。

最后一步，才是让 AI 把 DEMO 拆成几个开发任务。每个任务写清楚输入、输出、不做什么、验收标准。到这一步，才比较适合开始让 AI 写具体代码。

这套流程看起来多绕了几步，但比一上来写代码稳很多。

因为你不是让 AI 自己猜项目，而是一步步把它带到你想要的方向上。

写在最后

AI 参与开发以后，很多人会觉得写代码变快了。

这是真的。

但游戏项目里，写代码变快不一定等于项目变快。

如果需求没拆清楚，写得越快，后面返工也越快。如果边界没定清楚，AI 每次都多改一点，项目结构很快就会变得不好收拾。

所以我觉得，AI 开发游戏时，一个很重要的习惯就是：先拆需求，再写代码。

先让它帮你问问题。再让它帮你整理范围。再让它帮你拆任务。最后才让它真正开工。

这一步不难，也不需要什么高级技巧。只是很多人一开始太急，直接跳到了写代码。

但如果你真的想把 AI 当成长期开发助手，而不是只用它生成几个 Demo，那需求拆分这一步就很值得认真做。

AI 可以写得很快。但你得先告诉它，往哪里写。

---

结尾

好了，这就是今天分享的全部内容。

给欧米留言，分享你的心得！

---

点击”在看”让更多开发者看到

我是欧米，每天分享一点游戏开发小知识，希望能帮助到每一个走在实现梦想路上的游戏人。

本文由【欧米De游戏开发小屋】原创，抄袭必究

主笔：欧米

数据，排版：枫叶君

有想法，有趣的项目，合作都可以加我哈！

最近在做一个小的游戏创作者站点，

想先拉一个真的在做项目的小群内测。

你或者你的团队，现在如果有在做游戏，或者准备开始做，

任何游戏类型都可以。

可以加我哈