零成本AI短剧制作：本地部署Ollama+ComfyUI+FFmpeg实战

“一个社恐程序员深夜加班时捡到一只会说话的猫，猫用三句话说服他辞职创业。”——拿这句台词去做一条AI短剧，照一年前的主流玩法得先充会员、再买图生视频额度、配音还要单独订套餐，一套组合拳下来，一条30秒的片子可能就要花掉几十上百块。后来我把整套流程全部搬到了本地：Ollama部署大模型负责扩写剧本，ComfyUI生成分镜画面，CosyVoice做配音，FFmpeg收尾剪辑，整条流水线不花一分API费用。这篇文章就是这次“本地零元实测”的完整记录。

这是一次实打实的动手折腾，不是概念介绍。文章里会讲清楚每一步为什么要这么做、中间有哪些坑、参数怎么调、成品效果大概在哪一层，适合手里正好有一句创意想低成本试水AI短剧的人，也适合准备入坑本地大模型应用但不知道从哪下手的朋友。

1. 零元不等于零门槛：先把本地AI短剧的成本和硬件账算明白

1.1 为什么我把API费用砍到0，坚持走本地链路

先算一笔账。一条像样的AI短剧至少包含四个环节：剧本、画面、配音、剪辑。前三个环节只要用主流云端服务，几乎每个环节都按次数或按秒收费。剧本扩写一次不贵，但你要迭代十几版；文生图一张可能只要几毛钱，但要凑齐几十个镜头的“可用图”可能要生成几百张；图生视频按秒计价，一条30秒短片动辄几十上百。对以“反复试错”为常态的创作者来说，这笔成本会指数级膨胀，而不是线性上升。

本地链路的好处是边际成本几乎为零：软件全是开源或免费，模型文件下载一次后就能反复用，跑一次失败的成本只是电费和时间。更关键的是，本地部署没有云端API那种并发限制和每分钟调用次数上限，我可以一次性生成几十张候选图，再从里面挑出能用的几张。这个过程在云端做会心惊肉跳，在本地做毫无压力，这是“零元”最直接的体验差异。

1.2 硬件底线：没有多好的显卡也能开工

我的实测环境是：Windows 11，CPU是i5-12400F，内存32GB，显卡RTX 3060 12GB。这个配置在今天只能算“中端偏入门的AI玩具”，但跑通这套流水线完全够用。这里的关键是显卡显存，而不是CPU和内存。显存决定你能跑多大模型、多大分辨率，CPU和内存只要别太差就行。

如果显存只有6GB，建议把模型档次降下来：大模型用7B的INT4/INT8量化版，出图用SD1.5系列而不是SDXL，分辨率控制在512级别，配音用轻量级方案。如果显存有16GB以上，就可以尝试SDXL出图、AnimateDiff视频、更大参数的本地大模型。实测下来，显存决定上限，耐心决定下限。纯用CPU跑这套链路非常痛苦，出一张图可能要等几分钟甚至十几分钟，基本不具备实操性，所以压箱底的结论是：想玩本地AI短剧，一张NVIDIA显卡是硬前提。

1.3 零元的真实边界：免费工具不缺，缺的是耐心和流程

“零元”指的是不向任何云端API付费，而不是什么都不消耗。电费、硬件折旧、自己调试的时间，这些成本会从“钱”转移成“折腾”。先把全链路用到的工具和对应成本理清楚：

我第一次跑通全流程，前前后后花了一个通宵，大部分时间不是在等生成，而是在排错。所以如果你也想“零元实测”，请先把预期放低：这不是开箱即用的傻瓜流程，更像组装一台电脑——零件都是免费的，但装起来需要一点动手能力。不过这套流程一旦跑通，后续复制成本极低，这也是本地方案最大的魅力。

2. 从一句剧情到分场脚本：Ollama本地大模型扩写的Prompt链

2.1 选模型：deepseek-r1管分场，qwen2.5管台词

Ollama的部署很简单，官网下载安装包后，终端跑一句ollama -v验证即可。我本地常驻两个模型：deepseek-r1:7b和qwen2.5:7b-instruct，都是开源、中文友好、可以本地长时间跑的模型。为什么要同时用两个？因为一个是推理型模型，一个是指令型模型，它们擅长的任务完全不同。

