ComfyUI本地视频工作流：图生视频、TTS旁白与批量分镜实战

一段丛林悬疑剧本，配上“绿色贝雷帽小队进入山谷”这种画面感很强的开头，最适合拿来做本地 AI 视频工作流的练手素材：分镜要稳、镜头要连贯、旁白要能对上口型节奏，还得能批量跑。这次我们不聊怎么用云端会员生成几秒钟的 demo，而是把整条链路搬到本机——用 ComfyUI 作为工作流载体，接开源文生图模型出首帧、接开源图生视频模型出镜头、接本地 TTS 出旁白，最后用 ffmpeg 拼接成片。

这篇文章的重点是四件事：显存门槛到底卡在哪、镜头怎么保证前后一致、批量分镜怎么排队列、以及整个流程怎么用接口串起来。所有涉及具体显存数字的地方我都会写清楚“以本机实测为准”，因为视频模型迭代太快，同一个模型名不同精度、不同分辨率，占用能差出一倍。你照着这套流程走一遍，就能判断自己的卡能不能吃下这个活。

本文适合三类读者：手里有 12G 以上显存显卡、想试本地视频生成的同学；已经在用 ComfyUI 出图、想把工作流延伸到视频的创作者；以及需要把分镜批量生产做成半自动流水线的团队。纯虚构短片练习，不涉及任何真实人物和真实事件，这是前提。

1. 核心能力速览

先把这套工作流的能力边界摆出来，别看到“本地生成视频”就以为能一键出电影。下面是这套方案涉及的能力项，具体参数请对照你实际下载的模型版本，我会在每一项后面标明哪些是需要你本机实测的。

这张表里最容易误判的是“分辨率”和“显存需求”两行。很多人看到别人演示 720p 出片，就以为自己的卡也行，结果忽略了对方用的是量化权重或者更短的帧数。更稳妥的判断方式是：先用最低档分辨率跑通链路，确认模型能加载、能出帧、能保存，再逐级往上加，每次只改一个变量。

另一个容易被忽略的点是“镜头时长”。开源视频模型单次生成的长度通常有限，想要十几秒的连续镜头，主流做法是分段生成再拼接，或者用首尾帧衔接的方式让上一段的末帧成为下一段的首帧。这个做法能缓解跳变，但不会彻底消除，所以做分镜脚本的时候，就要有意识地把长镜头拆成短镜头，而不是指望模型一次给你一段完整的跟拍。

最后提醒一句，表格里所有“需以本机测试为准”的地方都不是免责话术。视频模型的显存占用和分辨率、帧数、采样步数、精度格式强相关，同一个模型在 fp16 和 fp8 下差出来的显存，足够决定你能不能跑 720p。所以后面第 7 节我会专门讲怎么观察和压降。

2. 适用场景与使用边界

先说适合谁。第一类是内容创作的“预演”需求：你脑子里有一个丛林场景，想快速看到画面长什么样，用来判断镜头调度和氛围对不对，这时候本地生成的草稿完全够用，哪怕细节有瑕疵，也比纯文字描述直观得多。第二类是风格测试：同一段分镜描述，换不同的基础模型和 LoRA，出片风格差异很大，本地跑不用担心次数限制，可以反复试。第三类是批量素材生产：比如一批短视频都需要类似的悬疑氛围空镜，把它做成模板化工作流，一次提交几十条，机器自己跑。

再说能解决什么问题。最直接的是成本可控：本地跑不吃按次计费，只有电费和硬件折旧。其次是数据不外传：你的剧本、你的参考图、你的旁白文本都在自己机器上，对于还没定稿的创意内容，这一点很重要。第三是可复现：工作流存成 JSON，参数写死在配置里，下次跑出来的是同一套逻辑，不会因为平台更新界面就找不到原来的按钮。

不适合的场景也得讲清楚。如果你要的是商业交付级的成片，需要严格的人物一致性、精确的口型同步、稳定的物理表现，那本地开源方案目前还撑不住，强行上会花掉大量返工时间。如果你需要的是实时生成，比如直播场景下的即时画面，那本地消费级显卡基本不用考虑，推理速度差得太远。如果你的素材涉及真实人物，尤其是可识别的面部，那不管技术上行不行，授权这一关先过。

