MoWorld 和视频生成模型差别在哪——边操作边出画面这点怎么验？

判断 MoWorld 这类交互式世界模型与普通视频生成模型的差别，最省事的切入口不是分辨率、时长或画质，而是画面推进的过程中，输入还能不能继续影响它。一次性视频生成是「提交参数 — 等待 — 拿到一段结果」，等待期间你改方向、改节奏、改提示词，都不会反馈到正在产出的这一段里；交互式世界模型则是在画面持续生成的同时保留输入通道，你的动作可以改变后续帧。要验证手上这套东西属于哪一类，通常不需要跑评测集，只需要在画面明显变化的过程中改一次输入方向或节奏，看画面是否跟着变，并把改变发生的时机、幅度和是否需要等待记录下来。

先分清一层：一次性视频生成是提交后等结果，交互式是生成过程中输入仍能影响画面。验证动作可以固定为——在画面明显变化时改变输入方向或节奏，重复 3 次，其中至少 1 次落在变化最快的时间点。判断依据只看三件事：改变后多久出现反应、反应幅度是否对得上输入、同一次操作能否复现。若反应稳定且方向对应，可判为支持持续交互；若只在慢速阶段或某一类输入上生效，判为特定条件下成立；若画面不随输入改变、或变化与输入无对应关系，只能先判为无法确认，需结合具体环境和日志再确认。

先明确两类东西的差别在哪一层

做对比时容易把维度摊得太开：画质、时长、镜头连贯性、可控性、算力成本。但对「边操作边出画面」这个问题，真正需要卡住的只有一层——输入与画面的因果时序。一次性生成把输入全部前置，生成开始后就没有输入通道了，模型只是在把已经确定的条件展开成帧序列；交互式生成把输入摊在时间轴上，画面推进到第 N 帧时，第 N+1 帧仍然可以受新的输入影响。

这一层差别决定了三件可观察的事，后面所有验证都围绕它们：

输入生效的时点：改变输入后，是从当前帧往后立即生效，还是必须等这一次生成结束、下一段重新开始时才生效。
画面的连续性：输入改变后，画面是接着演化，还是回退、重置、重新出图。
输入与变化幅度的对应关系：输入幅度变大变小，画面变化的幅度是否跟着变。

这里只描述差别，不评价哪一类更好：一次性生成在可复现性和稳定性上往往更省事，交互式在可操作性和可试探性上更省事。选择取决于你的使用场景，而不是哪一类「更先进」。

设计一个最小验证动作

验证的目标是拿到判断依据，不是压测系统。所以动作要尽量少，变量要尽量少。建议先把随机种子、提示词、初始画面或起始状态固定下来，再只改一个输入维度。

最小动作可以这样设计：

启动一次生成，等待画面出现明显变化（主体位移、场景切换、镜头推进、物体形变等，选一个你能一眼看出来的）。
在变化仍在持续时，把输入方向改成近似反向，或者把输入节奏从连续改为停顿两三秒再继续。执行时点必须在变化过程中，而不是等画面停下来之后。
保持改后的输入至少 2～3 秒，观察画面是否跟随。
重复 3 次：其中至少 1 次落在画面变化最快的时刻，至少 1 次落在变化较慢的时刻，剩下 1 次可以放在场景切换或镜头切换附近，用来看切换边界是否还接受输入。

如果这套系统提供脚本、命令行或配置入口，通常会有一个「运行中更新输入」的字段或方法名，不同实现的命名差异较大，字段名需要按你自己的版本文档确认。可以先用类似下面的骨架判断有没有这条通路，把 YOUR_INPUT_FIELD 换成实际字段：

// 伪代码骨架，仅示意调用顺序，字段名需按实际环境确认
session = start_generation(prompt, seed)
wait_until(frame_progress > 0.3)     // 等到画面已明显变化
before = capture_state()             // 记录改输入前的状态与时间戳
session.update_input(
    YOUR_INPUT_FIELD,
    value = reverse_or_pause,
    apply_mode = "during_run"        // 关键：运行中生效，而非下一段生效
)
after = capture_state()
log(before, after, wait_ms)

