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

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

---

这几年一提到 AI 做游戏，很多人的第一反应都是：

是不是可以直接让它写代码？是不是输入一句“帮我做一个塔防游戏”，它就能把项目生成出来？

如果只是做一个很小的 Demo，确实可以这么玩。比如让 AI 写一个角色移动脚本，写一个简单的敌人生成器，写一个点击按钮加金币的功能，它大概率能很快给出一段能跑的代码。

但如果真的想做一个稍微完整一点的游戏，第一步其实不是写代码。

更准确地说，第一步是先把要做的东西说清楚。

直接让 AI 开工，通常会很快跑偏

很多人第一次用 AI 写游戏，都会遇到一个问题：刚开始看起来很顺，越往后越难接。

比如你说：

“帮我做一个塔防游戏。”

AI 很可能马上给你写出一套基础逻辑：敌人沿路径移动、塔自动攻击、子弹追踪敌人、敌人死亡掉金币。

单看这些功能，好像没什么问题。

但继续往下做，就会发现问题慢慢出来了。

敌人路径是用路点，还是 Tilemap？塔的位置是自由摆放，还是固定格子？子弹是物理碰撞，还是逻辑命中？敌人死亡后，波次系统怎么判断结束？塔升级的数据放在哪里？关卡配置是写死在脚本里，还是做成 ScriptableObject / CSV？

这些东西如果一开始没说清楚，AI 就会按它自己的理解往下补。它不是故意乱写，而是你没有给它足够的边界，它只能自己补。

比如你没有说明“敌人沿固定路径移动”，它可能写成这种很简单的逻辑：

Enemy.Update:    move toward playerBase

这当然也能跑。敌人会往基地走，塔也能攻击，看起来像一个塔防原型。

但如果你想做的是固定路线塔防，逻辑就得更接近这种：

Enemy.Update:    currentPoint = path[currentIndex]    move toward currentPoint    if reached currentPoint:        currentIndex += 1    if currentIndex >= path.length:        damage playerBase        remove self

这两种写法看起来差别不大，但它们背后的设计完全不同。

前者更像“敌人冲向基地”。后者才是“敌人沿关卡路径推进”。

如果第一版写错方向，后面再补波次、路径转弯、减速区域、飞行敌人、终点扣血，都会变得别扭。

问题就在这里。

AI 最擅长的是在一个明确范围里完成任务。但如果任务本身很模糊，它补出来的方案未必适合你的项目。

你让它“做一个塔防”，它可能会给你一个能演示的版本。但你想要的，可能是一个以后能扩展 20 个关卡、10 种敌人、8 种塔、带天赋系统和数值配置的项目。

这两件事不是一回事。

游戏开发最怕的不是代码少，而是结构乱

很多独立开发者刚开始做项目时，会觉得代码写出来就行。

能跑，就先跑。能打，就先打。能通关，就先通关。

这种做法在手写代码时已经有风险，用 AI 辅助开发时风险会更明显。

因为 AI 写代码很快。

它不会像人一样，写到一半停下来想：“这个结构以后是不是会很难改？”它也不会主动提醒你：“这个功能现在写死没问题，但以后加关卡编辑器会很麻烦。”

如果你没有提前定好方向，它很可能会把所有东西写在一个脚本里。

比如一个 GameManager 里同时处理：

玩家血量、金币、敌人生成、塔建造、子弹发射、UI 刷新、关卡胜负判断。

刚开始很方便，甚至看起来效率很高。

伪代码可能就是这样：

GameManager.Update:    spawn enemies    move enemies    find tower targets    fire bullets    check bullet hits    add coins    refresh UI    check win or lose

这种写法做 Demo 很快。但它的问题也很明显：所有逻辑都挤在一起。

等你想加“不同关卡读取不同波次配置”的时候，就会发现生成敌人的逻辑已经和 UI、金币、胜负判断缠在一起。

等你想加“火焰塔造成持续伤害”的时候，又发现敌人受伤逻辑只支持一次性扣血。

等你想加“敌人有护盾、隐身、减速抗性”的时候，原来的敌人脚本又得大改。

更稳一点的拆法，至少应该先把职责分开：

WaveSystem:    read wave config    spawn enemies by timeEnemySystem:    update enemy movement    handle enemy damage and deathTowerSystem:    find target    request fire bulletBulletSystem:    update bullet movement    handle hit resultBattleState:    record hp, coins, win or loseBattleUI:    read BattleState    refresh display

这不是说一开始就要做得多复杂，而是至少要让每个模块知道自己该管什么。

这时候你再让 AI 写代码，它就不容易把所有东西都塞进一个类里。

项目先拆清楚，后面的代码才不容易一路歪下去。

先把游戏想法拆成能开发的东西

很多游戏想法听起来是一句话。

“我想做一个肉鸽塔防。”“我想做一个卡牌加自走棋。”“我想做一个类似 Fez 的视错觉解谜游戏。”“我想做一个玩家靠弹幕召唤士兵的直播游戏。”

