1. 视频大模型去路人这件事，到底在解决什么痛点
做短视频和商业拍摄的朋友应该都有过这种经历：好不容易等到一个光线、构图、人物状态都到位的镜头，结果画面边缘杵着两个路人，或者背景里有个不该出现的杂物。传统做法要么是重新布景重拍，要么是后期一帧一帧抠图修补，一条十几秒的素材修下来，半天时间就没了。我最早接触这类需求是在给一个本地生活商家拍探店视频的时候，门口来来往往全是人，客户又要求画面干净，当时用传统跟踪遮罩的方式硬啃，效率低到让人怀疑人生。
这两年视频大模型的能力上来了，尤其是具备时序一致性的视频生成与编辑模型，让“去路人”这件事从手工活变成了工作流。核心逻辑其实不复杂：把视频按帧拆开，让模型理解每一帧里哪些是主体、哪些是干扰元素，然后基于前后帧的时序关系，把干扰区域用合理的背景内容补全，最后再合成回视频。听起来简单，但真正落地成一条稳定可复用的工作流，中间要踩的坑相当多。
这篇文章我想聊的就是这套工作流的完整搭建思路。它适合谁看？一是做短视频内容、电商素材、商业拍摄的从业者，二是对AI视频编辑感兴趣、想自己搭一套自动化流程的技术玩家，三是手里有批量素材需要处理、想用API把流程串起来的小团队。我会把方案选型的考量、核心参数的设置、实操步骤、以及我踩过的那些坑都摊开讲，尽量让你看完就能照着搭。
需要先说明一点：视频大模型这个领域迭代极快，具体模型名称和接口参数可能几个月就变一轮，所以我更侧重讲清楚“为什么这么设计”和“每个环节的判断依据”，这样即使工具换了，你也能快速迁移。
2. 整体工作流设计与方案选型思路
2.1 为什么不做“一步到位”而是拆成流水线
很多人第一反应是：现在不是有那种直接输入视频、输出干净视频的端到端模型吗？为什么还要拆成工作流？我实测下来的结论是，端到端方案在简单场景下确实省事，但一旦遇到复杂背景、多路人、镜头运动剧烈的情况，稳定性和可控性就崩了。拆成流水线的好处是每个环节都能单独调参、单独替换、单独排查问题。
我的工作流大致分成五个阶段：素材预处理、干扰区域识别、时序信息提取、背景补全生成、合成与质检。每个阶段之间用中间产物衔接，比如帧序列、遮罩图、深度图、光流图这些。这样做的好处是，如果最终效果不理想，你能快速定位到底是识别错了、还是补全崩了、还是合成时色彩对不上。
提示：不要一上来就追求全自动。先把每个环节手动跑通一遍，确认每个中间产物是对的，再去考虑用脚本或工作流引擎串起来。我见过太多人直接上自动化，结果出错时完全不知道是哪一步的问题。
2.2 模型选型：视频大模型和图像模型怎么配合
这里有个关键判断：去路人本质上是一个“视频修复”任务，它既需要图像级的精细补全能力，又需要视频级的时序一致性。纯图像模型逐帧处理，会出现闪烁、纹理跳变；纯视频模型虽然时序稳，但在局部细节上往往不如专门的图像修复模型。
我的做法是混合使用：用视频大模型负责理解时序和生成主体运动，用图像修复模型负责单帧的精细补全，两者通过光流和遮罩做对齐。具体来说，视频大模型输出的是“这个区域在时间维度上应该长什么样”的指导信息，图像模型在此基础上做像素级填充。这样既保证了不闪烁，又保证了单帧质量。
选型时我重点看三个指标：一是模型对遮挡区域的理解能力，二是生成内容的纹理合理性，三是推理速度。速度这块要特别提醒，视频模型的计算量是图像模型的几十倍，如果你要处理的是几分钟的长视频，一定要考虑分段处理和显存占用。
2.3 提示词在视频去路人里的作用被低估了
很多人以为去路人就是纯算法活，跟提示词没关系。实际上，提示词在这里的作用是告诉模型“你要补的是什么”。比如背景是一面砖墙，你提示“红砖墙面，自然光照，轻微颗粒感”，模型补出来的纹理就会更贴合；如果你什么都不说，模型可能补出一片模糊的色块。
我一般会准备两类提示词：一类是场景描述词，描述背景的材质、光照、色调；另一类是负面提示词，明确告诉模型不要生成什么，比如“不要出现人物、不要出现文字、不要出现明显重复纹理”。负面提示词在去路人场景里特别重要，因为模型有时候会“脑补”出新的路人，这就很尴尬了。
2.4 工作流引擎的选择：轻量级还是重型
如果你只是偶尔处理几条视频，用ComfyUI这类节点式工具手动跑就行，直观、好调试。但如果你要批量处理，或者要把流程嵌入到自己的业务系统里，那就需要考虑用API把各个环节串起来。我目前的做法是：前期调试用节点式工具，确认参数后把每个环节封装成独立的API调用，用一个轻量级的调度脚本串起来。
这里要提一下上下文长度的问题。有些工作流引擎在处理长视频时，会把所有帧的信息塞进一个上下文里，很容易超出模型的token限制。我的经验是，按镜头切分，每个镜头单独处理，镜头之间的衔接用重叠帧做过渡。这样既避免了上下文超长，又保证了镜头切换处的连贯性。
3. 核心环节拆解与关键参数实操
3.1 素材预处理：帧率、分辨率与色彩空间
预处理这一步看着简单，但参数设错后面全白搭。首先是帧率，我一般会把素材统一转成24fps或30fps再处理，太高的帧率会让计算量翻倍，而且很多视频模型对高帧率的支持并不好。如果你的原始素材是60fps，建议先降帧，处理完再考虑要不要补帧回去。
分辨率方面，我的建议是不要超过模型的原生训练分辨率。比如模型是按1080p训练的，你硬塞4K进去，效果反而会下降，因为模型没见过那么大的图。正确做法是先缩到1080p处理，处理完再用超分模型放大回去。色彩空间也要统一，我习惯转成sRGB，避免不同软件之间色彩解释不一致导致合成后偏色。
# 用ffmpeg做预处理，统一帧率和分辨率 ffmpeg -i input.mp4 -vf "fps=30,scale=1920:1080:flags=lanczos" -c:v libx264 -crf 18 -pix_fmt yuv420p preprocessed.mp4注意：预处理时不要做过度压缩，crf值建议在16到20之间。压缩太狠会丢失细节，模型补全时就没有足够的参考信息。
3.2 干扰区域识别：手动遮罩还是自动分割
识别路人这件事，自动分割模型现在已经很强了，但在复杂场景下还是会有漏检和误检。我的策略是“自动为主，手动为辅”：先用分割模型跑一遍，生成初步遮罩，然后人工快速过一遍，把漏掉的路人补上，把误判的区域去掉。
分割模型的选择上，我倾向于用支持视频时序的分割模型，而不是逐帧分割。逐帧分割最大的问题是帧与帧之间的遮罩边缘会抖动，导致后续补全时边缘出现闪烁。支持时序的模型会利用前后帧信息平滑遮罩，效果稳定得多。
遮罩的羽化程度也是个关键参数。羽化太小，合成时边缘会有硬边；羽化太大，会把主体也吃掉一部分。我一般设置3到5个像素的羽化，具体看分辨率。如果是1080p，3像素左右比较合适；4K的话可以到6到8像素。
3.3 时序信息提取：光流与深度图的配合
光流图告诉模型“这个像素在下一帧会移动到哪里”，深度图告诉模型“这个区域离镜头有多远”。这两个信息结合起来，模型才能正确理解遮挡关系。比如一个路人从主体前面走过，光流能捕捉到运动方向，深度图能判断谁在前谁在后，这样补全时就不会把背景错误地补到前景上。
光流计算我一般用RAFT这类成熟方案，精度够用，速度也能接受。深度图用单目深度估计模型，虽然精度不如激光雷达，但对于视频补全来说足够了。这里有个细节：光流和深度图的分辨率要和原视频对齐，否则后续做遮罩变换时会错位。
3.4 背景补全生成：分块处理与重叠融合
这是整个工作流里最吃算力的一步。我的做法是把视频按时间切成若干段，每段之间保留10到15帧的重叠。每段单独送进模型生成，生成完再用重叠帧做融合。融合时用简单的线性过渡就行，不需要太复杂的算法，因为重叠帧的内容本身就很接近。
生成时的提示词要针对每个镜头单独写。比如镜头一是室内咖啡馆，镜头二是室外街道，提示词就要分别描述。我一般会先看一遍素材，把每个镜头的场景特征记下来，然后批量生成提示词。这一步看起来繁琐，但实测下来对最终质量的提升非常明显。
3.5 合成与质检：色彩匹配和边缘处理
合成不是简单地把生成区域贴回去就完事了。首先要做色彩匹配，因为模型生成的内容和原始素材在色调上可能有细微差异。我一般用直方图匹配或者简单的色彩迁移算法，把生成区域的色彩分布对齐到原始素材。
边缘处理也很关键。即使遮罩做了羽化，合成后边缘还是可能有轻微痕迹。我的做法是在合成后，对边缘区域做一个窄带的高斯模糊，宽度大概2到3个像素，这样能把残余的硬边柔化掉。质检环节我会抽帧检查，重点看三个方面：有没有闪烁、边缘有没有鬼影、背景纹理有没有明显重复。
4. 完整实操流程与参数配置实录
4.1 环境准备与依赖安装
我现在的测试环境是一台带24G显存的机器，处理1080p、30秒左右的视频基本够用。如果你显存小一些，可以把视频切得更碎，或者降低处理分辨率。依赖方面主要是PyTorch、OpenCV、以及各个模型对应的推理库。
# 创建虚拟环境 python -m venv venv source venv/bin/activate # 安装核心依赖 pip install torch torchvision opencv-python numpy scipy pip install raft-optical-flow # 光流计算 pip install depth-estimation # 深度估计提示：不同模型对PyTorch版本的要求可能不一样，建议先确定你要用的模型，再按它的要求装环境。我踩过最坑的一次是装完发现某个模型只支持特定版本的CUDA，又全部重装。
4.2 分步骤操作：从原始素材到成品视频
第一步，预处理。把素材统一成30fps、1080p、sRGB。这一步用ffmpeg一条命令搞定，前面已经给过示例。
第二步，分割遮罩。我用的是支持视频时序的分割模型，输入是预处理后的视频，输出是每帧的遮罩图。这里要注意，遮罩图要保存成单通道的PNG序列，方便后续处理。
第三步，计算光流和深度。光流用RAFT，深度用单目深度估计模型。这两个计算都比较耗时，建议用GPU加速。计算完把结果保存成npy文件，后续直接读取。
第四步，分段生成。按镜头切分视频，每个镜头单独送进视频大模型。提示词按镜头场景写，负面提示词统一加上“人物、文字、重复纹理”。生成时设置重叠帧为12帧。
第五步，合成。把生成结果按遮罩贴回原始帧，做色彩匹配和边缘柔化。最后用ffmpeg合成回视频，编码参数和预处理时保持一致。
4.3 关键参数的计算与选择依据
这里重点说几个容易设错的参数。首先是重叠帧数，我试过6帧、12帧、24帧，结论是12帧在大多数场景下够用。太少会导致融合处有跳变，太多会浪费算力。具体可以根据镜头运动速度调整，运动快就多留几帧。
其次是遮罩羽化半径。这个和分辨率强相关，我的经验公式是：羽化半径 = 分辨率宽度 / 640。比如1920宽就是3像素，3840宽就是6像素。这个公式不是绝对的，但作为起点很好用。
再就是生成时的采样步数。步数太少细节不够，步数太多速度慢且可能过拟合。我一般设20到30步，具体看模型。有些模型有推荐的步数范围，优先按推荐来。
4.4 批量处理的调度与资源管理
如果你要处理大量视频，调度就很重要了。我的做法是用一个简单的任务队列，每个任务包含视频路径、镜头切分信息、提示词、参数配置。调度器按顺序取任务，处理完一个再取下一个，避免显存爆掉。
资源管理上，我建议把光流和深度计算放在一个阶段批量做完，再统一做生成。因为生成阶段最吃显存，如果和光流计算混在一起，容易出现显存碎片。分开做的话，每个阶段都能把显存用满。
# 简单的任务调度示例 import queue import threading task_queue = queue.Queue() def worker(): while not task_queue.empty(): task = task_queue.get() process_video(task) task_queue.task_done() # 启动多个worker，但要注意显存限制 for i in range(2): # 根据显存决定并发数 t = threading.Thread(target=worker) t.start()注意：并发数不是越多越好。我试过开4个并发，结果显存直接爆了，反而比单线程还慢。建议先测单任务显存占用，再决定并发数。
5. 常见问题与排查技巧实录
5.1 生成结果闪烁、跳变怎么排查
闪烁是视频去路人最常见的问题，原因通常有三个：一是遮罩在帧间不稳定，二是光流计算错误，三是生成时没有利用时序信息。排查顺序建议从遮罩开始，把遮罩序列导出来逐帧看，如果边缘在抖，那就是分割模型的问题，换支持时序的模型或者加平滑滤波。
如果遮罩没问题，就看光流。光流错误通常出现在遮挡边界和快速运动区域。可以可视化光流图，正常的光流应该是平滑的，如果出现大片异常值，说明光流估计失败了。这时候可以尝试降低运动速度，或者用更鲁棒的光流模型。
5.2 背景补全出现“鬼影”或重复纹理
鬼影一般是深度估计错误导致的，模型把前景的背景补到了错误的位置。解决办法是检查深度图，确保前景和背景的深度关系是对的。如果深度图本身就不准，可以尝试用多帧深度做融合，或者手动修正关键帧的深度。
重复纹理是生成模型的通病，尤其是背景是砖墙、草地、瓷砖这类有规律纹理的时候。我的应对方法是在提示词里明确描述纹理的随机性，比如“自然砖墙，砖块大小略有差异，有轻微色差”。另外可以在生成后加一点噪声，打破规律性。
5.3 处理速度太慢的优化思路
速度慢通常卡在生成阶段。优化方向有几个：一是降低处理分辨率，先低分辨率生成再超分；二是减少采样步数，但要注意质量下降；三是用更小的模型，如果场景简单，没必要上最大的模型；四是分段并行，但要注意显存。
我实测下来，把分辨率从1080p降到720p，速度能快一倍多，质量下降在可接受范围内。如果最终输出是1080p，可以用超分模型补回来，整体效果比直接1080p生成差不了太多。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决思路 |
|---|---|---|---|
| 画面闪烁 | 遮罩帧间不稳定 | 导出遮罩序列逐帧检查 | 换时序分割模型或加平滑 |
| 边缘硬边 | 羽化不足 | 检查遮罩边缘 | 增大羽化半径 |
| 鬼影 | 深度估计错误 | 可视化深度图 | 多帧融合或手动修正 |
| 纹理重复 | 生成模型过拟合 | 观察背景区域 | 提示词增加随机性描述 |
| 色彩偏差 | 色彩空间不一致 | 对比生成区域和原始区域 | 统一色彩空间并做直方图匹配 |
| 速度过慢 | 分辨率或步数过高 | 监控各阶段耗时 | 降分辨率、减步数、换小模型 |
| 显存溢出 | 并发过高或分段过大 | 监控显存占用 | 降低并发、切碎分段 |
5.5 几个我踩过的坑和独家技巧
第一个坑是忽略了音频。去路人处理的是视频画面，但如果你直接处理带音频的视频，合成时音频可能会不同步。我的做法是先把音频分离出来，处理完画面再合回去，这样最稳妥。
第二个坑是过度依赖自动分割。有些场景下，路人穿的衣服和背景颜色很接近，自动分割会漏掉。这时候手动补几笔遮罩，效果比调半天参数好得多。
第三个技巧是关于提示词的。我发现把场景描述写得越具体，生成质量越高。比如不要写“室内”，要写“室内咖啡馆，木质桌面，暖色灯光，背景有书架”。模型对具体名词的理解比抽象形容词好得多。
第四个技巧是分段处理时的重叠帧不要用简单的复制粘贴，而是用光流做对齐后再融合。这样即使镜头有运动，重叠区域也能对齐得很好，融合痕迹几乎看不出来。
6. 工作流扩展与个人经验体会
6.1 从去路人扩展到其他视频编辑任务
这套工作流的框架其实很通用，把“干扰区域识别”换成其他目标，就能扩展到很多场景。比如去掉画面里的电线、广告牌、临时搭建物，甚至去掉画面里的某个特定物体。核心逻辑是一样的：识别、遮罩、时序分析、补全、合成。
我还试过用这套流程做视频去水印，效果也不错。区别在于水印通常是静态的，遮罩可以复用，处理速度会快很多。另外去水印对背景补全的要求更高，因为水印往往覆盖在复杂背景上。
6.2 和现有工作流工具的整合思路
如果你已经在用Coze、Dify这类工作流平台，可以把这套流程封装成几个节点。预处理和分割可以做成一个节点，生成和合成做成另一个节点，中间用文件存储或对象存储传递数据。这样你就能在平台上可视化地调度整个流程。
API调用方面，我建议把每个环节都封装成独立的HTTP接口，输入输出都用标准格式。这样不仅方便工作流平台调用，也方便你自己写脚本批量处理。接口的鉴权和限流也要考虑，尤其是如果你要把服务开放给团队其他人用。
6.3 关于成本和效率的几点真实感受
最后说点实在的。这套工作流跑下来，单条30秒视频的处理时间大概在10到20分钟，取决于分辨率和场景复杂度。电费和时间成本加起来，比请人手工修还是划算很多，尤其是批量处理的时候。
但我要提醒一句：不要为了自动化而自动化。如果只是偶尔处理一两条视频，手动用节点工具跑跑就行了，搭一套完整的API工作流反而更费时间。自动化只有在批量、重复的场景下才有价值。
另外，模型迭代很快，今天调好的参数可能下个月就不适用了。所以我的建议是，把精力花在理解原理和搭建框架上，具体参数保持灵活，随时准备调整。这套工作流的核心价值不在于某个具体模型，而在于这套“识别-分析-生成-合成”的思路，换什么模型都能套用。
