AI 实时交互式视频：从看视频到和视频对话

用户正在看产品演示，忽然问：“有没有更便宜、但保留这个功能的版本？”系统暂停当前讲解，回答价格差异，再播放对应功能片段。随后用户追问一个细节，视频继续沿着新的问题展开。

这是一个产品设计场景，不是本文已经运行过的演示。它说明了 AI 交互式视频值得探索的方向：让用户的问题改变内容的选择、表达和播放顺序。做到这一点，并不要求每一帧都现场生成。

对于内容可以拆成模块、回答又需要个性化的场景，本文更看好混合方案：经过审核的预制素材承担产品事实与关键演示，对话和数字人承担实时回应。生成式视频用于确实需要新画面的节点，而不是所有交互的默认开销。

一、先区分互动方式与内容生产方式

传统分支视频可以有明确的选择后果，分支合流也可能是有意的叙事设计；不能因为素材预先制作，就把它叫作“假互动”。AI 增加的是自然语言理解、动态内容编排，以及生成新素材的可能性。

这里的“实时”需要落实到具体能力。实时数字人可以持续输出说话画面，不等于能够实时生成任意场景和复杂动作；接口能够返回一段视频，也不等于能够中途打断、逐块播放。

预制素材的数量同样要算清楚。若每个节点产生 3 个新分支，根为第 0 层，连续分支 5 次，则第 5 层有 243 个叶节点；若每个节点对应一个独立片段，整棵树共有 364 个片段，而非 243 个。复用模块、合流和限制分支深度都可以减少素材数，指数增长只适用于不复用的完整树。

AI 也没有把剧情成本降为零。模型调用、审核、失败重试和状态分支管理仍然存在，只是把部分提前制作的成本转移到了运行时。

二、一次交互如何改变正在播放的内容

以产品顾问为例，一次请求包含五个相互依赖的动作：理解问题、检查当前会话状态、决定回应内容、准备媒体、提交给播放器。

2.1 意图理解产生候选，规则决定允许的动作

用户问“有没有平价替代”，模型可以提取预算诉求、当前产品和待比较功能。但它不能自行生成价格或折扣。产品事实应来自获准使用的数据，内容决策再据此选择比较表、演示片段或澄清问题。

首版不必支持无限开放的意图。先覆盖产品介绍、功能对比、价格查询和人工转接等明确动作，允许用户用自然语言表达，通常更容易检查回答是否正确。无法映射的问题要有明确的澄清路径，不能一律生成看似相关的视频。

2.2 状态记录“已确认什么”，不只记录“聊过什么”

下面是说明性的会话状态，不是某个服务的完整接口：

{
  "session_id": "demo-session-01",
  "state_version": 12,
  "active_request_id": "request-08",
  "current_segment": "feature-demo-v3",
  "topic": "product-comparison",
  "confirmed_preferences": {
    "budget_band": "entry",
    "required_feature": "offline-mode"
  },
  "shown_segments": ["intro-v2", "feature-demo-v3"],
  "pending_action": "compare-plans"
}

当前正在比较什么、用户已经看过什么，应该能从结构化状态中直接读取。对话摘要可以补充语境，但不能代替价格、商品版本和已确认选择。

历史检索有助于找回较早的偏好，前提是按用户与会话权限过滤，并区分用户明确说过的内容与模型推断。此处是会话记忆检索，不宜直接称作 Video-RAG；后者容易让读者误以为系统正在检索视频中的视觉或语音证据。

应用中的世界状态也不等于研究意义上的生成式世界模型。维护场景、人物位置和剧情事实有助于生成控制，但状态正确不会自动让输出画面保持同一张脸或正确的物理动作。还需要相应的模型条件和输出检查。

2.3 生成完成，不等于结果仍然有效

用户可能在视频准备期间改变问题。请求 08 正在生成价格讲解时，请求 09 已经改为查看另一款产品；请求 08 即使成功，也不应覆盖新内容。

因此媒体任务需要绑定请求 ID、状态版本和内容版本。播放器接收结果前，核对它是否仍属于当前有效请求。中途打断时先停止旧音频和播放队列，再尽可能取消下游任务；已经进入供应商计算的任务未必能撤销，其费用也未必能够收回。

只有实际播放确认后，才把片段记入“用户已看过”。生成、下载和加入缓冲区都是准备状态，不能提前当作用户已经获得的信息。

三、延迟要从用户体验向下拆解

“响应很快”至少包含三个不同指标：

此外还要记录完整内容就绪时间、卡顿和音画不同步。加载动画可以改善等待表达，不能从统计中扣掉真正的等待。

意图理解、内容决策、模型排队、生成、编码、传输和播放缓冲共同决定首段延迟。如果部分操作并行，应沿实际关键路径计算，不能简单把所有阶段的均值相加，更不能将各阶段的 P95 相加当成整条链路的 P95。

3.1 预生成只在命中时有效

用户观看功能介绍时，可以预加载下一步最可能的演示。候选命中会减少等待，未命中则增加无效生成和带宽成本。应同时记录命中率、未播放素材比例和取消后的费用。

共享缓存适用于无用户数据的公共演示。包含个人称呼、历史偏好或账户信息的内容必须隔离，不能仅以“相同意图”为键跨用户复用。

3.2 流式输出需要整个链路支持