deepseek-r1在生成“有逻辑结构的产出”时表现明显更好，比如把一句创意扩成多场戏、给每场戏安排起承转合，本质上是逻辑规划任务。但它有个毛病，就是回答里经常夹带“首先、其次、综上”这类分析腔，直接拿来做剧本台词会很生硬。qwen2.5-instruct则更听话，擅长把指令转成长度合适、口语化强的文本。所以我实际跑的链路是：deepseek-r1负责搭骨架，qwen2.5负责填血肉，各干各的活。测试时可以随时用ollama run deepseek-r1:7b进入交互模式，但一旦要批量跑脚本，还是走API更高效。

2.2 四段式Prompt工作流：从一句话到可拍脚本

所谓“一句剧本长出AI短剧”，核心就是把一句话变成一套可执行的短剧脚本。我拆成了四步，每一步都把任务范围压缩到极小：

第一步，把一句话扩展成150字左右的短剧梗概，要求包含起因、转折、高潮、结局。第二步，把梗概拆成4场戏，每场戏标注时间、地点、人物、剧情目标。第三步，给每场戏写口语化台词，单句不超过30字，并排除旁白。第四步，把每场戏转化成画面描述词，写清主体、动作、景别、光线，这部分的产出会直接喂给ComfyUI。

这样拆的原因很简单：一次让模型生成“一部完整短剧”，它往往会给你一堆正确的废话，因为任务粒度太大，模型不知道你更在意节奏、台词还是画面。拆成四步后，每一步都是一次“单一任务”，输出质量会稳定得多。比如刚才那句“社恐程序员和会说话的猫”，经过四步扩写后，第一场戏的画面描述会变成类似“深夜办公室，程序员工位上堆着泡面盒，一只猫蹲在显示器旁边，用爪子拍键盘，镜头从中景慢慢推到猫的特写”这种可以直接进文生图模型的文本。

2.3 用Python脚本把本地大模型串成流水线

四步如果每次手动复制粘贴，效率太低。我写了个简单的Python脚本，通过Ollama本地API把这四步串成一条流水线，一条命令跑完。核心代码如下：

import requests OLLAMA_URL = "http://127.0.0.1:11434/api/generate" def ask(model, prompt): resp = requests.post(OLLAMA_URL, json={ "model": model, "prompt": prompt, "stream": False, "options": {"temperature": 0.7} }) return resp.json()["response"].strip() seed_sentence = "一个社恐程序员深夜加班时捡到一只会说话的猫，猫说服他辞职创业" story = ask("deepseek-r1:7b", f"把以下一句话扩展成150字的短剧梗概，必须包含起因、转折、高潮、结局，不要输出解释：\n{seed_sentence}") scenes = ask("deepseek-r1:7b", f"把以下梗概拆成4场戏，每场戏严格按【场景+人物+剧情目标】输出：\n{story}") lines = ask("qwen2.5:7b-instruct", f"为以下4场戏写口语化台词，每句不超过30字，不要旁白，直接输出台词：\n{scenes}") visuals = ask("qwen2.5:7b-instruct", f"把以下每场戏转化成适合文生图模型的画面描述，写清主体、动作、景别、光线，每场一段：\n{scenes}")

测试时有个小技巧：温度参数不要设太高，0.6到0.8之间比较合适，太高模型会放飞自我，太低又容易把台词写得像说明书。如果某一轮输出格式乱了，最简单的方式不是改温度，而是在Prompt里加一句“严格按模板输出，不要任何额外说明”，模型会听话很多。

3. 镜头画面本地出图：ComfyUI里角色一致性是怎么抠出来的

3.1 为什么本地出图：可控和隐私只是次要的，主要是省迭代成本

文生图是整条链路里最依赖“反复试错”的环节，也是最能体现本地优势的地方。用云端服务时，每次生成都按张付费，很多时候一个镜头需要试十几个提示词策略才能出满意效果，成本会迅速累积。本地用ComfyUI，试错成本几乎为零，我可以放肆地生成一批、淘汰一批，再做局部修改重新生成，这种“量变引起质变”的迭代方式，在云端根本不敢碰。

另一个原因可能更现实：短剧的脚本往往涉及连续剧情，同一个角色要在多张画面里保持外貌一致，这就需要保存参考图、固定种子、反复冲洗同一套提示词。这个过程会产生大量半成品和中间文件，如果全部放在云端，既麻烦又不可控。本地文件系统可以随时回溯、对比、复用，体验完全不同。

3.2 ComfyUI基础工作流：固定种子、尺寸、负面提示词

