最近我做了一件说出去朋友都不太信的事用AI聊天窗口从零做了一款叫《蚂蚁搬家》的网页小游戏全程没打开过Unity、Godot安装包里连游戏引擎的影子都没有。就是跟AI反复对话让它写HTML、Canvas和JavaScript代码写出来一个能在浏览器里真实可玩的成品顺手把链接丢到群里大家玩完第一反应都是这真是AI写的这篇文章想聊清楚的东西有三层第一什么类型的游戏适合纯AI开发什么情况下你真的需要引擎第二我实际用AI开发《蚂蚁搬家》时从提示词到调试、踩坑的完整过程第三没有引擎的情况下这个小游戏是怎么做到上线可玩的。不管你是好奇AI写代码到底靠不靠谱的技术同学还是想低成本验证一个游戏想法、又不想一上来就啃引擎的独立创作者这一篇应该都能给你省下不少试错时间。1. 为什么敢不用游戏引擎先想清楚“蚂蚁搬家”需要什么很多人听到做游戏三个字第一反应就是Unity、Godot、Cocos好像不用引擎就做不了游戏。但《蚂蚁搬家》这种玩法本质上只需要三样东西一个循环刷新的画面、几个可以交互的对象、一套简单的碰撞判定。这三样东西原生HTML和Canvas完全能扛住游戏引擎在这里反而属于杀鸡用牛刀。1.1 这个玩法本质上只需要三样东西我拆解《蚂蚁搬家》的核心逻辑其实就几条画面中央偏右有个巢穴场地上散落着豆子玩家点击一只蚂蚁蚂蚁自动走向最近的豆子碰到之后把豆子搬回巢穴巢穴计数加一限时60秒内尽量多搬。听起来简单但它确实覆盖了游戏开发的基本要素游戏循环、输入响应、状态管理、碰撞检测、分数系统。这些在纯浏览器环境下怎么写游戏循环用requestAnimationFrameCanvas负责每帧重绘画面鼠标点击用事件监听蚂蚁和豆子的碰撞可以用距离判断分数和倒计时就是变量累加。全程只需要一个.html文件不需要导入任何外部资源不需要配置构建环境不需要维护任何依赖。AI在这种场景下特别能打因为它的训练数据里大量类似的Canvas小游戏demo你跟它说清楚需求它能在几十秒内给你端出一套能跑的原型。真实测试下来第一版代码从无到有只花了不到两轮对话。引擎能做什么引擎擅长的是资产导入、场景管理、复杂物理模拟、粒子特效、多人同步这些是《蚂蚁搬家》现阶段完全用不上的。你把引擎这一层重量压进来反而增加了理解成本、打包体积和调试复杂度。1.2 用引擎反而更别扭的三个地方诚实地讲我也试过用Unity做小游戏路径完全不同新建工程、导入Sprite、搭场景、挂脚本、调生命周期、打包WebGL这一套流程光是把环境跑通就能消耗掉你最初半小时的探索热情。而AI对某个具体版本引擎API的掌握程度反而不如它对原生JavaScript准确。我见过好几次AI把Unity旧版本API和当前版本API混在一起写报错之后连修都难修。第二个别扭的地方是打包体积。Unity WebGL哪怕是最简单的场景默认模板压缩之后也要几MB起步而《蚂蚁搬家》这种纯HTML游戏文件只有20KB上下加载速度天差地别。对一个休闲小游戏来说玩家点开链接恨不得一秒看到画面加载三秒钟已经算劝退。第三这类小游戏不需要美术资源管线。蚂蚁、豆子、巢穴全部用Canvas画出来就行AI甚至能给你画出会动的蚂蚁腿。你用引擎反而要先准备一套贴图纯HTML方案里这一步直接省了。如果哪天真要做到复杂物理、3D场景、大地图我第一个举手说该上引擎但不要为了用引擎而用引擎先看需求配不配得上那个重量级工具。2. 纯AI出代码的第一版提示词怎么给代码怎么验收纯AI开发不像你想的那样随口说一句帮我做个蚂蚁搬家小游戏就能拿到成品。我第一次这么试AI给了我一个画面很漂亮但点哪都没反应的静态页面。问题出在提示词太模糊它不知道你想要的玩法到底是什么。把需求说得越明确AI生成的第一版质量越高这个投入产出比非常惊人。2.1 我用的第一版提示词长这样下面这段是我的真实提示词你可以直接拿来改请帮我写一个网页小游戏“蚂蚁搬家” 1. 用 HTML Canvas 原生 JavaScript不要使用任何框架和外部库 2. 画面尺寸自适应浏览器窗口宽度不小于800像素 3. 游戏规则玩家用鼠标点击一只蚂蚁蚂蚁会自动寻找最近的食物黄色圆形豆子搬运回右侧的巢穴褐色半圆。每搬回一个豆子得10分限时60秒 4. 蚂蚁用红色小圆表示食物用黄色圆点表示场地内保持10颗豆子搬完自动补充 5. 要有开始按钮、倒计时、当前得分、重新开始按钮 6. 所有代码放在一个 html 文件中加中文注释逻辑清晰 7. 不要使用任何外部图片资源。为什么提示词这么啰嗦核心原因是AI的自由发挥是可控的但你要给它边界。限定技术栈它就不会给你引入一个你不知道的框架限定玩法和反馈方式它就不会做出一只起飞乱飞的蚂蚁限定UI要素它才知道你需要一个完整的游戏闭环。这套提示词结构我后来抽成模板了放在第六节你可以直接套用到任何休闲小游戏上。第一版生成出来的代码有280行左右保存成ant_game_v1.html双击在浏览器里打开能跑。能玩但问题也很明显窗口一缩小巢穴直接跑到屏幕外面去了蚂蚁走到豆子旁边豆子不消失倒计时有时快有时慢。这些就是后面的踩坑环节。2.2 第一次跑起来的正确姿势很多人拿到AI代码后习惯直接问对不对其实更好的做法是先自己跑一遍再看报错信息。我的习惯是拿到代码立刻存成文件浏览器打开按F12看Console面板。AI写代码也像一个手生的新人报错是常态但好消息是报错信息对AI而言就是最好的修正剂。我第一版第一次打开时白屏控制台报错Cannot read properties of undefined (reading getContext)原因是AI把画布初始化代码写在了一个还没加载完的节点前面。这种时候你不需要自己看懂代码直接把整段报错复制回AI对话框再加上一句请修复这个错误同时检查是否还有其他初始化顺序问题它很快就能改好。这里插一条关键心得修完一轮务必另存为ant_game_v2.html不要覆盖原文件。AI改代码有时候会改出新的问题保留每个版本文件你才有快速回滚的余地。我在这个项目里至少存了六个版本最后上线的是v5而v4在功能上其实比v5更完整只是多了一处小卡顿。有历史版本兜底心态会稳很多。3. AI最容易翻车的四个地方坐标、碰撞、时序、状态机既然敢说纯AI开发就不能只报喜不报忧。我这次踩的坑基本都集中在四个技术点上坐标写死、碰撞误判、循环时序混乱、状态机缺失。这四个坑不是《蚂蚁搬家》专属任何AI生成的Canvas小游戏都会遇到提前知道能省下大量循环纠错的时间。3.1 坐标写死把800x600塞进代码的所有角落AI的第一版代码里巢穴位置写的是{ x: 750, y: 550 }食物生成范围是x: 50到750蚂蚁初始位置{ x: 400, y: 300 }。这三个值全部是按800x600画布写死的一旦浏览器窗口不是这个比例巢穴可能跑到屏幕外或者食物生成区域只占画面一角。这其实是AI训练数据的老毛病——它看过太多固定尺寸的demo代码天然倾向于硬编码坐标。解决方式很简单在提示词或修复指令里明确写一句所有固定坐标改成相对于画布当前宽高的相对坐标然后再检查一遍有没有漏网的魔法数字。修复后的逻辑是巢穴位置等于canvas.width - 60, canvas.height - 50食物生成范围是20到canvas.width-20蚂蚁初始点在画布中心。这么一改窗口怎么拉游戏元素都待在应该在的位置上。这是纯AI开发里性价比最高的一次修复杂交AI改起来快你验收也直观。3.2 碰撞检测“差不多就行”会变成“差很多”蚂蚁搬豆子的核心交互就是碰撞判定AI第一版用的距离判断代码大概是if (Math.abs(ant.x - bean.x) 10 Math.abs(ant.y - bean.y) 10) { // 捡起豆子 }这个写法表面看着没问题实际玩起来有两个毛病。一是阈值给得太小蚂蚁走到豆子旁边经常擦肩而过触发不了搬运二是循环遍历豆子数组时如果两个豆子距离很近蚂蚁可能同时满足两个豆子的搬运条件一次捡起两颗分数异常增加。我的改法是碰撞判定增加蚂蚁到豆子中心距离小于蚂蚁半径加豆子半径同时给蚂蚁加一个携带状态标识已经在搬运状态的蚂蚁不再触发其他豆子的碰撞逻辑。另外用alive字段标记豆子是否已被拾取循环里跳过alive false的对象防止重复计数。这类问题指望AI一次写对不现实但给它一个明确的修复目标它处理得很干净。你能做的是告诉它当前碰撞存在重复触发请用距离半径加状态锁解决比你自己找出每处bug再教它改快得多。3.3 时序循环setInterval和requestAnimationFrame不能混着用这个坑属于没有游戏开发经验的人不太会注意的典型。AI第一版写移动用requestAnimationFrame写倒计时却用setInterval(1000)。问题是浏览器标签页切后台时定时器会降频甚至暂停等切回来的时候倒计时和蚂蚁动画就出现明显不同步——有时候蚂蚁在走倒计时不动有时候倒计时归零了蚂蚁还卡在搬运半路。修复核心思路就一个全游戏只保留一个requestAnimationFrame主循环倒计时、移动、碰撞检测全部在这个循环里基于时间戳计算。let lastTime 0; function gameLoop(timestamp) { const dt (timestamp - lastTime) / 1000; lastTime timestamp; // 倒计时累减、蚂蚁移动、碰撞检测全部用dt计算 requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);把setInterval从代码里整个删掉之后游戏节奏就稳定了。这个修复你可以在提示词里直接要求统一使用requestAnimationFrame作为唯一主循环不要使用setInterval或setTimeout驱动游戏逻辑能让AI绕开很多弯路。3.4 状态机比代码逻辑更怕的是逻辑自己打架一开始AI用三个布尔值管理蚂蚁状态isMoving、isCarrying、isBack。结果就是蚂蚁搬完豆子回到巢穴分数也加了但它站在原地愣住不动因为isBack为true的时候三个布尔值的组合没有覆盖到回巢后自动寻找新食物这条路径。后来我把蚂蚁行为统一成了状态机四个状态清清楚楚const State { IDLE: idle, // 空闲等待玩家点击 SEARCH: search, // 寻找食物 CARRY: carry, // 携带食物走回巢穴 BACK: back // 回到巢穴等待下一次指令 }每次进入新状态时重置目标状态切换只在固定的几个条件处触发。这样改完后蚂蚁行为变得非常可预测。你在提示词里直接写用状态机管理角色行为不要用多个布尔值互相组合AI大概率一开始就会给你更干净的结构。4. 纯AI开发不是一个人闷头聊我开着三个窗口搞多AI协作聊到这一步可能有人觉得纯AI开发就是一个人对着聊天窗口疯狂输出需求其实不是。我这次实际是开着三个AI对话窗口并行工作的它们各司其职一个写主代码一个做代码评审一个处理疑难报错。这种多AI协作模式比单窗口对话效率高不是一点半点。4.1 让第二个AI当“挑剔的代码评审”我拿到主AI生成的第一版代码后没有急着改而是把整份代码复制到第二个AI对话窗口告诉它请你以资深前端工程师的身份review 这份 HTMLCanvas 游戏代码。 重点检查 1. requestAnimationFrame 循环是否存在多循环或时间差未处理问题 2. 碰撞检测是否会导致重复计数或漏判定 3. 鼠标点击事件在移动端是否兼容 4. 是否所有固定坐标都适配了可变画布尺寸 5. 重新开始按钮是否能完全重置所有状态。 逐条给出问题和修改建议不要只说“整体不错”。结果非常有用。评审AI指出了三处我完全没注意到的问题一是豆子生成位置可能跟蚂蚁初始位置重叠开局瞬间蚂蚁自己把豆子捡了二是重新开始按钮只重置分数没重置豆子数组三是Canvas在全屏拉伸时没有处理设备像素比画面边缘发虚。这些问题单个看都不大但凑在一起足以毁掉第一版体验。4.2 分工的边界AI改完还是要人做最终裁决三个窗口的分工方式值得展开说一下。主窗口负责干活但不一定干得漂亮评审窗口负责挑刺但有些刺是误伤它会把合理范围内的设计当成bug第三个窗口专门用来粘贴报错信息因为报错排障的对话节奏和开发需求对话节奏完全不一样混在一个窗口容易让AI模型忘掉上下文。我还发现一个实用的技巧把评审AI的反馈原样复制给主AI时加一句只修改上面列出的问题不要重构其他部分。否则AI有时候会顺手把你写得没毛病的代码也重写了反而引入新bug。改完后你还是要自己读一遍关键逻辑至少要知道蚂蚁状态切换的触发点在哪。AI写代码的准确性在提升但好不好玩、手感顺不顺这种主观判断它替你做不了你才是最终验收的那个人。另外因为同时开了多个AI窗口版本管理变得更重要了。我在本地建了一个游戏项目目录按版本号命名文件每个文件顶部标注这个版本改了什么。这些标注都是我给AI下指令时的摘要比如v3修复碰撞重复计数蚂蚁加状态机回头出问题能一眼定位到是哪个改动引入的。5. 没有引擎怎么“上线”体积、兼容性和分享链接项目标题里说上线有人肯定会问没有引擎怎么发布其实我理解的上线就是把游戏变成一个任何人点开链接就能玩的成品。这一步走下来纯HTML方案的优势会被放大得很彻底。5.1 小体积才是纯HTML游戏的隐藏优势最终版《蚂蚁搬家》的HTML文件只有19KB里面写了蚂蚁绘制、食物生成、碰撞检测、倒计时、分数、重新开始、移动端适配。对这个体量的游戏来说加载时间约等于瞬间完成。如果你用Unity WebGL包装一个同样玩法的游戏哪怕各种裁剪优化WebGL加载体积通常也要1MB起步这还仅仅是引擎运行时没算游戏资源。对一个想靠好玩取胜的休闲小游戏来说首屏加载体验本身就是竞争力的一部分。纯HTML打包出来的游戏放进微信群聊、挂在文章里、做成二维码扫一下打开就是玩顺畅得像一个网页而不是一个小程序。5.2 手机能玩才算真的玩从click到触摸事件第一版代码的事件绑定是canvas.addEventListener(click, handleClick)PC上没问题我用手机浏览器打开后点半天没反应——这不只是触摸和鼠标的差别移动端浏览器对click事件有延迟和兼容性问题。修复方式是改用pointerdown事件这个事件同时兼容鼠标、触摸和触控笔是现在做跨端交互的首选。同时要在CSS里加一行touch-action: none防止手在画布上拖动时触发页面滚动或缩放。canvas.addEventListener(pointerdown, function (e) { const rect canvas.getBoundingClientRect(); const x e.clientX - rect.left; const y e.clientY - rect.top; // 基于坐标判断点击的对象 });这里有个隐藏坑用e.clientX计算坐标时必须减去canvas元素在页面中的偏移量rect.left和rect.top否则在页面滚动后点击坐标会全部错位。AI第一版没处理这个偏移PC端窗口最大化时恰好偏移为0所以没暴露手机上一滚就露馅了。5.3 发布前的验证清单我每次准备把版本分享出去之前会按下面的清单过一遍。这套清单也是我作为没有引擎兜底的开发者的自检流程双击打开就能玩不需要联网不需要额外安装任何东西浏览器F12控制台没有任何报错或警告改变浏览器窗口大小巢穴、食物、蚂蚁位置全部正常用手机浏览器打开触摸点击正常页面不会误滚动倒计时速度跟真实时间一致后台切换到前台后节奏不跳变重新开始按钮能完全重置分数、豆子、蚂蚁状态和倒计时反复快速点击蚂蚁不会出现状态错乱。第4、6两条最容易被忽略但它们直接决定了玩家会不会玩两秒就关掉。手机端不好用等于一半的潜在玩家直接流失重新开始不可用等于把游戏逼成了只能玩一局的单次体验。如果之后真想发布到微信、抖音这类小游戏平台纯HTML代码必然要做一次容器适配主要改渲染API和事件API平台方也有对应的开发者资质审核流程。我的建议是先用这种纯网页链接把玩法试出来确定有人爱玩再做容器适配投入这一步能帮你筛掉一大半不成熟的想法。6. 一键复现清单提示词模板、验收标准和下一步扩展前面聊了这么多原理和踩坑最后把这个项目沉淀成一套可以复现的方法论。你不需要复制我的《蚂蚁搬家》只要把这套结构和提示词模板拿过去换成你自己的玩法创意就能快速验证一个类似的小游戏想法。6.1 直接可用的提示词模板这是我从《蚂蚁搬家》项目里提炼的通用模板适用于大部分单场景休闲小游戏请开发一个名为“{游戏名}”的网页小游戏。 技术约束 - 单文件 HTML CSS JavaScript无外部依赖无外部图片 - 使用 Canvas 绘制游戏画面适配窗口大小变化 - 统一使用 requestAnimationFrame 作为唯一主循环移动距离按时间差计算不要使用 setInterval - 用状态机管理角色行为不要用多个布尔值组合状态。 玩法需求 - {一句话描述核心玩法} - {目标/胜负条件} - {玩家输入方式鼠标还是触摸} - {评分规则和时间限制} 界面要求 - 开始按钮、倒计时/计分、重新开始按钮 - 界面简洁能清晰看出游戏当前状态。 代码要求 - 加中文注释关键逻辑处说明作用 - 请先输出完整代码再单独列出这个玩法可能遇到的两个常见实现坑和对应修复方法。这个模板的核心价值在后半句再单独列出可能遇到的坑。AI在生成代码后主动给warning等于帮你预判了它自己可能犯的错误排查范围一下子缩小很多。6.2 五分钟验收清单拿到AI输出的代码后不用全读懂按下面顺序走一遍基本能判断靠不靠谱存成index.html双击打开看页面能否正常显示按F12打开Console看是否有错误先不动鼠标观察游戏画面有没有异常自动移动的对象玩一局完整的重点测开始、结束、重新开始这三个流程节点用手机打开同一份文件触摸一套操作调整浏览器窗口大小确认画面自适应正常。任何一步卡住了把现象描述加控制台报错截图一起丢回AI对话框让它修。核心排除法就是一次只抛一个问题给AI修完再进入下一个。6.3 下一步可以往哪里扩展《蚂蚁搬家》目前的版本只是一个基础垂直切片想继续深做后面有好几条路都值得走。加第二关可以引入随机掉落物蚂蚁被砸中会减速考验玩家的调度能力加排行榜可以用localStorage记录最高分变成每天玩一下的轻量粘性游戏加多只蚂蚁协作就能检验AI在多实体状态管理上的能力也更有蚂蚁搬家的场面感。从纯工具的角度看这次的实践让我最大的改观是AI小游戏开发已经过了能不能生成代码的阶段真正的门槛在于你能不能把需求拆到AI听得懂。同样的玩法我从一句做一个蚂蚁搬家游戏到成型用了大半天其中大部分时间不是花在AI想不出来而是花在它想出来之后我要怎么校准方向上。我最后想说的一个实际体会是纯AI开发小游戏最值钱的能力不是写代码而是验收和定位问题。你可以完全不会手写JavaScript但你必须要能描述清楚哪里不对、期望是什么、给的代码在哪个环节没达到预期。这个能力练出来之后AI会从玩具变成一个非常趁手的创作工具。下午写完这篇的时候我又去跟AI说要做一个猫抓老鼠版本这次从想法到可玩只花了四十分钟AI的下限在变高但会用它的人的思路才是真正的上限。 
长河君 · 2026/10/9 21:53:36 · 阅读 1.2k 纯AI开发网页小游戏：不用引擎，用HTML+Canvas从零做出一款可玩游戏
最近我做了一件说出去朋友都不太信的事用AI聊天窗口从零做了一款叫《蚂蚁搬家》的网页小游戏全程没打开过Unity、Godot安装包里连游戏引擎的影子都没有。就是跟AI反复对话让它写HTML、Canvas和JavaScript代码写出来一个能在浏览器里真实可玩的成品顺手把链接丢到群里大家玩完第一反应都是这真是AI写的这篇文章想聊清楚的东西有三层第一什么类型的游戏适合纯AI开发什么情况下你真的需要引擎第二我实际用AI开发《蚂蚁搬家》时从提示词到调试、踩坑的完整过程第三没有引擎的情况下这个小游戏是怎么做到上线可玩的。不管你是好奇AI写代码到底靠不靠谱的技术同学还是想低成本验证一个游戏想法、又不想一上来就啃引擎的独立创作者这一篇应该都能给你省下不少试错时间。1. 为什么敢不用游戏引擎先想清楚“蚂蚁搬家”需要什么很多人听到做游戏三个字第一反应就是Unity、Godot、Cocos好像不用引擎就做不了游戏。但《蚂蚁搬家》这种玩法本质上只需要三样东西一个循环刷新的画面、几个可以交互的对象、一套简单的碰撞判定。这三样东西原生HTML和Canvas完全能扛住游戏引擎在这里反而属于杀鸡用牛刀。1.1 这个玩法本质上只需要三样东西我拆解《蚂蚁搬家》的核心逻辑其实就几条画面中央偏右有个巢穴场地上散落着豆子玩家点击一只蚂蚁蚂蚁自动走向最近的豆子碰到之后把豆子搬回巢穴巢穴计数加一限时60秒内尽量多搬。听起来简单但它确实覆盖了游戏开发的基本要素游戏循环、输入响应、状态管理、碰撞检测、分数系统。这些在纯浏览器环境下怎么写游戏循环用requestAnimationFrameCanvas负责每帧重绘画面鼠标点击用事件监听蚂蚁和豆子的碰撞可以用距离判断分数和倒计时就是变量累加。全程只需要一个.html文件不需要导入任何外部资源不需要配置构建环境不需要维护任何依赖。AI在这种场景下特别能打因为它的训练数据里大量类似的Canvas小游戏demo你跟它说清楚需求它能在几十秒内给你端出一套能跑的原型。真实测试下来第一版代码从无到有只花了不到两轮对话。引擎能做什么引擎擅长的是资产导入、场景管理、复杂物理模拟、粒子特效、多人同步这些是《蚂蚁搬家》现阶段完全用不上的。你把引擎这一层重量压进来反而增加了理解成本、打包体积和调试复杂度。1.2 用引擎反而更别扭的三个地方诚实地讲我也试过用Unity做小游戏路径完全不同新建工程、导入Sprite、搭场景、挂脚本、调生命周期、打包WebGL这一套流程光是把环境跑通就能消耗掉你最初半小时的探索热情。而AI对某个具体版本引擎API的掌握程度反而不如它对原生JavaScript准确。我见过好几次AI把Unity旧版本API和当前版本API混在一起写报错之后连修都难修。第二个别扭的地方是打包体积。Unity WebGL哪怕是最简单的场景默认模板压缩之后也要几MB起步而《蚂蚁搬家》这种纯HTML游戏文件只有20KB上下加载速度天差地别。对一个休闲小游戏来说玩家点开链接恨不得一秒看到画面加载三秒钟已经算劝退。第三这类小游戏不需要美术资源管线。蚂蚁、豆子、巢穴全部用Canvas画出来就行AI甚至能给你画出会动的蚂蚁腿。你用引擎反而要先准备一套贴图纯HTML方案里这一步直接省了。如果哪天真要做到复杂物理、3D场景、大地图我第一个举手说该上引擎但不要为了用引擎而用引擎先看需求配不配得上那个重量级工具。2. 纯AI出代码的第一版提示词怎么给代码怎么验收纯AI开发不像你想的那样随口说一句帮我做个蚂蚁搬家小游戏就能拿到成品。我第一次这么试AI给了我一个画面很漂亮但点哪都没反应的静态页面。问题出在提示词太模糊它不知道你想要的玩法到底是什么。把需求说得越明确AI生成的第一版质量越高这个投入产出比非常惊人。2.1 我用的第一版提示词长这样下面这段是我的真实提示词你可以直接拿来改请帮我写一个网页小游戏“蚂蚁搬家” 1. 用 HTML Canvas 原生 JavaScript不要使用任何框架和外部库 2. 画面尺寸自适应浏览器窗口宽度不小于800像素 3. 游戏规则玩家用鼠标点击一只蚂蚁蚂蚁会自动寻找最近的食物黄色圆形豆子搬运回右侧的巢穴褐色半圆。每搬回一个豆子得10分限时60秒 4. 蚂蚁用红色小圆表示食物用黄色圆点表示场地内保持10颗豆子搬完自动补充 5. 要有开始按钮、倒计时、当前得分、重新开始按钮 6. 所有代码放在一个 html 文件中加中文注释逻辑清晰 7. 不要使用任何外部图片资源。为什么提示词这么啰嗦核心原因是AI的自由发挥是可控的但你要给它边界。限定技术栈它就不会给你引入一个你不知道的框架限定玩法和反馈方式它就不会做出一只起飞乱飞的蚂蚁限定UI要素它才知道你需要一个完整的游戏闭环。这套提示词结构我后来抽成模板了放在第六节你可以直接套用到任何休闲小游戏上。第一版生成出来的代码有280行左右保存成ant_game_v1.html双击在浏览器里打开能跑。能玩但问题也很明显窗口一缩小巢穴直接跑到屏幕外面去了蚂蚁走到豆子旁边豆子不消失倒计时有时快有时慢。这些就是后面的踩坑环节。2.2 第一次跑起来的正确姿势很多人拿到AI代码后习惯直接问对不对其实更好的做法是先自己跑一遍再看报错信息。我的习惯是拿到代码立刻存成文件浏览器打开按F12看Console面板。AI写代码也像一个手生的新人报错是常态但好消息是报错信息对AI而言就是最好的修正剂。我第一版第一次打开时白屏控制台报错Cannot read properties of undefined (reading getContext)原因是AI把画布初始化代码写在了一个还没加载完的节点前面。这种时候你不需要自己看懂代码直接把整段报错复制回AI对话框再加上一句请修复这个错误同时检查是否还有其他初始化顺序问题它很快就能改好。这里插一条关键心得修完一轮务必另存为ant_game_v2.html不要覆盖原文件。AI改代码有时候会改出新的问题保留每个版本文件你才有快速回滚的余地。我在这个项目里至少存了六个版本最后上线的是v5而v4在功能上其实比v5更完整只是多了一处小卡顿。有历史版本兜底心态会稳很多。3. AI最容易翻车的四个地方坐标、碰撞、时序、状态机既然敢说纯AI开发就不能只报喜不报忧。我这次踩的坑基本都集中在四个技术点上坐标写死、碰撞误判、循环时序混乱、状态机缺失。这四个坑不是《蚂蚁搬家》专属任何AI生成的Canvas小游戏都会遇到提前知道能省下大量循环纠错的时间。3.1 坐标写死把800x600塞进代码的所有角落AI的第一版代码里巢穴位置写的是{ x: 750, y: 550 }食物生成范围是x: 50到750蚂蚁初始位置{ x: 400, y: 300 }。这三个值全部是按800x600画布写死的一旦浏览器窗口不是这个比例巢穴可能跑到屏幕外或者食物生成区域只占画面一角。这其实是AI训练数据的老毛病——它看过太多固定尺寸的demo代码天然倾向于硬编码坐标。解决方式很简单在提示词或修复指令里明确写一句所有固定坐标改成相对于画布当前宽高的相对坐标然后再检查一遍有没有漏网的魔法数字。修复后的逻辑是巢穴位置等于canvas.width - 60, canvas.height - 50食物生成范围是20到canvas.width-20蚂蚁初始点在画布中心。这么一改窗口怎么拉游戏元素都待在应该在的位置上。这是纯AI开发里性价比最高的一次修复杂交AI改起来快你验收也直观。3.2 碰撞检测“差不多就行”会变成“差很多”蚂蚁搬豆子的核心交互就是碰撞判定AI第一版用的距离判断代码大概是if (Math.abs(ant.x - bean.x) 10 Math.abs(ant.y - bean.y) 10) { // 捡起豆子 }这个写法表面看着没问题实际玩起来有两个毛病。一是阈值给得太小蚂蚁走到豆子旁边经常擦肩而过触发不了搬运二是循环遍历豆子数组时如果两个豆子距离很近蚂蚁可能同时满足两个豆子的搬运条件一次捡起两颗分数异常增加。我的改法是碰撞判定增加蚂蚁到豆子中心距离小于蚂蚁半径加豆子半径同时给蚂蚁加一个携带状态标识已经在搬运状态的蚂蚁不再触发其他豆子的碰撞逻辑。另外用alive字段标记豆子是否已被拾取循环里跳过alive false的对象防止重复计数。这类问题指望AI一次写对不现实但给它一个明确的修复目标它处理得很干净。你能做的是告诉它当前碰撞存在重复触发请用距离半径加状态锁解决比你自己找出每处bug再教它改快得多。3.3 时序循环setInterval和requestAnimationFrame不能混着用这个坑属于没有游戏开发经验的人不太会注意的典型。AI第一版写移动用requestAnimationFrame写倒计时却用setInterval(1000)。问题是浏览器标签页切后台时定时器会降频甚至暂停等切回来的时候倒计时和蚂蚁动画就出现明显不同步——有时候蚂蚁在走倒计时不动有时候倒计时归零了蚂蚁还卡在搬运半路。修复核心思路就一个全游戏只保留一个requestAnimationFrame主循环倒计时、移动、碰撞检测全部在这个循环里基于时间戳计算。let lastTime 0; function gameLoop(timestamp) { const dt (timestamp - lastTime) / 1000; lastTime timestamp; // 倒计时累减、蚂蚁移动、碰撞检测全部用dt计算 requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);把setInterval从代码里整个删掉之后游戏节奏就稳定了。这个修复你可以在提示词里直接要求统一使用requestAnimationFrame作为唯一主循环不要使用setInterval或setTimeout驱动游戏逻辑能让AI绕开很多弯路。3.4 状态机比代码逻辑更怕的是逻辑自己打架一开始AI用三个布尔值管理蚂蚁状态isMoving、isCarrying、isBack。结果就是蚂蚁搬完豆子回到巢穴分数也加了但它站在原地愣住不动因为isBack为true的时候三个布尔值的组合没有覆盖到回巢后自动寻找新食物这条路径。后来我把蚂蚁行为统一成了状态机四个状态清清楚楚const State { IDLE: idle, // 空闲等待玩家点击 SEARCH: search, // 寻找食物 CARRY: carry, // 携带食物走回巢穴 BACK: back // 回到巢穴等待下一次指令 }每次进入新状态时重置目标状态切换只在固定的几个条件处触发。这样改完后蚂蚁行为变得非常可预测。你在提示词里直接写用状态机管理角色行为不要用多个布尔值互相组合AI大概率一开始就会给你更干净的结构。4. 纯AI开发不是一个人闷头聊我开着三个窗口搞多AI协作聊到这一步可能有人觉得纯AI开发就是一个人对着聊天窗口疯狂输出需求其实不是。我这次实际是开着三个AI对话窗口并行工作的它们各司其职一个写主代码一个做代码评审一个处理疑难报错。这种多AI协作模式比单窗口对话效率高不是一点半点。4.1 让第二个AI当“挑剔的代码评审”我拿到主AI生成的第一版代码后没有急着改而是把整份代码复制到第二个AI对话窗口告诉它请你以资深前端工程师的身份review 这份 HTMLCanvas 游戏代码。 重点检查 1. requestAnimationFrame 循环是否存在多循环或时间差未处理问题 2. 碰撞检测是否会导致重复计数或漏判定 3. 鼠标点击事件在移动端是否兼容 4. 是否所有固定坐标都适配了可变画布尺寸 5. 重新开始按钮是否能完全重置所有状态。 逐条给出问题和修改建议不要只说“整体不错”。结果非常有用。评审AI指出了三处我完全没注意到的问题一是豆子生成位置可能跟蚂蚁初始位置重叠开局瞬间蚂蚁自己把豆子捡了二是重新开始按钮只重置分数没重置豆子数组三是Canvas在全屏拉伸时没有处理设备像素比画面边缘发虚。这些问题单个看都不大但凑在一起足以毁掉第一版体验。4.2 分工的边界AI改完还是要人做最终裁决三个窗口的分工方式值得展开说一下。主窗口负责干活但不一定干得漂亮评审窗口负责挑刺但有些刺是误伤它会把合理范围内的设计当成bug第三个窗口专门用来粘贴报错信息因为报错排障的对话节奏和开发需求对话节奏完全不一样混在一个窗口容易让AI模型忘掉上下文。我还发现一个实用的技巧把评审AI的反馈原样复制给主AI时加一句只修改上面列出的问题不要重构其他部分。否则AI有时候会顺手把你写得没毛病的代码也重写了反而引入新bug。改完后你还是要自己读一遍关键逻辑至少要知道蚂蚁状态切换的触发点在哪。AI写代码的准确性在提升但好不好玩、手感顺不顺这种主观判断它替你做不了你才是最终验收的那个人。另外因为同时开了多个AI窗口版本管理变得更重要了。我在本地建了一个游戏项目目录按版本号命名文件每个文件顶部标注这个版本改了什么。这些标注都是我给AI下指令时的摘要比如v3修复碰撞重复计数蚂蚁加状态机回头出问题能一眼定位到是哪个改动引入的。5. 没有引擎怎么“上线”体积、兼容性和分享链接项目标题里说上线有人肯定会问没有引擎怎么发布其实我理解的上线就是把游戏变成一个任何人点开链接就能玩的成品。这一步走下来纯HTML方案的优势会被放大得很彻底。5.1 小体积才是纯HTML游戏的隐藏优势最终版《蚂蚁搬家》的HTML文件只有19KB里面写了蚂蚁绘制、食物生成、碰撞检测、倒计时、分数、重新开始、移动端适配。对这个体量的游戏来说加载时间约等于瞬间完成。如果你用Unity WebGL包装一个同样玩法的游戏哪怕各种裁剪优化WebGL加载体积通常也要1MB起步这还仅仅是引擎运行时没算游戏资源。对一个想靠好玩取胜的休闲小游戏来说首屏加载体验本身就是竞争力的一部分。纯HTML打包出来的游戏放进微信群聊、挂在文章里、做成二维码扫一下打开就是玩顺畅得像一个网页而不是一个小程序。5.2 手机能玩才算真的玩从click到触摸事件第一版代码的事件绑定是canvas.addEventListener(click, handleClick)PC上没问题我用手机浏览器打开后点半天没反应——这不只是触摸和鼠标的差别移动端浏览器对click事件有延迟和兼容性问题。修复方式是改用pointerdown事件这个事件同时兼容鼠标、触摸和触控笔是现在做跨端交互的首选。同时要在CSS里加一行touch-action: none防止手在画布上拖动时触发页面滚动或缩放。canvas.addEventListener(pointerdown, function (e) { const rect canvas.getBoundingClientRect(); const x e.clientX - rect.left; const y e.clientY - rect.top; // 基于坐标判断点击的对象 });这里有个隐藏坑用e.clientX计算坐标时必须减去canvas元素在页面中的偏移量rect.left和rect.top否则在页面滚动后点击坐标会全部错位。AI第一版没处理这个偏移PC端窗口最大化时恰好偏移为0所以没暴露手机上一滚就露馅了。5.3 发布前的验证清单我每次准备把版本分享出去之前会按下面的清单过一遍。这套清单也是我作为没有引擎兜底的开发者的自检流程双击打开就能玩不需要联网不需要额外安装任何东西浏览器F12控制台没有任何报错或警告改变浏览器窗口大小巢穴、食物、蚂蚁位置全部正常用手机浏览器打开触摸点击正常页面不会误滚动倒计时速度跟真实时间一致后台切换到前台后节奏不跳变重新开始按钮能完全重置分数、豆子、蚂蚁状态和倒计时反复快速点击蚂蚁不会出现状态错乱。第4、6两条最容易被忽略但它们直接决定了玩家会不会玩两秒就关掉。手机端不好用等于一半的潜在玩家直接流失重新开始不可用等于把游戏逼成了只能玩一局的单次体验。如果之后真想发布到微信、抖音这类小游戏平台纯HTML代码必然要做一次容器适配主要改渲染API和事件API平台方也有对应的开发者资质审核流程。我的建议是先用这种纯网页链接把玩法试出来确定有人爱玩再做容器适配投入这一步能帮你筛掉一大半不成熟的想法。6. 一键复现清单提示词模板、验收标准和下一步扩展前面聊了这么多原理和踩坑最后把这个项目沉淀成一套可以复现的方法论。你不需要复制我的《蚂蚁搬家》只要把这套结构和提示词模板拿过去换成你自己的玩法创意就能快速验证一个类似的小游戏想法。6.1 直接可用的提示词模板这是我从《蚂蚁搬家》项目里提炼的通用模板适用于大部分单场景休闲小游戏请开发一个名为“{游戏名}”的网页小游戏。 技术约束 - 单文件 HTML CSS JavaScript无外部依赖无外部图片 - 使用 Canvas 绘制游戏画面适配窗口大小变化 - 统一使用 requestAnimationFrame 作为唯一主循环移动距离按时间差计算不要使用 setInterval - 用状态机管理角色行为不要用多个布尔值组合状态。 玩法需求 - {一句话描述核心玩法} - {目标/胜负条件} - {玩家输入方式鼠标还是触摸} - {评分规则和时间限制} 界面要求 - 开始按钮、倒计时/计分、重新开始按钮 - 界面简洁能清晰看出游戏当前状态。 代码要求 - 加中文注释关键逻辑处说明作用 - 请先输出完整代码再单独列出这个玩法可能遇到的两个常见实现坑和对应修复方法。这个模板的核心价值在后半句再单独列出可能遇到的坑。AI在生成代码后主动给warning等于帮你预判了它自己可能犯的错误排查范围一下子缩小很多。6.2 五分钟验收清单拿到AI输出的代码后不用全读懂按下面顺序走一遍基本能判断靠不靠谱存成index.html双击打开看页面能否正常显示按F12打开Console看是否有错误先不动鼠标观察游戏画面有没有异常自动移动的对象玩一局完整的重点测开始、结束、重新开始这三个流程节点用手机打开同一份文件触摸一套操作调整浏览器窗口大小确认画面自适应正常。任何一步卡住了把现象描述加控制台报错截图一起丢回AI对话框让它修。核心排除法就是一次只抛一个问题给AI修完再进入下一个。6.3 下一步可以往哪里扩展《蚂蚁搬家》目前的版本只是一个基础垂直切片想继续深做后面有好几条路都值得走。加第二关可以引入随机掉落物蚂蚁被砸中会减速考验玩家的调度能力加排行榜可以用localStorage记录最高分变成每天玩一下的轻量粘性游戏加多只蚂蚁协作就能检验AI在多实体状态管理上的能力也更有蚂蚁搬家的场面感。从纯工具的角度看这次的实践让我最大的改观是AI小游戏开发已经过了能不能生成代码的阶段真正的门槛在于你能不能把需求拆到AI听得懂。同样的玩法我从一句做一个蚂蚁搬家游戏到成型用了大半天其中大部分时间不是花在AI想不出来而是花在它想出来之后我要怎么校准方向上。我最后想说的一个实际体会是纯AI开发小游戏最值钱的能力不是写代码而是验收和定位问题。你可以完全不会手写JavaScript但你必须要能描述清楚哪里不对、期望是什么、给的代码在哪个环节没达到预期。这个能力练出来之后AI会从玩具变成一个非常趁手的创作工具。下午写完这篇的时候我又去跟AI说要做一个猫抓老鼠版本这次从想法到可玩只花了四十分钟AI的下限在变高但会用它的人的思路才是真正的上限。