AI短剧自动化：从故事到成片的工程流水线

AI短剧自动化最容易被低估的地方，是它本质上不是一个大模型在“生成剧”，而是一条由文本理解、语音合成、视觉素材生成和视频剪辑串联起来的工程流水线。所谓“从故事到成片一键搞定”，在当前可实现方案里往往不是一条提示词就出片，而是先把故事拆成分镜，再逐镜头生成配音与画面，最后通过剪辑工具按统一规则合成为视频。理解这一点，才能真正着手搭建可运行的自动化系统，也才能理解为什么需要大量工程配置、任务状态和中间产物管理。下面从工程落地角度，把短剧自动化拆成可复现的实施路径。

1. AI短剧自动化为什么是一条流水线，而不是一个生成接口

1.1 从故事到成片要经历哪些环节

短剧的“成片”不是一个文件，而是多路信息在同一时间轴上的叠加：画面、配音、字幕、音乐、转场和节奏。自动化要做的是把这些信息分别生产出来，再按照分镜时间轴对齐合成。

一个最小可运行版本的短剧自动化流程可以拆成下面这些工序：

1. 故事文本拆解：把用户输入的短故事，划分成若干个段落或章节。
2. 剧本扩写：给每个段落补充冲突、对话、动作和情绪描写。
3. 分镜设计：把剧本变成镜头列表，每个镜头包含画面描述、旁白或台词、字幕、预计时长。
4. 配音生成：为每个镜头的旁白或台词调用语音合成服务，生成音频文件。
5. 画面素材生成：根据分镜里的画面描述，调用图像生成服务或检索版权素材库，得到每个镜头的底图。
6. 单镜头渲染：把一个镜头的底图和该镜头的配音合成为一段短视频片段。
7. 时间轴拼接：把所有镜头片段按顺序拼接。
8. 字幕与配乐混流：把字幕文件烧录进视频，加上背景音乐，最终输出成片。

注意这些工序的产物类型完全不同：文本模型输出结构化 JSON，语音模块输出音频文件，图像模块输出图片文件，剪辑模块最后输出视频文件。产物类型不同，就决定了它们不能在一个接口调用里全部完成。工程上，短视频自动化更适合被设计成一条多级流水线，而不是单个“生成式接口”。

1.2 为什么不适合用一个“万能模型”一步出片

确实有模型可以直接根据文本生成视频，但在短剧生产场景里，全片直接生成会遇到几个现实问题：

• 文本生成视频的耗时通常很长，一次生成几秒到几十秒的片段尚可，批量生产分集时长很困难。
• 短剧需要对白、配音、字幕和画面精确对齐，直接生成很难控制到帧级。
• 修改某一个镜头的台词或画面时，如果重新生成全片，修改成本会成倍放大。
• 台词从配音演员的角度看，需要先与文本模型分开处理，再交给语音合成模型，最后回填到分镜里。

所以，工程上更稳妥的路线是“各司其职”：文本模型负责结构化内容，语音模型负责音频，图像或素材库负责画面，FFmpeg 负责合成。这也是“自动化”的真实含义：不是让一个模型做所有事情，而是让多个工具在统一调度下协作完成同一件事。

从项目迭代角度看，一个 2.5 版本的短剧自动化系统，重点已经不是单个模型是否可用，而是这些环节之间的依赖关系是否清晰、失败后能否快速恢复、重复运行时能否降低成本。

1.3 自动化系统的核心是任务状态与中间产物

多环节流水线带来一个典型问题：链路中任何一环失败，整条任务都可能失败。如果每次都从故事文本重新执行，不仅浪费时间，还会反复消耗模型接口的调用成本。

解决这个问题的通用做法是引入“中间产物”和“任务状态”。每个环节把结果写入磁盘，并在状态文件里标记该环节是pending、running、done还是failed。下一次运行时，先读状态文件，已经完成的环节直接使用旧产物，只有未完成或失败的环节才重新执行。

中间产物清单至少应该包含这些内容：

