来源：市场资讯
（来源：科技行者）
你有没有想过这样一件事：你在直播打游戏，弹幕突然刷屏说"换个赛博朋克风格试试"，你嘴上答应了，但游戏画面能立刻变成赛博朋克吗？
当然不能。现实里你只能继续用原来的画风打完这局。但如果这是一段正在被AI实时生成的视频呢？如果观众的这句弹幕能立刻让接下来的画面风格开始转变，而且这种转变还能一直持续下去，直到下一条弹幕说"换成水墨风"？
这听起来像是科幻电影的设定，但2026年这篇来自浙江大学和阿里巴巴团队的论文，正是在解决这个问题。他们给这个任务起了个名字，叫无限视频编辑（Infinite Video Editing）。这篇论文提出的方法叫InfinityEdit，我们今天就来聊聊这背后的门道。
先说清楚一件事,你可能觉得"视频编辑"这个词已经很成熟了,市面上一堆AI工具都能改视频风格。但这里有个关键的错位,几乎所有现有方法解决的都是另一个问题。
现有的视频编辑,压根不是给直播用的
目前主流的指令式视频编辑方法,比如InsViE、Ditto、OpenVE这些工作,遵循的是一种叫"原位编辑"（in-place editing）的范式。
原位编辑：给定一段已经拍好、长度固定的源视频，模型对这段视频进行逐帧重写，输出的编辑结果和源视频时长完全一样，时间轴也完全对齐。你可以理解成，它是在"改写一份已经写完的文档"，而不是"继续写一份还没写完的文档"。
这套逻辑对付一段已经录制好的短视频完全没问题。你有一段5秒的视频，想把风格从写实改成动画，模型把这5秒逐帧改一遍，输出还是5秒，时间对得上，逻辑很顺。
但问题来了：如果这个视频是正在直播的、还没结束的、未来还会不断生成新内容的呢？
比如你在看一场正在进行的实况游戏直播，或者一个AI正在源源不断地生成一段长视频的镜头运动画面。这时候你说"把风格换成美式漫画"，你要编辑的其实不是已经播完的那一段，而是还没发生的、即将到来的画面。这些帧此刻根本不存在，模型无法对着一堆不存在的像素做逐帧重写。
这就是论文里反复强调的一个核心矛盾：编辑指令针对的是尚未生成的未来内容，而不是已经录制好的静态素材。
论文把这种全新的任务定义为无限视频编辑：给定一段前序视频片段和一条编辑指令，模型要生成的是紧接着这段前序视频之后的、满足编辑要求的新片段。而且这个过程会反复发生,编辑指令会像连续的弹幕一样一条接一条到来,模型要一直跟着编辑下去,理论上没有尽头。
这个定义读起来简单，但真正做起来会遇到两个特别棘手的难题，作者花了大量篇幅讲清楚这两点。
难题一：编辑出来的东西得是"接着讲故事"，不能是"另起一段"
第一个难题叫忠实延续（faithful continuation）。
这里有个特别反直觉的地方。你可能觉得，既然是编辑，那不就是把某个东西改一改吗？改风格、改镜头，逻辑应该跟原位编辑差不多才对。但无限视频编辑难就难在，输出的新片段和输入片段之间根本没有帧对帧的对应关系。你不能说"新视频的第10帧对应旧视频的第10帧，把它改一改"，因为新视频的每一帧都是全新生成的，压根不存在这种对应。
模型必须做的事情是：从前面那段视频的结尾自然地往下"生长"出新内容，同时让这段新内容符合编辑要求。
而更麻烦的是，哪些东西该保留、哪些该改变，这个标准会随着编辑类型的不同而完全不同。举个例子，如果编辑指令是"换成漫画风格"，那么画面里角色的动作、镜头的运动轨迹应该保持不变，只有画面的视觉质感应该变。但如果编辑指令是"镜头往上移"，那么角色长什么样、场景是什么应该保持不变，只有镜头的视角应该变。
这就好比你请一个作家帮你续写小说的下一章，同时提出一个要求："把故事的语气从悬疑改成幽默"。这时候，故事里的人物、地点、情节走向应该保持不变，只是叙述的语气变了。但如果你的要求是"把主角的视角改成配角的视角"，那这次该保持不变的是故事内容和语气，改变的是叙述立场。同样是"接着往下写",但每次该守住的边界完全不一样。如果作家不理解这个区别,乱套一个统一模板去续写,轻则违和,重则整个故事直接崩掉。
难题二：编辑久了会不会"越改越走样"
第二个难题叫累积编辑下的稳定性（stability under repeated editing）。
这个问题的根源在于一个残酷的现实：每一次生成出来的编辑结果，会变成下一次编辑的输入历史。
自回归生成：一种生成方式，模型把已经生成好的内容当作"历史"喂给自己，用来预测接下来该生成什么，一步接一步地往前滚动生成，而不是一次性生成全部内容。
这个机制本身没问题，问题在于错误会累积。如果第一次编辑生成的画面有一点点瑕疵，比如某个物体的边缘有点模糊，这个瑕疵会被当作"干净的历史"喂给第二次编辑，第二次编辑的输出可能会把这个瑕疵放大一点，然后这个放大后的瑕疵又变成第三次编辑的历史……
这就好比传话游戏，第一个人说的话本来是准确的，但每传一次都会有一点点失真，传了十个人之后，原话可能已经面目全非了。区别在于，这里不只是信息在失真，画质本身也在跟着失真，而且编辑指令还在不断往里面加新的变化。论文里用实验数据证实了这个担忧不是空穴来风：在他们的对比实验中，好几个基线方法的"美学质量"分数会随着编辑轮次增加而持续下降，掉了0.02到0.04分，而InfinityEdit几乎纹丝不动，波动接近于零。
搞清楚了这两个难题之后，再回头看论文的方法设计，很多选择就变得有理有据了。
InfinityEdit怎么解决这两个难题：冻住大脑，只训练一个"点火器"
先说结论式的设计思路：这篇论文没有从头训练一个全新的模型，而是找了一个已经很擅长"无限生成长视频"的现成模型，把它整个冻住不动，只在旁边加装一个很小的、可训练的"编辑适配器"（edit adapter）。
这个被冻住的基础模型叫Helios，是一个140亿参数规模的自回归视频扩散变换器（简单理解，就是一个专门用来一段一段生成长视频的AI模型），它有个蒸馏版叫Helios-Distilled，能做到少步数、近乎实时的推理。Helios的核心本领是能一段一段地（论文里叫"chunk"，也就是"块"）连续生成很长的视频而不崩溃，它靠的是把历史帧压缩成一个多尺度的记忆结构，再加上一个固定的锚点帧来防止画面越漂越远。
但是Helios本身完全不懂什么叫"编辑指令"，它只会闷头往下续写，你换个提示词它顶多是把新提示词当成新的场景描述来生成，它理解不了"这是对当前内容的一次修改"这种语义。
为什么不干脆全量微调整个Helios模型，让它自己学会编辑？论文里给出了理由，全量微调成本太高，而且很可能会把Helios原本训练出来的、"生成长视频不崩溃"这个宝贵能力给带偏。这就好比你请了一位已经练就一手好厨艺、能连续做出十道菜不失水准的大厨，现在你想让他多学一道新菜。你有两个选择：一是把他送回厨师学校重新培训整套厨艺体系，风险是他原来那手绝活可能会被打乱；二是给他配一个专门的小助手，负责在他做菜过程中随时递上一小撮新调料，大厨该怎么颠勺、怎么控火完全不用变。论文选的是后者，冻住大厨的全部本领，只训练那个小助手。
这个小助手就是编辑适配器，它由三个注意力模块组成，缺一不可。
编辑点火适配器（Edit-Ignition Adapter）：本论文提出的核心组件，一个轻量级的、可插拔的模块，负责把编辑指令"点燃"进正在生成的视频画面里，同时保持基础模型原本的生成能力不被破坏。
### 历史交叉注意力：让新画面知道"我是从哪儿接上的"
第一个模块叫历史交叉注意力（History Cross-Attention），作用是让正在生成的新片段能"回头看"输入的历史帧，从而知道自己应该从哪个内容基础上继续。
交叉注意力（Cross-Attention）：一种让模型在生成内容时，主动去"查询"另一份信息（比如历史帧或文字指令）的机制，可以理解成模型一边生成一边不断回头核对参考资料。
具体来说，这个模块只让新片段最前面几帧去查询历史帧的信息，而不是让整段新内容全都去查。这样做的好处是省计算量，而且前几帧吸收到的历史信息，会在接下来的模块里自然传递给后面的帧。这就好比接力赛跑，你不需要让全体队员都先跑去摸一下起跑线才出发，只要第一棒的选手准确接住了接力棒，后面的队员只需要跟着往前跑就行。
### 时序因果自注意力：信息只能往前传，不能往后串
第二个模块叫时序因果自注意力（Temporal Causal Self-Attention），它的任务是把第一个模块吸收到的历史信息，沿着时间轴，从早的帧传递到晚的帧。
这里有个关键限制，叫因果（causal），意思是后面的帧可以参考前面的帧，但前面的帧不能反过来受后面帧的影响。
因果掩码（Causal Mask）：一种数学上的"信息阀门"，强制规定信息只能从过去流向未来，不能让模型在生成第5帧时"偷看"还没生成的第10帧。
如果不设这个限制会怎样？那新片段的第一帧就有可能被后面还没生成的第100帧"倒着影响"，这在逻辑上是荒谬的，因为生成是按时间顺序一帧一帧发生的，你不可能让还不存在的未来帧影响已经生成的过去帧。这就像你写日记，今天的日记内容不能被明天还没发生的事情所左右，日记必须严格按照发生的先后顺序往前写，写完今天的才能写明天的，绝不能反过来。
### 编辑交叉注意力：把那句"换个风格"真正塞进画面里
第三个模块叫编辑交叉注意力（Edit Cross-Attention），这才是真正让编辑指令发挥作用的地方。当前正在生成的每一个画面块，都会主动去查询这条编辑指令的语义信息，然后把查到的结果加回到自己身上。
这三个模块被打包成一个适配器块，插在Helios每一层变换器的后面。而且这些适配器块在训练一开始，会被设置成"零初始化"，也就是刚开始训练时它们完全不改变任何东西，输出等于什么都没做。随着训练推进，它们才慢慢学会怎样在原有画面基础上加一点"编辑残差"。
零初始化（Zero Initialization）：把新加入模块的输出权重初始设为零，让这个模块在训练刚开始时相当于"什么都不做"，之后再慢慢学会施加恰当的影响，这样可以避免新模块一上来就把原模型的能力破坏掉。
这个设计思路其实很聪明，好比你想给一台运转正常的老机器加装一个新功能按钮，但你又怕这个新按钮不小心碰到会打乱机器原有的运转逻辑。解决办法是，先把这个新按钮焊死在"不生效"的位置上，然后一点一点地、小心翼翼地调试它，直到确认按下去只会增加想要的新功能，而不会干扰原来任何一个齿轮的转动。
光有架构不够，数据从哪儿来
看到这里你可能会问，这套三段式的注意力机制听起来挺合理，但模型总得靠训练数据学会这些东西吧？现实里根本不存在现成的"前序片段+编辑指令+编辑后延续片段"这种三元组数据集。
论文团队于是自己动手设计了一整套数据采集流程。
第一步是生成编辑指令。他们从一个叫VAP（Video-As-Prompt）的相关工作里借来了一批基础的编辑类型作为模板，但这些类型都是抽象的短语，比如"风格转变"，不能直接拿来用。团队先把源视频按照主要实体（比如人物、风景）分组，再给每组视频配上合适的编辑类型，然后用Gemini 3 Flash（谷歌的一个多模态大语言模型）把简单的编辑类型扩展成具体、详细的编辑指令。
第二步是生成对应的目标视频，这一步最考验设计巧思。因为编辑类型不同，处理方式也完全不同。对于风格类编辑，比如把画面变成美式漫画风，团队先用一个叫Qwen-Image-Edit-2511的图像编辑模型，把源视频最后一帧直接改成新风格的图片，再用这张改过的图片作为起点，生成后续视频。而对于镜头运动类编辑，比如"往上移"，源视频的最后一帧则原封不动保留，因为镜头运动不应该在衔接处就突兀地改变画面内容，只应该改变视角。
图像到视频生成（Image-to-Video，简称I2V）：一种AI生成方式，输入一张静态图片，模型据此生成一段动态视频，论文里用的是Wan2.2-I2V-A14B这个模型来完成这一步。
第三步是数据后处理，团队请了20名人工标注员，从四个维度给生成的三元组打分：编辑是否准确对齐了指令、编辑内容是否和原视频保持连贯、生成内容是否合理（有没有奇怪的人物多长了只手之类的问题）、以及原始素材本身的画质好不好。只有高质量的三元组才会被留下来训练模型。
推理阶段：只在"点火"那一刻用适配器，剩下的交给冻住的大脑
训练好了适配器,接下来是怎么用它。这里有个特别值得说的设计,叫"先点火，后延续"（ignite-then-continue）策略。
具体来说，当一条编辑指令到来时，适配器只会被激活一次，用来生成紧接着这条指令的第一个视频块，这个过程叫作点火（ignition）。一旦这第一个编辑过的块生成出来，适配器就立刻关闭，后面所有的块全部交还给原本冻住的Helios模型去自动续写，而Helios续写的依据，正是刚才那个已经带有编辑效果的历史块。
为什么要这样设计,而不是让适配器一直保持开启状态,持续参与每一个块的生成?
答案藏在Helios的工作机制里。Helios每生成一个新块，都是拿"最近生成好的历史内容"作为参照来续写下一个块的。既然第一个编辑过的块已经进入了历史窗口，那么后面的续写自然会"继承"这个编辑效果，就像滚雪球一样往下滚。既然编辑效果已经通过第一块传递下去了，就没必要每一块都劳烦适配器出马，这样既省了计算量，又让Helios原本擅长的"长视频不崩溃"的能力得以完整保留，不会被适配器的持续介入打乱节奏。
这就好比点篝火，你只需要用打火机点燃第一簇火苗，之后火焰会自己顺着木柴蔓延下去，你不需要一直拿着打火机跟着火苗到处点。如果你非要一直拿着打火机跟着烧，反而可能把整堆柴火的燃烧节奏搞乱。
除了这个"点火后放手"的策略，论文还提到了两个配套的细节设计。
一个是低噪声采样补细节。扩散模型生成图像有个特点，噪声越低的阶段越是在打磨精细的画面细节。有些编辑指令关注的恰恰是这些细节层面的变化，为了确保这些细节能被准确表达，团队在点火那一步额外加了一个接近零噪声的去噪步骤，让适配器能对着接近成品的画面再精细打磨一遍。
另一个是历史窗口滑动和锚点重置。Helios靠一个滑动窗口来管理历史记忆，只保留最近的一段内容，超出窗口的旧内容会被丢弃，这样才能保证内存开销不会随着视频越来越长而无限膨胀。同时Helios还有一个锚点帧（anchor frame），相当于一个"参照物"，防止生成内容随着时间推移越漂越远、逐渐失控。InfinityEdit的做法是，每次点火生成出新的编辑内容后，就把这个锚点帧重置成新编辑内容的第一帧。这样一来，后续的续写会以"新编辑后的样子"为基准，而不是继续用最初源视频的样子当基准，避免了内容慢慢"漂移"回原来的样貌。
锚点帧重置：每次编辑发生后，把用来防止画面漂移的参照帧更新成刚编辑完的画面，这样后续生成才会以"编辑之后的世界"为准，而不是一直惦记着"编辑之前的世界"。
如果不重置锚点会怎样？续写过程会一直参照最初那个没被编辑过的画面，久而久之，新生成的内容很可能悄悄地往回漂，慢慢淡化掉编辑效果，甚至完全遗忘掉编辑指令曾经发生过。这就好比你把一个房间刷成了蓝色，但你桌上一直摆着一张房间原来是白色时拍的照片当参考。时间长了，你在做后续装修决策时可能会不自觉地朝着"白色房间"的印象去调整，结果房间的颜色慢慢又漂回了白色附近。而把参照物换成刷完蓝色之后拍的新照片，后续的每一个决策才会真正以"蓝色房间"为基准。
训练细节里的巧思：怎么让适配器既学会编辑,又不崩溃
除了架构和推理策略,论文在训练环节还埋了几个不太显眼但很关键的设计。
第一个是历史腐蚀（History Corruption）。训练的时候，模型看到的历史帧永远是"干净"的真实数据，但实际推理的时候，模型看到的历史却是自己上一轮生成出来的、可能带瑕疵的画面。这种训练和推理之间的落差，学术上叫曝光偏差（exposure bias），是自回归生成模型的老大难问题。InfinityEdit的做法是，训练时故意往历史帧里掺一点噪声，让模型提前"见识"过不完美的历史输入是什么样子，这样它到了推理阶段面对自己生成的、带瑕疵的历史时，才不会手足无措。
这有点像给运动员做适应性训练。如果你只在风和日丽的室内场馆训练，到了真正比赛那天遇上大风大雨，运动员大概率会发挥失常。但如果平时训练就故意安排一些风雨天气下的模拟训练，运动员遇到恶劣天气时反而能从容应对。
第二个是混合高斯噪声采样。原本Helios用的是一种"金字塔式"的去噪调度，噪声越高对应越粗糙的画面布局，噪声越低对应越精细的画面细节，这套调度对生成任务很合适，因为生成天然就是从粗糙到精细。但编辑任务不一样，编辑可能针对视角、可能针对整体外观、也可能针对细枝末节，不应该被绑死在某个固定的噪声阶段。所以团队重新设计了一个专门的高斯混合分布，让训练时采样到的噪声值更集中在推理时会真正用到的那几个点上。
第三个是两阶段课程学习。第一阶段让模型均匀地学习各种噪声水平下的编辑能力，确保基础打得扎实；第二阶段则把训练重心往中低噪声区间偏移，同时给块里越靠后的帧分配越高的损失权重，因为这些帧离最初的历史锚点更远，也更容易在漫长的生成链条里丢失质量。这种由浅入深、由宽泛到精细的训练安排，本质上和人类学一门新技能的过程有点像，先把各个基本动作都摸一遍，再针对薄弱环节反复打磨。
实验结果说了什么
说了这么多设计思路,最终还是要看实际效果站不站得住脚。论文因为这是一个全新任务,现成的评测基准根本不存在,所以团队自己搭了一个基准,从UltraVideo数据集里挑了200个源视频,覆盖人物、风景等五大类实体,每个视频配上三条连续的编辑指令,一共覆盖15种编辑类型,分成实体变换、风格化、镜头运动、动作迁移四大类。
对比的基线方法分成三类：纯粹的原始Helios骨干网络（不加任何适配器，直接替换提示词）、原位编辑代表方法（Lucy-Edit、SANA-Streaming）、以及提示词切换类方法（Anchor-Forcing、Infinity-RoPE）。
VBench：一套通用的、不需要人工参与的视频生成质量自动评测工具集，能从多个维度给生成的视频打分，比如镜头运动准确度、动作流畅度、画面闪烁程度等。
先看VBench客观指标的结果：
| 方法类别 | 方法 | 镜头运动准确度 ↑ | 动作平滑度 ↑ | 时序闪烁抑制 ↑ |
| 纯骨干网络 | Helios-Base | 0.5494 | **0.9869** | 0.9641 |
| 原位编辑 | Lucy-Edit | 0.5062 | 0.9808 | 0.9616 |
| 原位编辑 | SANA-Streaming | 0.5432 | 0.9858 | 0.9631 |
| 提示词切换 | Anchor-Forcing | 0.4815 | 0.9775 | 0.9536 |
| 提示词切换 | Infinity-RoPE | 0.3580 | 0.9671 | 0.9344 |
| 本文方法 | InfinityEdit | **0.7654** | 0.9833 | **0.9660** |
InfinityEdit在镜头运动准确度上大幅领先第二名，差距达到0.22分，说明它对方向性镜头编辑（比如"往上移"、"拉远镜头"）的控制力明显更强。而在时序闪烁抑制上，它评测的是第三轮编辑之后的表现，也就是最容易出现累积误差的地方，InfinityEdit依然拿到了最好成绩，说明它在编辑链条走得很远之后依然没有明显崩坏。
再看更综合的VLM评判（用Gemini-3.5-Flash充当裁判，从四个维度给1到5分打分）：
| 方法类别 | 方法 | 编辑忠实度 ↑ | 视觉质量 ↑ | 内容保留度 ↑ | 跨轮连贯性 ↑ |
| 纯骨干网络 | Helios-Base | 2.637 | 2.850 | 2.790 | 2.885 |
| 原位编辑 | Lucy-Edit | 2.863 | 2.723 | 2.665 | 2.560 |
| 原位编辑 | SANA-Streaming | 3.303 | 3.093 | 3.060 | 3.030 |
热门跟贴