让 AI 做一个贪吃蛇 🐍 提示词写到什么程度才好玩？
前言
让 AI 写一个网页小游戏，现在已经不算难。难的是做出来以后，规则能不能正常玩、画面是不是你想要的，手机上用起来顺不顺手。
同样一句“帮我做个贪吃蛇”，AI 可能交出一个能移动的方块，也可能做出有开始界面、计分、暂停和重新开始的完整小游戏。差别通常不在提示词有多长，而在于需求有没有把交付、玩法、风格和完成标准讲清楚。
这篇咱们就拿贪吃蛇做例子，把一份提示词从“能生成”改到“能检查、能继续迭代”。
一、只说“做个贪吃蛇”还缺什么？
如果只给 AI 一句话，它还需要替你决定很多事：
- 游戏要保存成单个 HTML 文件，还是放进现有项目？
- 撞墙或咬到自己时，游戏结束还是可以穿过去？
- 吃到食物加多少分？蛇要不要变长？
- 游戏暂停、结束后，界面要显示什么？
- 手机用户通过什么方式控制方向？
- 你要的是像素风、简洁风，还是可爱卡通风？
AI 会尝试补齐这些空白，但它补出来的默认答案不一定符合你的想法。所以，提示词的重点不是一味加长，而是把会影响结果的决定提前说清楚。
二、把提示词拆成四个部分
做一个小游戏，可以先从下面四项开始：
| 提示词部分 | 要回答的问题 | 贪吃蛇示例 |
|---|---|---|
| 交付目标 | 要做什么，交付在哪里？ | 浏览器可玩的贪吃蛇，保存为 snake.html |
| 玩法规则 | 玩家怎么操作，怎样得分或结束？ | 方向键移动，吃到苹果加分，撞墙或咬到自己结束 |
| 视觉风格 | 页面和游戏元素长什么样？ | 浅绿色棋盘、可爱的蛇、红色蛇身 |
| 验收标准 | 怎么确认做完了？ | 能开始、暂停、重新开始，刷新后最高分仍保留 |
角色设定可以作为补充，但不需要编一段很长的履历。与其说“你是参与过某款大作的资深开发者”，不如直接说明需要什么能力：遵守现有代码结构、处理游戏状态、检查边界情况，并汇报实际验证结果。角色头衔不会自动保证代码质量，清楚的要求和验收才方便检查。
三、先看一个简单版本
下面这段提示词已经说明了游戏类型、交付方式和大致风格：
用 HTML 开发一个贪吃蛇小游戏，保存为 snake.html，可以直接在浏览器中打开。
游戏画面走可爱风格，整体使用绿色或浅绿色，蛇身使用红色。其他元素请围绕这个配色统一设计。它适合快速试方向，但玩法和边界还不明确。AI 可能会做出看起来不错的页面，却漏掉暂停、结束提示、手机操作或最高分记录。
另外，“其他元素请围绕配色统一设计”确实给了 AI 一定的设计空间；如果你希望它也能补充功能，就要再说清楚哪些功能可以自行决定，哪些规则不能改。
四、完整提示词：让功能、风格和验收对得上
下面是一份更完整、可以直接复制后修改的版本：
请实现一个可以在浏览器中直接运行的贪吃蛇小游戏。
【交付要求】- 如果是独立小游戏，使用 HTML、CSS 和 JavaScript 保存为 snake.html，双击即可在浏览器中打开，不使用外部依赖。- 如果是在现有项目中开发，先检查项目结构并遵循现有技术栈，不要擅自改成单文件。
【玩法规则】- 使用键盘方向键控制蛇移动，蛇不能直接反向进入自己的身体。- 吃到苹果后增加 10 分，蛇身增长一格，苹果出现在未被占用的位置。- 撞到墙或蛇自己的身体时结束本局。- 每吃到 5 个苹果提高一次速度，并设置合理的最高速度，避免游戏变得无法操作。- 提供开始、暂停/继续和重新开始操作。
【界面状态】- 开始前显示游戏标题和开始按钮。- 游戏进行中显示当前分数、最高分和操作说明。- 暂停时清楚提示当前处于暂停状态。- 游戏结束时显示本局分数，并提供重新开始按钮。- 最高分保存在浏览器本地，重新载入页面后仍然保留。
【视觉与设备】- 整体采用清爽的浅绿色主题，蛇身使用醒目的红色。- 蛇的造型偏可爱，棋盘、按钮和信息卡片保持统一风格。- 页面适配手机窄屏，并提供滑动控制；不要让棋盘或按钮溢出屏幕。
【完成检查】- 确认开始、暂停、继续和重新开始都能正常操作。- 确认吃到苹果后分数增加、蛇身增长，苹果不会生成在蛇身上。- 确认撞墙和咬到自己都会结束游戏。- 确认提速有上限，刷新后最高分仍然保留。- 说明修改了哪些文件、如何运行，以及实际检查过哪些项目；没有验证的内容请明确标出。这份提示词比简单版本长，但每个部分都能对应到具体行为。AI 不用猜游戏规则，交付后你也能沿着“玩法、状态、设备、存档”逐项检查。
五、为什么这份提示词更容易得到好结果？
把完整提示词里的要求和结果对应起来看，会更直观：
| 提示词里的要求 | 对结果的影响 |
|---|---|
保存为 snake.html，可直接打开 | 明确交付形式和运行方式 |
| 撞墙或咬到自己时结束 | 明确两种关键失败条件 |
| 每吃 5 个苹果提速，并限制最高速度 | 定义难度变化，也避免速度失控 |
| 开始前、进行中、暂停、结束分别显示内容 | 避免只有游戏画布，没有完整交互流程 |
| 浅绿色主题、红色蛇身、可爱造型 | 把审美方向转换成具体视觉约束 |
| 列出完成检查 | 让交付结果可以逐项核对 |
请注意，提示词能减少歧义，但不能保证 AI 一次就写对。比如最高速度是否合适，还是要实际玩过再调整；手机滑动手感也需要在目标设备上确认。
六、AI 交付后，别忘了自己验收
AI 说“完成了”，可以先按这张清单走一遍：
| 检查项 | 怎么检查 |
|---|---|
| 开始与重新开始 | 开始一局，结束后再开新局，确认分数和蛇的位置重置 |
| 方向控制 | 确认不能立刻反向进入自己的身体 |
| 吃到苹果 | 确认分数增加、蛇身增长，苹果没有出现在蛇身上 |
| 失败条件 | 分别测试撞墙和咬到自己 |
| 暂停与速度 | 暂停后蛇应停止；连续吃苹果后速度不能快到无法操作 |
| 最高分 | 创造一个高分，刷新页面，确认记录仍在 |
| 手机适配 | 用窄屏预览或手机实际操作，检查棋盘和按钮是否溢出 |
如果发现问题，反馈时带上操作步骤、当前现象和预期结果。比如：“游戏开始后连续向左移动，蛇撞墙时没有结束；预期是显示结束界面并停止移动。”这比单说“游戏有 Bug”更方便 AI 定位。
七、把这套结构复用到其他项目
小游戏可以这样写，普通网页功能也能套用。把玩法规则换成业务流程，把游戏状态换成页面状态就行：
【交付目标】我要实现什么？放进哪个项目或文件？
【功能规则】用户可以做什么？输入、状态变化和异常情况如何处理？
【视觉与设备】页面风格是什么？需要适配哪些屏幕或设备？
【约束】沿用哪些技术、文件结构和设计规范？哪些内容不要改？
【验收标准】完成后，我可以通过哪些操作确认功能符合预期？提示词不是越长越好。只要把会影响实现的关键决定讲明白，再把结果写成可以检查的标准，就已经比一句“帮我做得更好看”可靠得多。
总结
让 AI 做网页游戏，最容易漏掉的不是代码，而是规则、状态和完成标准。角色设定可以提供方向，但更重要的是明确交付目标、玩法细节、视觉约束和验收方式。
所以下次想让 AI 做一个贪吃蛇，不妨先想清楚：**怎么玩、什么时候结束、手机上怎么操作，以及怎样才算真的完成。**把这些写进提示词，生成出来的就不只是“能跑的页面”，而是一个你能继续检查和迭代的游戏。