说实话我对“用AI做小游戏”这件事一直半信半疑。总觉得生成式AI写写文案、做做总结还行真让它写一个能玩的东西大概率是能跑通但不好玩。直到前几天我试着完全不用Unity、不用Cocos拉着对话式AI从零做了一款“蚂蚁搬家”小游戏才发现这条路比想象中靠谱得多——整个项目没有碰任何游戏引擎甚至连构建工具都没装最终产物就是一个HTML文件双击就能玩发给朋友也能直接在浏览器里打开。这篇文章就记录一下完整过程。包括我为什么敢不开引擎、怎么用AI一步步把玩法搭出来、中间踩了哪些坑、以及最终怎么把它变成能正常分享的小游戏。如果你也想用AI做小游戏但一直卡在“不知道从哪下手”这篇文章应该能给你一条完整可抄的路径。1. 为什么这次连游戏引擎都没用1.1 先想清楚什么样的小游戏需要引擎很多人一提到做游戏第一反应就是Unity、Unreal、Cocos。这没有错引擎提供了场景管理、物理系统、动画状态机、资源管线一套组合拳下来做商业游戏确实是标配。但问题也在这里引擎是给复杂项目用的它的学习成本、工程结构、打包流程对一个“玩法简单、逻辑线性、纯前端运行”的小游戏来说反而是一种负担。蚂蚁搬家这个选题玩法核心就三件事蚂蚁找食物、蚂蚁搬食物、蚂蚁把食物运回巢穴。没有物理碰撞的精细需求没有3D模型没有角色动画骨骼没有联机网络同步。它需要的只是一块画布、几个坐标、一个状态切换的流程控制。这类游戏用游戏引擎去写等于开着一台重型卡车去送外卖——能到但没必要。我当时列了个对比表越看越觉得纯前端是对的对比项Unity/Cocos等引擎纯HTMLCanvas包体至少几MB带运行时单个HTML文件几KB到几十KB上手门槛需要学编辑器、场景、资源导入会浏览器打开文件就能跑调试方式编辑器内调试环境复杂浏览器F12直接看报错发布渠道需要平台适配、版本管理静态托管或双击文件即可适合品类中重度、多人、3D、复杂交互轻量休闲、原型验证、网页小游戏所以第一步不是“AI能不能替代引擎”而是“这个游戏根本不需要引擎”。把需求想清楚技术选型自然就清晰了。1.2 AI替代的不是引擎而是“从零造轮子”的过程那AI在这个项目里到底干了什么它没有替代引擎它替代的是“手写大量基础代码”的过程。以前做一个Canvas小游戏我至少要手写画布初始化、游戏循环、蚂蚁状态管理、食物坐标生成、拾取和搬运的碰撞检测、计分和重新开始……每个模块都不难但加起来零零总总也有几百行。而且这些代码大多是重复模式比如“位移速度乘时间”“矩形相交就是碰撞”。这些恰恰是生成式AI最擅长的事——它见过足够多的类似代码能直接把通用骨架吐给你。做一个类比引擎是“精装修交付的房子”直接入住纯前端是“毛坯房”但AI相当于一个不要钱、力气很大的施工队把砌墙、布线、刷漆都给你干了。你只要负责告诉它“我要什么样的房子”然后自己验收、再改细节。这次的实操感受是对话式AI写小游戏的能力比我预期的成熟。只要我给的需求足够明确它生成的代码基本能跑。剩下要做的就是像带新人一样告诉它“这里不对改这个地方”而不是自己撸起袖子把所有代码重写。2. 蚂蚁搬家玩法拆解和核心机制设计2.1 玩法设计一句话能说清的游戏才适合AI写在让AI动手之前我先把玩法用一句话定义清楚蚂蚁从巢穴出发在地图上寻找散落的食物搬运回巢穴每搬回一份积一分关卡结束时统计总分。玩法设计越简单AI的完成度越高。这不是玄学而是大模型的生成逻辑决定的——它擅长处理边界清晰、规则明确的任务。如果你上来就要“一个模拟蚂蚁群落生态的拟真游戏包含蚁后繁殖、季节变化、天敌系统、地下巢穴分层”AI大概率会生成一个看起来很华丽、但跑起来到处漏风的东西。所以我刻意把范围压缩到最小可玩版本巢穴固定在左下角食物随机分布在画面其他位置。蚂蚁从巢穴出发移动到食物位置再带着食物返回巢穴。到达巢穴后食物堆叠到巢穴旁分数加1。所有食物搬完后显示完成弹窗刷新食物重新开始。在这个基础上后续可以加多只蚂蚁、移动速度变化、障碍物、时间限制但第一版绝对不要加。先跑通再扩展这是做小游戏最省事的方式。2.2 核心机制拆解状态机、移动和碰撞我把整个游戏的逻辑拆成三个核心机制分开跟AI描述这样它生成的代码就不会挤成一坨。第一个是蚂蚁的状态机。一只蚂蚁在任意时刻只有四种状态寻找食物、走向食物、搬运食物、返回巢穴。状态之间靠事件切换——比如“到达食物坐标”触发拾取“到达巢穴坐标”触发放下。状态机的好处是逻辑清晰AI生成的代码结构也更好维护。第二个是移动逻辑。蚂蚁从一个点移动到另一个点本质上就是每帧把当前位置朝目标点推进一个固定速度的距离。我让AI用最简单的直线移动不做寻路算法因为地图上没有墙壁直线就是最优解。如果以后加了障碍物可以再让AI引入BFS或A*但那是后话。第三个是碰撞与计数。判断蚂蚁有没有到食物、有没有到巢穴用“两点距离小于阈值”的方式。不用精确的矩形碰撞因为视觉上蚂蚁和食物都是小圆点/小方块距离判断完全够用而且代码更简洁。拆完这三个机制后我给AI的提示词就有了清晰的脉络。我甚至把状态机和移动逻辑用伪代码写了一段给它// 蚂蚁状态 ant.state toFood; // toFood, withFood, toNest // 每帧更新 function updateAnt(ant, foodList, nest) { if (ant.state toFood) { moveTo(ant, ant.targetFood.pos); if (dist(ant.pos, ant.targetFood.pos) 20) { ant.state toNest; ant.carrying true; } } if (ant.state toNest) { moveTo(ant, nest.pos); if (dist(ant.pos, nest.pos) 30) { ant.carrying false; score; } } }这一段不是抄代码而是给AI一个“思路锚点”让它知道我要的状态机长什么样。实际生成的代码比这完整得多但骨架一致。3. 用AI从零写第一版提示词和生成实录3.1 提示词把需求写成像给实习生的工作单AI写代码质量高低前提是提示词写得好。我的经验是不用讲大道理直接给场景、给约束、给验收标准。就把它当成一个刚入职的实习生你得告诉它“用什么语言、什么环境、界面长什么样、行为怎么触发”。我用的提示词模板大概长这样请帮我用纯HTML CSS Canvas写一个蚂蚁搬家小游戏具体要求 1. 单个HTML文件不用任何外部库和框架双击可以直接运行。 2. 左下角固定一个蚁巢画成一个棕色半圆。 3. 画面上随机出现若干颗食物画成小圆点颜色可以不同。 4. 左上角显示一只蚂蚁的图标点击「开始」后蚂蚁会自动从巢穴出发。 5. 蚂蚁找到食物后拾取然后自动回到巢穴到达后分数加1食物从画面消失。 6. 画布大小固定为800x600所有文字显示为中文。 7. 蚂蚁的移动速度可以调节用变量定义方便改。 8. 代码里每个关键函数写中文注释。这些约束不是随口说的每一项都有目的。单文件是为了方便验证和分发不用外部库是为了避免环境问题中文注释是为了后面我自己改代码或者让AI继续改代码时上下文能对齐。第一次生成的代码大概两百来行。我保存成ant.html用浏览器打开画面能渲染蚂蚁会移动。但第一版有两个明显的问题一是蚂蚁走到食物后没有停直接穿过去了二是食物拾取后没有从数组里移除导致蚂蚁反复“搬运”同一个食物。3.2 第一版效果评估能跑但离能玩还差两步第一版能跑起来我的态度是“及格了”。因为AI写代码最大的价值不是一次写对而是给你一个能运行的底座然后你可以精准告诉它哪里有问题。我做的第一件事是把现象描述给它“蚂蚁到达食物坐标后没有停下也没有切换状态食物没有消失请检查状态切换的条件以及拾取后对食物列表的处理。”它会自动定位到相关函数然后给出修改代码。我直接把修改后的代码段复制回去刷新页面问题就解决了。这一轮迭代给我的感受很深AI写代码最怕的不是bug而是你描述不清bug。你把现象、期望、复现步骤说清楚它定位问题的速度远比自己一行行排查快。4. 优化迭代从能玩到好玩4.1 功能增强多蚂蚁协作、动态刷食物第一版只有一只蚂蚁玩起来很单调。我第二个迭代目标是让画面出现多只蚂蚁并且食物搬完一批后自动再刷一批形成“无尽模式”。这一步我没有让AI重写而是继续对话式追加需求。提示词可以这样写在现有代码基础上做以下修改 1. 增加4只蚂蚁同时从巢穴出发各自寻找最近的食物。 2. 每只蚂蚁的状态互相独立。 3. 当画面上的食物全部被搬走后等待1秒重新随机生成一批新食物。 4. 给每只蚂蚁编号画面上用不同颜色的点区分。这里的关键是“各自寻找最近的食物”——如果不加这个条件所有蚂蚁会涌向同一个食物画面看起来非常蠢。AI在理解“最近”之后需要遍历食物数组比较距离这个逻辑对它来说很基础。改完后的效果立刻上了一个档次。四只不同颜色的蚂蚁在地图上各自忙活画面一下子活了。当然也出现了新问题蚂蚁会走重叠的路线看起来像在穿模。这个好办——我用CSS给每只蚂蚁加了不同的圆形描边视觉上能区分至于位置重叠在2D简笔画小游戏里完全能接受不算bug。4.2 性能与手感帧率、移动速度、交互反馈小游戏除了“能玩”还得“好玩”这里面手感很重要。手感的核心就是节奏和反馈。速度方面我让AI把蚂蚁的移动速度从固定值改成了可调参数并且加了一个deltaTime的概念——也就是每帧移动距离乘以时间差保证在不同刷新率的屏幕上移动速度一致。如果不这么做在144Hz显示器上蚂蚁会飞在60Hz显示器上蚂蚁会爬体验割裂。这是AI容易忽略、但实际游戏必须处理的点。反馈方面我给三件事加了视觉反馈蚂蚁拾取到食物时食物变透明但保留残影蚂蚁回到巢穴时巢穴弹出一圈扩散波纹计分从纯数字改成了“1”飘字效果。这些细节全都可以靠AI实现每一条单独提出来都不难但叠加起来整个游戏的完成度提升非常明显。改动到这里这个游戏已经从“AI生成的demo”变成了“我愿意主动打开玩两把的小游戏”。5. 常见问题与排查实录5.1 我踩过的5个坑现象、原因和解决方案这一路下来踩了不少坑我把有代表性的整理成了速查表方便你直接对号入座。现象原因解决方案蚂蚁走到食物位置但不停直接穿过去状态切换条件写错或者拾取判断的阈值太大/太小检查“距离小于某值”的判断确认触发后就切换状态并移除食物对象食物被搬走后画面里还有残影只做了拾取标记没从foodList数组中splice移除让AI在拾取逻辑中同时执行数组删除操作多只蚂蚁全部冲向同一个食物没有指定“最近的”这个筛选条件而是取了第一个提示词明确写“遍历食物列表取距离最短的目标”游戏运行一会后越来越卡requestAnimationFrame里重复创建对象或残留了旧的食物实例检查循环中是否有new对象旧实体需要清理或复用页面在手机浏览器上显示错位画布大小写死成800x600没有做适配让AI加window.innerWidth判断或用CSS让画布自适应这五个坑几乎都是第一次用AI写Canvas小游戏时会遇到的共性问题。我的一个习惯是每次AI改完代码后先在浏览器里快速过一遍核心流程再决定要不要继续提下一个需求。不要一次性提五个修改需求然后让AI一次性改完那样出了问题反而不好定位。5.2 AI代码翻车时的兜底策略AI也不是每次都能一次改对。我遇到过几次越改越糟的情况比如它把正常的状态机逻辑改写坏了蚂蚁直接静止不动。这种时候我有个固定套路——不跟它在同一个对话里死磕到底而是先试两种方法第一种是让AI自己解释代码。我会说“请解释一下updateAnt这次改动的逻辑我觉得状态切换有遗漏。”AI在解释的过程中通常会自己发现问题然后主动给出修正。第二种是直接还原版本。所以我在每次让AI改代码之前都会把当前能跑的HTML文件复制一份存成ant_v1.html、ant_v2.html这样带版本的备份。一旦新改动翻车立刻回到上一个备份文件再重新提需求。这一步看着笨但实际能省下大量时间。你不能指望AI永远正确但你可以靠备份让错误永远不致命。6. 从本地HTML到可分享的小游戏6.1 单文件分发双击就能玩是最佳体验游戏做完接下来是分发。因为这个项目刻意做成了单HTML文件所以分发路径极其简单把文件丢给对方对方双击就行连服务器都不用。如果你想发一个链接让别人在线玩方法比想象中多。最省事的做法是找静态托管平台把HTML文件传上去得到一个访问链接。GitHub Pages、Gitee Pages、Cloudflare Pages都可以一个前端零基础的人也能在十分钟内搞定。因为只有单文件不用处理资源路径、不用打包上传直接把文件拖进去就能访问。我当时还做了一个小优化把游戏里的颜色、食物数量、蚂蚁数量、速度等关键参数提取到文件顶部一个叫Config的对象里。这样后续调难度时不用翻代码改几行配置就行。这个习惯也是让AI配合完成的——你只要让它“把所有数值参数集中到文件顶部”它就会照做。如果想要更小的体积还可以让AI做一次代码压缩——去掉多余注释和空格。但我的体会是对这类小游戏代码本身才几十KB压缩的意义不大保留注释反而方便后续自己回来维护。6.2 后续可以扩展的三个方向这个游戏做完以后我盘了一下后续可能的扩展方向也是给想照着做的人留几条路第一是微信小游戏适配。微信小游戏用的是类似的Canvas渲染模型但需要套一层小游戏运行时环境再加一个game.js入口。目前这个HTML文件不能直接变成微信小游戏但核心逻辑——蚂蚁状态机、食物刷新、得分——可以原封不动地搬过去只需要把HTML标签和DOM操作替换成小游戏API。对会改代码的人来说这是半天到一天的工时。第二是触屏交互。现在这版只支持点击“开始”按钮如果改成触屏可以让玩家用手指点按画面来生成“糖粒”引导蚂蚁路线或者左右划动切换视角。这个玩法改起来不复杂但对AI的指令要下得很细。第三是关卡难度曲线。现在是无尽模式每批食物数量一样。如果做成关卡制可以设置“第1关10个食物、蚂蚁速度慢第2关8个食物、但蚂蚁速度快、还会随机出现障碍物”。这类数值递进最好做成配置表不要让AI散落在代码里。我对扩展方向的建议是一个项目做完先记录当时的代码和玩法设计不要急着马上加功能。隔几天再回来看你最想玩的那个方向才是真正值得投入的方向。最后再分享一点个人体会。用AI做小游戏真正考验人的不是技术而是“表达需求”的能力。你能把玩法拆得越细把期望说得越具体AI的产出就越贴近你想要的东西。这跟带团队是一个道理目标清晰分工明确执行的人才能少走弯路。做完这个蚂蚁搬家小游戏我更倾向于把AI当成一个“永远在线、不要钱、记性时好时坏”的初级程序员伙伴。它能让你的想法快速跑起来但决定一个游戏好不好玩的还是你脑子里那个关于玩法的判断。