边界这块我要多说两句，因为这类内容风险不小。第一，肖像和声音授权：如果你的旁白用了真人声音样本做参考音频，或者画面里出现了可识别的真人形象，必须拿到明确授权，哪怕是朋友帮你录的，也要白纸黑字说清楚用途范围。第二，版权素材：丛林、山谷、装备这类画面，如果是参考了某部影视作品的剧照去做图生图，注意不要直接复刻受版权保护的具体画面构图和美术设计，做风格参考和直接复制是两回事。第三，内容合规：虚构的悬疑、探险题材没问题，但不要生成宣扬暴力、危害公共安全的内容，也不要把现实中的人物、组织、地区往里套，纯虚构、纯练习，是这条工作流的安全前提。

还有一条实操层面的边界：本地生成的结果具有随机性，同一个提示词跑十次，十次都不一样。这不叫不稳定，这是扩散模型的固有特性。你要做的是通过固定随机种子、固定采样参数、固定参考图，把“随机”压缩到一个可控范围内，而不是期待它每次都精确复现。理解这一点，后面调参的时候心态会好很多。

3. 本地部署环境准备

环境这块我按“从下往上”的顺序讲，先确认底层，再装上层，避免装到一半发现驱动不对白忙一场。

操作系统建议用 Windows 10/11 或者 Ubuntu 22.04 这类主流版本，主要是因为社区教程和预编译轮子覆盖最全，遇到问题好搜。显卡方面，NVIDIA 的卡适配最成熟，AMD 和 Apple Silicon 也能跑，但可用节点和性能优化会打折扣，如果你是新配机器，优先 NVIDIA。显存方面，8G 可以尝试低分辨率、短帧数、量化权重的组合，12G 到 16G 是比较舒服的区间，24G 以上可以往高清和长时长走。这个区间是经验判断，具体到某个模型能不能跑，还是要看它的权重文件和官方说明。

软件层面，Python 建议 3.10 或 3.11，太新的版本有些依赖轮子还没跟上。CUDA 版本要和 PyTorch 对应，装之前先看 ComfyUI 当前版本推荐的组合，别自己乱配。磁盘空间要留足，视频模型的权重文件动辄几个 G 到十几个 G，再加上中间产物和输出视频，建议单独留一块盘，至少 100G 起步。模型文件、输入素材、输出结果分三个目录放，这一点后面第 9 节还会强调。

具体到检查清单，装之前先跑一遍这些：

bash复制# 检查显卡和驱动
nvidia-smi

# 检查 Python 版本
python --version

# 检查 PyTorch 是否识别到 GPU
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

torch.cuda.is_available() 返回 True 才算过第一关。如果返回 False，先别急着装 ComfyUI，回去查驱动和 CUDA 版本匹配，这一步没通，后面全是白费。

然后是端口占用检查。ComfyUI 默认端口是 8188，如果你机器上已经跑着别的服务，启动会失败或者串到别的界面上去。检查方式：

bash复制# Linux / macOS
lsof -i :8188

# Windows PowerShell
netstat -ano | findstr :8188

端口被占了不一定要杀掉原来的进程，换个端口启动就行，命令里加 --port 参数。这个习惯建议养成，尤其是你同时维护好几套工作流的时候，一套一个端口，互不干扰。

最后是模型文件规划。视频模型一般需要一个主模型，可能还需要配套的文本编码器、VAE、以及可选的 LoRA。下载之前先看清楚目录结构要求，ComfyUI 的模型目录约定是分门别类的，放错了节点会提示找不到模型。建议在安装阶段就把目录建好，比如 models/diffusion_models、models/text_encoders、models/vae、models/loras，按类型归位，别全堆在一个文件夹里。

4. 安装部署与启动方式

ComfyUI 的安装有三种主流方式：官方直接克隆、便携整合包、以及容器化部署。三种我都建议你至少了解两种，因为不同机器环境不一样，一种卡住可以换另一种。

方式一是直接克隆仓库装依赖，适合你机器上已经有干净的 Python 环境：

bash复制# 克隆仓库并进入目录
git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI

# 创建并激活虚拟环境，避免污染系统 Python
python -m venv venv

# Windows
venv\Scripts\activate

# Linux / macOS
source venv/bin/activate

# 安装依赖
pip install -r requirements.txt