ComfyUI本身是一个节点式工作流工具，最直观的理解方式是把它当成一张“接线图”：加载模型、输入正向提示词、输入负向提示词、采样、解码、保存，核心链路就这几步。第一次跑通，建议直接用SD1.5系列的写实模型，比如majicMIX realistic或Realistic Vision，这类模型对中文创作者的审美比较友好，生成人物和室内场景都不容易翻车。

关键参数：分辨率不要一上来就拉到720x1280，容易爆显存，先在512x800左右出图，满意后再用Hires Fix放大；采样步数28步，CFG 6.5，采样器用DPM++ 2M Karras，这批参数在写实风格下最稳。负向提示词一定要写完整，我用的是“bad anatomy, extra fingers, lowres, watermark, text, deformed, blurry”这一组，实测能砍掉大量废图。生成种子固定下来，每张图都在文件名里写清楚镜头编号和种子号，方便后期回溯。

3.3 角色一致性实测：IPAdapter比“锁seed”靠谱得多

做短剧最头疼的不是单张画面好不好看，而是同一角色连续出场时脸长不一样。我一开始天真的以为，只要提示词里反复写“同一个男人、白色卫衣”，再加一个固定seed就能保持一致性，实际效果惨不忍睹——两秒钟的镜头切换，主角脸完全换人。

后来改用IPAdapter，流程是：选定一张满意的角色正面图当参考图，加载IPAdapter模型，把参考图接入采样流程，权重设在0.6到0.8之间，然后每张镜头图都以这张参考图为约束，只修改动作、景别和背景词。实测下来，角色面部的一致性提升非常明显，虽然做不到百分百稳定，但已经达到能看的程度。如果你连IPAdapter都不想装，还有一个退而求其次的办法：把所有画面的提示词拆成“固定段+变化段”，固定段写角色外貌和服装，变化段只写动作和镜头语言，效果比完全随机强一些，但别指望多稳定。

4. 画面动起来、对白说出来：低配方案和高配方案怎么选

4.1 低配方案：FFmpeg zoompan让静态画面“演”起来

不少AI短剧其实不是每帧都动态合成的，而是“图文短剧/漫剧”风格：静态画面加缓慢推拉镜头，配上对白和字幕，靠剪辑节奏感营造出动态效果。这种方式对硬件要求低得多，也是我把全链路跑通后最推荐的入门方案。实现方式不复杂：用FFmpeg的zoompan滤镜给每张静态图加缓慢缩放，输出成3到5秒的片段，再拼接。

一条典型的缩放命令长这样：

ffmpeg -loop 1 -i scene_001.png -vf "scale=1440:2560,zoompan=z='min(zoom+0.0008,1.2)':d=75:x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)':s=720x1280:fps=25" -t 3 -c:v libx264 -pix_fmt yuv420p clip_001.mp4

这里的d=75表示75帧，配合fps=25就是3秒钟。zoom增量0.0008是一个比较温和的推进速度，太快会让人头晕，太慢又感觉不到画面在动。每个镜头根据情绪决定是推近、拉远还是平移，我一般以3到5秒为一个镜头单位，刚好符合短剧的节奏。

4.2 高配方案：AnimateDiff和Wan2.1的门槛实测

如果追求真正的画面运动，比如猫真的跳上键盘、角色真的转头说话，那就得上视频生成模型。本地比较主流的是AnimateDiff和Wan2.1系列。实话实说，门槛不低：RTX 3060 12GB跑AnimateDiff只能在小分辨率下工作，生成一个几秒钟的片段可能需要十几分钟，而且很容易遇到显存不足或驱动重置。Wan2.1的画质上限更高，但对显存的要求也更高，想流畅跑至少需要16GB以上显存，我的实测体验是“能跑，但做不到随心所欲”。

我的建议是：第一次做短剧别碰视频生成模型，先用4.1里的低配方案把剪辑和叙事跑通，确认自己真的有耐心做完一条片子，再考虑升级到视频生成。视频生成模型会把调试时间拉长数倍，很多新手就是在这个环节被劝退的。

4.3 本地配音：CosyVoice2克隆音色，Piper适合快速试听

对白是短剧的灵魂，声音配不好，画面再精致也白搭。本地配音我试了两套方案：一套是CosyVoice2，另一套是Piper。CosyVoice2的优势是支持用一段参考音频克隆音色，十几秒的干净人声就能克隆出相对自然的语气风格，适合给不同角色设定不同声线；缺点是安装配置复杂度高，需要单独建Python环境，运行时也吃显存。Piper则轻量很多，安装简单、CPU都能跑，但中文语音的自然度和表现力都差一些，更适合快速试听台词节奏，不适合直接放进成片。