模型能逐块输出、编码能及时交付、播放器能增量解码，三者缺一不可。如果模型只能在任务结束后返回成片，更换传输协议无法让第一帧提前产生。

StreamDiffusion展示了扩散图像生成管线的实时交互优化，但图像吞吐不等于长视频叙事连续性，也不直接证明任意文生视频模型已经支持可打断的流式会话。评估时应把模型吞吐、首帧延迟、时序质量和整段任务时长分别测量。

四、播放器不是只接一个视频 URL

4.1 媒体协议与浏览器 API 要分层比较

HLS、DASH、MSE 和 WebRTC 不在同一层，不能给它们各填一个固定延迟数值就据此选型。

MSE 文档说明了 MediaSource 和 SourceBuffer 的职责；HLS 或 DASH 播放器可以建立在这类 API 上。MSE 本身不是与 HLS 并列的传输协议，也不保证片段能够任意无缝拼接。

HLS 还包含 Low-Latency HLS 方案，不能将所有 HLS 应用限定为 5–10 秒延迟。WebRTC 规范定义实时通信接口与连接机制，实际时延仍取决于生成、网络和接收端缓冲，不能承诺任何环境都小于 500 ms。

4.2 模块需要可检查的衔接条件

每个素材模块应描述入口和出口：场景、角色位置、镜头尺度、声音状态，以及允许接续的话题。以下是用于讨论的数据类型：

interface FrameState {
  sceneId: string;
  characterAssetVersion: string;
  camera: "wide" | "medium" | "close";
  poseKey: string;
}

interface VideoSegment {
  id: string;
  version: string;
  durationMs: number;
  enterState: FrameState;
  exitState: FrameState;
  topic: string;
  nextCandidates: string[];
}

状态匹配只是候选筛选。两个片段都标为中景，也可能在光照、视线或语音收尾上不适合直接拼接。稳定的开场、收尾、转场素材和试听检查，比任意拼接后寄希望于播放器“消除接缝”更可控。

播放层还要区分几种时钟：媒体时间用于字幕和商品卡片同步，会话版本用于选择有效结果，任务时间用于排队与超时。一个 UI 定时器不能代替它们。

4.3 无法立即生成时，也要有完整交互

等待时可以给出明确状态，展示已经审核的相关资料，或者先用文字和语音回应。用户应能停止、重试或改用文字输入。

是否主动追问，应结合用户当前动作：正在输入、切换窗口、静音观看，与完全没有回应不是同一种情况。固定每隔几秒插话，可能打断思考。可以从安静等待加可选按钮开始，通过实际会话观察再调整提醒时机。

五、第一版如何组织系统

首版可以由一个会话服务组织内容决策，不必先拆成多套微服务。数据库保存会话事件、已确认选择和内容版本；缓存用于加速读取；媒体任务由有界队列执行，结果通过事件通知播放器。

需要提前明确的职责有：

• 内容服务维护审核过的事实、片段和可衔接关系
• 会话服务管理请求顺序、状态版本与打断
• 生成适配层封装供应商参数、任务状态和结果格式
• 播放层控制媒体队列、缓冲、字幕和界面事件
• 观测系统串联输入、决策、生成和实际播放结果

“可以更换供应商”来自适配边界，不代表无需改动。模型支持的输入、角色控制、时长、流式能力和计费方式可能不同，更换后需要重新验证同一批交互用例。

视觉一致性也有不同解决层次。参考图、身份条件和 LoRA 可以约束外观；数字人资产可减少重复生成外观的需求；场景和剧情状态由应用记录。这些手段都不能单独保证完整连贯性，具体分工可参见人物一致性与技术选型。

六、商业价值应通过任务结果验证

视频是否比文字、图片或普通演示更有价值，需要对照验证。一个不会回答问题的数字人，可能比清楚的文字说明更费时间；一个能够按提问展示设备操作的界面，则可能减少用户在手册里寻找步骤的成本。

这些指标应与现有形式比较，不能仅凭用户与数字人说了更多话，就认定业务价值更高。企业场景可能有更清楚的采购目标，但不能据此断言 B2B 一定先于 B2C 成功，或小团队一定胜过大平台。

成本也应按完整会话统计：成功与失败生成、未播放的候选、语音服务、分发、内容制作和人工审核都要计入。只有将这些支出除以完成目标的会话数，才能判断混合策略是否真的更划算。用轻量模型承担简单回应可能减少开销，节省比例需要在相同任务质量要求下实测。

对外展示的角色、声音和产品事实需要明确来源；会话记忆应限制访问和保留范围。生成的人像或演示不能冒充真人背书、真实使用效果或尚未发生的交易结果。产品应直接说明哪些内容由 AI 生成，哪些来自已审核素材。

七、以可观察的条件决定何时增加生成比例

预制、数字人和场景生成可以长期共存，不必被安排成必然替代的三个年代。对于同一个产品，稳定的操作演示可能一直使用预制片段，问答需要动态语音，只有个性化解释才需要新的画面。

可以逐步增加生成比例的信号包括：同一组问题下首段等待缩短，打断不再播放过期答案，角色和场景错误减少，以及每个有效会话的总成本下降。若这些指标没有同时改善，增加生成比例可能只是增加等待和返工。

AI 交互式视频的机会，在于让视觉内容能回应当前问题。第一版应先证明这种回应帮助用户完成了任务，再决定多少内容需要现场生成。