AI 视频的 interaction ID，不等于版本历史

Google 发布 Gemini Omni 1.1 Flash 后，开发者面对的不再只是一个“一次输入、一次出片”的视频生成器。现在可以先生成草稿，再把 previous_interaction_id 传给下一次请求，用自然语言继续修改、延长场景、指定首尾帧，或把选中的结果放大到更高分辨率。Google 把 360p 定位为快速打样入口，把 4K 放在成片环节。

产品问题也随之改变。小团队不再只是判断某条提示词有没有生成一段惊艳视频，而是要判断：一串连续生成的素材，能否经得起分支探索、修改、审查、批准、留存和发布；每一个版本为什么存在，事后还能不能说清楚。

interaction ID 可以帮助 API 找回上一步状态，却不会替团队记录哪些细节必须保持不变、哪里发生了意外漂移、哪条旧分支其实更好、参考素材是否有授权、审稿人究竟批准了什么，也不会自动证明最终下载的文件仍带有所需的来源信号。换句话说，服务端状态不是创意版本控制。

这篇现场笔记给出一套建议执行的 18 例分支验收实验，以及一份可复用的视频版本凭证。我们没有调用 Gemini Omni 1.1 Flash，没有生成这些夹具，没有复现 Google 的演示，也没有比较不同视频服务商。下文的流程、阈值和空白结果字段都是供小团队自行执行的协议，不是 Y Build 的实测结论。

这次发布了什么，又没有证明什么

Google 的发布公告称 Gemini Omni 1.1 Flash 已可通过 Gemini API 用于生产工作流；这是厂商对发布状态的表述。新能力包括：每次延长 10 秒、累计最长 40 秒的场景扩展；首尾帧控制；用于快速试稿的 360p 输出；以及放大到 4K 的成片输出。Google 还称，扩展时模型最多可参考此前 10 秒内容，而更早的模型只参考最后 1 秒。

配套的 Gemini Omni API 指南列出文生视频、图生视频、参考素材生视频、编辑与延长等任务，同时也写明边界：延长只能追加在片尾，不能插入中间；为了让接缝更自然，输入片段末尾若干帧可能被重新处理；上传一段有人说话的视频后，目前不能通过扩展为人物新增对白；不支持语音编辑；不支持跨多段视频推理；英语经过完整支持，其他语言尚未评估。

这些是有用的产品事实，但不能证明同一个品牌角色经过四轮修改后一定保持一致，也不能证明对白逐字不变、4K 放大能修复错误构图，或 40 秒链条一定符合某个广告 brief。发布页展示的是厂商挑选的案例，小团队仍需用自己的交付任务取证。

合理而克制的结论是：迭代控制已经足够成熟，可以被当作完整工作流来测试；但生成视频并没有因此变得确定、可自动合并、天然权利清晰，或默认就能发布。

会话链是状态指针，不是提交图

Interactions API 文档说明，previous_interaction_id 会保留此前的输入与输出，后续请求因而能沿着历史继续生成。但其他请求参数仍然只对当次 interaction 生效，需要时必须重新指定。也就是说，子节点可以继承创意上下文，却不一定继承应用默认假设的所有配置和产品规则。

软件提交通常把内容绑定到一个标识符，记录父子关系，也允许找回历史状态。创意审查还需要更多证据：

• 每一份输入素材及其哈希；
• 精确模型标识、任务类型、分辨率、区域和客户端版本；
• 提示词，以及写在普通提示词中的负向要求；
• 不允许被修改的显式不变量清单；
• 输出文件哈希与稳定的本地存储位置；
• 带时间码的审查意见；
• 获准使用的目的、渠道、地区和有效期；
• 草稿、分支、延长、放大与最终发布文件之间的关系。

不要给文件依次命名为 v1、v2 和 final-final，就以为历史可以恢复。每个候选结果都应保存为不可变节点。一次编辑或延长产生一个子节点；两位审稿人探索不同方向时，应从同一个已接受父节点创建两个分支，而不是让最新一次服务端会话悄悄成为唯一保留路径。

生成视频不存在传统意义上的 merge。提示模型“合并两个版本的优点”，本质上又是一次生成，不是确定性合并。这个结果必须成为新节点，声明两个输入来源，并接受独立审查。

从一个可发布任务和六条锁定不变量开始

设想一个四人产品团队，要为虚构的日历助手 Cedar Calendar 制作一段 20 秒竖屏发布短片。已经批准的概念是：木桌上放着一本红色纸质日历，一只手圈出某个日期；房间光线从清晨变为傍晚；画面右下角留出空白，之后由团队叠加真实产品录屏。

