★ FEATURED ARTICLE 1. 项目概览为什么短剧创作需要“模块化”短剧创作这两年已经不是新鲜事了但大多数人还停留在“人工写剧本、人工拍摄、人工剪辑”这套传统流程里。直到AI生成视频、AI配音、AI配乐这几个能力陆续成熟才慢慢有人开始尝试把整条生产线交给机器。可问题也来了市面上的AI工具大多是一个个孤岛。写剧本的只管写剧本生成画面的只管生成画面音频那边又是另一套系统。每次要在三个工具之间倒数据格式不兼容、风格不统一、参数调起来特别痛苦。我当时给自己定的目标很明确能不能做出一个开源的、模块化的AI短剧创作源码系统让剧本、音频、视频这几个核心能力可以独立替换、插拔组合也就是说大家拿到这套系统之后既可以直接用内置的默认模块跑完一整条流水线也可以只换掉里面的“剧本生成模块”或者只换上自己训练的音色模型其他模块不动系统照常运转。这个项目最终交付的成果就是一个基于Python的源码项目按照“生产者—处理器—消费者”的管道思路拆成了三层架构。运行起来后你在命令行里输入一个故事梗概它会自动输出剧本文件、分镜描述、配音音频和合成视频整个过程大概几分钟不等取决于你选的模型复杂度和生成时长。对想做内容批量生产、AI短剧实验、或者单纯想研究生成式AI流水线的开发者来说这套系统提供了很直接的参考实现。下文我会把整个系统的设计思路、核心模块实现、踩坑记录和后续可扩展的方向都拆开讲清楚。2. 系统架构可插拔设计的核心逻辑2.1 模块解耦从“一条龙”到“乐高积木”传统的AI视频生成工具通常把剧本、音频、画面这些能力写死在一个程序里。比如某些一体化的视频生成平台剧本模块修改一点音频模块就要跟着改代码画面模块和音频风格的同步更是靠手工对齐。这种设计在上手阶段看起来很省事但一旦你换模型、换音色、换风格就会发现自己被框架绑死了。我在这套开源系统里做的第一个关键决定是把“生成”这件事拆成五个独立的服务组件输入解析器、剧本生成器、分镜解析器、音频合成器、视频合成器。每个组件对外暴露统一接口内部实现互不干扰。调用关系也很简单输入解析器把故事梗概整理成结构化参数剧本生成器拿到参数后输出剧本文本分镜解析器把剧本拆成分镜列表音频合成器根据分镜生成配音视频合成器拿着分镜和配音去渲染画面。这种设计带来的直接好处是你可以随时替换任意一个环节。比如某天你发现了一个更好用的开源剧本模型只需要写一个新的剧本生成器类实现同一个接口然后在配置文件里把默认模块换成它。其他四个组件完全不用动系统就能以新剧本模型重新跑通。提示可插拔设计的前提是每个模块的输入输出必须是标准化的数据结构。我在实现里用JSON作为模块间通信的统一格式。剧本模块的输出永远是包含“分镜序号、画面描述、对白文本、情绪标注”的JSON数组音频模块只要认这个结构就够了完全不关心剧本是哪个模型写的。2.2 配置驱动的模块路由为了让不同水平的用户都能上手我设计了一套基于配置文件的模块注册机制。核心思想很简单系统启动时读取一个YAML配置文件里面写明每个环节用的是哪个模块、需要加载什么模型参数、走本地推理还是调用远程API。配置结构大致长这样pipeline: script: provider: local_llm model: Qwen2.5-7B-Instruct temperature: 0.8 audio: provider: edge_tts voice: zh-CN-XiaoxiaoNeural rate: 10% video: provider: modelscope model: damo/text-to-video-synthesis resolution: 256x256如果不喜欢内置的默认配置你可以把audio那个provider换成任意一个实现了标准接口的模块。系统根本不需要重新编译重启时自动加载新模块即可。这种“配置即代码”的思路让这套系统具备了很高的灵活性也大大降低了二次开发的入门门槛。2.3 接口设计背后的命名约定组件之间的交互我参考了业界常见的Pipeline命名约定每个模块类至少实现generate(input: dict) - dict方法内部模块类还要加一个validate_input方法用于前置校验。这个约定不花哨但解决了一个容易忽略的问题模块在跑长任务之前可以先快速校验自己的输入是否完整。比如音频模块如果发现自己拿到的分镜列表是空的就直接抛异常退出避免白白等待几秒钟之后才发现数据不对。3. 剧本生成模块从故事梗概到结构化分镜3.1 提示词模板的设计思路剧本生成是整个流水线的第一环也是最需要“磨”的一环。我踩过最深的坑是直接用大模型生成小说式文本然后强拆成剧本格式结果剧情线经常对不上。后来我换了一个思路——先让模型生成严格的JSON结构再做格式校验而不是生成自然语言再转换。实现里的提示词模板大致分三段身份设定、任务说明、输出要求。身份设定告诉模型它是短视频编剧任务说明要求它把输入的故事梗概扩展成一个10集短剧的分镜方案每集包含5到8个镜头输出要求明确了JSON的字段名、枚举值范围和情绪标注的写法。为了让模型输出真正稳定我在提示词里还加了“必须用json标记输出不得输出额外解释”的硬约束。实际操作中我发现大模型对中文长文本的格式遵循能力并没有想象中那么强。有个很有效的补救措施是请求参数里加上response_format: {type: json_object}如果你的模型服务支持这个参数输出结构化JSON的成功率能显著提升。3.2 分镜数据的字段约定分镜JSON数组里每个元素包含这些字段scene_index: 分镜序号 location: 场景地点描述 action: 画面动作描述 dialogue: 角色对白 emotion: 情绪状态happy/sad/angry/surprise/neutral camera: 镜头运动static/pan/zoom duration: 预计时长秒这几个字段是经过不少次试错后固定下来的。最早版本里还有光照方向和天气状态的字段但实际跑下来发现视频生成模型根本不消费这些信息留在JSON里只会让提示词模板更臃肿生成稳定性反而下降。后来删掉效果立刻变好。注意字段不是越多越好视频生成模型能识别的信息量有限。分镜描述里真正起作用的其实是action、dialogue、emotion这三个字段其他字段更多是给音频模块和视频合成模块做对齐用的。3.3 长剧集生成策略一次生成还是分集生成刚开始我尝试一次性把十集的分镜JSON全让模型生成结果大多数时候模型在中途就开始重复、剧情逻辑崩坏或者漏掉分镜。后来改成逐集生成每集作为一个独立的生成任务输入里携带上一集的摘要和角色状态列表模型只需要关注当前这一集的内容。这样做还有一个额外好处某一集生成质量差你可以只重新生成这一集不用整片重跑。这在批量创作场景下非常实用。代价是整体生成时间稍微拉长而且需要维护一个“集状态上下文”的文件来记录角色关系、剧情进展和关键道具。4. 音频合成模块配音与情绪对齐的坑4.1 为什么最终选了可替换的TTS方案音频模块的选型在这个项目里经历了几轮反复。最开始尝试用本地训练的TTS模型音色可控但训练成本和推理延迟都比较高对普通用户不友好。后来换成云端TTS服务效果稳定但需要联网。最后我决定不把音频模块绑死在单一实现上而是做成接口加两个内置实现一个本地离线推理版一个云端API版。用户可以根据自己的网络条件和音色需求选择。这就是可插拔设计带来的直接红利——音频方案可以随时切换不用等我把代码改完。4.2 配音与分镜的时序对齐音频模块的输入是分镜列表输出是每个分镜对应的配音音频文件按命名规则排在输出目录里。这里有个很关键的技术点分镜里一个镜头可能包含多句对白直接合成一个音频片段会导致视频剪辑时不好对齐。我的解决方法是音频模块内部先把分镜的对白按句拆分每一句单独请求TTS生成然后用静音填充分隔最后合并成一个分镜音频文件。这样视频合成模块按分镜序号找音频时拿到的就是和画面时长严格对应的完整音频片段。还有个细节值得说说不同TTS服务的输出格式不一样。有的返回MP3有的返回WAV有的返回带时间戳的JSON。我在接口层统一加了一个音频格式化适配器把所有格式都转成44.1kHz、16bit、单声道的WAV文件。别小看这一步少了它后面做视频混流时几乎是必出问题。4.3 背景音乐与BGM生成的可选模块配音是主线背景音乐也不能少。我为这个系统加了一个可选的BGM模块默认使用一个简单的循环音乐生成器根据剧情情绪标注从预设的音乐库里选一首相匹配的曲子截取合适的长度压低音量后混入最终的音频轨道。这个模块默认不启用因为很多人希望在后期剪辑软件里自己做BGM。但当你需要全自动批量生成短剧时这个模块能帮你省掉大量人工配乐的步骤。启用方式就是配置文件里加一行bgm: enabled足够简单。5. 视频合成模块从分镜到成片的实现细节5.1 视频生成模型的选择与适配视频合成是这个系统里最吃资源、也最容易出问题的模块。我适配过几类方案开源本地视频生成模型、图像生成模型加运动后处理、以及在线视频生成API。每种方案各有适用场景。本地视频生成模型的优点是不依赖网络生成的视频完全可控但缺点是显存消耗巨大而且生成速度慢。生成一个5秒的短视频在消费级显卡上可能要等一两分钟。在线API的优点是速度快、画质高缺点是付费、有配额限制不适合大规模批量跑。我在设计时采取的策略是“模型适配器”写一个统一的视频生成接口内部根据配置文件选择具体实现。如果模型生成的视频尺寸不对适配器自动做缩放和裁剪如果模型只支持生成图片适配器就退化为“文生图加画面运动”模式。这样系统的视频生成能力就不会被某一款模型的缺陷卡死。5.2 字幕烧录与画面叠字实现短剧和普通视频的显著区别在于字幕。绝大多数短剧是竖屏播放字幕必须烧在画面上而且要清晰可读。视频合成模块里我加了一个字幕工具根据分镜JSON里的dialogue字段和音频时间戳生成字幕文件再用FFmpeg叠加到最终视频上。这里有一个实用性极强的参数配置字幕字体大小、描边宽度和显示位置。竖屏短剧的字幕通常放在画面下方约1/4处描边用黑色半透明才能保证在各种画面上都看得清。5.3 多分镜拼接与转场逻辑视频合成模块拿到全部分镜的视频片段后需要把它们拼成一个完整的长视频。拼接不是简单首尾相接不然视频会非常生硬。我写了一个简单但有效的转场逻辑根据上一分镜和下一分镜的情绪强度差决定转场类型。情绪强度差大用硬切加白闪情绪强度差小用淡入淡出连续动作场景则用匹配剪辑逻辑直接拼接。这些转场判断规则最初是手工调参试出来的后来发现用情绪强度做阈值判断很稳定就固化成了默认配置。如果你想给项目增加更多转场风格只需要在转场策略类里增加新的规则即可。6. 实操中的常见问题与排查技巧6.1 模型输出的JSON偶尔解析失败这是整个系统里遇到频率最高的问题。即便提示词里写了“必须以JSON输出”模型偶尔还是会输出一段解释文字、或者JSON结尾少一个括号。我的处理方式是双重保险第一层解析前做一次文本清理把模型输出里json标记之外的杂讯剥离掉第二层解析失败时重试重试时把错误的输出片段拼进错误信息再喂给模型让模型自我修正。实测下来重试一次的成功率就已经很高。6.2 音频和画面不同步最初出现这个问题是因为TTS返回的实际音频时长和分镜JSON里预估的duration差异较大。后来我在分镜估算模块里加了一个反馈校正机制音频生成完毕后把实际时长写回分镜JSON视频合成模块根据实际时长生成视频片段而不是用预估时长。改完之后同步问题基本消失。6.3 显存不足导致视频生成崩溃本地视频生成模型对显存极其敏感。我在适配层里加了自动降级机制当视频生成模块检测到显存不足时自动把分辨率从256降到128或者把帧率从30降到15实在不行就退化为“文生图加运镜”。这样系统不会因为资源不足直接崩溃而是以较低质量继续完成任务。6.4 长视频生成超过模型上下文窗口这个过程遇到的次数也不少。当你试图生成一个跨越很多分镜的长视频时有些在线视频API会因输入描述过长而拒掉请求。解决方案是分段提交每个视频片段对应一个分镜分别提交生成最后拼接。宁可多花几次网络请求也不要冒险提交超长描述。7. 可扩展方向与个人心得7.1 引入更强的大语言模型作为剧本引擎这个系统目前内置的剧本模型是一个通用对话模型。后续完全可以替换成专门针对剧本创作微调的开源模型。因为剧本模块的接口已经标准化换模型只需要新增一个provider其他人写好的模型适配代码可以直接复用。7.2 接入更强一致性的视频生成模型视频生成领域迭代很快新模型几乎每隔几个月就会出一个。本系统的可插拔设计很适合跟上这种节奏当新模型发布时只需要为它写一个适配器然后在配置文件里切换整条流水线就能使用最新的视频生成能力而不需要重写其他逻辑。7.3 多角色一致性记忆模块当前版本的角色一致性还是靠分镜描述里的文字信息在画面生成时可能会产生形象漂移。下一步可以做一个角色记忆库模块在剧本生成阶段记录每个角色的外貌特征视频生成时把这些特征作为附加描述一起提交。这个设计同样可以在不改变其他模块的前提下以新模块的形式加入系统。我自己在实际运行这套系统的过程中最大的感触是可插拔设计的价值往往不是第一天就显现出来的而是在你更换第二个、第三个模型的时候才真正体现。第一次换TTS方案时我还在怀疑是不是多此一举等到换视频生成模型才发现只要接口一致替换过程就是改两行配置的事几乎零成本。如果你也计划做一个类似的AI创作工具我非常建议从一开始就把模块边界划清楚哪怕多花一点设计时间都值得。现在这套系统我还在持续维护下一步准备加入角色一致性模块和更丰富的转场策略。如果你也在做AI短剧生成不妨直接拿这套源码系统跑一跑在此基础上改自己的模块会省掉很多从零搭建的弯路。
阅读完成 · 觉得有帮助？
