看到“游戏引擎都没用纯AI又上线了一款蚂蚁搬家小游戏”这个项目标题可能很多人第一反应是又整标题党。但这次真不是虚的。我最近就用AI做了一款蚂蚁搬家主题的小游戏全程没打开Unity也没碰Unreal、Godot、Cocos这些游戏引擎代码、玩法逻辑、美术素材、音效绝大多数都是我跟AI一轮一轮对话“聊”出来的。严格说不是完全没写代码我也手动改了大概几十行参数但主体逻辑确实是AI生成的。在此之前我还用同一套思路做过接金币、打地鼠这类小原型所以这次说是“又上线”一点不夸张。这篇文章就是想把这个项目从想法到可玩版本的完整过程摊开讲清楚包括需求怎么拆、提示词怎么写、技术栈怎么选、后期如何调试和发布顺带回答一个最近被问了很多次的问题AI开发的小游戏到底能不能拿去上架。1. “纯AI”不是不需要人而是换了一种开发节奏1.1 这个标题背后是一条新开发路线传统做小游戏基本绕不开游戏引擎。Unity、Unreal、Godot、Cocos门槛虽然一直在降但只要你想做一个像样的作品安装体积、项目结构、编辑器操作、脚本编译这些环节一个都跑不掉。早期我也这么干过Unity的编辑器打开一次要等好几秒场景里挂一个组件都要想半天引用关系。对一个人做一个小项目来说这套流程实在太重了。这次做蚂蚁搬家小游戏我换了一条完全不一样的路把小游戏的需求写成几段自然语言交给大模型AI去生成前端代码。AI基于它理解的游戏逻辑直接给出一套可运行的HTML、CSS和JavaScript代码我再逐轮让AI追加功能、修Bug。整个过程没有传统游戏引擎参与运行环境就是浏览器自带的渲染引擎。对实际上还是会用到浏览器这个“引擎”但这里“游戏引擎都没用”指的是没有用那些专门为游戏开发的综合工具。这里要澄清一下“纯AI”这个说法。纯AI不代表你什么都不干更不代表AI能自动从想法生成成品。我的实际体验是AI更像一个随叫随到的外包开发但“产品经理”这个岗位始终是你自己。需求定义、验收标准、玩法取舍、边界条件这些必须由人来定。AI写代码的效率完全取决于你把需求描述得多清楚。如果你丢一句“做个蚂蚁搬家游戏”过去得到的也只能是一个一句话质量的原型。1.2 蚂蚁搬家游戏的需求拆解选“蚂蚁搬家”这个题材是因为它天然适合作为AI编程能力的验证项目规则直观、状态清晰、但又有足够的扩展空间。我先给项目定了一个原始需求文档这份文档后来成了所有提示词的骨架。游戏的核心玩法是这样的蚂蚁巢穴在画面左下角食物刷新点在画面右侧。玩家点击场景空白处可以派出工蚁工蚁会自动执行“离巢—寻找食物—搬运食物—返回巢穴—放下食物”的循环。游戏限时90秒玩家需要在时间内帮蚁群运回指定数量的食物否则游戏失败。为了让游戏不只是“移动一下”我加了三层小机制。第一层是体力值每次搬运都会消耗体力体力用完后蚂蚁会放慢速度爬回巢穴第二层是随机事件场景中会周期性出现蜘蛛巡逻蚂蚁如果在搬运途中被蜘蛛追上会丢下食物并立即回巢第三层是升级系统玩家通过搬运食物积累点数再消耗点数去增加蚂蚁数量上限或提升移动速度。这些机制听起来有点多但落到技术上其实就是几个状态和几个数值。把需求拆得足够细AI生成代码时的命中率会高很多。如果你也想复现这个项目可以参考下面这份需求清单画面2D俯视使用Canvas渲染桌面端和手机端自适应数量同时活动的蚂蚁至少支持20只运行时不掉帧状态蚂蚁有4个状态寻找、搬运、回巢、休整计时90秒倒计时最后10秒界面闪烁提醒事件蜘蛛巡逻、下雨减速、体力耗尽交互点击场景空白处生成蚂蚁界面按钮切换升级项界面开始画面、游戏中HUD、胜利或失败结算。把这些写成“可验收的清单”AI才会知道你到底要什么。后面第三章我会放出完整提示词可以直接复制去试。2. 技术选型不碰游戏引擎我用什么把游戏跑起来2.1 为什么是HTML5 Canvas JavaScript很多人听到“不用游戏引擎”以为技术栈会很复杂。其实反过来我选了最笨也最稳定的组合原生HTML5 Canvas加原生JavaScript。一个HTML文件搞定一切没有框架没有构建工具。选这个方案的理由很清晰。小游戏的特点就是“打开就能玩”。用Unity或Cocos就算能导出Web版本也会带着一整个运行时加载慢而且你需要提前学编辑器流程。HTML5 Canvas是浏览器原生能力画圆、画矩形、贴图、做变换基本能满足2D小游戏的需求不需要额外SDK。JavaScript的requestAnimationFrame是现成的主循环入口性能在小游戏这个体量下完全够用。用AI生成代码的时候我也踩过一个小坑AI经常会默认给你上一套Vue或者React组件把整个场景拆成一堆DOM节点这在小游戏里是非常糟糕的设计。所以我在所有提示词里都会加一条硬性约束只能用原生JS不引入外部库不引入框架所有画面元素用Canvas绘制。这条约束直接决定后续生成结果能不能用。为了让你直观理解两种路线的差异我整理了一张对比表对比项传统游戏引擎Unity/Cocos等AI HTML5 Web技术栈入门门槛需要学习编辑器操作和脚本框架会写自然语言需求就行代码由AI生成项目体积引擎运行时动辄几十MB起一个HTML文件通常只有几百KB迭代速度改完代码要重新构建等待时间明显把需求丢给AI十几秒拿到新版本分工方式策划、程序、美术、测试各司其职一个人通过多轮对话完成多角色分工适用场景中大型游戏、3D、复杂特效轻量级小游戏、原型验证、网页游戏看到这个表你就明白了不碰游戏引擎不是为了炫技而是在小游戏这个体量下Web技术确实更轻快。如果你以后想放到微信小游戏、抖音小游戏这些平台HTML5项目也可以通过平台适配层转过去但那是发布阶段的事先把核心逻辑跑通再说。也有朋友问过我为什么不用Python写小游戏或者用C写一个。核心逻辑其实差不多但JavaScript有一个天然优势零依赖。只要对方有浏览器打开链接就能玩。用Python做的话还得考虑人家电脑上有没有Python环境传播成本一下就上去了。2.2 核心模块状态机、主循环与碰撞检测有了Canvas和JS剩下真正核心的技术模块其实就三块主循环、状态机、碰撞检测。这三块也是我在提示词里反复强调的东西。主循环使用requestAnimationFrame。为了让游戏速度不受屏幕刷新率影响我会专门让AI维护一个lastTime变量计算每帧的deltaTime然后所有移动量都乘上deltaTime。这个细节如果不写清楚AI生成出来的代码在60Hz和120Hz屏幕上跑出的速度会差将近一倍。状态机是蚂蚁搬家小游戏的核心。每只蚂蚁是一个Ant对象内部有state字段取值是FIND、CARRY、RETURN、REST。FIND状态下蚂蚁寻找最近的食物找到后切换到CARRY蚂蚁颜色和携带标记跟着改变CARRY状态下蚂蚁不再朝食物移动而是转向巢穴方向到达巢穴后计数加一短暂休息后回到FIND。这个四状态循环让AI生成的代码非常简洁。碰撞检测用圆碰撞就够了。下面这段就是AI生成的关键判断代码实际运行效果稳定function checkCollision(ant, target) { const dx ant.x - target.x; const dy ant.y - target.y; const distance Math.sqrt(dx * dx dy * dy); return distance ant.radius target.radius; }这段代码本身不起眼但正是这些基础检测组合起来决定了蚂蚁会不会在蜘蛛面前“穿模”食物会不会被两只蚂蚁同时抢走。AI生成这类基础逻辑的准确率很高但边界情况比如两个目标坐标重合、负坐标入场还是需要人工盯一下。2.3 美术和音效也交给AI处理代码没问题之后美术和音效成了我最大的顾虑。毕竟我不是设计师但小游戏又不能没有视觉反馈。我用了两套方案一套是让AI用Canvas的绘图指令直接画像素风素材另一套是让文生图模型生成贴图再由AI把贴图转到游戏里。先说Canvas画图。确实是可以用代码“画”出一只小蚂蚁的一个椭圆身体、两个触角、六条腿。这种极简画风对于小游戏来说完全够用好处是文件体积几乎为零加载速度极快。AI生成的画图代码往往是参数化的蚂蚁大小、颜色、腿摆动角度都可以通过变量调整。调试的时候改参数比重新做素材方便太多。音效方面Canvas本身没能力生成声音但我尝试了两条路。第一是用Web Audio API让AI写一个合音函数鼠标点击时发出短促的“嗒”声搬运成功时发出上升音阶失败时发出低音。这种合成音效效果意外不错。如果需要更丰富的背景音乐也可以用文生音频工具生成一个20秒的循环片段。需要注意的是AI生成的素材如果以后要商用最好提前确认授权条款尽量选允许商用和修改的版本省得后面版权踩雷。3. 实操记录从第一版到完整可玩版本的全程拆解3.1 第一轮提示词让AI写出能跑的雏形前面讲了这么多理论这章是大家真正能“抄作业”的地方。下面这段是我给AI的第一轮提示词原文可以直接复制去用。它不是随手写的里面每个约束都踩过坑。请用原生HTML CSS JavaScript写一个“蚂蚁搬家”小游戏要求如下 1. 不允许引入任何框架和第三方库纯原生JS 2. 使用HTML5 Canvas绘制全部游戏画面 3. 蚂蚁巢穴在画布左下角食物堆在画布右侧 4. 页面加载后自动派出一只蚂蚁蚂蚁自动走向食物点吃到食物后搬运回巢 5. 玩家点击画布空白区域可以新增一只蚂蚁 6. 每只蚂蚁有4个状态寻找食物、扛起食物、返回巢穴、休整 7. 画面顶部显示已搬运食物数量和90秒倒计时 8. 倒计时结束若搬运数量少于10个显示失败画面否则显示胜利画面 9. 适配不同屏幕尺寸画布居中按钮放在画面底部 10. 请你完整输出index.html一个文件不要分批输出。这段提示词最有价值的部分是第1条和第10条。AI写代码有个怪癖你不约束它它动不动就给你引一个cdn上的框架或者把代码分成好几个文件甚至写一句“其余部分见下一条回复”。先把这两个坑堵住得到的代码基本一次能跑。AI返回的结果确实是完整的index.html本地浏览器打开就能玩。第一版已经能跑蚂蚁会径直走向食物再跑回巢穴。但问题也很明显画面干巴巴的蚂蚁像几个小黑点在屏幕上移动没有队列效果也没有任何碰撞反馈。这很正常。第一版的核心任务就是验证“AI能不能把骨架撑起来”剩余的表现细节靠后续迭代慢慢补。3.2 迭代实录我把需求一轮一轮“喂”给AI第一版能跑之后我进入迭代阶段。这里我有一个习惯每一轮只提3到5个修改点不要一次性塞太多。一次塞十个需求AI很容易顾此失彼改完这个坏那个。一轮一轮说AI改代码的稳定度要高很多。第二轮我主要补了计分和反馈。我明确要求AI做三件事蚂蚁搬运食物回巢时顶部计分板加1并弹出一行“1个面包屑已入巢”蚂蚁回巢后休息时间设为0.8秒并给不同蚂蚁加上一点随机延迟让它们自然错开增加一个“蚁群士气”数值每成功搬运一个食物士气加2蜘蛛出现时士气减1士气低于3时界面上出现警告提示。这一轮AI生成了新代码我跑了一下计分、士气、警告都正常体验比第一版好多了。第三轮重点让游戏更有“蚂蚁搬家”的感觉。我要求AI加入三条队列规则同一时间往食物点移动的蚂蚁如果距离小于24像素就自动错开一条轨道搬运过程中蚂蚁用最短路径回巢不许中途乱转当运回巢穴的食物数量超过30个食物刷新点自动切换位置避免所有蚂蚁盯死同一个点。这些需求在代码上意味着避障和导航AI实现的版本不算完美但玩起来已经能看到一支有秩序的队伍而不是一群乱跑的黑点。第四轮处理表现层。我让AI给蚂蚁画了腿部摆动动画搬运状态时蚂蚁颜色变成暖黄色巢穴周围加了粒子效果。这轮改动非常快十分钟左右整个游戏的画面节奏就出来了。通过这些迭代你也能看到每一轮AI都在执行明确指令而我做的主要是检查、验收、再提下一轮需求。整个过程就像请了一个随叫随到的外包开发只是沟通成本低到可以忽略。3.3 多AI协作让另一个AI给代码找Bug项目进行到中后期我用了一个特别有效率的模式多AI协作。简单说就是让A模型负责写功能让B模型负责审查代码。人看自己刚写的代码容易惯性忽略问题AI同样有这个毛病换个模型换个视角就能减少很多盲区。具体操作是把当前版本的完整代码粘贴到另一个AI对话里然后对它说“请以游戏测试工程师的身份检查这段代码重点找这几类问题状态机有没有死循环碰撞判断是否漏了边界情况requestAnimationFrame是否有重复启动内存里是否存在无限增长的数组。请给出修改建议。”这种“换视角审查”特别能发现我自己容易忽略的边界问题。这个流程给我带来的第一个有效建议是蚂蚁在FIND状态下如果所有食物都已经被搬完会陷入一直寻找的卡死状态。我之前只处理了“食物少于N个就刷新”忽略了搬运瞬间那个空窗期。AI给出的解法是加一个fallback逻辑蚂蚁找不到食物时进入REST状态重新扫描一遍食物列表如果仍然为空就等待下一次刷新。这个细节如果靠人肉测试大概率要很后期才能暴露。多AI协作的好处不仅仅是有免费质检员还逼着生成代码的AI“解释自己的设计”。当第二个AI开始分析漏洞时你会对整个项目的状态流和边界条件有更深的理解。后面我会把“让AI自审”的提示词技巧单独放到第4章那个模式同样有奇效。3.4 参数调教与手感优化代码逻辑跑通之后真正决定游戏好不好玩的是参数。AI生成代码时用的参数往往非常“学术”每个值都能跑但手感就很平淡。这一块必须人来调。我最后定下来的参数是这样的蚂蚁移动速度不要在代码里写死而是用一个speedRange随机初始化范围在每秒90到130像素之间。这样每只蚂蚁速度有差异队列看起来更自然。蚂蚁的半径设为3到8像素食物点半径设为8到12像素碰撞判定距离是两者半径之和再加2像素的余量不然蚂蚁会“穿透”食物视觉上很别扭。蜘蛛巡逻速度设为蚂蚁平均速度的0.6倍这样玩家遇到蜘蛛时还有逃跑空间不至于一碰就死。蚂蚁休整时间我控制在0.8秒让肉眼能看出队列节奏但又不会觉得卡。食物刷新点放在画面右侧随机偏移每次刷新5到8个让蚂蚁自动分散开来处理。下雨事件每25秒随机触发一次持续6秒期间蚂蚁移动速度乘0.6同时用Canvas画雨线粒子效果。这个效果成本极低但氛围提升非常明显。这些参数都很普通但正是这些不会出现在AI默认代码里的细节决定了小游戏是好玩还是平庸。建议你复现的时候也重点调一调手感别看AI生成的默认值顺眼就不动它。4. 常见问题与排查AI开发小游戏的避坑手册4.1 五个典型问题代码生成对了跑起来却不对AI写代码最大的特点是单点逻辑很聪明整体一致性容易翻车。我做了这么多次AI小游戏项目遇到的坑里最有代表性的五个整理成了速查表。现象极可能的原因排查与解决思路蚂蚁跑到食物旁边就是不“拿”碰撞检测圆半径写成了固定值没有跟随物体大小变化让AI打印每帧的radius和distance统一改成对象属性蚂蚁全部挤在一个点卡住所有蚂蚁共用同一个目标点互相碰撞导致死锁给每只蚂蚁分配不同的目标顺序碰撞后随机偏移手机端画面模糊或按钮点不到没做viewport和devicePixelRatio适配提示AI补上meta nameviewport标签Canvas尺寸乘devicePixelRatio胜利条件触发了两次状态切换判断在同一个帧里重复执行触发胜利时加gameOver标志位并用return中断主流程游戏声音不播放AudioContext创建于页面加载时浏览器默认拦截未交互的音频改成玩家第一次点击屏幕时再初始化音频上下文这些坑不是AI凭经验能完全避开的因为它们往往跟运行时环境有关。我的处理方法很直接先让AI解释一遍“你觉得这个Bug为什么会发生”再让它给修复方案。你可能会觉得多此一举但AI的“自我解释”往往会暴露它代码里的错误假设比直接让AI硬改更有用。4.2 AI开发的小游戏能不能上架这是我在测试阶段听到最多的问题。答案是能但有几个前提必须说清楚。首先纯HTML5页面游戏可以直接作为网页版发布只要有一个托管页面就行。如果目标是微信小游戏、抖音小游戏这类平台那不能直接把index.html丢进去需要通过平台提供的适配工具把项目结构转成对应格式同时处理登录、支付、分享这些平台能力。这段工作涉及的已经不只是前端能力你至少得能读懂平台的开发文档。其次AI生成的代码上架前必须有一个人工审核兜底。平台审核最看重的是内容安全、隐私政策和版权。比如游戏里的素材如果是AI生成的就要确认没有直接抄袭某个现有IP形象游戏文案不能涉及诱导分享、违规抽奖之类的内容。AI提供了高效的生产力但不代表你可以放弃人工把关。该做的测试、隐私说明、真实身份认证一样都少不了。还有一条个人建议发布前做一轮完整的真机测试。AI生成的代码在桌面浏览器没问题不代表手机浏览器上也表现一致。至少要在iPhone Safari和安卓Chrome各跑一遍重点看触摸体验、音效初始化和屏幕旋转适配。如果你是第一次做别一上来就想着上架先发布一个网页版链接分享给朋友试玩收集一轮真实反馈再考虑平台发布这样成本可以压到最低。4.3 让AI当测试工程师自审提示词模板这一节是我认为这个项目里最值得单独拿出来说的技巧。要想提高AI生成代码的质量可以在每一轮迭代之后让AI给自己挑毛病。下面是我经常用的自审提示词模板。请以资深游戏开发工程师的身份对上面这份代码做一次Code Review。 重点检查 1. 是否有未定义变量或作用域泄漏 2. 是否存在可能引发死循环或无限递归的情况 3. 是否合理处理了玩家快速点击造成的重复触发 4. 帧循环是否唯一pause/resume逻辑是否覆盖全部场景 5. 数据结构和数组是否可能存在无限增长 6. 游戏状态转移是否覆盖了所有边界条件。 输出格式先列出你发现的问题再给修改后的完整代码最后用一句话解释每个修改点。这个模板和普通的“写代码”提示词有个关键区别它要求AI先给问题清单再给修改代码。这个顺序很重要。AI如果直接给代码往往不会解释为什么改要求它先列问题相当于逼它做一次系统性的推理改出来的代码稳定很多。我后来每个功能模块写完都会先让AI自审再让我本人做最终回归测试。这个流程走下来Bug率肉眼可见地下降。5. 项目做完之后的几点体会说说我真实的感受。蚂蚁搬家小游戏做完那天我花了一个多小时做最后的真机和浏览器测试把胜利界面、失败界面、蜘蛛巡逻、体力耗尽这些路径都走了一遍。说实话游戏本身不复杂复杂的是“人机对话”的节奏。AI擅长把一段清晰的指令变成可运行的代码但不擅长替你想清楚“游戏到底好不好玩”。好玩的判断标准在你这儿不在模型参数里。如果你也想尝试这套流程我给出三点建议。第一从需求说明书开始不要一上来就让AI写代码先把功能清单列出来AI才有稳定的输出基准。第二每一轮迭代只改3到5个点控制变量出了问题能立刻定位是这一轮改出来的。第三务必在项目后期安排一次另一个AI的代码审查这个阶段省下的调试时间远超你开启新对话的那几分钟。这套“纯AIWeb技术”的路线我现在已经复用到其他小游戏项目上。接金币、打地鼠、迷宫寻路基本都能靠一个HTML文件快速跑出可玩版本。如果你想验证自己的游戏创意现在最合适的启动方式已经不是下载Unity了而是打开一个AI对话把你脑子里的需求像我前面写的那样一步一步说清楚。最后再分享一个小技巧把每轮使用的提示词按项目保存下来。这些提示词就是你作为“AI产品经理”最核心的资产。下个项目开始的时候换个游戏名称和规则描述微调一下限制条件立刻就能复用整套工作流。这个习惯比多写几行代码值钱得多。