企业官网建设流程全解析

最近我干了一件看起来有点“自找麻烦”的事：在完全没有使用任何游戏引擎的前提下，用纯AI把一款蚂蚁搬家小游戏从零写了出来。整个过程里，Unity、Godot、Cocos一个都没开，连游戏框架都没引，我靠的是一个AI编程Agent在浏览器里直接生成、调试、优化代码。标题里那句“游戏引擎都没用”说的就是这件事——不是哗众取宠，而是一个真实可复现的现代工作流：AI负责写码，我负责定义规则和验收。

这款小游戏的玩法很朴素：蚁巢里不断涌出工蚁，它们在地图上寻找食物，搬运回巢，玩家要在限定时间内完成搬运目标。真正吸引我的不是游戏本身，而是“不用引擎”这个约束条件。传统开发小游戏，引擎能提供渲染、物理、动画、资源管理一套全家桶，但如果用AI Agent直接生成，能不能靠HTML、JavaScript和Canvas把这些底层能力全部手搓出来？结果证明，可行性比我预想的高很多。这篇内容适合所有对AI编程、Web小游戏开发感兴趣的朋友，尤其是想试试“不装Unity，不碰Cocos，依然能做出一款能玩的小游戏”的人。

1. 项目缘起：为什么非要挑战“不用引擎”

1.1 被AI Agent勾起的念头

大概半年前，我开始尝试用AI Agent处理一些完整的小项目，而不是只让它写几个函数。最初是拿它写工具脚本、爬虫、数据处理，后来胆子大了，开始让它生成小游戏。有一次我和一个做独立游戏的朋友聊起，他说现在很多小游戏开发者其实是被引擎绑住的——要装SDK、配环境、管依赖，光是把Unity项目跑到手机上就要折腾半天。我就在想：如果AI能直接生成一个零依赖的浏览器游戏，那开发门槛会低到什么程度？

于是就有了这个蚂蚁搬家项目。定下的第一条规则就是：不用游戏引擎。连Phaser、PixiJS这类轻量2D框架也不用，所有逻辑都用原生JavaScript实现，渲染直接走Canvas。这相当于让AI在“裸机”状态下写游戏，反而能暴露出它到底理解多少游戏开发的底层逻辑。

1.2 三个硬性限制条件

为了不让项目失控，我给AI下了三个死命令：

第一个，所有代码必须能在浏览器里直接跑，不依赖本地编译。所以要选纯Web技术栈：HTML、CSS、JavaScript、Canvas。第二个，不能使用任何外部图片素材，蚂蚁、食物、巢穴全部用代码绘制。这样既省去版权问题，也确保AI生成的代码是自包含的。第三个，游戏逻辑要清晰到能拆成状态机，因为AI生成代码最怕的就是乱成一团，状态机既是给AI看的约束，也方便后续人类审查。

这三个限制看起来简单，实际上把项目的复杂度压到了一个“AI可以掌控”的范围。我见过很多人让AI写游戏，结果AI生成了几百KB的代码，里面逻辑互相穿插，改一个功能就崩一片。问题就出在需求太模糊，边界不清晰。限制条件越硬，AI越容易输出合格结果。

1.3 这个项目想验证什么

表面上这是一个小游戏，底层其实有三个验证目标。

第一，纯AI能不能独立完成一个完整项目。注意是“完整”，不是“能动的Demo”，而是包含开始界面、游戏循环、胜负判定、关卡递增、音效反馈的闭环。第二，AI生成了代码之后，人类通过自然语言能不能继续维护和迭代。比如我告诉AI“蚂蚁不要重叠”，它能不能准确改到碰撞逻辑上。第三，不用引擎的情况下，性能能做到什么程度。如果画面同时存在50只蚂蚁，Canvas能不能保持60帧。如果这三点都能成立，那么“AI直接做小游戏”就不再是玩具，而是可以应用到教学、H5营销、原型验证、甚至独立上架的正规开发路径。

2. 蚂蚁搬家小游戏的设计拆解

2.1 核心玩法与胜负条件

