一句话生成不了好游戏：AI 造网页游戏的 Prompt 方法论

把生成游戏的 prompt 当成一份迷你 PRD：用 8 段结构化骨架加一个完整示例，教你用一段提示词让 AI 一次生成能直接在浏览器里玩的 H5 游戏。

你有没有试过对 AI 说「帮我做个贪吃蛇」,结果拿到一个能跑、但没手感、没难度、手机上还点不动的半成品?问题几乎从来不在模型,而在你给的 prompt 太像一句愿望,而不是一份需求。

这篇文章讲的是:当你想用 AI(Claude、GPT 这类)一次性生成一个能直接在浏览器里玩的 H5 游戏时,prompt 到底该怎么写。核心结论只有一句:

把 prompt 当成一份「迷你产品需求文档(PRD)」来写,而不是一句许愿。

为什么一句话不行

「做个消消乐」这种 prompt,把太多决定权丢给了模型的默认想象:几乘几的棋盘?消除判定是三连还是四连?有没有连击?输赢怎么算?手机上怎么操作?美术什么风格?

模型只能替你猜。猜对一两个,猜错一大半,于是你得到一个「技术上能跑、体验上没法玩」的东西。你花在反复「不对,我要的是……」上的时间,远超一开始把需求讲清楚。

好的游戏 prompt,本质是把这些决定提前替模型做完。

一个可复制的游戏 Prompt 骨架

下面这套结构,是把一份产品需求书压缩成 prompt 的形态。照着填,基本就能一把生成可玩版本。

1. 一句话定义:类型 + 核心动词

先用一句话锚定它是什么。关键是点明玩家每一秒在做的那个核心动作(核心动词)。

「一个竖屏休闲游戏:玩家拖动弹弓把小鸟弹出去,击中目标得分。」

「拖动」「点击」「滑动」「拼接」——这个动词决定了整个操作体系,必须写死。

2. 核心玩法循环(最重要的一段)

描述从开始到得分/结束的那个循环,逐帧地讲:

  • 玩家看到一个 8×8 的字母网格,上方给出 emoji 提示
  • 玩家判断 emoji 代表的单词,在网格里找到它
  • 按住首字母拖到尾字母高亮选中
  • 选对则单词高亮变绿、对应 emoji 打勾
  • 找齐所有单词 → 通关结算

这段写得越具体,生成质量越高。核心循环是游戏的心脏,含糊这一段,后面全塌。

3. 操作与控制(PC + 移动端都要写)

这是最容易被漏掉、又最致命的一段。必须分别写 PC 和手机的操作:

  • PC:鼠标点击并拖动
  • 移动端:手指触摸拖动
  • 竖屏 / 横屏
  • 目标分辨率:自适应

漏掉移动端,你多半会得到一个「电脑能玩、手机点了没反应」的游戏——因为 AI 默认只绑了 mousedown,没绑 touchstart。

4. 胜负条件与进度

明确赢是什么、输是什么、怎么变难:

  • 赢:消除全部方块
  • 输:方块堆到顶部
  • 进度:每关网格更密、道具更少;计时挑战最佳成绩

没有明确目标的游戏不是游戏,是玩具。

5. 起步范围(MVP):先做最小可玩

这是专业和业余的分水岭。别让 AI 一次做完整个游戏,先圈定「第一版必须包含什么」:

第一版必须有: 单个 8×8 网格、5 个单词、触摸拖动选词、选中路径高亮、通关页 + 再来一局。 暂不做: 排行榜、皮肤、音乐、多难度。

先要一个能跑通完整一局的最小版本,再迭代加料。一口气要太多,模型容易每个都做一半。

6. 美术风格与「手感」(juice)

游戏好不好玩,一半在反馈。点名要哪些即时反馈:

  • 风格:干净、明亮、圆润,适合手机竖屏
  • 选中单词有高亮路径动画,通关有庆祝粒子效果
  • 每次消除有轻微缩放 + 音效反馈

「juice」(打击感 / 动画 / 音效 / 震动)不写,AI 默认给你一个能跑但「干巴巴」的版本。

7. 技术约束(决定它能不能直接部署)

这一段决定生成结果能不能直接丢到浏览器就跑:

  • 输出单个 HTML 文件,内联 CSS 和 JS
  • 不依赖任何需要后端的服务;如需库,用 CDN 且明确写出
  • 存档用 localStorage
  • 响应式,适配移动端 viewport

不写这些,你可能得到一个拆成十几个文件、依赖构建工具、还连着某个不存在后端的项目——根本部署不了。

8. 可调参数(为下一轮迭代埋钩子)

让 AI 把关键数值抽成一个配置对象:

把网格尺寸、单词数量、配色、计时开关等,集中成一个 gameConfig 对象放在顶部,方便调整。

这样你二次迭代时,改数值不用重读全部代码。

三个进阶技巧

① 两步走:先出 PRD,再写代码。 对复杂游戏,先让 AI 按上面结构产出一份需求文档,你审一遍、改几处,再让它「按这份 PRD 实现」。这一步能挡掉大部分方向性返工。

② 用负面约束堵默认坑。 直接告诉它别做什么:「不要用需要 API key 的服务」「不要用固定像素宽度导致移动端溢出」「不要把资源拆成外部文件」。

③ 迭代提示词要「定位 + 复现」。 发现 bug 时别只说「有问题」,要说「在什么操作下、出现什么现象」:「手机上快速连续点击两个方块时,选中状态不清除」。定位越准,修得越准。

最容易踩的 5 个坑

  1. 一句话许愿 → 半成品,反复返工。
  2. 不写移动端操作 → 手机点了没反应(只绑了鼠标事件)。
  3. 不写技术约束 → 多文件 / 依赖后端 / 用了外部资源,没法直接部署。
  4. 不写胜负和难度曲线 → 能动但没目标,玩两下就腻。
  5. 一次要全套 → 每个功能都做一半,不如先要 MVP 再加。

一个可以直接用的完整示例

帮我做一个单 HTML 文件的竖屏休闲益智游戏「Emoji 找词」。

核心循环: 8×8 字母网格,上方显示 5 个 emoji 提示;玩家判断每个 emoji 代表的单词,在网格里(横 / 竖 / 斜、正反向均可)按住首字母拖到尾字母选中;选对则该词高亮变绿、对应 emoji 打勾;找齐 5 个词即通关,显示用时并可再来一局。

操作: PC 鼠标拖动,移动端手指拖动;竖屏;自适应分辨率。

第一版必须有: 单网格 5 词、拖动选词、选中路径高亮、错误不惩罚、通关页 + 再来一局按钮。暂不做: 排行榜、音乐、多难度。

手感与美术: 明亮圆润、适合手机;选中有高亮路径动画,通关有庆祝粒子;每次找到词有轻微缩放反馈。

技术约束: 单个 HTML,内联 CSS/JS,不依赖后端;存档用 localStorage;响应式适配移动端 viewport。

可调参数: 把网格尺寸、单词数量、配色集中成顶部的 gameConfig 对象。

把这段丢给 Claude,你拿到的大概率就是一个能直接在手机上玩的完整版本——而不是又一个「能跑但没法玩」的半成品。

写在最后

AI 生成游戏的门槛,已经从「会不会写代码」变成了「会不会把游戏讲清楚」。而「把游戏讲清楚」这件事,恰恰是可以结构化、可以照着模板练的。

想看更多真实案例?PocketKit 的每一个 AI 生成游戏详情页,都附带了生成它所用的完整 prompt,可以直接复制去复现、改造或学习。挑几个你喜欢的游戏,对照上面这套骨架读一读,你会更快找到感觉。