企业官网建设流程全解析

简介：这是一款面向短剧与漫剧创作者的开源本地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_HOST="host.docker.internal:11434" \ -e SD_WEBUI_URL="http://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", json=prompt) 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", json=sd_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 "atempo=1.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_LEVEL=INFO，并配置 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]scale=768:432:force_original_aspect_ratio=decrease,pad=768:432:(ow-iw)/2:(oh-ih)/2,format=yuv420p[v]; [1:a]aformat=sample_rates=44100:channel_layouts=stereo[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_output=True, text=True).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 短剧工作流从“实验室玩具”推向“真能接单生产”的分水岭。希望这套流程和踩坑记录能帮到你——至少让你少走我当初连续熬三个通宵的弯路。

本文还有配套的精品资源，点击获取