方式二是便携整合包，解压即用，适合不想折腾 Python 环境的同学。整合包的好处是依赖都打好了，缺点是版本更新可能滞后，遇到需要手动升级依赖的节点会麻烦一些。用整合包的时候要注意，模型文件和输出目录通常在包内，升级之前先备份，别一覆盖把模型删了。

方式三是容器化，适合服务器部署或者多环境隔离。需要机器上已经装好容器运行时和 NVIDIA 容器工具包，网络配置和模型挂载要提前规划好。

启动命令本身很简单，关键是参数：

bash复制# 基础启动，监听本地所有网卡的 8188 端口
python main.py --listen 0.0.0.0 --port 8188

# 显存紧张时启用低显存模式，会牺牲一部分速度换空间
python main.py --port 8188 --lowvram

# 显存更紧张时的激进模式
python main.py --port 8188 --novram

--listen 0.0.0.0 这个参数要慎用，它会把界面暴露到局域网，方便你在另一台机器上访问，但也意味着同网段的人都能连上来。如果只是自己在本地用，写 127.0.0.1 更安全。启动成功后终端会打印访问地址，浏览器打开就能看到节点界面。

工作流这块，我的建议是不要从零开始连线。先去把文生图那一段跑通，确认基础出图正常，然后再往上叠加视频生成节点。因为视频节点的依赖更多，如果基础链路就有问题，加进来之后你根本判断不了是哪一层出的错。具体做法是：先用一个简单的文生图工作流跑一张 720p 的静态图，看显存占用和出图时间；正常之后再接入图生视频节点，把首帧图喂进去；最后再接 TTS 和拼接环节。

视频节点接进来之后，参数设置上遵循“先小后大”的原则：帧数先用最小档，分辨率先用最低档，采样步数先用较小值，跑通一次完整的“出帧到保存”流程，确认输出目录真的有文件，再往上调。这个流程看起来笨，但能帮你在一堆变量里定位问题。很多人一上来就拉满参数，结果跑十分钟报显存溢出，连日志都没看清就放弃了。

5. 功能测试与效果验证

这一节按分镜生产的实际顺序拆成几个测试项，每个都给出输入、步骤、预期结果和失败排查方向。

5.1 首帧静态图生成测试

目的是确认文生图链路正常，且画面氛围符合分镜描述。输入是一段具体的画面描述，比如“黄昏时分，雾气弥漫的山谷入口，茂密植被遮挡视线，远处隐约有石阶延伸向上，冷色调，低照度”。操作步骤是在文生图节点里填入正向提示词，反向提示词写清楚不要出现什么，比如不要文字水印、不要多余肢体、不要过曝；采样步数先用中等值，分辨率先按 16:9 比例设定。

预期结果是能出一张构图合理、色调统一的静态图，山谷和环境元素符合描述。判断成功的标准有三条：画面没有明显崩坏，色彩氛围和提示词方向一致，导出文件能在输出目录找到。如果出图模糊，先看采样步数是不是太低；如果构图完全跑偏，检查提示词是不是太长太杂，适当精简；如果直接报错，多半是模型文件没放对位置或者精度格式不匹配。

这一步的产物很关键，它就是后面视频生成的首帧。所以不要随便用一张凑合的图往后走，首帧的质量直接决定了视频开头的稳定程度。建议同一个提示词多跑几张，挑一张构图最干净、留白最合理的，留给下一步。

5.2 图生视频镜头生成测试

目的是验证从静态图到动态镜头的转换效果。输入是上一步选定的首帧图，加上一段描述运动方式的提示词，比如“镜头缓慢向前推进，雾气轻微流动，植被随风轻摆”。操作步骤是把首帧图接入视频节点，设置帧数和帧率，采样参数先用保守值，然后执行。

预期结果是输出一段短视频，主体结构保持稳定，局部有合理的动态变化。判断成功的标准是：主体没有整体扭曲变形，运动方向和提示词描述大致吻合，背景没有出现大面积闪烁。这里最常见的失败是“崩脸”和“糊成一团”，原因通常有两个，一是运动幅度描述过大，模型处理不了这么大的变化量，二是分辨率或帧数超出了当前显存的舒适区。前者靠收敛描述解决，后者靠降档解决。