这款游戏的核心机制并不复杂：蚁巢是地图上的固定点，食物会随机刷新在远离巢穴的位置。工蚁从巢穴生成后，自动切换状态寻找食物，找到食物就扛起来往回走，把食物放进巢穴后积分增加。玩家不是全程挂机，每隔一段时间会刷新一只天敌蜘蛛，蜘蛛会捕食蚂蚁，玩家需要在蜘蛛靠近蚂蚁时点击屏幕释放“信息素”惊吓蜘蛛，让它暂时退避。

胜负条件也简单：每关限时60秒，目标是在时间内搬运指定数量的食物。比如第一关只需要搬回5个食物，第二关变成8个，后面逐步增加，同时蜘蛛刷新频率变高。这看起来简单，但对AI来说是个典型的状态机题目：每只蚂蚁在“找食物”“搬食物”“回巢”“休息”四种状态之间跳转，玩家点击事件还要能影响蜘蛛的行为，难度曲线还得平滑。这样的复杂度，正好适合验证AI的代码组织能力。

2.2 功能模块清单

在让AI动手之前，我把游戏分成了五个功能模块。

• 地图系统：负责场景边界、巢穴位置、食物刷新、蜘蛛生成。
• 蚂蚁系统：管理蚂蚁的生成、移动、状态切换、搬运和碰撞。
• 蜘蛛系统：天敌AI的追踪、惊吓、休眠、重生成。
• UI系统：开始画面、倒计时、积分、关卡进度、结束弹窗。
• 音效系统：用Web Audio API生成简单的搬运成功、惊吓蜘蛛、失败音效。

这个模块划分很重要。因为AI写代码时，如果需求描述里包含“模块”概念，它会更有意识地组织代码结构，而不是把所有功能平铺在一个巨大的update函数里。我在提示词里明确要求：每个模块对应一个JavaScript类或者一组独立函数，不允许出现全局变量满天飞的情况。

2.3 为什么选Canvas而不选DOM

很多人会问：蚂蚁这种几何图形小游戏，直接用DOM元素加CSS动画不就行了？为什么一定要Canvas？

原因有三点。第一，蚂蚁数量多。一个画面里轻松几十只蚂蚁，每只蚂蚁每秒要更新位置、方向、状态，如果用DOM元素，浏览器要处理几十个节点的样式变更，很容易卡。Canvas的绘制是一次性的，重绘整个画面反而更可控。第二，粒子效果和信息素标记用Canvas非常自然。比如我设计了一个“信息素波纹”效果，玩家点击后会有一圈圈扩散的视觉反馈，用Canvas的arc加透明度渐变可以写出很漂亮的代码，DOM很难实现。第三，AI生成Canvas代码的错误更容易定位。因为Canvas是命令式的，绘制顺序、坐标计算都是线性的，出了问题看控制台报错就知道画在哪一步。

当然，Canvas也有坑，比如高分屏适配必须处理DPR（设备像素比），还有热区点击需要手动换算坐标，这些后面第6章会细说。

2.4 美术与音效资源策略

既然不用引擎，外部的美术资源也一并不用。蚁巢我用一个半圆形土堆表示，上面画几个同心圆弧模拟洞口；蚂蚁用三个小球拼成身体，加上两根触角；食物用绿色叶子形状或简单的面包屑方块。这样处理是为了让AI能“画”出来，而不是依赖PNG图片加载。

其实纯代码绘制还有个隐藏优势：游戏体积极小。整个项目包含HTML、CSS、JavaScript的全部代码压缩后不到30KB，加载速度几乎瞬间完成。这在H5小游戏场景里很吃香，尤其微信小游戏或网页引流场景，用户点开就玩，根本不用等进度条。音效我用Web Audio API现场合成，搬运成功时播放一个“嘀”的短音，惊吓蜘蛛时播放低沉的“嗡”声，完全没有音频文件，又省一笔资源。

3. 纯AI开发的关键：提示词工程与多Agent协作

3.1 从一句话需求到功能分解

很多人让AI写游戏，输入的是“帮我写一个蚂蚁搬家小游戏”，AI确实能输出东西，但基本不可玩。原因是需求太模糊。AI不是人类，它不会主动追问玩法细节，更不会替你决策“碰到墙怎么办”“食物刷在哪里”。

