普通视频生成和交互式世界的差别，不在画质，而在有没有一个能被输入持续修改的状态。普通视频生成给一段提示词，输出一段固定时长的成片，交付就结束；交互式世界在同样的提示词之后，还要接住「向前走一步」「转个视角」「在门口停留触发开门」这类操作，并在操作之后保持场景前后一致地继续生成。所以判断自己要不要上交互式世界，只需要回答一个问题：用户拿到成片之后，还想不想动手，动手之后画面是否必须变。

先写一条用户操作路径，再看素材能否支撑，最后才谈投入。路径里如果只有「看到什么」、没有「做什么」和「画面怎么变」，说明要的是成片；操作后的画面变化明确、可复用、可验收，才值得考虑可操作世界。素材视角单一、场景没有可探索空间、主体在多帧之间还在变形的，通常先在单帧或普通短视频流程里解决。判断依据落在三件事上：操作是否真实存在、素材是否撑得住、同一操作重复执行结果是否一致。

把需求写成一条用户操作路径

别从「我要不要交互」这个问题本身入手，它很难答。换成一个填表动作：把需求写成「看到什么、做什么、画面怎么变」三段，填不满就说明不需要交互。模板如下，可以直接抄进文档或需求单：

• 看到什么：用户进入时画面里必须存在的元素，列三到五个，不要太细。
• 做什么：用户能发出的最小操作集，建议不超过三个动作，多了说明需求还没收敛。
• 画面怎么变：每个操作后必须发生的变化，以及哪些东西不能变。这两半都要写。

示例一，真需要交互的街区漫游小样：看到一条可步行街道、两侧门面、正前方路口；做的是前后移动、左右转视角、在门口停留触发开门；画面变化是前进后近处门面变大、远处路口位置相应前移，转身后背后店铺进入画面，开门时门扇转动但门框与招牌位置不动。这里的「转动视角」「门扇转动而门框不动」是普通成片给不了的，属于真需求。

示例二，其实只需要成片的产品展示：看到产品在桌面上的三个角度；用户做的只是点击播放、拖动进度条；画面不因为用户操作发生内容变化，只是按顺序播放。这类需求写下来就会发现，「拖动进度条」是播放器行为，不是对世界的操作，用普通视频生成加剪辑即可。

填完的路径建议落成一份可以重复跑的用例，后面每次改配置都拿它对一遍：

{
  "case_id": "street_walk_demo",
  "see": ["街道路面", "两侧门面", "正前方路口"],
  "actions": ["forward", "turn_left", "turn_right", "interact_door"],
  "expect_change": {
    "forward": "近处门面变大，路口位置前移",
    "turn_left": "左侧店铺进入画面，门面顺序不跳变"
  },
  "expect_stable": ["门框位置", "招牌文字", "路面纹理走向"]
}

expect_stable 是容易被忽略的一半。很多人只写「变了什么」，结果跑出来画面确实变了，但招牌文字每帧都在换，这种产出没法交付。

对比一次性成片和可操作世界两类产出

把差异落在使用方式上，比讲概念有用。下面这张对照表可以拿去和需求方对齐，四行里任何一行对不上，都说明方向不对。

验收标准那一行最能说明问题：成片验收是「看一遍觉得行」，可操作世界的验收是「按同一份用例跑两遍，结果对得上」。后者需要你提前准备用例，这部分成本经常被漏算。

检查自己的素材能否支撑持续操作

在投入之前先排除素材层面根本走不通的情况。三个自检项，任何一项不过关，交互式世界这条路通常都很吃力：

• 视角是否单一：素材只有正面固定机位，用户一转视角就没有信息可补。这类素材要么补多角度参考，要么接受模型补全带来的不稳定，先确认能接受哪种。
• 场景是否有足够可探索空间：一张桌子一个杯子，操作两三步就见底，说明「世界」规模不够，做成交互的性价比很低。
• 主体是否稳定：多帧之间形状、颜色、数量跳变明显的素材，在交互式世界里会被放大成每一帧都重画。可以先抽几帧并排看，确认同一物体轮廓是否一致。

抽帧检查是可核验的动作，不需要额外工具，用 ffmpeg 按固定间隔抽几帧拼成一张图看即可（间隔按素材长度调整）：

ffmpeg -i input.mp4 -vf "select='not(mod(n,30))',scale=320:-1,tile=4x2" -frames:v 1 frames.png

看这张图时只关注一点：同一物体在不同帧里的轮廓、颜色、数量是否对得上。对不上，先把素材问题解决，再谈交互。

估一次尝试需要准备哪些环节

不要一上来就接业务，先按三步走一遍，每步都有明确的完成标志：

1. 环境准备：确认模型权重或服务能拿到、依赖版本能装上、显存和单次推理耗时在可接受范围。完成标志是用最小输入跑出一次非报错的结果，不接任何业务代码。
2. 跑通一次推理：用第 1 节那份路径用例当输入，记录输入（首帧或参考图、提示词、操作序列）和输出（帧数、时长、文件大小、日志里有没有重试和报错）。完成标志是输出能对上用例里 expect_change 与 expect_stable 两栏。
3. 评估可用性：按第 2 节的验收标准逐项过，重点是同一操作连跑两次结果是否一致、连续操作五步以后场景有没有漂移。完成标志是能列出失败用例清单，而不是只有一条成功样例。

接入侧可以先写一个通用骨架，字段名按实际接口替换，重点是把「状态」显式传进去，而不是每次从零生成：

POST /generate
{
  "scene_ref": "<首帧或场景 id>",
  "state": { "pos": [0, 0], "yaw": 0 },
  "action": { "type": "forward", "steps": 1 },
  "seed": 1234
}

// 返回至少校验三个字段，缺一个就当作没跑通
// frames: 本次生成的帧
// duration: 时长
// state_after: 更新后的状态，必须能作为下一次请求的入参

state_after 能不能直接喂回下一次请求，是判断这套流程是否真的「可操作」的最直接办法。如果每次都要人工重新给参考图，那它本质上还是成片流程。

给出上或者不上交互式世界的判断结论

三条标准，对号入座即可，不必纠结中间状态：

• 标准一：路径里有真实操作，且操作后画面必须有可预期变化。建议直接上。动作是缩小场景，先做单场景单动作跑通，验证通过再扩场景和动作集。风险边界在于素材必须能支撑多视角，撑不住就先回到标准二。
• 标准二：操作需求确实存在，但素材视角单一或场景太小。建议先做小样：固定一条路径、一个动作、一份用例，跑通一次并检查重复执行一致性，再决定扩不扩。验证方式是连跑两次比对输出，风险边界是小样通过不代表扩场景后仍能通过，每加一个场景都要重跑用例。
• 标准三：路径只能写出「看到什么」，用户操作只是播放、暂停、拖动进度条。建议改用普通成片流程，把精力放在提示词收敛、分镜和剪辑上。这类需求上交互式世界，多出来的成本换不到用户能感知的东西。

这三条按顺序过一遍通常几分钟就够，比先搭环境再回头想需求省事得多。