还有一个高频问题是无意义的抖动。扩散模型生成的相邻帧之间会出现细微不一致，累积起来就是画面抖动。缓解方式是控制运动描述的强度，避免同时要求多个方向的运动，另外可以尝试固定随机种子，减少每次生成的随机波动。

5.3 首尾帧衔接测试

目的很明确，就是验证长镜头分段生成之后能不能接得上。输入是上一段的末帧，作为下一段的首帧。操作步骤是把末帧导出，接到下一次生成的首帧输入位上，提示词顺着上一段的运动方向继续写，注意保持场景描述一致。

预期结果是两段视频拼接处的画面元素基本对齐，没有突兀的跳变。判断标准是连续播放时肉眼不觉得出戏，环境元素的位置没有大幅位移。如果跳变明显，先从提示词入手，把两段的空间描述写成一致的，再检查首帧图本身有没有被压缩或裁切导致比例变化。

这里要有个合理预期：开源方案的首尾帧衔接做不到完全无缝，尤其是涉及镜头大范围移动的时候。所以在分镜设计阶段就要主动规避，多用固定机位、缓慢推进、局部运动这类相对稳的镜头语言，少用快速横摇和大范围旋转，后者在分段生成下几乎必然出问题。

5.4 旁白 TTS 生成测试

目的是给片子配上解说。输入是一段旁白文本，写成适合朗读的短句，避免超长从句。操作步骤是加载本地 TTS 模型，填文本，选择或上传参考音频，设置语速和停顿，生成音频文件。

预期结果是输出一段语速自然、断句合理的旁白音频。判断标准是听感上没有明显的机械感，数字和专有名词读对了，长句的停顿位置合理。如果断句奇怪，多半是文本里标点不清晰，补上标点就能改善；如果多音字读错，用拼音标注或者改写句子绕开。

如果使用参考音频复刻音色，务必确认这是你自己的声音，或者你有明确书面授权的他人声音。这一点没有灰色地带，尤其是准备公开发布的内容。生成出来的音频文件也建议单独归档，和画面素材分开放，方便后期替换。

5.5 成片拼接与验收测试

目的是把分镜片段和旁白合成完整短片。输入是若干视频片段和一段旁白音频，用 ffmpeg 拼接：

bash复制# 将多个分镜片段按顺序无损拼接，先写列表文件
# list.txt 内容为每行 file 'segment_01.mp4'
ffmpeg -f concat -safe 0 -i list.txt -c copy draft_no_audio.mp4

# 混入旁白音轨，画面直接复制，音频重新编码
ffmpeg -i draft_no_audio.mp4 -i voiceover.wav \
  -c:v copy -c:a aac -b:a 192k \
  -shortest final_cut.mp4

预期结果是得到一个画面连贯、音画大致对齐的成片。判断标准是文件能正常播放，时长和分镜清单一致，没有黑帧和卡顿。如果拼接后时长不对，检查列表文件的顺序和每段片段是否完整；如果音画错位，先确认旁白时长和画面总时长的比例，再做微调。

6. 接口 API 与批量分镜

分镜一多，手动点按钮就不现实了。ComfyUI 本身提供了 HTTP 接口，可以把工作流保存成 API 格式的 JSON，然后通过脚本批量提交。这是把“单次把玩”升级成“流水线”的关键一步。

第一步是在界面里把工作流调好，用“保存（API 格式）”导出 JSON。这个 JSON 里包含了所有节点和参数，你可以用脚本读取它、修改提示词字段、再提交。注意不要用界面普通的保存格式，那个是给界面加载用的，结构不一样。

第二步是启动服务并提交任务：

python复制import json
import time
import requests

SERVER = "http://127.0.0.1:8188"
WORKFLOW_PATH = "./workflows/shot_template_api.json"
PROMPT_NODE_ID = "6"   # 提示词节点的 ID，需按你的实际工作流修改
SEED_NODE_ID = "3"     # 随机种子节点的 ID，需按你的实际工作流修改

def load_workflow(path):
    with open(path, "r", encoding="utf-8") as f:
        return json.load(f)

def submit_shot(prompt_text, seed):
    wf = load_workflow(WORKFLOW_PATH)
    wf[PROMPT_NODE_ID]["inputs"]["text"] = prompt_text
    wf[SEED_NODE_ID]["inputs"]["seed"] = seed

    payload = {"prompt": wf}
    resp = requests.post(f"{SERVER}/prompt", json=payload, timeout=30)
    resp.raise_for_status()
    return resp.json()["prompt_id"]

