编写计时精准平台跳跃挑战的 AI 提示词

当精准平台跳跃游戏提示词写明移动、计时、失败处理和胜利状态的精确定义时，就更容易审查。从一条短路线开始，为每项操作规定时长，并先推演一次成功尝试和一次重置，再要求增加关卡或视觉润色。

本指南提供一套可复用的三阶段提示词模板，以及一个名为 Beatglass Crossing、可手动核对的示例。关卡和路线均为原创虚构设计。下方游戏提示词尚未提交；本文不声称存在可玩构建、玩家体验或测试结果。节拍推演是在明确假设下进行的纸面模拟。

聚焦一个计时跳跃问题

选择一个能回答单一设计问题的首个切片：玩家能否看懂循环开合的闸门，在安全格等待，并在闸门开启期间落地？角色只保留一名信使，路线只设两个缺口和一个检查点，目标是到达标记出口。范围收窄后，提示词便能明确计时规则，而不用让敌人、收集品和额外关卡淹没重点。

Beatglass Crossing 是本文创作的虚构 2.5D 横向关卡。其格子地图、节拍、闸门阶段和重置行为均为作者设定的假设，并非对现有游戏或实测移动系统的观察。

封面呈现了行动发生前的判断：当前闸门状态与预测落地状态不同。玩家无需查看分数、额外 HUD 面板或含义不明的强化道具，也能看出等待的作用。

写明节拍与落点约定

为位置和操作时长命名。在这个纸面模型中，每个水平格代表一个单位；“节拍”是离散的设计时钟，并不代表自然跳跃物理规律。每拍设为名义 60 Hz 下的六个固定步进，即 0.1 秒。路线只在信使进入闸门格时检查闸门。

操作约定也要写得同样明确。 向右跑 向右移动一格，并推进一拍。 等待 在安全格原地停留，并推进一拍。 向右跳 恰好移动两格、跨过中间一个缺口，并耗时两拍；这个简化操作会在抵达目的地时结算。闸门阶段为 节拍 mod 4。如果信使试图在闸门关闭时进入 x=7，或跑入缺口，则取消该次移动，显示受阻或坠落提示，返回最近的检查点，并将本次尝试时钟重置为节拍 0。设计中没有分数、生命值或收集品状态。

机制图聚焦于落地时的检查，而不是泛泛的跳跃画面。闸门格、空缺口、已落地的信使和阶段指示器，都对应书面规则中的同一状态。

分阶段编写提示词

提示词库应让修改更容易。先说明关卡和目标，再加入移动与计时规则，最后补充反馈和审查用例。下方三个提示词是可直接复制的模板，但尚未运行。未来用于构建前请替换方括号中的选项，并要求报告对应游戏中可见的状态。

提示词 1：定义可玩切片

创建一个名为[暂定名称]的虚构精准平台跳跃游戏切片。采用横向视角，关卡范围紧凑，从 x=0 延伸至 x=9。玩家控制一名信使，目标是到达 x=9。在 x=0–2 设置安全起点地面，x=3 设置一个格子的缺口，x=4–5 设置检查点平台，x=6 设置一个格子的缺口，x=7 设置计时闸门，并在 x=8–9 设置安全出口平台。玩家落在 x=4 时激活检查点。使用一个离散节拍时钟，并通过简单图标反馈显示当前位置、节拍、闸门阶段、检查点和获胜状态。不要增加其他缺口、敌人、收集品、分数或移动能力。先返回地图和初始状态，再添加美术。

第一轮先限制关卡规模，并指出后续审查者需要检查哪些状态变量。如果布局发生变化，应先更新格子地图，再修改移动规则。

提示词 2：规定移动和计时闸门

保留已确认的 x=0–9 关卡。只实现以下纸面设计操作：向右跑每拍向前移动一个安全格；等待在安全格停留一拍；向右跳在两拍内恰好移动两格，可跨过一个中间缺口。使用 phase = beat mod 4。x=7 的闸门在阶段 0 和 1 开启，在阶段 2 和 3 关闭；只在玩家进入 x=7 时检查。跳入 x=7 的动作在两拍结束时结算。如果进入时闸门关闭，或跑步将进入缺口，则取消移动，显示清晰的受阻或坠落提示，返回最近的检查点，并将节拍设为 0。不要增加连续惯性、可变跳跃高度、空中操控、蹬墙跳、其他闸门或第二套计时规则。为每种输入返回状态表。

这一阶段去掉“跳跃要精准”“时机要合适”等模糊说法，直接规定计时检查和重置状态，让审查者能将显示状态与书面规则逐一对照。

提示词 3：要求反馈和审查计划

保持已确认的关卡和规则不变。用四盏小灯显示当前节拍阶段；闸门开启时用青绿色表示，关闭时用红色表示；仅在安全落地后显示克制的落地闪光。到达 x=9 时点亮黄铜出口铃，并标记胜利。因闸门关闭而无法进入或坠入缺口时，给出一条简短反馈，然后恢复检查点并将节拍重置为 0。请提供：(1) 成功的输入/状态推演；(2) 未等待而失败的推演；(3) 检查点恢复推演；(4) 涵盖两个缺口、闸门开闭时进入、阶段重置和出口的验收用例。将预测与观察结果分开。除非实际检查过有记录的构建，否则不要声称用例通过。

