原型阶段最省事的做法是把生成和调数值拆成两段：BinkBink 负责把玩法骨架生成出来，人只负责数值平衡。顺序不要反——先让骨架能单独跑起来验证，再定通关时长，再调难度，最后把调好的数值写回需求描述。如果一上来就把难度和节奏交给生成，跑出来的东西“能玩但不对”，你想接手又找不到切入点，改了还容易和前面的描述冲突。

适用场景：原型阶段用生成工具产出玩法骨架、人工接手数值。操作动作：先把骨架拆成可独立跑的最小循环并跑一遍记录卡点，再按“先定目标通关时长、后调难度”的顺序，每次只改一个数值。验证方式：用卡点记录、通关时长与失败次数记录、外部试玩记录三类材料交叉核对。风险边界：单次跑测只能当线索，不能当结论；改多个数值会分不清是谁在起作用，通常要跑几次看区间。

把玩法骨架拆成可独立验证的最小循环

骨架不是“整个原型”，而是一段能被单独跑起来、单独判定成立与否的循环。建议把一个循环拆成“玩家输入 → 系统结算 → 反馈 → 出口”四段，每段都写清楚玩家做什么、系统给什么反馈、怎么判定这段成立。下面是一份可以直接替换字段的骨架示例，字段名按你自己的配置习惯改。

loop_id: prototype_loop_01
steps:
  - id: enter_node        # 玩家做什么：从入口选择一个节点
    player: 二选一（战斗房 / 绕行通道）
    system: 返回该节点的初始状态（敌人、掉落、出口）
    pass_if: 两条支路都能加载出完整内容，不出现空节点
  - id: act_or_skip       # 玩家做什么：打还是绕
    player: 攻击或绕过
    system: 返回血量变化、掉落、是否触发追击
    pass_if: 两种选择产生可观察的差异，而不是结果一样
  - id: settle            # 玩家做什么：结算并决定去留
    player: 继续 / 退出
    system: 返回奖励与下一节点
    pass_if: 两个出口都有响应，不出现卡死或无反馈

判定标准尽量写成“肉眼能看出来”的：节点能不能加载、两种选择结果是否不同、退出是否真的退出。不要写成“体验流畅”这类没法验证的话。骨架阶段的分工可以先这样切：

• 生成侧：节点结构、支路数量、流程串联、出口条件。
• 人工侧：每段的判定标准、卡点记录、后续数值锚点。
• 共同确认项：一个循环跑通后，才允许继续往下生成。

生成骨架后立刻跑一遍，记录卡住的位置

骨架生成完不要攒着，先跑一遍。这一遍的目的不是看好不好玩，而是看骨架本身立不立得住。卡点必须分类，否则后面调数值时会误判：玩法不成立（玩家做的选择没有意义）、操作反馈缺失（按了没反应、反馈延迟或缺失）、流程断点（走不到下一个节点）。每条卡点都要能用一句话复现，否则它就不是卡点，只是印象。

卡点编号: C-003
位置: 第 2 关 boss 前窄通道
分类: 操作反馈缺失
一句话复现: 在窄通道连续按两次跳跃，角色停在半空不落下，等待数秒后仍无任何反馈。
当前是否阻塞骨架: 是
处理方向: 先回到骨架层修跳跃判定，暂不动数值

“玩法不成立”和“操作反馈缺失”要分开处理，前者通常要改骨架描述重新生成，后者多半是配置或接线问题，不需要重生成。分类写错，后面的数值调整就白做。

接手数值：先定通关时长再调难度

数值调整需要一个锚点，最稳的锚点是目标通关时长。顺序建议是：先定目标通关时长区间，再定失败次数容忍范围，然后看难度曲线的形状（前松后紧、中段抬升），最后才动具体参数。每次只改一个数值，改前改后各跑一次，把差异记下来。

run_id: N-004
build: skeleton-0.3
目标通关时长: 12-15 分钟
实际通关时长: 9 分 40 秒（首次通关）
失败次数: 1（集中在第 2 关）
本次只改: 中段敌人数值系数 1.0 -> 1.2
改动前一次: 8 分 50 秒 / 0 次失败
改动后一次: 9 分 40 秒 / 1 次失败
未改动项: 其余参数全部保持原值

难度曲线建议按关卡分段记录，比只看总时长更容易定位问题：

• 关卡序号 / 预期难度（低、中、高）
• 实际耗时 / 死亡次数
• 是否需要回退到上一档（连续两次超出容忍范围就回退）

需要说清楚的边界：一次跑测的秒数受操作熟练度影响很大，通常跑几次看区间；不要因为一次偏短就整体加难，也不要因为一次偏长就直接改三四个参数。

把调好的数值写回需求描述

不写回描述，下一次生成就会回到旧设定，前面的调整等于没做。写回的原则是：稳定的骨架结构写进去，可调的数值约定写进去，单次跑测的临时数据留在本地记录。写回字段建议分成三段，明确哪些是“不要再改的”，哪些是“改了要记录的”。

玩法骨架（稳定，生成时不要改动）:
- 三节点线性推进，每个节点二选一（战斗 / 绕行）
- 结算后直接进入下一节点，不支持回退

数值约定（可调，改动需在本地记录留痕）:
- 目标通关时长: 12-15 分钟
- 失败次数容忍: 1-3 次
- 难度曲线: 前松后紧，第 2 关为第一个明显抬升点

不进描述（只留本地记录）:
- 单次跑测的具体秒数
- 调试期间用的临时倍率

下次生成前先核对描述版本：打开需求描述，确认顶部版本标识或更新时间是最近一次写回的那版，再看数值约定段是否与本地记录一致。如果发现描述里还留着被替换掉的旧数值，说明上一次没写回完整，需要先补写再生成。

拉一个人试玩，只记录卡点和放弃点

自己跑测会越来越熟练，感觉不到难度是否真的合理。找一个人试玩，你只记录两件事：卡在哪、什么时候放弃。不要中途提示，也不要问“好不好玩”，问不出可用信息。

试玩编号: P-002
卡点位置: 第 2 关中段
放弃时关卡: 第 3 关开头
玩家原话: “我知道要从那边绕，但跳过去总是掉下去”
观察: 试了约数次同一动作后停手
归类: 操作问题（知道该做什么，做不到）

区分难度问题和操作问题，有一个简单的判断方式：

• 不知道该做什么、找不到出口 → 信息反馈或引导问题，不是数值问题。
• 知道该做什么但做不到、动作多次失败 → 操作或判定问题，先别加难度。
• 知道也做得到，但反复失败在同一个数值门槛上 → 这才是难度数值问题，回到通关时长与失败次数记录里调。

归类写错是最常见的浪费：把操作问题当难度问题，就会去调低敌人强度，实际卡住的原因一直没解决。试玩记录只留下卡点位置、放弃时关卡和玩家原话这三项，够用了。