企业官网建设流程全解析

1. 为什么要在本地搭一套短剧生产流水线

去年年底我帮一个做短视频的朋友处理过一件事：他团队三个人，一个月产出四十条短剧，光剪辑和配音就占掉三分之二的时间，剩下的时间全花在等云端渲染排队上。后来我们把整条链路搬到本地，用一台带独显的机器跑生成、用脚本串起剪辑和字幕，产能直接翻了一倍多，而且素材不出本地，心里踏实。

这就是我写这篇东西的出发点。AI短剧本地部署这件事，说穿了就是把"写剧本、出画面、配音、剪辑、加字幕"这几个环节，从依赖各种在线服务，改成在自己机器上跑通。它适合三类人：一是想批量做短剧但预算有限的小团队，二是对素材隐私有要求的内容创作者，三是单纯想搞明白这套链路怎么运转的技术爱好者。你不需要是算法工程师，但得愿意动手敲命令、改配置。

整条链路大致长这样：大语言模型负责把创意扩写成带分镜的剧本，ComfyUI负责按分镜出图或出视频片段，FFmpeg负责把这些碎片拼成成片并压上字幕，中间用 Python 脚本做胶水。至于OpenClaw这类工具，更多是扮演"调度中枢"的角色，把上面几个环节串成一条自动流水线。下面我按实际搭建顺序，把每一步的选择理由、踩过的坑和能直接抄的配置都摊开讲。

提示：本文所有命令和配置都基于常见实践整理，具体版本号请以你实际下载到的为准，不要照抄版本号去搜安装包。

2. 硬件与系统底子：先算清楚你要跑多大的模型

2.1 显存决定你能跑什么，别一上来就冲大模型

本地部署最容易犯的错，是看别人说"某模型效果炸裂"就无脑下载，结果显存不够，跑起来要么爆显存，要么慢到怀疑人生。我的经验是先把显存和模型规模对应起来，再决定路线。

这里有个反直觉的点：剧本环节其实不需要最强的模型。短剧剧本讲究的是节奏和套路，7B 到 13B 的模型配上好的提示词模板，产出质量已经够用。真正吃资源的是画面生成，也就是 ComfyUI 那一环。所以如果你的机器只有一张 12GB 的卡，我建议把大模型跑在量化版本上，把省下来的显存留给图像和视频生成。

2.2 系统选择：Windows 能用，但 Linux 更省心

Windows 上跑这套东西完全可行，ComfyUI 有整合包，大模型也有现成的桌面客户端。但如果你打算长期跑批量任务，Linux 会少很多麻烦，尤其是涉及 FFmpeg 硬件加速和长时间无人值守渲染的时候。

我自己的主力机是 Ubuntu，显卡驱动装好之后，CUDA 环境基本一次到位。Windows 用户如果不想折腾，用 WSL2 也是个办法，但要注意 WSL2 的显存分配和文件系统性能问题，跨系统读写大文件会明显拖慢速度。有个常见的报错是环境校验失败，提示无法安全验证 WSL2 环境，这类问题多半出在虚拟化配置或版本不匹配上，遇到时优先检查系统虚拟化开关和 WSL 版本，而不是反复重装。

2.3 存储规划：素材盘和模型盘分开

短剧生产会产生大量中间文件：生成的图片序列、视频片段、音频、字幕文件。我建议至少留出 500GB 的可用空间，并且把模型文件和素材文件放在不同的物理盘上。原因很简单，模型加载是随机读，素材写入是顺序写，放一起会互相抢 IO。固态硬盘优先给模型盘，机械盘拿来存素材和成片就够了。

3. 大语言模型本地部署：剧本和提示词的发动机

3.1 用 Ollama 起步，别急着上复杂框架

大模型本地部署这块，新手最友好的入口是Ollama。它把模型下载、加载、接口暴露都封装好了，一条命令就能跑起来。安装完之后，拉一个 7B 级别的模型，比如常见的开源中文能力不错的那些，直接就能对话。

# 拉取并运行一个 7B 量化模型 ollama run qwen2.5:7b # 查看已下载的模型 ollama list # 以服务方式后台运行，供脚本调用 ollama serve

跑起来之后，Ollama 默认会在本地开一个接口，你的 Python 脚本就能通过 HTTP 请求调用它。这一步的意义在于：剧本生成和提示词扩写可以完全自动化，不用你手动复制粘贴。

3.2 剧本提示词模板：短剧的套路要写进系统提示里

短剧和长剧最大的区别是"前 3 秒必须抓人"。所以你的提示词模板里，必须把节奏要求写死。我常用的结构是这样的：