我采用的做法是把一句话需求拆成功能列表，再塞给AI。比如我这样描述：

• 游戏Canvas尺寸为800x600，采用网格地图，网格大小为20像素。
• 巢穴位于画布左侧中心，初始有5只工蚁。
• 食物每5秒在地图右侧随机位置刷新一次，最多同时存在10个。
• 工蚁速度设为120像素/秒，搬运食物后速度降到80像素/秒。
• 蜘蛛每20秒生成一只，朝向蚁群方向移动，碰到蚂蚁后蚂蚁消失，蜘蛛消失。
• 玩家点击画布会生成持续4秒的信息素区域，蜘蛛碰到信息素会反向逃离。

这些参数不是随便写的。每个数值背后都有玩法考量：速度差形成一个搬运节奏，20秒蜘蛛生成周期给玩家中间留出喘息空间，食物刷新5秒保证地图不空。当AI拿到这样的细致描述，它输出的代码质量完全不一样。

3.2 我使用的提示词模板

这次项目的提示词，我会共享一个可复用的模板。整体分为背景约束、功能清单、技术规范和交付格式四段。

你是一名资深Web游戏开发者。请使用纯HTML+CSS+JavaScript+Canvas开发一款蚂蚁搬家小游戏。要求： 1. 不使用任何游戏引擎、框架或外部库。 2. 不使用外部图片和音频资源，所有视觉元素用Canvas绘制，音效用Web Audio合成。 3. 实现以下功能列表：蚂蚁状态机、食物随机刷新、蜘蛛天敌、点击信息素、关卡倒计时、开始与结束界面。 4. 代码结构要求：使用ES6Class组织逻辑，Canvas渲染与游戏逻辑分离。 5. 输出一个完整的HTML文件，包含全部内联CSS和JavaScript，可直接在浏览器打开运行。 6. 关键变量请添加中文注释。

为什么强调“输出一个完整的HTML文件”？因为很多AI工具默认会给你拆成多个文件，但对小游戏来说，单文件交付最简单。打开即玩，也方便部署。添加中文注释则是为后续维护做准备，毕竟我自己也要读代码，AI生成代码后如果全是英文变量名，排查问题会很吃力。

3.3 多AI协作：让三个Agent各司其职

现在流行讲AI Agent，但大部分人说“多智能体协作”时都停留在概念。这次项目我确实用了三个不同角色的Agent，流程是固定的：

• Agent A负责编码，拿到上面的需求模板，输出初始版本。
• Agent B负责代码审查，我会把Agent A生成的代码粘贴给Agent B，让它模拟“严格的技术主管”角色，只挑毛病，比如内存泄漏、性能瓶颈、边界条件。
• Agent C负责测试，它不看我描述，而是直接读代码，然后列出至少5个测试场景，并预测每个场景下游戏会如何表现。

实际操作下来，这个流程非常有用。Agent A生成的初版基本都有bug，但Agent B能快速提示“蚂蚁在碰撞检测时每次都要遍历所有蚂蚁，O(n^2)会导致卡顿”或者“canvas里坐标转换没有乘devicePixelRatio，高分屏会偏移”。Agent C更夸张，它直接把我的玩法反推出来，并提出“如果食物刷在画布边缘，蚂蚁可能过不去”“限时结束时食物刚好在路上，积分如何处理”这类边界问题。

这种协作方式，本质上是用AI之间的多轮反馈代替传统的代码评审。我不需要自己逐行读所有代码，只需要判断那些意见是否合理，如果不合理就让它们进一步论证。在这个流程下，原本需要一两天手搓的游戏，大概一个下午就达到可以公开玩的状态。

3.4 AI生成代码之后，人类的验收检查单

AI把代码交付之后，不能直接上线，我总结了一份验收检查单，每一条都有明确目的：

