这条标题听起来像个标题党但昨天我确实把一款蚂蚁搬家小游戏用纯AI做了出来全程没碰游戏引擎。这里的“纯AI”不是指让AI念个剧本而是从玩法定义、代码生成、素材生成到性能优化所有脏活累活都交给AI Agent我这个“开发者”主要干三件事说清楚需求、验收结果、该兜底的时候兜底。如果你也好奇AI到底能不能独立做出一款能让人玩下去的小游戏或者你手里正好有个游戏创意但不想为了它去学一套引擎这篇记录应该能给你一份可复现的参考。我用的技术栈其实非常朴素HTML、CSS、JavaScript加上一个Canvas画布而你只需要一个会写代码的大模型。1. 拆掉引擎的那层壳为什么我决定不用Unity直接裸写HTML51.1 之前用Unity做微信小游戏时攒下的“不满”先交代一下背景。我上一款小游戏是用Unity做的走的是微信小游戏打包那套流程。为了一个单屏、玩法不超过三个按钮的休闲游戏我不得不建工程、配资源、管生命周期打包产物体积轻轻松松就上了好几MB。Unity对3D、复杂物理和大型项目来说确实强但对“想用AI快速验证一个点子”的场景它太沉了。更现实的痛点是AI模型的训练数据里虽然有很多Unity代码但让它直接对着一个Unity项目改逻辑它经常会把预制体、场景文件、序列化字段搞乱。你写一句“把蚂蚁速度调快”它改完Prefab字段可能连带把另一个对象的数据也改崩了。我意识到AI生成的代码是纯文本纯文本最好的执行环境就是浏览器而不是需要编译、打包、烘培资源的引擎工程。1.2 纯AI开发的最小闭环是什么我这次采用的工作流是浏览器写代码 → 刷新页面 → 看效果 → 把Bug描述扔回给AI → 再刷新。整个循环以秒计算而不是像Unity那样“构建一下、等进度条、装进开发工具里看”。这背后的关键点是AI大模型最擅长的就是生成结构化文本而HTMLCSSJavaScript恰好是一种不需要任何额外工具链就能在浏览器里跑起来的结构化文本。你甚至可以不需要安装IDE一个记事本加一个浏览器就够了。我在网页版AI助手里把需求描述贴进去拿到完整代码后直接保存成HTML文件双击打开就能玩。这个最小闭环带来的直接好处是我不用在开始写第一行代码之前先花一周时间学习游戏引擎的架构。对于“蚂蚁搬家”这个体量的小游戏引擎里90%的功能我都用不上而裸HTML5 Canvas能覆盖剩下99%的需求。1.3 几条技术路线的横向对比我把候选方案摆在一起比过包括Unity、Python的pygame、以及最终的HTML5 Canvas技术栈学习成本生成产物体积打开门槛AI生成可靠度移动端触控Unity高入门到能上架要数月几MB到几十MB需要下载/安装或走平台包壳中等改工程文件容易翻车好但要处理适配Python pygame中几十KB但需Python环境用户要装Python或打包exe中上代码生成可以但分享很麻烦弱触控支持不原生HTML5 Canvas 原生JS低几十KB浏览器直接打开零安装高这段代码AI写得特别顺手好天然支持触控事件从表格就能看出HTML5 Canvas几乎是“AI生成游戏代码”这条路线上的成本最低点。尤其要注意微信小游戏这类平台本身也是跑在WebView环境里的你写好网页后再按平台规则包壳比起从Unity工程转小程序要轻得多。当然这不意味着Unity一无是处如果你要做的是重交互的3D游戏别犹豫老老实实用引擎。1.4 我对“游戏引擎都没用”这句话的真实理解很多人看到“游戏引擎都没用”会觉得这是噱头但用过一轮之后我认为它描述的是一个事实对单屏休闲小游戏来说引擎带来的组织能力在这个体量上体现不出来反而成了AI协作的障碍。没有引擎的束缚之后代码结构可以随意调整AI重写一个模块时不需要考虑引擎的生命周期钩子只需要保证Canvas上的绘制逻辑正确。当然不排除以后AI能完全驾驭Unity工程但至少在现在这个时间点如果你和我一样想让AI独立扛起一个小游戏选择最没有中间层的实现方式AI的成功率最高你的验收成本也最低。2. 蚂蚁搬家的玩法拆解三个核心机制和一串待办任务2.1 为什么选“蚂蚁搬家”这个题材题材是我特意挑的不是随手乱选。蚂蚁搬家有几个很适合AI生成和玩家直觉的优势场景单屏就能装下不需要卷轴地图目标很直观把食物搬回家过程有天然的队列感视觉上好看而且它自带“协作”叙事比“保护公主”之类的题材更容易让人秒懂规则。我也见过“奶娃快跑”这类跑酷型小游戏但蚂蚁搬家其实比跑酷更简单因为玩家不需要控制连续跳跃只需要做方向性决策。这种决策密度对休闲玩家来说刚刚好不会手忙脚乱但又有操作空间。2.2 三个核心机制是怎么定下来的我给AI定义的第一版玩法包含三个机制这三个机制我花了不少时间想清楚不是为了堆功能而是确保每个机制都可以用十几行代码实现。第一个机制是“点击指挥”。玩家点击场景中的任意位置当前选中的蚂蚁或整个蚂蚁小队就朝那个位置移动。它构成了所有操作的基础也让AI很容易理解“玩家输入”和“蚂蚁行为”的关联。第二个机制是“队列搬运”。蚂蚁遇到食物后自动拾取然后沿着来路返回巢穴把食物放下再继续出去找。这里隐含了一个视觉重点蚂蚁要排成一列一只接一只走才能叫“搬家”。如果所有蚂蚁都独立的飞来飞去玩家会觉得自己只是在操作一群虫子而不是在看一支运输队。第三个机制是“天敌与天气”。我加了下雨和一只偶尔出没的蜘蛛作为干扰因素。雨水会在地图上形成水坑蚂蚁碰到会掉一点生命并减速蜘蛛会追击离它最近的蚂蚁。为了让玩家有事可做我设计了一个“吹哨召回”操作点击巢穴可以让所有蚂蚁快速撤回等雨停或蜘蛛离开再重新出发。这三个机制之间的逻辑关系是这样的点击指挥决定蚂蚁去哪队列搬运决定蚂蚁存在的意义天敌与天气制造风险和决策点。没有第三个机制游戏会变成纯点按模拟器没有一点紧张感没有第二个机制整个题材就不成立。2.3 给AI约定的数值和手感参数AI生成游戏最容易出的问题不是代码不跑而是跑起来的手感非常奇怪。蚂蚁走得比火箭快、搬食物一瞬间完成、水坑对所有蚂蚁一视同仁这些都会毁掉游戏体验。所以我在需求里直接给了一组初始参数让AI不要自由发挥速度值。我定的数值如下蚂蚁移动速度在60到80像素每秒携带食物后速度降为70%食物刷新间隔是3到5秒随机一个队列中每只蚂蚁对前一只的跟随延迟控制在0.15到0.3秒这样看起来是一支队伍而不是一列连体虫雨水区域从屏幕顶部生成下落速度约120像素每秒。这些数值不是拍脑袋而是我基于一个960宽、640高的Canvas画布估算的。如果你用不同的画布尺寸换算公式很简单速度大约是画布宽度除以12到16。AI只要拿到了具体数值就不会出现“蚂蚁瞬移”这种地狱场面。2.4 把大需求拆成AI能消化的“子任务”我一开始直接把整段需求扔给AI结果它给我生成了一坨能运行但是缺少细节的代码。后面我把需求拆成了五个子任务按顺序逐次对话子任务一画一个草地背景放下一个蚁巢和一个砂糖块蚂蚁能从蚁巢出发移动。子任务二让蚂蚁找到砂糖后自动拾取并且带回蚁巢。子任务三让所有蚂蚁排队跟随而不是各自为战。子任务四加雨水区域和蜘蛛实现碰到后的减速掉血。子任务五加分数、关卡倒计时和开始/结束界面。每个子任务都单独测试通了再进入下一个。这种“最小可用块”策略非常重要因为AI在单次对话里处理的信息量有限你一次性塞给它十个需求它一定会丢掉一两个细节。拆开后每次它都只需要解决一个相对单纯的问题产出质量明显更高。3. 给AI布置作业的全过程从需求描述到可玩原型3.1 第一版提示词长什么样这一节我把自己的真实提示词放出来你可以直接抄。我的第一版提示词是这样的请用HTML CSS JavaScript Canvas实现一个蚂蚁搬家小游戏。 画布尺寸960x640。 场景草地背景左侧有一个蚁巢土堆右侧随机位置生成砂糖块。 玩家点击任意位置蚁群会以队列的方式移动过去。蚁群由一只领头蚂蚁和10只跟队蚂蚁组成。 蚂蚁接近砂糖块后自动拾取然后带回蚁巢。带回一个砂糖得10分。 所有蚂蚁共用同一个坐标序列后一只蚂蚁跟随前一只蚂蚁的轨迹点保持10到15像素间距。 蚂蚁是简单的黑色椭圆加触角不需要复杂绘制。 请直接输出完整可运行的HTML文件代码。这版提示词里我做了几件关键事第一给它一个明确的验收标准比如“共用坐标序列”“保持间距”第二我用自然语言描述了数据结构这比说“请使用队列”更清晰第三我限定画布尺寸避免它生成一个自适应布局导致东西乱跑。3.2 第一轮生成的结果能跑但完全没有“搬家”的感觉AI很快给了一版能运行的HTML文件。双击打开之后蚂蚁确实能从巢穴出发确实能点击移动也确实能“碰到”砂糖。但问题是它只是碰到就消失然后过一会儿在巢穴里冒出一个分数10的飘字整个过程没有搬运的视觉反馈。这是AI生成的典型“功能正确、体验错误”逻辑上拾取成功了但玩家看不见蚂蚁扛着食物走三步再放下的动画过程。搬运感被AI用“瞬移替代”省掉了因为它的训练数据里更常见的是“拾取即入背包”的游戏逻辑而不是“搬运”这种需要额外渲染的过程反馈。我没有直接否定这版代码而是补了一条新需求蚂蚁拾取砂糖后食物要变小并吸附在蚂蚁身体上方跟随移动到巢穴后再消失。这一条要求出来之后AI理解了“视觉上必须出现一列扛着食物的蚂蚁”整个场景才开始有搬家的意思。3.3 多轮迭代里最管用的提问句式跟AI协作时提问方式决定返工次数。我试过用“这个游戏有问题帮我修一下”这种模糊描述结果AI回了一堆无意义的道歉和猜测。后来我固定用四段式反馈模板效果稳定复现步骤打开页面后点击了屏幕右下角的砂糖块。实际现象所有蚂蚁都朝砂糖位置移动但它们到达后叠成了一团没有任何一只把糖搬回去。预期行为应该只有离砂糖最近的一只蚂蚁出队搬运其他蚂蚁保持等待或跟随。相关代码把蚂蚁移动的那段代码贴给它标注“这里可能是问题点”。这个模板的本质是给AI一份“最小可复现Bug报告”就像你在GitHub提Issue一样。AI不需要猜测你的意图它只需要对着一条具体指令做修改。实践中我最大的体会是你对现象描述得越精确AI改对的概率就越高。3.4 多AI协作的分工方式这次我实际上是让三个不同的AI协作完成的。一个负责生成核心玩法的代码我称它为主写手另一个专门做代码审查我把主写手生成的完整代码贴给它让它找潜在性能问题第三个负责生成美术风格参考和音效建议。它们之间不需要互相讲话由我当“翻译官”。比如我把主写手的代码交给审查AI让它列出“可能导致性能低下的写法”它指出蚂蚁循环里有频繁的数组拼接操作我就把这个意见回传给主写手让它改成环形缓冲。又比如让美术AI出素材时它会给我输出“蚂蚁应该有三节身体”的提示我再把这个描述转成代码绘制参数给主写手。这种多AI协作模式有一个风险就是要防止AI之间互相否定导致方案来回跳。我的经验是每次只把一类问题抛给一个AI并且明确告诉它“保持现有功能不变只解决我提出的问题”。没有这个限制条件第二个人会把第一版架构推倒重来白白浪费几轮对话。4. AI写代码的Bug实录蚂蚁排队时撞成一团4.1 最经典的翻车现场十只蚂蚁叠成一个点迭代中我遇到最搞笑也最典型的Bug是蚂蚁移动的目标点设置错误。AI第一版实现里每只蚂蚁都在“独立寻路到当前点击位置”而不是“跟随前一只蚂蚁走过的轨迹”。结果就是十只蚂蚁从不同的路径到达目的地后互相穿插、重叠成一个黑色圆点看起来像一串葡萄。交互层面更矛盾的是点击一个砂糖块整队蚂蚁都会朝糖冲过去第一只蚂蚁把糖捡走之后后九只到达糖原来的位置后发现没东西可搬于是原地转圈。这个Bug不解决游戏根本没法玩。4.2 排查链路我没有直接改代码先让AI解释逻辑我当时没有急着让AI修而是先问它“请描述一下每只蚂蚁如何决定自己的移动目标”。这一步很关键因为AI生成的代码有时连它自己都没法直接定位。它的回答暴露了问题根源每一只蚂蚁的目标都是“最近的前景目标点”或者“玩家点击位置”根本没有队伍链条的概念。找到根因后修复方案就清晰了让领头蚂蚁每帧把自身坐标压入一个轨迹数组后一只蚂蚁以“轨迹数组中靠前一定距离的点”作为自己的目标。这其实就是经典的“Path Following with Spacing”算法只是AI在没有明确要求时很少主动使用这种方案它默认你只是想移动一群独立的个体。4.3 修复后的核心代码片段我让AI重写了移动逻辑核心代码是这样的let trail []; // 记录领头蚂蚁走过的轨迹点 function updateLeader() { trail.push({ x: leader.x, y: leader.y }); if (trail.length 60) trail.shift(); // 只保留最近60帧的轨迹 } function updateFollower(ant, index) { // 每只蚂蚁沿轨迹落后(index 1) * 2帧的点保证间隔 let trailIndex Math.max(0, trail.length - (index 1) * SPACING); let target trail[trailIndex]; if (target) { let dx target.x - ant.x; let dy target.y - ant.y; let dist Math.hypot(dx, dy); if (dist ant.speed) { ant.x (dx / dist) * ant.speed; ant.y (dy / dist) * ant.speed; } else { ant.x target.x; ant.y target.y; } } }这个方案的好处是O(1)的数组操作加一次距离计算十只蚂蚁没有性能压力哪怕放大到50只也能顶住。而且视觉上一旦领头蚂蚁转弯后面的蚂蚁会按照轨迹“压弯”那种列队行进的质感立刻就出来了。4.4 其他几个高频Bug都值得记录除了叠罗汉我整理了几个AI几乎每轮都会犯的毛病。第一个是Retina屏模糊问题。AI生成的Canvas代码直接固定宽度和高度没有做设备像素比适配在手机上看所有文字和蚂蚁边缘都是糊的。我在需求里加了一条“canvas.width cssWidth * devicePixelRatio再用ctx.scale(devicePixelRatio, devicePixelRatio)”之后问题消失了。第二个是点击事件穿透。AI习惯用document.addEventListener监听click但游戏场景里有按钮、有食物、有地面它一开始把整个页面的点击都当成“让蚂蚁移动”导致玩家点结束按钮时蚂蚁也会往按钮方向跑。修复方式是区分“UI层”和“游戏层”只有游戏Canvas区域的点击才触发移动。第三个是requestAnimationFrame的帧率问题。AI生成的移动代码用的是每帧移动固定像素在60Hz屏幕上没问题但遇到120Hz屏幕蚂蚁速度快了一倍。我自己在手机实测时发现这只队伍疯跑最后让AI改成基于时间戳的移动方式每帧位移乘以动态的事件间隔缩放。4.5 我从Bug清单里提炼出的“AI验收用例”踩了这么多坑后我开始整理一份可以直接发给AI的验收清单每次改完代码都让它自查Canvas在1倍和3倍屏下元素边缘是否清晰。点击任意空白区域蚂蚁是否会重叠成同一点。点击UI按钮是否同时触发了游戏移动。在120Hz刷新率下移动速度是否和60Hz一致。蚂蚁携带食物后食物是否保持在蚂蚁身体上方而不是穿模。这套验收用例相当于给AI竖了几根“栏杆”它没撞倒任何一根我才会认为这次迭代真正完成。5. 从浏览器Demo到平台审核上线前的硬性检查单5.1 单HTML文件只适合演示不适合上线在浏览器里验证完玩法后我面临一个现实问题如果想把游戏放进小游戏平台原封不动的单HTML文件通常过不了审核。不是说平台禁止单文件而是平台要求你提供明确的页面入口、资源管理和生命周期回调单文件里揉成一团会让审核人员很难判断代码边界。我的做法是先做一次工程化拆分把背景、蚂蚁、食物、特效分别放到不同函数模块里将静态资源统一集中到一个资源清单对象中。这个拆分动作我不排斥自己动手因为AI重构时容易迷失“哪些函数是被谁调用的”这时候人工把控模块边界更高效。5.2 侧边栏复访能力一个绕不开的硬门槛大多数小游戏平台在审核时有一条硬性规定原话大意是小游戏必须接入侧边栏复访能力否则将被平台审核拒绝请接入该能力后重新上传代码。我第一次提交时就踩了这个雷纯网页Demo能玩没有任何问题但平台认为没有“复访入口”就等于丢失了大量老用户场景。具体的接入做法依赖于每个平台的文档但共通逻辑是在游戏启动时调用平台提供的侧边栏组件接口用户可以从侧边栏直接回到最近玩过的小游戏页面。我提前在代码里预留了一个空的api入口然后按平台最新文档填入真实SDK调用重新上传后审核就通过了。这个坑提醒我AI并不知道平台最新的审核规范它生成的代码再完美也替代不了人去阅读平台规则。5.3 个人信息处理能不做就不做审核材料里还有一项很典型的隐私要求开发者仅处理为实现小游戏功能所必要的个人信息这些权限将获得用户同意后才能调用。我的小游戏连账号系统都没有理论上最安全根本不需要申请任何个人信息权限。但AI给我加了一个本地排行榜功能顺手写了一段读取本地存储的代码。虽然在技术上是无害的但为了避免隐私合规上产生不必要的解释成本我直接砍掉了这个功能让“排名”变成纯本地会话内展示不写入存储。这个判断AI做不了因为它不知道“最小化收集”对审核来说比“功能完整”更重要。5.4 手机端触控和大小的实测我在开发阶段用电脑浏览器看得挺顺眼一上手机就露馅了。首先是移动端点击有大约300毫秒的延迟虽然现代浏览器大多已经通过meta viewport处理但我还是加了一行touch-action: manipulation来去掉双击缩放等待。其次是画面尺寸适配我原来固定960x640在手机上要么被拉伸变形要么四周留白。最后的处理方式是把Canvas改成等比缩放模式以960x640为设计基准计算出手机可视区域的缩放比例再通过CSS把画布铺满内部坐标不动。这样做的好处是所有逻辑坐标不变AI不用跟着适配逻辑一起改只改了一层渲染缩放而已。5.5 最终上线检查单我把检查项压缩成一张清单你以后用AI做完网页小游戏想上平台的话可以参考检查项具体操作侧边栏复访确认平台文档中该版本SDK的入口位置填入真实调用隐私说明在游戏启动页或商店页声明不收集个人信息如需收集则展示同意弹窗首屏加载压缩代码和图片目标首屏时间在2秒以内素材版权所有AI生成素材标注生成来源优先使用CC0素材库在线状态确认不支持本地单机运行不上架则忽略上架则按平台要求接入在线校验这张清单是我踩了几次拒审之后总结的照着过一遍能省下大量的提审等待时间。6. 纯AI做小游戏的边界能做的和不能做的6.1 AI超额完成的部分我必须承认这次开发里面AI的完成度比我预想的高。它生成的初版代码就实现了点击移动、食物拾取和计分整体达标率大概有70%。写队列跟随算法的时候我甚至不需要解释“轨迹采样”这个术语它直接给出了可以跑的代码。对一名产品出身、没有系统学过游戏开发的博主来说这个效率太可观了。我最意外的部分是它对“蚂蚁搬家”场景的理解它自发地给食物搬运过程加上了“数量减少”的视觉反馈还会在巢穴上方弹出一个简单的糖果堆叠计数这些都是我没有明确要求的合理设计。可见当任务边界足够清晰时AI可以利用自己的“世界知识”补全一些人性化细节。6.2 AI翻车最频繁的部分但AI的短板同样明显。首先是平台SDK它的训练数据不可能覆盖每个平台刚更新的接口凡是涉及官方API的部分我只能自己翻文档对照其次是数值手感它很难理解“蚂蚁的速度跟人手指的反应时间应该怎么匹配”这类主观体验需要真机试玩后手动微调再次是美术风格的统一性同一个AI生成的三张素材蚂蚁、砂糖块和草丛的笔触风格可能完全不像一个世界里的东西。还有一类问题更隐蔽AI对于“合规边界”没有判断力它不知道某个素材可能有版权风险也不知道某个功能在审核时会变成减分项。所以“AI生成、人来把关”的原则在合规环节尤其不能放松。6.3 什么人最适合走这条路线根据这次尝试的经验我觉得有三类人最值得复制这条路线。第一类是像我这样有创意但没系统学过游戏开发的人AI能把想法快速变成可点开玩的Demo帮你跨过技术门槛第二类是独立开发者你可以在AI生成的代码上快速验证玩法和用户反馈再做是否用引擎重写的决策第三类是想学习编程的新手通过这种小项目你能很直观地看到“需求如何变成代码”比啃教程有成就感得多。如果你本身是资深游戏开发我反而不建议为了不用引擎而硬不用引擎。你已经具备引擎思维Unity或Cocos能给你更成熟的生态。这条纯AI裸HTML5的路线本质上是为“快速验证创意”设计的轻量方案不是要推翻游戏行业的生产方式。6.4 我的公道话做完整款游戏之后我最大的感触是纯AI做小游戏这件事真正考验人的不是编程能力而是“把需求说清楚”的能力。你给AI的每一句话都会被它当成产品需求文档执行。你以为你说了“蚂蚁要有队伍感”它可能理解成“蚂蚁要在队伍里呆着不动”。所以以后如果有人问我做AI小游戏最重要的是什么我会建议他把时间花在写一份连实习生都能看懂的验收标准上剩下的活儿AI比你想象中扛得住。如果你也想试一次不要从大型RPG开始就从“蚂蚁搬家”这种单屏玩法开始。把你脑子的规则一条条写下来扔给网页版AI助手做好研究最少三十轮迭代的准备你会亲身体会到游戏引擎真的可以被暂时搁在一边而AI真的能帮你把一个只存在于脑袋里的点子变成别人手里玩得下去的游戏。最后再分享一个我踩出来的经验每一次让AI改代码前发一份“当前代码全量期望改动点验收条件”比让它凭空“优化一下”靠谱一百倍。验收条件里哪怕只写清楚“蚂蚁不要叠在一起”“食物要跟着蚂蚁走”这两条都能让你的AI队友少走一半弯路。