你是一名短剧编剧。请根据以下主题生成一集 60 秒短剧的分镜脚本。 要求： 1. 开场 3 秒内出现冲突或悬念 2. 全片 6 到 8 个镜头，每个镜头不超过 10 秒 3. 每个镜头输出：画面描述、台词、时长 4. 结尾留一个反转钩子 主题：{用户输入}

这个模板的关键在于把"镜头数"和"时长"约束住，否则模型很容易写出一个信息量过大、根本没法在 60 秒内呈现的剧本。我试过不加约束，模型能给你写出 20 个镜头的"史诗"，实际根本拍不完。

3.3 提示词到画面的翻译层：这一步最容易被忽略

剧本出来之后是中文的画面描述，但 ComfyUI 的很多模型对英文提示词响应更好。所以中间需要一个翻译和扩写层。我的做法是让大模型直接把画面描述转成结构化的英文提示词，格式固定成"主体 + 动作 + 场景 + 光线 + 风格"。

import requests def build_prompt(scene_desc): payload = { "model": "qwen2.5:7b", "prompt": f"把下面的画面描述转成英文图像提示词，" f"按主体、动作、场景、光线、风格五段输出，用逗号分隔：{scene_desc}", "stream": False } r = requests.post("http://localhost:11434/api/generate", json=payload) return r.json()["response"]

这段代码看着简单，但它把"剧本"和"出图"两个环节接上了。没有这一层，你就得手动一条条翻译，批量生产根本无从谈起。

注意：本地模型的中英翻译质量参差不齐，如果发现提示词翻译得离谱，可以在模板里加几个示例（few-shot），效果会明显好转。

4. ComfyUI 出图出片：短剧画面的核心产线

4.1 整合包还是手动装，看你要不要改底层

ComfyUI 的安装有两条路：一是用社区维护的整合包，二是手动克隆仓库装依赖。整合包的好处是开箱即用，环境都配好了，适合只想跑工作流的人。手动装的好处是你能控制每个依赖的版本，遇到插件冲突时好排查。

我的建议是：先用整合包把流程跑通，再考虑手动装。很多人一上来就手动装，结果卡在依赖冲突上，连界面都没见到就放弃了。整合包跑通之后，你对整个工作流的节点逻辑有了感觉，再去手动装就有方向了。

4.2 工作流设计：把"分镜"变成"批量任务"

ComfyUI 的核心是工作流，也就是一张节点图。短剧生产的工作流和单张出图不一样，它需要能接收一批提示词，然后批量产出。我的做法是用一个文本节点读取提示词列表，配合批处理节点循环执行。

工作流里几个关键节点：

• 提示词输入节点：从外部文件读取，一行一个提示词
• 采样器节点：控制步数和采样方法，短剧画面我一般用 20 到 25 步
• 尺寸节点：竖屏短剧用 9:16，常见分辨率是 720x1280
• 保存节点：输出到带序号的文件夹，方便后续按顺序拼接

这里有个实操心得：批量出图时把随机种子固定住，这样同一批画面风格才统一。如果每条都随机，拼出来的短剧会像不同人拍的，观感很割裂。

4.3 插件生态：哪些值得装，哪些是坑

ComfyUI 的插件非常多，但短剧生产真正需要的就那么几类：

装插件最大的坑是版本冲突。有些插件依赖特定版本的 ComfyUI 核心，装多了之后启动直接报错。我的经验是一次只装一个插件，装完重启验证，确认没问题再装下一个。别一次性装十个，出问题你根本不知道是哪个引起的。

4.4 从图到视频：补帧和时长控制

如果短剧需要动态画面，就得用到图生视频。这一步对显存要求更高，而且生成速度慢。我的做法是：关键镜头用视频生成，过渡镜头用静态图加运镜。所谓运镜，就是在 FFmpeg 里对静态图做缓慢的缩放或平移，成本几乎为零，但观感上有了动态。

视频生成还有个常见问题是时长不可控，生成出来可能只有两三秒。解决办法是生成多个片段，然后在剪辑环节拼接。别指望一次生成一个完整的长镜头，那是给自己找麻烦。

5. FFmpeg 剪辑流水线：把碎片拼成成片

5.1 安装与硬件加速：别用默认的软件编码

FFmpeg 的安装方式取决于系统。Linux 上包管理器直接装，Windows 上建议下载带硬件加速支持的构建版本。这里的关键是启用 GPU 编码，否则纯 CPU 编码会慢到让你怀疑人生。

# 查看是否支持硬件编码 ffmpeg -encoders | grep nvenc # 用 GPU 编码把图片序列合成视频 ffmpeg -framerate 30 -i frame_%04d.png \ -c:v h264_nvenc -pix_fmt yuv420p output.mp4