1. 是否满足单文件要求。打开HTML文件，地址栏前缀是file://，确认没有去请求外部资源。
2. 游戏主循环是否存在。搜索requestAnimationFrame，确认它被正确调用了，并且有deltaTime参数。
3. 状态机是否清晰。搜索蚂蚁类里的state字段，确认它只在有限几个值之间切换。
4. 是否避免全局污染。所有类、函数都应该包裹在一个立即执行函数或模块作用域里。
5. 高分屏适配。确认Canvas画布的实际尺寸乘以devicePixelRatio，CSS尺寸保持清晰。

这份检查单既是AI自检的指导，也是我作为开发者最后的防线。毕竟AI再强，最终上线出问题的是我自己的项目。

4. 核心实现解析：蚂蚁搬家的代码逻辑

4.1 整体文件结构与入口

因为要求单文件，整个项目结构实际上是把样式、脚本、HTML骨架组合在一起。核心JavaScript代码大概分为三块：游戏配置对象、蚂蚁类和蜘蛛类、主循环与碰撞系统。

先看配置对象。所有可调参数集中在一个常量对象里，方便调数值平衡：

const CONFIG = { canvasWidth: 800, canvasHeight: 600, gridSize: 20, antSpeed: 120, antCarrySpeed: 80, spiderSpeed: 100, foodRefreshTime: 5000, spiderSpawnTime: 20000, levelDuration: 60, targetScore: [5, 8, 12, 18], };

入口处只需要拿到canvas的2D上下文，然后启动一个主循环。

const canvas = document.getElementById('gameCanvas'); const ctx = canvas.getContext('2d'); let lastTime = performance.now(); function loop(now) { const dt = (now - lastTime) / 1000; lastTime = now; update(dt); render(); requestAnimationFrame(loop); } requestAnimationFrame(loop);

这里的关键点是dt（增量时间），如果直接用帧率差异来算速度，刷新率不同的设备上蚂蚁移动速度会完全不一样。使用dt之后，不管显示器是60Hz还是120Hz，蚂蚁都能保持每秒固定的像素移动距离。

4.2 蚂蚁状态机与移动逻辑

蚂蚁是游戏的核心，我把状态机设计成四个值：SEEK、CARRY、RETURN、REST。

• SEEK：蚂蚁在地图上随机游走，同时检查附近是否有食物。
• CARRY：蚂蚁找到食物，头顶变绿，携带食物返回巢穴。
• RETURN：蚂蚁朝向巢穴移动，到巢穴边缘后放下食物，积分加一，然后进入REST。
• REST：蚂蚁短暂停顿，再回到SEEK。

代码核心是update方法：

class Ant { constructor(x, y) { this.x = x; this.y = y; this.state = 'SEEK'; this.target = null; this.angle = Math.random() * Math.PI * 2; this.speed = CONFIG.antSpeed; } update(dt) { if (this.state === 'SEEK') { this.seekFood(dt); } else if (this.state === 'CARRY' || this.state === 'RETURN') { this.moveTowardNest(dt); } else if (this.state === 'REST') { this.restTimer -= dt; if (this.restTimer <= 0) this.state = 'SEEK'; } } }

移动逻辑其实不复杂。找食物阶段，我先让蚂蚁做随机偏转，这样能覆盖更多地图区域。一旦视野范围内检测到食物，就切换到朝向食物的方向。由于地图上障碍物很少，没有做路径寻路，而是直接用向量归一化后乘以速度。这也算是对“不用引擎”的妥协，毕竟真实蚂蚁也不是靠A*算法找路的，它们靠信息素和随机探索。

4.3 食物搬运与巢穴积分的实现

食物类要处理“是否已被搬起”的状态，否则会出现多个蚂蚁同时“吸”同一个食物的情况。解决办法是给食物加一个carriedBy属性，初始值为null。当蚂蚁靠近食物时，检查这个属性，如果为空，则设置为当前蚂蚁，蚂蚁进入CARRY状态；如果不为空，则继续寻找下一个食物。

搬运回家之后，巢穴积分的计算放在蚂蚁的RETURN状态里。我会在巢穴半径范围内做碰撞检测：

const nestX = CONFIG.nest.x; const nestY = CONFIG.nest.y; const dist = Math.hypot(this.x - nestX, this.y - nestY); if (dist < CONFIG.nestRadius) { score += 1; this.target = null; this.state = 'REST'; this.restTimer = 0.5; spawnLeafParticle(nestX, nestY); }