这些说法适合用来描述创意，但不适合直接交给 AI 开发。

真正要开发时，得继续往下拆。

比如“塔防游戏”，至少可以拆成几个基本部分：

地图系统。敌人系统。塔系统。子弹系统。波次系统。关卡配置。建造与升级。胜负结算。UI 显示。存档与养成。

每一块再继续拆，就会越来越接近开发任务。

比如“塔系统”不能只写“做塔”。

它至少要说清楚：

塔能不能升级？塔的攻击目标怎么选？优先最近、最前、血量最低，还是随机？塔的数据放在脚本里，还是配置文件里？不同塔是继承不同类，还是用统一逻辑加数据区分？塔的攻击表现和伤害结算，是同一套逻辑，还是分开处理？

如果只是很粗地定一版塔配置，也可以先写成这样：

TowerData:    towerId    name    damage    attackRange    attackInterval    bulletId    targetRule    upgradeCost

这个配置并不复杂，但已经能说明一些基本方向。

比如塔的伤害、射程、攻速来自数据。塔用什么子弹，也从 bulletId 里找。塔怎么选目标，则交给 targetRule。

有了这类约定，AI 后面再写基础塔、减速塔、火焰塔时，就不容易每种塔都重新造一套逻辑。

这些问题看着都不大，但会影响后面的代码是临时能跑一下，还是能继续接着做。

AI 可以继续往下写，但往哪个方向写，还是得人先定下来。

AI更像一个执行力很强的初级同事

我觉得比较合适的理解方式是：不要把 AI 当成一个完整的主程，也不要把它当成一个万能外包。

它更像一个执行力很强、知识面很广、但对你项目上下文不稳定的初级同事。

你给它一个清楚的小任务，它能做得很快。

比如：

“根据这个 EnemyData，帮我写一个 EnemyFactory。”“把这段敌人移动逻辑改成读取路点数组。”“写一个 Unity Editor 工具，批量把 CSV 转成 ScriptableObject。”“帮我检查这个 Buff 叠层逻辑有没有问题。”

这类任务边界清楚，输入输出也明确，AI 的价值就很明显。

但你如果只说：

“帮我优化战斗系统。”“帮我做一个完整的技能系统。”“帮我把项目架构整理一下。”

它也会回答，而且回答得可能还挺像那么回事。

问题是，这些回答里会混进很多默认假设。它默认你的项目是某种结构，默认你的数据是某种格式，默认你的运行流程是某种方式。

而这些默认假设，未必和你当前项目一致。

所以用 AI 开发游戏，最重要的能力不是“会不会问它写代码”，而是你能不能把任务拆到它不会乱猜的程度。

第一阶段最好不要急着进 Unity

很多人有了游戏想法，会马上打开 Unity，新建场景，拖一个角色，写一个移动脚本。

这当然没问题，尤其是做原型时，快速动起来很重要。

但如果你准备让 AI 参与开发，我反而建议第一阶段先别急着进 Unity。

可以先做几份很简单的文档。

不用写得很正式，也不用像公司里的策划案那样长。但至少要有几样东西。

第一，核心玩法一句话。这句话不是宣传语，而是开发用的描述。

比如：

“玩家在固定格子上建造不同类型的塔，抵御沿路径行进的敌人，通关后获得资源，用于解锁新的塔和天赋。”

这句话很普通，但它比“我要做一个好玩的塔防”有用很多。

第二，最小可玩版本。

也就是这个游戏最早能跑起来时，需要哪些功能。

比如塔防游戏的最小版本可能是：

一张地图。一条敌人路径。一种敌人。一种塔。一种子弹。三波敌人。能建塔。能攻击。能胜利或失败。

也可以直接写成一个很简单的验收清单：

MVP 验收:    start game    enemies spawn by wave    enemies move along path    player can build one tower    tower can attack enemies    enemies reaching end reduce base hp    killing enemies gives coins    all waves cleared => win    base hp <= 0 => lose

这份东西看起来很粗，但对 AI 很有用。

因为它知道第一版要做到哪里，也知道哪些东西先不用做。

比如第一版不做天赋。第一版不做复杂敌人。第一版不做多章节关卡。第一版不做每日任务和养成系统。

这就能减少很多跑偏。

第三，模块拆分。

不用一开始就画很复杂的架构图，只要知道大概有哪些模块，模块之间怎么交互。

比如敌人系统只负责敌人移动和受伤。塔系统只负责索敌和发起攻击。子弹系统只负责飞行和命中。波次系统只负责按配置生成敌人。UI 只读数据，不直接改战斗逻辑。

这些约定越早定下来，后面 AI 写代码越不容易把逻辑搅在一起。

第四，数据放在哪里。

这是游戏开发里很容易被忽略的一点。

一个功能写死很快，但写死以后就很难改。

比如塔的伤害、射程、攻速、升级价格，如果都写在脚本里，AI 写起来很快。但你后面要调数值、做多种塔、做关卡限制，就会很麻烦。

