在 AI 编程工具大量出现之后做一个小游戏原型已经不是从零写类、调碰撞检测的事情了。用 CodeUI 这类以对话为核心的 AI 编码界面只需要把玩法描述清楚工具就能生成一个可以打开的前端页面。这里以一个 AI 割草游戏为例你可以在几分钟内得到一个可运行的 Canvas 游戏并且整个过程消耗的 token 费用可能只有两毛钱左右。这篇文章围绕生成、运行、验证、排查和成本控制展开适合想尝试 AI 编程但又不知道如何下手的前端初学者也适合想了解 AI 生成代码边界的前端工程师。割草游戏并不是真的“割草”而是借用了“怪物像草一样成片倒下”的玩法体验。玩家控制角色在地图里移动攻击范围内的敌人会被自动清除敌人不断从边缘生成玩家要在越来越密集的攻击中坚持更久。用 AI 辅助生成这样一个小游戏最大的好处是省去了从零搭页面、写主循环、调碰撞的重复劳动同时也能快速验证玩法的核心感觉。不过AI 不是项目保姆它擅长的是“把一个清晰任务变成代码”而不是“替你把一团乱麻的需求理清楚”。1. 先理解 CodeUI 的边界和割草游戏的最小技术形态1.1 CodeUI 是编码助手不是项目保姆CodeUI 是一个面向编码场景的 AI 工具界面核心交互方式是自然语言对话。你输入需求它会返回代码片段、解释或修改建议你可以针对某个文件继续追问也可以把报错信息贴进去让它协助定位。它可以把一个完整的单文件游戏生成出来但它并不理解你的部署环境、美术资源、后续维护计划。所以使用它的正确姿势是把它当作一个随叫随到的结对程序员而不是把整个项目托付给它。在实际项目中CodeUI 更擅长处理以下几类任务生成一个结构完整的单文件页面修改某个函数的行为比如攻击间隔、移动速度解释一段陌生代码的作用根据报错日志给出排查方向为已有代码补充注释或测试。它不擅长的任务包括在没有约束的情况下生成一个可扩展的大型游戏架构自动处理资源加载、跨浏览器兼容、安全防护理解你心中模糊的“好玩”或“流畅”代替你做出技术选型决策。因此做 AI 割草游戏前最好把需求拆成“第一版最小玩法”和“后续迭代”两个阶段。第一版只需要包含玩家移动、敌人移动、自动攻击、分数统计四个核心点。后续再逐步加入更丰富的敌人类型、音效、升级效果。1.2 割草游戏需要哪些核心技术点割草游戏本质上是“幸存者类”玩法玩家在一个有限地图上移动敌人不断增加玩家依靠自动攻击在高压下生存。最小技术组成可以用一张表说明模块作用实现方式游戏画布所有角色和特效的绘制区域HTML 的canvas元素玩家键盘控制位置自动攻击保存 x、y、速度、攻击范围敌人从边缘生成并朝玩家移动数组保存多个敌人对象逐帧更新坐标主循环持续更新状态和重绘画布requestAnimationFrame碰撞检测判断敌人是否攻击到玩家、子弹是否命中敌人判断两点距离小于半径之和计分与结束击杀增加分数碰撞后结束DOM 刷新分数弹出结束画面如果是零基础读者可能会把“碰撞检测”想得很神秘。其实在 2D 小游戏里最常用的是圆心距离判断两个圆形物体如果中心距离小于两者半径之和就认为发生了碰撞。这个方案实现简单也足够覆盖大多数小游戏场景。1.3 为什么用纯前端单文件实现用 CodeUI 生成割草游戏时推荐把目标设定为一个index.html文件CSS 和 JavaScript 都写在里面。这样做的原因很实际浏览器双击就能打开不需要安装 Node.js、配置 WebpackAI 一次对话就能输出完整文件避免了多文件之间的引用关系代码量小容易审查出现问题可以直接在控制台排查方便把 AI 生成的代码作为第一版原型后续再拆模块迁移到正式工程。学习阶段使用纯前端单文件没有问题。但如果目标是发布到线上让玩家稳定游玩就需要考虑模块化、资源压缩、异常监控、跨平台兼容等问题。这个差异在后面的章节会具体展开。2. 环境准备只需要浏览器和 CodeUI 工作区2.1 准备工具在开始生成代码之前先把需要用到的工具准备好。不要把时间浪费在“生成完发现没法运行”这种问题上。工具作用最低要求CodeUI 工作区与 AI 对话并获取代码能正常登录选择可用的编码模型现代浏览器运行 HTML 文件、查看控制台Chrome 或 Edge 最新稳定版本地目录保存生成的 HTML 文件一个普通文件夹即可可选的本地静态服务如果使用 file 协议遇到资源限制Python 或 Node.js 环境CodeUI 的入口可能在不同版本中有所不同常见的是 Web 端和桌面端。无论哪个版本核心能力都是通过对话生成代码。如果登录后看不到模型选择可以先使用工具默认模型不同模型的能力和计费有差异后续再根据需求调整。2.2 写出第一版需求描述很多人在第一次使用 AI 编程时只写一句话“帮我做一个割草游戏”。这句话信息量太少生成的代码大概率不符合预期。更好的方式是把需求拆成可执行的特征清单。下面是一个适合第一版生成的提示词示例请帮我生成一个完整的 HTML 文件包含 CSS 和 JavaScript实现一个 AI 割草游戏。要求 1. 使用 Canvas 画布游戏区域为 800x600。 2. 玩家用 WASD 移动是蓝色圆形。 3. 敌人是红色圆形从屏幕边缘随机生成并向玩家移动。 4. 玩家会自动攻击每 0.5 秒攻击一次攻击范围内所有敌人受到伤害。 5. 敌人血量 3 点被击中后闪烁血量为 0 时消失并加分。 6. 左上角显示击杀数。 7. 当玩家碰到敌人时游戏结束显示得分。 8. 代码保持在一个 index.html 文件中注释清楚。这段提示词为什么有效因为它把“游戏”拆成了视觉、输入、玩法、对象属性、结果反馈几个维度。CodeUI 不需要猜测“割草”到底是什么意思只需要照着约束生成代码。要注意这里没有写“AI 割草游戏”里的 AI 二字因为 AI 在这里指的是使用 AI 工具来制作而不是游戏里具备 AI 行为。如果想让敌人具备更智能的移动避障可以在后续迭代中补充描述。2.3 检查工具输出格式和运行方式CodeUI 可能返回一个完整的index.html也可能只返回某段 JavaScript。第一次使用时要先确认输出格式。如果把 AI 返回的内容保存为 HTML 文件后打开是空白页最常见的原因是内容不完整。判断方法很简单在文件里搜索!DOCTYPE html、canvas、script这几个标签。如果缺少任意一个说明 AI 可能只生成了代码片段需要继续追问让它补全为完整 HTML 文档。保存文件时要注意编码。Windows 记事本默认可能保存为带 BOM 的编码可能会导致脚本解析异常。建议使用 VS Code 等编辑器并将文件编码设为 UTF-8。HTML 的head里最好保留meta charsetUTF-8避免中文乱码。3. 跑通第一版生成、保存、运行、验证3.1 第一次生成后的保存步骤拿到 AI 输出后按以下步骤保存并运行复制 AI 输出的完整 HTML 内容。在本地创建一个新文件夹比如ai-mower-game。在文件夹里新建index.html把内容粘贴进去。保存后双击index.html用浏览器打开。如果浏览器没有正常显示按 F12 打开控制台查看报错。如果希望使用本地静态服务运行可以在项目目录中打开终端执行python -m http.server 8000然后访问http://localhost:8000。对于纯 Canvas 小游戏file://协议通常也可用但使用本地服务更接近生产环境也能避免某些浏览器对本地文件的限制。3.2 打开后应看到的画面第一版正常运行后浏览器中应该出现一个 800x600 的 Canvas 画布蓝色圆形代表玩家红色圆形代表敌人敌人随机从屏幕边缘出现并朝玩家移动玩家按 WASD 键移动玩家自动攻击范围内的敌人左上角显示击杀数玩家碰到敌人后游戏结束并显示得分。如果打开后画面不符合预期不要直接修改代码。先按 F12 打开控制台看有没有红色报错。AI 生成的代码即使整体思路正确也可能因为某个变量名不一致、某个方法拼写错误导致白屏。3.3 常见第一版失败现象现象可能原因处理方案页面完全空白HTML 不完整或 JavaScript 运行时报错打开控制台查看报错让 CodeUI 补全文件键盘操作无反应事件监听没有绑定到window或document检查keydown事件代码改用window.addEventListener(keydown, ...)敌人不生成生成逻辑写在初始化函数里但没有调用检查生成函数是否在gameLoop中定时执行攻击不生效攻击半径设置过小或攻击计时器逻辑混乱把攻击计时、范围判断打印到控制台中文乱码文件保存编码不是 UTF-8重新保存为 UTF-8并在 head 中加charsetUTF-8这一阶段的目标是让游戏“可玩”而不是“好玩”。只要玩家能移动、敌人能生成、攻击能击杀、碰撞能结束第一版就算跑通了。4. 关键代码拆解AI 割草游戏的核心机制AI 生成代码后不应该直接当作黑盒使用。就算不写代码的人也应该理解这几个核心机制否则后续迭代和排查都会很被动。这一节给出核心代码片段方便你在询问 CodeUI 时参考实际生成代码可能略有不同但思路是一致的。4.1 游戏主循环游戏本质上是一个不断刷新画面的循环。每次刷新时计算时间差值dt更新所有对象的位置然后重新绘制画面。let lastTime 0; function gameLoop(timestamp) { const dt (timestamp - lastTime) / 1000 || 0; lastTime timestamp; update(dt); render(); requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这里的dt是两帧之间的时间差单位为秒。游戏中的移动速度应该乘以dt这样无论浏览器帧率是 60 还是 30角色移动速度都不会明显变化。这是小游戏开发中一个非常重要的习惯。4.2 玩家移动与边界玩家对象通常包含x、y、speed、radius等属性。键盘状态可以用一个对象保存。const keys {}; window.addEventListener(keydown, e { keys[e.code] true; }); window.addEventListener(keyup, e { keys[e.code] false; }); function updatePlayer(dt) { let dx 0; let dy 0; if (keys[KeyW]) dy - 1; if (keys[KeyS]) dy 1; if (keys[KeyA]) dx - 1; if (keys[KeyD]) dx 1; if (dx ! 0 || dy ! 0) { const len Math.hypot(dx, dy); player.x (dx / len) * player.speed * dt; player.y (dy / len) * player.speed * dt; } player.x Math.max(player.radius, Math.min(800 - player.radius, player.x)); player.y Math.max(player.radius, Math.min(600 - player.radius, player.y)); }方向向量归一化的原因是如果同时按 W 和 D斜向移动速度不应该比单独按 W 更快。这个细节 AI 生成时不一定都会处理读代码时要注意检查。边界限制用Math.max和Math.min夹住坐标确保玩家不会跑出画布。4.3 自动攻击自动攻击不是每帧都产生伤害而是按照固定间隔触发。常见的实现方式是用一个计时器倒计时。let attackTimer 0; const attackInterval 0.5; const attackRange 150; function updateAttack(dt) { attackTimer - dt; if (attackTimer 0) return; attackTimer attackInterval; enemies.forEach(enemy { const dist Math.hypot(enemy.x - player.x, enemy.y - player.y); if (dist attackRange) { enemy.hp - 1; enemy.hitFlash 0.1; } }); }这段代码展示了“范围攻击”的核心遍历所有敌人计算每个敌人到玩家的距离距离小于攻击半径时扣血。用距离判断而不是矩形判断是因为圆形角色的攻击范围更自然。攻击间隔attackInterval可以放在玩家对象上方便后续做武器升级后的数值调整。4.4 敌人生成、移动与碰撞检测敌人对象需要有位置、速度、血量、半径属性。生成时可以从四个边缘随机取一个方向并给一个朝向玩家的初始速度。function spawnEnemy() { const side Math.floor(Math.random() * 4); let x, y; if (side 0) { x -20; y Math.random() * 600; } if (side 1) { x 820; y Math.random() * 600; } if (side 2) { x Math.random() * 800; y -20; } if (side 3) { x Math.random() * 800; y 620; } enemies.push({ x, y, speed: 60 Math.random() * 40, hp: 3, radius: 12, hitFlash: 0 }); }碰撞检测在update中完成。玩家碰到敌人后游戏结束let gameOver false; function checkCollision() { for (const enemy of enemies) { const dist Math.hypot(enemy.x - player.x, enemy.y - player.y); if (dist enemy.radius player.radius) { gameOver true; break; } } }注意这里判断的是“中心距离小于两个半径之和”而不是小于玩家半径否则敌人会嵌进玩家身体后才判定结束。两个圆形物体发生接触时中心距离一定小于等于半径之和。4.5 分数刷新与游戏结束分数通常维护在变量里每次击杀敌人时递增同时更新 DOM。let score 0; function updateScore() { score; document.getElementById(score).textContent 击杀: score; }游戏结束后停止主循环或设置gameOver标志然后在画布上绘制结束文字。if (gameOver) { ctx.fillStyle rgba(0, 0, 0, 0.6); ctx.fillRect(0, 0, 800, 600); ctx.fillStyle #fff; ctx.font 36px sans-serif; ctx.textAlign center; ctx.fillText(游戏结束得分: score, 400, 300); return; }这段代码把结束界面直接画在 Canvas 上省去了额外的 DOM 结构。对于原型来说够了后续如果要加“重新开始”按钮可以让 CodeUI 在结束画面中增加一个按钮和对应的事件处理。5. 用 CodeUI 做第二轮迭代从能玩到更好玩第一版跑通后会立刻感受到玩法上的单调。这时就是使用 CodeUI 做第二轮迭代的最佳时机。迭代的核心是“用自然语言描述问题并且只改一个点”。5.1 用自然语言描述问题如果觉得敌人类型太少可以这样对 CodeUI 说现在敌人太单调请增加两种敌人 1. 一种黄色圆形敌人速度慢血量为 6移动速度 30。 2. 一种青色圆形敌人速度快血量只有 1移动速度 120。 不要改变玩家移动和攻击逻辑。只需要修改敌人生成部分让三种敌人都能随机出现。这段提示词里最关键的不是“增加两种敌人”而是最后一句“不要改变玩家移动和攻击逻辑”。因为 AI 默认会尽量满足你的描述但有时它会顺手重构整个文件导致你之前调的参数被重置。每次迭代都明确限定修改范围能减少这类问题。5.2 迭代提示词的分寸迭代时一次只提一个核心需求。例如第一轮增加敌人类型。第二轮增加攻击特效。第三轮增加经验值和升级。第四轮增加音效。不要把“增加敌人类型、攻击特效、经验值、升级、音效、排行榜”一次性塞给 AI。需求太多时AI 生成的代码会变得难以审查任何一个逻辑出错你都不知道是哪个需求导致的。每个需求都单独验证一遍再进入下一个。如果要同时改三个参数可以直接明确写到提示词里把玩家的移动速度从 200 改为 250 把攻击间隔从 0.5 秒改为 0.4 秒 把攻击范围从 150 改为 180。这种数值型需求AI 通常能准确处理。改完之后要用浏览器实际验证手感不要只看代码。5.3 控制迭代成本AI 编程的“钱”主要体现在 token 消耗上。每次对话都会把之前的上下文一起发送给模型对话越长token 越多。成本控制的核心策略是不让上下文无限制膨胀。策略做法效果分阶段对话完成一个需求后新开一个对话再继续避免海量历史代码被反复计费限定修改范围明确说“只修改 xx 函数”减少 AI 重新生成无关代码合并小需求“把移动速度调到 250攻击间隔调到 0.4”减少请求次数使用更小模型如果工具支持简单场景用低参数模型单价更低响应更快及时结束原型完成就停止对话避免无意义的闲聊消耗标题里“只花了两毛钱”是一个成本参考。实际费用取决于模型定价、上下文长度和生成代码量。以单文件 HTML 小游戏为例输入提示词只占几十到几百 token输出代码几百行完整费用通常不高。使用前可以在 CodeUI 的用量页面查看具体消耗以实际计费为准。6. 运行验证和成本复盘6.1 功能验收清单无论 AI 生成代码多快最终都要靠人工验收。下面这个清单可以直接复制使用[ ] 页面打开后不报错无白屏[ ] WASD 可以控制玩家移动玩家不会移出画布[ ] 敌人从画布边缘随机生成并向玩家移动[ ] 玩家自动攻击范围内敌人血量减少[ ] 敌人血量归零后消失击杀数增加[ ] 玩家碰到敌人后显示结束画面和最终得分[ ] 刷新页面可以重新开始[ ] 浏览器控制台没有任何红色报错[ ] 游戏长时间运行不出现明显卡顿。前五项是功能验收后三项是稳定性和体验验收。第一版如果全部通过就可以进入迭代如果某一项失败先把这个问题修掉再继续。6.2 如何估算 token 和成本cost 估算在 AI 编程里是一个很实际的问题。尽管不同平台的计费方式不同但总可以按三步来估算在 CodeUI 的用量页面查看本次对话的输入 token 和输出 token。将输入 token 乘以模型输入单价输出 token 乘以输出单价。把总费用换算成人民币或美元。如果工具没有直接显示 token可以保守估计一个汉字大约 1 到 2 个 token一行代码大约 5 到 10 个 token。生成一个 300 行的 HTML 文件输出 token 通常在 2000 到 4000 之间。相比聊天场景编码场景的输出 token 更多但仍然属于小量级消耗。这里要强调一点不同模型、不同时段的定价可能变化不能把某个固定数字当成长期标准。更合理的做法是“小步快跑、及时复盘”每次迭代后记录 token 消耗和费用形成自己对成本的感知。6.3 学习环境和生产环境的差异用 CodeUI 做出来的单文件游戏适合学习、演示、原型验证。如果要部署给真实用户还需要考虑更多问题。项目学习环境生产环境代码组织单 HTML 文件模块化拆分按需加载资源加载本地相对路径CDN、OSS、资源指纹配置写死在代码里外置配置环境区分日志浏览器 console日志上报、错误监控性能小对象数量可使用数组遍历对象池、空间分区、帧率监控安全本地原型不用考虑输入校验、防作弊、防注入测试手动验玩单元测试、自动化浏览器测试如果你的目标只是体验 AI 生成代码的能力或者做一个课堂演示单文件原型完全够用。如果你想发布到线上建议把 Canvas 绘制逻辑和游戏逻辑拆成独立模块再补充测试和监控。7. 常见问题排查7.1 浏览器控制台报错AI 生成代码后出现报错非常正常。关键是学会看报错信息而不是直接让 AI 重写整个文件。Uncaught TypeError: Cannot read properties of null (reading getContext)这个报错说明获取 Canvas 上下文时canvas元素为 null。可能原因HTML 中canvas idgameCanvas没有写。JavaScript 在canvas出现之前就执行了。getElementById的 id 和 HTML 中的不一致。检查顺序先看 HTML 里有没有 canvas再看 script 标签的位置最后核对 id 名称。如果是执行顺序问题可以把script移到/body之前。7.2 动画卡顿游戏在敌人数量增多后变卡通常是每帧执行的逻辑过重。常见原因包括每帧创建新的对象导致垃圾回收频繁敌人数量无限增长没有清理机制每帧遍历大量敌人做高成本计算。解决办法敌人死亡后从数组移除而不是仍然保留在数组中限制最大敌人数量碰撞检测可以先按区域粗略过滤再精确计算如果使用粒子效果控制粒子池大小。先查看控制台的 Performance 面板确认卡顿是 CPU 还是内存问题再针对性优化。7.3 攻击不生效或敌人不消失如果玩家移动正常但敌人不扣血、不消失重点检查攻击逻辑攻击计时器是否在update中执行攻击范围是否设置得太小敌人血量是否是数字类型而不是字符串扣血后是否重新渲染了敌人。可以在代码中临时加入console.log(enemy.hp)来观察血量变化。如果一直没有扣血说明攻击范围判断或计时器没有触发。7.4 AI 生成代码与需求不符出现这种情况先不要急着怪 AI 能力不行。多数原因是需求描述不够具体。比如只写“增加攻击特效”AI 可能只是加了一个简单的圆形光效。如果你希望“攻击时出现剑光持续 0.2 秒后消失”就要把这个约束写清楚。现象可能原因检查方式处理方案保存后白屏生成的 HTML 不完整搜索 doctype、canvas、script让 AI 补全为完整文件中文乱码编码不是 UTF-8用编辑器查看编码保存为 UTF-8 并加 charset敌人数量暴涨生成间隔太短或未限制打印敌人数组长度增加生成间隔和最大数量攻击无效果攻击计时器未运行控制台输出 attackTimer检查 update 调用链碰撞不结束碰撞距离判断错误输出玩家与敌人距离改为半径之和判断排查顺序建议先确认输入是否正确再看文件路径和命名然后检查依赖和配置最后才看代码本身。对于 AI 生成的小游戏90% 的问题都出在“文件不完整”和“事件绑定缺失”上。8. 最佳实践把 CodeUI 当作结对程序员而不是自动生成器8.1 Prompt 写法清单与 CodeUI 对话时好的 prompt 应该具备五个要素角色、任务、约束、输入输出、异常处理。角色你是前端开发工程师。 任务生成一个 index.html 文件实现一个画布小游戏。 约束使用原生 JavaScript不依赖外部库不使用构建工具。 输入玩家按 WASD 移动。 输出左上角显示击杀数玩家被敌人碰到后结束。 异常敌人从边缘生成时不要超出画布边界。这条 prompt 比“帮我写一个游戏”好得多因为它让 AI 知道“做成什么样算完成”。如果你对某个功能有具体要求就在 prompt 中继续追加。比如“玩家不能移动到画布外”“攻击范围圆形可视化显示”“敌人死亡后掉落经验星”等。8.2 不要完全信任 AI 生成的代码AI 生成代码的速度快但不代表一定正确。每次生成后至少要阅读以下几部分主循环是否正常启动玩家坐标是否被正确更新敌人数组是否能被清理碰撞检测是否使用了合理的半径结束状态是否阻止了后续更新。一个实用做法是把“需求描述”和“验收清单”放在同一个文档里。AI 生成完代码后你按清单逐项测试。这样既不会漏掉功能也方便在下次迭代时回顾。此外不要直接在生产环境使用 AI 生成的关键逻辑。至少需要经过代码审查、单元测试和压力测试。AI 生成代码的价值是提高效率而不是降低代码质量标准。8.3 从割草游戏继续扩展的方向把这个最小割草游戏跑通后可以从以下方向继续练习增加武器升级系统击杀敌人获得经验经验可升级攻击范围、攻击间隔、移动速度增加多种敌人和 BOSS为不同类型敌人设计不同行为比如远程攻击、自爆、分裂增加技能选择每次升级时提供三个随机技能玩家选一个增加关卡设计限定存活时间时间到进入下一关增加音效和背景音乐用 Web Audio API 生成简单的合成音效增加移动端支持把 WASD 改成虚拟摇杆适配触屏事件。每扩展一个功能都按“新开对话、写清 prompt、单测验收”的流程走一遍。这样能积累出属于自己的 AI 编程工作流也能更清楚地知道每次迭代到底花掉了多少 token 和费用。如果你从没有用 AI 生成过完整游戏建议先把这个最小割草游戏跑通再逐步增加需求。AI 生成代码的价值不在于一次性交付而在于把无聊的样板代码省掉让你把注意力放在玩法的设计和验证上。下一步可以试着让 CodeUI 增加一个 BOSS 技能或者把你的角色改成碰撞体为矩形的模型。每改一次记录一下 prompt 和 token 消耗你会越来越清楚 AI 编程的边界在哪里。