尧图网页设计 
简介这是一款面向短剧与漫剧创作者的开源本地AI生成工具定位为一站式工作流管理平台支持从故事构思、脚本创作到动画及AI真人剧成片的全流程处理数据全程在本地运行兼顾隐私安全与离线可用。适合个人创作者或小型团队尝试不同风格的剧集生产。资源包共227个文件大小41.38MB核心代码以js、vue、sql及json为主包含前端页面、数据库配置与后端逻辑另附bat启动脚本、md文档、jpg/png图片素材及示例mp4可快速部署体验。压缩包内还含有ffmpeg.exe等辅助工具便于本地处理视频资源。目前已有810人学习下载。通过该资源用户可获得完整的开源项目源码、本地部署脚本、数据库初始化文件及目录结构参考帮助理解短剧工作流管理平台的模块设计也可在此基础上修改二次开发借助AI小说创作与情节推进能力提升制作效率。1. 开源本地 AI 短剧生成把“故事→成片”的完整工作流压进一台机器你大概率刷到过那种 AI 生成的短剧运镜虽然有点僵但节奏、对白、分镜完全是工业化水准。这类片子大部分是在云端跑完的角色一致性靠抽卡台词是模板拼的最关键的是整个流程被拆成十几个分散的工具你要自己当胶水。这套开源本地 AI 短剧 漫剧生成工具解决的就是这个问题——它把剧本、分镜、配音、图生视频到剪辑封装成一条完整工作流数据不出本机所有环节通过本地部署的模型串起来。适合已经在用 ComfyUI、Dify 这类本地 AI 工作流平台但苦于没有一个完整短剧生产链路的人。你不用再手动把文案粘进 TTS、再把生成好的图片拖进视频合成器这个平台把中间步骤全部接管了。对我这种习惯把所有生成任务都压在本地跑的人来说它最大的价值不是某个模型多强而是把一条需要六个工具才能走通的生产线压缩成了一个可复现的工作流编排项目。2. 本地部署与底座选型为什么这年头短剧生成必须跑在本地工作流上2.1 本地化方案的三个底层理由隐私、成本和磨刀短剧生成这个事云端方案看着方便但实际用起来有硬伤。第一是隐私剧本通常带原创设定、人物关系甚至真实项目里的商业稿你不可能把未发布的内容整段丢给在线平台。第二是成本一条 60 秒的短剧按云端 API 计价生图、生视频、语音合成加起来可能十几块人民币十条就是一百多一个月下来够买一块本地显卡了。第三是调试效率云端方案的接口文档变来变去参数调整一次要等半天回包本地跑最大的优势是你可以反复试错改一个提示词立刻出结果。这套工具的部署形态是典型的 Docker Compose 全家桶不搞花活。核心组件包括一个大模型服务做剧本和分镜、一个语音合成服务读旁白和对白、一个图像生成服务出关键帧外加一个工作流编排引擎把三者串起来。我用下来的感受是这个组合选得很务实——不是追最前沿的模型而是选社区最活跃、文档最全、出问题能搜到答案的那一套。这在你面对一个全新的生产环节时特别重要。2.2 部署前的硬件清单和目录规划先把家底盘清楚。这个项目的部署底线是 8GB 显存的 NVIDIA 显卡16GB 显存会从容很多。内存建议 32GB因为大模型加载时有一部分要占共享显存内存不够会直接 OOM。硬盘至少留 80GB光是下载模型权重就要 30GB 上下剩下是生成的素材缓存。部署路径上我一般会在 /data/ai-drama 这样的目录下操作避开中文路径这个习惯后面会省掉一堆编码问题。# 建议的目录结构把模型和生成物分开 mkdir -p /data/ai-drama/{models,output,workspace,logs} cd /data/ai-drama # 克隆项目以实际项目仓库说明为准 git clone https://example.com/ai-drama-workflow.git . # 检查显卡驱动和 Docker 环境 nvidia-smi docker version --format {{.Server.Version}}代码里做了三件事一是按模型、输出、工作区三个维度分目录这样后面换模型、清理生成物都干净二是克隆项目文件三是确认 NVIDIA 容器运行时可用。注意第三行nvidia-smi必须能打出显存信息如果报错说明你的宿主机显卡驱动有问题容器里再怎么配都白搭。2.3 模型底座的拉取与版本对齐这个项目最容易被忽略的是模型版本对齐。它默认接的是 Ollama 拉取的 Qwen 系列模型图像生成端接的是 Stable Diffusion WebUI 的 API语音合成端接的是 GPT-SoVITS 或者 Edge-TTS 的本地服务。三个服务各有自己的版本要求——比如 Ollama 要 0.1.40 以上才能稳定跑多模态输入SD WebUI 最好用 1.9 及以上版本否则 API 的返回格式不一致。# 拉取剧本生成用的语言模型示例为 7B 量级显存紧张可换 3B ollama pull qwen2.5:7b # 启动工作流编排容器注意挂载本机模型目录 docker run -d --name workflow-engine \ -v /data/ai-drama/models:/workspace/models \ -v /data/ai-drama/output:/workspace/output \ -e OLLAMA_HOSThost.docker.internal:11434 \ -e SD_WEBUI_URLhttp://host.docker.internal:7860 \ -p 8080:8080 \ ai-drama-workflow:latest这里的关键是把宿主机上 Ollama 的 11434 端口和 SD WebUI 的 7860 端口透传给容器让容器内的编排引擎能通过host.docker.internal访问到宿主机服务。-v挂载参数把模型目录共享进容器避免容器内重复下载权重。如果你用的是 Windows WSL2 环境host.docker.internal这个域名有版本差异建议先用docker run --rm alpine ping host.docker.internal验证通不通。3. 核心模块逐模块拆解从剧本到成片中间到底发生了多少次转换3.1 剧本生成模块结构比文采重要短剧剧本不是小说它要的是节拍。这个工具内置的提示词模板把编剧逻辑硬编码成了结构化输出——每一集分为若干场每场包含场景描述、角色、对白、动作提示和运镜建议。这个设计很聪明因为后面的分镜和视频生成不是读自然语言而是读 JSON 字段。# 调用本地 LLM 生成剧本结构注意 system prompt 里约定了 JSON 输出格式 import requests import json prompt { model: qwen2.5:7b, messages: [ {role: system, content: 你是一名短剧编剧。输出必须是 JSON包含 episodes 数组每个元素有 title、scenes每个 scene 有 location、characters、dialogue、action、camera。不要输出任何解释文字。}, {role: user, content: 写一个都市复仇题材的第一集3 个场景节奏要快每场不超过 80 字。} ], format: json, stream: False, options: {temperature: 0.7, top_p: 0.9} } resp requests.post(http://localhost:11434/api/chat, jsonprompt) data resp.json() # 解析出第一个场景作为后续分镜的输入 first_scene data[message][content][episodes][0][scenes][0] print(f场景位置: {first_scene[location]})这段代码里format: json让 Ollama 强制输出合法 JSON 结构temperature控制的是发散程度——短剧剧本用 0.7 比较稳太高会跑题太低会干巴巴。我踩过的坑是stream: False必须显式声明否则返回的是一个异步流对象解析message.content会拿到 None。拿到场景后下一步要把它拆成关键帧描述。3.2 分镜与关键帧文字到图像的映射细节分镜是整个链路里信息丢失最严重的环节。LLM 输出的自然语言描述图像模型不一定理解。这个工具的解决办法是内置了一套“场景修饰器”——把剧本文本自动转成 SD WebUI 能理解的标签式提示词比如把“昏暗的办公室、落地窗、压抑氛围”转成dark office, floor-to-ceiling windows, gloomy atmosphere, cinematic lighting, wide shot。# 调用 SD WebUI API 生成关键帧img2img 模式保证角色一致性 sd_payload { prompt: dark office, floor-to-ceiling windows, gloomy atmosphere, cinematic lighting, wide shot, 1girl, suit, negative_prompt: lowres, bad anatomy, bad hands, extra fingers, blurry, steps: 28, cfg_scale: 7.0, width: 768, height: 432, seed: 20240101, batch_size: 4 } r requests.post(http://localhost:7860/sdapi/v1/img2img, jsonsd_payload) # 返回的 images 字段是 base64 编码的 PNG img_b64 r.json()[images][0]这里的seed我故意固定了不是忘了加随机——固定种子是角色一致性的土办法同一个角色在同一个种子下生成的面部特征偏差会小很多。batch_size: 4是关键一次性生成 4 张候选图让你挑如果只生成一张再重新抽种子变了角色长相也跟着变了那才是灾难。另外注意宽高比用了 768x432这是 16:9 的横屏参数如果你要的是抖音竖屏短剧要改成 432x768重点词全部重新调整后面我会说竖屏的坑。3.3 语音合成对白音色分离的正确姿势短剧配音和普通有声书不一样它要区分角色。这个项目的语音环节用了 GPT-SoVITS 进行零样本音色克隆你只需要上传几秒钟的目标音色样本它就能用这个音色朗读任何文本。对接方式是通过它的 API 端口传入文本和音色参考音频路径。# 启动 GPT-SoVITS API 服务使用项目自带的配置 cd /data/ai-drama/models/GPT-SoVITS python api_v2.py -a 127.0.0.1 -p 9880 -c GPT_SoVITS/configs/tts_infer.yaml # 验证是否启动成功返回音频二进制数据 curl -X POST http://127.0.0.1:9880/tts \ -H Content-Type: application/json \ -d {text: 你不配站在这里。, seed: 42, messages: []} \ --output test.wav这个服务有几个参数特别关键。seed决定每次生成的音色稳定性同一个 seed 出来的音色波动会小很多这个数字建议固化在项目配置里。messages数组可以传上一轮的对白作为参考GPT-SoVITS 会模仿前一句的情绪状态这个特性可以实现同一角色在争吵场景里越说越激动的情感递进。如果你只想要稳定的叙述腔messages留空即可。这里最容易翻车的点是音频采样率——GPT-SoVITS 默认输出 32000 Hz而后面视频合成器通常要 44100 Hz不转码的话音画会不同步。4. 避坑本地 AI 短剧生成最容易翻车的五个点4.1 角色一致性崩坏就算是同个 seed换个提示词长相也会变现象同一角色在场景 A 和场景 B 里长得像两个人观众一眼出戏。原因img2img模式下提示词里的角色描述不完全一致哪怕只改了一个形容词面部特征就会被重新“脑补”。解决把角色核心描述固化成模板变量——比如把“1girl, suit, black hair, red eyes”存成{character_boss}每个场景的 prompt 都由这个变量开头然后接场景描述绝不在主描述里二次修改角色外观词。另外用ControlNet的openpose或depth模式约束姿态也能稳住轮廓但最开始的模板变量法成本最低。4.2 显存被吃满导致生成中断OOM 不是模型太大是并发没关现象跑到第三个场景时 SD WebUI 报CUDA out of memory。原因SD WebUI 里的--no-half参数没开或者后台还挂着 ControlNet 的多个模型每个都要占 2GB 显存。解决启动 SD WebUI 时加上--medvram模式同时把batch_size从 4 降到 1生成完成立即调torch.cuda.empty_cache()。更狠的做法是给 SD WebUI 打个请求排队插件阻止工作流并发打进来的请求宁可慢一点不能崩。4.3 TTS 对白和画面时长对不上修了采样率又蹦出来语速问题现象配音文件比画面短一大截生成出来的视频画面已经切走台词还没说完。原因GPT-SoVITS 默认语速偏慢而且标点符号会触发较长的停顿。解决在调用 TTS 的代码里统一做变速处理用ffmpeg -filter:a atempo1.15把语速提 15%如果还是俫检查文本是否被截断——有些中文标点比如省略号会让 TTS 生成超长静音直接删掉这类符号。我一般会在工作流里加一个自动断言TTS 音频时长必须介于场景预期时长的 0.9 倍到 1.2 倍之间否则直接重新生成不留隐患。4.4 中文路径和文件名乱码Linux 容器里生成的素材拷到 Windows 全变杠现象生成的 PNG 文件名显示类似ç”»é¢的乱码Docker 容器里访问不到。原因宿主机 Windows 用的是 GBK 编码Linux 容器是 UTF-8中文字符在跨系统传输时编码错乱。解决项目里所有生成的素材文件名统一用时间戳加序号例如scene_001_v3.png不用语义化文件名。剧本和提示词里的中文只存在于内容层不进入文件系统层。这个规则我从踩坑之后一直强制保留——文件名里彻底禁中文不然光排查文件对应关系就够你喝一壶。4.5 工作流编排引擎卡死日志文件无限膨胀磁盘被撑爆现象跑了一晚上第二天打开发现生成速度奇慢进容器看日志文件已经十几个 GB。原因编排引擎默认开启 debug 日志每生成一张图就记录全部 prompt 和 base64 编码的完整图像数据日志文件膨胀速度远超预期。解决在启动命令里加LOG_LEVELINFO并配置 logrotate 定期切割日志。base64 图像数据只允许出现在内存里不允许落盘到日志文件。这个问题的隐蔽性在于日志文件不会报错你只会觉得“怎么越来越慢”没有磁盘告警根本发现不了。5. 把模块串成工作流引擎Dify 之外的另一种编排思路与迁移策略5.1 工作流定义文件解析节点、边和参数传递这套项目的前端是一个短剧工作流管理平台后端则是一套基于节点图的运行引擎。只要你定义好工作流配置文件引擎就会按依赖关系自动调度上面的模块。这种方式比 Dify 这种开源工作流平台更轻——它不需要一个常驻的服务来管理工作流定义一切都是声明式 YAML 文件。# workflow.yaml 核心片段定义了从剧本到配音的节点连接 nodes: - id: script_gen type: llm model: qwen2.5:7b prompt_template: prompts/script_v2.txt output: scenes_json - id: scene_splitter type: http url: http://localhost:8000/split_scenes input: ${scenes_json} output: scene_list - id: tts_gen type: gpt_sovits host: 127.0.0.1 port: 9880 seed: 42 input: ${scene_list.dialogue} output: audio_per_scene edges: - from: script_gen to: scene_splitter - from: scene_splitter to: tts_gen${scenes_json}这种引用语法是节点间的数据通道。script_gen节点产出的 JSON 会自动注入scene_splitter的输入。边edges定义了执行的先后顺序引擎检测到tts_gen依赖scene_splitter的输出就会等后者完成再执行。这里要特别提一下prompt_template字段它指向一个外部文件这意味着你可以不改代码只改提示词模板就调整整个剧本风格——我一般会把模板文件按题材拆成script_urban.txt、script_ancient.txt、script_fantasy.txt切换题材只需改一个字段。5.2 与 Dify / Coze 工作流平台的适用分界很多人问这个项目和 Dify 有什么区别。我的判断是Dify 适合做轻量级的编排——比如把一个大模型调用和几个工具节点串起来它的可视化界面确实友好但节点类型受限像 GPT-SoVITS 这种本地服务要封装成工具插件才能接入且并发调度能力一般。Coze 更偏云端本地化部署要自己搞代理。这套工具的价值在于它是为“短剧生产”专门设计的——节点类型直接写好了gpt_sovits、sd_webui、video_merge不用你自己写插件封装。如果你的工作流是要处理图像、音频、视频三类重资产数据用通用工作流平台反而要多做一层转换。另外这个引擎支持断点重跑——某个节点挂了修好之后从失败节点开始继续跑不用从头来过这对长剧集特别关键。5.3 视频合成节点ffmpeg 命令行封装出的转场逻辑最后一个关键节点是视频合成。引擎会调用 ffmpeg 把图像序列、音频轨道和字幕文件合成为短视频。它默认按“场景切、声音进”的规则拼——每个场景的静态图保持 3 到 5 秒配音音频长度决定实际停留时间然后硬切或叠化转场。# 引擎内部生成的 ffmpeg 命令示例为单个场景合成 ffmpeg -y \ -loop 1 -i scene_001_v3.png \ -i dialogue_001.wav \ -filter_complex [0:v]scale768:432:force_original_aspect_ratiodecrease,pad768:432:(ow-iw)/2:(oh-ih)/2,formatyuv420p[v]; [1:a]aformatsample_rates44100:channel_layoutsstereo[a] \ -map [v] -map [a] \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 128k \ -t 5.0 \ output_scene_001.mp4这个命令里-loop 1把单张图片变成无限时长视频流-t 5.0限制输出长度pad滤镜处理图片比例不对时的黑边问题。特别注意aformat把 TTS 的 32000 Hz 强制转成 44100 Hz 标准采样率这就是规避前面提到音画不同步的兜底措施。crf 23是质量和体积的平衡点预览时调到 28 就够最终成片再回到 23。6. 从“能跑通”到“敢用于交付”批量出片与素材溯源的两个硬习惯到这一步完整流程已经能跑通了但离“批量生产”还差一个质检层。我在跑完前十条片子之后沉淀了两个必须强制执行的流程缺一个都会在交付时翻车。第一个是批量出片后的抽检脚本。每生成一批十个短视频我不会直接打包交付而是先跑一段自动抽检把每个视频的时长、分辨率、音频采样率和是否有静音片段统计出来。一次跑完整个剧集后用表格对比一眼就能看出哪条片子的音频对不上、哪条画面比例不对。# 批量质检脚本片段扫描输出目录检测异常文件 import os, subprocess, json, glob for mp4 in glob.glob(/data/ai-drama/output/*.mp4): # 用 ffprobe 读取视频流参数 cmd [ffprobe, -v, quiet, -print_format, json, -show_streams, mp4] info json.loads(subprocess.run(cmd, capture_outputTrue, textTrue).stdout) video_stream next(s for s in info[streams] if s[codec_type] video) audio_stream next((s for s in info[streams] if s[codec_type] audio), None) duration float(video_stream.get(duration, 0)) width video_stream[width] height video_stream[height] # 检查时长、分辨率、音频是否存在且采样率合规 if duration 3.0: print(f异常: {mp4} 时长过短 {duration}s) if (width, height) ! (768, 432): print(f异常: {mp4} 分辨率错误 {width}x{height}) if audio_stream is None or int(audio_stream.get(sample_rate, 0)) ! 44100: print(f异常: {mp4} 音频缺失或采样率错误)这段脚本我每次批量出片前都会强制跑一遍duration 3.0s是最常见的异常——说明某个场景的配音没有生成长视频成了无声空镜分辨率错误通常出在 SD WebUI 切换了模型后输出尺寸变动。检查采样率是防止有些文件走了旧版 TTS 缓存路径绕过了转码逻辑。这个脚本几十行但它能在一分钟内告诉我这批片子能不能交付。第二个硬习惯是素材溯源记录。本地生成的最大风险是不知道某张图用的什么提示词、什么种子——一旦客户要改一个角色的眼睛颜色你重新生成全剧还是只重新生成那个场景我的做法是每跑完一批把工作流的 YAML 配置文件、所有关键节点的 seed 值、模型文件 hash 存成一个metadata.json放到输出根目录。这个文件相当于整个生成过程的“黑匣子记录仪”出了任何问题都能回溯到产生问题的具体参数组合。从那以后我每次跑完一批都会强制走一遍抽检脚本 素材溯源入库的流程确认全部通过才进入剪辑交付环节。这套双保险流程是我把这条本地 AI 短剧工作流从“实验室玩具”推向“真能接单生产”的分水岭。希望这套流程和踩坑记录能帮到你——至少让你少走我当初连续熬三个通宵的弯路。本文还有配套的精品资源点击获取 开源本地AI短剧生成工作流：从剧本到成片全自动部署指南
简介这是一款面向短剧与漫剧创作者的开源本地AI生成工具定位为一站式工作流管理平台支持从故事构思、脚本创作到动画及AI真人剧成片的全流程处理数据全程在本地运行兼顾隐私安全与离线可用。适合个人创作者或小型团队尝试不同风格的剧集生产。资源包共227个文件大小41.38MB核心代码以js、vue、sql及json为主包含前端页面、数据库配置与后端逻辑另附bat启动脚本、md文档、jpg/png图片素材及示例mp4可快速部署体验。压缩包内还含有ffmpeg.exe等辅助工具便于本地处理视频资源。目前已有810人学习下载。通过该资源用户可获得完整的开源项目源码、本地部署脚本、数据库初始化文件及目录结构参考帮助理解短剧工作流管理平台的模块设计也可在此基础上修改二次开发借助AI小说创作与情节推进能力提升制作效率。1. 开源本地 AI 短剧生成把“故事→成片”的完整工作流压进一台机器你大概率刷到过那种 AI 生成的短剧运镜虽然有点僵但节奏、对白、分镜完全是工业化水准。这类片子大部分是在云端跑完的角色一致性靠抽卡台词是模板拼的最关键的是整个流程被拆成十几个分散的工具你要自己当胶水。这套开源本地 AI 短剧 漫剧生成工具解决的就是这个问题——它把剧本、分镜、配音、图生视频到剪辑封装成一条完整工作流数据不出本机所有环节通过本地部署的模型串起来。适合已经在用 ComfyUI、Dify 这类本地 AI 工作流平台但苦于没有一个完整短剧生产链路的人。你不用再手动把文案粘进 TTS、再把生成好的图片拖进视频合成器这个平台把中间步骤全部接管了。对我这种习惯把所有生成任务都压在本地跑的人来说它最大的价值不是某个模型多强而是把一条需要六个工具才能走通的生产线压缩成了一个可复现的工作流编排项目。2. 本地部署与底座选型为什么这年头短剧生成必须跑在本地工作流上2.1 本地化方案的三个底层理由隐私、成本和磨刀短剧生成这个事云端方案看着方便但实际用起来有硬伤。第一是隐私剧本通常带原创设定、人物关系甚至真实项目里的商业稿你不可能把未发布的内容整段丢给在线平台。第二是成本一条 60 秒的短剧按云端 API 计价生图、生视频、语音合成加起来可能十几块人民币十条就是一百多一个月下来够买一块本地显卡了。第三是调试效率云端方案的接口文档变来变去参数调整一次要等半天回包本地跑最大的优势是你可以反复试错改一个提示词立刻出结果。这套工具的部署形态是典型的 Docker Compose 全家桶不搞花活。核心组件包括一个大模型服务做剧本和分镜、一个语音合成服务读旁白和对白、一个图像生成服务出关键帧外加一个工作流编排引擎把三者串起来。我用下来的感受是这个组合选得很务实——不是追最前沿的模型而是选社区最活跃、文档最全、出问题能搜到答案的那一套。这在你面对一个全新的生产环节时特别重要。2.2 部署前的硬件清单和目录规划先把家底盘清楚。这个项目的部署底线是 8GB 显存的 NVIDIA 显卡16GB 显存会从容很多。内存建议 32GB因为大模型加载时有一部分要占共享显存内存不够会直接 OOM。硬盘至少留 80GB光是下载模型权重就要 30GB 上下剩下是生成的素材缓存。部署路径上我一般会在 /data/ai-drama 这样的目录下操作避开中文路径这个习惯后面会省掉一堆编码问题。# 建议的目录结构把模型和生成物分开 mkdir -p /data/ai-drama/{models,output,workspace,logs} cd /data/ai-drama # 克隆项目以实际项目仓库说明为准 git clone https://example.com/ai-drama-workflow.git . # 检查显卡驱动和 Docker 环境 nvidia-smi docker version --format {{.Server.Version}}代码里做了三件事一是按模型、输出、工作区三个维度分目录这样后面换模型、清理生成物都干净二是克隆项目文件三是确认 NVIDIA 容器运行时可用。注意第三行nvidia-smi必须能打出显存信息如果报错说明你的宿主机显卡驱动有问题容器里再怎么配都白搭。2.3 模型底座的拉取与版本对齐这个项目最容易被忽略的是模型版本对齐。它默认接的是 Ollama 拉取的 Qwen 系列模型图像生成端接的是 Stable Diffusion WebUI 的 API语音合成端接的是 GPT-SoVITS 或者 Edge-TTS 的本地服务。三个服务各有自己的版本要求——比如 Ollama 要 0.1.40 以上才能稳定跑多模态输入SD WebUI 最好用 1.9 及以上版本否则 API 的返回格式不一致。# 拉取剧本生成用的语言模型示例为 7B 量级显存紧张可换 3B ollama pull qwen2.5:7b # 启动工作流编排容器注意挂载本机模型目录 docker run -d --name workflow-engine \ -v /data/ai-drama/models:/workspace/models \ -v /data/ai-drama/output:/workspace/output \ -e OLLAMA_HOSThost.docker.internal:11434 \ -e SD_WEBUI_URLhttp://host.docker.internal:7860 \ -p 8080:8080 \ ai-drama-workflow:latest这里的关键是把宿主机上 Ollama 的 11434 端口和 SD WebUI 的 7860 端口透传给容器让容器内的编排引擎能通过host.docker.internal访问到宿主机服务。-v挂载参数把模型目录共享进容器避免容器内重复下载权重。如果你用的是 Windows WSL2 环境host.docker.internal这个域名有版本差异建议先用docker run --rm alpine ping host.docker.internal验证通不通。3. 核心模块逐模块拆解从剧本到成片中间到底发生了多少次转换3.1 剧本生成模块结构比文采重要短剧剧本不是小说它要的是节拍。这个工具内置的提示词模板把编剧逻辑硬编码成了结构化输出——每一集分为若干场每场包含场景描述、角色、对白、动作提示和运镜建议。这个设计很聪明因为后面的分镜和视频生成不是读自然语言而是读 JSON 字段。# 调用本地 LLM 生成剧本结构注意 system prompt 里约定了 JSON 输出格式 import requests import json prompt { model: qwen2.5:7b, messages: [ {role: system, content: 你是一名短剧编剧。输出必须是 JSON包含 episodes 数组每个元素有 title、scenes每个 scene 有 location、characters、dialogue、action、camera。不要输出任何解释文字。}, {role: user, content: 写一个都市复仇题材的第一集3 个场景节奏要快每场不超过 80 字。} ], format: json, stream: False, options: {temperature: 0.7, top_p: 0.9} } resp requests.post(http://localhost:11434/api/chat, jsonprompt) data resp.json() # 解析出第一个场景作为后续分镜的输入 first_scene data[message][content][episodes][0][scenes][0] print(f场景位置: {first_scene[location]})这段代码里format: json让 Ollama 强制输出合法 JSON 结构temperature控制的是发散程度——短剧剧本用 0.7 比较稳太高会跑题太低会干巴巴。我踩过的坑是stream: False必须显式声明否则返回的是一个异步流对象解析message.content会拿到 None。拿到场景后下一步要把它拆成关键帧描述。3.2 分镜与关键帧文字到图像的映射细节分镜是整个链路里信息丢失最严重的环节。LLM 输出的自然语言描述图像模型不一定理解。这个工具的解决办法是内置了一套“场景修饰器”——把剧本文本自动转成 SD WebUI 能理解的标签式提示词比如把“昏暗的办公室、落地窗、压抑氛围”转成dark office, floor-to-ceiling windows, gloomy atmosphere, cinematic lighting, wide shot。# 调用 SD WebUI API 生成关键帧img2img 模式保证角色一致性 sd_payload { prompt: dark office, floor-to-ceiling windows, gloomy atmosphere, cinematic lighting, wide shot, 1girl, suit, negative_prompt: lowres, bad anatomy, bad hands, extra fingers, blurry, steps: 28, cfg_scale: 7.0, width: 768, height: 432, seed: 20240101, batch_size: 4 } r requests.post(http://localhost:7860/sdapi/v1/img2img, jsonsd_payload) # 返回的 images 字段是 base64 编码的 PNG img_b64 r.json()[images][0]这里的seed我故意固定了不是忘了加随机——固定种子是角色一致性的土办法同一个角色在同一个种子下生成的面部特征偏差会小很多。batch_size: 4是关键一次性生成 4 张候选图让你挑如果只生成一张再重新抽种子变了角色长相也跟着变了那才是灾难。另外注意宽高比用了 768x432这是 16:9 的横屏参数如果你要的是抖音竖屏短剧要改成 432x768重点词全部重新调整后面我会说竖屏的坑。3.3 语音合成对白音色分离的正确姿势短剧配音和普通有声书不一样它要区分角色。这个项目的语音环节用了 GPT-SoVITS 进行零样本音色克隆你只需要上传几秒钟的目标音色样本它就能用这个音色朗读任何文本。对接方式是通过它的 API 端口传入文本和音色参考音频路径。# 启动 GPT-SoVITS API 服务使用项目自带的配置 cd /data/ai-drama/models/GPT-SoVITS python api_v2.py -a 127.0.0.1 -p 9880 -c GPT_SoVITS/configs/tts_infer.yaml # 验证是否启动成功返回音频二进制数据 curl -X POST http://127.0.0.1:9880/tts \ -H Content-Type: application/json \ -d {text: 你不配站在这里。, seed: 42, messages: []} \ --output test.wav这个服务有几个参数特别关键。seed决定每次生成的音色稳定性同一个 seed 出来的音色波动会小很多这个数字建议固化在项目配置里。messages数组可以传上一轮的对白作为参考GPT-SoVITS 会模仿前一句的情绪状态这个特性可以实现同一角色在争吵场景里越说越激动的情感递进。如果你只想要稳定的叙述腔messages留空即可。这里最容易翻车的点是音频采样率——GPT-SoVITS 默认输出 32000 Hz而后面视频合成器通常要 44100 Hz不转码的话音画会不同步。4. 避坑本地 AI 短剧生成最容易翻车的五个点4.1 角色一致性崩坏就算是同个 seed换个提示词长相也会变现象同一角色在场景 A 和场景 B 里长得像两个人观众一眼出戏。原因img2img模式下提示词里的角色描述不完全一致哪怕只改了一个形容词面部特征就会被重新“脑补”。解决把角色核心描述固化成模板变量——比如把“1girl, suit, black hair, red eyes”存成{character_boss}每个场景的 prompt 都由这个变量开头然后接场景描述绝不在主描述里二次修改角色外观词。另外用ControlNet的openpose或depth模式约束姿态也能稳住轮廓但最开始的模板变量法成本最低。4.2 显存被吃满导致生成中断OOM 不是模型太大是并发没关现象跑到第三个场景时 SD WebUI 报CUDA out of memory。原因SD WebUI 里的--no-half参数没开或者后台还挂着 ControlNet 的多个模型每个都要占 2GB 显存。解决启动 SD WebUI 时加上--medvram模式同时把batch_size从 4 降到 1生成完成立即调torch.cuda.empty_cache()。更狠的做法是给 SD WebUI 打个请求排队插件阻止工作流并发打进来的请求宁可慢一点不能崩。4.3 TTS 对白和画面时长对不上修了采样率又蹦出来语速问题现象配音文件比画面短一大截生成出来的视频画面已经切走台词还没说完。原因GPT-SoVITS 默认语速偏慢而且标点符号会触发较长的停顿。解决在调用 TTS 的代码里统一做变速处理用ffmpeg -filter:a atempo1.15把语速提 15%如果还是俫检查文本是否被截断——有些中文标点比如省略号会让 TTS 生成超长静音直接删掉这类符号。我一般会在工作流里加一个自动断言TTS 音频时长必须介于场景预期时长的 0.9 倍到 1.2 倍之间否则直接重新生成不留隐患。4.4 中文路径和文件名乱码Linux 容器里生成的素材拷到 Windows 全变杠现象生成的 PNG 文件名显示类似ç”»é¢的乱码Docker 容器里访问不到。原因宿主机 Windows 用的是 GBK 编码Linux 容器是 UTF-8中文字符在跨系统传输时编码错乱。解决项目里所有生成的素材文件名统一用时间戳加序号例如scene_001_v3.png不用语义化文件名。剧本和提示词里的中文只存在于内容层不进入文件系统层。这个规则我从踩坑之后一直强制保留——文件名里彻底禁中文不然光排查文件对应关系就够你喝一壶。4.5 工作流编排引擎卡死日志文件无限膨胀磁盘被撑爆现象跑了一晚上第二天打开发现生成速度奇慢进容器看日志文件已经十几个 GB。原因编排引擎默认开启 debug 日志每生成一张图就记录全部 prompt 和 base64 编码的完整图像数据日志文件膨胀速度远超预期。解决在启动命令里加LOG_LEVELINFO并配置 logrotate 定期切割日志。base64 图像数据只允许出现在内存里不允许落盘到日志文件。这个问题的隐蔽性在于日志文件不会报错你只会觉得“怎么越来越慢”没有磁盘告警根本发现不了。5. 把模块串成工作流引擎Dify 之外的另一种编排思路与迁移策略5.1 工作流定义文件解析节点、边和参数传递这套项目的前端是一个短剧工作流管理平台后端则是一套基于节点图的运行引擎。只要你定义好工作流配置文件引擎就会按依赖关系自动调度上面的模块。这种方式比 Dify 这种开源工作流平台更轻——它不需要一个常驻的服务来管理工作流定义一切都是声明式 YAML 文件。# workflow.yaml 核心片段定义了从剧本到配音的节点连接 nodes: - id: script_gen type: llm model: qwen2.5:7b prompt_template: prompts/script_v2.txt output: scenes_json - id: scene_splitter type: http url: http://localhost:8000/split_scenes input: ${scenes_json} output: scene_list - id: tts_gen type: gpt_sovits host: 127.0.0.1 port: 9880 seed: 42 input: ${scene_list.dialogue} output: audio_per_scene edges: - from: script_gen to: scene_splitter - from: scene_splitter to: tts_gen${scenes_json}这种引用语法是节点间的数据通道。script_gen节点产出的 JSON 会自动注入scene_splitter的输入。边edges定义了执行的先后顺序引擎检测到tts_gen依赖scene_splitter的输出就会等后者完成再执行。这里要特别提一下prompt_template字段它指向一个外部文件这意味着你可以不改代码只改提示词模板就调整整个剧本风格——我一般会把模板文件按题材拆成script_urban.txt、script_ancient.txt、script_fantasy.txt切换题材只需改一个字段。5.2 与 Dify / Coze 工作流平台的适用分界很多人问这个项目和 Dify 有什么区别。我的判断是Dify 适合做轻量级的编排——比如把一个大模型调用和几个工具节点串起来它的可视化界面确实友好但节点类型受限像 GPT-SoVITS 这种本地服务要封装成工具插件才能接入且并发调度能力一般。Coze 更偏云端本地化部署要自己搞代理。这套工具的价值在于它是为“短剧生产”专门设计的——节点类型直接写好了gpt_sovits、sd_webui、video_merge不用你自己写插件封装。如果你的工作流是要处理图像、音频、视频三类重资产数据用通用工作流平台反而要多做一层转换。另外这个引擎支持断点重跑——某个节点挂了修好之后从失败节点开始继续跑不用从头来过这对长剧集特别关键。5.3 视频合成节点ffmpeg 命令行封装出的转场逻辑最后一个关键节点是视频合成。引擎会调用 ffmpeg 把图像序列、音频轨道和字幕文件合成为短视频。它默认按“场景切、声音进”的规则拼——每个场景的静态图保持 3 到 5 秒配音音频长度决定实际停留时间然后硬切或叠化转场。# 引擎内部生成的 ffmpeg 命令示例为单个场景合成 ffmpeg -y \ -loop 1 -i scene_001_v3.png \ -i dialogue_001.wav \ -filter_complex [0:v]scale768:432:force_original_aspect_ratiodecrease,pad768:432:(ow-iw)/2:(oh-ih)/2,formatyuv420p[v]; [1:a]aformatsample_rates44100:channel_layoutsstereo[a] \ -map [v] -map [a] \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 128k \ -t 5.0 \ output_scene_001.mp4这个命令里-loop 1把单张图片变成无限时长视频流-t 5.0限制输出长度pad滤镜处理图片比例不对时的黑边问题。特别注意aformat把 TTS 的 32000 Hz 强制转成 44100 Hz 标准采样率这就是规避前面提到音画不同步的兜底措施。crf 23是质量和体积的平衡点预览时调到 28 就够最终成片再回到 23。6. 从“能跑通”到“敢用于交付”批量出片与素材溯源的两个硬习惯到这一步完整流程已经能跑通了但离“批量生产”还差一个质检层。我在跑完前十条片子之后沉淀了两个必须强制执行的流程缺一个都会在交付时翻车。第一个是批量出片后的抽检脚本。每生成一批十个短视频我不会直接打包交付而是先跑一段自动抽检把每个视频的时长、分辨率、音频采样率和是否有静音片段统计出来。一次跑完整个剧集后用表格对比一眼就能看出哪条片子的音频对不上、哪条画面比例不对。# 批量质检脚本片段扫描输出目录检测异常文件 import os, subprocess, json, glob for mp4 in glob.glob(/data/ai-drama/output/*.mp4): # 用 ffprobe 读取视频流参数 cmd [ffprobe, -v, quiet, -print_format, json, -show_streams, mp4] info json.loads(subprocess.run(cmd, capture_outputTrue, textTrue).stdout) video_stream next(s for s in info[streams] if s[codec_type] video) audio_stream next((s for s in info[streams] if s[codec_type] audio), None) duration float(video_stream.get(duration, 0)) width video_stream[width] height video_stream[height] # 检查时长、分辨率、音频是否存在且采样率合规 if duration 3.0: print(f异常: {mp4} 时长过短 {duration}s) if (width, height) ! (768, 432): print(f异常: {mp4} 分辨率错误 {width}x{height}) if audio_stream is None or int(audio_stream.get(sample_rate, 0)) ! 44100: print(f异常: {mp4} 音频缺失或采样率错误)这段脚本我每次批量出片前都会强制跑一遍duration 3.0s是最常见的异常——说明某个场景的配音没有生成长视频成了无声空镜分辨率错误通常出在 SD WebUI 切换了模型后输出尺寸变动。检查采样率是防止有些文件走了旧版 TTS 缓存路径绕过了转码逻辑。这个脚本几十行但它能在一分钟内告诉我这批片子能不能交付。第二个硬习惯是素材溯源记录。本地生成的最大风险是不知道某张图用的什么提示词、什么种子——一旦客户要改一个角色的眼睛颜色你重新生成全剧还是只重新生成那个场景我的做法是每跑完一批把工作流的 YAML 配置文件、所有关键节点的 seed 值、模型文件 hash 存成一个metadata.json放到输出根目录。这个文件相当于整个生成过程的“黑匣子记录仪”出了任何问题都能回溯到产生问题的具体参数组合。从那以后我每次跑完一批都会强制走一遍抽检脚本 素材溯源入库的流程确认全部通过才进入剪辑交付环节。这套双保险流程是我把这条本地 AI 短剧工作流从“实验室玩具”推向“真能接单生产”的分水岭。希望这套流程和踩坑记录能帮到你——至少让你少走我当初连续熬三个通宵的弯路。本文还有配套的精品资源点击获取