实际做短剧时，我的流程是：先用Piper把台词按大致语速合成一遍，边听边改台词文本和断句，等文本定稿后再用CosyVoice2配参考音色生成正式干音。这里有一个从实测里得到的建议：参考音频要选语速适中、背景干净的声音，最好是室内安静环境下录的，不要拿嘈杂视频里的人声当参考，否则合成出来的每个字都会带着底噪。

5. FFmpeg把素材剪成“能看的短剧”：批量剪辑与字幕烧录

5.1 为什么是FFmpeg：非编软件干不了的批量活

刚开始做短剧时我用的是常规的非编软件，拖拽素材、加转场、加字幕，操作直观，但有一个致命的问题：一个30秒的短剧也要十几个分镜，每次改一个词、换一张图就得重新手动导出一遍，非常消耗耐心。换成FFmpeg之后，我把整个剪辑过程写成了脚本，素材路径、字幕文件、输出参数全部改成变量，以后每次只需要把新素材扔进固定文件夹、运行脚本命令，几分钟就能得到一版新成片。这种“参数化剪辑”对持续迭代来说太重要了。

FFmpeg的功能可以概括为：把滤镜、拼接、转码、加字幕这些操作变成命令行指令，可重复、可批量、可自动化。对零元方案来说，它不止是替代品，而是整套流程的“粘合剂”。

5.2 三段式剪辑命令：拼接、字幕、混音一次搞定

我的FFmpeg剪辑分成三步。第一步，把单个镜头片段写入一个文本清单list.txt，格式如下：

file 'clip_001.mp4' file 'clip_002.mp4' file 'clip_003.mp4'

第二步，用concat协议把清单里的片段按顺序拼接成一条视频，命令是：

ffmpeg -f concat -safe 0 -i list.txt -c copy concat.mp4

第三步，给成片烧录字幕并混入配音音轨，音轨可以在这一步导入：

ffmpeg -i concat.mp4 -i audio_all.wav -vf "subtitles=lines.srt:force_style='FontSize=18,Alignment=2,Outline=1'" -c:v libx264 -c:a aac -shortest final.mp4

需要注意：字幕文件里的时间轴必须和画面片段完全对应。我写了个小脚本，根据导入的台词文本和每个镜头的时长自动生成srt文件，避免手动对时间轴。如果你只需要临时看看效果，也可以先不加字幕，直接混音，用耳朵判断节奏。

5.3 30秒成品片的参数参考与时长控制

实测一条30秒的短剧，我一般控制在8到12个镜头，每个镜头3到5秒，这样节奏比较紧凑。输出参数固定为H.264编码、720x1280分辨率、25帧率，码率让CRF 18到20自动决定，这样文件体积既不会太大，画质也能保持。音频用AAC编码，采样率44100赫兹，和大多数短剧平台的兼容性都很好。

生成速度方面，文字扩写和台词脚本大约需要3到5分钟，8张分镜图每张40到60秒，配音部分几分钟，FFmpeg拼接和字幕烧录基本是秒级到分钟级。整体算下来，从一句剧本到一条30秒的粗剪成片，大约需要一个半小时到两小时，大头在各种生成环节，真正的剪辑环节反而是最快的。

6. 实测连环坑：驱动崩溃、显存不足、模型断连的排查记录

6.1 nvlddmkm事件153：显卡驱动重置的真相

我在ComfyUI长时间高负载出图时遇到过屏幕突然闪黑、画面卡死、然后所有GPU进程被系统杀掉的情况，打开系统事件查看器，能看到“来自源 nvlddmkm 的事件 ID 153”的警告，而且系统提示找不到关于该事件的描述信息。第一次遇到时我也以为显卡坏了，后来排查下来，这种情况大多数是显卡的TDR超时被系统强制重置——说白了就是GPU长时间打满，驱动以为它“无响应”，干脆重启了显卡驱动。

这类问题不用急着重装系统或换显卡。我的处理顺序是：先降低批量出图尺寸和步数，把batch size从2改成1；再检查电源供电是否充足，尤其是老旧电源要注意；最后更新到相对稳定的驱动版本，不一定要最新，Studio版驱动往往比Game Ready驱动在高负载下更稳。如果问题依然频繁出现，大概率是散热问题，夏天环境温度高的时候尤其明显。

6.2 显存不足时别急着关进程，先改这三个参数