h264_nvenc是 NVIDIA 显卡的硬件编码器，速度比软件编码快好几倍。如果你用的是其他品牌的显卡，对应的编码器名称不同，装之前先查清楚。

5.2 拼接、配音、字幕：三条命令搞定

短剧成片需要三样东西合到一起：画面、配音、字幕。我一般分三步走。

第一步，把画面片段按顺序拼接：

# 用 concat 协议拼接多个视频片段 ffmpeg -f concat -safe 0 -i filelist.txt -c copy merged.mp4

filelist.txt里每行写一个片段路径，格式是file '片段路径'。用-c copy表示不重新编码，速度极快，前提是所有片段的编码参数一致。

第二步，把配音混进去：

# 替换或混合音频 ffmpeg -i merged.mp4 -i voice.wav \ -c:v copy -c:a aac -map 0:v:0 -map 1:a:0 \ -shortest final_with_audio.mp4

第三步，压上字幕：

# 烧录字幕（硬字幕） ffmpeg -i final_with_audio.mp4 \ -vf "subtitles=subtitle.srt:force_style='FontSize=24'" \ -c:a copy final.mp4

字幕文件用 SRT 格式，时间轴要和配音对齐。这一步最容易出问题的是字幕编码，如果 SRT 文件不是 UTF-8，中文会变乱码。我踩过好几次这个坑，现在生成字幕文件时一律强制 UTF-8。

5.3 批量处理脚本：把上面三步串起来

单条短剧手动跑这三步还行，批量生产就必须脚本化。我用 Python 写了一个调度脚本，遍历素材文件夹，自动完成拼接、混音、压字幕。

import subprocess import os def make_episode(ep_dir): merged = os.path.join(ep_dir, "merged.mp4") voice = os.path.join(ep_dir, "voice.wav") srt = os.path.join(ep_dir, "subtitle.srt") out = os.path.join(ep_dir, "final.mp4") # 拼接 subprocess.run([ "ffmpeg", "-f", "concat", "-safe", "0", "-i", os.path.join(ep_dir, "filelist.txt"), "-c", "copy", merged ], check=True) # 混音 + 压字幕 subprocess.run([ "ffmpeg", "-i", merged, "-i", voice, "-vf", f"subtitles={srt}", "-c:v", "h264_nvenc", "-c:a", "aac", "-map", "0:v:0", "-map", "1:a:0", "-shortest", out ], check=True)

这个脚本跑通之后，你只要把素材按集数分好文件夹，剩下的就是等它自己跑完。我实测下来，一集 60 秒的短剧，从素材到成片大概两三分钟，比手动剪辑快太多了。

6. OpenClaw 调度中枢：让整条线自己转起来

6.1 它到底解决什么问题

前面几个环节单独跑都能跑，但它们是割裂的：你得手动把剧本喂给大模型，把提示词喂给 ComfyUI，把素材喂给 FFmpeg。OpenClaw 这类工具的价值，就是把这些环节串成一条自动流水线，你给一个主题，它自动走完剧本、出图、剪辑、成片的全过程。

它的工作方式本质上是任务编排：定义好每个环节的输入输出，然后按顺序触发。你可以把它理解成一个"总控台"，底下挂着大模型、ComfyUI、FFmpeg 三个执行器。

6.2 部署时的环境校验问题

部署这类调度工具时，最常见的拦路虎是环境校验。比如在 WSL2 里跑的时候，可能提示无法安全验证环境。这类问题的根源通常是虚拟化配置、版本不匹配或者权限问题，而不是工具本身有 bug。

我的排查顺序是：先确认系统虚拟化功能已开启，再确认 WSL 版本和内核版本匹配，最后检查文件权限。不要一遇到报错就重装，重装往往解决不了配置层面的问题，反而浪费一两个小时。

6.3 对接本地模型服务

调度工具要调用大模型，就得配置接口地址。Ollama 默认在本地开一个端口，你在 OpenClaw 的配置里把模型服务地址指向它就行。配置项一般包括服务地址、模型名称、超时时间。

llm: provider: ollama base_url: http://localhost:11434 model: qwen2.5:7b timeout: 120 comfyui: base_url: http://localhost:8188 ffmpeg: path: /usr/bin/ffmpeg

超时时间要设得宽松一点，本地模型首次加载比较慢，设太短会直接超时失败。我一开始设了 30 秒，结果每次第一次调用都失败，改成 120 秒之后就稳了。

6.4 任务队列与失败重试

批量生产最怕的是跑到一半某个环节挂了，整批任务全停。所以调度配置里一定要开失败重试，并且把中间产物保留下来。这样即使某一步失败，重跑时也能从断点继续，不用从头再来。

