
简介这是一份开源本地AI短剧与漫剧一站式制作平台的完整源码包面向具备一定开发基础的内容创作者、AI应用爱好者及短剧从业者。平台深度整合多模态AI能力覆盖故事生成、角色设定、分镜设计、语音合成、画面生成到成片输出的完整链路全程数据不出本机从根源上保障创作隐私与知识产权。压缩包共261个文件约17.97MB以tsx/ts前端界面代码、md文档说明、png图像资源为主另有json配置、Docker运维文件等结构清晰便于本地部署、二次开发与学习研究。已有109人学习下载。源码遵循MIT协议配套文档包含快速入门、API说明、模型替换教程及硬件建议同时内置多种题材风格包、虚拟数字人驱动及可视化工作流编排支持自定义模板与多版本迭代适合希望低成本搭建AI短剧制作管线、研究本地化生成流程的开发者。1. 当“导演”成为一条流水线BigBanana AI Director 在解决什么“ai短剧迟早要出片”这句话在创作者圈子里喊了大半年但真正卡住大家的从来不是灵感而是灵感之后那几百条分镜、几十段配音、上百个人物一致性镜头。BigBanana AI Director 是一个工业级一站式的 AI 短剧 / AI 漫剧 / AI 导演平台面向创作者把“灵感→剧本→分镜→画面→配音→剪辑→打包交付”整条链路串成一条可批处理、可断点续跑的流水线最终交付物就是一个带全部素材索引的 zip 工程包。这套东西适合三类人做竖屏短剧的工作室想用漫剧形态做内容但不会动画的 UP 主以及需要批量生成测试样本的 MCN 和出海内容团队。它和那些只能生成单张图、单段视频的“玩具级”工具有本质区别你给它的不是一张提示词而是一份结构化的导演脚本它替你调度生成模型、语音模型和剪辑逻辑。换句话说前面那 30 秒的兴奋谁都能给后面 300 条镜头的稳定产出才是这个平台值钱的地方。2. 先立住故事结构从灵感变成剧本、再从剧本变成分镜数据2.1 灵感怎么进系统一句话 premise 到三幕结构的拆解逻辑在 BigBanana 这类 AI 导演平台里第一步绝不允许创作者直接写长篇剧本。常见做法是你先给出一句话 premise比如“外卖骑手意外获得读心术在都市悬疑案件里一路逆袭”系统用 LLM 把它扩写成符合短剧节奏的三幕结构——通常按 3 分钟一集、每集结尾留钩子的格式来拆。这一步的产物不是自然语言文档而是一份严格的 JSON 剧本纲要。我一般会先用一个 Python 脚本把 premise 发给模型并约束它只输出结构化字段方便后续直接挂到分镜生成器上import json premise 外卖骑手意外获得读心术在都市悬疑案件里一路逆袭 system_prompt 你是一名短剧编剧。请把用户给出的 premise 扩写成一部竖屏短剧第一集的剧本纲要。 严格输出 JSON不要输出任何解释性文字。字段格式如下 { logline: 一句话剧情梗概, acts: [ { act: 1, goal: 本幕目标, conflict: 本幕冲突, hook: 本幕结尾钩子 } ], characters: [ {name: 角色名, role: 主角/反派/配角, trait: 核心性格标签} ] } def expand_premise(premise: str, temperature: float 0.7) - dict: # 实际调用中这里会替换为平台的 LLM 接口 response llm_call(system_prompt, premise, temperaturetemperature) data json.loads(response) # 强制 JSON 解析非法输出直接报错 return data script_meta expand_premise(premise, temperature0.7) print(json.dumps(script_meta, ensure_asciiFalse, indent2))这段代码的逻辑核心是“强制结构化输出”。system_prompt里明确要求模型输出 JSON但模型偶尔会夹带 Markdown 代码块或者多余的“好的以下是……”这类尾巴所以json.loads这一步不可省。temperature参数我一般设 0.7太低大纲会像说明书一样干瘪太高角色设定容易跑偏后面做角色一致性时你会想哭。2.2 分镜数据才是核心资产场次表、镜头表、角色表怎么建模很多新手把分镜理解成“用自然语言描述画面”这在 AI 导演平台里是典型的踩坑写法。BigBanana 这类工业级平台底层跑的是批量生成任务它需要的是结构化的分镜数据场次、镜头、角色引用、运镜方式、对白、配音音色。你必须把“画面描述”和“生成参数”分开前者给模型当 prompt后者控制生成行为。下面这份 JSON 是我常用的分镜数据结构覆盖了短剧和漫剧两条生产线的公共字段{ project_id: short_drama_001, episode: 1, scenes: [ { scene_id: ep01_scene02, location: 都市夜景街头, shots: [ { shot_id: ep01_scene02_shot03, duration_sec: 4.0, camera_move: push_in, character_refs: [lin_qi, suspect_a], prompt: 外卖骑手站在路灯下神色紧张对面穿黑色卫衣的男子低头避开视线, dialogue: { character: lin_qi, text: 你手里那封信是寄给我的吧, emotion: suspicious }, voice_id: vocal_linqi_v2, seed: 1024 } ] } ] }这份 JSON 就是整个项目唯一的真相源后面所有画面生成、配音、剪辑全部从它读参数。注意character_refs里的lin_qi、suspect_a是角色 ID而不是角色描述文本下游生成器会拿着这个 ID 去找角色参考图的嵌入向量这样才能保证“同一个角色换个镜头还是同一张脸”。2.3 漫剧和短剧的分叉点静态帧怎么变成“可动”的漫剧同一个分镜 JSON短剧和漫剧的执行路径在画面生成这步开始分叉。短剧走的是“图生视频”每一段镜头是一段连续的视频漫剧走的是“静态帧 局部动效”生成一张高质量漫画帧然后通过镜头推拉和局部运动头发飘动、眼神微动、衣摆晃动让画面“活”起来。这个差异直接体现在参数上。做漫剧时我会把分镜 JSON 扩展出motion字段控制动效幅度和镜头移动。下面是一段漫剧镜头配置我用 Python 字典维护便于批量套用模板motion_config { shot_id: ep01_scene02_shot03, motion_strength: 0.35, # 0~1越大画面元素运动越明显 camera_move: slow_push, # 缓慢推近制造心理压迫感 animated_elements: [hair, eyes], # 只动头发和眼睛降低破绽概率 loop_frames: 12 # 动效循环帧数越多越顺滑但渲染越慢 }参数里最容易翻车的是motion_strength。漫剧想省钱省时间但动效强度超过 0.5 后背景线条会开始扭曲尤其是大面积纯色区域夜空、墙壁会出现波纹。我一般限制在 0.30.4 之间只让头发和眼睛动画面的漫画质感反而更稳。这里也埋了一个伏笔漫剧的成片率瓶颈不在画质而在动效的“可控性”后面避坑章会专门讲。3. 从分镜到画面角色一致性、运镜与配音参数怎么调3.1 角色一致性不是靠提示词而是靠角色参考图 人脸嵌入AI 短剧项目里最常见的翻车现场就是“主角换了三集脸换了三种”。很多刚上手的人以为把“黑色短发、右眼角有泪痣”写进每一条 prompt 就够了实际生成出来仍然千奇百怪。BigBanana 这类工业级平台的做法是先把每个角色的参考图单独跑一遍生成该角色的人脸嵌入向量后续所有镜头用character_id 嵌入向量 控制权重三个维度锁定长相。角色初始化时我一般会跑一个很短的角色注册脚本给每个角色生成一份可复用的身份配置character_identity { character_id: lin_qi, name: 林奇, base_prompt: 25岁中国男性短发清瘦眼神疲惫但锐利, ref_image_path: assets/refs/lin_qi.png, face_embedding_weight: 0.85, # 越高越像参考图但构图自由度越低 body_embedding_weight: 0.6, # 服装一致性权重漫剧里要调高 seed_range: [1000, 1999] # 固定 seed 区间降低生成随机性 }face_embedding_weight是这里面最玄学的参数。设到 0.9 以上角色脸是稳了但镜头调度稍微大一点人物姿态就变得僵硬像个贴纸设到 0.7 以下姿态自然但脸开始在“像”和“不像”之间横跳。我常用的做法是固定 0.85然后用同一个 seed 把每个角色在不同表情下的参考图先各生一张挑选最顺眼的作为基准后续镜头全部基于这个基准跑。角色初始化这步没有捷径属于必须提前做的脏活不做后面省下的都会加倍还回去。3.2 运镜参数与镜头语言推拉摇移在生成模型里对应什么分镜 JSON 里的camera_move不是给人看的艺术标注而是直接映射到生成模型里的一组控制参数。竖屏短剧最常用的几种运镜在平台里对应这样一套可调参数镜头类型参数名取值范围作用效果适用场景推近push_in0~1画面中心放大情绪强化角色发现关键线索拉远pull_back0~1揭示环境制造孤独感主角站在高楼天台上横移track_left/right0~1平行跟随节奏平稳两人边走边对话手持晃动handheld0~0.3画面幅度抖动追逐戏、紧急事件旋转roll0~15度画面倾斜旋转角色眩晕、反转时刻参数的核心规律是“宁小勿大”。push_in超过 0.7 时画面边缘会出现明显的形变人脸会被拉伸handheld超过 0.2 就让人头晕竖屏小窗更明显。我一般把push_in控制在 0.40.6handheld控制在 0.1然后用“推近 轻微手持”组合伪装出紧张感破绽最少。另外运镜参数和渲染时长直接相关。同一个镜头push_in0.5 的渲染时间大约是 0.3 的 1.5 倍因为模型需要生成更多中间帧来保证运动平滑。预算紧张的项目我会优先砍运镜幅度而不是砍分镜数量。3.3 配音环节TTS 音色绑定、对白节奏与情感标签画面与配音的对齐是 AI 短剧工业化最容易忽视的一环。分类得很清楚画面生成用的是图像模型配音用的是 TTS两条管线各自跑最后在剪辑阶段合并。BigBanana 里的配音参数有三个关键点voice_id音色绑定、emotion_tag情感标签、pause_after句后停顿。下面是我常用的 TTS 参数结构放在分镜 JSON 的dialogue块里{ dialogue: { character: lin_qi, text: 你手里那封信是寄给我的吧, emotion: suspicious, voice_id: vocal_linqi_v2, speed: 1.0, pause_after_sec: 0.3, pitch_variation: 0.1 } }pause_after_sec是这里最容易被忽略的参数。短剧剪辑里“停顿”本身就是一种表演在角色说出关键疑问后停 0.3 秒观众的紧张感完全不一样。但 TTS 模型不会自动生成这种停顿你需要显式配置。还有pitch_variation配合emotion标签做语气起伏通常设 0.1 就已经够用设到 0.2 以上听起来就像故意夹着嗓子说话。配音对不上口型是另一个高频坑。TTS 输出的音频时长和生成的视频时长经常差 0.51.5 秒解决方式不是去修视频而是让 TTS 先跑完把音频实际时长写回分镜 JSON 的dialogue.duration_actual字段剪辑时以音频长度为基准裁剪画面而不是反着来。4. 把这些串成“工业级”流水线批处理、缓存与 zip 交付4.1 为什么单集能过、整季翻车批处理的重试与断点续跑单集 AI 短剧跑通的概率其实不低真正翻车的是整季 20 集、600 个镜头连续生成的时候。任何一个环节挂了比如显存溢出、角色参考图路径失效、TTS 接口超时整条流水线就得重跑这是所有 AI 生成项目最痛的血泪经验。工业级平台和玩具级工具的分水岭就在“批处理能不能断点续跑”。我常用的批处理逻辑是“镜头最小单元 失败重试 结果缓存”。每个镜头生成完立即把产物落盘脚本重启后先扫描哪些镜头已有产物直接跳过。下面是一段简化但能跑的批处理伪代码以本地执行来理解#!/bin/bash PROJECT_DIR/data/projects/short_drama_001 MANIFEST$PROJECT_DIR/scenes/manifest.json OUTPUT_DIR$PROJECT_DIR/output/shots MAX_RETRY3 # 逐镜头执行生成已生成过的镜头直接跳过 python run_pipeline.py \ --manifest $MANIFEST \ --output_dir $OUTPUT_DIR \ --skip_existing \ # 核心参数跳过已有产物的镜头 --max_retry $MAX_RETRY \ --retry_delay 10 # 失败后等 10 秒再重试避免接口限流--skip_existing是这条命令的后悔药它的判断依据是输出目录下是否存在shot_id.mp4和shot_id.json两个文件。如果之前跑挂了脚本重启后会接着跑而不是从头再来。--max_retry 3也很关键AI 生成接口偶发超时是常态直接失败跳过会丢镜头重试 3 次能把成功率从 90% 拉到 99% 以上。注意重试间隔不能太短我踩过 1 秒重试导致接口被限流的坑10 秒是相对安全的间隔。4.2 资源路径是黑匣子项目目录规范与素材引用方式生成项目跑多了你会发现最大的黑匣子不是模型效果而是文件路径。角色参考图在assets/refs/分镜脚本在scenes/manifest.json生成产物散落在output/shots/TTS 音频又在另一个目录——一旦路径写死、或者打包时引用的是本机绝对路径这个项目交到别人手里就是一个解不开的死结。我一般会按下面这个结构组织整个项目且只使用相对路径short_drama_001/ ├── manifest.json # 全项目分镜总表下游一切任务的入口 ├── assets/ │ ├── refs/ # 角色参考图 │ │ ├── lin_qi.png │ │ └── suspect_a.png │ └── audio/ # 备用音效、背景音乐 ├── scenes/ │ ├── ep01_scenes.json │ └── ep02_scenes.json ├── output/ │ ├── shots/ # 每镜头一份视频/动效文件 │ ├── audio/ # TTS 产出的音频和时间戳 │ └── rushes/ # 合并用的粗剪文件 └── logs/ # 批处理运行日志排错专用这条目录规范最大的价值是“可迁移”。整个项目文件夹从一个人的电脑拷到另一台机器只要保持相对路径结构不变manifest.json里的引用就全部有效。这里有一个细节所有生成器读取素材路径时我会在代码里强制做一次路径校验路径中不允许出现C:\或/Users/xxx/这样的绝对路径头宁可启动时报错也不要生成途中才发现引用断了。4.3 交付物打包为什么最终交付是“从灵感到 .zip”前面做了这么多结构化工作最终都要落到一个交付物上。BigBanana 平台的交付风格是“从灵感到 .zip”不仅交付成片而是把分镜 JSON、角色配置、生成产物、字幕文件、时间戳全部打成一个 zip 工程包。这个包的意义在于拿到它的人可以继续做二次剪辑、换配音、改局部镜头而不是抱着一堆视频文件干瞪眼。打包这一步我建议用命令而不是右键压缩因为命令可以写进流水线自动执行cd /data/projects/ zip -r short_drama_001_delivery.zip short_drama_001/ \ -x short_drama_001/logs/* \ -x short_drama_001/tmp/* # 校验 zip 完整性 unzip -t short_drama_001_delivery.zip | tail -5打包命令里的-x参数是排除项我把logs/和tmp/排除了这两个目录对交付没有意义塞进 zip 只会让包变大。unzip -t是必须做的完整性校验血泪教训没有校验就把 zip 发给下游对方反馈解压损坏的时候你都不知道是自己打包的问题还是对方解压工具的问题来回拉扯一次就是半天。另外提醒一句交付 zip 不建议加密。平台使用者里有人喜欢给压缩包设密码但协作时要传递密码本身就多一道人工环节密码丢了更是灾难。我有一次拿到一个加密 zip密码在前任同事的聊天记录里翻了一个小时才找到。工业级项目的交付要的是“开箱即用”不是“解谜游戏”。5. 避坑在本地跑通 AI 短剧流水线最常见的 5 个翻车现场5.1 翻车一分镜 JSON 里出现非法字符生成端直接静默失败现象批处理脚本跑了大半天回头一看日志某个镜头“生成成功”但输出目录里根本没有对应视频文件只有一份空 JSON。生成端没有报错只是静默跳过。原因分镜 JSON 里的 prompt 字段含有 JSON 规范外的控制字符比如不可见换行符\u2028、或者半角引号混入全角引号导致解析错位。平台生成端在反序列化失败时选择了跳过而不是终止。解决在分镜 JSON 写入文件之前用 Python 做一次强制清洗把非法控制字符统一替换成空格并且用json.loads()反序列化校验一遍校验通过才允许落盘。不要相信模型或人工编辑能生成永远合法的 JSON。5.2 翻车二角色一致性“调了等于没调”现象同一角色在不同镜头里脸型、肤色、发型出现漂移尤其是在侧脸和低头角度下“不像”的感受特别明显。原因face_embedding_weight设置得不够高是第一个嫌疑但更常见的是不同镜头用了不同seed。AI 生成模型在同一提示词下seed 变化会导致人物细节大幅变化参考图嵌入只在“同一个 seed 区间”内才稳定。解决在角色身份配置里锁定seed_range所有含该角色的镜头 seed 都从同一段区间取值比如都落在[1000, 1999]。同时把face_embedding_weight提到 0.85 并固定不变。这招能把“跳脸”概率从一半降到十分之一。5.3 翻车三配音对不上口型时间轴一塌糊涂现象生成出来的成片里角色嘴型已经闭上了配音还在说后半句或者画面已经切走台词才开始。粗剪时发现绝大部分镜头都要手动对齐音画。原因TTS 和视频生成并行跑视频按固定时长 4 秒生成但同一句话不同语速的实际时长可能是 3.2 秒或 5.1 秒。两边各跑各的自然对不上。解决把运行顺序改成“先 TTS、后视频”。让 TTS 先生成音频并返回duration_actual实际时长把该时长写回分镜 JSON 的镜头字段视频生成时以这个时长为准。宁可多生成几帧也不要让画面等声音。5.4 翻车四zip 解压后素材大量丢失现象交付的 zip 在本地解压一切正常对方机器上解压后出现一堆空的文件路径镜头视频找不到。原因打包时项目内部引用的是绝对路径有人把/data/projects/short_drama_001/assets/refs/lin_qi.png这个路径原样写进了分镜 JSONzip 解压到别的机器的不同目录后引用自然失效。解决打包前跑一遍脚本扫描manifest.json和所有分镜文件凡是以/开头的绝对路径一律报错。然后把整个项目目录迁移到一个标准目录下再打包保证包内所有引用都是相对路径。这是最值得做的“防呆”工作。5.5 翻车五整季批处理跑到一半显存爆了现象单集生成没任何问题但跑第 3 集某几个镜头时进程直接 OOM显存溢出而且每次爆的位置还不一样。原因批处理过程中生成模型在处理完一个镜头后没有释放显存缓存加上视频生成模型每镜头都要加载中间数据累积到一定程度就爆了。解决在批处理命令里加--per_shot_memory_limit之类的参数让每个镜头处理完后清一次 GPU 缓存同时把单镜头分辨率从 1080P 降到 720P 跑批处理只对最终选定的镜头用 1080P 精修。工业级生成玩的不是“单个镜头多惊艳”而是“一万个镜头里废片率多低”。6. 最后的验证技巧跑全量之前先抽三个镜头验证很多人拿到 BigBanana 这类平台习惯把整季分镜一次性丢进流水线等 8 小时跑完一看角色不像、音画不同步、某个运镜幅度大得离谱这时候想止损已经晚了。我现在养成的习惯是批处理全量生成之前无论如何先抽 3 个关键镜头做“验证集”——开场钩子镜头、中段情绪转折镜头、高潮戏镜头。这三个镜头覆盖了提示词复杂度、角色表情幅度、运镜强度三个最危险变量。验证脚本没什么高深之处我的通用做法是把这三个镜头单独跑一遍然后检查三件事输出文件是否存在且非空、文件时长是否接近分镜 JSON 里写的目标时长、画面里角色的脸和参考图的余弦相似度是否在阈值内。第二步尤其重要因为时长是音画对齐的地基时长不对后面全白搭。这三个镜头全部验证通过再启动全量批处理翻车概率立刻降一半。这个习惯救过我一次有一回做漫剧项目验证时发现角色参考图的路径全部失效因为我在打包整理项目时把assets/refs/目录改过名但分镜 JSON 里还是旧路径。这个问题如果等到整季生成完再发现差不多要重跑三天。从那以后无论多急我都要让这批验证跑完再去睡觉。“先验证后批处理”这句话被我贴在工位上希望它也能帮你在 AI 短剧出片的路上少熬几个夜。本文还有配套的精品资源点击获取