SEELE AI 是一个基于多模态 AI 的网页游戏创作工作空间。用户可以从自然语言需求出发，创建并持续迭代 2D、3D 游戏原型。理解这类工具的关键，不是把它看成 “自动画图”，而是把它看成一条从需求描述到交互验证的原型生产流程。

游戏与静态图像的区别，在于状态会不会变化

一张静态图像可以完整表达角色造型、环境氛围、构图和美术风格，是很有价值的视觉成果。但游戏还需要处理玩家输入以及输入引发的状态变化。

例如，画面里出现角色、金币和出口，只能说明 “这里可能有一个游戏”。真正运行时还需要回答：角色怎样移动？接触金币后发生什么？收集多少金币才能打开出口？碰到障碍是否失败？成功和失败如何反馈给玩家？

从技术角度看，可玩游戏至少包含一个持续循环：

呈现场景 → 接收输入 → 解释操作 → 更新状态 → 输出反馈 → 进入下一轮

MDN 对游戏主循环的说明同样强调了 “呈现、接收、解释、计算、重复” 这一过程。只有画面而没有输入、状态更新和结果判断，得到的是视觉内容；当这些内容进入运行循环，玩家的行为能够改变系统状态时，才形成可玩的交互体验。

一句 Prompt 如何组织成游戏结构

在 SEELE AI 中，Prompt 更适合作为一份压缩后的需求说明，而不只是画面描述。写作者可以按玩家目标、核心动作、空间关系、对象状态、规则条件和反馈方式拆解想法，再据此组织一个短循环原型。

整个过程可以概括为：

Prompt → 场景与对象 → 规则与反馈 → 可玩结果 → 试玩迭代 → 验收

其中任何一层表达不清，都会影响下一层。例如，只写 “做一个太空游戏”，系统需要补全大量设计空白：是驾驶、射击还是探索？采用什么视角？怎样获胜？玩家受到攻击后有什么变化？这种 Prompt 可以用于寻找方向，却不适合作为稳定的原型需求。

更有效的方法，是把 “玩家在什么地方、控制什么、反复做什么、系统如何回应” 写进同一段话。

一个可复用的 Prompt 需求模板

下面是一条具体示例：

创建一个低多边形风格的第三人称 3D 小游戏。玩家控制一台月球勘探车，在环形陨石坑中收集 6 个蓝色能源晶体。WASD 移动，鼠标调整视角；场景中有两台沿固定路线巡逻的维修机器人，玩家碰到机器人后损失一点能量，并在出生点重新出现。收集全部晶体后，中央信标亮起，驶入信标区域即获胜。界面显示已收集晶体数量和剩余能量；拾取、受击、信标解锁和胜利都要有明显的视觉反馈。第一版只做一个关卡，不加入对话、背包和技能树。

这是一份需求模板，而不是经过实际执行并验证成功的结果。它的价值在于展示一个可玩原型需要哪些信息，不能据此推断某次生成的具体画面、性能或完成质量。

拆开来看，这段 Prompt 已经覆盖了游戏的主要结构。

“环形陨石坑” 和 “中央信标” 定义场景及空间关系；“勘探车、能源晶体、维修机器人、信标” 构成可交互对象。对象不只是模型，还带有状态：晶体可以由 “未收集” 变成 “已收集”，信标可以由 “关闭” 变成 “解锁”，玩家能量也会随碰撞改变。

“收集 6 个晶体”“碰到机器人后损失能量”“集齐后信标亮起” 属于规则。规则通常可以理解为条件与动作的组合：

当玩家接触未收集晶体时，将其标记为已收集，并增加计数；当计数达到 6 时，改变信标状态；当玩家进入已解锁的信标区域时，触发胜利。

“视觉反馈” 和界面信息则让这些内部状态对玩家可见。若晶体已经被收集，但画面、声音或计数都没有变化，规则可能已经执行，玩家却无法确认结果。反馈不是装饰，而是连接系统状态与玩家判断的接口。

最后一句主动排除了对话、背包和技能树。明确 “不做什么” 能够控制首版范围，避免核心循环还未得到验证，原型就承担过多系统。

从结构化需求到可玩结果

在这条流程中，首轮目标应是形成一个可以开始试玩的短循环，而不是直接追求复杂商业游戏的完成度。

场景决定玩家活动的空间；对象提供可观察或可交互的实体；规则管理对象之间的关系；反馈解释规则执行后的结果。四者结合后，玩家才能完成 “移动 — 发现目标 — 采取行动 — 得到结果 — 继续决策” 的循环。

