最近我又干了件挺有意思的事完全没碰Unity也没开Godot就靠纯AI把一款蚂蚁搬家小游戏从零做出来了而且能玩、能发布、能放到微信小游戏里跑的那种。先别急着划走我说的纯AI不是拿AI画几张图、找个模板套上去。是连游戏逻辑、蚂蚁寻路、动画循环、UI碰撞这一整套东西全部让大模型生成我只负责提需求、看结果、挑毛病。标题那句话说得有点夸张但方向是真的——现在的AI编程能力已经足够支撑一个没有任何游戏引擎经验的普通玩家从0到1做出一款能上线的小游戏。这篇不是教程更像是我把整个过程摊开来给你看从选题为什么是蚂蚁搬家到AI第一版生成的代码长什么样到我用了哪些提示词技巧再到现在游戏引擎对大部分纯AI生成的小游戏来说到底还有没有必要。如果你也好奇AI到底能不能独立做游戏这篇文章应该能给你一个相对完整的参考。1. 为什么是蚂蚁搬家选题背后的技术算盘1.1 小游戏的本质是规则闭环不是画面堆料很多人觉得做游戏难第一反应就是我不会画画不会建模不会写Shader。但小游戏这个品类恰恰是最不吃这套的。你打开任何一款休闲小游戏画面像素级简陋、角色就是几个圆形方块照样有人玩得停不下来。核心在于它的规则是否形成闭环玩家操作什么、反馈什么、分数怎么涨、失败条件是什么。蚂蚁搬家的闭环特别清晰蚁穴里的蚂蚁出发跑到地图上的食物点搬起食物再跑回蚁穴放下。搬得越多分数越高。如果再加一条时间限制或者蚂蚁体力值游戏张力就出来了。这个规则不需要复杂的物理引擎不需要骨骼动画不需要3D模型纯粹是移动检测计数三个基础能力就能跑通的东西。1.2 对AI来说这类游戏的代码量刚好卡在舒适区我让AI生成过游戏也尝试过让它做一个完整的RPG实话讲后者现阶段容易被AI写得支离破碎。但蚂蚁搬家这种单场景、单角色逻辑的休闲小游戏代码量通常在几百行JS以内恰好是大模型输出窗口能够稳定覆盖的范围。更重要的是它的技术栈是HTML5 Canvas加原生JavaScript这意味着不需要任何构建工具、不需要安装依赖、不需要配置环境。一个HTML文件双击就能在浏览器里跑起来。这种单一文件的特性天然适合AI生成——因为AI在生成时不需要在多个文件之间维护状态所有逻辑都写在同一个文件里上下文一致性好出bug的概率也低得多。我给AI设定的需求大概是这样画面上有蚁穴、食物堆、蚂蚁角色蚂蚁自动寻路找到最近的食物搬起来送回蚁穴每搬回一个食物分数加一食物数量减少地图上随机生成障碍物蚂蚁不能穿过有一个时间倒计时时间结束游戏结束操作方式玩家点击或拖动画面里的蚂蚁引导它往对应方向走核心思路是玩家不直接搬食物而是指挥蚂蚁——这个设定让游戏有了操作感和策略性比纯挂机看蚂蚁自动跑要有趣得多。2. 零引擎起步AI第一版代码的真实水平2.1 第一版从来不是完美而是能动我先直接说结论AI第一版生成的代码基本功能全部跑通了蚂蚁会动食物能搬分数会涨倒计时也在走。但细节上一堆毛病包括不限于蚂蚁会斜着穿墙、食物消失得莫名其妙、玩家点了蚂蚁结果蚂蚁跟中邪一样原地转圈。如果拿这份代码去上线肯定不行。但它证明了最关键的一点骨架是对的。坐标系统、对象结构、游戏循环这三样东西AI理解得很扎实我没有改一行逻辑代码就把它跑起来了。这就是纯AI开发游戏的第一个价值——把从空白到骨架的时间压缩到了几分钟。2.2 我们拆一下AI写出的代码结构AI自己规划了这么几个模块比我预想的要清晰得多GameState对象管理分数、剩余时间、蚂蚁状态、食物列表Ant类属性包括位置、速度、目标、携带状态方法包括移动、寻路、拾取、放下Food类记住静态位置、是否被搬走、对应的分数Obstacle数组存储所有阻挡块的矩形范围主循环用requestAnimationFrame驱动每一帧的更新和重绘这个结构放在任何引擎里都是说得通的。说白了游戏引擎能帮你省掉的也就是主循环渲染调度碰撞检测这几块而这几块对于蚂蚁搬家这个体量来说手写并不复杂。AI既然能手写那引擎就不是必需品。有意思的是AI给蚂蚁设定的寻路逻辑没有用A星算法而是用了简化版本每帧计算蚂蚁与目标的夹角沿着方向移动如果遇到障碍物则尝试沿障碍物边缘滑行。这个方案效率不高但在这个游戏里够用而且代码量少。这种够用就好的判断恰恰是AI模仿人类开发者的典型表现。2.3 浏览器里为什么能跑出游戏感很多非技术朋友可能好奇没有引擎游戏感从哪来答案就是浏览器本身。requestAnimationFrame这个API可以让浏览器以每秒60帧的频率重绘画面配合Canvas的2D绘图上下文已经能画出平滑的动画效果。蚂蚁迈腿的效果我用的是简单的交替绘制奇数帧画六条腿偶数帧画四条腿视觉上就有一种在爬的感觉。这种小技巧全部来自AI的提议我只说了一句蚂蚁要看起来像在爬而不是在滑。音效那部分我让AI用Web Audio API生成了一小段循环背景音和搬起食物时的噗声全程没有引入任何音频文件代码大约30行。这就是纯AI开发小游戏的第二个价值——它可以在不依赖外部资源的情况下自己给自己造出所需的一切美术、音效、逻辑全在代码里。3. 提示词才是真正的引擎我如何把需求喂给AI3.1 把大需求切碎成AI能理解的小单元外边流传的很多AI开发教程上来就是让AI做一个游戏然后AI给你吐一个四不像出来。问题不在AI在你给的提示词太笼统。我实际踩过好几次这样的坑之后总结出一个经验让AI分步构建别让它一步到位。我用的第一段提示词长这样我要开发一个蚂蚁搬家小游戏使用HTMLCSSJavaScript用Canvas渲染。先不要写任何逻辑只需要构建一个游戏场景画布左侧有一个椭圆形的蚁穴右侧有三堆食物每个食物是一个圆形面包屑中间区域随机分布5个矩形障碍物。请输出完整的HTML文件。然后是第二段现在给场景添加一只蚂蚁用黑色圆形加三条腿表示。蚂蚁会自己移动到离它最近的食物位置移动过程中不能穿过障碍物如果碰到障碍物就沿着障碍物边缘滑动。请只输出完整的script标签内容。再然后是第三段给蚂蚁添加搬运逻辑。蚂蚁到达食物点后食物变成被携带状态蚂蚁沿最短路径返回蚁穴到达蚁穴后食物消失分数加一。食物堆中共有20个食物全部搬完则游戏胜利。每次只让AI处理一个能力点测试通过后再叠加下一个。这个方式看着没技术含量但它恰好利用了AI最擅长的东西——在明确的小约束下生成高质量代码。反过来一次给太多需求AI会自己内部打架比如寻路逻辑和碰撞逻辑互相冲突很难排查。3.2 用角色设定引导AI的编码习惯我试过给AI加一句角色设定你是一个有十年经验的前端游戏开发工程师代码需要模块化、注释清晰、方便后续维护。效果确实不一样。加了这句之后AI写出来的代码有了统一的风格变量命名更规范逻辑块的边界更清楚而且会自动把常量抽到顶部统一管理。这背后的原理其实不神秘大模型的输出风格深受prompt引导。你提十年经验工程师它的输出分布就会趋近于经验丰富者的代码风格你什么都不加它倾向于输出最普遍的代码形态也就是网上最常见的写法不一定适合你的项目。我还习惯在每轮对话之后追加一句请列出当前代码中你认为可能需要优化的地方。这等于让AI自己给自己做Code Review。很多时候它指出来的问题就是你下一步要踩的坑提前修掉能省很多时间。3.3 提示词的负面清单比正面要求更管用这是我在多次实践中发现的一个很反直觉的点。与其反复告诉AI你要做什么不如明确告诉它你不要做什么。我列了一份负面清单不要使用任何外部图片资源所有图形都用Canvas绘制不要使用第三方库纯原生JS不要引入复杂的类继承体系用简单的对象和函数即可蚂蚁的移动速度不要超过每帧2像素否则游戏体验过差UI文字不要用系统默认样式至少要设置字体大小和颜色把这些写上之后AI生成代码的返工率明显降低了。因为AI默认会倾向于用最好的方案——比如引入图片、用ES6类继承、加入一堆可能不需要的特性。你的负面清单就是在强行压制它的创作冲动让它走直线。4. 多AI协作流水线写码、审码、素材三路并行4.1 一个AI写代码另一个AI当裁判做到一半的时候我有个想法如果让同一个AI既写代码又检查自己的代码它很容易护短也就是下意识忽略自己生成的逻辑里的漏洞。这时候最有效的办法是换一个AI或者换一个对话上下文来当严格审查员。我把写好的代码完完整整发给另一个会话的AI配上这样一段话请检查以下游戏的JavaScript代码。重点审查1. 是否存在数组越界风险2. 碰撞检测是否有漏检3. 游戏帧循环是否可能导致内存泄漏4. 蚂蚁寻路是否存在死循环5. 移动端触摸事件是否处理正确。请不要修复代码只列出问题清单和严重程度。这一下子收获非常大。审查AI指出了三个我根本没注意到的问题食物数组在迭代过程中被修改可能导致跳过某个食物不处理蚂蚁到达目标点后没有及时的碰撞检测有概率卡进障碍物内部游戏结束后requestAnimationFrame没有停止后台仍持续消耗CPU这些属于典型的代码能跑但不健壮的问题写代码的AI自己发现不了因为它的关注点在功能实现上。而审查AI关注点在鲁棒性上恰好互补。这就是多AI协作的第一个好处让不同上下文、不同偏好的模型分工而不是一个模型从头干到尾。4.2 专门用一个AI负责美术风格小游戏的美术是个大坑找素材网站太碎侵权风险又高自己画又实在看不下去。我的解决方案是给美术单独开一个会话完全不碰游戏逻辑只负责生成画到Canvas里的绘图代码。比如我对美术AI说请生成一段JavaScript函数用Canvas 2D API画出一个蚂蚁图标。蚂蚁是俯视视角身体分头胸腹三节腹部带条纹六条腿对称分布大小约30x20像素。输出一个名为drawAnt的函数包含必要的注释颜色使用深棕色系。这其实是个非常巧妙的窍门让AI生成绘图函数而不是生成PNG图片。绘图函数直接嵌入游戏代码里既能动态控制大小和方向又不依赖任何外部文件。游戏里的蚁穴、食物、背景、障碍物全部用这种方式由美术AI单独生成到最后我再手动合并进主代码。这个模式跑通之后我明显感受到多AI协作的真正含义——不是开多个窗口各自为战而是建立一条流水线需求AI负责拆解任务编程AI负责实现逻辑审查AI负责挑毛病美术AI负责出绘制函数最后主程序员也就是人只做整合和决策。4.3 人的角色变了从写代码到当甲方整件事给我最大的触动是做游戏的人的角色已经完全变了。以前我写一个功能要自己盯住每一个变量名、每一处边界条件。现在我只负责描述我想要的效果然后像甲方看方案一样审视AI输出的结果——哪些符合预期哪些还需要改。说白了我更像是一个懂得提出好要求的产品经理而不是一个闷头敲代码的工程师。这个转变对很多想尝试做游戏但被代码门槛挡住的人是个好信号你不一定需要成为编程高手但你得有清晰的逻辑、明确的体验描述能力以及最基本的代码理解力至少能看懂哪里是函数、哪里是循环。5. 实测掉坑清单AI游戏常见的五个毛病和修复办法5.1 蚂蚁陷入局部死循环这是最典型的一个坑。AI写的沿障碍物边缘滑行逻辑在遇到凹形障碍物时会让蚂蚁陷入反复横跳的死循环蚂蚁在两个朝向之间来回切换永远走不到目的地。排查思路其实很经典加上日志输出打印蚂蚁每一帧的位置和朝向然后观察它在哪个坐标区间反复横跳。我让AI在关键节点加了几行console.log跑一会儿就发现蚂蚁卡在了某个障碍物的右上角。解决方案是给蚂蚁加一个卡死检测计数器如果连续50帧蚂蚁的位置变化小于0.5像素就强制重新计算目标方向绕开当前障碍物。这个思路是我提的AI负责具体实现。说实话这种问题在有游戏引擎的物理系统里不一定会出现但也正因为没有引擎逼得你不得不理解游戏的底层逻辑——对我个人来说反而是个好事。5.2 碰撞检测漏检导致穿模AI第一版的碰撞检测逻辑写得很粗暴每次移动后检查蚂蚁新位置是否落在任何一个障碍物的矩形范围里是的话就退回原位。这个方法在蚂蚁移动速度慢的时候没问题但一旦速度提上来就可能出现跨界跳帧——上一帧还在障碍物左边下一帧已经跑到障碍物右边了中间没有一次检测能拦住它。修复办法是连续碰撞检测把移动路径拆成若干小段逐步检测。也就是说一次5像素的移动拆成10次0.5像素的移动每走一小段检测一次。这个方案代码量增加了但换来的是物理层面的安全感。修改之后我特意把蚂蚁速度拉满让它在障碍物之间高速乱窜再也没有出现过穿模。5.3 移动端触摸事件失效桌面浏览器跑得好好的到了手机上一摸蚂蚁根本不理会。原因特别基础AI只写了mousedown、mousemove和mouseup事件没有处理touchstart、touchmove和touchend。这个问题的修复倒是简单让AI把鼠标事件替换成指针事件pointerdown、pointermove、pointerup一套事件就能同时覆盖鼠标和触屏。但这件事的教训值得记下来给AI提需求时必须明确要求支持移动端否则它默认只做桌面环境。如果你也是第一次用AI开发游戏这句话能帮你少走很多弯路。5.4 性能问题蚂蚁数量一大就掉帧游戏后期我加了一个蚂蚁越搬越多的彩蛋每搬回5个食物就多生成一只新蚂蚁。这个设计本身很有意思但到20只蚂蚁同时在地图上乱跑的时候帧率掉到了20FPS左右肉眼可见的卡顿。AI的性能优化建议很直接不要每一帧都重新计算每个蚂蚁和每个障碍物的距离改成每10帧算一次全局寻路中间帧只需要沿着已经算好的路径移动。等于把实时避障换成了预计算路径平滑移动对蚂蚁搬家这种慢节奏游戏完全够用。优化后即使30只蚂蚁同时活动帧率也稳定在55FPS以上。这个经验放大了说其实和高德地图做路径规划一个思路不是每秒钟重新规划全量路径而是路径算好之后一段时间内复用只在关键节点做微调。5.5 AI接单工程化版本管理全靠复制粘贴最后一个坑不是游戏逻辑的而是工程习惯的。AI生成代码是一段一段来的中途改了几次之后代码版本就乱了我都不知道哪个浏览器里跑的是第几版。后来我养成了一个特别朴素的习惯每完成一个功能点就备份一次完整HTML文件文件名带上版本号。比如ant_game_v1.html、ant_game_v2_fix_collision.html。当AI改出问题时我可以随时回滚到上一个能跑的版本而不是在乱七八糟的修改里痛苦地找原因。这个习惯在传统开发里被称为版本控制在AI开发里同样重要只是你要自己稍微勤快一点。6. 游戏引擎VS纯AI什么情况下值得继续走这条路6.1 做个表看对比引擎解决什么纯AI解决什么纯粹从技术选型的角度我拿它和Unity、Godot这类引擎做了个对比不吹不黑直接上结论对比维度游戏引擎方案纯AIHTML方案上手门槛需要理解引擎概念、C#或GDScript只需会开浏览器和提需求跨平台发布可直接打包安卓、iOS、PC网页为主可转微信小游戏等容器物理与碰撞成熟物理引擎效果精细手写碰撞检测够用但简陋美术资源支持支持复杂材质、3D模型仅Canvas绘图适合2D小游戏性能上限可以支撑大型3D项目适合轻量级2D休闲游戏调试工具有场景视图、性能分析器全靠console.log比较原始AI辅助程度AI也能辅助但需结合引擎APIAI生成的就是整个游戏本身适合作品体量几百MB到几十GB的项目几KB到几百KB的项目表格看下来结论其实很清晰如果你的目标是2D休闲小游戏、轻交互、快速上线、跨端要求不高纯AI这条路完全走得通甚至效率更高如果你的目标是大型项目或者对物理表现要求高引擎仍然是更好的选择。6.2 什么情况下我建议你试试纯AI开发小游戏第一是零编程基础但想验证创意的人。你脑海里有一个小游戏的点子不确定好不好玩与其花几个星期学Unity入门不如直接让AI花一个晚上生成一个可玩的原型。跑起来试玩一下如果连你这个设计者自己都觉得无聊那这个创意大概率不太行省下的时间比什么都值钱。第二是前端开发者想拓展技能边界。纯AI生成的游戏本质上还是一个前端项目你能在调试过程中接触大量Canvas绘制、坐标运算、状态管理方面的逻辑这些技能在Web端做图形交互时有很高的复用价值。第三是教育场景。把让AI生成一个游戏再手动修改当作编程入门的练习题比枯燥的语法练习有趣得多。学生可以快速看到劳动成果再针对性地学习发现问题、解决问题的过程这也是编程思维训练的核心。6.3 纯AI开发的上限在哪说实话纯AI开发的上限不在AI模型本身而在你的需求描述能力和调试能力。AI可以生成的代码复杂度在不断增长但你要能清楚地描述出想要的体验才能把它的潜力兑现出来。反过来一旦生成的东西出了问题你也得能看懂报错、分析日志、把问题定位到具体模块——这些能力还是你自己的。就蚂蚁搬家这个项目而言从开始到能玩花了大概一晚上到能上线花了两个晚上。我个人的判断是这类项目以后会越来越多不是因为游戏引擎不好用了而是因为AI把做一个简单游戏的门槛打了下来让很多原本被技术拦在门外的人也有机会把自己的创意变成能跑的东西。至少对我来说这次尝试之后再看Unity的下载页面反而没那么焦虑了。