我的做法是每个环节的输出都落盘，并且记录一个状态文件。调度器每次启动先读状态文件，跳过已完成的环节。这个机制看起来简单，但在实际批量跑的时候能省下大量时间。

7. 踩坑实录：那些文档里不会写的问题

7.1 显存碎片化导致越跑越慢

连续跑几十条任务之后，我发现生成速度明显下降，重启之后又恢复正常。后来查明白是显存碎片化：每次任务加载和释放模型，显存被切得七零八落，新任务找不到连续的大块显存，只能反复整理。

解决办法是定期重启生成服务，比如每跑 20 条就重启一次 ComfyUI。听起来笨，但比研究显存池化省事多了。如果你追求极致，可以研究一下模型常驻内存的方案，但配置复杂度会上升不少。

7.2 音频和画面不同步

拼接的时候偶尔会出现音画不同步，尤其是片段时长和配音时长对不上的时候。根源在于视频片段的实际帧率和预期不一致，导致累计时长有偏差。

我的处理办法是在拼接前先统一所有片段的帧率和分辨率，用 FFmpeg 批量转一遍。虽然多花一点时间，但能避免后面反复调整。统一参数的命令：

ffmpeg -i input.mp4 -r 30 -s 720x1280 \ -c:v h264_nvenc -c:a aac normalized.mp4

7.3 字幕时间轴漂移

字幕漂移通常是因为配音生成时语速和预估不一致。我的经验是先出配音，再根据配音的实际时长生成字幕时间轴，而不是先写死时间轴再配音。顺序反了，漂移几乎不可避免。

具体做法是用语音识别工具对配音做一次对齐，拿到每个字的实际时间戳，再生成 SRT。这一步多花几十秒，但字幕准确度提升非常明显。

7.4 批量任务的命名混乱

一开始我没在意文件命名，结果跑了几十集之后，素材文件夹里全是output_1.mp4、output_2.mp4，根本分不清哪集是哪集。后来改成用"日期 + 主题 + 集数"的命名规则，并且每个环节的输出都带上前缀，一眼就能看出进度。

这个坑看着小，但当你需要回溯某一集的素材时，命名混乱会让你抓狂。命名规范要在项目开始前就定好，别等乱了再改。

8. 产能与成本：本地部署到底划不划算

8.1 一次性投入 vs 长期产出

本地部署的前期投入主要是硬件。一台能跑 7B 模型加图像生成的机器，配置下来大概在万元级别。如果只是偶尔做几条，这个投入不划算。但如果你打算长期批量生产，摊到每条短剧上的成本会迅速下降。

我算过一笔账：按每月产出 100 条短剧算，本地部署的硬件成本大概三四个月就能摊平，之后每条短剧的边际成本几乎只有电费。这个账对于有稳定产出需求的团队来说，是算得过来的。

8.2 时间成本才是大头

硬件成本好算，时间成本容易被忽略。搭建这套流水线，从装环境到跑通第一条成片，新手大概需要两三天。这期间你会遇到各种报错、版本冲突、配置问题。

我的建议是先跑通最小闭环：一条主题，走完剧本、一张图、一段配音、一次拼接。闭环跑通之后，再逐步加批量、加自动化。别一上来就追求全自动，那样很容易在某个环节卡死然后放弃。

8.3 质量与产量的平衡

本地模型的质量和顶级在线服务比，确实有差距。但短剧这个品类，观众对画面精度的要求没有想象中那么高，节奏和剧情才是核心。所以本地部署的定位应该是用可接受的质量换可控的成本和产能，而不是追求单条极致。

我实际跑下来的感受是：本地生成的画面，配上好的剧本和剪辑节奏，完播率并不比精修的低多少。关键还是内容本身能不能抓住人。

9. 后续可以继续深挖的几个方向

整套流水线跑通之后，还有不少可以优化的地方。比如把配音环节也本地化，用本地的语音合成模型替代在线服务，这样整条链路就彻底不出本地了。再比如给调度器加一个简单的 Web 界面，让不熟悉命令行的同事也能提交任务。

还有一个方向是工作流的模块化。把不同风格的画面生成拆成不同的工作流模板，根据剧本类型自动选择。比如都市题材用一套模板，古装题材用另一套，这样产出的画面风格更统一。

我自己最近在试的是把失败重试和状态记录做得更细，让调度器能精确到"第几个镜头的第几次生成失败"，这样排查问题的时候不用翻整个日志。这个改进看起来不起眼，但批量跑的时候能省下大量排查时间。

最后分享一个小技巧：把每次成功跑通的配置存成一个快照，包括模型版本、插件版本、工作流文件、脚本参数。下次环境出问题的时候，直接对照快照回滚，比一点点排查快得多。我吃过没存快照的亏，重装环境花了一整天，从那以后每次调通必存快照。