团队有意不让模型生成产品 UI 或品牌文字。生成文字容易错读，虚构界面也可能夸大真实能力。模型生成的片段只是最终广告的一项素材，不是广告本身。

第一次请求前，锁定六条不变量：

1. 日历始终是红色，形状保持一致；
2. 圈出的日期始终是 14 日；
3. 画面中的手没有首饰或可识别标记；
4. 镜头保持连续的俯拍单镜头；
5. 右下角保持安静、可叠加真实 UI；
6. 不出现 logo、可读产品承诺、公众人物或可识别的普通人。

再单独列出允许变化的维度：灯光、运镜速度、背景物件、声音质感，以及从早到晚的过渡方式。这样，审稿人不必只说“感觉差不多”，而能明确指出：新灯光虽然漂亮，但某条锁定不变量发生了漂移，所以必须拒绝。

换到其他产品，不变量可能是包装几何、服装颜色、配料数量、无障碍对比度、教学动作中的手部位置，或“不得出现医疗承诺”。锁定不变量不是为了消灭创意，而是为了区分有意修改与意外变异。

建立 18 例分支验收夹具

准备六类内容 brief，每类跑三个工作流分支。18 例不足以估计模型的普遍成功率，但规模足够小，团队可以逐一检查每个转场、提示词、输出和决定。

每个 brief 使用相同的三个实验臂：

实验臂 A：草稿后放大。 先生成 360p 草稿，选中一个候选，再请求最终分辨率。这里测试的是低成本草稿能否预测高分辨率成片会被接受，而不只是初始价格更低。

实验臂 B：有状态编辑分支。 从同一个已保存父节点创建两个子节点：一个只要求修改可变维度，另一个要求相同修改，同时重新声明锁定不变量。比较显式不变量清单是否减少意外变化。

实验臂 C：场景延长。 对一段已接受短片延长一次，再对新子节点延长第二次。不仅审查新增画面，还要检查父节点的最后几秒，因为 API 指南明确提醒：为了保持连续性，接缝附近的原视频帧可能被修改。

运行前冻结 brief、评分标准、参考素材哈希、审稿人分配和决策规则。看到坏结果后不能改写提示词，再把修复版算成原始案例通过。所有修复请求、被拦截请求和废弃生成都要留在台账中。

审查差异，而不只看最新视频

如果审稿人只播放最新输出，很容易漏掉主体身份漂移、背景替换、道具变化或产品约束被削弱。每个子节点都要与父节点并排审查。

使用六个彼此分开的维度：

这种拆分借鉴公开研究，但不把公共 benchmark 伪装成广告验收测试。VBench把视频拆成主体一致性、背景一致性、闪烁、运动平滑度、美感、成像质量和多项语义维度；VideoScore则用多维人工评分训练，覆盖视觉质量、时序一致性、动态程度、文本对齐和事实一致性。两者都说明，“视频质量”不是一个数字。

对小型产品工作流来说，自动指标只适合初筛。它们可以提示闪烁或大幅视觉变化，最终放行仍需一位真正理解 brief 的人。即使画面漂亮，只要违反产品事实、权利边界或安全留白要求，就应被拒绝。

可复用的视频版本凭证

每个输出节点单独建立一份凭证，而不是整段会话只留一张总表。

video_version_receipt:
  node_id: "cedar-calendar-brief-03-edit-b"
  parent_nodes: ["cedar-calendar-brief-03-draft-accepted"]
  purpose:
    campaign: "calendar-launch"
    channel: "vertical-social-draft"
    territory: "record-intended-territory"
    expires_at: null
  provider:
    model: "pin-exact-model-id"
    interaction_id: ""
    previous_interaction_id: ""
    task: "text_to_video|image_to_video|reference_to_video|edit|extend"
    resolution: "360p|720p|1080p|4k"
    region: ""
    client_version: ""
  ingredients:
    - id: "calendar-reference"
      sha256: ""
      license_receipt: "rights/calendar-reference.md"
      consent_receipt: null
  instruction:
    prompt_sha256: ""
    requested_change: ""
    locked_invariants: []
  output:
    file_sha256: ""
    duration_seconds: null
    generated_at_utc: ""
    local_archive: ""
    synthid_check: "not_run|detected|not_detected|unclear"
    content_credentials_check: "not_run|valid|invalid|absent"
  review:
    requested_change: "pass|fail"
    invariant_results: []
    continuity_findings: []
    rights_findings: []
    repair_minutes: null
    generation_calls_to_accept: null
  decision:
    state: "candidate|accepted_parent|approved_export|rejected|withdrawn"
    approved_by: null
    approved_at_utc: null
    allowed_edits_after_approval: []

