家里有个10岁的小朋友，最近突然迷上了“小兔子接胡萝卜”这种简单又上头的掉落小游戏。我寻思这需求也不复杂，干脆自己做一个给她玩。真正动手之后发现，现在用AI辅助写代码的效率是真的高——从描述需求到浏览器里能跑，前后没用半小时。这篇文章就是给这个小游戏项目留个档，也把我和AI协作开发HTML小游戏的完整过程、代码思路、以及实际运行中踩过的坑都记下来，希望对同样想动手给小朋友做东西的人有点参考。
1. 先想清楚：为什么是HTML小游戏
1.1 单文件零依赖，双击就能玩
做给10岁小孩玩的东西，第一原则是“不要给使用制造任何门槛”。HTML小游戏的最大优势就是单文件，HTML、CSS、JavaScript三样都写在同一个文件里。把这个文件保存成game.html，在任何电脑、手机、平板上，只要是带浏览器的设备，双击就能直接玩。
不需要装Python、不需要配置Node环境、不需要打包成app、不需要联网加载资源。对小朋友来说，“双击文件”就是全部的上手成本。对大人来说，留档也特别省心：一个文件就是整个项目，拷贝、备份、发给别人都方便。如果是客户端游戏或者服务端游戏，留档要留的东西就太多了，环境配置、依赖版本、数据库结构，随便哪个变了都可能跑不起来。
我最初也想过做成小程序或者手机App，后来发现没必要。又不是什么需要推送、需要账号体系的场景，就是给自家孩子玩的小玩具，HTML单文件是最合适的形态。想改配置直接改代码，想换主题就换颜色，随时随地能迭代。
1.2 canvas还是DOM：AI写哪种代码更稳
确定了HTML之后，紧接着要决策的是渲染方案。小游戏的画面实现，无非两条路：用canvas画布自己绘制，或者用DOM元素配合CSS来做。
两条路的差异很明显。canvas上限高、性能好，适合做复杂动画和大量粒子，但代码量也大，坐标系统要自己维护。DOM方案就直观得多，每个游戏元素就是一个div，摆放位置靠CSS或者JavaScript直接改坐标，调试的时候一眼就能看出问题在哪。
这里有一个实际经验：如果用AI辅助开发，DOM方案的稳定性明显高于canvas。我试过让AI用canvas写同样的小游戏，坐标错乱、缩放失真的情况出现概率很高。因为canvas需要计算绘制位置、画布尺寸、坐标系缩放，AI在生成这类代码的时候经常出现前后不一致。而DOM方案，AI只需要操作元素的left、top、transform，这部分训练样本多，出错率低很多。
小兔子接胡萝卜这个游戏，同时出现在屏幕上的掉落物最多也就十几个，DOM的性能完全够用，不需要上canvas。既然目标是“快速做出能玩的成品”，那就选最简单的方案。很多技术选型其实不是选最强的，而是选最不容易出错的。
1.3 主题由孩子定，规则由人拍板
游戏的内容主题是小朋友自己提的：要兔子，要胡萝卜，要可爱好看的粉粉嫩嫩风格。这个需求描述简单明确，但作为开发者，我在接手的时候把规则细化了一下：
- 玩家控制小兔子，在画面下方左右移动
- 胡萝卜从上方随机掉落，接住一个得1分
- 出现金色胡萝卜时，接住得5分
- 炸弹不能接，碰到炸弹游戏结束
- 得分越高，掉落速度越快
为什么这么定？因为10岁孩子的注意力模型很清晰：目标明确、反馈及时、难度渐进。如果规则太复杂，她第一关就失去兴趣；如果没有失败机制，玩两分钟就腻了。炸弹的存在让游戏有了紧张感，速度递增让玩家能持续感受到挑战。
有一点特别重要：AI只是执行工具，它不会替你做产品决策。你给AI提供规则，它负责实现，但“这个游戏好不好玩”是需要人来判断的。我试过直接把“小朋友想玩接胡萝卜游戏”这句话丢给AI，生成出来的版本确实能跑，但节奏平淡、难度没有变化，玩两把就不想碰了。AI写的是代码，产品设计和体验调优还是得靠人。
2. 与AI协作的实操方法：把需求说成人话
2.1 第一版提示词：给AI一个“画面感”
跟AI协作，最关键的是第一版提示词。写得太简单，AI就给一个最简陋的版本；写得太复杂，AI容易顾此失彼。我实际用的第一版提示词大概是这样的：
请帮我写一个HTML游戏，适合10岁小女孩玩。 主题：小兔子接胡萝卜。 游戏玩法：小兔子在画面最下方，玩家用键盘左右方向键控制移动，胡萝卜从画面顶部随机掉落。成功接到胡萝卜得1分，碰到炸弹则游戏结束。游戏要有暂停功能，按空格键暂停/继续。 视觉要求：整体风格可爱，背景用粉彩色系，小兔子和胡萝卜全部用HTML/CSS绘制，不要使用任何外部图片。所有代码加中文注释。 技术限制：请生成一个完整HTML文件，所有CSS和JavaScript都内嵌在一个页面里。这个提示词里有几个关键信息：目标用户（10岁小女孩）、操作方式（键盘左右键）、核心规则（得分、失败条件）、视觉风格（可爱、粉彩）、技术限制（不用外部图片、单文件、中文注释）。
第一版生成出来之后，基本能玩。兔子是一个用CSS画的圆脸，胡萝卜是橙色圆角块加绿叶，整个页面是那种奶乎乎的粉色渐变背景，小朋友看到第一眼就被吸引了。这里有个小经验：如果你想要AI生成的东西“可爱”，一定不要只写“好看”，而是写“适合10岁小女孩的可爱风格”“粉彩色系”“卡通圆润造型”。AI对风格关键词非常敏感，但泛泛的“好看”它理解不了。
2.2 迭代原则：一次只改一个点
第一版能跑，但不完美。比如没有计分显示、没有音效、手机屏幕上不能玩、游戏结束之后没有重玩按钮。这些功能我并没有一次性一起提，而是分成了好几个轮次，每轮只让AI加一个功能。
轮次大概是这样：
- 第一轮：基础移动和掉落，已经完成
- 第二轮：增加计分显示，接到胡萝卜分数加1
- 第三轮：增加金色胡萝卜，得分5分，并且掉落概率更低
- 第四轮：增加游戏结束画面，显示最终得分和重玩按钮
- 第五轮：增加音效，接到胡萝卜和炸弹时播放不同提示音
每轮沟通的时候，我都在开头加一句“请在现有代码的基础上修改，不要重写整个文件”。这句话非常重要——AI在重新生成全部代码的时候，很容易丢掉之前已经实现的功能。而局部修改的稳定性远高于整体重写。这跟真人团队改代码的逻辑其实很像：小步修改、频繁验证，比一次性大重构稳妥得多。
2.3 高效表达的三句式要求
跟AI提修改需求，我总结了一个“三句式”写法：先说目标，再说范围，最后加约束。
- 目标：请增加一个计分板，显示当前得分。
- 范围：只需要修改JavaScript部分，请不要改动现有布局和样式。
- 约束：不要重写整个文件，在现有代码基础上追加。
这三个要素缺一不可。只说目标不说范围，AI会觉得“那我干脆帮你重新写一遍吧”；只说范围不说约束，AI有时候会自作主张调整代码结构。如果希望改动越小越好，最后一句一定要加。我用这种句式提需求，AI改出问题的情况少了很多。
不太有效的是那种特别口语化的模糊描述，比如“能不能让它更好玩一些”“加分的时候能不能炫酷一点”。这种需求AI一顿操作猛如虎，最后大概率改出来一个跟原来不一致的版本。想要什么就具体说什么，哪怕觉得描述得有点啰嗦也没关系。
2.4 一个关键操作：保留完整代码再提修改
AI对话框的上下文长度是有限的，聊到后面，它可能会忘记前面的代码是什么样。这时候如果直接说“请增加一个暂停功能”，它有可能会凭空造一个不是你要的版本。
我的做法是，每次提新需求之前，把当前完整的HTML文件内容复制进对话框，然后再写需求。比如先粘贴200行代码，再写：
“以上是当前游戏代码，请在此基础上增加一个暂停功能：按空格键暂停游戏，再次按空格键继续。暂停时显示暂停遮罩。只修改JavaScript逻辑，其他不要动。”
把完整代码带过去之后，AI的修改准确率会高很多。这就相当于你给一个远程同事发了“当前代码文件在这里”再提需求，而不是凭空描述一段没上下文的功能。留档也有这个好处，我要改的时候，随时能拿到当前最新且能运行的版本，复制粘贴就能用。
3. 核心代码拆解：小游戏就是这么跑起来的
3.1 页面结构与纯CSS小动物绘制
整个游戏的HTML骨架非常简洁，三个大模块：游戏容器、玩家兔子、掉落物容器。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>小兔子接胡萝卜</title> <style> /* 样式部分 */ </style> </head> <body> <div id="game"> <div id="sky"></div> <div id="player"></div> <div id="items"></div> <div id="scoreBoard">得分：0</div> <div id="endScreen" style="display:none;"></div> </div> <script> // 逻辑部分 </script> </body> </html>兔子没有用图片，也没有用表情字符，而是纯CSS画的：一个粉白色的圆脸，上面加两个椭圆长耳朵，再用深色小圆点做眼睛。代码核心就是把一个div切成不同区域的border-radius，配合两个伪元素画耳朵。这样做的最大好处是零外部依赖——留档文件复制到任何一台电脑上都能原样显示，不会因为图片路径失效而白屏。
胡萝卜也是用CSS画的，准确说是两个div：下面一个橙色竖向圆角块，上面加绿色叶子的伪元素。为了区分普通胡萝卜和金色胡萝卜，金色版本就是换了配色和加了轻微发光效果。用纯CSS绘制游戏元素，对AI来说完全不是负担，但对项目的可迁移性帮助巨大。
3.2 玩家移动：键盘、鼠标、触屏一起支持
玩家的移动逻辑，其实就是在处理三件事：看懂输入、改变横坐标、限制边界。
键盘控制的代码是典型的事件监听加坐标修改：
document.addEventListener('keydown', (e) => { if (e.key === 'ArrowLeft') { playerX -= 12; } else if (e.key === 'ArrowRight') { playerX += 12; } else if (e.key === ' ') { togglePause(); } clampPlayer(); renderPlayer(); });鼠标控制的思路是让兔子的中心点跟随鼠标的横坐标：
document.addEventListener('mousemove', (e) => { playerX = e.clientX - PLAYER_WIDTH / 2; clampPlayer(); renderPlayer(); });触屏设备需要监听touchmove，并且注意在处理触摸事件时阻止页面滚动。这里有个好用的细节：把三种输入方式都实现之后，不同设备上的体验是一致的——电脑上用键盘和鼠标，平板上用触摸，完全不用为不同设备写多套界面。
边界限制是一个很容易被AI忽略的点。如果没有clampPlayer这个函数，兔子会被移出屏幕一半，看起来非常诡异。限制逻辑很简单：横坐标最小值是0，最大值是页面可视宽度减去兔子宽度。小游戏要跑在不同尺寸的屏幕上，这个边界必须用实时窗口宽度来计算，不能写死。
3.3 掉落物生成与统一游戏循环
掉落物的生成本质是一个定时任务。我让AI实现的时候，明确要求它用一个主循环（requestAnimationFrame）驱动所有移动，而不是开一堆setInterval。因为setInterval多起来以后，互相之间的节奏会乱，页面最小化再切回来的时候也会产生堆积。
生成逻辑大概是这样：每间隔一定毫秒数，往页面里添加一个掉落物元素，随机决定是普通胡萝卜、金色胡萝卜还是炸弹。概率上我设置成普通胡萝卜约75%、金色胡萝卜约10%、炸弹约15%。这样游戏既不会太无聊，也不会因为炸弹太多而显得不公平。
移动逻辑的伪代码：
function gameLoop() { const now = Date.now(); const delta = (now - lastTime) / 16; lastTime = now; for (let item of items) { item.y += speed * delta; renderItem(item); if (item.y > window.innerHeight) removeItem(item); if (checkCollision(player, item)) handleHit(item); } requestAnimationFrame(gameLoop); }这里引入delta是为了让移动速度跟帧率无关。不管屏幕是60Hz还是120Hz，游戏里的速度感知都是一致的。很多人看到“帧率无关”可能会觉得高深，其实原理特别简单：比如原来每帧移动10像素，在60Hz的屏幕上，每秒移动600像素；在120Hz的屏幕上，每秒就移动1200像素，明显快了一倍。用delta归一化之后，每帧移动量根据时间差调整，速度就能保持一致。这是AI生成代码时经常漏掉的点，但实际体验中差别很大。
3.4 碰撞检测：用矩形碰撞解决“接到了吗”
碰撞检测是这个游戏里最核心的逻辑。掉落物和兔子都是矩形元素，最简单可靠的方式是矩形相交判断。
function checkCollision(a, b) { const aRect = a.getBoundingClientRect(); const bRect = b.getBoundingClientRect(); return !( aRect.right < bRect.left || aRect.left > bRect.right || aRect.bottom < bRect.top || aRect.top > bRect.bottom ); }代码里的四个条件是“没有相交”的四种情况：a的右边界在b的左边界左侧、a的左边界在b的右边界右侧、a的下边界在b的上边界上方、a的上边界在b的下边界下方。四种都不满足，说明两个矩形有重叠区域，也就是碰撞发生了。
用getBoundingClientRect获取实时坐标，而不是用生成掉落物时记录的x、y值，这一个细节能避免很多“明明没碰到却判定命中”的诡异问题。我在调试的时候就踩过这个坑：AI用生成时保存的坐标做碰撞判断，但掉落物一直在移动，坐标早就变了，会导致判定位置和画面位置不一致。改成实时获取元素的矩形位置之后，问题立刻消失。
3.5 计分、加速与本地最高分
计分逻辑很直接：协调函数handleHit里根据碰撞到的对象类型来加不同分数。普通胡萝卜加1分，金色胡萝卜加5分，炸弹触发游戏结束。
难度递增的实现是每满一定分数就让掉落速度加快。我用的是“每10分提升一次速度”，每次提升非常小，保证玩家的紧张感是渐进式的，而不是突然变难。具体实现是维护一个speed变量，在得分之后判断目前分数属于哪个速度档位，然后更新speed。
最高分用localStorage保存。这是最简单的本地存储方案，游戏关闭再打开之后，最高分还在。代码只有两行：
localStorage.setItem('bestScore', bestScore);对于小朋友来说，能看到“历史最高分”的挑战感完全不一样。她玩到50分之后，下一次的目标就是超过50分。这种小小的成就感驱动，让这小游戏的寿命翻了好几倍。一个不起眼的本地存储功能，性价比其实很高。
3.6 音效：用Web Audio在浏览器里“演奏”
加音效的需求，一开始我以为要准备音频文件。后来发现Web Audio API可以直接用代码合成简单音效，完全不用加载外部mp3。
实现一个简短音效播放函数：
function playTone(freq, duration, type = 'sine') { const ctx = getAudioContext(); const osc = ctx.createOscillator(); const gain = ctx.createGain(); osc.type = type; osc.frequency.value = freq; gain.gain.setValueAtTime(0.1, ctx.currentTime); gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime + duration); osc.connect(gain); gain.connect(ctx.destination); osc.start(); osc.stop(ctx.currentTime + duration); }接到胡萝卜的时候播一个800Hz左右的短音，碰到炸弹的时候播一个200Hz的长音。因为是用振荡器合成的声音，代码量很小，不会给页面增加任何体积负担。
这里有一个大坑：浏览器为了防止网页自动出声干扰用户，音频上下文默认是“锁定”状态，必须等用户跟页面产生过一次交互之后才解锁。所以我在代码里加了一个初始化监听，第一次点击屏幕或者按下按键的时候，调用一次unlockAudio()，把AudioContext激活。不加这一步，音效在某些浏览器上就是不响，特别是iOS上的浏览器，几乎必现这个问题。这个坑我在实际测试的时候遇到了，花了一点时间排查，属实不能说浏览器做错了，配合就好。
4. 实测避坑：AI写出来的代码不一定一次就稳
4.1 速度忽快忽慢，原来是两个计时器打架
第一版实际跑起来之后，小朋友反馈说“有时候胡萝卜掉得好快，有时候又很慢”。我还以为是她的错觉，自己观察了一下，确实存在这个问题。
排查下来发现，AI第一版用了两个独立的setInterval，一个负责生成掉落物，一个负责移动掉落物。这两个计时器的间隔稍微错开，视觉效果上就会产生“一阵一阵”的变速感。再加上页面标签页切出去再切回来，浏览器对后台计时器的节流策略也会让掉落的节奏彻底乱掉。
解决方案就是前面提到的统一游戏循环：用requestAnimationFrame做唯一的更新入口，所有的位置移动都在这个循环里完成。生成掉落物的时间判断也用时间戳，而不是独立计时器。改完之后节奏稳定了很多。
4.2 手机浏览器动不了：缺了touch事件
电脑上玩得好好的，拿到平板上一试，发现触屏点了没反应。这个问题很明显：第一版代码只监听了mousemove和keydown，触屏设备上的触摸事件没处理。
加上touchmove和touchstart监听就能解决。但还有一个细节：触摸设备上滑动的时候，浏览器默认会滚动页面，需要加上e.preventDefault()阻止默认行为。有些AI生成的代码在preventDefault这个处理上做得不彻底，导致页面在游戏里滑动的时候会跟着上下动。把触摸事件整理干净之后，移动端体验基本就跟桌面端一致了。
4.3 音效不响：浏览器把音频锁了
音效功能刚加上的时候，在电脑上测试一切正常，换到手机上又没声音了。查了一圈资料，基本确认是AudioContext的自动播放限制策略。
浏览器在页面没有用户交互的情况下，不允许声音自动播放。即使游戏内部希望接到胡萝卜的时候自动发声，浏览器也会静音处理。解决办法就是前面说的，在任何一次用户点击或者触摸时，执行unlockAudio操作：
function unlockAudio() { if (audioCtx && audioCtx.state === 'suspended') { audioCtx.resume(); } } document.addEventListener('click', unlockAudio, { once: true });这个坑算是我留档经验里最值得写的一笔。以后再做什么网页音频功能，我会先考虑交互解锁的问题，再考虑音色效果。
4.4 AI改着改着就开始“自由发挥”
这是跟AI协作最需要警惕的问题。有一次我提需求说“请增加暂停功能”，AI给出的结果不仅加了暂停，还把整个背景、兔子造型、掉落物样式全部重新设计了一遍。乍一看确实更漂亮了，但小朋友明确表示不喜欢新的颜色搭配，而且旧的收藏功能也被搞乱了。
那次之后我养成习惯：每次需求后面都额外加一句“不要修改现有样式和布局。如果某次AI改得不对，直接让它撤销相关操作。”AI的自由发挥看上去是惊喜，在游戏开发里却常常是惊吓。做产品、做开发，控制变更范围永远是第一位的。
4.5 问题速查表
| 问题现象 | 可能原因 | 解决思路 | 核心操作 |
|---|---|---|---|
| 速度忽快忽慢 | 多个计时器互相干扰 | 统一为requestAnimationFrame循环 | 删除独立setInterval，用时间戳驱动 |
| 触摸设备无法控制 | 缺少touch事件 | 补充touchmove/touchstart | 监听触摸事件并preventDefault |
| 音效不响 | AudioContext被浏览器锁定 | 首次交互后解锁音频 | 用户点击时调用audioCtx.resume() |
| AI修改后功能丢失 | 未保留完整上下文 | 每次改前粘贴当前代码 | 给AI完整文件再提局部需求 |
| 碰撞判定错位 | 用旧坐标计算 | 实时获取元素矩形位置 | 使用getBoundingClientRect() |
| 接炸弹后还能继续 | 缺少结束与重玩逻辑 | 增加游戏状态控制 | 设置gameOver状态，显示结束界面 |
这张表我留档的时候就贴在项目目录里，下次遇到类似问题直接按表排查。有需要的读者也可以直接参照。
5. 留档不只是存档：后续怎么继续玩
5.1 留档记录了什么价值
“留档”这两个字听起来简单，但这个版本静态存档的价值在于：你可以随时知道某个阶段的产品长什么样、代码怎么写的、当时小朋友的反馈是什么。
我留档时做了三件事：保存了带日期的完整HTML文件、在文件头部写了几行注释记录版本信息和已知问题、挑了一张运行截图放进了同一个文件夹。这样即使以后代码改得面目全非，随时可以打开旧版本对比感受一下差异。
更重要的是，留档给小朋友递了一个认知入口。她能看到“这个游戏住的房子”长什么样——原来就是个文本文件，里面全是文字和符号，但打开在浏览器里就成了游戏。这种从代码到可视化产物的直观体验，远比给她讲一遍“什么是编程”来得有效。10岁小朋友自己就会问：“为什么这些文字能变成小兔子？”这就是很好的编程启蒙时机。
5.2 三个值得尝试的扩展方向
留了档，不代表项目就到此为止。这个基础版本其实给后续扩展留了很大的空间，我列了三个方向：
方向一：让掉落物从画面左右边缘斜着落下来。目前所有掉落物都是垂直下落，加上水平和垂直两个方向速度分量，关卡感会强很多。改动集中在掉落物的更新逻辑，不影响其他部分。
方向二：加入“金萝卜收集进入下一关”。每收集3个金胡萝卜就到下一关，关卡越高掉落速度越快，炸弹比例也越高。这是对整体难度曲线的优化，需要一个简单的关卡状态变量，代码量不大。
方向三：增加家庭排行榜。用localStorage保存前三名的名字和分数，每局结束之后如果进了前三，弹出输入框让玩家自己输入名字。这个功能对家庭场景特别合适，小朋友会拉着全家人轮流玩、互相比赛。
三个方向可以选一个先做，做完之后照旧留档。新的HTML文件就是V2版本，和V1放在一起，看到自己做出的东西一点点变丰富，对小朋友来说也是成就感。
5.3 带孩子动手改参数，第一堂编程启蒙课
这个项目做完之后，我不打算把它变成“大人的作品”然后跟小朋友说“这是给你写的游戏”。我更想做的是带着她一起改代码。
最简单的是让她找几个数字改着玩。比如代码里speed = 8，告诉她“这个数字越大，胡萝卜掉得越快，你改个15试试”，她在游戏里立刻能感受到速度变化。又比如炸弹比例是0.15，改成0.02，炸弹几乎不出现，游戏就变成了“无限接胡萝卜”的休闲模式。这种“改一个数字，游戏立刻变一个样”的即时反馈，比任何教材都能激发兴趣。
当然，动手改之前要提醒一件事：先复制一份文件再来改。对，这就是留档最初的意义。她手上拿着原版文件，随便改成什么样，都不会把原本能玩的版本弄丢。从这个角度说，留档其实是最好的版本管理教学。
老实说，让AI帮忙写这个小游戏，真正花时间的部分不是生成代码，而是想清楚规则、盯紧细节、反复调试。AI把“从想法到能运行”的时间压缩到了半小时以内，但离“成品”还是差着一截距离——那个距离要靠人来补：这里调一下手感，那里加一个反馈，小朋友说不好看就换风格。做给小孩玩的东西，大人的审美滤镜要放一边，孩子觉得好玩，比代码写得整整洁洁重要得多。这篇留档既是记录，也希望给同样想自己动手做小游戏的朋友一点参考。
