把 Hy-Nomas 的产出当成「场景帧」，把操作输入当成「帧间衔接指令」，排查时先分清是哪一侧出了问题：画面本身不合理，属于生成侧的外观问题；画面合理但不跟手、不连续，属于响应侧的衔接问题。两者的调参入口不同，混在一起改，最后往往说不清是哪个改动起了作用。

适用场景：用 Hy-Nomas 生成可探索场景、由操作输入决定下一帧如何衔接，画面不符合预期时。操作动作：先做零输入和单步输入两次对照，判断问题落在外观侧还是响应侧，再固定一侧、只改另一侧。验证方式：看页面行为与日志中同一帧点的输出，而不是凭整体印象。风险边界：涉及渲染延迟、输入采样的问题需要结合运行环境确认，仅靠改配置不一定能定位。

把一次失败输出拆成外观问题和响应问题

先定性，再动手改配置。判断用两问，顺序不要颠倒。

第一问：画面本身对不对。先不输入任何操作，让场景保持静止，看生成出来的画面里该有的物体、朝向、材质、整体风格是否合理。如果静止画面就已经跑偏，比如描述要的是室内却生成了开阔地形，或者物体位置明显穿模，这属于外观侧问题，改操作输入基本无效。

第二问：画面是否跟着操作变。在静止画面可接受的前提下，给一段最小输入，例如只按一次前进或只转一次视角，观察下一帧是否朝预期方向推进、动作结束后是否停在合理状态。如果画面不响应、响应过头，或者相邻帧之间出现跳变，这属于响应侧问题。

两种典型情况要区分开：静止画面正常、操作后不动，说明生成没问题，是衔接环节没把输入接到下一帧；静止画面就不对、操作后也乱，则先修外观，因为外观错了，响应是否正确根本看不出来。判断不出来时，先跑一次零输入，再跑一次单步输入，两次结果放在一起对比，通常就能定位。

只改描述文本看外观是否变化

这一轮的目的是单独验证外观侧的影响，所以操作序列、输入映射、衔接参数全部保持不变，只动描述文本里的一处。

1. 准备一段固定的操作序列，跑一遍并记录关键帧的画面，作为基准。
2. 在描述文本中只改一个维度，例如只改材质词、只改风格词、只改视角高度，不要同时改三处。
3. 用同一段操作序列重跑，停在相同的帧点截图或记录日志输出。
4. 把改动和观察结果写进下表，判断这处改动是否值得保留。

如果连续两轮改动后画面几乎一模一样，说明描述文本里这一类词在当前配置下影响很小，继续在这一维上试错意义不大，可以转去检查描述是否真的被读取。

只改操作序列看响应是否变化

这一轮反过来：描述文本固定为上一轮确认可用的版本，只动操作序列。操作序列建议写成显式结构，至少包含动作、持续时长、间隔三项，缺少任何一项都很难判断衔接是否正确。

# 操作序列示例，字段名按你的实际输入格式替换
steps:
  - action: move_forward     # 动作名，需与输入映射表一致
    hold_ms: 800             # 持续时长
    gap_ms: 200              # 与下一步之间的间隔
  - action: turn_left
    hold_ms: 300
    gap_ms: 0

对应的观察点：第一步输入是否被响应；连续两步之间是否出现丢步或跳帧；动作结束后画面是否停在合理位置；把间隔从 0 调大后，衔接是否变得更连贯，还是反而出现停顿。一次只改动作、时长、间隔中的一项，改完立刻用同一段描述文本重跑。

把两类参数分区写在同一个配置文件里

分区的作用是让后续每次实验只动一个区，避免两侧参数互相干扰。外观组只放影响「生成什么」的字段，交互组只放影响「下一帧怎么接」的字段。

# scene.yaml —— 仅示意结构，字段名按你的实际实现替换
appearance:              # 外观组：控制生成什么样的场景
  prompt: "..."          # 场景描述文本
  style: "..."           # 风格词
  seed: 0                # 固定种子，便于对照

interaction:             # 交互组：控制下一帧如何衔接
  input_map:             # 动作到输入的映射
    move_forward: W
    turn_left: A
  blend: 0.2             # 相邻帧衔接强度，示例占位值，需结合实现确认
  max_step: 1            # 单帧最大推进量，示例占位值

注释写清每组控制什么，是给下一次实验的人看的。检查方式是：改外观组后，交互组的行为应当看起来没有变化；如果改外观时衔接手感也变了，说明两侧参数耦合，需要先把耦合项单独拎出来确认归属。

记录每次只动一组参数的结果

零散的试错不记录，下次还得从头再试一遍。每次实验只写一行，至少包含三项：改动项、观察到的变化、是否保留该改动。

「观察到的变化」写具体现象，例如「画面不动」「两步之间停顿明显」，不要写「感觉好一些」。是否保留也要写理由，尤其是回滚的改动，标明是因为没变化还是因为引入了新问题变差。这样积累几轮之后，遇到同类画面问题，可以直接查表判断该改描述还是改操作输入，而不是继续来回试。