从一句话到成片：AI短剧生成平台的搭建与实现解析

简介这是一套面向AI内容创作者、短视频开发者及低代码爱好者的一站式AI短剧生成平台开源实现解决传统短剧制作中剧本撰写、角色建模、分镜设计、配音合成等环节人力成本高、流程割裂的痛点。资源包含94个文件以56个TypeScript前端逻辑文件含8个Vue组件、10个Markdown文档含CLAUDE.md与README说明、6个JSON配置及数据文件、4个PNG资源图为主辅以Dockerfile、docker-compose.yml、config.example.yaml等部署支撑文件整体仅634KB轻量易部署。已有232人学习下载包内提供完整前后端分离架构后端基于LLM解析剧本并提取角色/场景/分镜前端支持角色音色分配、宫格图生成、TTS配音、FFmpeg多轨合成与整集导出所有模块均在源码中可追溯、可调试、可二次开发。 从一句话到成片我如何搭起一个AI短剧生成平台打开仓库里那份源码的时候我心里想的是这个项目真能把“一句话写短剧”这件事跑通吗事实证明它不仅能跑通而且跑得比我想象中顺畅。用户输入一句“两个外卖员在暴雨天同时收到一条神秘订单”系统就能自动输出剧本、拆出角色和场景、生成分镜画面、配上对白旁白最后合成一段能直接播放的短视频。这个流程放在一年前还得靠一个五人小团队忙活两三天现在本地部署一套开源代码就能搞定。这篇博文就围绕这套平台的源码结构、部署流程和实操中踩过的坑展开重点讲讲每个环节的技术选型和实现原理给想自己搭一套或者准备二次开发的朋友一个参考。1. 项目整体设计与流程拆解1.1 一句话到成片平台的工作流拆开这个平台的第一眼我就注意到它整个流程是严格按“剧本创作管线”来组织的。你可以把它理解为一条流水线原料是一句话终点是一部完整的短剧视频。流水线上有五个核心工位剧本编写、角色与场景提取、分镜生成、配音合成、视频拼接。每个工位只做自己的事做完把产物放到约定好的位置下一个工位再取走。这种设计给我的第一感觉是“很工程化”。它不是把一堆AI能力简单堆在一起而是认真设计了数据在工位之间传递的格式。比如剧本生成后会输出一份结构化的JSON里面包含了角色列表、场景列表、对白、旁白、情绪标签等。后面的角色提取模块不直接读原文而是读这份JSON。这意味着每个模块可以独立替换、独立测试。比如你觉得默认的配音音色不好听只需要替换配音模块其他部分完全不用动。另一个值得说的点是这套流程支持“断点续跑”。实际跑的时候如果某个模块挂了比如分镜生成时API超时你不需要从第一步重新开始。已经生成的剧本和角色数据都存在本地修复后直接从分镜模块继续就行。这个设计在调试阶段帮我省了大量时间。1.2 技术栈选型与关键考量整个平台的核心语言是Python这个选择没什么悬念。AI生态里最成熟的库、最完整的文档、最多的示例代码都在Python这边。视频合成阶段用了FFmpeg这是命令行工具Python通过subprocess调用的方式操作它。几个关键模块的技术选型如下模块技术方案备注剧本生成大语言模型API 提示词模板默认OpenAI兼容接口可切换本地模型角色/场景提取大语言模型 结构化输出通过JSON Schema约束输出格式分镜生成Stable Diffusion WebUI API调用img2img接口生成画面配音边缘TTS引擎支持多音色、语速、音量调节视频合成FFmpeg MoviePy拼接图片生成视频叠加音轨为什么要这么选我实际对比过几种方案。剧本生成也可以用LangChain的Agent模式来做但我发现对“写短剧”这个固定任务来说Agent反而容易跑偏。它会在工具之间来回跳生成内容的风格不稳定。直接用提示词模板约束模型反而更可控。分镜生成这里如果追求效率可以用Hugging Face的Diffusers库在本地跑但对显存要求高一张图片要十几秒。走Stable Diffusion WebUI的API方式可以把图片生成任务交给已经跑起来的服务自己不用过多干预。1.3 为什么选择这样的模块化架构这个平台如果把所有功能塞进一个脚本里大概300行就能跑通demo。但真实场景下没人会这么干因为后面维护太痛苦了。模块化的核心价值在于出错时能快速定位替换时不用牵一发动全身。我举个实际例子。第一次跑通整个流程后我发现旁白音量明显偏低。在非模块化架构下我得去视频合成代码里找音轨叠加的逻辑改完还得担心会不会影响背景音乐。但在这个平台上我只需要找到配音模块的配置项把旁白的音量参数从0.8调到1.0重新生成一遍音轨就行其他模块的产物完全复用。此外模块间的数据格式也是经过设计的。角色列表里每个角色有ID、姓名、性格标签、声音特征场景列表里每个场景有ID、地点、氛围描述、建议画面风格。这些字段都是分镜生成模块的输入。如果角色信息不够结构化分镜模块就得自己从文本里推断角色长相那就容易出现同一角色在不同画面里长得不一样的问题。而现在分镜模块拿到的是规范的结构化数据可以严格保证跨画面的角色一致性。2. 核心模块解析与实操要点2.1 剧本生成提示词工程是关键剧本生成是整个流程的起点它的质量直接决定了后续所有环节的上限。平台沉淀了一套专用的短剧提示词模板里面写了角色设定规则、场景切换规则、对白风格、旁白语气甚至规定了每一集的结尾要留钩子。我对比过直接用聊天式提示词的方案效果天差地别。聊天式提示词生成的剧本有两个典型问题一是角色对白没有辨识度两个人说话像同一个人二是场景描述太长太细后面分镜模块没法直接转换成画面。而平台模板里明确要求了“每句对白不超过20字且对白前标注说话角色ID和情绪状态”这样输出的剧本结构非常规整。这里有一个很重要的经验不要把剧本写得“太满”。很多人在提示词里让AI穷尽细节比如把演员走位、镜头运动、道具摆放全都写进去。但这样做的结果是信息过载分镜模块反而不知道重点在哪里。好的做法是只写清楚“发生了什么、谁和谁的关系、情绪如何变化”把“怎么拍”留给分镜模块。2.2 角色与场景提取结构化输出的落地方式角色和场景提取模块本质上做的是信息抽取工作。它的输入是剧本JSON输出是一个更精细的角色清单和场景清单。角色清单里除了剧本中已有的姓名和性格还会补充角色的声线特征和视觉形象描述。场景清单里会标注场景类型是室内还是室外光线氛围是明亮还是昏暗核心道具是什么。这块的技术核心是让LLM输出严格符合预定义Schema的JSON。平台的做法是在请求中加入一个JSON Schema的定义并明确告诉模型“只输出JSON不要任何多余内容”。实测下来当提示词里给出明确的输出示例时模型的收敛性会好很多。我从这个模块里学到的实操技巧是字段设计不要过度嵌套。第一版我把角色信息设计成“基础信息、外形特征、声音特征、性格特征”四层嵌套结果模型偶尔会把外形特征和声音特征写串。后来拍平成单层键值对准确率直接提升了一个档次数据也更好读取。2.3 分镜生成从文本到画面的桥接分镜模块是这套系统里技术难度最高的一环它的任务是把每个镜头的画面描述转成一张真实的图片。平台调的是Stable Diffusion WebUI的API请求参数包括正向提示词、反向提示词、采样步数、画面比例、种子值。正向提示词的构造有技巧。平台不是直接把场景描述丢给模型而是把它翻译成Stable Diffusion更容易理解的语言。比如场景描述是“一个昏暗的便利店窗外下着暴雨”翻译后的提示词可能是“dark convenience store, large windows, heavy rain outside, fluorescent light, cinematic lighting”。这种“先翻译后生成”的方式画面质量明显优于直接塞长句。反向提示词平台预置了一套固定模板包括“低分辨率、模糊、水印、变形的手、多余的肢体”等常见负面标签。这里有一个踩坑记录第一版反向提示词写得太狠导致画面色彩被过度抑制整体发灰。后来我砍掉了一部分不知道从哪里抄来的“美学负面词”画面风格才恢复正常。2.4 配音与视频合成最后两公里的衔接配音模块用的是边缘TTS方案支持多音色、语速、音量调节并且能生成带情绪的对白。平台会给不同角色分配不同音色旁白用另一套音色这样听众能清楚区分谁在说话。视频合成的核心是FFmpeg。整个流程分三步先把每个镜头的图片和对应音频片段按时间轴排列再用交叉淡入淡出处理镜头切换最后把旁白和背景音乐混合到对应的音轨上。中间涉及大量FFmpeg命令平台的源码里把这些命令封装成了几个Python函数参数都做成了配置项。我特别喜欢这个平台的一点是它默认生成的视频是竖屏9:16格式分辨率1080x1920。这是因为短剧的主要消费场景是手机端。如果按默认的横屏16:9生成后期发到短视频平台还得重新裁剪。这个细节说明作者真实考虑过内容投放在哪。3. 环境准备与源码部署3.1 环境要求不只是装个Python那么回事部署这套平台前我建议先确认自己的机器配置。CPU跑通全流程是没问题的但如果想分镜生成环节不等到天荒地老最好有一块NVIDIA显卡显存6GB以上。如果纯粹想测功能CPU模式也能跑只是单张图可能要等三五分钟。软件依赖上核心是Python 3.10以上版本、FFmpeg、Stable Diffusion WebUI。Python版本这个坑我得提一下源码里用了较新的类型注解语法3.9以下版本直接跑不起来。如果你机器的默认Python版本低于3.10可以用conda单开一个环境千万别去动系统自带的Python。3.2 源码结构解读拿到开源仓库后先把目录结构摸清楚。这个平台源码的目录组织比较清晰顶层有核心目录如下目录作用core/核心流程编排负责串联各模块modules/各功能模块按sub_package拆分config/配置文件目录含模型参数、API地址、音色配置output/生成产物输出目录按时间戳建子目录tests/接口测试和模块级测试脚本建议你按“先读config、再读core、最后看modules”的顺序来读源码。配置看完就基本知道系统能做什么核心流程看完知道数据怎么流转模块代码是最后需要深挖的部分。3.3 一步步启动服务部署流程我拆成了下面几个步骤每一步的意图我都会说清楚克隆代码并创建Python虚拟环境。安装requirements.txt里的依赖包。启动Stable Diffusion WebUI服务命令中加上 --api 参数。修改config里的模型API地址和密钥。运行入口脚本触发一次完整的短剧生成。这里我用了一个命令行示例来启动SD WebUIcd stable-diffusion-webui ./webui.sh --api --xformers --listen注意--api这个参数特别关键没有它WebUI只提供网页操作界面外部程序无法通过API调用。另外--xformers是显存优化选项如果你的显卡显存够大可以不加。3.4 配置项说明与常见设置整个平台的配置集中在config目录下的YAML文件中我挑几个核心配置讲一下配置项说明建议值llm.api_base剧本生成接口的地址指向你的LLM服务llm.max_tokens单次生成的最大token数2000sd.sampler分镜采样器DPM 2M Karrassd.steps采样步数20tts.voice_role旁白与角色音色映射按角色ID配置video.fps视频帧率30这些配置项不是摆设。比如sd.steps我是从默认的20往上加到了28发现画质提升不明显但耗时增加了30%以上后来就改回20。video.fps如果设成60视频会更流畅但生成时间翻倍对短剧这种内容来说30帧完全够用。4. 实操过程与核心环节实现4.1 一次完整的短剧生成演示我实际跑了一个案例输入是“共享单车管理员下班后在最后一辆单车的车筐里发现一个日记本”。整个流程分成下述几个阶段。第一阶段剧本生成。系统自动写出了一段三分钟左右的短剧剧本里面包含六组镜头、三个角色、两处场景转换。看了下时间剧本生成用了大概15秒。第二阶段角色与场景提取。系统从剧本JSON中提取出“共享单车管理员、日记本主人通过旁白展示、青年时期的日记本主人”这三个角色以及“单车停放点、管理员的出租屋”两个场景。角色清单里给每个角色分配了音色和形象关键词。第三阶段分镜生成。六个镜头逐张渲染每张图片耗时15秒左右总共一分半钟。第四阶段配音合成。对白和旁白分别用不同音色合成整体用了大概10秒。第五阶段视频合成。FFmpeg拼接全部镜头和音轨输出一个44秒的竖屏MP4文件。整个过程从输入一句话到拿到成片总共约三分钟。4.2 生成质量优化技巧同一套流程不同参数下生成的质量差别很大。我在实测中总结出三个最有效的优化方向第一个是剧本环节的优化。如果生成的剧本对白平淡可以在提示词模板里补充一条要求叫做“每个角色都有自己的口头禅”。就这么一个简单的修改角色的辨识度会立刻提升。第二个是分镜环节的优化。默认情况下同一角色在不同镜头里长得可能不完全一样。平台支持在分镜提示词里注入角色形象关键词比如“black jacket, baseball cap, middle-aged man”。注入后角色跨镜头的一致性会好很多但也不能完全杜绝。想解决得更彻底可以给关键角色生成参考图再用图生图的方式把参考图的特征迁移到新画面里。第三个是配音环节的优化。边缘TTS默认的语速偏快短剧场景下建议把语速调慢10%左右情感表达会更到位。旁白和角色对白之间建议加0.3秒的静音间隔这个小小的停顿能让听感舒服很多。4.3 二次开发建议如果你打算在这个平台上做二次开发我建议从三个方向切入第一个方向是增加批量处理能力。当前源码是按单条短剧来组织的如果要做批量生成可以加一层调度逻辑把多组输入串行或并行执行。第二个方向是增加自定义素材库。目前分镜画面完全是AI生成如果想插入实拍片段、品牌素材或历史视频可以在视频合成模块前加一个素材筛选节点。第三个方向是增加人工审阅环节。AI生成的剧本有时会翻车比如对白里出现角色前后矛盾。一个实用的做法是增加一个“人工修改剧本后重新生成分镜”的接口让剧本可以被二次编辑后再进入流水线而不是从头跑一遍。这三个方向在源码里都有现成的扩展点。前两个改动集中在modules层第三个需要改动core层的流程编排。5. 常见问题与排查技巧实录5.1 部署阶段的坑部署阶段最容易出的问题集中在两个地方Stable Diffusion WebUI连不上和FFmpeg找不到。SD WebUI连不上的典型症状是流程跑到分镜模块直接报连接超时。排查步骤是先手动在浏览器里打开SD WebUI的地址确认服务本身有没有起来再确认启动命令里是否带上了--api参数最后检查配置文件里的地址是否和实际情况一致。比如WebUI默认跑在7860端口配置里写成7861必然连不上。FFmpeg找不到的问题常见于Windows环境。很多人在官方下载了FFmpeg之后没配置系统环境变量Python调用时提示找不到可执行文件。解决办法两个一是把FFmpeg的bin目录加进PATH二是在配置里显式指定FFmpeg完整路径。我推荐第二种因为不同项目用的FFmpeg版本可能不一样显式指定更可靠。5.2 生成质量问题的排查手段如果发现生成的分镜画面“不像短剧”可以参考下面的排查路径现象可能原因解决手段画面和场景描述无关正向提示词权重分配不当降低非核心关键词的权重人物面部扭曲采样步数偏低或模型偏弱步数提高到28或换用写实类模型色彩整体发灰反向提示词过度精简反向提示词角色前后不一致缺少形象特征约束在提示词中注入形象关键词对白与旁白混叠音频时间轴拼接错误检查镜头时长对应关系我最常用也最有效的排查技巧是把出问题的镜头的正向提示词和反向提示词单独拿出来放到SD WebUI的网页界面里手动生成一次。这样可以快速确认是提示词的问题还是流程的问题不需要反复全流程重跑。5.3 性能与稳定性优化整套平台跑下来性能瓶颈主要在分镜生成环节。一次完整短剧生成分镜消耗的时间占总时长的70%以上。我的优化建议有三条第一条调低采样步数。实测步数从28降到18画质肉眼几乎看不出差别但单张图耗时能下降15%到20%。第二条开启SD WebUI的批量队列。如果一次要生成多个镜头可以把多个img2img请求打包发送。第三条调整视频编码参数。FFmpeg编码时可以不追求无损画质推荐用-crf 23配合-preset medium画质几乎无损但压制速度快很多。稳定性方面最容易出问题的是LLM API接口偶发超时。平台源码里其实没有做自动重试自己加一个重试机制会比较稳妥。我建议脚本里对LLM调用做三次重试重试间隔按1秒、3秒、5秒递增。这个改动落地后长时间批量生成时的成功率能提高很多。5.4 显存不足与资源占用问题如果你在低配机器上跑显存不足是最常见的拦路虎。分镜模块默认请求的图片分辨率是512x512显存占用约2GB。如果是6GB显存的卡同时跑SD WebUI和其他模块问题不大但如果你还想再跑一个8GB的大模型做剧本生成显存就非常紧张了。我的建议是在生成高峰期只保留SD WebUI在显存里LLM调用走API接口。这样做模型和平台解耦互不影响资源占用也更可控。6. 这个平台还能做些什么按我的使用体验这个平台不只是“短剧生成器”这么简单。它的流水线设计思路完全可以迁移到其他内容生产场景。比如把剧本模块换成“商品卖点描述模块”角色提取换成“目标用户画像提取”分镜换成“商品场景图生成”配音换成“卖点讲解音频”你就能得到一个AI带货视频生成器。事实上网上热词里的“AI带货视频一键成片”就是这么个玩法。再比如把提示词模板改成“儿童睡前故事”风格场景图换成绘本插画风格你就能生成带旁白的故事视频。这类内容在育儿赛道流量一直很稳定很多人靠它做账号矩阵。我个人觉得这套架构最有价值的部分是它把生成过程的数据流明明白白地理清了。你不需要看懂大模型内部的原理只需要理解输入输出结构就能把模块换成任何你想用的工具。这种“AI流水线”思路比死磕某一个模型的高分更重要。另外提一句源码仓库里还附了一些示例配置和测试脚本。跑通一次后多留几组不同风格的试跑结果方便后续做对比。以后如果换模型或者改参数就能明显看出来差异在哪。7. 踩过几次坑之后的总结最后分享几个我在反复调试中沉淀下来的经验如果你准备上手这套平台应该能少走一些弯路。第一剧本生成不要追求“文采好”。这个系统本质上是内容生产流水线剧本的作用是给后面的模块提供输入。剧本里每一句话最好都能被其他模块有效使用如果写出一堆形容词后面分镜完全不知道怎么渲染。第二分镜模块要大胆调。很多人担心调提示词会把画面弄坏其实完全不用担心多试几次把好的提示词记下来形成自己的模板库。我现在就存了一组“夜景、雨天、情绪化”风格的提示词模板隔三差五就会用到。第三部署环境保持干净。建议所有服务都通过虚拟环境管理别直接把SD WebUI和平台本身的依赖混装在全局环境里。我在测试时曾经因为两者依赖冲突白白折腾了一下午。第四别小看FFmpeg。你如果只是简单拼接图片和音频FFmpeg本身很简单但如果要做花字、特效、转场你需要的功能开始变多。建议至少把滤镜、字幕、音量混合这几个能力过一遍后面做视频质量优化时全用得上。整套平台玩下来我最直观的感受是AI生成内容的门槛已经不在“生成”这一步了而在“编排”这一步。能不能把剧本、画面、声音、视频这些能力串成一条可靠的流水线才是决定产出效率的关键。这套开源平台的价值恰恰就是把编排的思路和工程实现都开源了出来你可以直接站在这个基础上往自己的方向迭代。本文还有配套的精品资源点击获取