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短剧生成，不妨直接拿这套源码系统跑一跑，在此基础上改自己的模块，会省掉很多从零搭建的弯路。
