AI短剧自动化最容易被低估的地方是它本质上不是一个大模型在“生成剧”而是一条由文本理解、语音合成、视觉素材生成和视频剪辑串联起来的工程流水线。所谓“从故事到成片一键搞定”在当前可实现方案里往往不是一条提示词就出片而是先把故事拆成分镜再逐镜头生成配音与画面最后通过剪辑工具按统一规则合成为视频。理解这一点才能真正着手搭建可运行的自动化系统也才能理解为什么需要大量工程配置、任务状态和中间产物管理。下面从工程落地角度把短剧自动化拆成可复现的实施路径。1. AI短剧自动化为什么是一条流水线而不是一个生成接口1.1 从故事到成片要经历哪些环节短剧的“成片”不是一个文件而是多路信息在同一时间轴上的叠加画面、配音、字幕、音乐、转场和节奏。自动化要做的是把这些信息分别生产出来再按照分镜时间轴对齐合成。一个最小可运行版本的短剧自动化流程可以拆成下面这些工序故事文本拆解把用户输入的短故事划分成若干个段落或章节。剧本扩写给每个段落补充冲突、对话、动作和情绪描写。分镜设计把剧本变成镜头列表每个镜头包含画面描述、旁白或台词、字幕、预计时长。配音生成为每个镜头的旁白或台词调用语音合成服务生成音频文件。画面素材生成根据分镜里的画面描述调用图像生成服务或检索版权素材库得到每个镜头的底图。单镜头渲染把一个镜头的底图和该镜头的配音合成为一段短视频片段。时间轴拼接把所有镜头片段按顺序拼接。字幕与配乐混流把字幕文件烧录进视频加上背景音乐最终输出成片。注意这些工序的产物类型完全不同文本模型输出结构化 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 模块选型与依赖确认短剧自动化没有固定技术栈只要能用统一接口把各环节串起来项目结构就是合理的。下面给出一个常见参考组合职能模块常见形态负责内容文本生成OpenAI 兼容接口或本地模型服务故事拆解、剧本扩写、分镜 JSON 生成语音合成TTS 服务或本地 TTS 模型旁白、台词、角色配音画面素材文生图服务或版权素材库镜头底图、封面图视频合成FFmpeg 命令行单镜头渲染、拼接、字幕烧录、音频混合这种组合的好处是模块之间不依赖同一个 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 已安装并加入系统 PATHffmpeg -version ffprobe -versionffprobe是 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}, }, timeoutconfig[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(parentsTrue, exist_okTrue) for scene in scenes: scene_id scene[scene_id] out_path audio_dir / fscene_{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, formatduration, -of, json, str(path) ], capture_outputTrue, textTrue, checkTrue, ) 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(parentsTrue, exist_okTrue) out_path asset_dir / fscene_{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(parentsTrue, exist_okTrue) out_path clips_dir / fscene_{scene[scene_id]:03d}.mp4 cmd [ ffmpeg, -y, -loop, 1, -i, scene[asset_path], -i, scene[audio_path], -vf, ( fscale{render_cfg[width]}:{render_cfg[height]}, ffps{render_cfg[fps]}, formatyuv420p ), -c:v, render_cfg[video_codec], -tune, stillimage, -c:a, render_cfg[audio_codec], -shortest, str(out_path), ] subprocess.run(cmd, checkTrue) scene[clip_path] str(out_path) return scene命令里的几个参数需要解释-loop 1让静态图片循环成为视频流。-shortest视频流或音频流哪个先结束输出就停在哪里确保片段不会出现没有声音的黑场。-tune stillimage针对静态图片场景优化编码。formatyuv420p保证输出视频在常见播放器里可以正常播放。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), encodingutf-8)最后把字幕烧录进视频并混合背景音乐ffmpeg -y -i output/demo/concat.mp4 -i output/demo/bgm.mp3 \ -vf subtitlesoutput/demo/subtitles.srt:force_styleFontNameNoto Sans CJK SC,FontSize14 \ -filter_complex [0:a]volume1.0[voice];[1:a]volume0.15[music];[voice][music]amixinputs2:durationfirst[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(encodingutf-8)) return {scenes: [], done_stages: []} def save_status(status, manifest_path): pathlib.Path(manifest_path).parent.mkdir(parentsTrue, exist_okTrue) pathlib.Path(manifest_path).write_text( json.dumps(status, ensure_asciiFalse, indent2), encodingutf-8, )主流程在执行每个阶段前检查对应产物已经存在的直接跳过。这样即使某个第三方服务超时程序中断后也可以从断点继续执行而不是无止境地重复调用模型接口。4. 关键设计细节数据结构、参数和缓存策略4.1 分镜 JSON 是模块之间的契约短剧自动化系统里剧本、画面、音频、剪辑四个模块共享同一个分镜结构。如果这个结构不统一后续每个环节都会出现“字段对不上”的问题。一个可直接使用的分镜字段设计如下字段类型说明scene_idint镜头序号主键rolestring说话角色或“旁白”narrationstring配音用文本决定音频内容subtitlestring字幕显示文本visual_promptstring图像生成提示词estimated_durationfloat文本模型估算时长audio_pathstringTTS 生成的音频文件路径actual_durationfloatffprobe 探取的真实音频时长asset_pathstring生成或检索到的画面底图路径clip_pathstring单镜头渲染后的视频文件路径约定好这份结构之后各模块的输入输出都会非常清楚。llm.py负责生成原始 JSONtts.py负责补充audio_path和actual_durationimage_gen.py负责补充asset_pathffmpeg_utils.py负责补充clip_path。4.2 参数速查哪些参数直接影响成片质量参数常见值调大影响调小影响使用建议temperature0.7文本更发散分镜容易偏离故事更稳定但可能缺乏变化拆解阶段建议 0.5 到 0.7tts.speed1.0语速快单位时间承载更多台词语速慢镜头变长先按默认试听后再调render.fps24文件更大动作更流畅文件小但画面卡顿静态图主导的短剧 24 足够render.width/height1080x1920清晰度更高渲染变慢体积小清晰度不足竖屏常用 1080x1920image.width/height832x1248画面细节更丰富细节丢失最好与渲染比例保持一致背景音乐音量0.15音乐盖过配音气氛不足以能听清对白为准这些参数中最容易被忽略的是图像比例与视频比例不一致。比如底图生成的是 1:1 方形图渲染时强行拉伸成 9:16 竖屏画面上的人物会被压扁。实际项目里要么让图像服务输出与目标视频同比例要么在 FFmpeg 的scale之后补上crop或pad逻辑。4.3 缓存设计不仅要省钱还要避免脏数据缓存的价值不只是减少成本更是让开发调试变得可控。如果每次运行同一段故事都会调用文本模型相同的分镜可能生成不同结果你很难判断后续修改是哪个环节引起的。缓存策略可以按阶段拆分文本模型产物按故事文本的内容哈希缓存。TTS 产物按文本内容、音色、语速联合哈希缓存。图像产物按提示词、尺寸、风格参数联合哈希缓存。单镜头视频按底图路径、音频路径、渲染参数联合哈希缓存。每个阶段的缓存都要依赖“上级产物的路径”而不是依赖内存里的对象。比如单镜头视频的缓存 key 可以取asset_path audio_path 分辨率 fps的哈希。只要上游文件发生变化哈希就会变化旧视频不会被误用。注意不要把“当前系统时间”或“随机数”写进缓存 key 里。否则缓存永远命中不了每次运行都会重新调用昂贵的外部服务。4.4 异常处理与重试策略第三方模型服务不稳定是常态。短剧自动化流程里音频和图像请求失败后直接让整条流水线退出会让可用性非常差。更合理的做法是对每个外部调用做“有限重试 指数退避”。import time import requests def request_with_retry(func, max_retries3): 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.mp45.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.mp45.2 用 ffprobe 检查音画时长final.mp4 生成后至少要检查这几个指标# 视频总时长 ffprobe -v error -show_entries formatduration \ -of csvp0 output/demo/final/final.mp4 # 是否包含音频流 ffprobe -v error -show_entries streamcodec_type \ -of csvp0 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, formatduration, -of, csvp0, str(path)], capture_outputTrue, textTrue, checkTrue, ) return float(result.stdout.strip()) def srt_end_time(srt_path): text pathlib.Path(srt_path).read_text(encodingutf-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 高频问题的现象与处理方向问题现象可能原因检查方式处理建议成片只有画面没有声音混流时没有正确映射音频流ffprobe -show_entries streamcodec_type检查-map [aout]是否生效画面与配音不同步用了估算时长而不是音频真实时长对比音频时长和单镜头片段时长用ffprobe回填actual_duration图片在竖屏视频里被压扁图像比例不是 9:16查看底图实际宽高先scale再crop或pad单镜头拼接后黑屏每个片段没有统一使用yuv420p检查每个片段的编码器参数统一渲染参数必要时重新转码字幕是乱码SRT 编码不是 UTF-8 或缺少中文字体打开字幕文件检查编码使用 UTF-8 编码并设置中文字体重复运行费用暴涨缓存 key 设计不合理查看缓存目录是否生成了大量重复文件检查缓存 key 是否包含时间戳或随机值TTS 请求偶发失败第三方服务超时查看错误类型是连接超时还是业务错误对网络错误做指数退避重试对业务错误直接失败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 streamwidth,height -of csvp0 输入文件解决方式是统一尺寸更好的写法是在-vf里使用能保证像素对齐的表达式-vf scale1080:1920,croptrunc(iw/2)*2:trunc(ih/2)*2,formatyuv420p实际项目中直接在配置层把图片尺寸和视频分辨率都设计成偶数可以从源头避免该问题。6.4 通用排查顺序当整条流水线失败时按下面的顺序排查最有效输入故事文本是否有内容编码是否为 UTF-8。路径配置是否正确work_root目录是否可写。文本模型是否返回了合法 JSON是否出现幻觉字段。TTS 文件是否生成成功音频时长是否正常。图像文件是否存在尺寸是否符合预期。FFmpeg 命令是否在单镜头阶段报错。拼接清单中的相对路径是否与当前工作目录匹配。最终文件的音视频流和时间轴是否对齐。这个顺序遵循“先检查输入再检查中间产物最后检查输出”的原则。大部分在“第 1 步到第 4 步”出现的问题最终都会表现为成片异常需要逐层往下看不能只盯着 final.mp4 检查。7. 从自动化的 Demo 到可生产落地还要补齐这些事7.1 学习环境与生产环境的差异本地跑通一条短剧流水线和真正对外提供服务之间还有不少距离。下面列出主要差异维度学习环境生产环境第三方服务手动重试失败后人工干预需要独立任务队列、告警、自动补偿状态存储JSON 文件或内存状态数据库或对象存储 状态机成本控制不太关注费用需要预算上限、调用次数统计、配额告警权限隔离本地脚本直接执行需要环境变量、密钥管理、权限控制日志打印到控制台结构化日志、调用链追踪、监控大盘内容合规只需要本地可看需要接入内容审核人工抽审不可省略回滚重新跑一遍即可需要历史版本归档、产物版本对比本地 JSON 作为状态文件在单机脚本里足够但如果未来要支持多任务并行或多人协作建议改用数据库表记录每个分镜的执行状态。 AI短剧自动化：从故事到成片的工程流水线
AI短剧自动化最容易被低估的地方是它本质上不是一个大模型在“生成剧”而是一条由文本理解、语音合成、视觉素材生成和视频剪辑串联起来的工程流水线。所谓“从故事到成片一键搞定”在当前可实现方案里往往不是一条提示词就出片而是先把故事拆成分镜再逐镜头生成配音与画面最后通过剪辑工具按统一规则合成为视频。理解这一点才能真正着手搭建可运行的自动化系统也才能理解为什么需要大量工程配置、任务状态和中间产物管理。下面从工程落地角度把短剧自动化拆成可复现的实施路径。1. AI短剧自动化为什么是一条流水线而不是一个生成接口1.1 从故事到成片要经历哪些环节短剧的“成片”不是一个文件而是多路信息在同一时间轴上的叠加画面、配音、字幕、音乐、转场和节奏。自动化要做的是把这些信息分别生产出来再按照分镜时间轴对齐合成。一个最小可运行版本的短剧自动化流程可以拆成下面这些工序故事文本拆解把用户输入的短故事划分成若干个段落或章节。剧本扩写给每个段落补充冲突、对话、动作和情绪描写。分镜设计把剧本变成镜头列表每个镜头包含画面描述、旁白或台词、字幕、预计时长。配音生成为每个镜头的旁白或台词调用语音合成服务生成音频文件。画面素材生成根据分镜里的画面描述调用图像生成服务或检索版权素材库得到每个镜头的底图。单镜头渲染把一个镜头的底图和该镜头的配音合成为一段短视频片段。时间轴拼接把所有镜头片段按顺序拼接。字幕与配乐混流把字幕文件烧录进视频加上背景音乐最终输出成片。注意这些工序的产物类型完全不同文本模型输出结构化 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 模块选型与依赖确认短剧自动化没有固定技术栈只要能用统一接口把各环节串起来项目结构就是合理的。下面给出一个常见参考组合职能模块常见形态负责内容文本生成OpenAI 兼容接口或本地模型服务故事拆解、剧本扩写、分镜 JSON 生成语音合成TTS 服务或本地 TTS 模型旁白、台词、角色配音画面素材文生图服务或版权素材库镜头底图、封面图视频合成FFmpeg 命令行单镜头渲染、拼接、字幕烧录、音频混合这种组合的好处是模块之间不依赖同一个 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 已安装并加入系统 PATHffmpeg -version ffprobe -versionffprobe是 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}, }, timeoutconfig[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(parentsTrue, exist_okTrue) for scene in scenes: scene_id scene[scene_id] out_path audio_dir / fscene_{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, formatduration, -of, json, str(path) ], capture_outputTrue, textTrue, checkTrue, ) 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(parentsTrue, exist_okTrue) out_path asset_dir / fscene_{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(parentsTrue, exist_okTrue) out_path clips_dir / fscene_{scene[scene_id]:03d}.mp4 cmd [ ffmpeg, -y, -loop, 1, -i, scene[asset_path], -i, scene[audio_path], -vf, ( fscale{render_cfg[width]}:{render_cfg[height]}, ffps{render_cfg[fps]}, formatyuv420p ), -c:v, render_cfg[video_codec], -tune, stillimage, -c:a, render_cfg[audio_codec], -shortest, str(out_path), ] subprocess.run(cmd, checkTrue) scene[clip_path] str(out_path) return scene命令里的几个参数需要解释-loop 1让静态图片循环成为视频流。-shortest视频流或音频流哪个先结束输出就停在哪里确保片段不会出现没有声音的黑场。-tune stillimage针对静态图片场景优化编码。formatyuv420p保证输出视频在常见播放器里可以正常播放。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), encodingutf-8)最后把字幕烧录进视频并混合背景音乐ffmpeg -y -i output/demo/concat.mp4 -i output/demo/bgm.mp3 \ -vf subtitlesoutput/demo/subtitles.srt:force_styleFontNameNoto Sans CJK SC,FontSize14 \ -filter_complex [0:a]volume1.0[voice];[1:a]volume0.15[music];[voice][music]amixinputs2:durationfirst[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(encodingutf-8)) return {scenes: [], done_stages: []} def save_status(status, manifest_path): pathlib.Path(manifest_path).parent.mkdir(parentsTrue, exist_okTrue) pathlib.Path(manifest_path).write_text( json.dumps(status, ensure_asciiFalse, indent2), encodingutf-8, )主流程在执行每个阶段前检查对应产物已经存在的直接跳过。这样即使某个第三方服务超时程序中断后也可以从断点继续执行而不是无止境地重复调用模型接口。4. 关键设计细节数据结构、参数和缓存策略4.1 分镜 JSON 是模块之间的契约短剧自动化系统里剧本、画面、音频、剪辑四个模块共享同一个分镜结构。如果这个结构不统一后续每个环节都会出现“字段对不上”的问题。一个可直接使用的分镜字段设计如下字段类型说明scene_idint镜头序号主键rolestring说话角色或“旁白”narrationstring配音用文本决定音频内容subtitlestring字幕显示文本visual_promptstring图像生成提示词estimated_durationfloat文本模型估算时长audio_pathstringTTS 生成的音频文件路径actual_durationfloatffprobe 探取的真实音频时长asset_pathstring生成或检索到的画面底图路径clip_pathstring单镜头渲染后的视频文件路径约定好这份结构之后各模块的输入输出都会非常清楚。llm.py负责生成原始 JSONtts.py负责补充audio_path和actual_durationimage_gen.py负责补充asset_pathffmpeg_utils.py负责补充clip_path。4.2 参数速查哪些参数直接影响成片质量参数常见值调大影响调小影响使用建议temperature0.7文本更发散分镜容易偏离故事更稳定但可能缺乏变化拆解阶段建议 0.5 到 0.7tts.speed1.0语速快单位时间承载更多台词语速慢镜头变长先按默认试听后再调render.fps24文件更大动作更流畅文件小但画面卡顿静态图主导的短剧 24 足够render.width/height1080x1920清晰度更高渲染变慢体积小清晰度不足竖屏常用 1080x1920image.width/height832x1248画面细节更丰富细节丢失最好与渲染比例保持一致背景音乐音量0.15音乐盖过配音气氛不足以能听清对白为准这些参数中最容易被忽略的是图像比例与视频比例不一致。比如底图生成的是 1:1 方形图渲染时强行拉伸成 9:16 竖屏画面上的人物会被压扁。实际项目里要么让图像服务输出与目标视频同比例要么在 FFmpeg 的scale之后补上crop或pad逻辑。4.3 缓存设计不仅要省钱还要避免脏数据缓存的价值不只是减少成本更是让开发调试变得可控。如果每次运行同一段故事都会调用文本模型相同的分镜可能生成不同结果你很难判断后续修改是哪个环节引起的。缓存策略可以按阶段拆分文本模型产物按故事文本的内容哈希缓存。TTS 产物按文本内容、音色、语速联合哈希缓存。图像产物按提示词、尺寸、风格参数联合哈希缓存。单镜头视频按底图路径、音频路径、渲染参数联合哈希缓存。每个阶段的缓存都要依赖“上级产物的路径”而不是依赖内存里的对象。比如单镜头视频的缓存 key 可以取asset_path audio_path 分辨率 fps的哈希。只要上游文件发生变化哈希就会变化旧视频不会被误用。注意不要把“当前系统时间”或“随机数”写进缓存 key 里。否则缓存永远命中不了每次运行都会重新调用昂贵的外部服务。4.4 异常处理与重试策略第三方模型服务不稳定是常态。短剧自动化流程里音频和图像请求失败后直接让整条流水线退出会让可用性非常差。更合理的做法是对每个外部调用做“有限重试 指数退避”。import time import requests def request_with_retry(func, max_retries3): 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.mp45.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.mp45.2 用 ffprobe 检查音画时长final.mp4 生成后至少要检查这几个指标# 视频总时长 ffprobe -v error -show_entries formatduration \ -of csvp0 output/demo/final/final.mp4 # 是否包含音频流 ffprobe -v error -show_entries streamcodec_type \ -of csvp0 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, formatduration, -of, csvp0, str(path)], capture_outputTrue, textTrue, checkTrue, ) return float(result.stdout.strip()) def srt_end_time(srt_path): text pathlib.Path(srt_path).read_text(encodingutf-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 高频问题的现象与处理方向问题现象可能原因检查方式处理建议成片只有画面没有声音混流时没有正确映射音频流ffprobe -show_entries streamcodec_type检查-map [aout]是否生效画面与配音不同步用了估算时长而不是音频真实时长对比音频时长和单镜头片段时长用ffprobe回填actual_duration图片在竖屏视频里被压扁图像比例不是 9:16查看底图实际宽高先scale再crop或pad单镜头拼接后黑屏每个片段没有统一使用yuv420p检查每个片段的编码器参数统一渲染参数必要时重新转码字幕是乱码SRT 编码不是 UTF-8 或缺少中文字体打开字幕文件检查编码使用 UTF-8 编码并设置中文字体重复运行费用暴涨缓存 key 设计不合理查看缓存目录是否生成了大量重复文件检查缓存 key 是否包含时间戳或随机值TTS 请求偶发失败第三方服务超时查看错误类型是连接超时还是业务错误对网络错误做指数退避重试对业务错误直接失败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 streamwidth,height -of csvp0 输入文件解决方式是统一尺寸更好的写法是在-vf里使用能保证像素对齐的表达式-vf scale1080:1920,croptrunc(iw/2)*2:trunc(ih/2)*2,formatyuv420p实际项目中直接在配置层把图片尺寸和视频分辨率都设计成偶数可以从源头避免该问题。6.4 通用排查顺序当整条流水线失败时按下面的顺序排查最有效输入故事文本是否有内容编码是否为 UTF-8。路径配置是否正确work_root目录是否可写。文本模型是否返回了合法 JSON是否出现幻觉字段。TTS 文件是否生成成功音频时长是否正常。图像文件是否存在尺寸是否符合预期。FFmpeg 命令是否在单镜头阶段报错。拼接清单中的相对路径是否与当前工作目录匹配。最终文件的音视频流和时间轴是否对齐。这个顺序遵循“先检查输入再检查中间产物最后检查输出”的原则。大部分在“第 1 步到第 4 步”出现的问题最终都会表现为成片异常需要逐层往下看不能只盯着 final.mp4 检查。7. 从自动化的 Demo 到可生产落地还要补齐这些事7.1 学习环境与生产环境的差异本地跑通一条短剧流水线和真正对外提供服务之间还有不少距离。下面列出主要差异维度学习环境生产环境第三方服务手动重试失败后人工干预需要独立任务队列、告警、自动补偿状态存储JSON 文件或内存状态数据库或对象存储 状态机成本控制不太关注费用需要预算上限、调用次数统计、配额告警权限隔离本地脚本直接执行需要环境变量、密钥管理、权限控制日志打印到控制台结构化日志、调用链追踪、监控大盘内容合规只需要本地可看需要接入内容审核人工抽审不可省略回滚重新跑一遍即可需要历史版本归档、产物版本对比本地 JSON 作为状态文件在单机脚本里足够但如果未来要支持多任务并行或多人协作建议改用数据库表记录每个分镜的执行状态。