如果根本没有运行中更新输入的通路，只能停下再重新生成，那这一点本身就已经是结论的一部分了，可以直接进到记录环节。

观察画面是否随新输入改变

现象描述不能停留在「感觉变了」，要写成别人可以照着重述的句子。每次操作至少记录四项：改变发生的时机（帧号或时间点）、从改输入到画面出现对应变化之间的等待、变化幅度与输入幅度是否成比例、画面是否连续演化。

可复述的描述大概长这样，注意这是描述句式，不是结论：

「在第 3 次改变方向后约 2～3 帧内，画面主体的水平运动方向由向右转为向左，位移速度大致回到改输入前的量级，无需等待整段重生成。」
「把节奏改为停顿时，画面在停顿时保持原地摆动，恢复输入后重新开始推进，没有回到起始画面。」
「在场景切换附近改方向，画面先完成了当前切换，切换结束后的运动才跟随新输入，存在约一次切换的滞后。」

记录可以用一张表或一段结构化日志，字段建议固定下来，方便三次重复横向对比：

记录字段模板（纯文本，可直接抄进表格）
- 次数:</n- 执行时点: 画面进度约__%（或第__帧/第__秒）
- 输入改变: 方向 右→左 / 节奏 连续→停顿__秒
- 首次可见反应: 改输入后约__帧 / 约__秒
- 幅度是否对应: 是 / 否 / 无法比较
- 画面是否连续: 连续演化 / 回退重置 / 无变化
- 是否复现: 与第__次一致 / 不一致

等待这一项要单独记。短等待（画面内可感知）和长等待（需要整段重新生成）在体验上是两回事，但在记录里容易被混成一句「有反应」。建议把等待拆成「可感知的短等待」和「超出当前片段长度的等待」两档，写清楚你观察到的属于哪一档。

把无效情况也记下来

只留正面记录，最后一定会把偶发当成能力。下面几种情况同样要记，而且尽量原文照记，不要修饰成「大致有反应」：

输入改变后画面无变化：写清改了什么、在什么时点改的、保持输入多长时间、画面在此期间是否仍在正常推进。无变化但画面在动，和画面整个卡住，是两种不同的记录。
延迟很久才变化：写清等待时长，以及这段等待里画面是否仍在演化。如果变化正好出现在下一次片段开始的边界上，那更像是重新生成，而不是运行中影响。
变化方向无法对应：画面确实变了，但变化方向、幅度和输入对不上，或者每次都不一样。这种要记成「变化与输入无对应关系」，不要写成「反应灵敏」。
画面回退或重置：输入改变后画面跳回起始状态或重新出图，说明这次输入触发的是重跑，不是持续交互。
只有 UI 反馈、画面无反馈：输入控件有响应、状态指示变了，但画面没有跟随，也要单独记一条。

每条无效记录同样带上执行时点、输入内容、保持时长和重复次数，这样它才和正面记录一样可比较。

把记录收敛成一句判断

三次重复做完、无效情况也记完之后，结论按下面三种口径之一来写，并在后面注明依据的是哪几条记录，避免出现只有形容词没有出处的结果。

支持持续交互：依据第 1、2、3 次记录，输入在画面变化过程中改变后，画面在可感知的短等待内沿新输入方向变化，幅度与输入幅度大致对应，画面保持连续且三次重复一致。注意这一句只说明「运行中可影响」，不说明效果好坏，也不说明在长时段或复杂场景下同样成立。
只在特定条件下成立：依据第 2 次和第 3 次记录，输入在慢速变化阶段能被画面跟随，但在变化最快的时刻或场景切换附近无效或滞后到下一段，说明这条通路存在但受时点或输入维度限制。使用时需要把操作限制在可生效的时点范围内。
无法确认：依据全部三次记录，画面均不随新输入改变，或变化方向与输入无对应关系，或等待时长超出当前片段长度且无法区分是缓冲排队还是运行中生效。这种情况下不建议直接按交互式用法使用，需要结合配置项、运行日志和输入通道说明再确认一次。

三种口径都只覆盖你实际试过的场景。换了输入类型、换了片段长度、换了运行环境之后，结论需要重新用同一套最小动作再走一遍，而不是直接沿用。