空字段是有意保留的。API 返回视频，不代表权利、同意、来源或审查自动通过。缺少证据时，应记录 not_run、absent 或 unknown，不能把空白转换成绿色勾选。

要对下载后的文件做哈希，不能只保存 interaction 响应。如果提示词含有敏感活动信息，应把提示词单独存成受版本控制的文件。最终视频经过裁切、加字幕、调色或与真实素材合成后，再创建一份导出凭证，把生成节点列为 ingredient。

草稿分辨率是实验臂，不是承诺

Google 建议用 360p 预览加快、降低迭代成本；API 指南也明确把 1080p 和 4K 称为 upscale 输出。由此可以提出一条合理漏斗：先低成本探索，只对选中的方向支付成片成本。但这并没有证明，360p 阶段选中的视频到 4K 仍会被接受。

决定成败的往往是小细节。手部变形在草稿里可能看不清；纹理、文字、边缘伪影、面部细节或背景异物放大后会更加明显。反过来，审稿人也可能因为 360p 看起来粗糙而拒绝一个构图其实能通过的候选。

因此要直接测量这条漏斗：

• 每个 brief 生成多少条 360p；
• 选出草稿花了多少时间；
• 被选中的草稿在最终分辨率审查后仍获接受的比例；
• 哪些缺陷只在最终分辨率出现；
• 每个获批导出总共消耗多少生成调用和服务商费用；
• 最后一轮生成后仍需多少人工修复时间。

当前 Gemini API 价格页列出了付费 Gemini Omni Flash preview，并以输出 token 解释视频计费。它只能用于规划，不能当作 Omni 1.1 的永久报价。执行实验时，要记录实际模型、计费单位、账号层级和账单证据。“低价草稿”在计入重试和修复前仍只是假设。

有状态编辑同时也是留存决策

previous_interaction_id 的便利依赖服务端状态。Interactions API 指南说明 interaction 默认 store=true；当前文档列出的保留期为付费层 55 天、免费层 1 天，付费项目还能配置更短周期。文档同时说明，store=false 会阻止后续通过 previous_interaction_id 延续会话，也不能与后台执行一起使用。

零数据留存指南进一步拆开了这个权衡：有状态 interaction、上传文件、日志和缓存各有各的处理方式；File API 对象还需要按自身生命周期主动删除或等待过期。付费服务不拿数据改进产品，不等于每一份操作副本都会立即消失。

上传客户产品、面孔、未发布包装或活动素材前，先选择模式：

不要把这项选择藏在 SDK 默认值里。产品应该清楚展示创意会话何时被存储、保留多久、谁能查看，以及删除后哪些能力会失效。至少执行一个删除夹具，确认 interaction、上传素材、应用缓存、审查预览和衍生导出都遵循声明的生命周期。

水印与来源记录解决的是不同问题

Omni API 指南称生成视频包含 SynthID。Google 的 SynthID 文档把它描述为不可见水印，并称其设计目标包括经受裁切、滤镜、帧率变化和有损压缩等常见修改。Google 的验证说明也提醒：没有检测到或无法确定 SynthID，不能反向证明文件不是 AI 生成。

SynthID 是指向 Google 生成媒体的来源信号，不是许可证、同意记录、提示历史、完整编辑日志，也不能证明画面中的事实可以安全发布。

C2PA 2.4提供另一类互补标准，用签名式 Content Credentials 记录素材 ingredient，以及创建、编辑等动作。团队添加字幕、产品实拍或人工剪辑时，可以继续把生成节点记录为 ingredient。NIST 生成式 AI Profile同样把来源追踪和合成内容检测视为透明度工具，同时强调它们的局限与组织治理语境。

发布门禁要分别回答四个问题：

1. 下载文件是否正是被批准的那个节点？
2. 当前水印工具能否识别出 Google 生成素材？
3. 有效的来源清单是否记录了输入素材和后续编辑？
4. 独立的权利与同意记录是否授权当前用途？

任何一个“是”，都不能替代另外三个。

放行规则必须绑定分支，而且不能取平均

用计划上线的准确 API surface 执行 18 例实验。固定模型标识和客户端版本，记录区域与安全过滤表现；高价值资产或包含人物身份的素材，至少由两人审查。平均画面再漂亮，也不能掩盖一次禁用声明或一次未授权肖像。

只有所有硬门槛都通过，才能放行对应工作流：

