异步任务的最小实现
2026/8/28 13:03:30
如果几年前有人说，一个没写过游戏的人可以在一周内做出一款能在浏览器里反复玩的 2D 小游戏，我大概率不会信。但这次我用 AI 辅助完成了一次完整的游戏开发旅程：从玩法设想、代码生成、报错修复到发布预览，整个过程既比预想中顺利，也比预想中更容易翻车。
AI 辅助游戏开发并不是“让 AI 替你把游戏写完”这么简单。真正的难点在于：如何把想法拆成 AI 能执行的提示词，如何判断生成代码是否正确，如何在报错时把信息喂回给 AI，以及如何在 Demo 已经能玩之后继续补齐手感、音效、存档和发布流程。这篇记录就是围绕这条主线展开的：先讲 AI 能在游戏开发里介入到什么程度，再给出一套可以照着做的工具链和项目基线，然后从一个无依赖的 Canvas 小游戏出发，演示完整的生成、验证、排错和发布过程。
如果你正在尝试用 AI 做游戏开发，或者想把手头只会“聊天”的 AI 用成真正的编码帮手，下面这套方法可以直接复用。它的前提不是你会写复杂的引擎代码，而是你愿意把需求描述清楚、把错误日志贴完整、把每一步验证做扎实。
1. AI 进入游戏开发后，最先改变的是“从想法到原型”这一段
1.1 游戏开发里 AI 真正能接手的四个环节
传统游戏开发的链条很长：策划写玩法文档，程序写逻辑，美术画素材，音频做音效，测试反复试玩。个人开发者不可能把所有环节都做精，这也是很多人想做游戏但始终停在一堆草稿纸上的原因。
AI 真正改变的是把“想法验证成本”降下来了。在个人小规模项目里，最值得 AI 接手的环节是代码生成、占位素材、玩法文案和报错分析。下面这张表可以帮你看清哪些环节适合第一时间交给 AI，哪些环节仍然需要你自己把关。
| 环节 | 传统做法 | AI 辅助做法 | 适合交给 AI 的程度 |
|---|---|---|---|
| 游戏逻辑代码 | 手写角色移动、碰撞、计分、状态机 | 给模型描述玩法，让它生成核心逻辑片段 | 高，尤其适合原型 |
| 占位美术 | 找免费素材或找画师 | 用 AI 生成占位图，或用 Canvas 画简单几何体代替 | 中，占位阶段完全可用 |
| 文案与剧情 | 写角色对话、任务描述 | 让 AI 生成对话树、物品描述、关卡说明 | 高，但需要人工校准风格 |
| 报错与调试 | 搜索报错、阅读文档、打断点 | 把错误日志贴给 AI，让它给出排查方向和修复片段 | 高，但结论必须人工复核 |
这里的关键判断是：AI 在“单点任务”上很强，在“完整系统”上很弱。让它生成一个碰撞函数、一段随机掉落逻辑、一个商品描述，它通常能做得不错；让它一次性输出一个包含存档、关卡、音效、UI 的大型游戏，它大概率会给你一堆看着完整但跑不起来的代码。
1.2 为什么“AI 生成代码”不等于“不用懂代码”
很多初学者会把 AI 编程理解成“我不需要学习编程了”。这个理解在游戏开发里尤其危险。游戏代码的特点是强状态、强时序、强交互：玩家按了键，角色要移动；物品掉到特定区域，要触发碰撞；分数变了，界面要刷新。任何一个环节出错，游戏可能整个卡死。
AI 生成代码时并不真正理解“这个游戏好玩在哪里”。它只是根据语料和你的提示词，按照统计规律拼接出看起来合理的代码。它可能用错 API，可能忽略边界情况，可能把碰撞判定写反。这时候你需要具备的最基本能力不是写代码，而是读代码、做验证、贴报错。
所以我更愿意把 AI 编程定位成“放大你能力上限的工具”，而不是“替代你思考的引擎”。你能把需求描述得越清楚，你能读懂生成结果的大致结构，你能在出问题时给出有效错误信息，AI 能帮你做的事情就越多。
1.3 这套流程适合谁，以及读完你能得到什么
这篇文章适合三类读者：第一，完全没写过游戏但想把玩法原型做出来的想法型开发者；第二，会写一些代码、想用 AI 减少重复劳动的 Web 前端开发者；第三，正在评估“AI 能否进游戏制作流程”的团队技术负责人。
按下面的路线走完，你会得到一个能在浏览器直接运行的接物小游戏，并且理解整套 AI 辅助开发的循环：写需求、拆任务、生成代码、跑起来、报错、修复、验证、再迭代。这个循环同样适用于后续做更复杂的玩法，甚至是接入 Unity、Godot 等引擎的场景。
2. 从零搭建一个 AI 游戏工作台：工具选型与项目基线
2.1 游戏引擎先别急着选，先确认你要做什么平台和玩法
很多人一上来就问“AI 能不能帮我写 Unity 游戏”，但其实第一步想清楚的反而是：你的目标平台是什么，玩法复杂度有多高。
我给自己的判断依据是三条：一是能不能在最短时间内跑出可玩原型；二是不是我熟悉的技术栈；三是素材依赖重不重。对于一个以“验证玩法”为目标的个人项目，我选了纯网页 Canvas，因为一个 HTML 文件就能承载完整玩法，不需要安装引擎、不需要编译打包，AI 生成结果后直接双击或用本地静态服务就能打开。
| 方向 | 代表方案 | 上手成本 | AI 辅助收益 | 适合场景 |
|---|---|---|---|---|
| 纯网页 Canvas | 原生 JS + Canvas API | 低 | 高，代码量小，适合整段生成 | 原型、2D 小游戏、教程示例 |
| 网页游戏框架 | Phaser、PixiJS | 中 | 中，需要理解框架生命周期 | 2D 网页游戏、平台跳跃、塔防 |
| 独立游戏引擎 | Godot | 中 | 中高，GDScript 生成质量尚可 | 跨平台 2D/3D 独立游戏 |
| 大型商业引擎 | Unity、Unreal | 高 | 中，强依赖项目架构和版本 | 复杂交互、团队化项目 |
这不是说 Canvas 比 Unity 好，而是说在“AI 辅助 + 原型验证”这个目标下，Canvas 的反馈链路最短。等你把玩法和手感验证清楚了，再迁移到 Godot 或 Unity 也不迟。反过来，如果你的目标就是做 3D 游戏，那直接进入 Godot 并用 AI 辅助写 GDScript 也是合理路线，只是排错成本会高一些。
2.2 AI 编码工具的配置：模型、上下文和提示词基线
现在可用的 AI 编码工具很多，常见的有独立编码编辑器、主流 IDE 里的 AI 插件、以及支持长上下文对话的大模型应用。工具形态不重要，重要的是你建立一套稳定的使用基线。
建议在开始项目前先确认三个配置项。第一是模型选择：代码生成类任务优先选擅长编码和长上下文的模型，如果团队技术栈是 Java，也可以关注 Spring AI 这类封装层，它把模型调用抽象成统一接口，适合做后端能力集成。第二是温度参数：代码生成建议用较低温度，减少随机发挥；需要头脑风暴玩法的时候再用较高温度。第三是上下文策略：不要在一个会话里塞几十轮无关对话，项目改到一个阶段后，把最新的完整代码和需求文档重新贴进新会话，让模型基于当前真实状态回答。
提示词基线我习惯用四段式：角色设定、任务目标、约束条件、验收标准。例如“你是一名资深前端游戏开发工程师；请实现一个 Canvas 小游戏；不使用任何第三方框架；最终代码要能直接保存为 HTML 并运行”。这个结构看着简单，但它能明显减少 AI 生成“次品”的概率，因为模型知道你希望它写到什么程度。
2.3 最小项目结构：一个 HTML 文件起步
对于原型项目，不要一开始就建一堆目录。我这次的项目结构只有两个文件：
catch-the-star/ ├── index.html └── README.mdindex.html里同时包含 HTML 结构、CSS 样式和 JavaScript 逻辑。README.md用来记录需求文档、迭代日志和 AI 对话中觉得重要的提示词。
这样做的好处是：本地运行零配置，AI 生成的代码片段可以直接整体替换，报错时也只需要把单个文件交给 AI 分析。等原型稳定后，再按“页面、样式、逻辑、素材”拆分结构也不迟。项目一开始就把结构做重，反而会让 AI 生成时频繁踩到引用路径和模块导入的错误。
3. 用 AI 重走一遍：从需求描述到可运行的小游戏
3.1 把需求写成给 AI 看的“产品说明”，而不是一句话
如果你只给 AI 一句“帮我做个游戏”，它能给你一百种不同玩法，其中大部分都跑不起来。有效做法是先写一页非常短的产品说明，把自己脑海里的画面翻译成 AI 能执行的语言。
我这次的需求说明是这样写的：
玩法说明 - 画布尺寸 600x400，深色背景。 - 玩家角色是画布底部的一个白色矩形。 - 按键盘左右方向键或 A/D 控制角色移动，不能移出画布边界。 - 画布上方每隔 1 到 1.5 秒随机掉落圆形物品。 - 绿色物品被接住后加 1 分；红色物品被接住后游戏结束。 - 画布左上角显示当前分数。 - 游戏结束后显示 Game Over，按 Enter 重新开始。 - 技术约束：单个 HTML 文件，使用 Canvas 2D，不引入任何外部依赖。这段说明只有 140 字左右，但它把玩法、规则、界面、技术约束全部说清了。AI 拿到这段文字后，不需要猜你的意图，生成的代码符合预期的概率会高很多。实际项目中，需求说明本身就是产品文档的雏形，AI 只是在帮你把文档变成代码。
3.2 分阶段生成：先静态画面，再移动，再碰撞，再计分
即使有了需求说明，也不要让 AI 一次性输出完整代码。我建议把开发拆成五个阶段：
| 阶段 | 提示词要点 | 预期结果 |
|---|---|---|
| 1. 静态场景 | 画出画布、背景、玩家角色 | 页面打开后能看到角色 |
| 2. 角色移动 | 键位绑定、边界限制 | 角色能左右移动且不会出界 |
| 3. 物品生成与下落 | 随机位置、随机速度、时间间隔 | 物品持续从上方掉落 |
| 4. 碰撞与计分 | AABB 碰撞判定、计分、游戏结束 | 玩法闭环成立 |
| 5. 手感打磨 | 调整速度、间隔、提示文字 | 游戏玩起来更舒服 |
分阶段的本质是“每一步都能验证”。如果一步错了，你只需要回退一步，而不需要把整段代码推倒重来。这对 AI 编码尤其重要，因为 AI 的上下文记忆有限，越长的代码越容易出现前后不一致。
3.3 完整代码示例：一个无依赖的 Canvas 小游戏
下面是我在 AI 生成结果基础上整理后的完整代码。它不依赖任何框架，保存为index.html后就能在浏览器中运行。这里给出的版本整理了变量命名和注释，实际 AI 生成的结果可能更乱，整理过程中也能帮你理解每段逻辑的作用。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Catch the Star - AI 辅助游戏开发示例</title> <style> html, body { margin: 0; padding: 0; background: #1e1e2e; font-family: sans-serif; } #game { display: block; margin: 24px auto; border: 1px solid #333; background: #101020; cursor: pointer; } </style> </head> <body> <canvas id="game" width="600" height="400"></canvas> <script> const canvas = document.getElementById('game'); const ctx = canvas.getContext('2d'); const W = canvas.width; const H = canvas.height; let score = 0; let gameOver = false; let lastTime = 0; let spawnTimer = 0; let fallingItems = []; const player = { width: 80, height: 14, x: W / 2 - 40, y: H - 30, speed: 260 }; const keys = { left: false, right: false }; function resetGame() { score = 0; gameOver = false; fallingItems = []; player.x = W / 2 - player.width / 2; spawnTimer = 0; } function spawnItem() { const type = Math.random() < 0.8 ? 'good' : 'bad'; const radius = type === 'good' ? 10 : 12; fallingItems.push({ type, radius, x: radius + Math.random() * (W - radius * 2), y: -radius, speed: 120 + Math.random() * 120 }); } function update(dt) { if (gameOver) return; if (keys.left) player.x -= player.speed * dt; if (keys.right) player.x += player.speed * dt; player.x = Math.max(0, Math.min(W - player.width, player.x)); spawnTimer -= dt; if (spawnTimer <= 0) { spawnItem(); spawnTimer = 1 + Math.random() * 0.5; } for (let i = fallingItems.length - 1; i >= 0; i--) { const item = fallingItems[i]; item.y += item.speed * dt; const playerRect = { left: player.x, right: player.x + player.width, top: player.y, bottom: player.y + player.height }; const itemRect = { left: item.x - item.radius, right: item.x + item.radius, top: item.y - item.radius, bottom: item.y + item.radius }; const hit = itemRect.right > playerRect.left && itemRect.left < playerRect.right && itemRect.bottom > playerRect.top && itemRect.top < playerRect.bottom; if (hit) { if (item.type === 'good') { score++; fallingItems.splice(i, 1); } else { gameOver = true; fallingItems.splice(i, 1); } continue; } if (item.y - item.radius > H) { fallingItems.splice(i, 1); } } } function draw() { ctx.clearRect(0, 0, W, H); fallingItems.forEach(item => { ctx.beginPath(); ctx.arc(item.x, item.y, item.radius, 0, Math.PI * 2); ctx.fillStyle = item.type === 'good' ? '#4ade80' : '#f87171'; ctx.fill(); ctx.closePath(); }); ctx.fillStyle = '#ffffff'; ctx.fillRect(player.x, player.y, player.width, player.height); ctx.font = '18px sans-serif'; ctx.textAlign = 'left'; ctx.fillStyle = '#ffffff'; ctx.fillText('Score: ' + score, 12, 28); if (gameOver) { ctx.textAlign = 'center'; ctx.font = '28px sans-serif'; ctx.fillStyle = '#ffffff'; ctx.fillText('Game Over', W / 2, H / 2 - 10); ctx.font = '16px sans-serif'; ctx.fillText('按 Enter 重新开始', W / 2, H / 2 + 24); } } function loop(timestamp) { const dt = Math.min((timestamp - lastTime) / 1000, 0.05); lastTime = timestamp; update(dt); draw(); requestAnimationFrame(loop); } window.addEventListener('keydown', (e) => { if (e.key === 'ArrowLeft' || e.key === 'a' || e.key === 'A') keys.left = true; if (e.key === 'ArrowRight' || e.key === 'd' || e.key === 'D') keys.right = true; if (e.key === 'Enter' && gameOver) resetGame(); if (e.key.startsWith('Arrow')) e.preventDefault(); }); window.addEventListener('keyup', (e) => { if (e.key === 'ArrowLeft' || e.key === 'a' || e.key === 'A') keys.left = false; if (e.key === 'ArrowRight' || e.key === 'd' || e.key === 'D') keys.right = false; }); resetGame(); requestAnimationFrame(loop); </script> </body> </html>这段代码里值得注意的点有三个。第一，requestAnimationFrame的回调会传入timestamp，代码通过dt归一化时间差，保证在不同刷新率屏幕上的移动速度一致。第二，碰撞检测用的是 AABB 矩形相交判断，给圆形物品画了一个外接矩形来简化计算，这在原型阶段完全够用。第三，spawnTimer控制了物品生成节奏，dt做了上限截断，防止浏览器切后台后回到页面时出现瞬间大量逻辑更新。
3.4 本地运行和首批验证
这个游戏不需要构建，直接用浏览器打开index.html就能运行。如果遇到文件协议下部分 API 受限，或者想模拟真实部署环境，可以在项目目录起一个本地静态服务：
cd catch-the-star python3 -m http.server 8080启动后访问http://localhost:8080，就能看到游戏页面。如果你本机没有 Python 但装了 Node.js，也可以用npx serve .这类工具启动同类型的静态服务。
首批验证要做的不是“看看好不好玩”，而是确认几个最基本的点：页面能否正常打开；角色能否左右移动且不越界；绿色物品掉落且被接住后分数是否加 1；红色物品接住后是否显示 Game Over；按 Enter 后能否重新开始。这五点全部通过，这个原型才算真正跑通。
4. AI 生成的代码为什么不能直接信：拆解一次“从报错到修好”
4.1 最常见的生成结果问题：不存在的 API 和过旧写法
AI 幻觉是 AI 编码里最典型的问题。它具体表现为：模型自信满满地写出一个 API，但这个 API 根本不存在；或者写出了某个框架中已经废弃的旧写法；或者在 Canvas 里调用了一个参数顺序错误的方法。模型不会因为自己“不确定”而主动提醒你，这正是它和搜索引擎文档最大的区别。
以 Canvas 为例，AI 很容易把ctx.fillRect(x, y, width, height)的参数顺序写反，或者把ctx.arc(x, y, r, startAngle, endAngle)的末尾参数漏掉。这类问题在代码量小的时候一眼能看出来，但一旦游戏逻辑变复杂，报错信息往往会指向一个看起来毫无关系的行。
处理这类问题的方法是：不要直接问 AI“帮我找 bug”，而是把完整的报错堆栈、相关代码片段和你的操作步骤一起贴给它。比如下面的提示词模板：
运行下面这段代码时，浏览器控制台报错： Uncaught TypeError: Cannot read properties of undefined (reading 'x') 相关代码： [粘贴代码片段] 我刚刚做的操作是：用方向键移动角色后，物品下落时才出现这个报错。 请先分析可能原因，按可能性排序，并给出修复后的完整函数。不要改其他逻辑。这样写的目的是把 AI 的搜索空间缩小。它不需要猜测你遇到什么问题，也不需要自己构造复现场景，只需要基于你给的真实信息做定位。
4.2 把错误日志和分析任务一起交给 AI，而不是只问“为什么出错”
很多人在 AI 编程时只会写“为什么报错”，然后 AI 给出一个通用解释，用户还是一头雾水。更有效的做法是永远提供三段信息：现象、操作、代码。
现象描述要具体到报错文本和控制台输出；操作描述要写清楚“我先做了什么，然后发生了什么”；代码片段要贴出真正相关的那一段，而不是整个文件。如果文件很长，可以拆成几次提交，每次只针对一个函数或一个事件处理函数。
举例来说，如果游戏在运行过程中偶尔报dt未定义，正确做法是把requestAnimationFrame回调这一段贴出来，并说明“第一次打开是好的，但是按 Enter 重开后报错”。AI 收到这些信息后，大概率会引导你检查lastTime是否在resetGame里被重置，或者requestAnimationFrame是否在重开时启动了多个循环。这类问题靠一句“为什么报错”是问不出来的。
4.3 用版本锁定和最小复现控制“AI 幻觉”
减少 AI 幻觉还有一个实用手段：在提示词里主动锁定技术版本。你可以在需求说明中写明“使用 JavaScript ES6 语法”“使用 Canvas 2D 通用 API”“不要使用任何第三方库”“不要使用浏览器实验特性”。版本锁定本身不复杂，但它能显著降低模型去“发挥”最新语法的概率。
如果生成代码后仍然频繁出现让你看不懂的报错，最佳手段是构造最小复现。先删掉游戏里和报错无关的部分，只保留能触发问题的十几行代码，再把这段最小代码交给 AI 分析。最小复现既能提高 AI 判断准确率，也能帮你确认问题到底是出在自己的逻辑上，还是出在浏览器兼容性上。
注意：不要把生成结果当文档来读。AI 给出的代码能跑通，说明它至少在某个环境里逻辑自洽；如果跑不通，优先相信报错信息，而不是相信模型的解释。
5. 运行验证：从“能打开页面”到“玩法真的成立”
5.1 功能验证清单和预期结果
对于一个原型游戏，我建议验证时直接列一张清单，每项都写上预期结果。下面是可以直接套用的验证表：
| 检查项 | 操作方式 | 预期结果 |
|---|---|---|
| 页面加载 | 刷新浏览器 | 无报错，画布正常显示 |
| 角色移动 | 按左右方向键、A/D | 角色左右移动，不越界 |
| 绿色物品计分 | 移动到绿色物品下方 | 左上角分数加 1 |
| 红色物品结束 | 让红色物品碰到角色 | 显示 Game Over |
| 重新开始 | 游戏结束后按 Enter | 分数归零，物品清空 |
| 切后台恢复 | 运行中切换标签页再回来 | 游戏不瞬移、不卡死 |
这份清单越基础越好。很多时候问题不是出在复杂玩法上，而是出在最基本的流程上。比如按 Enter 后重新开始，如果只是把分数清了但fallenItems数组没清，旧物品还会继续出现在画布上，这属于典型的状态重置遗漏，AI 很容易漏掉这种细节。
5.2 手感调优：速度、间隔、碰撞判定这些参数从哪里来
当玩法逻辑全部跑通后，就要进入手感调优阶段。手感这个东西很主观，AI 给不出答案，因为它不懂你的目标。你需要自己做实验，调整的参数包括：角色移动速度、物品生成间隔、物品下落速度、碰撞判定范围、画面反馈效果。
比如把这个游戏调到“难度适中”的过程中，我依次调整了三个参数：player.speed从 220 调到 260，让角色跟手；spawnTimer从恒定的 1.2 秒改成 1 到 1.5 秒随机，避免玩家背板；物品下落速度从固定 150 改成 120 到 240 的随机区间，让每局手感都有差异。
这些参数在 AI 生成的代码里通常都散落在常量定义中。你可以直接让 AI 把参数提取到文件顶部的配置对象里，方便统一调整：
const CONFIG = { playerSpeed: 260, spawnIntervalMin: 1.0, spawnIntervalMax: 1.5, fallSpeedMin: 120, fallSpeedMax: 240 };把参数集中管理后，手感调优就不再是搜索每一处数字，而是改配置对象里的一个值。这个习惯在 AI 辅助开发中尤其重要，因为 AI 生成的代码经常会把魔法数字散落在各处，不统一抽出来，后面调起来非常痛苦。
5.3 控制台和浏览器工具排查
遇到运行异常，第一反应应该是打开浏览器开发者工具。在页面上按 F12，进入 Console 面板，所有 JavaScript 报错都会显示在这里。常见的浏览器报错有几类：变量未定义、读取不到属性、语法错误、以及requestAnimationFrame循环异常。
排查顺序建议从现象反推：先看报错发生在哪个文件哪一行；再看报错信息里的变量名或函数名是不是代码里确实存在的；最后看是不是事件触发时机的问题，比如键盘事件绑在了window上但页面内嵌了 iframe，导致焦点丢失后按键不响应。
遇到“明明没报错但功能不对”的情况，可以在关键位置加console.log输出现场数据。比如物品是否生成、碰撞条件是否进入、分数是否变化。AI 生成代码时经常会忽略这些调试输出，加日志是开发者自己要补上的工作。
6. 常见坑：AI 做游戏最容易在哪几步翻车
6.1 坑一：一句话要一个完整游戏，AI 返回一坨不可维护代码
最典型的错误写法是“帮我做一个完整游戏”，AI 会生成一个几百行的巨型代码块，里面打包了画面、逻辑、音效、存档，然后你运行时报错，你根本不知道从哪里开始排查。
原因在于 AI 的上下文和注意力都是有限的。任务越广，代码越长，前后不一致的概率就越大。正确的做法是把大任务拆成可验证的小任务。每完成一个小任务，就把代码保存、运行、确认无误，再让 AI 继续下一步。这种“一小步一验证”的模式，是把 AI 从“代码生成器”变成“结对程序员”的关键。
6.2 坑二：依赖版本没对齐，生成代码用了还没普及的 API
如果你的项目用了 Phaser、Three.js 或 Godot 这类框架，AI 很容易按照它记忆里的最新版本 API 写代码，而你自己本地装的可能是旧版。结果就是property is not a function，或者构造函数参数对不上。
预防方法是把版本信息直接写进提示词。比如“使用 Phaser 3.60 版本，使用this.physics.add.existing而不是旧版写法”。如果项目里已经有代码，把现有代码的引入方式和版本字段贴给 AI，让它先对齐环境再写新逻辑。发布前的另一个稳妥做法是直接在需求说明里锁定主要依赖版本号，避免与生成代码不一致。
6.3 坑三：上下文太长后 AI 忘记早期约定，反复改坏功能
AI 对话窗口的上下文是有限的。当你在同一个会话里聊了几十轮之后，它可能忘记最初的“不使用第三方库”或“玩家不能越界”这类约束，然后生成一段依赖外部库或破坏边界限制的代码。
处理办法是“定期存档”。每完成一个稳定版本，就把代码保存，并把当前需求说明、代码结构和下一步任务写进新会话。不要指望 AI 能在一个超长对话里记住所有历史，给它一份新的、干净的项目状态说明，效果会好得多。
注意：AI 对话中的“记忆”并不可靠。重要的决策、参数、文件路径，都应该落在代码注释或 README 里，而不是只存在于聊天记录中。
6.4 坑四：把 AI 当成美术和策划，素材和数值全靠它“猜”
有些开发者会发现 AI 能生成图片、文案、音效，于是把整个游戏的美术风格、对话和数值全都交给 AI 决定。结果做出来的东西玩起来总感觉哪里不对，但又说不清哪里不对。
这是因为 AI 只能给出“统计上像样”的答案，无法判断你的目标玩家喜欢什么。占比、难度曲线、奖励节奏这类数值设计，必须靠你自己设计、试玩、调整。美术素材在原型阶段可以用 AI 生成，但进入正式发布阶段，仍然需要确认素材版权、风格统一和去重问题。AI 是助手，不是决策者。
7. 从 Demo 到可发布：还差哪些工程能力
7.1 音效、存档和资源管理的轻量补齐
原型做完后，最容易让游戏“显得完整”的增强是音效、存档和资源管理。对于无依赖的网页游戏，音效可以不用外部文件，直接通过 Web Audio API 生成简单音效，例如接住物品时播放一个短促“嘀”声，结束播放一个低音。
存档也只需要几行代码。把最高分写入localStorage，下次打开页面时读取并显示，玩家会明显感觉到这是一个“有记忆”的游戏：
const BEST_KEY = 'catch-the-star-best'; function saveBest() { const best = Number(localStorage.getItem(BEST_KEY) || 0); if (score > best) { localStorage.setItem(BEST_KEY, String(score)); } }不过在增加这些功能前，先确认它们是否服务于玩法。不要为了“像完整游戏”而堆功能，每一个新增功能都会增加验证和排错成本。
7.2 性能与加载优化
原型代码跑起来没问题，不代表发布前不需要处理性能。这个回合制很简单，但如果你把玩法扩展成同时存在几百个物品，就需要考虑对象池、离屏 Canvas 和 draw 调用次数优化。
最简单也最有效的优化是限制同时存在的物品数量。当fallingItems.length超过某个阈值时，停止生成新物品，或者复用最旧的物品对象。另一个容易踩的坑是帧率不稳定，导致动画卡顿。用requestAnimationFrame驱动时一定要做dt截断，防止后台切回时一次性追上大量时间差。
7.3 发布、版本管理和 AI 素材合规
网页小游戏发布成本很低，常见的静态托管平台就能直接托管单页项目。发布前至少要做一次多浏览器验证，至少检查 Chrome、Edge 和移动端浏览器。
版本管理建议从第一天就引入 git。每完成一个可玩版本就提交一次，这样 AI 把功能改坏时，你可以轻松回退到上一个稳定状态。对于 AI 生成的素材，要保留生成记录、确认素材的使用许可，并在项目 README 里写明来源。不要默认“AI 生成的东西没有版权问题”，不同的模型和平台对生成内容的使用授权并不完全一样，发布前要自己核对。
7.4 发布前检查清单
发布前的检查不能只做一次，建议在正式上线前完整走一遍：
| 检查项 | 检查方式 | 通过标准 |
|---|---|---|
| 核心玩法 | 完整试玩 3 轮 | 计分、结束、重开均正常 |
| 浏览器兼容 | Chrome、Edge、移动浏览器 | 无阻断性报错 |
| 存档功能 | 刷新页面、重启浏览器 | 最高分正常保存和读取 |
| 音频控制 | 浏览器音频策略 | 首次交互后能正常播放 |
| 资源来源 | 检查 AI 生成素材记录 | 说明来源和授权 |
| 代码提交 | git status和提交记录 | 最新代码已提交 |
| 日志清理 | 搜索console.log | 无调试日志残留 |
这些检查做完，游戏才具备分享给别人的基础。否则读者打开页面看到一堆控制台报错，体验会大打折扣。
8. 两周上手路线和拓展方向
8.1 两周从“跟着生成”到“自己主导”
如果你也想从零进入 AI 游戏开发，可以参考一个为期两周的路线，重点是逐步减少对 AI 的依赖，增强对代码的理解。
| 阶段 | 时间 | 任务 | 验证标准 |
|---|---|---|---|
| 第 1 天 | 跑通本文的 Catch the Star | 玩法完整，参数可调 | 能按需求说明修改变量 |
| 第 2-3 天 | 增加音效、最高分和暂停功能 | 每个新增功能独立验证 | 代码仍保持单个文件可运行 |
| 第 4-5 天 | 用 AI 生成一个不同玩法的微游戏 | 例如飞行躲避或记忆翻牌 | 能整理出可复用的需求说明模板 |
| 第 6-7 天 | 自己动手改掉 AI 生成代码里的一处逻辑 | 例如改变碰撞规则 | 能说清楚改动前后行为差异 |
| 第 8-10 天 | 把原型迁移到 Godot 或 Phaser | 复刻同样的玩法 | 生成代码中框架版本与本地完全一致 |
| 第 11-14 天 | 设计一个原创玩法并完成可运行原型 | 玩法文档 + 原型 | AI 只负责执行，你负责决策 |
这个路线最核心的训练目标是“拆任务”。AI 能帮你把任务跑完，但把玩法拆成哪些子任务、每个子任务怎么验证，这些判断必须由你完成。练习次数多了之后，你会发现自己问 AI 的提示词越来越精准，返工率越来越低。
8.2 更复杂的玩法如何继续用手动拆分 + AI 执行
如果下一步想做一个像“合成大西瓜”或“飞行射击”这样的小型完整游戏，方法完全一样。不要把整个项目交给 AI，而是先拆出核心循环：生成物体、物理运动、碰撞处理、得分规则、失败条件、界面反馈。每个循环单独用 AI 生成并测试，跑通后再组合。
组合时最容易出问题的是状态共享。比如“合成”玩法的物体列表、连锁反应和分数计算之间耦合度高，AI 很难一次生成正确。建议在需求说明中显式画出数据流动关系，让 AI 明确谁是数据入口、谁是状态源、谁负责刷新界面。即使不写正式设计文档，至少要在提示词里把这些关系说清楚。
8.3 最终建议：把 AI 当成协作者，而不是监督者
这次 AI 游戏开发旅程给我最大的体会是：AI 不是来替代你做游戏的，它更像一个效率极高的协作者。它能快速生成原型、快速查错、快速生成描述性文案，但它无法替你做手感判断、无法替你做玩法取舍、也无法替你对最终版本负责。
如果你刚开始尝试，最值得投入的事情是两件：一是把需求写清楚，二是把验证做扎实。需求写得越具体，AI 的能力发挥得越充分；验证做得越早，返工成本就越低。等你把这两个习惯练成肌肉记忆，AI 在游戏开发里能帮你节省的时间会远超你刚开始时的想象。之后无论是做网页小游戏、接入 Godot 做独立游戏，还是把 AI 能力封装成自己的游戏开发工作流，你都已经掌握了最关键的方法。