story.txt 用户在项目开始时提供的原始故事 scenes.json 文本模型生成的结构化分镜 audio/*.wav 每个镜头的配音文件 assets/*.png 每个场景的画面底图 clips/*.mp4 每个镜头渲染后的视频片段 final/final.mp4 最终拼接输出 final/subtitles.srt 字幕文件 manifest/status.json 任务执行状态

有了这份清单，自动化系统就具备断点续跑的基础。单个镜头配音失败时，只需重跑该镜头，而不是重跑整条故事线。

2. 环境准备：先按这个清单把工具链搭起来

2.1 模块选型与依赖确认

短剧自动化没有固定技术栈，只要能用统一接口把各环节串起来，项目结构就是合理的。下面给出一个常见参考组合：

这种组合的好处是模块之间不依赖同一个 SDK。只要文本服务能返回 JSON、TTS 服务能返回音频文件、图像服务能返回图片文件，就可以用 Python 脚本统一调度。

如果你使用的服务版本或接口格式与下文示例不同，落地时先对照服务方文档调整请求参数。下面示例用于说明流程，不绑定具体厂商或版本。

2.2 Python 环境与基础依赖

建议使用 Python 3.10 或更高版本，并创建独立的虚拟环境。

python -m venv .venv source .venv/bin/activate pip install requests pyyaml

这里没有引入重量级框架，因为短剧自动化的核心是调度编排，不是 Web 服务。requests用于调用各类模型接口，PyYAML用于读取配置文件。

还需要确认 FFmpeg 已安装，并加入系统 PATH：

ffmpeg -version ffprobe -version

ffprobe是 FFmpeg 自带的媒体探测工具，后面获取音频时长、视频时长都会用到。没有安装 FFmpeg 时，请先根据操作系统的包管理方式完成安装。

2.3 项目目录设计

一个适合初版迭代的项目结构如下：

ai_short_drama/ ├── config/ │ └── demo.yaml ├── input/ │ └── story.txt ├── output/ │ ├── manifest/ │ │ └── status.json │ ├── audio/ │ ├── assets/ │ ├── clips/ │ └── final/ ├── pipeline/ │ ├── __init__.py │ ├── llm.py │ ├── tts.py │ ├── image_gen.py │ ├── ffmpeg_utils.py │ └── workflow.py ├── scripts/ │ ├── run_pipeline.py │ └── verify_output.py └── requirements.txt

目录设计的原则是“输入、输出、代码分离”。input只放用户原始故事，output只放自动生成的中间产物，pipeline放业务调度代码，scripts放可执行入口。不要把故事文本硬编码在代码里，也不要让每个模块各自往根目录写文件。

2.4 用一份 YAML 配置管理全局参数

短剧自动化涉及的参数很多，包括模型名称、服务地址、语音角色、画面尺寸、视频分辨率等。建议集中在config/demo.yaml里管理：

project: short_drama_demo work_root: output/demo story_file: input/story.txt llm: endpoint: http://your-llm-service/v1/chat/completions model: your-text-model-name temperature: 0.7 timeout_seconds: 60 tts: endpoint: http://your-tts-service/api/synthesize voice: zh_female_01 speed: 1.0 sample_rate: 44100 image: endpoint: http://your-image-service/api/generate prompt_prefix: cinematic still, vertical short drama width: 832 height: 1248 render: width: 1080 height: 1920 fps: 24 video_codec: libx264 audio_codec: aac

这里的endpoint是占位地址，落地时替换为自己使用的服务地址。配置集中管理的直接收益是：当需要换语音角色或调整画面尺寸时，只改一份 YAML，不需要改动调度代码。

3. 实现最小可运行版本：先把各模块串成一条主流程

3.1 第一步：读取故事，用文本模型输出结构化分镜

这一阶段的目标不是得到一篇优美的剧本，而是得到一个可以由后续模块消费的镜头列表。免费或商业文本模型通常都支持 JSON 输出，建议在系统提示词里强制约束输出格式。

# pipeline/llm.py import json import requests SYSTEM_PROMPT = """你是短剧编剧。请把用户提供的短故事拆成分镜 JSON。 每个镜头必须包含： - scene_id: 镜头序号 - role: 当前镜头说话的角色 - narration: 旁白或台词，作为配音文本 - subtitle: 用于字幕展示的文本 - visual_prompt: 当前镜头的画面描述，供图像生成使用 - estimated_duration: 根据 narration 长度估算的秒数 只输出 JSON，不要输出其他文字。""" def generate_scenes(story_text, config): resp = requests.post( config["llm"]["endpoint"], json={ "model": config["llm"]["model"], "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": story_text}, ], "temperature": config["llm"]["temperature"], "response_format": {"type": "json_object"}, }, timeout=config["llm"]["timeout_seconds"], ) resp.raise_for_status() content = resp.json()["choices"][0]["message"]["content"] return json.loads(content)

响应里一般会包含一个 JSON 对象，例如：

{ "scenes": [ { "scene_id": 1, "role": "旁白", "narration": "凌晨一点，城东便利店门口的路灯闪了两下。", "subtitle": "凌晨一点，城东便利店门口的路灯闪了两下。", "visual_prompt": "深夜便利店外景，路灯闪烁，冷蓝色调，电影质感", "estimated_duration": 5.0 }, { "scene_id": 2, "role": "林晚", "narration": "我说过，不要再来找我了。", "subtitle": "我说过，不要再来找我了。", "visual_prompt": "便利店门口，年轻女人回头，眼神冷漠，暗色背景", "estimated_duration": 4.0 } ] }

这段输出是整个系统后续模块的连接点。如果文本模型返回的不是合法 JSON，要让程序立刻报错并保留原始响应，方便排查，而不是勉强往下执行。

3.2 第二步：对每个分镜生成配音，并用真实音频时长修正镜头时长

分镜里的estimated_duration是估算值，不能作为最终渲染依据。真正决定镜头长度的是音频的实际时长。因此，每个镜头都先调用 TTS 生成配音文件，再用ffprobe探取真实时长，回写到分镜列表。

# pipeline/tts.py import subprocess import requests import json import pathlib def synthesize_all(scenes, config): audio_dir = pathlib.Path(config["work_root"]) / "audio" audio_dir.mkdir(parents=True, exist_ok=True) for scene in scenes: scene_id = scene["scene_id"] out_path = audio_dir / f"scene_{scene_id:03d}.wav" resp = requests.post( config["tts"]["endpoint"], json={ "text": scene["narration"], "voice": config["tts"]["voice"], "speed": config["tts"]["speed"], "format": "wav", }, ) resp.raise_for_status() out_path.write_bytes(resp.content) duration = probe_media_duration(out_path) scene["audio_path"] = str(out_path) scene["actual_duration"] = duration return scenes def probe_media_duration(path): result = subprocess.run( [ "ffprobe", "-v", "error", "-show_entries", "format=duration", "-of", "json", str(path) ], capture_output=True, text=True, check=True, ) data = json.loads(result.stdout) return float(data["format"]["duration"])

注意，不能用旁白文字字数除以某个固定语速来推算时间。即使是同一段文字，不同音色、不同语速、不同标点停顿都会导致时长差异。以音频真实时长为准，是避免画面与声音不同步的第一步。

3.3 第三步：生成或检索画面素材，并加入缓存判断

图像生成通常比文本和语音耗时更长，成本也更高，因此必须做缓存。一个最简单的缓存策略是：把visual_prompt、图像尺寸、图像模型名称拼接后取哈希，作为文件名。

# pipeline/image_gen.py import hashlib import pathlib import requests def generate_image(scene, config): visual_prompt = scene["visual_prompt"] prefix = config["image"].get("prompt_prefix", "") prompt_text = f"{prefix}, {visual_prompt}" cache_key = hashlib.md5( f"{prompt_text}|{config['image']['width']}|{config['image']['height']}".encode() ).hexdigest() asset_dir = pathlib.Path(config["work_root"]) / "assets" asset_dir.mkdir(parents=True, exist_ok=True) out_path = asset_dir / f"scene_{scene['scene_id']:03d}_{cache_key}.png" if out_path.exists(): scene["asset_path"] = str(out_path) return scene resp = requests.post( config["image"]["endpoint"], json={ "prompt": prompt_text, "width": config["image"]["width"], "height": config["image"]["height"], }, ) resp.raise_for_status() out_path.write_bytes(resp.content) scene["asset_path"] = str(out_path) return scene

这里的关键点在于：缓存 key 必须包含会影响图片内容的所有因素。比如换了图像风格、改了尺寸、改了模型名称，都应当生成不同的 key。如果把缓存 key 简单地写成scene_id，那么同一个镜头即使画面描述已经变化，也只能拿到旧图。

3.4 第四步：用 FFmpeg 渲染单个镜头片段

每个镜头拿到一张底图和一个配音文件后，就可以渲染成一个小视频片段。逐镜头渲染而不是一次性拼接，是为了避免单个镜头生成失败时全片重来。

# pipeline/ffmpeg_utils.py import subprocess import pathlib def render_single_clip(scene, render_cfg): clips_dir = pathlib.Path(render_cfg["work_root"]) / "clips" clips_dir.mkdir(parents=True, exist_ok=True) out_path = clips_dir / f"scene_{scene['scene_id']:03d}.mp4" cmd = [ "ffmpeg", "-y", "-loop", "1", "-i", scene["asset_path"], "-i", scene["audio_path"], "-vf", ( f"scale={render_cfg['width']}:{render_cfg['height']}," f"fps={render_cfg['fps']}," "format=yuv420p" ), "-c:v", render_cfg["video_codec"], "-tune", "stillimage", "-c:a", render_cfg["audio_codec"], "-shortest", str(out_path), ] subprocess.run(cmd, check=True) scene["clip_path"] = str(out_path) return scene

命令里的几个参数需要解释：

• -loop 1：让静态图片循环成为视频流。
• -shortest：视频流或音频流哪个先结束，输出就停在哪里，确保片段不会出现没有声音的黑场。
• -tune stillimage：针对静态图片场景优化编码。
• format=yuv420p：保证输出视频在常见播放器里可以正常播放。

3.5 第五步：拼接视频、生成字幕、混合背景音乐

所有镜头渲染完成后，先生成一个拼接清单，再用 FFmpeg 的 concat demuxer 拼接。

# output/demo/concat_list.txt file 'clips/scene_001.mp4' file 'clips/scene_002.mp4'

然后执行拼接。如果中间文件的编码参数完全一致，通常可以使用直接复制流的方式提速；如果每个片段来自不同编码参数，则需要重新编码。

ffmpeg -y -f concat -safe 0 -i output/demo/concat_list.txt \ -c copy output/demo/concat.mp4

字幕文件需要从分镜列表生成。推荐使用 SRT 格式，内容按音频真实时长累积：

def write_srt(scenes, srt_path): lines = [] cursor = 0.0 for scene in scenes: start = cursor end = cursor + scene["actual_duration"] lines.append(f"{scene['scene_id']}") lines.append(f"{format_srt_time(start)} --> {format_srt_time(end)}") lines.append(scene["subtitle"]) lines.append("") cursor = end pathlib.Path(srt_path).write_text("\n".join(lines), encoding="utf-8")

最后把字幕烧录进视频，并混合背景音乐：

ffmpeg -y -i output/demo/concat.mp4 -i output/demo/bgm.mp3 \ -vf "subtitles=output/demo/subtitles.srt:force_style='FontName=Noto Sans CJK SC,FontSize=14'" \ -filter_complex "[0:a]volume=1.0[voice];[1:a]volume=0.15[music];[voice][music]amix=inputs=2:duration=first[aout]" \ -map 0:v -map "[aout]" -c:v libx264 -c:a aac output/demo/final/final.mp4

这里背景音乐音量设为原音量的 15% 左右，避免盖过配音。具体音量要根据实际素材调整，生产环境建议单独试听。

3.6 主流程与断点恢复

把上面的模块串成一个主流程，同时维护每个镜头的完成状态。

# pipeline/workflow.py import json import pathlib def load_status(manifest_path): if pathlib.Path(manifest_path).exists(): return json.loads(pathlib.Path(manifest_path).read_text(encoding="utf-8")) return {"scenes": [], "done_stages": []} def save_status(status, manifest_path): pathlib.Path(manifest_path).parent.mkdir(parents=True, exist_ok=True) pathlib.Path(manifest_path).write_text( json.dumps(status, ensure_ascii=False, indent=2), encoding="utf-8", )

主流程在执行每个阶段前检查对应产物，已经存在的直接跳过。这样即使某个第三方服务超时，程序中断后也可以从断点继续执行，而不是无止境地重复调用模型接口。

4. 关键设计细节：数据结构、参数和缓存策略

4.1 分镜 JSON 是模块之间的契约

短剧自动化系统里，剧本、画面、音频、剪辑四个模块共享同一个分镜结构。如果这个结构不统一，后续每个环节都会出现“字段对不上”的问题。

一个可直接使用的分镜字段设计如下：

约定好这份结构之后，各模块的输入输出都会非常清楚。llm.py负责生成原始 JSON，tts.py负责补充audio_path和actual_duration，image_gen.py负责补充asset_path，ffmpeg_utils.py负责补充clip_path。

4.2 参数速查：哪些参数直接影响成片质量

这些参数中，最容易被忽略的是图像比例与视频比例不一致。比如底图生成的是 1:1 方形图，渲染时强行拉伸成 9:16 竖屏，画面上的人物会被压扁。实际项目里，要么让图像服务输出与目标视频同比例，要么在 FFmpeg 的scale之后补上crop或pad逻辑。

4.3 缓存设计不仅要省钱，还要避免脏数据

缓存的价值不只是减少成本，更是让开发调试变得可控。如果每次运行同一段故事都会调用文本模型，相同的分镜可能生成不同结果，你很难判断后续修改是哪个环节引起的。

缓存策略可以按阶段拆分：

1. 文本模型产物按故事文本的内容哈希缓存。
2. TTS 产物按文本内容、音色、语速联合哈希缓存。
3. 图像产物按提示词、尺寸、风格参数联合哈希缓存。
4. 单镜头视频按底图路径、音频路径、渲染参数联合哈希缓存。

每个阶段的缓存都要依赖“上级产物的路径”，而不是依赖内存里的对象。比如单镜头视频的缓存 key 可以取asset_path + audio_path + 分辨率 + fps的哈希。只要上游文件发生变化，哈希就会变化，旧视频不会被误用。

注意：不要把“当前系统时间”或“随机数”写进缓存 key 里。否则缓存永远命中不了，每次运行都会重新调用昂贵的外部服务。

4.4 异常处理与重试策略

第三方模型服务不稳定是常态。短剧自动化流程里，音频和图像请求失败后，直接让整条流水线退出，会让可用性非常差。更合理的做法是对每个外部调用做“有限重试 + 指数退避”。

import time import requests def request_with_retry(func, max_retries=3): for attempt in range(max_retries): try: return func() except (requests.ConnectionError, requests.Timeout) as exc: if attempt == max_retries - 1: raise time.sleep(2 ** attempt) return None

这里只对“网络错误”和“超时”做重试。对“参数错误”或“审核拒绝”这类业务错误不要重试，因为重试多少次结果都一样，只会浪费时间和成本。

5. 运行验证：不能只看有没有 final.mp4

5.1 运行主流程

把故事写入input/story.txt后，执行入口脚本：

python scripts/run_pipeline.py --config config/demo.yaml

正常的执行路径会依次生成音频、图片、单镜头片段、拼接视频、字幕文件。如果所有模块拆得足够干净，执行日志应该能直观看到每个镜头的处理状态。

完成后的目录结构大致是：

output/demo/ ├── audio/ │ ├── scene_001.wav │ └── scene_002.wav ├── assets/ │ ├── scene_001_xxx.png │ └── scene_002_xxx.png ├── clips/ │ ├── scene_001.mp4 │ └── scene_002.mp4 ├── concat_list.txt ├── concatenated.mp4 ├── subtitles.srt └── final/ └── final.mp4

5.2 用 ffprobe 检查音画时长

final.mp4 生成后，至少要检查这几个指标：

# 视频总时长 ffprobe -v error -show_entries format=duration \ -of csv=p=0 output/demo/final/final.mp4 # 是否包含音频流 ffprobe -v error -show_entries stream=codec_type \ -of csv=p=0 output/demo/final/final.mp4

预期输出里，第一个命令返回类似18.432000的时长，第二个命令应该同时出现video和audio。如果只有video，说明音频没有进入最终文件，需要检查-map参数。

5.3 用脚本验证分镜与视频是否对齐

可以写一个简单的校验脚本，逐行读取 SRT 字幕文件的最后一个时间轴结束时间，与视频实际时长做比较。

python scripts/verify_output.py --video output/demo/final/final.mp4 --srt output/demo/subtitles.srt

校验逻辑可以用下面这段简化代码表示：

import subprocess import re import pathlib def get_duration(path): result = subprocess.run( ["ffprobe", "-v", "error", "-show_entries", "format=duration", "-of", "csv=p=0", str(path)], capture_output=True, text=True, check=True, ) return float(result.stdout.strip()) def srt_end_time(srt_path): text = pathlib.Path(srt_path).read_text(encoding="utf-8") times = re.findall(r"(\d{2}:\d{2}:\d{2},\d{3}) -->", text) last = times[-1] h, m, s = last.split(":") return int(h) * 3600 + int(m) * 60 + float(s.replace(",", "."))

如果字幕最后结束时间与视频总时长误差超过 0.5 秒，基本可以判断音频对齐或拼接环节出了问题。短剧对白密集，这类问题必须在上线前解决。

5.4 人工抽审不能省

自动化可以解决“能不能生成”，但解决不了“生成得好不好”。训练好的文本模型偶尔会把角色名写错，TTS 可能在某些词上发音不自然，图像模型可能生成畸形手指，这些都需要人工抽帧检查。生产环境中即使无法逐镜头人工审核，也至少要通看一遍成片，再进入分发环节。

6. 常见问题排查：从现象定位到具体模块

6.1 高频问题的现象与处理方向

6.2 声音与画面不同步的完整排查链路

这是短剧自动化中最高频的问题之一，排查顺序建议从时间来源查起。

第一，检查分镜里的actual_duration是否已经是音频的真实时长。可以在中间产物 JSON 里搜索audio_path，用ffprobe手动探取该音频文件时长，与 JSON 里的actual_duration对比。如果两个值不一致，说明 TTS 阶段没有正确回填时长。

第二，检查单镜头片段时间是否等于音频时长。使用ffprobe查看clips/scene_001.mp4的时长。如果片段时长不等于音频时长，可能是渲染命令里的-shortest逻辑没生效，或视频流参数导致时间基准错误。

第三，检查拼接后的整体时长。所有镜头片段相加后，理论上应等于最终视频时长。如果concat.mp4比各片段之和短，通常是 concat 清单里的文件路径写错或存在被覆盖的旧文件。

第四，检查字幕起始时间是否正确。字幕生成脚本通常使用actual_duration累积游标。如果字幕时间轴没有按音频实际时长累积，听到的声音还没结束，字幕就已经切到下一句。

6.3 FFmpeg 拼接报错“height not divisible by 2”

这个错误很常见。H.264 编码要求视频宽高必须是偶数，如果某个画面素材的分辨率是奇数，比如 833x1248，就会触发该错误。

检查方式是读取视频或图片的真实尺寸：

ffprobe -v error -select_streams v:0 \\ -show_entries stream=width,height -of csv=p=0 输入文件

解决方式是统一尺寸，更好的写法是在-vf里使用能保证像素对齐的表达式：

-vf "scale=1080:1920,crop=trunc(iw/2)*2:trunc(ih/2)*2,format=yuv420p"

实际项目中，直接在配置层把图片尺寸和视频分辨率都设计成偶数，可以从源头避免该问题。

6.4 通用排查顺序

当整条流水线失败时，按下面的顺序排查最有效：

1. 输入故事文本是否有内容，编码是否为 UTF-8。
2. 路径配置是否正确，work_root目录是否可写。
3. 文本模型是否返回了合法 JSON，是否出现幻觉字段。
4. TTS 文件是否生成成功，音频时长是否正常。
5. 图像文件是否存在，尺寸是否符合预期。
6. FFmpeg 命令是否在单镜头阶段报错。
7. 拼接清单中的相对路径是否与当前工作目录匹配。
8. 最终文件的音视频流和时间轴是否对齐。

这个顺序遵循“先检查输入，再检查中间产物，最后检查输出”的原则。大部分在“第 1 步到第 4 步”出现的问题，最终都会表现为成片异常，需要逐层往下看，不能只盯着 final.mp4 检查。

7. 从自动化的 Demo 到可生产落地：还要补齐这些事

7.1 学习环境与生产环境的差异

本地跑通一条短剧流水线和真正对外提供服务之间，还有不少距离。下面列出主要差异：

本地 JSON 作为状态文件在单机脚本里足够，但如果未来要支持多任务并行或多人协作，建议改用数据库表记录每个分镜的执行状态。