1. 蚂蚁搬家这游戏我用“纯AI 一个HTML文件”做了出来没开Unity没用Cocos没碰Godot甚至连包管理器都没装。我旁边只开着浏览器、一个AI对话窗口、一个能编辑HTML的文本编辑器然后花了一个下午把一款完整的“蚂蚁搬家”小游戏从零做到了能玩。代码是AI写的画面是AI画的交互逻辑也是AI搭的我做的事情就是提需求、测试、把bug反馈给它、再测。可能有人觉得这不就是“生成个网页”吗但如果把它当成一个真正的游戏项目来看要素其实一个都不少Canvas绘制角色和场景、requestAnimationFrame驱动主循环、碰撞检测、玩家鼠标输入、计分系统、状态机切换、最高分持久化存储。这些全部塞进一个HTML文件里双击就能在浏览器里玩。说句实在话做小体量的休闲游戏原型这条路不仅走得通而且效率比传统方式高太多。再说说这个游戏本身怎么玩。用鼠标点击场景里任何一个位置蚂蚁就会朝那个方向爬。场景中会随机刷出面包屑蚂蚁爬过去叼起面包屑然后自动带回屏幕左下角的蚁穴回到洞口得分加1。与此同时一只蜘蛛在场景里四处游走当它嗅到蚂蚁的气息后就会加速扑过来碰到蚂蚁直接游戏结束。界面上有开始页、游戏页、结束页三态切换左上角显示得分Game Over后能看到历史最高分。什么样的人适合看这篇如果你是完全零基础、不想装各种大型软件、只想体验“亲手做出一款小游戏”的普通玩家这篇的操作流程你完全可以照着走一遍。如果你想尝试AI辅助编程又不知道该从哪里下手这篇里的提示词模板和建议也可以直接抄。如果你已经是老手希望你别嫌弃这个玩具级项目——把AI辅助开发的SOP在这类小体量项目上跑通比一上来挑战大型项目要靠谱得多。1.1 这套“纯AI”工作流到底是怎么回事我所谓“纯AI”指的是制作过程中的实现环节全部交给AI去生成实现代码我本人不做手写编码而是负责需求定义、效果验收和问题反馈。技术栈一句话讲完一个索引HTML文件内部包含HTML结构、CSS样式和Canvas原生JavaScript代码不引用任何外部图片、模型或框架。这种“纯AI单文件”的模式本质上是在用文本描述替代传统的资源准备流程。传统做游戏要建工程、导入引擎、处理素材、写逻辑脚本其中美术资源、场景搭建、代码框架各占一大块工作量。纯AI模式把这些全都折叠成对话里的几轮需求描述生成结果是一个自包含的运行单元。对于以玩法验证为目的的小型项目来说这种折叠是降维式的便利。1.2 为什么“蚂蚁搬家”这个小品级玩法反而很有价值选择蚂蚁搬家不是因为玩法多复杂恰恰相反是看中了它的规则简单、边界清晰、画面不需要美术资源。这几条对于一个靠AI生成的项目来说特别关键。AI在生成代码时最大的短板是处理模糊需求和规则纠缠而蚂蚁搬家这个玩法几乎是一根直线找食物、搬回家、躲天敌规则之间只有简单的组合没有牵一发动全身的深度耦合。另外这个体量的项目正好适合当“AI辅助开发”的试验田。它不难到让人劝退也不简单到什么都学不到。一轮完整的开发流程——需求拆解、原型落地、体验反馈、BUG修复、功能扩展——都可以在一个下午的时间里循环好几遍。这个过程的SOP跑熟了以后换任何题材的小游戏你都能用同样的套路快速出活。2. 为什么这种小游戏天生适合AI直接生成2.1 玩法规则清晰天然适合拆成需求条目小游戏开发的难点不在代码量而在需求的描述。传统游戏开发里策划、程序、美术之间的信息传递损耗是项目延期的主要源头。而你把一个玩法发给AI时本质上是自己一个人包办了策划和产品经理的活——你需要把模糊的“好玩”翻译成明确的规则。蚂蚁搬家的规则清单很长这样蚂蚁能移动玩家点击地图设置目标点蚂蚁碰到面包屑后叼起叼起后自动回蚁穴到达蚁穴得分加1蜘蛛会在场景内游走蜘蛛触碰蚂蚁则玩家失败。这两条之间没有歧义AI生成代码时可以直接把每一条映射成一个函数或一次判断。换成一句“给我做一个好玩的蚂蚁游戏”AI也会给你写但写出来的东西大概率是拼凑感很强的烂代码因为“好玩”不是一个计算机能直接处理的需求。2.2 Canvas手绘美术不需要外部资源就能撑起画面很多人在做游戏时被美术资源卡住但蚂蚁搬家这个题材完全不需要素材库。蚂蚁就是Canvas画的一个椭圆身体、一个小圆头、两条触角、六条摆动的腿。蜘蛛用几个圆和线条拼出来。草地是绿色背景上随机撒一些更深的绿点。蚁穴就是一个带洞口的小土堆。这些东西全部用Canvas原生的绘图API画出来连一张图片都不用加载。Canvas对AI来说是个非常适合生成图像的接口因为它不是贴图没有文件路径、没有加载顺序、没有版权问题所有图形信息都以向量指令的形式写在代码里。画一只蚂蚁的过程就是执行一串“先画椭圆再画圆再画线”的指令。AI最擅长的就是把这种带坐标和颜色参数的过程式绘图写出来。做出来的视觉效果也许称不上惊艳但对于一个玩法原型来说信息传递足够清晰后期想改风格改几个坐标和颜色就能整体变样成本低到可以随手尝试。2.3 体验闭环完整再加机扩展不设限能让人玩下去的小游戏体验闭环一定是完整的开始、操作、反馈、结果、再来一局。蚂蚁搬家做起来很轻松——开始界面一个标题一个按钮操作过程中有蚂蚁腿的摆动、蛛蛛逼近的紧张感失败后有惩罚和重来入口。这个闭环本身就构成了一个游戏的最低可用版本不会出现“程序写好了但根本玩不起来”的尴尬。更难得的是这套玩法有清晰的扩展阶梯。第一版只有蚂蚁和面包第二代加上蜘蛛和危险判定第三代可以继续补加入雨天带延缓走路速度、加入多只蚂蚁分工、加入限制时间、加入双人分屏比拼。每一次扩展都是在一个稳定的核心骨架上做增量迭代成本摊得非常薄。我在做的过程中深有体会这种“跑起来之后再慢慢加东西”的感觉特别适合降低开发者的挫败感。3. 三代版本演进从“能跑”到“像个游戏”再到“有挑战性”3.1 V1.0先把核心循环跑通第一版的要求我压得特别低蚂蚁能走能碰食物能带回蚁穴能得分。就这4条别的什么都不要。AI用几十行代码就交付了跑起来的那一刻说实话很朴素——蚂蚁是一个小黑点没有动画没有界面装饰连个开始按钮都没有打开页面直接就是游戏世界。但这一版解决的是“这项目到底能不能成”的问题。很多人做小游戏死就死在第一步连个能跑的原型都搞不出来。如果你用AI辅助开发第一轮千万不要贪多哪怕最后只有一个圆点来回移动也要先让它跑通。代码一旦跑通后面所有事情都变成增量迭代心情和状态完全不一样。我第一版测出了两个重要信息方向完全正确以及——AI没用deltaTime游戏实际速度会和显示器刷新率绑定。后面细说。3.2 V1.1让画面动起来像一款真正的游戏能跑之后我开始补“游戏感”。我给AI提了几个具体到不能再具体的要求蚂蚁要画出身体、头、触角、六条腿腿要会摆动背景要加草丛和小石子蚂蚁搬运时面包屑要明确显示在蚂蚁背上加开始界面和结束界面加分时左上角数字要跳一下。这轮AI生成的代码量明显上来了但它并没有翻车原因就是我每个要求都具体到了“坐标形状触发条件”的颗粒度。这里有个很重要的经验当你希望AI提升视觉效果时千万不要说“把画面做得精致一点”。AI对“精致”这种主观词的理解完全不可控它可能把蚂蚁改成像素风也可能给你泼一屏幕赛博朋克配色。正确姿势是把审美需求翻译成可执行指令——“蚂蚁头部用半径4的圆身体用8乘5的椭圆六条腿按六个角度画线”。需求越具体AI输出越稳定。这轮结束后的蚂蚁已经是那个六条腿会摆的活物游戏看起来不再是技术演示而是有“角色”在动。3.3 V1.2加入危险机制游戏有了压力曲线原版玩法本质上是个散步模拟器玩家点哪蚂蚁走哪没有任何风险。到了第三轮我开始琢磨游戏性。让AI加入了一只蜘蛛蜘蛛在场景中随机游走当它和蚂蚁的距离小于120像素时进入追踪状态加速扑向蚂蚁碰到就直接Game Over。同时要求蜘蛛头上显示一个感叹号警告让玩家有提前预判和逃窜的空间。这个版本的难度曲线基本可用前期蜘蛛离得远玩家安心搬运随着蜘蛛慢慢靠近紧张感上升被追击时玩家要么遛蜘蛛要么放弃当前食物换条路。一个非常朴素的“压力循环”就跑起来了。后来我又顺手让AI加了一个雨天模式每隔几秒全屏降下雨滴蚂蚁搬食物时雨天会减速。这一笔扩展下来游戏的玩点就从“搬运模拟”真正升到了“策略取舍”。你完全可以按这个思路继续加东西但记住一条铁律每次只加一个机制跑通验证完再加下一个否则bug会互相纠缠排查成本指数上升。4. 核心代码拆解这几个关键逻辑值得看明白4.1 游戏主循环deltaTime是一切的基石代码核心就三块主循环、实体更新、碰撞检测。先说主循环。游戏循环的思路是让浏览器每帧调用一次回调在回调里更新世界状态并重新绘制画面。AI默认给出的代码一般长这样let lastTime 0; function gameLoop(timestamp) { const deltaTime Math.min((timestamp - lastTime) / 1000, 0.05); lastTime timestamp; update(deltaTime); render(); requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这里有两个容易忽视的细节。第一timestamp是毫秒必须除以1000转成秒速度单位才是“像素/秒”。第二我用了Math.min把deltaTime的限制设定为0.05秒这个上限是为了防止玩家切走浏览器标签页再切回来时两帧之间的时间差过大导致蚂蚁坐标瞬间飞出画布。这个坑是真实踩过的没有这行保护切后台再回来蚂蚁和蜘蛛的位置都会“瞬移”到地图外面游戏直接无法继续。有了正确的deltaTime之后所有移动逻辑都统一用“速度乘时间”来算。同样是蚁120像素/秒的移动速度在60Hz屏幕上每帧走2像素在144Hz屏幕上每帧走0.83像素单位时间内的位移完全一致。这一步不做对后面所有体验优化都白搭。4.2 蚂蚁的移动与搬运让“搬东西”这件事跑起来蚂蚁的逻辑比想象中简单本质是一个三态循环走向目标点、到达检查目标类型、决定下一步动作。用伪代码展开就是目标为空原地待命目标为食物走直线过去碰到食物叼起来把目标切换成蚁穴坐标回到蚁穴放下食物分数加1。核心移动代码大概长这样class Ant { constructor(x, y) { this.x x; this.y y; this.speed 120; this.carrying false; this.target null; } update(deltaTime) { if (!this.target) return; const dx this.target.x - this.x; const dy this.target.y - this.y; const dist Math.hypot(dx, dy); if (dist 2) { this.onArrive(); return; } const step this.speed * deltaTime; this.x (dx / dist) * step; this.y (dy / dist) * step; } onArrive() { if (this.target.type food) { this.carrying true; this.target { x: home.x, y: home.y, type: home }; } else if (this.target.type home this.carrying) { this.carrying false; this.target null; score; updateScore(); } } }里面最关键的位置就是这个if (dist 2) { this.onArrive(); return; }。如果没有这段到达判定蚂蚁会一直在目标点附近来回振荡因为当距离小于单帧移动步长时dx和dy会被反复计算蚂蚁每一帧都在“前进一点又后退一点”之间横跳画面看起来就像抽搐。这个函数写对了“搬东西”的节奏感立刻就有了。这里的“寻路”其实只是直线移动没有真正的路径规划。场景里没有障碍物蚂蚁走直线完全合理。如果以后要加岩石、水坑这类障碍就需要把移动逻辑换成网格化地图上的路径搜索算法但那就超出“小品级”的范畴了。对于蚂蚁搬家这个体量直线移动就是最优解。4.3 碰撞检测三类角色之间怎么判定游戏里碰撞分三种情况蚂蚁吃到食物、蜘蛛碰到蚂蚁、食物生成时避开蚁穴。基础判定用的都是同一个套路——两个圆心之间的距离小于半径之和就算撞上function isHit(a, b) { const dx a.x - b.x; const dy a.y - b.y; const dist Math.hypot(dx, dy); const r (a.radius || 8) (b.radius || 8); return dist r; }这里有一个AI默认做不到、需要人工提出来的细节蚂蚁吃食物不能等整个身体都碰到食物才算吃否则看起来就像食物被隔空吸走。我在需求里明确要求过“蚂蚁头部判定点”也就是从蚂蚁中心位置朝当前移动方向偏移几个像素作为检测点这样玩家看到的效果是蚂蚁先走到食物旁再低头叼起节奏自然得多。蜘蛛和蚂蚁的碰撞判定反过来阳判范围要比视觉尺寸大一圈我刻意把radius加到了16像素。这样蜘蛛还没完全压到蚂蚁头上游戏就已经结算玩家会觉得“这游戏判定挺合理、不阴人”。这类微调AI第一次生成时绝对想不到它只会做一个字面正确的圆形碰撞至于手感如何完全不管。所以体验调优这件事指望AI一步到位是不现实的最终还是得人来玩、来提意见。5. 实测翻车现场AI写代码时我踩过的5个经典坑5.1 蚂蚁在目标点附近疯狂抖动这是第一个遇到的坑点击远处目标时蚂蚁正常爬行到达后却不停止在原地左右来回横跳画面看着像BuggyAI发电报。原因就是前面说的“到达判定”逻辑缺失蚂蚁在目标点附近因为单帧步长过大坐标反复跨过目标点来回震荡。排查方法很简单在控制台输出蚂蚁每一帧坐标能看到x的值在目标点附近来回穿。修复方式是给update加到达判断距离小于阈值时不再移动直接进入到达处理函数。这个坑在AI生成的移动代码里几乎必现你完全不用慌张属于十次有八次会遇到的老朋友。5.2 144Hz和60Hz显示器上游戏难度完全不一样把游戏发给同事玩他的144Hz高刷屏上蚂蚁和蜘蛛都像开了倍速一分多钟就Game Over。我这边办公室里60Hz频率正常。原因就是AI首版没有用deltaTime每帧固定移动固定像素刷新率越高跑得越快。这不仅是手感问题在多人测试时还带来一个荒谬的结果不同人反馈的难度完全不可比。修法就是全部移动逻辑改为基于deltaTime。这个修复会牵扯不少代码位置如果你直接把“把移动改成基于deltaTime”发给AI它能改但强烈建议要求它“保留原有API只改update方法内部的计算方式”。这样不会牵连到其他渲染和碰撞逻辑。5.3 食物刷新在蚁穴里分数据假AI生成食物位置时用的是全画布范围随机数结果有那么几次面包屑直接刷在洞口蚂蚁出门就“搬”回一颗面包分数涨得毫无意义。我本来觉得无所谓后来连续玩了几把发现高分会变得很假玩家一眼就看出来这是系统漏洞。修复方式是给食物生成加约束生成坐标距离蚁穴至少80像素且与已有食物不能重合。AI实现起来就是用while循环反复尝试随机坐标条件不满足就重抽。注意一定要加最大尝试次数防止画布过小或食物过多时出现死循环让AI生成代码时主动写一个保护逻辑这个细节很多人会漏。5.4 AI“幻觉”出一个根本不存在的API有一次我想优化蜘蛛的追击轨迹AI在返回的代码里调用了一个名叫nativePathfind()的函数参数列表还有模有样注释也写得像真的。但实际上这个API浏览器里根本不存在一运行就报Uncaught ReferenceError。这种幻觉在复杂需求和长对话里特别容易发生AI为了凑出逻辑会自行编造接口。你不需要自己去查文档验证API真伪最省事的办法是把浏览器控制台的报错信息原样复制贴给AI。它一看到“nativePathfind is not defined”马上就明白自己编了东西会给出一版更合理的实现。这里也提醒一点如果AI在某次回复里开始写很“华丽”的函数名大概率是在自我发挥用报错信息约束它最有效。5.5 游戏运行越来越卡对象数组不清理这是最隐蔽的坑也是后面测试中真正影响体验的问题。AI用数组保存面包屑和雨滴对象只往里面添加却不想着在对象离开画布或完成使命后删除。游戏运行几分钟后数组里的对象动辄几百个主线程每帧遍历的代价越来越大最终蚂蚁和蜘蛛开始瞬移。排查方法在render函数里临时打印数组长度或者打开Chrome Performance面板录制一小段时间。一旦看到长度只增不减就是对象泄漏。让AI加上“对象生命周期结束即从数组中移除”的逻辑这类问题迎刃而解。做完整个项目我已经养成习惯了每完成一个新功能先检查它的生命周期清理逻辑这一步对长时运行的网页游戏是大前提。6. 一个人也能复刻提示词模板与操作SOP6.1 可以直接抄走的第一版提示词模板我把最终收尾版本的需求清单整理成一个提示词模板你直接贴给AI对话工具就能用。基于你用的AI产品不同效果会有细微差异但整体思路是通的请帮我用HTML Canvas 原生JavaScript写一个“蚂蚁搬家”小游戏要求如下 1. 打开页面后进入开始界面有游戏标题和“点击开始”按钮。 2. 点击开始后进入游戏画布尺寸960x540背景是草地风格。 3. 场景左下角有一个蚂蚁窝小土堆造型。 4. 玩家用鼠标点击场景任意位置蚂蚁就朝那个点移动。 5. 场景中随机刷新面包屑蚂蚁碰到面包屑后自动叼起并移动回蚂蚁窝到达后得分1。 6. 场景中有一只蜘蛛游走当蜘蛛与蚂蚁距离小于120时开始加速追赶碰到蚂蚁则游戏结束。 7. 左上角显示得分游戏结束时显示“游戏结束”和“重新开始”按钮并保存历史最高分到localStorage。 8. 整个游戏使用Canvas手绘图形不引用任何外部资源。 9. 使用requestAnimationFrame所有移动基于deltaTime计算保证不同刷新率下速度一致。模板里有两个必须写进需求的硬性条件一是“不引用任何外部资源”这能彻底避免AI试图加载图片、音效、字体导致本地打开时匪夷所思的CORS问题二是“所有移动基于deltaTime”直接绕开刷新率大坑。第二条前面吃过亏现在几乎每次做游戏项目都会写进第一版需求里。6.2 迭代调试的几条黄金法则一次只提一个需求。同一次回复里塞进太多“顺便加一下”AI改动的范围失控很容易把之前能跑的代码改崩。正确做法是跑完上一版、确认没新问题再提下一处改动。修改时尽量把整个HTML文件贴回AI。有些AI产品不支持项目级上下文你只给它贴一个函数片段它可能会在其他地方做出莫名其妙改。完整贴文件虽然占对话长度但AI能全局把握改出来的内容可靠得多。另外我习惯把每版另存为index_v2.html、index_v3.html改坏了随时回退坏心情和坏代码都会少很多。报错信息直接粘贴给AI。有一次我跟AI说“蚂蚁不动了”它连续猜了三种原因都不对我把控制台的红字报错贴上去它半分钟定位到问题。文字描述会带入你自己的猜测容易误导报错信息是计算机的原话AI理解起来精准得多。让AI在复杂逻辑处加注释。注释不光方便你自己阅读更重要的是下一轮迭代时AI能快速回忆起自己之前的意图。你在需求最后补一句“请在复杂逻辑处加中文注释”后续的所有版本修改效率都有明显提升。6.3 从本地HTML到后续分发当前项目的交付物就是单个HTML文件双击浏览器就能玩发给朋友通过浏览器打开也直接能跑。如果你满足于此整个项目到这里就已经完整结束了。我自己最常用的方式是把这个文件扔到家里内网服务的一个目录里局域网内任何设备都能打开玩手机用浏览器访问也能跑因为触摸屏点击事件在Canvas里天然兼容鼠标位置——严格来说Canvas的click事件要吃坐标但桌面端和移动端浏览器在这类简单交互上体验差距不大。如果后续想更进一步往各大平台渠道分发那就要开始接触平台要求的打包和适配流程。但那是另一个话题了而且从当前原型到上线之间真正要花时间的不是移植代码而是平台资格、资源管理等非技术环节。把这个小项目当作流程练习入门是完全可以的但在那之前先把第一个能玩的HTML文件做出来再说。7. 写在最后的个人体会这个项目做完我最大的感受是AI真正改变的不是“写代码的速度”而是“尝试一个想法的成本”。以前脑子里冒出一个游戏玩法要建工程、找素材、写界面每一步都可能把热情磨掉。现在我用语言把玩法描述清楚AI几秒就把一版能跑的Demo交到我手里我上手玩、发现问题、回去再改一个下午能迭代五六版。被压缩掉的这部分时间换来的是更频繁的试错和更低的创新门槛。但也必须说实话AI目前做不了真正有质感的游戏。美术风格、数值手感、让人上瘾的反馈节奏这些都需要人反复体验、亲自调整。AI擅长的是把明确的需求变成可运行的程序至于“这个游戏到底哪里好玩”的判断它给不出答案。你玩一次觉得爽的点要通过你的嘴翻译成需求它才能行动。最后再分享一个小技巧如果AI第一版生成的游戏不好玩别急着否定AI的能力先检查一下自己的需求里有没有给出足够具体的体验描述。你把自己放在产品经理的位置把玩家想要的感受拆成一条条可执行的行为规则AI的表现会立刻不一样。先跑起来再谈好玩——这句做游戏的老话放在AI辅助开发时代依然通行。