用自然语言生成动作游戏时，很多人会先写：“角色在云端平台上不断向上攀登，躲避尖刺并到达终点。”这样的描述很容易生成天空、平台和角色，却不一定能生成一局真正可玩的攀登关卡。
平台可以看，不代表踩得住；角色会跳，不代表能稳定抓边；体力条会减少，也不代表归零后一定松手。要让关卡可测试，提示词必须把目标、运动、抓边、体力、动态障碍、坠落恢复和重开写成明确规则。
本文把第一版范围限定为：1 名玩家、30 段平台、3 个检查点、8 分钟时限和 100 点体力。每条规则都按照“数值—触发条件—可见反馈—失败处理—实现状态”来写，避免把概念画面误认为玩法完成。
图注：连续向上的平台适合表达攀登目标，但平台碰撞、抓边判定、体力消耗与坠落恢复仍需运行测试。静态图不能证明角色可控制、平台可踩、尖刺有伤害、检查点存在、体力会消耗或关卡能够完成。
第一条：先写清目标、平台编号和8分钟时限
“爬到最高处”只是视觉目标，不是系统能够判断的完成条件。生成工具可以据此搭出一条向上的路线，却不知道最高处对应哪个对象，也不知道玩家漏过检查点后是否仍能通关。
第一版可以这样定义：
玩家：player_01
平台：platform_01—platform_30
检查点：checkpoint_01—checkpoint_03
终点：summit_01
时限：480 秒
3 个检查点分别放在 platform_10、platform_20 和 platform_26 之后。玩家离开起点区域时开始计时，暂停期间计时冻结。
胜利必须同时满足：
- 3 个检查点按顺序激活；
- 玩家触碰
summit_01； - 剩余时间大于 0。
玩家只是经过检查点附近，不能自动取得进度。系统应要求真正进入激活区域，并播放声音、画面或 HUD 反馈，再把检查点状态写为“已激活”。
测试时记录：
platform_id | checkpoint_id | checkpoint_state
elapsed_time | remaining_time | game_state
有了平台和检查点编号，坠落后系统才能判断玩家应回到哪里，测试人员也能准确记录第一次失败发生在哪一段。
第二条：移动、跳跃和空中控制必须有数值
“操作灵活”“跳跃自然”都不是可执行规则。移动速度、跳跃高度、空中转向和二段跳会直接决定平台间距是否合理。
第一版可以先采用一组固定基线：
- 地面移动速度：5 米/秒；
- 单次跳跃目标高度：2.2 米；
- 空中转向能力：地面的 40%；
- 二段跳：关闭；
- 落地前重复按键：不再次触发跳跃。
这些数值不代表所有游戏的最佳答案，它们的作用是建立可复现基线。平台间距和高差必须用这套运动参数实际测试，不能只根据画面判断“应该跳得到”。
角色状态至少要区分：
idle | run | jump | airborne
land | hang | climb | fall | reset
角色从一段平台跳向另一段时，记录起跳平台、落地平台、起跳时间和落地结果。如果按下跳跃键后没有离地，应能区分输入未接收、角色不在地面、状态锁定或脚下碰撞无效，而不是统一归类为“跳跃失败”。
AI 生成的角色与平台可以帮助准备原型外观，但角色能否稳定起跳、落地，仍取决于角色控制器、碰撞体、平台间距和运动参数是否匹配。
第三条：抓边要同时检查位置、方向和站立空间
抓边不能简化成“手碰到任意物体就悬挂”。否则墙面、尖刺和终点装饰物都可能被错误识别，角色背对平台也可能突然吸到边缘上。
一次有效抓边至少需要同时满足：
- 手部或身体检测点进入带有“可抓边”标签的区域；
- 角色与边缘的距离小于设定阈值；
- 角色朝向与边缘法向的夹角处于允许范围；
- 边缘上方有足够空间容纳角色站立；
- 体力大于 0；
- 角色不处于受击、失败、复位或结算状态。
第一版应为距离与角度设置可调参数，并在调试界面显示实际检测值。具体阈值要根据角色胶囊、手臂长度和动画复测，不宜只凭角色模型外观填写。
失败时不要只提示“无法抓取”，而要区分：
- 距离不足；
- 朝向不符；
- 上方空间被占用；
- 对象不可抓取；
- 体力不足；
- 当前状态禁止抓边。
测试时，让角色从正面、侧面和背面接近同一边缘，再从不同高度落下。每次记录平台编号、检测点位置、角度、空间检测、体力和最终状态。
抓边成功后，角色必须进入明确的 hang 状态，普通空中移动应停止或按设计受限；向上爬到平台后，再切换为 climb 和 land。只播放一段抓边动画，却没有改变角色碰撞和运动状态，仍不能算抓边功能成立。
第四条：体力要真正约束悬挂和攀爬
体力条显示 100，不代表体力系统已经参与玩法。真正需要写清的是：什么动作消耗体力、消耗多少、何时恢复，以及归零后发生什么。
第一版可以采用以下固定数值：
- 最大体力：100；
- 悬挂消耗：每秒 8 点；
- 每次向上攀爬额外消耗：12 点；
- 安全平台恢复延迟：连续站立 2 秒；
- 延迟结束后的恢复速度：每秒 20 点；
- 暂停、失败、复位和结算期间：体力不变化。
体力归零时，角色必须松手并进入 fall 状态，不能继续悬挂，也不能在同一物理时刻立即吸附到另一条边。为避免边界抖动，还需要规定松手后的短暂禁止重抓时间，具体长度再根据操作手感测试。
日志不能只保存最终数值，还应记录变化原因：
player_state | stamina_before | stamina_delta
stamina_after | change_reason | timestamp
重点测试三个边界：剩余 1 点体力时的下一次更新、体力归零的瞬间、暂停后恢复游戏。只有 HUD 数值、角色状态和日志三者一致，体力规则才算真正连接到玩法。
第五条：移动平台、碎裂平台和尖刺要分开判定
三类动态障碍看起来都能增加难度，实际需要完全不同的状态规则。
移动平台
写明起点、终点、移动周期、等待时间和往返方式。角色站在平台上时，应正确继承平台位移，不能因为平台在物理更新和角色更新之间发生错位而被无故甩下。
碎裂平台
角色满足承重条件后才启动倒计时。倒计时结束时，裂开反馈、碰撞关闭和“不可站立”状态应由同一次状态切换触发。若平台本局不恢复，应明确写出；若会恢复，还要定义恢复时间和重置条件。
尖刺
伤害只由明确的有效碰撞区域触发。装饰性的尖刺轮廓不能自动成为伤害判定，角色没有实际进入伤害区时不应扣血、击退或复位。
调试记录至少包括：
platform_id | platform_type | platform_state
collision_enabled | player_grounded
hazard_event | event_result
视觉模型、碰撞和逻辑状态不一定必须在完全相同的渲染帧变化，但必须遵循稳定、可解释的顺序，不能长期出现“平台看不见却还能踩”或“平台还在却已经穿过去”的状态。
第六条：坠落、检查点和时间处罚要形成闭环
“掉下去后回到安全位置”仍然不够明确。系统必须知道安全位置属于哪个检查点、保留哪些进度，以及失败需要付出什么代价。
第一版可以规定：
- 玩家低于关卡下限时判定坠落；
- 回到最近一个已合法激活的检查点；
- 每次坠落扣除 10 秒；
- 复位时清除垂直速度和残留平台位移；
- 检查点进度保留；
- 体力恢复到 100，确保玩家能够继续测试路线。
“最近已激活点”和“空间距离最近的检查点”不是一回事。玩家可能从高处跌到一个尚未到达的检查点附近，系统不能因此把它当作复位点，否则会跳过中间关卡。
分别从 platform_08、platform_16 和 platform_28 坠落，核对返回点、扣时、体力和检查点状态。如果玩家在激活新检查点前坠落，应回到上一个有效检查点，而不是回到距离最近但尚未解锁的位置。
第七条：暂停、胜负和重开必须统一管理
暂停不能只停住倒计时。移动平台继续运行、碎裂倒计时继续推进、体力仍在减少，都会让恢复后的状态与暂停前不一致。
暂停时应冻结：
- 关卡倒计时；
- 玩家输入和角色运动；
- 移动平台进度；
- 碎裂平台倒计时；
- 体力消耗与恢复；
- 坠落复位流程；
- 尖刺等动态伤害事件。
恢复后从暂停前状态继续，不能一次性补执行暂停期间本应发生的事件。
玩家在按顺序激活 3 个检查点后触碰 summit_01，胜利只结算一次。第一版的失败条件只保留超时；坠落通过扣除 10 秒间接增加失败风险，不额外引入尚未定义的跌落次数上限。
完整重开必须恢复：30 段平台的初始状态、100 点体力、3 个未激活检查点、480 秒倒计时、玩家起点、移动平台周期、碎裂平台状态、伤害事件和结算弹窗。
准备角色和平台资产时，可以使用 AI 3D 模型生成入口。但资产生成解决的是初始内容准备，不等于抓边、体力、碰撞、检查点和重开规则已经实现。
一段可直接复制的攀登提示词
请生成一个可操作、可重复测试的云端攀登关卡，不要只生成概念画面。
1. 目标与时限
- 1 名玩家，30 段平台，编号 platform_01 至 platform_30。
- 在 platform_10、platform_20、platform_26 后分别设置 checkpoint_01、checkpoint_02、checkpoint_03。
- 终点编号 summit_01，关卡时限 480 秒。
- 玩家必须按顺序激活 3 个检查点，并在剩余时间大于 0 时触碰终点才胜利。
2. 基础运动
- 地面移动速度 5 米/秒，单次跳跃目标高度 2.2 米。
- 空中转向能力为地面的 40%，关闭二段跳。
- 落地前重复按键不触发第二次跳跃。
- 输出 idle、run、jump、airborne、land、hang、climb、fall、reset 状态。
3. 抓边判定
- 只有带可抓边标签的边缘可以抓取。
- 同时检查检测点距离、角色朝向、边缘上方站立空间、体力和当前角色状态。
- 失败时分别反馈距离不足、朝向不符、上方受阻、对象不可抓、体力不足或状态禁止。
4. 体力
- 最大体力 100；悬挂每秒消耗 8 点；每次向上攀爬额外消耗 12 点。
- 在安全平台连续站立 2 秒后，以每秒 20 点恢复。
- 体力归零时松手并进入坠落状态，不能同一时刻立即重新抓边。
- 暂停、失败、复位和结算期间体力不变化。
5. 动态障碍
- 移动平台使用固定路径与周期，玩家站在上面时正确继承平台位移。
- 碎裂平台承重后开始倒计时，结束时同步更新视觉反馈、碰撞和不可站立状态。
- 尖刺只在明确的伤害碰撞区内生效。
6. 坠落与检查点
- 玩家低于关卡下限后，回到最近一个已合法激活的检查点。
- 每次坠落扣除 10 秒，清除下落速度，保留合法检查点进度，并把体力恢复到 100。
- 不得把玩家送到尚未激活的检查点或未到达的平台。
7. 暂停、结算与重开
- 暂停冻结倒计时、角色、移动平台、碎裂倒计时、体力、复位和动态伤害。
- 胜利与失败都只结算一次；第一版唯一失败条件为倒计时归零。
- 重开恢复平台、体力、检查点、倒计时、玩家位置、伤害事件和全部弹窗。
请为每条规则输出：具体数值、触发条件、玩家可见反馈、失败处理，以及“已实现／未实现／待验证”状态。同步记录 platform_id、玩家状态、体力、检查点、剩余时间、平台状态和最终结果。没有运行证据的功能必须标记为“待验证”。
提示词写得具体，能减少生成工具自由补全规则造成的歧义，但提示词本身仍不是验收报告。工具无法实现的内容应标记“未实现”；画面出现了、却没有运行记录的功能应标记“待验证”。
用三轮验收确认规则真正连通
第一轮：正常通关
从起点出发，按顺序激活 3 个检查点，在 8 分钟内到达终点。记录检查点激活时间、当前平台、剩余体力、剩余时间和最终结算。
第二轮：主动制造失败
分别测试抓边失败、体力耗尽、碎裂平台、尖刺和坠落。核对失败原因、提示文本、返回检查点、10 秒处罚和体力恢复是否一致。
第三轮：中断与重开
在悬挂、移动平台运行、碎裂倒计时和坠落复位过程中分别暂停，再恢复或完整重开。检查玩家状态、平台状态、体力、检查点、时间和弹窗是否回到正确值。
测试记录至少包括：
build_version | platform_id | player_state
stamina | checkpoint_state | remaining_time
platform_state | failure_reason | final_result
只有编号与时限、运动参数、抓边条件、体力、动态障碍、坠落恢复、暂停与重开全部能重复验证，才适合把结果称为“可玩的攀登原型”。
提示词要描述状态，不只是描述画面
AI 生成 3D 模型、角色和场景适合快速准备攀登关卡的外观，但云层有层次、平台一路向上，只能证明视觉方向成立。抓边是否可靠、体力是否真正限制动作、坠落后能否恢复、重开是否清除旧状态，都必须通过规则和运行记录证明。
提示词越接近“数值—触发条件—可见反馈—失败处理—状态记录”，后续越容易判断生成结果完成了哪一层，也越容易定位第一次失败发生在哪里。
写攀登提示词时，你更容易漏掉抓边空间、体力归零，还是坠落后的检查点恢复？
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/Solange__/article/details/166849111
