先说结论：让一次旅程完整闭环
舒适探索类提示词需要的不只是柔和的配色和安静的场景。还要给玩家一个可重复的动作、一条能看出前进方向的路线、一种宽容的恢复方式，以及一个容易辨认的终点。与其堆叠大量场景和氛围词，不如先写清这些规则，这样更容易检查第一版结果。
“苔玻湾航线”（Mossglass Crossing）是本文原创的纸面设计示例：一名划桨者、一处平静海湾、三道按顺序通过的浮标门，以及最后的隐蔽海湾码头。下文的路线、控制方式、示例提示词和预期状态都是虚构的设计材料。这里没有运行提示词，也没有提供游戏构建或试玩，因此示例展示的是如何描述并检查构想，而非已验证的可玩成果。
先把第一次旅程控制在几句话就能说明白的范围内。如果某个功能不会影响玩家下一步选择、路线状态、恢复方式或结局，就先不要放进第一版。
把平静氛围转成可执行的约束
不同创作者对“舒适”的理解可能不同。把它转成可检查的行为：不设计时器、伤害、燃料或进度丢失；浮标门宽阔易辨；恢复操作能把皮艇送回安全水域，又不会撤销已经通过的门。路线仍有先后顺序和目的地，但不会惩罚转向较慢的玩家。
在“苔玻湾航线”中，从出发点就能看见海湾码头，水道也没有岔路。每对浮标横跨航线。有效通过时，水面留下平缓的尾波，浮标轻轻起伏，作为反馈。反馈紧贴玩家刚完成的动作，因此无需计时器、分数、收集品、日志或复杂 HUD 来说明发生了什么变化。
这些只是本设计提案中的选择，并非所有舒适游戏都要遵循的通用规则。如果另一个构想依赖可选探索、社交互动或自由漫游，请先想清它们怎样影响玩家路线，以及怎样才算一个令人满足的停留点，再把它们加入设计。
先写规则约定，再写场景提示词
在描述岩石或芦苇等细节前，先定义玩家如何移动、什么算作进度、恢复操作会改变什么，以及旅程何时结束。明确通过方向和下一道门，可以避免后续浮标门被提前计数，也能防止反向通过时结果被悄悄改变。
| 规则 | 苔玻湾方案 | 预期反馈 |
|---|---|---|
| 初始状态 | 从出发点开始， routeProgress = 0，检查点设在出发点，完成状态为 false。 | 第一道门是下一个目标；沿着唯一水道前行，可以看见远处的海湾码头。 |
| 控制方式 | 按住 Forward 划行；Left 和 Right 控制转向；Back 让皮艇缓慢倒退；Recover 重新安置皮艇；Interact 用于最终码头交互。 | 每个按键只对应一种明确效果；转向本身不会增加进度。 |
| 按顺序通过 | 从接近方向穿过下一对浮标之间的空隙。有效的正向通过依次推进第 1、2、3 道门。 | 每到一道新门，进度只增加一次。反向、跳过或重复通过都不会改变进度。 |
| 反馈 | 有效通过时，浮标轻轻起伏，尾波穿过门间空隙。 | 玩家会看到与动作对应的轻微反馈；该设计无需数字 HUD。 |
| 恢复 | 碰到浅滩会让皮艇停下。使用 Recover 后，皮艇会被放到最近通过的浮标门旁边的安全水域；若进度为零，则回到出发点。 | 位置会改变； routeProgress 和完成状态不会改变。 |
| 结束与重开 | 只有当进度为 3 且皮艇位于海湾码头时，按 Interact 才会结束旅程。从任何状态重开，都会回到出发点、把进度设为零、清除完成状态并恢复出发点检查点。 | 提前到达码头不能跳过浮标门。重开后会回到同一个明确的初始状态。 |
状态变化可以用一句话概括：只有沿正向通过下一道门才会改变 routeProgress；Recover 只改变位置；进度达到 3/3 后，码头交互才会结束旅程。编写场景时，把这句话放在提示词旁边。
这张图是对设计中 2/3 状态的概念表现，不是游戏截图。它展示了如何用实体地标传达顺序进度，而不必过早添加计数器。
按三步编写提示词
把规则澄清、首次构建请求和后续修正分开。每段提示词都应说明输入、约束、预期输出，以及读者如何检查输出。下面前两段可以在尚无构建时改写使用；第三段只适用于已经观察到实际结果之后。
提示词 A：找出规则中的歧义
我正在规划一款名为“苔玻湾航线”的小型单人舒适探索游戏。这是虚构的设计简报，不是在描述一款现有游戏。
玩家从码头旁的皮艇出发。目标是从接近方向依次穿过三对浮标之间的空隙，最后在看得见的海湾码头进行交互。Forward 用于划行，Left 和 Right 用于转向，Back 用于缓慢倒退；Recover 会把皮艇移到最近通过的浮标门旁边的安全水域（进度 0/3 时回到出发点）；Interact 仅用于最终码头。沿正向通过下一道门时，routeProgress 增加 1。反向、跳过和重复通过都不会改变进度。恢复只改变位置，不改变进度。只有进度达到 3/3 时，码头才会结束旅程。Restart 会恢复出发点状态并清除进度与完成状态。
暂时不要设计场景或构建游戏。请返回：(1) 状态与转移表；(2) 任何含糊或冲突的规则；(3) 反向穿过第 1 道门、进度为 0/3 时尝试第 3 道门、通过第 2 道门后恢复，以及提前与码头交互时的预期结果。不要默默补造规则。把所有建议选项标为设计决策，而不是观察到的行为。先阅读歧义清单。在请求构建前，先自行决定任何尚未明确的选项；否则后续结果可能会遵循你原本无意采用的假设。
提示词 B：请求构建最精简路线
请根据这份设计规格，构建一个小型单人、第三人称、实时 3D 皮艇探索原型。场景是一处平静的石灰岩海湾，包括一个出发点、一条连续水道、三对宽阔的浮标门，以及最终的海湾码头。使用一位成年划桨者和一艘红褐色木质皮艇。第一版保持精简、易读。
重置时，把皮艇放在出发点，设置 routeProgress = 0、completion = false，并将出发点设为恢复点。按住 Forward 划行；Left 和 Right 转向；Back 缓慢倒退；Recover 将皮艇送回最近通过的门旁边或出发点的安全水域；Interact 用于最终码头。只有沿正向穿过下一道门的空隙，routeProgress 才增加 1，且每道门只计一次。反向通过、提前通过后续门或重复通过已完成的门都不产生效果。恢复只改变位置。只有在海湾码头且 routeProgress = 3 时，Interact 才会结束旅程。Restart 恢复完整的出发点状态。
有效通过浮标门时提供简单的非语言反馈，例如浮标轻微起伏、尾波穿过门间空隙。水道保持连续，并留出安全余量。排除计时器、伤害、燃料、收集品、岔路、NPC、天气、日志、资源系统、计分和额外任务。不要添加会改变进度或完成状态的机制。
请在原型旁简要重述控制方式和状态规则。如果某条规则无法实现或必须修改，请明确列出差异。除非确实完成构建并检查过，否则不要声称设计已实现或测试。这是尝试构建一个定义明确的原型请求，并不能证明工作区会按描述实现控制方式或浮标门逻辑。扩展美术或路线前，先把实际输出与规则约定逐项比较。
提示词 C：修正一处已观察到的不一致
仅当你已有实际构建并重复过同一项检查后才使用。不要编造观察结果。
可复现操作：[准确输入和初始状态]
书面约定中的预期状态：[进度、位置、完成状态]
构建中的观察结果：[实际发生了什么]
只修改纠正这一不一致所需的最小规则或控制方式。保留其余所有规则。编辑前，说明哪一处状态转移有误。编辑后，明确说明如何重复同一项检查。如果无法通过检查或运行构建来确认结果，请说明哪些内容仍未验证，不要报告成功。提示词 C 是可复用的修正格式，并不表示本示例真的出现过某种不一致。只有真实操作和结果才能填写观察字段。
手工推演一条路线，再进行检查
用一段简短流程检查书面规则是否彼此一致。这是对提案规则的手工推演，不是运行游戏或试玩。
| 步骤 | 玩家操作 | 预期状态 |
|---|---|---|
| 开始 | 从出发码头旁开始。 | 进度 0/3；出发点为检查点；完成状态为 false。 |
| 1 | 向前划行，穿过第 1 道门。 | 进度变为 1/3；第 1 道门成为最近的检查点。 |
| 2 | 转向并穿过第 2 道门。 | 进度变为 2/3；第 2 道门成为最近的检查点。 |
| 3 | 漂到浅滩边并按 Recover。 | 皮艇回到第 2 道门旁；进度保持 2/3；完成状态仍为 false。 |
| 4 | 向前划行，穿过第 3 道门。 | 进度变为 3/3；在码头交互前，完成状态仍为 false。 |
| 5 | 到达海湾码头并按 Interact。 | 完成状态变为 true，并出现平静的靠岸反馈。 |
预期流程为 0/3 → 1/3 → 2/3 → 在 2/3 时恢复 → 3/3 → 与码头交互后完成。恢复会改变位置，但不改变路线进度；只有正向通过全部三道门后，停靠交互才会改变完成状态。图片是这一提议结尾的概念图，并非游戏已完成的证据。
| 检查项 | 从已知状态开始的操作 | 预期结果 |
|---|---|---|
| 反向通过 | 在 0/3 时，从第 1 道门的远端反向穿过。 | 进度保持 0/3。 |
| 跳过前序门 | 在 0/3 时，向前穿过第 2 道门。 | 进度保持 0/3；下一道仍是第 1 道门。 |
| 重复通过 | 在 1/3 时，再次穿过第 1 道门或绕行后重过。 | 进度保持 1/3；下一道仍是第 2 道门。 |
| 进度为零时恢复 | 在 0/3 时碰到浅滩并按 Recover。 | 回到出发点；进度保持 0/3。 |
| 进度为二时恢复 | 在 2/3 时碰到浅滩并按 Recover。 | 回到第 2 道门旁；进度保持 2/3。 |
| 提前停靠 | 在 2/3 时驶近海湾码头并按 Interact。 | 旅程不会完成；进度保持 2/3。 |
| 重新开始 | 完成后重新开始。 | 回到出发点，进度为 0/3、完成状态为 false，并恢复出发点检查点。 |
读者可以用这些验收检查对照自己的构建。实际检查之前，它们只是根据已写规则推导出的预期结果，并非观察结果。
做一次基于证据的修订
如果实际结果与预期状态不同，请在修改提示词前记录初始状态、准确输入、预期结果和观察结果。然后只修改受影响的规则或控制方式，并重复同一操作。例如，如果有效通过第 2 道门后进度仍是 1/3，请先检查对通过方向和下一道门条件的描述，再考虑添加新地图或奖励系统。
在记录中将预期值和观察值分开。纸面推演可以说明规格内部一致，但无法证明生成的控制响应灵敏、浮标门容易通过，或玩家能理解反馈。如果还没有构建，就把观察结果留空，并将下一步视为计划。
把简报交给创作工作区
当前的 Free AI Game Maker 页面称，创作者可以用日常语言描述游戏构想、查看可玩的 2D 或 3D 结果、在 Workspace 中继续迭代，并在生成前查看页面显示的 Koin 费用和账户选项。这些是产品页面介绍的一般工作流程。该页面并未说明皮艇、按序通过浮标门、检查点恢复、本文所列的具体控制方式，也没有证明“苔玻湾航线”已成功运行。
把你自己的简短规则约定作为输入，然后检查工作区实际返回的结果。如果结果改变了通过规则、恢复状态、控制方式或完成条件，请对照上表评估差异，再决定修改提示词还是设计。功能类别名称只是宽泛的规划参考，并不保证这条具体路线会按描述构建。
把规则约定带入下一步
添加第二条路线或新活动之前，先检查五个要点：玩家动作、地标顺序、进度变化、恢复行为和结束条件。路线设计若能清楚说明这些内容，第一条请求就会明确，也能据此具体评估实际结果。
准备好塑造自己的游戏构想时，请打开 Free AI 游戏制作器。带上一份可供检查的简报，在工作区查看结果和当前生成费用；在亲自核实之前，把每个未经验证的机制都当作待确认问题。
常见问题
“苔玻湾航线”是一款可玩或经过测试的游戏吗？
不是。“苔玻湾航线”是原创的纸面教学示例。路线流程是依据本文规则手工推演的；没有提供提示词运行记录、生成的构建、用户会话或试玩。请把它当作规格练习，并在核实自己的构建后，再把控制方式或路线行为描述为观察结果。
皮艇反向穿过浮标门时，进度应该减少吗？
本设计中不会。只有正向通过下一道门才会增加进度；反向、跳过或重复通过都不会改变数值。如果你希望玩家后退时损失路线进度，请把它写成独立规则并说明触发条件和反馈，不要让浮标门的通过方向暗示这一机制。
皮艇碰到浅滩后，恢复操作应该改变什么？
这里的 Recover 只改变位置。在 0/3 时，它会将皮艇送回出发点；有效通过浮标门后，则把皮艇放到最近通过的门旁边的安全水域。进度和完成状态保持不变。如果你的游戏希望恢复时重置部分进度，请明确指出重置哪些状态，并增加对应检查。
平静的路线怎样才能仍然有明确目标？
用地标和结尾来建立目标，无需添加计时器。此例中，三对清晰可见的浮标门告诉玩家下一步去哪里，远处的海湾码头则标明旅程终点。宽容的恢复方式降低了转向失误的代价，局部尾波反馈能确认有效通过，也不会增加分数压力。
一段提示词能保证这条路线在游戏制作器中正常运行吗？
不能。官方产品页面介绍了从构想到可玩结果的一般工作流程，但并未验证这些皮艇规则，也不保证特定控制方式、浮标门或恢复机制会如何实现。请按书面检查项核对实际结果。如果尚无构建，就把提示词和检查描述为计划，而不是测试结论。