ComfyUI第一次跑大分辨率图几乎必然报“CUDA out of memory”，这不是你操作错了，而是显存分配策略的问题。我的降级三板斧：第一，启动ComfyUI时加--lowvram参数，让它自动控制显存加载策略；第二，把批量大小固定为1，禁止并行加载多张图；第三，把生成分辨率降到512级别，出图成功后再用Hires Fix放大。如果这三板斧都用了还是爆显存，说明当前模型真的超出了显卡上限，需要换小模型。

实测下来，SD1.5在6GB显存下用512x800分辨率完全可以跑，SDXL在12GB显存下跑720x1280也比较吃力，建议先用SD1.5做全流程验证，管线完全跑通后再考虑换更大的模型。

6.3 Ollama、Dify、ComfyUI抢端口：一套本地环境要统一规划

当你同时装Ollama、ComfyUI，还会折腾Dify这类本地部署工具时，端口冲突就会找上门。Ollama默认监听11434端口，ComfyUI默认监听8188端口，Dify本地部署默认会用5000和8080端口，如果不做规划，后启动的服务很可能把端口挤掉，导致前方调用异常。我实测中最常见的是Dify的容器启动失败或Ollama API长时间无响应，排查半天才发现是端口占用。

建议在一开始做一张端口规划表：Ollama固定用127.0.0.1:11434，ComfyUI用127.0.0.1:8188，Dify的5000端口若被其他开发服务占用，就在配置里改掉。调用Ollama API时，地址尽量写127.0.0.1而不是localhost，Windows下localhost偶尔会解析到IPv6的::1，导致连接失败。如果模型下载到一半断了，重新执行ollama pull会自动续传，不用删掉重下。

7. 这套流水线最值得优化的地方，以及我对“零元”的真实结论

7.1 先统一角色，再优化画质

整套流水线跑通之后，我的最大体会是：画面精致度不是首要瓶颈，角色一致性和叙事连贯性才是。我建议所有想复刻这套流程的人，先不要追求单张图的画质有多惊艳，而是先把以下三个模板固定下来：一个角色参考图、一套公共提示词模板、一张镜头表。镜头表里写明镜头号、画面描述、景别、时长、使用提示词，这能避免后面剪辑时发现“这场戏的镜头语言跟上一场对不上”。

更进一步的做法是给每个角色建立专属“角色素材包”，包含参考图、名字、服装关键词、常用角度。后续生成新镜头时，每次都从素材包里读取，效果比临时改提示词稳定得多。

7.2 几个让流水线更顺手的增效技巧

顺着“角色素材包”的思路，还有三个小技巧能让整个流水线更顺。第一个是写一个极简脚本自动生成srt字幕文件，入参是“台词列表”和“每句持续秒数”，内部按时间戳累加输出标准srt。这样做的好处是，每次改台词只改文本文件，字幕时间轴自动重新生成，不用手动挪字幕。

第二个是把所有画面的提示词、种子、参数按“镜头号”记录在一个markdown或csv表格里。不要相信记忆力，同一个角色，前三天生成的提示词和今天写的一定有偏差，记录下来才能让后续镜头保持一致。

第三个是学习ComfyUI的API模式。节点图可以导出为JSON，通过POST请求把提示词模板提交到http://127.0.0.1:8188/prompt，这样批量生成不同分镜时不需要在界面里一个个点。这一步对短剧这种“多镜头、多批次”场景特别有用。

7.3 “零元”不是神话，但确实是一条值得走的路

最后说点实在的。这条链路的真实成本是：一块中端显卡、一个通宵的调试、多次推倒重来的耐心。它不见得比“充会员一键生成”更快，但它的价值在于：一旦你掌握了这套本地工作流，后续每个项目的边际成本都会无限趋近于零，而你的能力积累是留在自己手里的。如果只是想尝鲜，云端工具可能更省事；但如果你真的打算长期做AI短剧，或者有大量需要试错的原型创意，本地方案值得你认真投入。

我个人在实操中最喜欢的一点是，每一步都能看到中间产物、可以随时干预，而不是把整个创作过程交给一个黑盒。这种“看得见摸得着”的控制感，可能是本地AI工作流最容易被忽略的价值。想试的朋友，建议从一句自己真正喜欢的剧本开始，先把四段式Prompt链用起来，跑出第一版分场脚本。你很快就会发现：AI短剧的难题，永远不在“生成”这一步，而在于你有没有想清楚要讲什么故事。