可玩也不等于内容很多。一个只有几十秒流程的原型，只要输入有效、目标明确、状态能够变化，并存在成功或失败条件，就可以用于验证核心设计。相反，场景即使非常丰富，如果玩家不知道要做什么，操作没有响应，或者结果无法判断，也还没有形成清晰的可玩闭环。

SEELE AI 提供 AI Game Generator、Image to Game、3D Game Maker、Simulation Builder 和 3D Asset Editor 等入口，但不同入口最终仍需回到同一问题：生成的内容能否参与交互，交互能否构成可验证的规则循环。

迭代时，修改最弱的一环

第一版原型的意义是暴露问题。试玩后不宜立刻扩展大量内容，而应先判断问题来自场景、对象、规则还是反馈。

如果玩家经常找不到目标，可以调整路径、地标、镜头或目标提示；如果操作显得迟钝，应检查移动速度、转向方式、碰撞范围和相机跟随；如果规则能够运行但玩家看不懂，则需要加强计数变化、对象状态、受击表现或结束界面。

后续 Prompt 最好采用增量修改，而不是每次重新描述整个游戏。例如：

保留现有场景、角色和胜利条件。让未收集晶体增加轻微上下浮动和蓝色光晕；玩家首次接近晶体时显示一次简短提示；不要增加新的敌人或关卡。

这种写法明确了保留项、修改项和范围边界，更容易判断本轮修改是否解决了目标问题。一次只验证一个主要假设，也有助于避免美术、规则和难度同时变化后无法定位原因。

MDA 游戏设计框架将机制、运行动态与玩家体验联系起来。对原型迭代而言，这意味着不能只检查某条规则 “是否存在”，还要观察它运行后造成了什么行为，以及玩家能否感知设计意图。

怎样验收一个 AI 生成的游戏原型

验收不应只看截图，而要完成实际操作。一个基础原型可以从以下方面检查：

• 启动与输入： 游戏能够进入可操作状态，主要控制方式与 Prompt 一致。
• 核心循环：玩家可以执行核心动作，系统会持续更新相关对象和状态。
• 规则完整性： 收集、碰撞、计分、胜利和失败等条件能够正确触发，不出现明显冲突。
• 反馈可读性： 玩家能够分辨操作是否成功、当前进度如何，以及为什么获胜或失败。
•  边界与恢复： 角色离开有效区域、受到伤害或重新开始时，系统有合理处理。
•  范围一致性： 首版实现集中在约定的关卡和机制，没有因附加功能削弱核心体验。

还可以把验收条件写得更具体，例如 “新玩家不阅读额外说明也能发现第一个晶体”“收集数量与场景剩余数量一致”“胜利触发后不再继续累计分数”。这些都是项目要求，不代表未经测试即可确认的产品能力。

原型通过验收，只说明核心玩法已具备继续开发的价值。若要进入复杂商业项目，还需要专业工程、美术规范、性能优化、内容权利审查、设备适配和系统化测试。

FAQ

AI Game Generator 是否意味着完全不需要编程？

用户可以从自然语言需求开始，不必先完成传统工程搭建。但复杂规则、性能优化、设备测试和长期维护仍可能需要专业开发工作，因此不宜把它绝对理解为 “不需要代码”。

最小可玩原型至少要写清哪些内容？

至少写清玩家目标、核心动作、控制方式、关键对象、状态变化、反馈、结束条件和首版范围。美术风格可以简写，但 “玩家怎样影响游戏状态、怎样知道结果” 不能缺失。

可玩原型与关卡演示有什么区别？

关卡演示可以侧重场景和移动；可玩原型还需要目标、规则、反馈和可到达的结束状态。即使流程只有几十秒，只要这些部分能闭合，就比内容很多却无法判断结果的场景更适合验证设计。

为什么第一版不应该加入太多系统？

因为原型首先要验证核心循环。系统越多，变量越多，出现问题时越难判断是操作、规则、反馈还是内容造成的。先完成一个短而完整的循环，再根据试玩证据扩展更稳妥。

如何判断一个想法适合继续开发？

观察玩家是否理解目标、操作是否产生预期反馈、核心动作是否值得重复，以及成功或失败是否能够被清楚解释。原型的价值在于用实际体验检验假设，而不是只证明功能已经生成。

参考资料

• SeeleAgent — AI Agent for Games, Images, Video & 3D | Seele AI
•