最终只做四种决定：explore、internal-draft、limited-publish 或 hold。放行范围必须绑定具体 brief 类型、语言、参考素材类型、时长、区域和输出渠道。产品物件短片通过，不代表可以生成可识别人物广告；无对白场景延长通过，也不代表对白密集型本地化可上线。

模型别名、Interactions API、安全行为、区域、分辨率路径、水印工具、参考素材政策或后期应用发生变化时，都要复测。

上线前必须主动触发的失败模式

最新 interaction 覆盖了最佳分支。 团队无法找回已批准构图，只能重新生成。

请求的修改成功了，锁定细节却漂移。 灯光变好，但产品颜色、日期、手部或留白发生变化。

接缝改写了已接受画面。 审稿人只看新增 10 秒，漏掉扩展边界附近的变化。

把 360p 批准当成 4K 批准。 创意已经签字后，最终分辨率才出现新缺陷。

把提示历史误当权利历史。 系统保存了参考 URL，却不知道所有权、同意范围、地区和有效期。

把水印当真相证书。 检出 Google AI 信号，不代表事实正确、获得许可或从未被修改。

隐私数据流遗漏已存状态。 interaction 历史、上传媒体、审查预览或本地导出超过原定目的继续存在。

被拦截的生成从成本表中消失。 成功视频看似便宜，是因为重试、安全拦截和人工修复没有计入。

由不懂目标语言的人审本地化。 API 文档已经说明非英语尚未评估，团队却用画面精致度代替熟练语言审查。

这套协议适合哪里，又不适合哪里

当小团队把迭代生成视频用于营销草稿、产品叙事、社交媒体变体、引导页视觉、概念预览或创意工具时，可以使用这套协议。尤其当用户能继续编辑或延长旧输出、产品需要解释“究竟批准了哪一版”时，它最有价值。

它不能认证 Gemini Omni 1.1 Flash，不能给服务商排名，不能估计罕见伤害，也没有复现 Google 的主张。它不适用于新闻证据、政治传播、生物识别、儿童内容、医疗指导、法律证据、安全关键培训，或任何可能把合成场景误认为真实事件的工作流。这些场景需要领域专家与更强控制。

这套夹具也不能证明版权归属，无法替代对肖像、商标、音乐、工会、广告或平台披露义务的判断。权利取决于输入素材、指令、输出、合同、司法辖区和预期用途；风险足够高时，应咨询合格法律专业人士。

一份 48 小时 Build Lab 计划

第 0–4 小时： 选定一个可发布视频任务。冻结六类 brief、锁定不变量、允许变化的维度、权利排除项和目标渠道。

第 4–10 小时： 实现不可变节点存储和视频版本凭证。对输入素材、提示词、输出与本地存档做哈希，并在审查界面显示父节点和 ingredient 关系。

第 10–20 小时： 执行草稿/放大、有状态编辑和场景延长三个实验臂。保留每个失败、拦截、废弃和修复结果；不要使用真实客户生产素材。

第 20–30 小时： 完成父子差异审查。检查扩展接缝、最终分辨率、静音播放、字幕、裁切安全、事实承诺、可识别人物和所有锁定不变量。

第 30–36 小时： 计算每个获批导出的调用量、计费单位、延迟、审稿时间和修复分钟数。服务商生成成本与下游人工后期要分开。

第 36–42 小时： 核验文件哈希、SynthID 状态、Content Credentials 状态、素材权利和人物同意记录。让一次撤回和一次删除穿过所有列明的存储位置。

第 42–48 小时： 针对每类 brief 签署 explore、internal-draft、limited-publish 或 hold。记录准确模型、API、区域、语言、参考素材类型、分辨率路径、审稿人和复测触发器。

Gemini Omni 1.1 Flash 让产品更容易加入迭代视频能力。这种便利反而要求创意历史更明确，而不是更含糊。把每次输出当作证据保存，逐一比较子节点与父节点，最终批准观众真正会看到的资产，而不是那条恰好生成它的会话链。

参考资料

1. Google，Build with Gemini Omni 1.1 Flash
2. Google AI for Developers，Generate and edit videos with Gemini Omni Flash
3. Google AI for Developers，Interactions API
4. Google AI for Developers，Zero data retention in the Gemini Developer API
5. Google AI for Developers，Gemini Developer API pricing
6. Google DeepMind，SynthID
7. Coalition for Content Provenance and Authenticity，C2PA Technical Specification 2.4
8. NIST，Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
9. Huang 等，VBench: Comprehensive Benchmark Suite for Video Generative Models
10. He 等，VideoScore: Building Automatic Metrics to Simulate Fine-grained Human Feedback for Video Generation
11. Google Gemini Apps Help，Verify AI-generated images, videos, and audio