def wait_done(prompt_id, interval=5, timeout=1800):
    start = time.time()
    while time.time() - start < timeout:
        r = requests.get(f"{SERVER}/history/{prompt_id}", timeout=15)
        if r.status_code == 200 and r.json():
            return r.json()
        time.sleep(interval)
    raise TimeoutError(f"任务 {prompt_id} 超时未完成")

if __name__ == "__main__":
    shots = [
        {"text": "黄昏山谷入口，雾气弥漫，镜头缓慢前推", "seed": 1001},
        {"text": "密林深处小径，光线斑驳，镜头轻微手持晃动", "seed": 1002},
        {"text": "石阶尽头洞口，冷色逆光，镜头静止", "seed": 1003},
    ]
    for i, shot in enumerate(shots, start=1):
        pid = submit_shot(shot["text"], shot["seed"])
        print(f"第 {i} 个分镜已提交，prompt_id={pid}")
        result = wait_done(pid)
        print(f"第 {i} 个分镜完成，输出信息长度：{len(json.dumps(result))}")

这段代码有两个地方必须按你的实际情况改：节点 ID 和接口路径。节点 ID 在导出的 JSON 里能看到，不同工作流不一样，直接照抄别人的 ID 大概率报错。接口路径也要以你当前版本的文档为准，我只用了 /prompt 和 /history/{id} 这两个最基础的路由。

批量任务的目录设计建议这样规划：

json复制{
  "input_dir": "./inputs",
  "workflow_dir": "./workflows",
  "output_dir": "./outputs",
  "log_dir": "./logs",
  "batch_size": 1,
  "max_retry": 2,
  "retry_interval_seconds": 30,
  "stop_on_error": false
}

batch_size 设为 1 是有意的，视频生成显存占用高，串行执行比并行稳。max_retry 给 2 次，因为有些失败是偶发的显存碎片导致的，重试一次往往就过了。stop_on_error 设成 false，让单个分镜失败不影响整批，最后统一看日志补跑。

失败重试这块有个细节：重试之前最好把上一次的中间产物清掉，避免节点读取到残留文件导致结果错乱。另外每次提交都记日志，把分镜序号、提示词、种子、prompt_id、开始时间、结束时间、是否成功都写进去，后面排查问题全靠这个。

7. 资源占用与性能观察

视频生成的资源观察和出图完全不是一个量级。出图你可能几秒钟就完事，视频是按分钟算的，所以监控要提前挂上。

显存观察最直接的方式是命令行轮询：

bash复制# 每秒刷新一次显存占用，观察生成过程中的峰值
nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu \
  --format=csv -l 1

重点看峰值而不是启动后的静态值。有些模型加载完占用不高，一到采样阶段就冲上去了，你只看开头会误判。建议在跑第一个分镜的时候就把这个命令挂上，全程盯一遍，心里就有数了。

影响占用的几个变量，按影响从大到小排：分辨率、帧数、采样步数、精度格式。分辨率是平方级影响，从 480p 到 720p 占用会明显上台阶；帧数基本是线性增长；采样步数影响的是时间不是峰值显存；精度格式影响很大，量化权重能显著降低占用，代价是一部分画质。压降的顺序建议是：先降分辨率，再降帧数，最后才考虑换量化权重，因为前两个是可逆的，第三个会实质影响出片质量。

CPU 推理和 GPU 推理的差异要说清楚：CPU 能跑，但速度慢到不适合做视频，一个几秒的镜头可能要几十分钟甚至更久，只适合验证链路是否通畅，不适合实际生产。如果你只有 CPU，那这套工作流的实用价值很低，不如先攒硬件。

还有一个容易踩的坑是进程残留。视频生成任务如果中途中断，Python 进程可能还挂在后台占着显存，你下次启动就会提示显存不足，但实际上 nvidia-smi 显示占用是空的——这种情况多半是进程没退干净。处理方式是先看进程列表，确认没有残留的 Python 进程，再重启服务。端口冲突同理，服务没关干净就重新启动，会报端口被占用，换端口或者杀掉旧进程都行。

