把想法变成测试，而不是愿望清单
你可以先定义一个可玩的循环，请求实现一个小版本，检查结果后再逐步增加内容，以此使用 AI 制作游戏。提示词是输入，并不能证明其中要求的功能已经实现。生成后更有用的问题不是“它看起来像不像游戏”，而是“玩家能否执行操作、达成目标、以可以理解的方式失败，并重新开始？”
本指南结合一个保留下来的、有记录的 SEELE 案例与一份独立的教学需求。案例已有可玩链接和录屏；本稿中的教学需求尚未生成或测试。把两者分开，才能避免将看似合理的流程误认为已经报告成功的案例。
有记录的僵尸生存案例能说明什么
原文章描述了一条 2026 年 10 月的 SEELE 生成记录，要求制作一款使用 Three.js 的第一人称僵尸生存游戏。请求功能包括指针锁定移动、枪械、装弹、瞄准、蹲伏、冲刺、拾取物和小地图。
原文章对结果录屏的说明指出，画面中可以看到第一人称武器视角、生命值与弹药 HUD、小地图、波次计数、敌人和拾取提示。21.5 秒的游戏录屏只覆盖第一波的一部分。这些可见元素不能单独证明装弹、蹲伏、所有拾取交互、完整五波流程或其他浏览器兼容性都正常。这是已公开案例的证据边界，并非一次新完成的实际测试报告。
该图片记录了这个具体项目通过提示生成的过程。
复制一份更小的首版制作需求
当射击游戏对第一次尝试来说包含过多相互影响的系统时，可以使用下面的教学示例：
教学示例，并非已经测试的版本：制作一个名为 Signal Run 的单屏俯视角浏览器游戏。玩家使用 WASD 或方向键移动，收集三块电池，并抵达可见的出口。显示电池计数和操作说明。一个障碍在两个固定点之间水平移动。接触障碍显示失败画面；没有收齐电池就抵达出口时，显示需要先收集电池的提示。收集三块电池并抵达出口时显示胜利画面。无论哪种结局，按 R 都可重新开始，并重置玩家、电池、计数器和障碍。使用容易辨认的占位图形。不要增加敌人、武器、存档、联网、额外关卡或支付功能。说明修改了哪些项目组件，并给出移动、收集、胜利、失败和重新开始的检查方法。
从需求到原型的阶段可以使用 SEELE 的提示式游戏创建流程。但请求的操作和重置行为仍必须在实际输出中验证，提示词的表述本身不能保证它们实现。
第一步：检查首个可玩循环
美化之前，运行目标版本并按照游戏内显示的操作进行测试。检查各个方向的移动，确认玩家不能离开游戏区域。收集一块电池后，再走过它原来的位置：计数器不应再次增加。
提前尝试出口并记录提示。完成收集路线并检查胜利；故意接触障碍并检查失败；两种结局之后都重新开始。如果障碍重置了而电池没有，应报告这一确切差异，而不是让 AI 笼统地“修复游戏”。
第二步：利用案例建立验证记录
每项功能维护四个字段：请求的行为、可用证据、观察到的行为和状态。在僵尸案例中，看得见的小地图属于证据；位置追踪是否准确，在测试前仍未验证。对于装弹，在能够记录弹药变化和装弹动作之前，它仍属于规格要求。
对 Signal Run 采用同样的标准。“请求了三块电池”不等于“三个独立拾取物都被正确计数”。不确定的项目应标为未验证，不要用语气肯定的说明填补空白。这份记录能让下一条提示更具体，也能向协作者可靠地说明当前版本。
第三步：修改一条规则并重新运行循环
保存可用版本后，只请求一项改变：将障碍移动速度降低 20%，同时保留移动路线和全部收集规则。从相同起点重复同一次穿越，比较时间，并重新测试两种结局。
如果一次无关的视觉修改导致移动失效，应恢复到已知可用版本并缩小请求范围。提供准确错误、目标环境、预期行为和最短复现步骤。不要在尚未解释清楚的故障上继续叠加大范围重写。
第四步：单独检查工程交接
可玩链接不等于交付源项目。依赖某个工具进行后续开发之前，应检查当前套餐的项目访问和导出选项。如果能够取得所需格式，保存带版本的副本，清点入口、源文件、素材、依赖清单、锁文件和运行说明。弄清哪些内容由工具生成、哪些是依赖，以及哪些需要单独的服务。不要随项目公开凭据、私有接口地址或账号令牌。
在独立的干净文件夹中，按照该引擎或框架的实际文档执行安装和运行命令。记录运行时版本及缺失依赖。在不依赖托管工作区的情况下，重复移动、收集、胜利、失败和重新开始测试。如果本地版本失败或无法导出，应记录这一限制；在线预览无法填补证据缺口。对于保留的僵尸案例，尚未确认源文件导出或本地运行成功。
第五步：准备范围明确、如实描述的分享
分享之前，检查干净加载、易读的操作说明、音频（如有）、键盘焦点和重新开始。根据预期用途审查当前工具及素材条款。声称支持第二种浏览器或设备之前，先进行测试。性能描述应对应明确的硬件和记录下来的方法，而不是根据嵌入视频看起来流畅就下结论。
使用上面的需求，在 SEELE 中开始自己的小型原型。请求更多内容之前，保存可用版本、准确提示词和测试记录。里程碑是一个经过验证的循环，而不是冗长的功能清单：新玩家能移动、理解目标、体验两种结果并重新开始。只有在创作者无需额外解释就能展示这个循环后，再增加关卡和更丰富的素材。如果项目需要在工作区外继续开发，应将源项目交接和干净环境本地运行作为独立验收关卡，而不是根据预览作出假定。
证据与验收矩阵
下表整理的是本文提出的检查项，并非已经完成的测试报告。
| 主张或任务 | 来源或需求已经说明什么 | 仍需检查什么 |
|---|---|---|
| 有录屏的生存案例 | 文章描述了一段简短游戏录屏，并指出其中可见的 HUD 和敌人元素。 | 不要根据短片推断完整游戏流程或浏览器兼容性。 |
| 可玩循环 | 教学需求提出了操作、目标、失败状态和重新开始。 | 在实际版本中运行每项行为并记录结果。 |
| 修改 | 工作流要求一次范围明确的改变。 | 应用修改后重复基线检查。 |
| 工程交接 | 交接是工作流中的独立阶段。 | 检查实际文件、配置说明和允许的使用方式。 |
常见问题
短游戏视频能证明整个游戏正常运行吗？
不能。它只能支持录制时间内可见的内容。即使 HUD 出现，也不代表所有底层规则都正确。应使用功能清单、可复现的输入和更长的针对性录屏来验证行为，并区分过程视频、外观预览和已完成的玩法测试。
我需要理解每一个生成的文件吗？
你需要具备足够理解，能够测试游戏、保护可用版本并找到相关修改。可以要求助手用通俗语言解释组件和假设。遇到不熟悉的引擎特定行为，应查阅当前引擎文档。不要仅因为解释听起来技术上有说服力，就接受大范围代码重写。
什么时候应该替换占位美术？
等游戏循环清晰、可重复之后再替换。每次替换一小组素材，并重新检查碰撞、比例、对比度、加载和使用权。好看的媒体有助于表达，但不能验证未经测试的机制。概念图应如实标注，不要把它当成可运行生成结果的截图。
选择下一个可玩里程碑的工作流程
如果只需一个能在浏览器里玩的短循环就能验证下一步设计，先用游戏制作工具。如果项目已有引擎、素材或代码库，先在现有环境里用助手完成一处范围明确的修改。把导出和素材清单与试玩记录放在一起，分别判断成果是否可玩、工程是否能移交。