这里有个细节：积分只能加一次。蚂蚁不能来回搬运同一个食物，所以到达巢穴后把食物对象从舞台上移除，或者标记为collected。否则食物还留在蚂蚁身上再搬出去，逻辑就乱了。

4.4 蜘蛛天敌和信息素互动

蜘蛛AI相对简单。生成时设置一个固定位置，然后朝整个蚁群的质心移动。实现方式是把所有蚂蚁的位置求一个平均值，作为蜘蛛的当前目标。这样蜘蛛会看起来像在追蚂蚁，但不会精准锁定某一只要咬死，而是追踪群体，更符合真实捕食行为。

信息素玩法是玩家点击屏幕触发的。点击时生成一个圈，持续数秒，蜘蛛碰到信息素范围就反转方向。为了让“遇到信息素掉头”这个动作不僵硬，我给蜘蛛添加了一个冷却时间。第一次碰到信息素后，蜘蛛在2秒内不会再被同类信息素影响，避免它在圈里反复横跳。

这个交互让游戏从纯挂机变成了有操作感的小游戏。玩家要判断蜘蛛来袭的路线，提前在它的行进方向上释放信息素。AI生成这部分逻辑时，还算准确地理解了“反转方向”是“让蜘蛛临时转向NPC的固定路径”，而不是“调整移动角度到一个随机值”。

4.5 性能优化：让50只蚂蚁稳定60帧

第一版代码运行后，我发现蚂蚁数量到25只左右帧率就掉到30帧以下。排查之后发现两个问题。第一，每一帧都绘制所有食物、蚂蚁、蜘蛛的图形时，绘制次数太多，而且蚂蚁的小球使用了shadowBlur发光效果，这是Canvas的性能杀手。第二，碰撞检测是O(n^2)的，蚂蚁与蚂蚁之间也做了碰撞检测，但当时其实根本不需要，蚂蚁之间直接穿透就好，不影响玩法。

优化手段有三个：

1. 去掉所有shadowBlur和阴影，改用径向渐变模拟光影效果，性能提升巨大。
2. 碰撞检测只做蚂蚁对食物、蚂蚁对巢穴、蜘蛛对蚂蚁这三组，不做蚂蚁对蚂蚁。
3. 当画布外还有食物时，不绘制食物对象，直接跳过。

优化之后，哪怕蚂蚁数量增加到60只，在普通笔记本上也能保持55帧以上。值得一提的是，AI在做第五轮优化时主动提出了对象池方案，我没有干预。它建议把消失的蜘蛛和蚂蚁实例缓存起来，而不是反复new对象。这个方案确实减少了GC压力，代码也更规整。

5. 实操实录：从AI生成到上线的完整过程

5.1 第一版AI速写：印象与问题

我带着需求模板直接开始，Agent A大概几十秒就产出了一份完整的HTML文件。打开浏览器那一瞬间，画面是真的出来了：蚂蚁在爬，食物在刷，倒计时在走。虽然很粗糙，但整体框架已经成立。

不过问题也很明显。蚂蚁的行动方向非常随机，经常绕着食物转圈却拿不到。原因很简单，食物检测范围太小，而蚂蚁的随机转角又太大，导致它在食物旁边不断晃过。另外，蜘蛛生成后，因为目标指向整个蚁群的质心，而蚁群分布很散，导致蜘蛛会在几个位置之间抽搐，看起来很不自然。

这些都在预期之内。我把日志收集好，然后开始下一轮修复。

5.2 让AI自己修Bug：一次对话式迭代

我把第一版代码和问题描述一起发给Agent A，让它修复。这里特别注意：描述bug要精确到“现象+发生条件+期望效果”。我会这样写：

“蚂蚁在食物半径30像素内仍然会绕过食物，原因是检测到食物后未将目标点锁定，而是继续随机游走。请修复为：当蚂蚁进入食物检测范围后，直接锁定该食物位置为临时目标，不再随机转向，直到碰撞或目标被其他蚂蚁拾取。”

