我做过十几个小游戏 side project，前期浪费了大量时间在一件事上：
让 AI 直接帮我写游戏代码。
不是说 AI 写不了，而是我发现，用 AI 开发游戏和用 AI 写普通业务代码有本质区别。游戏逻辑充满隐式状态、帧序列依赖、边界 case——AI 在没有足够上下文的情况下，极容易生成"能跑但不对"的代码。
后来我重新设计了自己的工作流，把 AI 放在三个完全不同的角色上，开发效率提升不止一倍，返工率降低了大概 70%。
核心思路只有一句话：不同阶段，AI 扮演不同角色。策划期是设计搭档，原型期是执行工具，打磨期是 QA 测试员。角色混用，是大多数人卡住的根本原因。
下面逐阶段拆解，每个阶段都有可以直接复用的 prompt 模板。
// 目标：在动一行代码之前，把设计漏洞全部暴露出来大多数人跳过这个阶段，直接让 AI 开始写代码。这是最贵的错误。
游戏设计的坑，在代码层面修代价极高。一个 mechanic 如果在设计阶段就有根本性问题，写到一半才发现，你面对的是推翻重来还是打补丁的两难选择。
这个阶段 AI 的正确用法，不是让它帮你生成 GDD，而是让它扮演一个专门找你麻烦的设计审稿人。
"帮我设计一个类 Flappy Bird 的小游戏，要有障碍物、分数系统和难度递增。"
"我想做一个 Flappy Bird 变体，核心 mechanic 是点击加速而不是跳跃。请指出这个设计可能存在的手感问题、平衡性漏洞，以及玩家最可能在哪里感到挫败。"
第二种问法会让 AI 给你输出它认为的设计风险，你再逐条反驳或接受。这个"抬杠"过程本身，就是在做设计收敛。
我在策划期常用的三个 prompt 模板：
PROMPT TEMPLATE · 策划期 #1 — 机制压力测试prompt# 用途：暴露核心机制的设计漏洞 我在做一个 [游戏类型] 的小游戏，核心机制是 [描述机制]。 目标玩家是 [描述玩家，比如：休闲手游用户，单局5分钟]。 请从以下角度分析这个机制的潜在问题： 1. 手感层面：操作反馈是否清晰，容错空间是否合理 2. 平衡性：是否存在必胜策略或无解局面 3. 学习曲线：新手第一局最可能在哪里放弃 4. 技术实现难点：哪些地方代码容易写出 bug # 不需要给解决方案，只需要列出问题，我来决定怎么解决PROMPT TEMPLATE · 策划期 #2 — 数值系统预演prompt# 用途：在写代码前就把数值设计做稳 我的游戏有以下数值参数： - 玩家速度：[值]，障碍间距：[值]，难度增长：每 [N] 秒加速 [X]% 请帮我模拟以下场景的玩家体验： 场景A：新手玩家，反应时间约 400ms，第 30 秒时的局面 场景B：熟练玩家，反应时间约 200ms，第 2 分钟时的局面 判断这套数值是否会造成"太简单撑不到难"或"太难根本学不会"的问题。 输出：数值调整建议（用表格），以及你认为最关键的一个参数。PROMPT TEMPLATE · 策划期 #3 — 竞品差异化分析prompt# 用途：避免做一个"缝合怪" 我的游戏设定是：[一句话描述] 市面上最相似的游戏是：[列举 2-3 个] 请指出： 1. 我的设计和这些游戏的核心差异点在哪里 2. 如果玩家玩过这些游戏，他们对我的游戏会有什么错误预期 3. 有哪些"看起来是创新，其实是已知的坏设计"的地方 # 这个 prompt 会让你提前发现你以为的"创新"是否真的有价值当你能用一句话清楚描述"玩家做什么、为什么有趣、第一局结束时的感受"，策划期才算完成。如果你还在用"类似XX但是……"来解释自己的游戏，说明还没收敛。
// 目标：最快速度得到一个可以玩的版本，哪怕代码烂得没法看原型期最大的陷阱，不是 AI 写出了 bug，而是AI 写出了过度工程化的代码。
你让它"写一个障碍物生成系统"，它可能给你一个带工厂模式、配置注入、事件总线的完整架构——而你其实只需要一个setInterval每两秒push一个对象进数组。
架构越重，验证越慢，验证越慢，死在原型期的概率越高。
原型期让 AI 做架构设计是浪费时间。原型代码 90% 以上会被重写，你需要的是可以跑、可以感受手感的代码，不是可以维护的代码。
解决方法是在 prompt 里明确告诉 AI 进入"快糙猛"模式：
PROMPT TEMPLATE · 原型期 — 快糙猛模式声明prompt# 把这段话贴在每个原型阶段 prompt 的开头【原型模式】 这是原型代码，不是生产代码。 请遵守以下约束： - 不要使用设计模式，除非逻辑本身需要 - 不要写注释和文档，除非逻辑极其反直觉 - 不要做错误处理，假设输入都是合法的 - 不要抽象复用，允许重复代码 - 优先用最少的行数实现功能 - 优先用原生 API，不引入依赖 目标：让我 10 分钟内能跑起来感受手感。加了这段声明，AI 输出的代码量通常会缩减 60% 以上，而且更容易读懂和修改。
原型期最容易让 AI 翻车的三个场景，以及对应的 prompt 技巧：
碰撞检测 — 让 AI 先用 AABB，不要用像素级检测明确说"用矩形碰撞盒，容差设为实际尺寸的 80%"。AI 如果自己决定，可能会给你写一个精确但性能极差的方案，原型阶段完全没必要。游戏主循环 — 指定用 requestAnimationFrame，并告诉它 delta time 怎么处理很多 AI 生成的原型用 setInterval 做主循环，在不同帧率设备上表现不一致。prompt 里直接说"用 requestAnimationFrame，用 delta time 做帧率无关的物理计算"。状态管理 — 要求用一个全局 state 对象，不要用分散变量说"所有游戏状态放在一个叫 state 的对象里，包括 score、lives、speed、isRunning 等字段"。这让你在调试时能随时在控制台 console.log(state) 看全局快照，省掉大量找 bug 的时间。下面是一个完整的原型期 prompt 示例，以一个躲避类游戏为例：
PROMPT EXAMPLE · 完整原型请求prompt【原型模式】（见上方约束，此处省略） 用原生 JS + Canvas 实现一个躲避类游戏原型： 玩家：鼠标/触摸控制横向移动，始终在画布底部 80px 区域内 障碍物：从顶部随机 x 位置生成，匀速下落，宽 40px 高 20px 碰撞：AABB，容差 80%，碰到扣一条命（共 3 条） 难度：每 10 秒障碍物速度增加 15%，生成频率提高 10% 状态对象：{ score, lives, speed, spawnInterval, isRunning, obstacles[] } # 不需要：开始界面、音效、粒子效果、本地存储# 需要：能跑，有计分，有 Game Over 逻辑# 代码全部放在一个 HTML 文件里你实际玩了 5 分钟，能感受到"这个手感对不对"。如果你还在盯着代码而不是在玩游戏，说明原型还没完成。
// 目标：找出你自己看不见的体验断层和边界 case原型验证完手感，进入打磨期。这个阶段大多数开发者的做法是：自己玩，发现问题，改代码，再玩。
这个循环的问题是——你太了解自己的游戏了。你不会犯新手会犯的错，你不会在意老手觉得无聊的地方，你的肌肉记忆会帮你绕过所有设计缺陷。
这个阶段 AI 最有价值的用法，是让它帮你模拟你没有的视角。
PROMPT TEMPLATE · 打磨期 #1 — 新手视角模拟prompt# 把你的游戏逻辑描述或代码片段粘贴进来 以下是我的游戏的核心逻辑：[粘贴代码或文字描述] 请扮演一个从未玩过此类游戏的新手玩家，描述： 1. 游戏开始后的前 10 秒，他最可能看不懂什么 2. 第一次死亡时，他是否能理解死亡原因 3. 他最可能在第几秒放弃，以及放弃的直接原因 4. 他会误以为存在但实际不存在的功能是什么 # 不需要给解决方案，只需要给我问题清单PROMPT TEMPLATE · 打磨期 #2 — 边界 case 枚举prompt# 专门用来找代码里没有处理的极端情况 以下是我的 [碰撞检测 / 障碍物生成 / 分数计算] 逻辑： [粘贴代码] 请列举所有可能导致非预期行为的边界情况，包括： - 极端输入（速度为 0、负数、极大值） - 时序问题（两帧之间发生的事件） - 设备差异（低端机帧率 20fps vs 高端机 120fps） - 玩家异常操作（快速多次点击、同时按多键） 对每个 case，说明：出现概率（高/中/低）+ 会造成什么现象。PROMPT TEMPLATE · 打磨期 #3 — 游戏感 (Game Feel) 审查prompt# 游戏感是最难量化但影响最大的东西 我的游戏当前参数： - 玩家操作响应延迟：[值]ms - 死亡动画时长：[值]ms - 障碍物生成前是否有预警：[是/否] - 得分时是否有反馈：[描述] 参考游戏：[你想对标的游戏，如 Flappy Bird / Geometry Dash] 请对比分析：我的游戏在操作响应感、失败反馈感、成功奖励感三个维度上， 和参考游戏的差距在哪里，以及最小改动是什么。 # 所谓"最小改动"：不改代码架构，只调参数或加简单效果打磨期还有一个极度好用但几乎没人用的技巧：让 AI 帮你写测试剧本。
不是单元测试，是人工测试剧本——一份清单，列出你需要手动验证的所有场景，按优先级排序。
PROMPT TEMPLATE · 打磨期 #4 — 生成手动测试剧本prompt以下是我的游戏功能列表：[列出所有功能] 请生成一份手动测试剧本，格式如下： | 测试项 | 操作步骤 | 预期结果 | 异常风险等级 | |--------|---------|---------|------------| | ... | ... | ... | 高/中/低 | 按异常风险等级降序排列，我会从高风险开始测。 重点关注：多局连续游戏、从暂停恢复、极低分和极高分状态。把游戏给一个从没玩过的人，不说任何规则，观察他第一局。如果他能在 30 秒内搞清楚怎么玩，并且愿意主动开始第二局，打磨基本到位了。
整个工作流的核心逻辑是：
策划期：AI 是你的挑刺者不让它生成设计，让它否定你的设计。目标是在动代码前清空设计债。
原型期：AI 是你的执行工具明确要"脏代码"，用结构化的 prompt 约束它的输出范围。目标是最快感受手感。
打磨期：AI 是你的 QA让它模拟你没有的视角——新手、极端操作、不同设备。目标是找出你自己找不到的问题。
这套工作流不是银弹。AI 在游戏开发里依然有明显的能力边界：复杂的物理模拟、多人同步逻辑、音频系统——这些地方 AI 的输出质量会显著下降，需要你自己主导。
但在策划决策、快速原型、测试覆盖这三块，它能实实在在帮你压缩至少一半的时间。
最后一个反直觉的结论：用 AI 做游戏开发，让你进步最快的不是它帮你写的代码，而是它在策划期逼你想清楚的那些问题。很多时候，你以为自己在做技术决策，其实是在做设计决策。
你现在在做或者想做什么类型的小游戏？有没有在哪个阶段特别卡住过？
欢迎留言，我会在下一篇里选几个典型场景专门写。
// 觉得有用 → 点「在看」，转给正在做游戏 side project 的朋友
夜雨聆风
