说实话我见过太多前端同事做游戏的第一步就卡死在“想太多”上。脑子里从关卡设计想到了排行榜架构代码一句没写一晚上过去了。我自己入这行将近十年真正让我把第一个小游戏做出来的不是哪门“游戏引擎课”而是一套特别朴素的思路用 AI 把可玩原型先立起来然后再把它一点点补完。今天这篇就把这条路线展开聊聊——前端开发者为什么适合这么做、AI 在哪个环节真正帮你省时间、以及从“能跑”到“能看”中间那些 AI 大概率不会替你想到的坑。1. 方向选择为什么我先做一个“丑得能玩”的原型而不是直接规划完整游戏1.1 可玩原型的边界到底划在哪很多前端开发者的通病是把小游戏当成“页面”来规划。要菜单、要设置、要商店、要排行榜再加一堆转场动画。这套需求在 Web 应用里很合理但在游戏项目里就是灾难。游戏开发的核心反馈回路是玩家操作系统给反馈反馈产生情绪情绪驱动继续操作。你第一版要验证的是这条回路通不通而不是外围功能全不全。所以我给“可玩原型”划的边界很简单一个页面能打开玩家能用鼠标或键盘进行操作核心玩法能跑满 30 秒以上不崩溃有明确的胜负判定。就这么多。画面可以丑用色块和几何图形代替美术资源数值可以粗糙先调到“手感和结算逻辑对”就行菜单可以没有刷新页面就当重新开始。这样做的目的是让你在动手半小时后就能摸到一个真实可玩的东西而不是对着抽象需求文档发呆。1.2 前端开发者选技术栈的妥协方案Canvas 优先但别排斥 DOM怎么选渲染方案这个问题我跟 AI 吵了不止一次。它的默认偏好是给你写canvasJS 全量绘制因为通用的贪吃蛇、飞机射击这类教程代码全是这么写的。但对于有前端背景的人我得提醒你Canvas 不是唯一解甚至不是最优解。如果你的玩法本质是“一堆块在网格上移动”或者“几个元素在页面里做交互动画”那用绝对定位的 DOM transitiontransform完全够用浏览器帮你处理了几乎所有渲染细节。只有当对象数量超过 100 个或者需要每帧对大量像素做碰撞检测时Canvas 的 2D 上下文才真正有优势。我的个人标准是先判断“对象数量”和“每帧更新复杂度”。假如这俩指标都不高别为了“显得专业”而上 Canvas。你用 DOM 写AI 生成的代码你容易看懂改起来心里有底。至于纯游戏引擎像 Phaser 这类框架我不建议第一次尝试就上。倒不是它不好而是 AI 生成的 Phaser 代码里场景管理、预加载、物理系统这些概念你一旦不熟出了问题连报错都读不懂。先用裸语言把逻辑跑通再考虑引擎是转行做游戏比较顺的一条路径。2. 把 AI 当聪明助理的正确用法我的提示词和迭代流程2.1 给 AI 一份“游戏策划案”而不是一句空泛需求AI 编程最大的误区是上来就喊“帮我写个游戏”。这句话太宽泛它只能给你一个最模板化的随机生成器。我自己的习惯是先花 15 分钟写一份极简策划案结构固定玩法名称、操作方式、胜利条件、失败条件、难度增长曲线、美术建议。不需要长每项一两句话但你必须先想清楚。举个例子假设我想做的是接金币游戏玩法名称接金币 操作方式鼠标左右移动或手指拖动控制屏幕底部的篮子 胜利条件60 秒倒计时结束后累计接满 100 个金币 失败条件漏掉金骨头累计 3 次 难度增长曲线每 15 秒金币下落速度提升 20% 美术建议先用圆形文字代替金币等原型跑通后再补素材这份东西发给 AI 之后它的输出质量会跟“帮我写个接金币游戏”完全不在一个量级。因为它不再需要替你瞎猜需求可以把全部精力放在代码逻辑上。这里必须强调一下美术建议那条这其实是给 AI 的“降噪指令”。如果你不提它会自作主张引入图片资源、加载逻辑甚至雪碧图这些对原型阶段都是包袱。明确告诉它“用几何图形”能帮你省掉一大半前期排查时间。2.2 迭代时把问题拆成“改一个小函数”而不是贴一整段报错AI 对话的第二个关键技巧是管理上下文。很多人会把整段脚本一次性扔给 AI然后说“帮我加个功能”这会让模型陷在整个文件里找不到重点。我在实践中更好用的模式是“按函数迭代”先让 AI 把核心组件拆成独立函数比如spawnCoin()、updatePositions()、checkCollision()之后每次修改都精确命中其中一个而不是“整个文件”。另外碰上报错先别急着把整屏报错直接贴过去。先自己读一下报错信息是哪一行、什么类型、涉及哪个变量把这个信息用大白话描述给 AI。比如“我的updatePositions里访问coins数组中的元素报错说 undefined”它基本上一耳朵就能定位。你用什么 AI 工具都行重点是养成“用问题描述驱动 AI”的习惯这比“复制粘贴整段崩溃日志”有效得多。2.3 用“守门员”心理AI 给的第一版永远是草稿不是答案我自己踩过的最大的坑是太信任 AI 第一次给出的方案。有一次它给我生成的物体生成器没有做屏幕边界判断物体源源不断往屏幕外生成浏览器标签页直接卡到无响应。这种问题用搜索引擎也能搜到但在 AI 辅助下特别容易放松警惕因为它给出的代码语法漂亮、结构清晰看起来就很“正确”。所以我给自己定了一条规矩AI 生成的代码第一次运行前必须过一遍“关键三行”——创建对象的地方、更新位置的地方、检测碰撞的地方。把这三个点找出来读一遍确认逻辑闭合再按运行按钮。这不是不信任 AI而是你不掌握这三个点的话后面出了问题根本没法查。3. 从“能玩”到“像样”AI 容易漏掉但你必须自己拍板的细节3.1 游戏循环与实时帧率为什么不用 setInterval 写主循环市面上的入门教程里一半让你用setInterval做循环另一半让你用requestAnimationFrame。我自己最初也觉得setInterval更直观直到做了个下落速度越来越快的游戏才发现它的致命伤setInterval的最小间隔不稳定浏览器切后台还会被节流导致金币突然瞬移一大截。这时候要理解一个概念叫“帧率无关性”。你的游戏逻辑如果依赖“每帧移动多少像素”那在 144Hz 的屏幕上游戏就比在 60Hz 的屏幕快 2.4 倍。解决办法是用时间差专业术语叫 deltaTime。每次requestAnimationFrame回调里计算这一帧和上一帧的时间差所有速度都乘以这个差值游戏在什么刷新率的屏幕上都会以同样节奏运行。3.2 碰撞检测的物理精度矩形、圆心还是距离碰撞检测看着像是一个纯数学问题实践中却最能体验出一个开发者是否“懂游戏”。AI 默认多半给你矩形相交检测因为它的实现最简单两个矩形的边界框相交就判定碰撞。这个方案对格子游戏没问题但对圆形物体尤其是需要精确手感的小球类游戏误差大到玩家能明显感觉到“我明明没碰到它却被判死了”。我个人的做法是接到游戏需求先判断主体形状。如果球类物体居多直接用圆心距离检测计算两球心直线距离小于半径之和就是碰撞了一行公式搞定。如果矩形偏多再考虑 AABB 检测。这个选择也直接影响玩家对游戏“手感”的评价——所以千万别让 AI 替你拍板它只会选最好写的不会选最合适的。3.3 重开一局的隐藏成本全局变量、事件监听和音效可玩原型里很容易忽略“局间重置”这件事。我第一次做测试的时候玩完一局想再来一局发现分数还在涨、旧的金币还在下落新的一批又生成了。原因很简单所有状态都存在全局变量里AI 帮你写了个startGame()但这个函数里只顾着初始化新值忘了清掉旧的事件监听和定时器。一个更隐蔽的问题是重复事件监听。你每 start 一次就addEventListener一次到第三局时同一个点击被触发了 3 次游戏难度直接变成地狱模式。所以我在迭代时会专门盯着 AI 的启动流程要求它把所有监听器集中到一个初始化函数里并在重开时统一removeEventListener或者用标志位防止重复注册。音效也是这一块最容易出问题的。AI 生成的音频处理代码常见错误是没在用户交互后调用播放接口结果浏览器直接屏蔽音频。我给的解决方式是第一次点击屏幕时创建一个全局AudioContext之后所有音效都挂在这个实例上不要在每次播放时新建。这既能过浏览器的自动播放策略又避免开太多音频节点导致内存泄漏。3.4 适配移动端从“能用鼠标”到“能在手机上玩”很多前端开发者写的第一版游戏只考虑桌面端鼠标移动或者键盘上下左右测试时在浏览器里缩一缩窗口觉得没啥问题真到了手机上才发现抓瞎。移动端至少要解决三件事第一触摸事件的touchmove要配合preventDefault()否则页面会跟着手指滚动第二click事件在移动端有 300 毫秒延迟游戏交互最好统一用pointerdown/pointermove第三横屏或竖屏的屏幕比例不同物体生成边界不能写死固定像素要用clientWidth和clientHeight动态计算。这些如果靠你自己挨个去查半天就没了。但你在迭代提示里主动跟 AI 提一句“请兼容移动端触摸事件并动态计算边界”它通常一次就能给你补齐。前提是你得知道要提这个需求。忘了提它的代码就只会为桌面服务。这一节的主旨是AI 可以帮你写代码但它不知道你心里的玩家会在什么设备上打开游戏这些信息你得自己喂给它。4. 运行时的暗坑AI 生成代码里最常见的三类逻辑病4.1 数组遍历时删除元素导致的下标错乱这个 Bug 在 AI 生成的代码里出现频率极高。场景是检测到金币和篮子碰撞就把这个金币从数组里删除删除的同时数组长度变了但循环变量还在继续自增于是隔一个金币被漏判一次。新手经常看到“有时候明明撞上了不消失”“金币消失的规律很随机”十有八九就是这个问题。修复方案有两种。一种是从后往前遍历删除当前元素不影响前面的下标另一种是用filter方法重新生成数组。第二种更符合函数式习惯代码可读性也好。我在给 AI 写提示时会直接说“碰撞检测遍历金币数组时请用 filter 返回新数组不要用 splice 边遍历边删。”它基本能一次写对。4.2 时间累加导致的游戏越来越卡如果 AI 初始化时用了setInterval生成金币而你没在后续版本里把它换掉就会出现一个经典问题玩得越久单位时间内生成的金币越多因为多个定时器叠在一起了。这个 bug 看起来跟“难度曲线”很像玩家会以为游戏设计就是越来越快但实际上是性能越来越差。我实测过的一个项目开局 10 秒后 FPS 就掉到 20 以下。排查后发现每一层金币下落函数都被上一轮循环的定时器重复调用。解决办法是把定时生成改成在requestAnimationFrame的循环里基于时间判断。比如记录上一次生成金币的时间当前时间减去上一次大于 800 毫秒就生成一个。这样游戏速度和性能都稳定在一个函数里不会因为定时器堆叠而失控。4.3 硬件加速和内存泄漏DOM 方案的隐藏成本如果你采用 DOM transform 方案做游戏有一个性能点必须提前盯住transform和opacity是 GPU 加速属性频繁改动它们的问题不大但如果你直接改top和left每次位移都会触发布局重排一百个元素时页面就会明显卡顿。所以即使是在 DOM 上做游戏我也坚持让 AI 把所有定位都写成transform: translate(x, y)几乎是物理内存层面最便宜的优化。内存泄漏就比较隐蔽了。尤其是在做“爆炸特效”这类功能时AI 会习惯性document.createElement一个元素然后 append但如果它没在动画结束后remove这个元素会一直挂在 DOM 里。游戏越玩越卡的原因不是逻辑变重了而是 DOM 节点越积越多。你可以在优化阶段让 AI 自己写一个对象池或者至少在动画结束的回调里清楚释放节点。5. 收尾阶段的心智转变从“可玩原型”到“敢发给朋友玩”5.1 打磨手感比加功能重要十倍可玩原型跑通之后自然会产生“要不要加点新玩法”的冲动。我个人的建议是忍一忍。把剩余时间绝对优先投入“手感调整”。什么叫手感就是操作响应有没有延迟、碰撞判定是不是符合直觉、速度曲线是不是让人感到“上头”而不是“手忙脚乱”。这时候我常做一件事让游戏暴露一部分调试参数。比如下落速度、生成间隔、碰撞半径全部定义在代码最前面的一个CONFIG对象里。每次调整我只需要改一个数字刷新页面再玩一局。这比让 AI 去猜“哪里应该改”效率高出一个量级。用不着优雅的 UI 面板甚至不需要可视化工具一个小配置区足够。5.2 保留调试信息不想让别人看见就藏在 URL 参数后面很多开发者的习惯是发测试版给朋友前先把所有调试信息从页面上删干净。我反而会建议你反过来做把调试信息留成可开关的。比如 URL 带?debug1时显示 FPS、碰撞半径和当前对象数不带就一切如常。为什么值得多花这一步因为游戏最难复现的 bug 往往只在特定节奏下出现朋友玩的时候一句话描述根本不够你定位的。我做过一个很有效的操作让 AI 在 debug 模式下每秒在画面角落输出几条关键数值——对象数量、当前帧率、最近一次碰撞的坐标。朋友发来一张截图我立刻就知道问题出在哪。后来压测了几个 AI 协作项目发现负责任的做法其实是把“可观测性”当成一等公民而不是最后才补的装饰物。5.3 构建与发布体积控制、静态资源 CDN 与首屏加载当游戏总算可以发给别人玩时前端的职业病就该上线了。顺手就开的构建工具链压缩一波 JS图片资源压成 WebP能管不少用。用 Vite 也好用 webpack 也好对一款原型级别的游戏来说最重要的指标就是首包体积。不要为了一个可能在 10 秒后才会出现的美术资源把首屏体积撑到 5MB 以上。另外一个容易被忽略的问题是加载顺序。如果你给 AI 描述的美术资源是动态加载的注意要在资源加载完成之后再显示“开始游戏”按钮否则点下去可能正好加载到一半素材区域一片空白。这也是典型“看着不严重、实际很影响第一印象”的问题。在发布之前花 5 分钟做一次低网速模拟测试比什么都值。6. 在 AI 游戏项目里培养自己的判断力怎么避免沦为“调参师”6.1 把 AI 当成“短期记忆”自己得握有“长期记忆”做到第六个晚上我意识到一个核心问题AI 跟人一样上下文窗口内的记忆是有限的。我今天改了金币速度明天让它调音效它可能把速度给回退到一个更早的版本。于是我把所有关键参数从代码里抽出来调整记录直接用注释和版本号写在一个README.md里。这听起来很土但确实救了我好几次。更重要的是这种“参数和逻辑分离”的习惯能让你在 AI 的辅助下始终握住游戏的灵魂。AI 负责实现你负责决策。一旦你自己心里有清晰的决策依据AI 就是很好的执行工具反之如果决策全交给 AI你跟用户之间的差距就只剩下一层偶然性。6.2 用 Playtest 代替代码评审让真人的反应替你找问题代码评审在传统项目里是好习惯但游戏项目里最有效的是真人测试。我每次做到一个里程碑就发给三五个人试玩标题只有一句话“帮我玩两分钟随便操作录个屏”。不解释玩法不给指导哪怕他们完全玩不懂你也能从录屏里看出哪些信息玩家根本没注意到哪些按钮的点击反馈不够明显。我前前后后做过两次测试第一次“玩家”一进去就狂点屏幕发现我的随机生成逻辑对高频点击特别不友好直接穿透了碰撞检测判定。第二次有人告诉我“胜利的提示太小了赢了我都没反应过来”。这些都是代码层面看不出问题、但直接影响体验的真实反馈AI 再聪明也没法替你完成这一步。6.3 第二个游戏会快很多把 AI 对话记录存档成模板最后的实用提醒是第一个游戏做完别把 AI 的对话记录清空。那个长长的工作流里存着你所有踩坑时的精确描述和 AI 给出的修正方案。下一次做第二个游戏时把第一段对话的历史记录直接甩给新对话作为“背景资料”你会发现 AI 自动避开了很多第一轮犯过的错误。我把这种对话记录叫做“个人开发经验缓存”。有意思的是这缓存比代码仓库更能体现你的思维过程。代码仓库保存的是最终状态而对话记录保存的是你如何一步步把它变成最终状态的。两条线索合在一起才是你真正从“前端开发者”转向“会做游戏的前端开发者”的证据。关于 AI 辅助做小游戏我最想留给你的一句话其实特别朴素别让它替你决定你的游戏该是什么样让它替你把你想做的游戏实现出来。第一版可以很丑但一定要可玩后面的每一版都让玩家的反馈而不是 AI 的建议来当方向盘。下一个周末不妨就从一个弹球游戏或者一局贪吃蛇开始相信我30 分钟之后你会看到一个能玩的页面那种成就感和写完一个业务组件完全不是一回事。