看到这个标题估计有人会摇头鼓吹“游戏引擎没用”已经够激进还说是“纯AI”做出来的是不是标题党我先不急着辩解。事实是我确实没打开Unity也没碰Cocos、Godot连微信小游戏官方模板都没碰就用一个浏览器、一个编辑器、几个AI对话窗口从零做出了一款能玩的蚂蚁搬家小游戏并且部署上线、发链接给朋友试玩。整个过程走完最大的收获不是“AI能不能替代游戏引擎”而是在这个体量的项目里游戏引擎本来就不是必需品。这篇文章会把完整的工作流、提示词写法、核心代码逻辑、以及我在实测里踩过的坑都摊开讲适合那些想用AI快速验证玩法、又不想被引擎工程化流程拖住的人。我先说一句重要的不用游戏引擎不等于不处理工程问题。恰恰相反因为没有引擎帮你管理场景、物理、生命周期你得更懂自己在做什么。但好在蚂蚁搬家这个题材足够简单简单到一套Canvas加JavaScript就能扛住。如果你也想搞纯AI小游戏我建议你先别急着开新引擎项目把下面这条路走一遍。1. 为什么这事能成立AI写游戏能不能绕过引擎核心是认清边界1.1 引擎到底在解决什么问题很多人一提起做游戏默认就要上Unity或者Unreal。但你要先想清楚游戏引擎是一个“工业化工具箱”它把渲染、物理模拟、场景管理、资源加载、UI、音频、动画状态机等一系列通用能力打包了。它解决的痛点是大型项目的复杂度而不是“在屏幕上画出几只蚂蚁并让它们移动”。我用一个生活化的类比请装修公司是因为你要改水电、做吊顶、贴瓷砖。如果只是想给出租屋刷一面墙拿滚筒自己上反而更快。游戏引擎对我来说就是那个装修公司而蚂蚁搬家小游戏只是一面墙。再往深处说引擎的价值在它替你处理“帧循环、渲染管线、资源流加载、多人同步”这些问题时是体系化的。但代价是项目结构、构建链、打包流程都跟着引擎走动不动几个G的编辑器还要学它的组件系统、场景文件格式。对一个网页小游戏来说这些是真正的负担。1.2 蚂蚁搬家需要引擎的哪些能力我把这个游戏真正需要的能力列了个清单蚂蚁在画布上移动、食物随机生成、蚂蚁发现食物并搬回巢穴、数量增长、计分、胜利判定、音效和简单的视觉反馈。仅此而已。这些需求对应的技术能力是2D图形绘制、圆形碰撞检测、游戏循环、鼠标点击交互。渲染我用Canvas就能做碰撞就是计算两个圆心之间的距离物理系统根本用不上资源加载就是零——图形全部程序化绘制不需要加载外部图片。整套东西塞进一个HTML文件就能跑。为了方便你判断“自己要不要上引擎”我当时做了个对照表需求引擎能提供什么我这个项目实际用的画面渲染场景树、材质、光照系统Canvas 2D画笔碰撞检测刚体物理、碰撞体组件两点距离公式游戏循环引擎内置的Update/FramerequestAnimationFrame资源管理资产管线、动态加载单文件内程序化生成打包发布多平台构建部署静态HTML这张表看完你就明白不是引擎不好是它提供的复杂能力在这个项目里完全冗余。我连图片素材都不用加载引擎的资产管理系统等于白给。1.3 纯AI写代码的边界不是替代引擎而是替代“低效开发环节”既然不用引擎那AI到底在项目里承担什么角色我的真实体会是AI很擅长生成离散的函数、组件以及根据报错信息修代码它不擅长的是自己攒出一套完整且可扩展的架构。所以你怎么拆需求决定了AI输出的质量。在这个项目里我先把整个游戏拆成了十几个小单元游戏循环、蚂蚁类、食物类、状态机、拾取判定、巢穴判定、孵化机制、计分UI、开始界面、结束界面、背景绘制、音效。每一个单元都足够小小到AI能够独立理解并写出像样的代码。然后我把这些单元逐个喂给AI再手动拼装。这个思路本身也和“不用引擎”是配套的。引擎帮你管理场景和生命周期你没有引擎就得自己定义清楚对象模型和状态流转。人负责架构AI负责填砖这才是“纯AI开发”能跑通的前提。2. 第一版提示词是怎么写的从四个字到可落地的功能拆解2.1 给AI看的“需求说明书”长什么样很多人让AI做游戏就扔一句话“帮我写一个蚂蚁搬家小游戏。”然后AI还真能给你吐出一堆代码但质量全看运气。我的习惯是把AI当成一个刚进公司、有点能力但完全不了解业务的新人你交代需求越具体它给你的东西越接近你想要的。我当时给AI的提示词是这样拆的你是一名资深Canvas游戏开发者。请用纯HTMLCSSJavaScriptCanvas实现一个蚂蚁搬家小游戏禁止引入任何游戏引擎和第三方库。 玩法说明 1. 巢穴在画布左侧蚂蚁从巢穴出发。 2. 食物随机出现在画布右侧区域。 3. 蚂蚁会自动寻找离自己最近的食物搬运回巢穴。 4. 每搬运成功一次计分加1。 5. 每搬运3个食物在巢穴旁边孵化一只新蚂蚁。 6. 计分达到20分时显示胜利界面。 交互与反馈要求 - 点击画布空白区域可以生成一个临时障碍物蚂蚁需要绕开。 - 蚂蚁捡到食物时食物颜色变亮蚂蚁运动速度略微降低。 - 搬运回巢穴时巢穴上方飘出一个数字加1的动画。 验收标准 - 双击打开HTML文件直接在浏览器中能玩。 - 蚂蚁数量可以从1只增长到20只以上。 - 游戏中不能出现报错蚂蚁不能卡在障碍物里。 - 画面风格统一蚂蚁和食物要用Canvas图形绘制不要用文字代替。划重点技术栈、玩法、交互反馈、验收标准四段缺一不可。特别是“验收标准”它让AI有机会在生成代码时自我检查而不是交一个半成品。2.2 AI的第一版代码为什么“能跑但不像游戏”第一版代码生成得很快两三分钟就出来了。双击打开浏览器里确实能看到蚂蚁在动食物也会被搬回去。但说实话那东西不像游戏像PPT自动播放蚂蚁全都直愣愣冲向食物搬回来之后没有任何反馈画面安静得像教学演示。问题出在哪里我提示词里只写了“玩法”没写“感受”。AI默认把需求理解为“最小可运行的逻辑演示”它不会主动思考游戏性的节奏和情感反馈。后来我在每个功能描述后面都补了一句“这个功能要给玩家什么感受”效果立刻不一样了。还是拿搬运食物举例。第一版就是蚂蚁移动到食物坐标食物消失计分加一。加了一句感受要求之后AI会给蚂蚁背部画一个小亮点搬运途中走路变得颠簸一点巢穴口会闪一下光。这些细节不改变玩法但玩家能感觉到“自己的操作是有反馈的”。这也是我觉得AI编程和传统外包最大的区别AI不会主动追问产品意图你要把“要什么”和“为什么”一起喂给它。2.3 把功能清单和验收标准显性化我在开始写第二版代码之前做了一份功能清单每实现一个就勾一个。这份清单既给AI看也给自己看。它长这样编号功能模块第一版状态最终版状态1游戏循环与帧率控制完成增加dt限幅2蚂蚁移动与朝向完成增加状态机3食物随机生成完成增加刷新间隔4拾取判定完成增加背包概念5搬运回巢完成增加计数动画6新蚂蚁孵化未完成完成7胜利界面未完成完成8音效反馈未完成完成9点击生成障碍物未完成完成10调参与手感优化未完成完成有了这个表格你就清楚AI生成的代码到底缺了什么、接下来要补什么。一个很现实的经验是别指望AI一次到位它负责把有确定性的代码写对你负责把功能验收清单维护好。把这个清单扔回给AI它会更容易理解当前的进度。3. 核心玩法编码全过程状态机、碰撞和搬运逻辑是三个关键3.1 游戏循环与对象列表在不用引擎的情况下游戏循环是整个项目的骨架。Canvas只是画布它不会自己刷新画面需要你不断重绘。我让AI生成的游戏循环长这样const canvas document.getElementById(game); const ctx canvas.getContext(2d); const ants []; const foods []; let lastTime 0; function loop(time) { const dt Math.min((time - lastTime) / 1000, 0.05); lastTime time; update(dt); render(); requestAnimationFrame(loop); } requestAnimationFrame(loop);这里有两个工程细节值得注意。第一dt是上一帧到这一帧的时间差单位秒。所有移动都基于这个值计算才能保证不同刷新率下蚂蚁速度一致。第二我限制了dt最大为0.05秒。为什么因为当用户切换浏览器标签页再切回来时time会突然跳大如果直接拿真实差值去更新蚂蚁会瞬间瞬移一大段距离。限制上限后这种情况最多产生两三帧的异常影响很小。对象列表也简单蚂蚁和食物分别用数组管理每次更新时遍历数组。没有引擎的“场景树”概念数组就是我的场景。这个越简单越好因为后面要在这个基础上叠加状态机和碰撞判定。3.2 蚂蚁状态机寻路、拾取、搬运、回家第一版AI生成的蚂蚁逻辑是一坨if-else如果没食物就去最近的有食物就往家走。听起来没问题但一旦有另一只蚂蚁抢先把食物搬走它就傻在原地或者无限寻找已经消失的食物。于是我让AI把蚂蚁行为改写成状态机。状态机的核心是把蚂蚁的“状态”显式建模每个状态只处理自己该做的事切换条件写清楚const STATE { SEEK: SEEK, // 漫游寻找食物 TO_TARGET: TO_TARGET,// 锁定食物正在走过去 CARRY: CARRY, // 搬着食物往巢穴走 DELIVERED: DELIVERED // 刚放下食物短暂停顿 }; class Ant { constructor(x, y) { this.x x; this.y y; this.state STATE.SEEK; this.speed 60 Math.random() * 30; this.target null; this.direction Math.random() * Math.PI * 2; } update(dt, foods, nest) { if (this.state STATE.SEEK) { this.target findNearestFood(this.x, this.y, foods); if (this.target this.target.alive) { this.state STATE.TO_TARGET; } else { this.wander(dt); } } else if (this.state STATE.TO_TARGET) { moveToward(this, this.target, dt); const d distance(this, this.target); if (d ANT_RADIUS FOOD_RADIUS) { this.target.alive false; this.carry this.target; this.state STATE.CARRY; } else if (!this.target.alive) { this.state STATE.SEEK; } } else if (this.state STATE.CARRY) { moveToward(this, nest, dt); if (distance(this, nest) NEST_RADIUS) { this.state STATE.DELIVERED; onDeliver(this); } } else if (this.state STATE.DELIVERED) { this.deliverTimer - dt; if (this.deliverTimer 0) { this.state STATE.SEEK; } } } }这个状态机的价值体现在一个细节蚂蚁锁定的食物如果被另一只蚂蚁搬走了this.target.alive会变成false蚂蚁会在下一次判断中回到SEEK状态重新找目标。没有这个机制蚂蚁会冲着不存在的食物坐标走到天涯海角。3.3 碰撞与拾取判定圆形距离公式就够说到碰撞很多人容易想复杂。蚂蚁搬食物这个场景不需要像素级碰撞更不需要物理引擎的刚体模拟。我用的是最简单的圆形碰撞function distance(a, b) { return Math.hypot(a.x - b.x, a.y - b.y); } // 拾取判定两个圆的圆心距离小于半径之和 if (distance(ant, food) ANT_RADIUS FOOD_RADIUS) { ant.target food; ant.state STATE.CARRY; }这个公式对2D俯视角的休闲游戏来说绝大多数情况都够用。为什么不用更精确的矩形碰撞因为矩形碰撞涉及旋转、包围盒、方向轴投影计算量更大代码也更复杂。圆形碰撞只算一次开方即使同时有几百只蚂蚁在做判断性能也没问题。障碍物碰撞也类似我把障碍物当成固定位置的不会动的圆蚂蚁靠近时按障碍物的圆心和半径做排斥偏移。效果就是蚂蚁会绕开障碍物一步而不是穿过去。这个方案简单到AI一遍就写对了。3.4 回巢、计数、孵化新蚂蚁与胜利判定每次蚂蚁搬回食物巢穴要记录分数并判断是否要孵化新蚂蚁。这里有个容易踩的坑如果每帧都判断“是否分数达到3”会导致同一帧里瞬间孵出好几只新蚂蚁。我在提示词里就强调了这个边界AI最终给出的方案是加一个冷却计时器let score 0; let hatchTimer 0; const HATCH_INTERVAL 1.5; // 秒 const HATCH_THRESHOLD 3; function onDeliver(ant) { score; ant.carry null; ant.deliverTimer 0.4; hatchTimer - HATCH_INTERVAL * -1; // 用计时器的思路控制孵化节奏 } function update(dt) { hatchTimer - dt; if (score HATCH_THRESHOLD hatchTimer 0 ants.length MAX_ANTS) { hatchTimer HATCH_INTERVAL; const newAnt new Ant(nest.x randomOffset(), nest.y randomOffset()); ants.push(newAnt); } if (score WIN_SCORE) { showWinScreen(); } }这个代码不是最优雅的但逻辑非常直白。更关键的是它避免了玩家看到“蚂蚁成倍暴增”的失控场面。孵化延迟让新蚂蚁一只一只出现玩家能看到蚂蚁数量慢慢变多游戏的节奏感立刻不一样了。这也是我在第2章强调“感受”的一个实际成果。4. 单模型不够用把多个AI拼成一条开发流水线4.1 一个写功能、一个唱反调、一个补测试这个项目里我不是只和一个AI对话。我把不同AI的“人格”分开了一个负责写功能代码一个专门挑毛病一个负责生成边界测试。这借鉴的是结对编程里“驾驶员”和“领航员”的分工——写代码的人容易陷入自己的思路盲区审查的人专门盯着边界条件找漏洞。我给审查型AI的提示词是你是一名资深游戏代码审查员。请审查下面这段JavaScript代码只输出问题清单不要直接给修改后的代码。重点关注 1. 数组在遍历过程中是否被修改。 2. 是否存在对象复用导致的状态残留。 3. 食物数组里被标记为alivefalse的元素是否还会参与碰撞。 4. 是否有意外全局变量或类型转换隐患。 5. 高帧率显示器上移动距离会不会出现跳变。你别说这个“唱反调”的AI真的帮我挡了两个bug一个是食物删除后碰撞还在计算另一个是蚂蚁数组在更新时被孵化逻辑往末尾添加元素导致for循环遍历到越界。这两个问题写代码的AI自己是看不见的。4.2 Agent化工作流把反馈循环自动化既然AI能写代码、也能审代码那为什么不把它们串成一条自动流水线我在本地搭了一个很轻的工作流AI生成代码 → 保存到本地 → 跑语法检查 → 打开浏览器手动试玩 → 把报错或异常表现的日志贴回给AI → 让AI修复 → 再检查。我用的命令非常简单# 检查JavaScript语法能抓出明显的语法错误 node --check game.js # 在本地起一个静态服务方便浏览器加载 python3 -m http.server 8000然后在浏览器打开http://localhost:8000玩一遍。遇到问题就把控制台报错复制出来和“我期望什么行为、实际发生什么行为”一起丢给AI。这个闭环跑顺之后一个周末里我大概迭代了十几轮代码每次都是“AI改 → 我验证 → 有问题 → 再丢回去”。我当时没有用特别复杂的Agent框架单纯依靠人的判断来调度AI但效果已经接近“小团队流水线”。如果你用的是带AI编程插件的开发环境这个闭环可以做得更顺手。很多人问我是用哪个编辑器其实不重要重要的是你愿不愿意把“验证”这个环节坚持做好。AI生成代码的速度可以很快但它没有判别力验证永远得有人来做。4.3 美术也交给AI程序化绘图代替素材小游戏对美术的要求不高但又不能太素。我的选择是让AI生成Canvas绘制代码用程序化图形代替美术素材。这样既绕开了版权问题也省去了找素材、扣素材的时间。蚂蚁的画法我给了AI一个方向身体分成三节头部两根触角整体用深棕色系。AI生成的函数是这样function drawAnt(ctx, x, y, angle, color) { const hue color ! undefined ? color : 25; ctx.save(); ctx.translate(x, y); ctx.rotate(angle); // 身体第三节 ctx.fillStyle hsl(${hue}, 55%, 30%); ctx.beginPath(); ctx.ellipse(-6, 0, 5, 3.2, 0, 0, Math.PI * 2); ctx.fill(); // 身体第二节 ctx.beginPath(); ctx.ellipse(-1, 0, 4.5, 3, 0, 0, Math.PI * 2); ctx.fill(); // 头部 ctx.beginPath(); ctx.arc(4.5, 0, 3.2, 0, Math.PI * 2); ctx.fill(); // 触角 ctx.strokeStyle hsl(${hue}, 40%, 20%); ctx.lineWidth 0.8; ctx.beginPath(); ctx.moveTo(6, -2); ctx.quadraticCurveTo(10, -7, 13, -5); ctx.moveTo(6, 2); ctx.quadraticCurveTo(10, 7, 13, 5); ctx.stroke(); ctx.restore(); }实际效果比我预想的好关键是hsl()里那个hue参数让我可以给每只蚂蚁染不同的深浅色。代码里没写死颜色蚂蚁看起来就更有生命力。食物则用了不同形状的圆点加小线段模拟米粒和碎叶。一张图片都不加载加载速度飞快打包部署也轻。5. 实测中踩过的坑能玩到好玩之间差了不少路5.1 AI编造API名三分钟一个幻觉AI写的代码有一个典型毛病自信地编造API参数。我在实测中最典型的是ctx.ellipse的用法AI给了一个不存在的参数组合浏览器直接报错说参数个数不对。还有一次它把requestAnimationFrame回调函数的参数命名成了非时间变量导致移动速度全变成NaN蚂蚁全部瘫在起点。原因很好理解大语言模型是根据语料概率来生成代码的它见过很多版本类似的代码片段但不一定“运行过”每一行。所以你一定要把验证环节当成铁律。我的办法是让AI每改一次代码都顺手导出“改动摘要”我每粘贴一次代码进入HTML都第一时间刷新页面看有没有红色报错。语法检查只能抓低级错误运行时报错和NaN漂移只能靠真跑一遍才能发现。5.2 蚂蚁数量上来后掉帧对象没管好当蚂蚁数量超过300只时画面明显变卡。最开始我以为是Canvas处理不了后来一排查问题根本不在绘制而在对象管理代码里每帧都在创建新对象食物数组里被搬走的元素还留着占内存所有蚂蚁每帧都重新遍历整个数组。这些被反复执行的分配和遍历才是卡顿的元凶。优化手段是对象池。核心思想是不重复创建和销毁对象而是把不用的对象回收复用。这个模式对游戏开发属于基本功但对AI来说如果你不告诉它“需要对象池”它大概率不会主动做。我把这个需求直接写在提示词里AI很快写出了对应实现。优化之后同样几百只蚂蚁帧率稳定多了。5.3 调参的玄学速度、数量、拾取半径的权衡代码逻辑对了游戏仍可能不好玩因为数值调教完全是一笔经验账。我整理了一张调参表记录我的调整过程和理由参数初始值问题调整后手感变化蚂蚁速度60像素/秒太慢画面像慢放80~120随机明显有“忙起来”的感觉拾取半径8像素太苛刻蚂蚁经常错过15像素成功率大幅提高食物生成间隔0.5秒食物太多玩家无压力1.2秒随机供需比较平衡孵化冷却0秒新蚂蚁瞬间成堆1.5秒成长感变得平缓胜利分数5个太短没进入状态就结束20个能体验到从弱到强的过程调参这件事没法靠AI自动完成我是一边玩一边改。玩到你觉得“这局还想再来一次”手感就差不多了。我建议你在发布前把游戏玩至少十遍每一遍只改一个参数记录感受别一次调五六个参数。5.4 向AI提交bug报告的姿势报警告而不是问“为什么不行”很多人遇到问题就问AI“蚂蚁不走路了怎么办”这种沟通方式效率极低因为AI没有上下文只能瞎猜。我后来养成一个习惯给AI提交的bug报告严格按照四段式。问题现象蚂蚁走到食物旁边后不拾取而是继续绕圈。 期望行为蚂蚁碰上食物后食物应该消失蚂蚁转成搬运状态。 实际行为食物没消失蚂蚁在食物旁边不断重新寻找目标。 最近的代码改动我把食物数组从数组改成了对象池复用并用alive标记存活状态。 报错信息无报错控制台干净。你可以直接把这个模板复制到对话里用。它本质上是把一个模糊的问题描述转换成一个有上下文、可复现的“事实陈述”。AI看到这样的格式几乎每次都能给出准确的修复方向而不是绕回来问你一堆问题。6. 从浏览器到微信小游戏打包上架之前先想清的几件事6.1 真的要上微信小游戏吗先看清平台差异有朋友问我既然游戏做好了是不是可以直接打包成微信小游戏这里我要泼一盆冷水。浏览器版本和你真正跑在微信小游戏环境里的版本存在很多差异微信小游戏没有完整的DOM和BOM能力Canvas API虽然接近但加载方式、文件组织、分包体积限制都不同。浏览器里双击就能跑的单文件HTML不能原封不动丢过去。如果你走的是Unity引擎的微信小游戏打包流程那是另一套体系和本文的纯AICanvas路线关系不大。我的建议是如果目标只是验证玩法、发给朋友玩网页版迭代效率最高如果一定要上微信小游戏提前把两层适配时间预估进去至少要留出小半天做环境和API排查。6.2 AI开发的小游戏能不能上架版权和审核说实话“AI开发的游戏能不能上架赚钱”这是个绕不开的疑问。平台审核的核心关注点通常在于素材版权是否清晰、是否收集用户隐私、内容是否合规。如果你用的是AI生成的图片素材要特别小心训练数据带来的版权追踪问题有些素材平台对AI生成图片的使用条款很模糊。我自己规避的办法就是全程序化绘图——所有蚂蚁、食物、巢穴、背景全部用Canvas代码实时绘制游戏不依赖任何外部图片文件。这样版权关系非常清晰代码是我们写的绘制结果也是代码生成的不存在第三方素材的纠纷。至于AI写的代码本身正常上架没有障碍但每个平台的具体规则都在更新提审前一定要看最新的开发者条款。还有一个容易忽略的点如果你的游戏有音效音效素材也要注意授权。我自己当时用Canvas生成简单音效不现实就直接先不放音效或者用Web Audio API合成简单的“滴”声规避了素材来源问题。6.3 我最终的选择先留在网页版继续迭代这个蚂蚁搬家小游戏我最终没有立刻去走微信小游戏提审流程而是先做成网页版丢到一个静态托管服务上把链接发给朋友试玩。这种做法优势很明显改完代码上传就能更新试玩反馈可以快速落到下一版而平台提审流程一套下来可能要等上几天甚至更久对一个人开发的小游戏来说是致命的迭代成本。我的结论是先别被“上架”这个词绑架。网页小游戏能做到随发随玩本身就是一种“上线”。当你把玩法、数值、素材问题都验证完了再决定要不要花时间去做真正的平台适配也不迟。最后说点个人体会。整个项目做下来给我印象最深的不是“AI多厉害”而是AI把试错成本打到了极低。以前学一个新的游戏框架光配置开发环境就能耗掉半天现在我有一个想法可以随手丢给AI快速拿到可运行原型然后像改文章一样改代码。但你也别指望它一次给全套我在那个周末大概和AI对话了七十多轮其中至少十轮是在解决它自己制造的bug。如果你想复刻这条路我建议先做一个蚂蚁搬家这类边界清晰的单文件小游戏把“拆需求、写提示词、验证代码、调参数”这条工作流彻底跑顺再去做更复杂的东西。别一上来就张口要一个大型3D项目AI和你的耐心都扛不住。