所以早一点想清楚数据结构，往往比早一点写代码更重要。

先让 AI 帮你问问题

AI 很适合做的一件事，是帮你把模糊想法变成一组问题。

比如你可以不要一上来就说：

“帮我写一个塔防游戏。”

而是先问：

“我想做一个竖屏 2D 塔防游戏，类似固定路线、格子建塔、关卡推进。请你先不要写代码，帮我列出开发前必须确认的问题，按核心玩法、数据结构、关卡系统、UI、存档、后续扩展分类。”

这样问，结果会比直接写代码有用很多。

它会帮你把很多原本没想到的坑列出来。

你再从这些问题里挑真正重要的部分，决定哪些现在做，哪些以后做，哪些先不考虑。

比如第一版不做存档。第一版不做天赋。第一版只做一种塔。第一版不做复杂敌人抗性。第一版只验证“建塔打怪”的核心循环。

这一步看起来慢，其实是在省后面的时间。

因为后面 AI 写出来的每一段代码，都会受到这些前置决定的影响。

写代码之前，先写任务单

如果要让 AI 真正参与开发，我觉得最实用的做法是：先写任务单，再写代码。

任务单不需要很复杂，但要说清楚几件事。

这次要做什么。不做什么。已有项目结构是什么。相关脚本有哪些。输入数据是什么。输出结果是什么。验收标准是什么。哪些地方不能改。哪些地方可以重构。

比如一个不太好的任务是：

帮我做一个减速塔。

这个任务太短了。AI 能做，但它很容易自己发挥。

它可能会直接在敌人脚本里加一个 isSlow。也可能会在子弹命中时直接改敌人的速度。甚至可能顺手把塔、子弹、敌人的结构都改了。

更好的任务可以写成这样：

请基于现有 TowerBase、EnemyBase、BulletBase 三个脚本，实现一个减速塔。要求：1. 减速塔使用 TowerSlow.cs。2. 子弹使用 SlowBullet.cs。3. 子弹命中敌人后，给敌人添加持续 2 秒的减速效果。4. 减速比例从 TowerData.slowRatio 读取，比如 slowRatio = 0.3 表示速度降低 30%。5. 不要直接修改 EnemyBase 的移动主逻辑。6. 只通过 EnemyBase.ApplyMoveSpeedModifier() 接口影响速度。7. 不要改动已有普通塔的攻击逻辑。8. 完成后说明需要挂载哪些组件，以及 Inspector 里要配置哪些字段。

这就比“帮我做一个减速塔”靠谱很多。

差别就在这里：前一种任务有边界，后一种任务基本是在让 AI 自己猜。

如果再进一步，还可以把验收标准也写出来：

验收:    build SlowTower in scene    enemy enters range    tower fires SlowBullet    bullet hits enemy    enemy currentSpeed is reduced by slowRatio    after 2 seconds speed returns to normal    normal tower still works

这类验收条件不复杂，但很重要。

因为你不是只让 AI 把代码写出来，而是让它朝着一个明确结果去写。

人还是要负责判断方向

这也是我现在越来越明显的感受。

AI 参与开发以后，人并没有变得不重要。

只是人的工作重心变了。

以前更多时间花在从零写代码、查 API、复制粘贴、改语法错误上。现在这些事情可以交出去一部分。

但你要花更多时间判断：

这个方案适不适合我的项目？这个结构以后好不好扩展？这段代码有没有隐藏副作用？它是不是改了不该改的地方？它有没有把表现逻辑和数据逻辑写死在一起？它是不是只解决了眼前问题，却制造了后面的坑？

这些判断，AI 可以帮你分析，但最后还是得人拍板。

尤其是游戏开发这种东西，不只是代码能跑就行。

手感、节奏、反馈、资源结构、关卡推进、数值成长，这些都和具体项目目标有关。AI 可以给建议，但它不知道你真正想做成什么样。

写在最后

所以，如果你准备让 AI 帮你做游戏，我不太建议第一步就让它写代码。

更好的方式是，先让它帮你把事情拆清楚。

先明确最小版本。先拆模块。先定数据结构。先写任务单。再让它进入具体开发。

AI 的确能提高开发效率，尤其是在写工具、搭框架、生成重复代码、整理配置、检查逻辑这些地方，非常好用。

但前提是你得知道自己要什么。

这也是我觉得 AI 做游戏最现实的用法。

它不是替你做完整个游戏。它是帮你把那些原本费时间、费精力、但又必须做的事情，尽量做得快一点。

真正决定游戏能不能做下去的，还是前面那些看起来不太刺激的工作：拆需求、定边界、想结构、做取舍。

代码当然重要。但在 AI 参与开发时，第一步真的不是写代码。

---

结尾

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

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

---

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

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

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

主笔：欧米

数据，排版：枫叶君

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

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

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

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

任何游戏类型都可以。

可以加我哈