1. 为什么用 Vibe Coding 做贪吃蛇是最合适的练手项目先说一个很多人误会的事情Vibe Coding 不是“敲两句话让 AI 把代码写出来、然后收工”这么简单。它更像“带着明确意图提需求、看懂 AI 给出的方案、在关键节点做判断和修正”的协作过程。你负责说清楚要什么AI 负责把骨架搭出来但你仍然需要知道怎么检查这个骨架站不站得住。这个系列第一期我已经把 Trae 的基本用法和 Vibe Coding 的核心思路捋了一遍。这一期直接用贪吃蛇来落地——因为贪吃蛇是所有小游戏里“性价比”最高的练手项目逻辑链条短画面简单但技术覆盖一点都不少。能锻炼到 Canvas 绘制、游戏循环、键盘事件监听、状态管理、碰撞检测、动态数组操作这些前端基础能力。做完一个能玩的贪吃蛇你对“AI 生成的代码到底要盯哪些地方”会有一个非常具体的概念。有人可能觉得贪吃蛇太基础拿 AI 来做有点杀鸡用牛刀。但我的看法相反Vibe Coding 最有价值的练习场景恰恰是这种“不难但细节多”的项目。因为项目本身可控你可以把注意力放在人和 AI 的协作节奏上——哪里该给出精确指令哪里可以放心交给 AI哪里 AI 给出答案后你必须自己再过一遍脑子。这种判断力只有通过完整做一个小东西才练得出来。2. 动手前的思路拆解先把规则说清楚再让 AI 动手2.1 贪吃蛇的底层逻辑其实只有四件事用 Trae 写贪吃蛇之前我建议你先自己在脑子里把游戏拆一遍拆得越清楚你的提示词就能写得越精准AI 生成出来的代码也就越接近一次成型。拆解之后贪吃蛇的核心只有四件事蛇是一串坐标点组成的数组头部的坐标决定了它的行进方向。每一帧通常是每秒 8 到 15 次往当前方向前进一步在头部加一个新坐标在尾部去掉一个坐标。吃掉食物的时候尾部不去掉蛇身就变长了。食物是随机在画布空白格上生成的一个坐标点。生成的时候要避开蛇身否则食物刷在蛇身上根本没法吃。游戏结束的判断有两个维度蛇头撞到画布边界或者蛇头撞到自己的身子。得分与速度挂钩每吃一个食物分数加 10 或 20速度适当提升让后期难度上去。这一套逻辑是纯游戏规则层面的不依赖任何工具。想清楚这四件事之后我们再来看用什么技术方案去实现它。2.2 为什么这次选 Canvas 而不是 DOM 元素实现贪吃蛇有两种常见的实现路径。第一种是用 DOM 元素画格子每个格子是一个 div蛇移动时改样式第二种是用 Canvas 画布在一张画布上重新绘制每一帧的画面。我建议用 Canvas原因有三点Canvas 的性能更好。贪吃蛇虽然格子不多但用 DOM 元素每走一步就要增删元素操作多了以后页面会明显卡顿。Canvas 只需 clearRect 然后重绘开销小得多。Canvas 的 API 更贴近“游戏开发”的标准思路。你用 AI 生成代码时AI 对 Canvas 绘图的标准写法掌握得非常熟练几乎不会出错。如果用 DOM 拼接反而需要跟 AI 沟通更多布局样式细节容易跑偏。Canvas 这个技术栈的通用性更强。做完贪吃蛇你想改成俄罗斯方块、打砖块Canvas 那套 draw、clear、requestAnimationFrame 的套路可以无缝复用。技术选型你在提示词里明确告诉 AI 就好一条指令的事但选型背后的考虑你得自己清楚。这是 Vibe Coding 里“人负责做选择、AI 负责做执行”的典型场景。2.3 给 Trae 的第一个提示词应该包含哪些信息很多人在 Vibe Coding 初期最容易犯的错是提示词给得太空。上来就一句“帮我做一个贪吃蛇”AI 确实也能写但出来的东西大概率是默认画布大小、默认速度、没有开始界面的基础版。你后面要反复改反而更慢。我把这个项目的需求文档浓缩成了一段提示词实际使用效果很稳定你可以直接参考用原生 HTML CSS JavaScript Canvas 做一个贪吃蛇游戏要求如下 1. 画布大小 400x400每个格子 20x20共 20x20 个格子。 2. 蛇初始在画布中央长度 3 格方向默认向右用深绿色方块绘制。 3. 食物用红色方块绘制随机出现在空白格上不能刷在蛇身上。 4. 用键盘方向键控制蛇的移动方向移动过程中不能反向掉头比如当前向右走时不能直接按左键。 5. 游戏循环使用 setInterval初始间隔 200ms每吃 5 个食物后加速一次间隔减少 20ms最快不能低于 80ms。 6. 蛇撞到边界或撞到自身时游戏结束弹出提示并显示得分。 7. 页面上显示当前得分和当前速度等级。 8. 加一个重新开始按钮点击后重置游戏。 9. 代码写完后用注释标出每个核心函数的职责。这段提示词包含了四个关键信息技术选型原生三件套 Canvas、核心参数画布、格子、速度、游戏规则食物、碰撞、反向掉头、交互要求按钮、重置。信息密度足够但又没有限制 AI 的实现自由效果最好。我把提示词贴在 Trae 的对话框里它一次性生成了一段完整的 HTML 文件代码。文件里包含 CSS 样式、HTML 结构和 JavaScript 逻辑全部在一个文件里方便直接打开验证。3. 核心环节实现解析AI 生成之后你应该重点检查哪些代码3.1 第一次看 AI 生成的代码先抓大结构别陷进细节AI 给出代码后不要急着复制粘贴到浏览器里就跑。先滚一遍确认大结构是否符合你的预期。一个结构清晰的贪吃蛇 HTML 文件通常长这样!DOCTYPE html html langzh-CN head meta charsetUTF-8 title贪吃蛇/title style /* 页面布局、画布样式、按钮样式 */ /style /head body div classgame-container div classheader span得分: span idscore0/span/span span速度等级: span idspeedLevel1/span/span /div canvas idgameCanvas width400 height400/canvas button idrestartBtn重新开始/button /div script // 游戏的所有逻辑 /script /body /html先看 canvas 元素的宽高是否和需求一致。再看有没有 score、speedLevel、restartBtn 对应的 DOM 元素。最后看 JavaScript 里有无明显的结构分区比如 config、state、functions、eventListener。结构没问题再开始运行。这一步我称之为“结构低扫”。不是逐行读代码而是看轮廓。你不需要完全理解 AI 写的每一行但至少要能看出它有没有按需求搭出对应的骨架。有了这个习惯后面 debug 的时候才有地方可以下手。3.2 核心函数逐个拆解AI 常用写法与检查要点我在实际项目里遇到的 AI 生成贪吃蛇代码可以说是五花八门但核心函数的写法高度一致。你不需要会写但要会看。游戏配置区AI 基本都会在代码开头用一个对象存配置。常见写法像这样const CONFIG { gridSize: 20, // 每格 20px cols: 20, // 横向 20 格 rows: 20, // 纵向 20 格 initialSpeed: 200, // 初始 200ms 一步 minSpeed: 80, // 最快 80ms 一步 speedStep: 20 // 每 5 个食物加速一次 };这个区域的检查重点是参数是否符合你提词里的设定。有些 AI 默认会把格子数算成 25 或者把初始速度设成 150你要是不检查后面体感就不对。蛇的移动逻辑蛇身数组是核心中的核心。AI 最常见的实现方式是let snake [ { x: 10, y: 10 }, { x: 9, y: 10 }, { x: 8, y: 10 } ]; function moveSnake() { const head { ...snake[0] }; switch (direction) { case right: head.x 1; break; case left: head.x - 1; break; case up: head.y - 1; break; case down: head.y 1; break; } snake.unshift(head); if (hasEatenFood) { // 吃掉食物时不删除尾巴蛇变长 hasEatenFood false; } else { snake.pop(); } }这里有个非常关键的检查点方向切换时能否反向掉头。AI 经常会漏掉这个限制条件。你直接在代码里搜 keydown 事件监听看看里面有没有类似if (newDirection left direction right) return;的判断。没有的话游戏玩起来蛇会直接穿体而过体验很糟糕。碰撞检测AI 写碰撞检测也容易出小问题。最基本的边界判断长这样if (head.x 0 || head.x cols || head.y 0 || head.y rows) { gameOver(); }检查的重点是边界条件用的是而不是。如果用蛇头走到最后一行的时候不会触发碰撞画面看起来就很诡异。自身碰撞的检测方式比较多样有的 AI 会用snake.some(segment segment.x head.x segment.y head.y)有的会用字符串拼坐标比对。这两种都可以能用就行不用纠结写法。食物生成食物生成的代码function generateFood() { let newFood; do { newFood { x: Math.floor(Math.random() * cols), y: Math.floor(Math.random() * rows) }; } while (snake.some(segment segment.x newFood.x segment.y newFood.y)); food newFood; }这段逻辑 AI 通常不会写错但有时候会出现do while循环没有布尔条件、直接死循环的情况。重点检查 do 后面的 while 条件里是否真的排除了蛇身坐标。游戏主循环AI 实现游戏循环一般用setInterval。代码大致是let gameInterval setInterval(gameTick, CONFIG.initialSpeed); function gameTick() { moveSnake(); draw(); }这里注意一个细节很多 AI 生成的代码会把 draw() 和 moveSnake() 的调用顺序搞反。正确的顺序是先移动、再绘制这样蛇头移动后的位置才能被正确绘制出来。如果顺序错了画面会慢一拍看起来蛇的反应不跟手。围绕这五个区域做检查基本能把 AI 生成代码的 90% 的问题拦截下来。剩下的问题要等实际运行才能暴露。3.3 从一次生成到可玩的游戏完整跑通流程实录这段记录一下我实际用 Trae 做这个项目的完整过程。你在自己操作时基本可以照这个流程走。第一步新建一个文件夹命名如 snake-game。用 VS Code 打开在 Trae 对话框里输入前面那段需求文档。它生成了一份 HTML 文件。这一步大约花 30 秒。第二步我在浏览器里打开这个文件发现能跑蛇会动食物会随机生成键盘方向键能控制移动。到这里一切符合预期。第三步我立刻测试了一个关键场景向右走的时候按左方向键。结果蛇直接掉头穿过自己的身体游戏结束判定没有触发。这就印证了我前面说的AI 很容易漏掉反向掉头的限制。我回到 Trae 对话框输入这样一句“蛇当前向右移动时不能直接按左键反向请加一个方向锁定的逻辑同时保证在游戏结束和暂停状态下方向键不会触发移动。”它很快就改好了代码再测试问题解决。第四步继续测试吃到食物后蛇身变长、分数增加、加速逻辑。结果发现一个有趣的现象每吃 5 个食物加速 20ms 的逻辑AI 用的是“速度等级 Math.floor(食物数 / 5) 1”然后 interval 每次重启时取对应的 speed。这个实现可行但注意一个坑用clearInterval后再setInterval重置游戏循环时如果同一个游戏周期里反复加速会出现多个 interval 叠加的 bug。最稳妥的做法是让加速逻辑只在吃到食物后的 resetInterval 里执行一次。这一点如果 AI 没处理好你可以在提示词里直接让它“确保 setInterval 每次都先 clearInterval 再重新创建”。第五步图形界面的微调我把蛇头的颜色和一个蛇身的颜色做了区分AI 写的代码里蛇头是深绿色蛇身是更浅一点的绿色视觉效果很直观不用改。页面背景、按钮圆角这些也让它顺手加了点 CSS 样式。这些属于纯偏好调整看个人喜好。整个流程走完大概用了半小时。其中真正让我花时间的地方不是代码量而是跑出问题之后怎么向 AI 描述问题。这其实就是 Vibe Coding 的核心能力——问问题的准确度决定效率。4. 用 Trae 做贪吃蛇的常见问题我自己踩过的坑和排查方法4.1 高频 Bug 速查表AI 生成代码不是万无一失贪吃蛇这种小项目里常见的坑我已经帮你整理成一个速查表问题现象根本原因排查方法蛇向右走时按左键直接掉头缺少方向锁定判断检查 keydown 事件里有没有方向互斥判断蛇头撞到边界但游戏没结束边界判断用了而不是检查碰撞条件里是否包含边界坐标本身食物生成在蛇身上随机坐标没有排除蛇身看生成食物的循环/递归条件是否检查了所有蛇身的坐标吃完食物后蛇没有变长unshift 了新头部但误删了尾部检查 move 函数里有没有根据吃到食物状态来决定是否 pop 尾部游戏一段时间后越来越卡setInterval 多次叠加检查每次重置时是否先 clearInterval 再 setInterval加速逻辑不生效或速度跳变用绝对值修改 interval 而不是基于基础值计算看 speed 计算是否有基础速度参与而不是用累积时间这张表是我把实际跑代码时遇到的问题汇总出来的不是猜测。大多数 AI 生成代码的常见缺陷集中在这几类你在测试的时候按表里列的场景逐项验证就行。4.2 让 AI 帮你 Debug 的正确姿势代码运行出 Bug 之后很多人会直接对 Trae 说“游戏有个 Bug帮我修一下”。这个问题太模糊AI 只能猜。我的经验是 Debug 的提示词要遵循三段式结构先说出现象再说出复现步骤最后给出一条“你认为可能的原因”。举一个实际例子。我在测试时发现蛇每次吃到第 5 个食物后速度并没有变快。当时对 Trae 输入的是游戏有个 bug蛇吃到第 5 个食物时应该加速但速度没有变化。我确认速度等级已经变成了 2但 setInterval 的时间间隔似乎没变。请你检查加速相关的代码尤其是 speedLevel 换算成 interval 时间的那部分逻辑。它定位到问题是代码里初始化 interval 时用的是CONFIG.initialSpeed但速度等级变化后没有重新用新速度去创建 interval。修复后就正常了。你可以看到这个提示词里面包含了复现步骤、现象描述、以及怀疑的方向。AI 在这种输入下定位问题的速度快得多。这也是同一个项目里AI 既能写代码又能 debug但效率取决于你怎么描述问题。4.3 一个值得留意的细节方向和坐标系的对应关系很多第一次做贪吃蛇的人会对坐标系感到困惑。Canvas 的坐标系是 x 轴向右、y 轴向下也就是说向右走head.x 1向左走head.x - 1向上走head.y - 1向下走head.y 1这里的 y 轴方向和数学课上的坐标系是反的很多新手在这里踩坑。如果你发现 AI 生成的代码里按下方向键的上下键时蛇的移动方向是相反的那大概率是 AI 在这两行坐标变换上写反了。这个问题的排查方法很简单。先在代码里找到方向切换相关的 switch 或 if 分支然后在浏览器里按上下键实际测试。如果方向反了你不需要理解整段代码只需要看head.y - 1和head.y 1这两个操作有没有和 up、down 对应正确。这是我在实操中见过较多的一类小 bug每次调试基本 1 分钟就能定位。5. Vibe Coding 做贪吃蛇的价值不只是做出一个小游戏5.1 人与 AI 的分工边界在这个小项目里看得最清楚做完这个项目你会发现一个有意思的现象AI 确实能写出整个游戏但过程中的关键决策——比如网格粒度定多少、速度曲线怎么设计、反向掉头要不要锁定、游戏结束时展现什么样的交互——都是你来定的。AI 做的是翻译把人话翻译成代码人做的是定义把体验描述成人话。翻译可能出错误但错误的等级都比较低属于“语法错误”或者“逻辑遗漏”这一级。而定义出了问题整个项目的方向就不对了。举一个具体的例子。你在提示词里如果只写“做一个贪吃蛇”AI 可能给你一个画布 800x800、速度极快、没有重新开始按钮的版本。这个版本技术上看不出毛病但体验上不堪一玩。你需要在提示词里明确“初始速度慢一点”“加重新开始按钮”“显示得分”这些需求就是在做产品定义了。人机分工这个思维结合在这个小项目里再合适不过。通过它建立起来的协作经验和判断标准之后移到更大的项目上也一样好用。5.2 从贪吃蛇到其他小游戏的扩展思路贪吃蛇做完之后这个代码模板的价值不会止步于此。换几个变量调整一下绘制逻辑就能做出一系列小游戏改成俄罗斯方块把蛇的坐标数组改成方块堆叠加上方块旋转逻辑碰撞检测从蛇头对蛇身变为方块对已落定方块。改成打砖块把蛇的移动逻辑改成挡板左右移动增加小球碰撞的向量运算食物逻辑变成砖块消除。改成飞机大战把蛇的方向键控制改成飞机的上下左右移动食物变成敌机碰撞判定变成子弹与敌机的距离检测。这些游戏的核心代码框架和贪吃蛇高度相似——游戏循环、输入监听、碰撞检测、绘制更新。你只要会用 Vibe Coding 写过一个贪吃蛇再做其他小游戏时会明显感觉到AI 给出的可复用底座是现成的你要做的只是描述新的游戏规则。5.3 继续学习的方向从游戏到真实项目如果你用小游戏练熟了 Vibe Coding 的节奏下一步可以考虑两个方向。一个方向是给游戏增加更多功能模块比如本地记录最高分、暂停与继续、移动端触屏控制。这些功能涉及的 API 会更多AI 的代码量也会明显增大这时候提醒词里描述需求的能力就更重要了。另一个方向是做一个管理后台类的页面比如一个简单的待办事项加数据统计页面。这类项目考验的就不再是 Canvas 绘图和游戏循环了而是 DOM 操作、状态管理、数据持久化。逻辑链条比贪吃蛇短但界面状态更多交互更杂。无论哪个方向核心方法论不变结构低扫、核心逻辑检查、复现步骤化提交 bug、把大需求拆成小提示词。这套方法练扎实了你在任何 AI 编程工具里都会比大部分使用者效率高出一截。在做这个项目的过程中我的一个明显感受是Vibe Coding 并不会让我们变懒反而要求我们在更高层级上保持专注。要盯着结果、盯体验、盯边界条件这些恰恰是代码里那些需要“认真对待”的部分。贪吃蛇不长但人手写一遍会消耗大量时间在重复代码上而交给 AI 做省下的时间正好用来反复打磨游戏手感。这大概就是 Vibe Coding 最理想的状态让工具的归工具让创造的归创造。