同时要求状态推演和验收用例，有助于在增加第二个关卡前发现矛盾。如果后续构建的操作或计时不同，应记录实际版本并修订约定，不要悄悄改动预期表格。

手动核对 Beatglass Crossing

成功路线为 跑、跑、跳、跑、等待、跳、跑、跑。由于一次跳跃耗时两拍，应记录结束阶段，而不只是起始阶段。

在 x=5 立即起跳会于节拍 7、阶段 3 结束，因此入口受阻且本次尝试重置。等待会让时钟推进到节拍 6；随后两拍跳跃在节拍 8、阶段 0 抵达 x=7。只有时钟计入跳跃的两拍，这条路线才能按描述成立。

成果插图描绘的是虚构且经手动推演的终态。它不是游戏构建的截图；铃铛是视觉目标提示，并非测试已完成的证据。

定义检查点重置

重试需要完整的重置状态。如果玩家在节拍 7 闸门关闭时尝试进入，就恢复到 x=4 的检查点，并将时钟重置为节拍 0。随后可按以下路线恢复： 跑、等待、跳、跑、跑：抵达 x=5/节拍 1，等待至节拍 2，跳到 x=7 时为节拍 4/阶段 0，然后跑过 x=8，在节拍 6 到达 x=9。检查点位置和时钟重置缺一不可；保留节拍 7 会导致闸门状态不同。

坠入缺口后也使用相同规则。取消失败操作，显示原因，恢复最近的检查点，清空本次尝试时钟，并保持关卡几何布局不变。这样失败才有助于玩家了解要调整哪条规则，并从明确状态重新尝试。

未来进行试玩时，应记录确切输入序列、起始检查点、节拍、闸门阶段和返回位置。本文只根据所述表格重新推演路线；没有记录任何游戏体验。

将推演转为验收检查

增加内容前，先把纸面模型转化为可观察的问题。以下是为未来构建拟定的验收检查，并非已取得的结果。

实际结果可用后，应将其记录在预期状态旁，并保留构建版本。如果检查失败，每次只修改一条规则，例如闸门周期或跳跃时长，然后重新推演成功和失败路线。不要把手动表格称为测试结果。

将需求带入游戏制作流程

提示词说明了一个小型首要操作和明确目标后，就可以把需求带入游戏制作流程。目前官方 Free AI Game Maker 页面介绍了使用自然语言描述游戏、生成可玩的 2D 或 3D 初版、在浏览器中测试，以及通过后续提示词改进。该流程提供免费 Koins，并要求创作者在每次生成前查看费用。这些是一般流程信息，并不能证明 Beatglass Crossing、其计时规则或本文提示词已实际生成。

未来迭代时，应将审查过的构建与提示词中的地图、控制约定、阶段表和重置状态进行比较。每轮只提出一项具体修改，例如让开启的闸门更醒目，或在重置后显示检查点。在确认某项规则已实现前，先检查实际结果和行为。

后续审查应围绕已说明的地图、移动约定、闸门阶段、重置状态和胜利条件展开。后续构建可能与纸面示例不同；先记录实际表现，再决定要修改哪条规则。

从一条可审查的路线开始

从这段单一计时穿越开始，要求提供状态推演，并将结果与列出的约定比较。细节明确后，再选择一项修改用于未来迭代。Beatglass 的数值仍只是虚构且手动推演的教学模型，不能证明游戏已生成。

将聚焦后的创意带入通用制作流程： Free AI 游戏制作器

精准平台跳跃提示词常见问题

怎样的精准平台跳跃提示词才算具体？

具体说明关卡位置、每项操作的移动距离和时长、计时规则、检查时机、失败反馈、重置状态和精确胜利条件。“让跳跃更难”没有说明构建应如何表现。简短推演可以在增加更多系统前，检验这些预期是否彼此一致。

跳跃是否应设定固定时长？

对于首个确定性纸面模型，应该：明确跳跃距离、耗时节拍，以及能跨越哪些缺口。未来的游戏引擎可以采用连续运动，但那需要不同的约定和有记录的检查。本文的两拍跳跃只是设计假设。

应如何描述计时闸门？

说明闸门周期、开启阶段、关闭阶段，以及触发检查的确切事件。Beatglass 仅在进入 x=7 时进行检查，不会在跳跃中途改变规则。还应说明每项操作是否推进时钟，以及重置后恢复到哪个阶段。

进入闸门失败后应如何处理？

取消移动，显示受阻提示，返回最近的检查点，并将本次尝试时钟重置为节拍 0。明确列出位置和计时状态，方便推演重试过程。在本例中，没有分数、生命值或收集品状态需要额外重置。

Beatglass Crossing 已经构建或试玩了吗？

没有。关卡是虚构的，路线是在纸面上手动推演的。提示词模板尚未提交；本文不声称存在可玩构建、游戏测试或观察结果。生成图片是概念插图，不是游戏截图。列出的数值只描述这些虚构规则，不代表观察到的实际实现行为。