AI收到这个描述后，几秒钟就给出了补丁代码，它把寻路部分改为“靠近目标后持续逼近”，并且加了overlap检测。这次修完，试玩体验立刻不同，蚂蚁搬运成功率肉眼可见地提升了。这个过程中我其实没有写过一行代码，我只做了问题定位、描述和验收。

5.3 平衡性调优：从“手滑”到“顺畅”

游戏平衡是最需要人类直觉的部分。AI参数调优很多时候会把数值推向极端，比如它把食物刷新时间从5秒改成了2秒，认为这样玩家容易过关，实际玩起来反而手忙脚乱。

我自己的调参记录如下：

• 蚂蚁数量初始从3只改到5只，因为3只时搬运速度太慢，前30秒几乎攒不到分。
• 蜘蛛生成间隔从20秒改到15秒，第二关开始可以接受更频繁的打扰。
• 搬运减速从reduce20%改到33%，即搬运时速度变成原来的三分之二，给玩家留出操作反应时间。
• 每关目标从固定值改成递增曲线：5、8、12、18。

数值调整后，我连续测了20轮。最直观的感受是，第一关60秒内刚好能完成目标，差一点点就失败，这种临界体验是最抓人的。如果你做完一个小游戏，发现玩家轻松通关或者完全过不去，说明数值设计有问题，要往临界体验去校准。

5.4 部署上线：压缩成单文件并托管

本地好跑还不够，上线才能拿给别人玩。我把AI生成的代码交给一个压缩步骤，去掉注释和多余空格，单文件从40KB压缩到25KB左右。然后部署到静态托管平台，用的是GitHub Pages。因为整个过程不需要后端，静态托管就够了，访问路径就是一个HTML文件，加载速度几乎无感。

上线后我在手机上测了一下，遇到两个新问题。第一个是点击事件坐标偏移，因为Canvas在高分屏上做了DPR缩放，但监听click的鼠标坐标没有换算。第二个是部分手机的默认字体渲染导致游戏结束弹窗文字换行，这个通过设置固定宽度和字体大小解决。

记得明确一点：无论AI生成还是人手写，上线前的跨设备适配必须自己人工过一遍。AI能生成代码，但它不能替你搞清手机型号差异。我一般会用浏览器开发者工具模拟几款主流机型，再真机实测一轮。

5.5 实测数据与体验总结

上线后的数据很朴素：加载耗时平均约0.8秒，首屏渲染完成时间在2秒内，60秒一局的游戏在中等手机上流畅运行。这个体验已经接近很多H5休闲游戏的门槛。如果放到微信小游戏或者Web小游戏平台上，这种体积和性能都有优势。

当然，纯粹的“AI生成”项目不能省略人类的质量把控。我的体会是：你可以让AI完成80%的机械编码和调试，但剩下20%的玩法打磨、视觉风格统一、跨端兼容，仍然需要人来拍板。AI像一个执行力极强但不理解“好玩”的实习生，你得告诉它方向，它才能跑对路线。

6. 常见问题与避坑指南

6.1 AI生成的代码是不是直接能用

很多人以为AI生成完就能直接上线，这是最大的误区。初版代码大概率有肉眼可见的问题，比如变量名拼写错误、某个函数未定义、循环导致的无限卡死。即使代码能跑，逻辑也可能不符合预期。

我的习惯是：让AI先自检，再让另一个Agent做代码审查，最后自己打开浏览器在控制台里盯报错。每次迭代都记录修改点，避免AI修一个新bug却引入三个旧bug。实际上在项目开发中，有一轮AI为了增加游戏难度，直接给蚂蚁添加了随机瞬移，完全偏离了需求，我一眼就看出来不对劲，于是把它驳回了。

6.2 Canvas坐标系统总是搞混怎么办

Canvas坐标系统是各类bug的高发区。常见问题是绘制坐标用了逻辑坐标，但事件坐标是CSS像素坐标，二者在高分屏下差一个devicePixelRatio的倍数。

解决方式很标准。拿到canvas后先设置一块固定逻辑尺寸的缓冲区，然后将canvas的实际宽度乘以devicePixelRatio，再通过ctx.scale(dpr, dpr)统一缩放坐标系统。这样后续所有绘制逻辑都能在一个固定的800x600坐标系里进行，不需要每处都除以dpr。

