简介面向短剧、漫剧创作者、内容团队及AI产品开发者的一份自动化生成平台源码包。其核心定位是输入一句话即完成从剧本、分镜、配音到成片输出的全流程创作把原本依赖编剧、拍摄、剪辑的复杂链路压缩为AI驱动的单点操作显著降低短视频制作门槛。包内共365个文件以Go语言后端服务为主体搭配TypeScript与Vue构成前后端工程核心模块涉及提示词处理、AI控制、分镜任务调度等另含SQL脚本、环境变量、说明文档与配置文件压缩包约2.48MB目录结构清晰便于按模块定位代码。当前已有805人学习下载。这份资源包含可部署的前后端源码、自动化分镜任务调度逻辑与配套配置示例可直接用于二次开发或原型验证从文件结构可观察Go服务与前端Vue工程的清晰分层方便梳理一句话生成短剧的整体架构与数据流转路径。1. 灵果短剧AI在解决什么问题一句话到成片中间的坑比想象中多“一句话生成一部短剧”听起来像营销话术但灵果短剧AI这类一站式平台确实把短视频剧集的生产拆成了可自动化的流水线剧本由大模型生成分镜从剧本结构化出来画面、配音、字幕、背景音各自由独立模型完成最后合成一个完整成片。对于没有导演和剪辑团队的个体创作者、MCN中台或者想短周期验证剧情脚本的短剧从业者这套方案能大幅压缩从创意到样片的时间。但“全自动化”不等于“全自动出好片”真正落地时模型的配合方式、参数的调整以及中间格式的可靠程度往往比模型本身更决定成片质量。这篇笔记会顺着这条流水线把每个环节做什么、为什么这样做、参数怎么调、坑在哪里讲透。2. 拆开“全自动化”从剧本到成片的六段流水线一个完整的短剧/漫剧生成平台内部并不是一个“大模型吃进一句话吐出一整段视频”而是一条多AI协作的流水线。我接触过的类似方案基本都是六个模块串起来剧本生成、分镜设计、角色与画面生成、配音、字幕/合成。下面拆开讲清楚每个模块的职责和选型理由这对后续调参和排错很重要。2.1 为什么不能只要一个大模型多AI协作的流水线结构很多第一次接触这类平台的人会问为什么不直接用视频生成大模型比如输入“悬疑短剧开场妻子深夜回家发现门锁被换”让模型直接输出一段40秒视频答案是目前任何单模型都做不到可控的剧情和角色一致性。视频生成模型擅长生成几秒到十几秒的“画面片段”但它不理解“第一集留悬念、第三集揭示对立”这种叙事结构更无法保证同一角色在不同镜头里长得一样。这就像让一个画师直接画一部动画他画得完但前后风格、人物长相、剧情连续性都会崩。所以常见做法是拆成多个专用模型用流水线把任务分给不同模型语言模型负责把一句话扩写成剧本另一个语言模型把剧本转成分镜表图像模型根据分镜生成关键帧视频模型再基于关键帧生成动态片段TTS模型负责对白最后用FFmpeg之类工具合成。每个环节只做一件事彼此通过文件或JSON接口传递数据这样即使某个环节翻车也能单独替换或重新跑。这个思路不是灵果独有而是这类AI视频生成的通用工程架构。流水线的数据结构可以用一个简单的 JSON 中间格式来理解。以下是我在类似项目里常用的一种分镜表示{ video_title: 陌生邻居, scenes: [ { scene_id: 1, duration_sec: 5.0, shot_type: 中景, camera: 缓慢推进, prompt: 深夜公寓走廊一个年轻女性站在自家门前钥匙滑落, dialogue: 钥匙声怎么打不开, character: 女主 } ] }这段结构里scene_id 用来排序duration_sec 控制时长prompt 给视觉模型dialogue 给配音。把剧本输出成这种结构的好处是后续每个模型读到的都是明确的“最小任务”视频生成模型一次性只需生成5秒内容压力小生成成功率也高。参数说明shot_type 和 camera 会影响镜头控制但在国内可用的视频生成模型里它们未必会被完全遵守所以 prompt 里的描述越具体越好。2.2 剧本生成与结构化分镜中间格式才是关键流水线的第一环是“一句话扩展成剧本”。这里的核心不是让模型写得多精彩而是让它输出“结构化剧本”——即带有场次、角色动作、对白、时长的脚本。如果只输出一个散文故事后续分镜就没法自动化。所以常见做法是在 Prompt 里强制模型输出 JSON 或表格然后用代码解析。灵果这类平台通常内置了剧本模板但我自己接第三方模型时发现模板的稳定性决定了整个流程的成败。举个例子给剧本模型的提示词里除了写“生成一个3集短剧每集60秒”还要明确要求“每集包含3个场景每个场景包含动作描述和对白”并且给一个输出样例。这里有三点容易踩坑第一模型输出的 JSON 可能带注释或换行直接 json.loads 会失败需要先做清洗第二分镜数量太密会让后续视频生成步数爆炸每集60秒分成6个10秒镜头是比较稳的节奏第三对白里如果包含括号动作提示配音模型会读出来必须用正则提前剥离。剧本模型我一般会用支持超长上下文的对话模型因为生成完一集后下一集要基于前情避免人物关系和风格断裂。如果直接用无状态接口每集的角色设定会漂移刚才还叫“女主张薇”下一集可能变成“李薇”。一个很土但有效的办法是把第一集生成的“人物设定表”作为额外上下文喂给第二集的生成请求而不是只喂第一集全文。2.3 角色一致性与画面生成最考验工程的部分分镜表有了下一步是生成画面。这一步在全自动化链路里最不可控。视频生成模型确实能根据 Prompt 生成动态片段但同一个角色在多个分镜里要保持五官、服装、发型一致需要额外机制。常见做法有两种一种是先用图像模型SD系列生成一张“角色设定图”然后在视频生成时把这张图作为条件输入让模型参考另一种是给每个角色设计一个独特的视觉标记词比如“红色短发、左脸有痣”保证每次 Prompt 都带上这个词。我在实际项目里更推荐“角色图 描述词”双保险。因为纯文字标记在长剧集里会丢失模型一眼没注意就成了另一个人。角色图相当于给了一个参考锚点大幅降低脸崩概率。具体实现上可以用 IP-Adapter / 类似参考网络也可以直接把角色图拼进首帧。不同视频模型对输入格式的要求差异很大有的只认首帧图有的支持多参考图所以在配置层要留出接口不要写死。漫剧和短剧在这里也有区别。漫剧的画面相对静态主要靠分镜切换和运镜对视频生成的一致性压力小得多甚至可以退化为“高质量图片 局部运动”方案。短剧则更需要肢体动作和面部表情对视频生成模型的推理时长和显存要求更高。如果只是做漫剧我不建议直接上视频生成用图生视频里“轻微运动”模式就够成本低且不容易鬼畜。2.4 配音、字幕与成片合成用 FFmpeg 把碎片拼成剧画面片段生成后还需要配音、字幕、背景音乐和拼接。配音这一环相对简单TTS 模型已经非常成熟需要注意的就是语速和情绪标注。台词模型支持情感提示比如“低声”“急促”但并不是所有 TTS 都认需要测试。我一般会把对白中的括号内容全部剥离只保留纯台词然后用额外的参数控制语速和音调否则配音会给人“念稿”的感觉。最后合成阶段所有AI平台都离不开 FFmpeg。这一步的工程价值常常被低估。每个分镜的视频片段分辨率、帧率可能不同拼接前要统一转码字幕文件需要和音频时间轴对齐而音画不同步是最常见的翻车原因。我会在这时做一个中间检查先不合成画面只把对白音频拼起来检查总时长是否与分镜总时长一致差了再调整视频片段时长或加转场。使用 FFmpeg 合成的基本命令如下ffmpeg -f concat -safe 0 -i filelist.txt -c:v libx264 -pix_fmt yuv420p -crf 18 output.mp4其中 filelist.txt 每行是“file scene_001.mp4”顺序由分镜编号决定。逻辑说明concat 协议用于无缝拼接同编码片段libx264 做编码yuv420p 保证兼容性crf 控制画面质量。参数说明crf 值越小质量越高但文件也更大如果片段分辨率不一致要先统一分辨率否则 concat 会失败或黑屏。这一步的坑后面避坑章节还会细说。3. 本地部署与最小跑通从 Lingg.zip 到第一条成片拿到灵果短剧AI这类 zip 包后第一件事不是急着跑而是先搞清包里的结构。常见的压缩包会包含核心代码、模型调用脚本、配置文件和一个示例输入目录。部署的核心是把模型后端接好而不是把前端跑起来。下面按环境、配置、最小示例三步走。3.1 环境准备Python版本、依赖与显存规划这类项目几乎都是 Python 写的依赖里通常包含 PyTorch、transformers、diffusers、openai、ffmpeg-python 等。如果直接用全局环境很容易和已有的包冲突。我一般会先建一个独立的虚拟环境再用 requirements.txt 安装。注意两个高频坑第一PyTorch 和 CUDA 版本不匹配会导致模型加载时报错第二有些包在 requirements.txt 里是 github 路径需要先装 git 和编译工具。一个相对稳妥的安装流程如下cd Lingg python -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt python -c import torch; print(torch.__version__, torch.cuda.is_available())逻辑说明venv 把项目依赖隔离在单独目录避免污染系统 Pythonrequirements.txt 是项目开发者锁定的依赖清单按顺序安装即可。参数说明最后一行用来验证 torch 是否识别 GPU如果输出 False说明 CUDA 没装对后面跑视频生成几乎注定翻车。这一步会花不少时间建议用国内 pip 镜像加速但不要因镜像版本滞后而强制升级核心依赖。显存规划是另一件大事。视频生成模型对显存的占用非常高默认参数下生成 10 秒 512x768 的视频一般需要 12GB 以上显存。如果你的显卡只有 8GB常见做法是开启 offload把模型权重临时放在内存GPU 只做计算或者降低生成分辨率。灵果这类平台如果集成了视频生成后端配置文件中通常有“device_map”或“enable_offload”选项不要忽略它。显存不够会直接 OOM 崩溃但很多项目不会告诉我“OOM”因为它是静默的表现为生成到一半进程退出。3.2 配置 config.yaml模型后端、密钥与路径解压之后项目根目录一般会有一个 config.yaml 或 .env 文件记录了所有模型接口的配置。无论是调用云端大模型 API还是本地加载开源模型都要在这里把地址、密钥、模型名称写清楚。常见做法是剧本模型用云端 API视频和图像模型用本地/私有化部署。因为剧本模型的上下文理解和长文生成云端模型效果更好而视频模型如果走云端按秒计费成本非常高所以有本地算力的话尽量本地跑。下面是我整理的一个最小配置示例比真实项目的简单但结构类似llm: provider: openai_compatible base_url: http://10.0.0.2:8000/v1 api_key: sk-xxx model: qwen-long temperature: 0.7 video: provider: local model_path: /data/models/animatediff_ckpt resolution: [512, 768] frames: 30 enable_offload: true tts: provider: edge_tts voice: zh-CN-XiaoxiaoNeural rate: 10%参数说明llm 段里的 base_url 指向一个兼容 OpenAI 接口的服务api_key 可以是代理服务生成的不一定是某个官方账号的密钥temperature 控制剧本的随机性0.7 算是稳定和创意的平衡点做剧情悬疑时我会调到 0.8做口播短剧会降到 0.5。video 段里的 model_path 是本地模型权重目录frames 表示要生成的帧数30 帧配合 512x768 在大多数场景下能生成约 1 秒内容。tts 的 rate 是语速偏移10% 表示比默认速度快 10%。这里要特别提醒不要把云端服务的接口地址误写成 localhost。把大模型部署在同一台机器上的话地址通常是一串局域 IPlocalhost 只在同一进程内起服务时才有效。配置好后建议先用 curl 快速验证接口能不能通再跑完整流程。3.3 跑通最小示例一句话生成10秒漫剧配置完成接下来跑一个最小的示例。项目里一般会有一个 run_pipeline.py 或 split_generator.py 之类的主脚本入口是传入一句剧情梗概输出成片路径。我第一次跑的时候会先用一个极短的句子比如“女主发现邻居的门锁换了”而不是给“三十集都市悬疑”这种大活方便定位问题。一个典型的最小调用如下python run_pipeline.py --text 女主深夜回家发现门锁被换 --scenes 2 --output demo1.mp4逻辑说明--text 是那句“一句话”--scenes 控制生成几个镜头这是为了快速验证--output 是输出文件。参数说明如果脚本内部用的是配置文件里的模型那么 --scenes 2 会让剧本模型输出两个分镜后续视频生成也只跑两个片段整个流程可以在几分钟内跑完。如果此时显存不够就把 config.yaml 里的 resolution 改成 [384, 512] 再试。跑通之后你会看到输出目录里多了一些临时文件剧本 JSON、每个分镜的图片/视频、对白音频、字幕 SRT最后合成的 demo1.mp4。我一般会逐个检查这些中间文件因为“成片能播放”不等于“环节都正确”。例如有个分镜视频是黑屏但整体合成成功了这种情况就是某个环节静默失败必须看日志里有没有“empty frame”之类的警告。把这个最小链路跑通后续才谈得上批量生成和调质量。4. 让输出变“能看”四个关键参数组怎么调跑通不等于能用。AI 生成的短剧在“能看”和“不能看”之间的差距往往是几个关键参数决定的。这一章把调参经验按流水线顺序展开剧本、分镜、视频、配音字幕。每个参数都给出我常用的取值范围和调整方向你可以把它们作为起点再针对自己的素材微调。4.1 剧本参数长度、冲突密度与句式剧本生成参数中最重要的是“输出长度”和“随机性”。输出长度由 tokens 或字数上限控制如果你发现生成的对白像论文一样长或者三句话就结束一个场景就要调整长度参数。另一个是 temperature高于 0.9 时模型会频繁“脑洞”容易出现前后矛盾的角色决策低于 0.4 时又过于机械像是翻版广告文案。我处理悬疑短剧时一般用 0.75处理甜宠剧会降到 0.6因为甜宠剧更依赖固定套路不需要太多意外。除了采样参数Prompt 才是最大的“参数”。建议在提示词里显式限制对白句式比如“不写旁白只写对白”以及“每句对白不超过25个字”。原因是短剧观众只能通过字幕快速读对白长句会让人觉得节奏拖沓。如果项目里支持“负面提示词”给 LLM也加上“避免总结性句式、避免主角长篇内心独白”这一类限制比调 temperature 更有用。4.2 分镜参数镜头数、运镜与画面描述分镜是把剧本转成画面的关键这一层的参数往往会被忽略。最重要的两个是“每集场景数”和“每个场景的时长”。场景数太多每个场景分配到的时长变短视频模型来不及展示有效动作场景太少又会让画面看起来像幻灯片。一个规律是每 10 秒的视频控制在 2 到 3 个镜头的节奏这样既有机位变化又保留了脸部特写的停顿。画面描述要尽量贴近视频生成模型的语言习惯。你没做过的话可以从这三个维度补全描述主体动作、镜头运动、场景氛围。举例{ scene: 1, duration_sec: 5, prompt: 深夜公寓走廊暖黄灯光女主拿钥匙开门却打不开镜头缓慢推进到她的面部表情紧张 }逻辑说明这段 prompt 的前半段是静态环境中间是动作末尾是镜头和情绪。参数说明如果视频模型对“缓慢推进”支持不好就换成“固定镜头”或“变焦”生成失败率会低很多。另一个常见参数是 negative_prompt比如“文字、水印、模糊、变形的手、多余的人”能显著减少画面瑕疵。灵果这类平台可能在分镜生成阶段没有让用户填负向提示但我一般会在配置文件里预留一个字段把负面词传进去。4.3 视频生成参数帧率、步数与分辨率视频生成的三个最关键参数是帧率、采样步数和分辨率。它们的优先级排序是分辨率 步数 帧率。分辨率高反而容易让画面细节崩坏因为模型在 1024x1024 下生成的复杂场景手部和眼睛跑形概率远大于 512x768。如果不是做横屏精品我建议默认 512x768竖屏短剧对应的分辨率。采样步数和帧率的关系也容易被误解。步数决定视频的噪声去除次数步数太低画面闪太高会过饱和。通常 20 到 25 步是安全区。帧率参数会影响文件大小和流畅度但很多视频模型并不支持任意帧率只支持 15/24/30 等预设。如果把帧率设成 18模型会直接按 15 处理导致实际时长不符合预期。我一般把生成的帧率设为 24导出成片时再用 FFmpeg 转成 30避免单个片段时间轴错位。还有一个容易被忽视的参数是“无种子”。视频模型每次生成不同画面适合跑多版本但如果你想重现某次满意的效果就必须固定随机种子。种子参数一般写成 seed: 42但注意不同模型版本对同一 seed 的响应不一样所以记录 seed 时顺便记模型版本不然下次更新权重后之前的参数组合也回不到原来的效果。4.4 配音字幕参数语速、对白样式与背景音配音参数往往决定一个 AI 短剧是否“像样”。TTS 提供语速、音调、音量三个基础参数。语速推荐在10%到20%之间因为 AI 合成默认语速通常偏慢。音调要根据角色设置主角和配角的音调差太近会让观众分不清是谁在说话。如果你是在平台上批量生成配置文件里可以按角色定义 voice 字段同一声色共用同一 TTS 声音。字幕生成也有技术细节如果对白是模型生成的字幕的时间戳需要通过音频的静音段来切分而不是按文本字数推算。很多项目简化处理直接用朗读时长倒推结果字幕提前或滞后。更好的做法是让 TTS 接口返回词级时间戳或者用语音识别反向对齐。如果项目不支持至少要把字幕延迟 100 到 200 毫秒因为人眼识别字幕有惯性字幕比声音稍微慢一点反而自然。背景音和音效通常最后用 FFmpeg 混流。混流的参数主要是音量平衡ffmpeg -i dialogue.wav -i bgm.mp3 -filter_complex [1:a]volume0.2[b];[0:a][b]amixinputs2:durationfirst mix.wav逻辑说明dialogue.wav 是对白音频bgm.mp3 是背景音乐通过 volume 滤镜把背景音乐降到 0.2 倍音量再用 amix 合并。参数说明amix 的 durationfirst 让输出音频长度跟随第一个输入也就是对白音频的时长。背景音太大是很多 AI 短剧的通病建议 0.15 到 0.25 之间宁可弱也不要盖过人声。5. 常见问题排查与避坑指南把翻车率打下来跑通和调参之后你会遇到一些“玄学”问题有时同一套配置生成结果却截然不同。这一章写几个高频踩坑案例每条都是现象、原因、解决的结构也是我自己的血泪经验。5.1 画面崩坏与闪烁清空缓存、锁定种子现象同一段文本生成两次视频第一次人像正常第二次的人脸扭曲或者视频每帧之间的画面剧烈闪烁像老式电视信号不好。 原因闪烁通常是因为视频生成模型在逐帧推理时没有稳定的帧间约束。人脸扭曲则可能是随机种子的影响也可能是参考图像没有被模型正确读取。这类问题属于概率性翻车但在长剧集里一旦出现会让人反复重跑成本极高。 解决首先清理临时缓存目录很多项目会把之前的中间帧存在缓存里重跑时意外复用了坏数据。其次把随机种子固定下来找到一个能接受的输出后锁住 seed。最后如果还闪就把视频解析度降低一级比如 768 降到 512闪烁概率明显下降。5.2 音画不同步先查节拍再查转码现象成片中人物的嘴型明显比台词快半拍或者动作发生完声音才出来。 原因常见原因是分镜时长和 TTS 生成的音频时长不一致。比如脚本里写了这个镜头 5 秒但TTS朗读对白花了8秒拼接时系统直接按“音频总时长”延迟下一个镜头导致画面停留在上一个结尾处。另一个原因是转码时帧率不匹配影响了播放速度。 解决先逐个检查分镜的 audio_duration 和 duration_sec 是否有偏差。有偏差就优先调整分镜时长或文字内容不建议硬调音频速度那样声音会变调。然后确认所有视频片段都由同一个帧率参数生成最后统一转码。如果项目是直接拼接不重编码一定要用 ffprobe 查看每个片段的实际时长因为生成的mp4时长经常比物理帧数少1到2帧。5.3 长剧集上下文丢失分段生成再合并现象第1集里主角叫张文第2集突然变成林文或者前一集设置的悬疑线到第5集完全没交代。 原因这是因为长剧集拆集生成时每次只给模型当集的输入没有把前面的剧情摘要传给下一集。分段生成是性能上的必要手段但模型上下文是“短时记忆”。 解决在生成第N集之前先用模型把前N-1集的剧情摘要压缩成300字以内的梗概连同“人物设定表”一起作为上下文字段传给下一集。这个做法比直接喂全部历史文本更省钱也更稳定因为历史里的低质文本不会被错误带入。灵果这类平台如果支持“续集模式”一般也是这个原理如果不支持可以自己做一层缓存把人物设定、地点、关键线索存成结构化文件。5.4 显存溢出与模型加载失败现象运行到视频生成阶段时终端打印 CUDA out of memory或者进程直接退出没有报错模型加载时报“size mismatch”或“unexpected key”。 原因显存溢出通常是分辨率或批处理大小设置过高。尺寸不匹配则是因为下载的权重版本和代码里的模型结构不一致最常见的是在 diffusers 架构和原生 checkpoint 之间混用。 解决显存溢出先关掉所有非必要进程再把 config.yaml 里的 resolution 设为 384x512同时打开 offload 选项。如果还溢出就把视频生成拆成两个短片段。模型结构不匹配的解决方式是把权重转换成项目要求的格式一般要在项目仓库里找转换脚本而不是单独下新模型。注意不要同时加载多个大模型到同一块卡上可以通过把 LLM 走 API、只把视频模型放本机的方式错开显存占用。6. 进阶玩法从批量生成到人工审核闭环当你能稳定生成单条成片后下一个瓶颈是效率和品控。我最后的建议是别让全自动化完全闭环要在流水线里留一个“人工审核口”。这个口不是让你去剪视频而是只看三样东西分镜表、首帧图和成片前5秒。分镜表能看出剧情逻辑是否断裂首帧图能看出角色一致性和画风漂移成片前5秒能发现画面崩坏和音画脱节。只要这三项过关整条成片大概率能看。用这个方法我曾在一次短剧批量生成中把返工率从一半降到十分之一。批量生成的高效做法是把“一句话创意”做成Excel表每行是一个剧名和梗概然后用脚本循环调用流水线。这里的关键是设置一个“暂停条件”某个分镜连续失败两次就停止这一集的生成而不是硬跑到底。因为视频生成是概率性的失败越多后续的错误会像滚雪球一样被堆进成片里最后整个片段都不能用。失败的分镜可以单独重跑不要把整条流水线重跑一遍否则时间成本翻倍。我还有一个习惯每次生成完把这次用到的 prompt、种子、模型版本都记录在一个 manifest 文件里连同成片一起归档。听起来像是额外工作但当客户要求“这个风格再出一部”时你就会发现没有元数据的话想复现某种效果几乎全凭运气。这套做法在单条生成时很麻烦但做成短剧矩阵后它就是你能持续复用的“后悔药”。真正做下来我最大的体会是AI短剧生成平台不是让你把导演替换掉而是让你把制片时间缩短。工具的价值在于让创作者有更多试错机会而不是让机器替你决定什么是好故事。希望这套从拆解到调参、从踩坑到验收的路径能帮你在灵果短剧AI这类平台上少走一段弯路。本文还有配套的精品资源点击获取