长时间批量跑的稳定性也要观察。连续跑十几个分镜之后，出片质量可能开始下滑，或者速度明显变慢，这通常是显存碎片累积导致的。应对方式是每跑完一批就重启一次服务，把状态清干净再继续。这个做法听起来原始，但比你去研究内存池优化要省事得多。

8. 常见问题与排查方法

下面这张表覆盖了这套工作流里最常遇到的几类问题，按“现象、原因、排查、解决”四列组织，遇到问题可以对照着看。

这张表里最值得单独展开的是“CUDA out of memory”。很多人一看到这个就以为要换卡，其实大部分情况是参数没调对。判断方法很简单：先降到最低分辨率、最短帧数，如果还报错，那才是真的显存不够；如果能跑通，那就是参数问题，逐级往上加，找到你这张卡的上限在哪，以后就按这个上限来配。

另一个高频误区是“模型缺失”。ComfyUI 的模型目录是有约定的，你把一个视频模型丢进 checkpoints 目录，节点可能也能识别到，但类别不对照样报错。遇到这类问题，先看清楚报错信息里期望的路径长什么样，照着建立目录，别凭感觉放。

9. 最佳实践与使用建议

第一，永远先跑最小可运行配置。第一次接触一套新工作流，别急着用你精心准备的高质量素材，先用一张简单的测试图、一段短提示词、最低参数跑一遍。目的不是出好片，是确认链路通。链路通了，再往上堆质量，这时候出问题你能快速定位是哪一层。

第二，把最小可运行配置固化下来。跑通之后立刻把工作流导出存档，参数记在配置文件里，和素材、输出分目录管理。这次能跑通，下次换个模型版本可能就跑不通了，有存档你至少能回到已知可用的状态。这个习惯在视频生成这种依赖复杂的场景里，价值远超你的想象。

第三，批量任务一定要加日志和重试。前面给的脚本只是个骨架，实际用的时候把每个任务的输入、输出、耗时、状态都记下来。失败重试要设上限，别搞成无限循环。跑之前先估算一下总时长，几十个分镜可能要跑一晚上，提前规划好机器别中途干别的。

第四，接口服务限制访问范围。如果你的机器在内网里，--listen 别随便开成所有网卡，更不要直接暴露到公网。这套服务本身没有复杂的鉴权机制，暴露出去等于把机器交出去。自己用就绑本地回环，需要远程访问就通过受控的内网通道。

第五，素材合规这条线要守住。画面里不要出现可识别的真实人物面部，旁白不要用未授权的声音样本，参考素材不要直接复刻受版权保护的具体画面。虚构的丛林探险题材本身没问题，但一旦涉及真实的人、真实的组织、真实的地点指向，就超出练习范畴了。发布之前过一遍内容，这一步不能省。

第六，发布前做效果复核。自动生成的东西一定会有瑕疵，尤其是连续镜头之间的衔接，你自己看的时候容易忽略，换个屏幕、隔一天再看，问题会很明显。建议把成片完整看两遍，一遍看画面连贯性，一遍只听声音，分开检查比混在一起更容易发现问题。

10. 总结与下一步

这套工作流最值得试的地方，是把“一个想法”到“一段能看的画面”之间的路径缩短到了几分钟，而且全程在你自己的机器上，不用看任何平台的配额脸色。对做分镜预演和风格测试的人来说，这个反馈速度的价值很高。

最先该验证的功能，我建议是首帧生成加单镜头图生视频这两步，先把这两步跑稳，其余都是加法。很多人一上来就想做完整短片，结果卡在拼接和音画对齐上，反而没搞清楚单个镜头到底能做到什么程度。

最容易踩的坑有三个：一是低估显存需求，直接拉满参数然后报错；二是把首尾帧衔接想得太理想，做长镜头时反复返工；三是批量任务没做日志和重试，跑一晚上第二天发现全挂了还查不到原因。这三个坑，前面几节都给了具体的绕法。

往下扩展的方向也很清楚：如果你对镜头一致性要求更高，可以研究参考图控制类的工作流；如果你要处理更长的叙事，可以把分镜脚本做成结构化的配置，让脚本自动读取并提交，人只负责审片和挑片；如果你需要批量产出不同风格的空镜，可以把风格参数抽出来做成变量，一次生成多个版本对比。

先从一条分镜开始跑，跑通了再谈批量。