function setupCanvas() { const dpr = window.devicePixelRatio || 1; canvas.width = CONFIG.canvasWidth * dpr; canvas.height = CONFIG.canvasHeight * dpr; canvas.style.width = CONFIG.canvasWidth + 'px'; canvas.style.height = CONFIG.canvasHeight + 'px'; ctx.scale(dpr, dpr); }

设置完之后，监听click时拿到的clientX和clientY需要减掉canvas的getBoundingClientRect().left和top，然后得到的就是逻辑坐标。这个换算必须在事件处理里做，不能偷懒。

6.3 蚂蚁一多就卡怎么排查

先别急着优化代码，先看浏览器性能面板是哪个函数的耗时最高。如果是render函数，优先检查是否每帧做了大量Canvas状态切换，比如频繁设置fillStyle、shadowBlur、globalAlpha。如果是update函数，去统计是否做了不必要的碰撞检测。

我遇到过最典型的卡顿是蚂蚁在寻找食物时，每一帧都会调用数组的indexOf方法查找目标食物是否还在数组里。这个操作看起来小，但蚂蚁数量一多，数组又频繁增删元素，就会变成性能瓶颈。解决办法是把食物的存活状态用一个alive属性标记，而不是从数组里splice删除。这样查找时直接判断alive即可，几乎零成本。

6.4 浏览器兼容性：别让iOS Safari背锅

同一段Canvas代码在Chrome正常，在iOS Safari却可能出现字体忽大忽小、点击无响应、音频无声的情况。尤其是Web Audio API，在iOS上必须由用户主动触发的操作来解锁音频上下文，否则不会播放。

我的处理方式是页面首次点击时创建一个AudioContext实例并resume，确保后面的合成音效可以使用。同时点击事件要同时监听click和touchstart，否则iPhone上可能会有300毫秒的延迟感。

此外，Canvas在Safari里如果用fillText绘制的文字，字体加载时机可能不同，导致画面内文字短暂消失。解决方法是让AI用pt单位设置字体，或者把关键文字也绘制在Canvas上并等待页面onload完成后才开始游戏。

6.5 提示词被AI理解偏了怎么办

AI出现“理解偏”不是因为它笨，而是因为它缺乏上下文。比如我最初写“蜘蛛会捕食蚂蚁”，AI竟然把蜘蛛和蚂蚁做成了同阵营，蜘蛛只在地图上来回走，从不攻击蚂蚁。原因是我没有定义“捕食”的具体逻辑。

再比如“信息素惊吓蜘蛛”，AI实现成蜘蛛在检测到信息素时会开一个定时器，2秒后直接回到初始位置，这其实更像瞬移。我后来明确要求“蜘蛛碰到信息素圈，立刻把移动目标变为反向方向，持续3秒，期间不可再次受影响”，这个描述一出来，AI的修改就完全对了。

所以提示词工程的核心是：把你知道的领域知识尽量转化为可操作的逻辑，而不是让AI去替你猜。你越是明确“什么时候、做什么、持续多久、结果是什么”，AI的表现越接近一个靠谱的程序员。

写在最后的小技巧

如果你也想复现这个项目，我最建议的切入方式是：先不要追求完整，而是用AI生成一个“蚂蚁从巢穴出发、随机走到食物点、搬食物回巢”的最小闭环。只有这个闭环跑通了，再逐渐添加蜘蛛、信息素、关卡、音效。因为小游戏开发的复杂度是累积的，一个功能出错往往会影响另一个功能的表现，先用最小闭环建立信心，后面都是增量迭代。

我个人在实际操作中还有一个体会：AI写游戏代码的时候，你当那个“产品经理”比当“程序员”更重要。它写出来的代码细节你未必能逐行看懂，但你完全可以通过定义玩法、提bug、做验收来把控整个项目走向。这个模式放到几年前是想都不敢想的，现在确实变成了现实。希望这篇内容能给你一个参考，让你知道“不用游戏引擎，纯靠AI做小游戏”不是噱头，而是一条可以复制的工作流。