★ FEATURED ARTICLE 最近我给自己立了一个每周打卡的规矩抽一个晚上用 Vibe Coding 的方式做一个小东西做完就分享过程不追求工程化也不追求上线只求把想法变成能跑的程序。第二期我选了贪吃蛇起因也很简单——它是各种编程教程里最经典的小游戏逻辑规模小反馈链路短非常适合用来验证“用自然语言生成可玩游戏”这件事到底能走多远。这篇文章就把这一次完整的过程写下来提示词怎么组织、AI 第一次生成的代码长什么样、跑通之后踩了哪些坑、又是怎么一轮轮迭代成型的。如果你也想用 AI 编程工具做类似的小游戏或者单纯想搞明白 Vibe Coding 的真实体验可以照着这份记录来一遍。1. 为什么把打卡第二期选成贪吃蛇1.1 贪吃蛇是一个“边界清晰”的练习场做小游戏最怕的不是代码写不出来而是需求说不清。很多游戏看似简单但实际上涉及场景、角色、物理碰撞、动画帧、音效、存档、关卡设计一大堆系统光提示词就能写到上千字。贪吃蛇不一样它的规则几乎每个人都能说清楚一条蛇在地图上移动吃到食物变长撞墙或撞到自己就结束。这种“规则简单但逻辑完整”的特点让贪吃蛇成了验证 AI 编程能力的理想标的。当我把它拆给 AI 工具时目标非常明确固定大小的网格地图蛇按方向键移动随机位置生成食物吃到食物后蛇变长、分数增加撞到边界或自身时游戏结束有重新开始按钮这些需求用几句话就能说完AI 理解起来不会跑偏。相比做一个“玩法丰富”的游戏贪吃蛇更适合做第一版演练原因很简单它能快速暴露 AI 生成代码里最常见的逻辑缺陷比如死循环、输入冲突、数组越界。1.2 别把 Vibe Coding 当成“完全不用想”Vibe Coding 这个名字给人一种错觉好像只要描述一个大概程序就能自己长出来。实际上真正跑过几次之后会发现它更像是“把写代码的一部分劳动转移成写需求、审代码、调参数”思考量一点没少只是思考的位置变了。举个例子直接对 AI 说“做一个贪吃蛇游戏”它能给你一个能跑的版本但大概率是简单到不能再简单的四方形、白底、没有分数显示。如果你想让它像样一点就得补充蛇头蛇身要有区分、食物要有形状、移动要有停顿感、按键不能太灵敏。这些细节都需要你在提示词里主动提出来AI 不会替你做产品决策。所以我做这次打卡前给自己定了一条原则不追求“一句话生成成品”而是把贪吃蛇拆成几个阶段用对话不断叠加需求让 AI 在每一轮只改进一个点。这样既方便观察它的修改是否有副作用也方便对照着学习核心逻辑。2. 开局准备AI 编程工具和一份能说清需求的提示词2.1 工具侧的准备新建项目的两种起点我用的是一款带对话式生成能力和代码编辑器的 AI 编程工具标题里提到的那款就是这次打卡的主角。它支持在应用内直接创建项目也可以打开已有文件夹。第一次做贪吃蛇我选的是“新建前端项目”的路径因为这种小游戏最适合跑成 HTML JavaScript用浏览器就能玩不需要配置 Python 环境和依赖库。新建项目之后最常见的问题是如何启动项目。这个环节各家工具略有差异但大方向是一致的AI 会帮你生成入口文件和基本目录结构你需要找到预览窗口或者本地开发服务器。我这里建议新手优先选择“打开预览面板”的方式而不是把文件下载到本地再用命令行跑因为前者能立刻看到效果方便快速反馈循环。启动问题的典型参数其实是端口、入口文件和静态资源路径。贪吃蛇这类纯前端游戏基本没有依赖只要入口文件被正确加载预览就能跑起来。如果遇到白屏先看控制台有没有 404 报错绝大多数情况都是文件路径写错了。2.2 我的第一版提示词和生成结果我不太提倡所谓“提示词咒语”复杂的模板只会让 AI 陷入过度理解反而不容易生成简洁代码。对贪吃蛇这种项目我用的第一版提示词很直接几乎就是口语化需求然后配合几条明确约束。请帮我做一个贪吃蛇小游戏用 HTML CSS JavaScript 实现运行在浏览器里。 要求 1. 20x20 的网格地图 2. 蛇用绿色方块表示蛇头用更深的绿色 3. 食物用红色方块 4. 用键盘方向键控制移动 5. 蛇吃食物后变长分数加 1 6. 撞到墙壁或自身时游戏结束弹出提示 7. 页面下方显示当前分数和最高分 8. 有“重新开始”按钮 9. 移动速度适中不要太快也不要太慢这份提示词没有写“用 canvas 还是 DOM”因为我想先看 AI 自己的默认选择。结果它选择了 Canvas 绘制的方案这其实是合理的选择20x20 网格用 Canvas 可以高效绘制方块坐标换算也直观。第一次生成的代码大概两百行能跑但问题不少。最大的问题是蛇移动速度固定不变而且按方向键时经常出现连续掉头的情况。这也印证了我之前说的第一版只能作为起点不能作为终点。2.3 一次生成就能跑的实用技巧想让 AI 第一次生成就接近可用有几个小技巧是可以复用的。第一明确技术栈。如果你不指定AI 可能会在原生 JavaScript、JQuery、Vue、React 之间随机横跳。虽然都能实现但文件结构和运行方式差别很大。贪吃蛇这种小规模项目直接指明“原生 HTML CSS JavaScript不要使用框架”最省事。第二把地图尺寸和视觉风格写成具体数字。20x20、方块边长 25 像素、背景色、蛇头蛇身颜色这些具体约束能大幅减少后续调整。你给的信息越像素级AI 就越不会自由发挥出奇怪的效果。第三要求“单一文件实现”。对纯前端小游戏单文件意味着预览最简单不需要处理多文件打包或路径解析出问题的概率也会小很多。我第一次就明确提出“所有代码放在 index.html 里”或者“CSS 和 JavaScript 与 HTML 分开但不要打包工具”两者效果都不错。第四不要急着让它一次做完所有功能。先把“蛇能移动、食物能生成、吃食物能变长”这个最小闭环跑通再加计分、重开、最高分。这样每一轮出错你都能快速定位是哪一步新增导致的。3. 关键逻辑拆解AI 生成的贪吃蛇到底在忙什么3.1 数据表示、移动与主循环很多人看 AI 生成的贪吃蛇代码第一反应是“代码量不大但不知道它在干什么”。这里我把它拆开讲。贪吃蛇的底层逻辑其实就三个部分蛇的数据表示、移动规则、碰撞检测。蛇的数据通常是一个数组每个元素是一个坐标对象比如[{x: 8, y: 8}, {x: 7, y: 8}, {x: 6, y: 8}]。数组第一个元素是蛇头后面是蛇身。移动的通用做法是计算新蛇头坐标把它插入数组头部然后根据是否吃到食物决定是否删除数组尾部的坐标。这段逻辑可以用一个很短的循环描述AI 写起来不费劲。但关键在于“移动间隔”的控制这也是 Vibe Coding 迭代里最常调整的数值。如果你让 AI 用for循环连续移动游戏会快到你根本按不过来正确做法是用setInterval或requestAnimationFrame配合时间戳。// 核心数据 let snake [{ x: 10, y: 10 }]; let direction { x: 1, y: 0 }; // 当前移动方向 let nextDirection { x: 1, y: 0 }; // 待生效的方向 let food null; let score 0; let highScore 0; let gameRunning false; let gameLoop null; const gridSize 20; const cellSize 25;移动计算很简单蛇头坐标加上当前方向向量就是新头部坐标。比如方向是{x: 1, y: 0}那就向右移动一格。插入头部后如果新头部坐标和食物坐标相同就说明吃到了蛇身长度不变分数加 1重新生成食物如果没吃到就弹出尾部一格保持总长度不变。这段逻辑虽然短却是整个游戏的基石。AI 生成的第一版往往能写对但也容易藏一个隐患数组操作顺序不对可能导致吃食物时蛇身长度不变或者反而缩短。我建议你把主循环代码看一遍确认“先插头、后判断是否吃食物、再决定是否删尾”的顺序没有颠倒。3.2 输入延迟与“转向锁”贪吃蛇常见的体验问题是“按方向键反应太灵敏”或“蛇原地掉头”。这两个问题其实都出在键盘事件处理上。如果你直接监听keydown事件后立刻改变direction手机或者某些环境里连按两次方向键蛇可能还没来得及移动一格方向就连续变了两次结果直接撞到自己。标准解法是引入“下一帧方向”缓冲。键盘事件只更新nextDirection不直接改direction然后在主循环的移动步骤里先做合法性检查再把nextDirection赋给direction。如果用户按了相反方向——比如当前向右按了左键——就要忽略这次输入因为蛇不能 180 度掉头。这一段 AI 第一次生成的代码往往不会自动实现。你要么在提示词里明确写“按方向键时不允许反向移动”要么生成后再手动修改。我当时第二次迭代就遇到了连按掉头的问题最后让 AI 加上了一组逻辑判断它具体实现是这样的function trySetDirection(dx, dy) { // 不允许设置与当前方向完全相反的移动 if (direction.x dx 0 direction.y dy 0) { return; } nextDirection { x: dx, y: dy }; }这个判断用了一个很巧妙的数学特性两个相反方向向量相加等于{x: 0, y: 0}。所以只要检查新方向和当前方向相加是否为零向量就能阻止掉头。很多初学者一开始会写四个 if 分别判断上下左右其实这一行的逻辑更干净。3.3 碰撞、食物与分数碰撞检测分三种墙碰撞、自身碰撞、食物碰撞。墙碰撞最简单判断新蛇头坐标是否超出网格边界。这里有一个产品决策是“撞墙死亡”还是“穿墙穿越”。经典贪吃蛇是撞墙就死但这个选择应该由你定而不是让 AI 默认。如果在提示词里没说AI 大概率会做撞墙死亡因为这是最经典的逻辑。自身碰撞稍微复杂一点它需要检查新蛇头坐标是否和蛇身数组里的任意一个节点相同。这里有个细节很容易被忽略判断自身碰撞时应该排除蛇尾。因为如果这一帧蛇没有吃到食物尾部会同时移动新蛇头到达的位置可能恰好是刚才蛇尾的位置这种情况在经典规则里是不该算死亡的。AI 生成的时候分不清“含尾碰撞”和“不含尾碰撞”多半会写成包含尾部导致蛇在高速移动时偶尔自己撞死。食物生成最容易被写坏的逻辑是“随机位置可能落到蛇身上”。如果 AI 生成的是food { x: random, y: random }没有任何检查那食物刷在蛇身上的概率随着蛇变长而快速上升。正确做法是循环随机生成坐标直到找到一个不在蛇身上的空位。更稳妥的方式是维护一个空白格子列表随机取一个。后者在蛇很长时也不会陷入死循环。分数和最高分相对简单但要提示 AI 使用localStorage保存最高分否则刷新页面后最高分会清零。我第一次没指定AI 只做了“当前分数”显示后来才补上localStorage版本。4. 第一版跑通后我踩过的三个典型坑4.1 食物刷在蛇身上导致的死循环第一版生成后我玩了一会儿发现一个问题有时候吃不到食物地图上明明还有很多空位。打开控制台看到一条报错是那个随机生成食物的函数里出现“超过最大调用次数”——其实就是死循环了。检查代码发现它是用setInterval每秒钟调一次食物生成函数每次随机坐标然后判断是否与蛇身重叠重叠就重新随机。这种写法在蛇短的时候没问题但蛇吃到一定长度后就会频繁碰撞。更糟的是它的循环条件写成了while (isOnSnake(food)) { randomFood(); }当蛇身充满大半张地图时随机撞空位的概率变得很低函数就会卡很久表现为游戏“卡顿”。解决方案是把随机生成改成从空白格子列表里取样或者虽然还是用随机循环但要加上最大重试次数作为兜底。这个坑让我意识到一个问题AI 生成的看似合理的随机算法可能无法应对极端情况。我后来在提示词里强调“地图剩余空间越少食物生成速度也要越快不能有明显卡顿”它才换成空白格子列表方案。4.2 快速连按方向键蛇原地掉头第二个坑就是前面提到的转向锁问题。第一版里我按“下”再快速按“左”再接“上”蛇没有按照我期望的“下→左→上”的轨迹走而是直接掉头撞向自己。原因是键盘事件里的方向更新是即时生效的上一帧方向还没在画面上体现出来方向就已经被改成了相反方向导致蛇头在移动之前就先“转身”。修复办法就是我之前说的trySetDirection缓冲方案。不过这里还有一个小坑缓冲区只能保存一个待生效方向如果你在极短时间内连按三四个方向中间的方向会被丢掉这也是合理的行为因为蛇每帧只能移动一格强制记录所有按键反而会形成幽灵输入。对玩家来说“当前方向 下一个方向”的缓冲已经能满足大部分手速场景。我当时的完整体验是加了转向锁之后手感依然稍微有点“粘”。进一步查的原因是键盘事件触发频率高于移动帧率虽然方向更新已经缓冲但玩家按键的体验是“每次按下都有反应”。要做到“按下立即显示出蛇头朝向变化”比较难因为 Canvas 绘制本身是按帧刷新的。对于贪吃蛇这个游戏来说可感知的延迟大约在 30ms 以内已经很难察觉所以我没有继续优化。4.3 速度参数没调好导致“难度曲线”失真贪吃蛇的另一个常见问题是速度固定。如果 AI 生成的是固定setInterval(100)那 100 毫秒移动一格前期太慢后期又显得单调。真正的贪吃蛇通常会让速度随分数增加而小幅提升。我让 AI 改成“基础速度 150 毫秒每吃 5 个食物减少 5 毫秒最少不低于 50 毫秒”。这个参数比固定速度好玩得多但我也踩了一个实现细节的坑setInterval的时间间隔一旦设定了就不能动态修改只能先clearInterval再重新setInterval。如果 AI 写的是“改一个变量就行”实际运行根本不会生效。更好的方案是改用requestAnimationFrame或setTimeout递归每个循环里根据分数计算延迟。setTimeout这个方案实现起来最简单也很适合贪吃蛇function step() { if (!gameRunning) return; update(); // 移动蛇、检测碰撞、吃食物 draw(); // 绘制整个画面 const delay Math.max(50, 150 - Math.floor(score / 5) * 5); setTimeout(step, delay); }这段代码把延迟计算放在每一步之前分数变化后自然生效不需要手动重启计时器。AI 在一次对话里能想到这种写法但如果你不主动提速度曲线它大概率不会自动做。这类产品决策就是你作为 Vibe Coding 使用者必须提供的信息AI 不会替你决定游戏应该是什么手感。5. 从“能玩”到“像样”迭代的三个方向5.1 状态管理重新开始、最高分和暂停第一版能玩之后我做的第一轮迭代是把“重新开始”按钮、最高分和暂停功能补齐。这三个功能虽然都是新增但它们都属于状态管理核心思路是定义一个gameState把这些状态集中到一个对象里而不是散落在全局变量中。AI 生成的第一版把gameRunning、score、gameOver都当成全局变量一多起来就容易出现“重新开始后分数清零但蛇身没有重置”的 bug。最典型的问题是重新开始时调了生成食物函数但没清理本地存储里的最高分或者点击按钮后旧的setTimeout还在继续跑导致新旧循环叠加。修复的方式很简单也很有代表性重新开始时把蛇重置成初始数组、方向重置为初始方向、食物重新生成、分数清零并且确保旧的计时器被取消。这几件事必须全部执行缺一项就会出现奇怪现象。暂停功能在贪吃蛇里也很有实际价值尤其是你把游戏调快以后按方向键很有可能会误触暂停键。我用空格键控制暂停/继续keydown里监听空格但要注意默认行为是滚动页面需要用事件对象的阻止默认行为方法屏蔽掉它。5.2 视觉与反馈格线、配色和节奏贪吃蛇的视觉迭代其实是性价比最高的一环。因为它的玩法已经被市场验证过了你能做的差异化主要体现在视觉风格和操作反馈上。我让 AI 把纯白背景改成深灰色蛇身用“绿色渐变”而不是单色方块食物画成圆形每次吃到食物时有一个微小的缩放动画。这些改动本身不涉及复杂逻辑但能让游戏从“教学 Demo”升级成“能发朋友圈的小作品”。这里有一个细节值得所有 Vibe Coding 玩家注意视觉改动很容易引发逻辑回归。比如画蛇时如果用了“蛇头单独用更深的绿色”AI 可能会把蛇的数据结构从“一个数组”改成“头部对象 身体数组”导致碰撞检测写错。所以我的迭代习惯是“一次只改一个视觉点改完立刻玩一遍”。颜色、形状、动画分开调出问题也好定位。节奏上的调整同样重要。蛇移动速度、食物生成位置、每吃掉一个食物后分数跳动的文案都构成“感官反馈”。如果只是蛇身变长玩家会觉得平淡加上“分数 1”的动画和一个简短音效愉悦感立刻上来。声音我用的是一段很短的 Web Audio API 生成的嘀声没有额外引入音频文件避免了资源加载的问题。5.3 新增功能的取舍穿墙、障碍和变速到这一步基础功能已经齐了我开始考虑要不要加更多玩法。比较自然的三个方向是穿墙模式、障碍物、局部变速食物。穿墙模式实现起来非常容易新蛇头坐标越界时取模映射到对侧即可。玩法上从“求生存”变成“攀比长度”很多经典贪吃蛇二代的玩法就是这样。障碍物则复杂一点因为障碍物位置要么固定要么随机如果随机生成需要保证不会堵死唯一通路。局部变速食物是最有创意的方向比如地图上生成一个特殊食物吃掉后蛇身缩短三节这在长蛇局里有一种另类的策略感。但我最后只加了穿墙模式并且把它做成一个开关经典模式撞墙死穿墙模式穿墙过。障碍物和局部变速我决定留到后续打卡再研究。原因很简单贪吃蛇本体的逻辑已经稳定增加太多新系统会导致提示词越来越长AI 修改时更容易引入隐藏 bug。与其一次堆十个功能不如每次迭代只做一两个把质量做稳。6. 做完这版贪吃蛇我对 Vibe Coding 的理解变了6.1 提示词能节省的时间远低于调试能浪费的时间这次贪吃蛇打卡给我最大的冲击是这个事实用 AI 写代码代码生成只占十分之一的时间剩下十分之九都在“审代码、改逻辑、查边界”。提示词写得好能帮你少走弯路但不可能让你完全跳过调试。AI 代码的问题不是“看不懂”而是“看起来都对但一跑就错”而且错的往往都是边界情况。比如食物生成的死循环、方向上锁、最高分存储这些问题单看代码是很难一眼发现的必须通过实际游玩才能暴露。这让我想起以前手工写程序时的习惯永远不要因为代码短就觉得肯定没问题。AI 生成也是一样它对边界情况的处理能力取决于你是否在提示词里提供了足够多的场景。6.2 Vibe Coding 最合适的项目长度经过这一期打卡我对 Vibe Coding 适合什么项目有了更准确的感觉。它最适合的是“1-3 小时能完成、需求能被自然语言说清楚、反馈路径短”的小项目贪吃蛇恰好是其中最标准的代表。如果项目再大比如涉及后端数据库、多角色登录、复杂状态同步AI 生成的代码会显得非常脆弱因为你很难用几句话把所有业务规则说清楚它只能在每一个局部给你“看起来合理的代码”但在整体架构上会频繁做出互相矛盾的决定。这种情况下AI 更适合做为辅助搜索和代码补全工具而不是主导生成器。当然每种工具的边界都在快速变化也许过一段时间 Vibe Coding 就能承担更大规模的项目。但至少在现在拿它做小游戏、小工具、自动化脚本是体验最好、风险最低的入口。6.3 第三期打卡我会怎么选第三期我已经想好方向了做一个基于浏览器的小型节奏点击游戏核心玩法类似“跟着鼓点点击目标区域”但会加入可自定义的谱面逻辑。这个项目的复杂度刚好比贪吃蛇高一个台阶又不会高到需要依赖完整前端框架。它有明确的帧率循环、事件系统和状态管理正好可以继续检验 AI 工具在稍微复杂一点的逻辑下的表现。我还会继续坚持“一次只改一个点”的迭代思路并且每改完一轮就完整试玩几局。很多 Vibe Coding 玩家容易忽略的问题是AI 生成的代码如果长时间不实际游玩问题会不断累积最后一次性爆发时几乎没法定位。每隔几分钟就玩一把表面上是浪费时间实际上是最高效的调试手段。这次贪吃蛇打卡就到这里下一期更新的时候我会把节奏游戏的完整过程也写出来。如果你也准备用 AI 工具做小游戏我建议你从贪吃蛇或者扫雷这类游戏开始先把吃透提示词和代码审阅这两关过了再挑战更复杂的玩法。
阅读完成 · 觉得有帮助？
