AI短剧生成平台实战：从脚本到成片的pipeline搭建与调优

简介：面向AI视频创作者与短剧开发者的全栈源码包，解决从一句话创意到成片输出的完整短剧制作难题。基于大语言模型解析剧本并自动提取角色、场景与分镜，配合AI绘图生成角色形象和场景背景，再通过图生视频、TTS配音与FFmpeg合成，形成一条自动化工作流。压缩包共94个文件、约634KB，文件类型以ts、vue、md、json为主：ts为前后端逻辑源码，vue为管理界面组件，md为说明文档，json为配置数据；同时包含docker-compose与Dockerfile，便于本地快速部署。已有305人学习/浏览，适合需要系统了解AI短剧生成链路或进行二次开发的读者。资源内含完整的项目与剧集管理、AI剧本改写、角色与场景编辑、分镜拆解、音频生成及视频导出模块，并附带角色形象批量生成、音色分配、帧类型选择等细节设计。部署后即可体验“一句话出短剧”的完整流程，同时可参考skills目录中的脚本改写、分镜拆解与网格提示词生成逻辑，快速接入自有业务。

1. 一句话到成片：AI短剧生成平台今天能跑到哪一步

输入一句话，自动吐出剧本、分镜、配音和成片——AI短剧生成平台是这两年里最让人“又爱又恨”的一类项目。爱的是它把整条生成链路串得很完整：剧本编写、角色和场景提取、分镜生成、配音、视频合成，每个环节都有对应模块；恨的是它比单点AI工具难伺候得多，模型、素材、编码、音画对齐全混在一起，任何一个环节翻车，整条流水线就停在半路。

这类平台的本质不是某个大模型，而是一条编排好的pipeline：大模型负责剧本与分镜，TTS负责台词配音，ffmpeg负责把素材拼成带字幕的短片。它真正能替代的，是从零写脚本、逐条配音、手工剪镜头这些繁琐工序；它暂时替代不了的，是导演对镜头节奏的判断。适合谁用？想批量做AI漫剧、短视频解说、营销短片的团队，以及想在自己项目里集成“文生视频”能力的开发者。下文我按自己实际搭过的方案，把拆解、部署、调参和踩坑一次讲完。

2. 剧本与分镜：怎么把一句话变成一套可执行的拍摄脚本

拿到一句话需求，我不会让模型一口气输出“剧本+分镜+角色表”，而是拆成三次独立的LLM调用：第一次扩写剧本，第二次抽角色和场景，第三次切分镜。这种拆法看起来很笨，但每一步都能单独校验，出错了也能定位到具体环节。整条链路本质上是多个ai agent各管一段：编剧agent负责扩写，抽取agent负责结构化，分镜agent负责把长文本切成可拍摄的单位。

这样做还有个现实原因：上下文一长，大模型在单次输出里既要保持剧情连贯，又要保证JSON结构合法，非常容易顾此失彼。与其赌一个超长输出的稳定性，不如把任务切小。下面三个小节分别讲这三步怎么做，代码可以直接抄进你自己的服务里。

2.1 剧本扩写提示词：把20字的主旨扩成1200字的正文

剧本扩写是整个平台里最“吃”提示词的一步。写提示词本身就是工程，行业内现在常说的ai编程提示词也好、prompt engineering也好，核心就一句话：把约束写清楚，把自由留给模型。我一般会定义一个多行字符串模板，里面留好可替换的占位符，比如剧名、题材、集数、每集字数。

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), # 兼容OpenAI协议的服务端点 ) def build_script_prompt(one_line_story: str, episodes: int = 3, words_per_ep: int = 800) -> str: return f""" 你是一位短剧编剧。请根据下面这句话扩写出一部完整的短剧大纲，并展开第一集的完整剧本。 一句话故事：{one_line_story} 要求： 1. 短剧共{episodes}集，每集约{words_per_ep}字。 2. 输出顺序为：剧名 / 一句话梗概 / 角色表（姓名+年龄+性格+口头禅）/ 每集的剧情大纲 / 第一集完整剧本。 3. 剧本正文必须包含对白、动作描述、场景地点。 4. 对白口语化，单句不超过40字。 5. 不要输出JSON，用自然段落，便于后续二次抽取。 第一集剧本控制在{words_per_ep}字左右，结尾留一个钩子。 """

这段代码里有两个关键点：一是用f-string把故事和集数传进提示词，同一个函数可以复用于不同需求；二是明确写了“不要输出JSON”——剧本这种长文本交给模型自由发挥就好，强行让它这时候输出结构化内容，很容易让剧本质量和JSON完整性互相拖累。参数上，扩写任务我一般把temperature调到 0.8 左右，max_tokens给到3000以上，给足故事发挥的空间。

2.2 角色与场景抽取：从剧本到结构化JSON，一次稳住的写法

剧本扩写完成后，第二步是把角色和场景抽成结构化数据。这一步严格要求输出合法JSON，所以要用第二次LLM调用，而不是让第一次扩写顺带完成。抽取时temperature要降到 0.1，给模型的自由度越小越好。

from pydantic import BaseModel, Field class Character(BaseModel): name: str = Field(description="角色姓名") gender: str = Field(description="性别") age: int = Field(description="年龄") personality: str = Field(description="性格特征，不超过20字") catchphrase: str = Field(description="口头禅，没有就填空字符串") class Scene(BaseModel): location: str = Field(description="场景地点，如：老宅客厅") time: str = Field(description="时间段，如：傍晚") atmosphere: str = Field(description="氛围关键词，如：压抑、温暖") def extract_roles_and_scenes(script_text: str): prompt = f""" 从下面的剧本中抽取角色和场景，只输出JSON，不要解释。 剧本： {script_text[:6000]} 输出格式： {{ "characters": [{{"name": "", "gender": "", "age": 0, "personality": "", "catchphrase": ""}}], "scenes": [{{"location": "", "time": "", "atmosphere": ""}}] }} """ resp = client.chat.completions.create( model=os.getenv("LLM_MODEL"), messages=[{"role": "user", "content": prompt}], temperature=0.1, response_format={"type": "json_object"}, ) data = json.loads(resp.choices[0].message.content) # 用pydantic再做一次校验，非法字段直接抛错，避免脏数据流到下游 characters = [Character(**c) for c in data["characters"]] scenes = [Scene(**s) for s in data["scenes"]] return characters, scenes

这里我用了response_format={"type": "json_object"}让模型尽量输出合法JSON，再用pydantic二次校验。不要只依赖模型的JSON mode，它只能保证“格式像JSON”，不能保证字段齐全。pydantic校验这一步相当于给下游加了一道保险，角色表缺字段时会在这一层直接报错，而不是等分镜阶段才暴露。

2.3 分镜生成的边界：怎么让AI别替你做剪辑决定

分镜这一步最容易犯的错，是让模型自由决定“镜头怎么切”。模型没有画面素材概念，AI自由发挥出来的分镜往往天马行空，下游根本找不到对应素材。我一般会把分镜任务限定为“语义切块+画面描述补全”：按场景段落、台词密度、节奏起伏把剧本切成若干分镜片段，每段只输出固定的几个字段。

def split_into_shots(episode_script: str, scene_info: dict, max_shots: int = 12): prompt = f""" 你是分镜师。请把下面的剧本片段切分成{max_shots}个以内分镜。 场景信息：{scene_info} 每个分镜必须包含： - shot_id: 镜号 - duration_sec: 预估时长，3到8秒 - shot_size: 景别，从[远景, 全景, 中景, 近景, 特写]中选 - visual: 一句话画面描述，要具体到主体动作和环境 - line: 该分镜内的台词，没有就填空字符串 - sfx: 音效或背景音提示 只输出JSON数组，不要输出其他内容。 剧本： {episode_script} """ resp = client.chat.completions.create( model=os.getenv("LLM_MODEL"), messages=[{"role": "user", "content": prompt}], temperature=0.3, max_tokens=1500, ) shots = json.loads(resp.choices[0].message.content) # 一个常见兜底：duration_sec总时长如果远小于目标时长，自动按比例放大 total_sec = sum(s["duration_sec"] for s in shots) target_sec = 60 * 3 # 假设一集3分钟 if 0 < total_sec < target_sec * 0.8: scale = target_sec / total_sec for s in shots: s["duration_sec"] = round(s["duration_sec"] * scale, 1) return shots

max_tokens这里给到1500，配合max_shots=12的约束，基本能保证一次输出完整JSON，不会因为生成长数组被截断。把duration校验逻辑放在切分函数里，是我习惯留的“后悔药”：模型估算的镜头时长经常偏短，与其后期剪辑时才发现不够用，不如在分镜阶段就按目标总时长缩放。分镜得到的是纯文本描述，真正的画面来自第三章要讲的素材库，这两件事必须在设计上分开。

3. 配音、素材与合成：从分镜脚本到成片的三道工序

分镜脚本出来后，真正开始接触音视频的环节有三道：TTS配音、场景素材匹配、ffmpeg合成。这一章是翻车高发区，前三步在文本世界里跑得再顺，到了音视频环节仍然可能因为一个参数没对齐就前功尽弃。

3.1 TTS配音选型：先定音色表再选引擎，别让角色声音飘

很多人在配音上踩的第一个坑，是拿到角色表就急着调TTS接口，结果发现同一个角色在不同分镜里声音忽高忽低。正确顺序是先定音色表，再选引擎。所谓音色表，就是把2.2抽出来的角色和TTS引擎的音色参数一一绑定，整个生成过程中不再改动。

我一般会为每个角色固定一组参数：引擎、音色标识、语速倍率、音高偏移、音量增益。角色有多个时，音色标识要提前分配好，避免两个角色共用同一种声音。下面是基于edge-tts方案的一个示例，它走的是公网TTS服务，音质稳定，部署时只要服务器能正常访问公网即可。

import edge_tts import asyncio # 音色表：角色名 -> (engine, voice, rate, pitch, volume) VOICE_TABLE = { "林小雨": {"voice": "zh-CN-XiaoxiaoNeural", "rate": "-8%", "pitch": "+2Hz", "volume": "+0%"}, "陈默": {"voice": "zh-CN-YunxiNeural", "rate": "-4%", "pitch": "-3Hz", "volume": "+0%"}, "旁白": {"voice": "zh-CN-YunyangNeural", "rate": "+0%", "pitch": "+0Hz", "volume": "+0%"}, } async def synth_line(character: str, line_text: str, out_path: str): v = VOICE_TABLE[character] tts = edge_tts.Communicate( line_text, voice=v["voice"], rate=v["rate"], pitch=v["pitch"], volume=v["volume"], ) await tts.save(out_path)

语音合成有一个经验：逐句合成比整段合成更稳。整段合成时只要中间有一句读错，整段音频就要重跑；逐句合成则能单独替换，配合分镜JSON里的line字段，一条台词对应一个音频文件，后期对齐字幕也方便。实际跑的时候，我会先把所有分镜的台词一次性批量合成到一个audio/目录，文件名用shot_{id}.mp3规则命名。如果你的环境网络受限，也可以把edge_tts.Communicate换成本地TTS引擎的HTTP接口，音色表的逻辑不用改。

3.2 场景匹配：打标签做粗筛，向量检索做精排

素材匹配这个环节，最容易犯的错是只依赖文本向量检索。素材库几百条视频时，纯向量召回经常匹配出风马牛不相及的片段。我的做法是两段式：先用人工打的硬标签做粗筛，再用向量相似度做精排。

素材库里每段视频都配一个CSV清单，字段包括素材ID、场景关键词、光线氛围、镜头运动方式、横竖比例、时长。粗筛时只用结构化条件过滤，比如分镜要求“老宅客厅+傍晚+温暖”，就先从CSV里挑出同时满足三个标签的素材；硬筛结果为空时，再降级只保留“客厅”标签，给下游兜底。筛选到三五条候选后，再用向量模型对“一句话画面描述”和素材描述算相似度，取最高者。

import csv def match_material(shot: dict, material_csv: str): with open(material_csv, encoding="utf-8") as f: rows = list(csv.DictReader(f)) def score(row): s = 0 if row["location"] in shot.get("location_tags", []): s += 2 if row["atmosphere"] == shot.get("atmosphere_tags", ""): s += 2 if row["aspect"] != shot.get("aspect", "9:16"): # 画幅不匹配直接否决 return -1 return s candidates = [r for r in rows if score(r) > 0] candidates.sort(key=score, reverse=True) return candidates[0] if candidates else None

这段代码里我把画幅不匹配直接判为负分，因为9:16竖屏素材和16:9横屏素材混进同一条片子，后期很麻烦。粗筛的分数其实不用设计得太复杂，我试下来两三个硬标签加权就够用，关键是“先否决、后打分”的顺序不能反。向量精排那段代码和embedding模型耦合较深，不同模型差异大，这里就不贴通用实现；你只需要知道粗筛后还剩三五个候选时，向量排序才值得做。

3.3 ffmpeg视频合成：统一规格后再拼接，字幕在最后烧

ffmpeg是整条流水线的最后一道工序，也是坑最多的地方。我在第一次搭的时候，直接把素材片段按分镜顺序丢给ffmpeg concat，结果成片里有的片段播得快、有的播得慢，音画完全对不上。后来才意识到，concat要求所有输入片段编码参数一致，而素材库里不同来源的视频，分辨率、帧率、码率经常全不一样。

所以我在拼接之前会先做一次统一转码，把每个片段都转成同一个分辨率、同一个帧率、同一个编码格式。竖屏短剧我一般统一到 1080x1920、25fps、H.264。转码命令如下。

# 先统一规格，再进拼接列表 for f in material_*.mp4; do ffmpeg -y -i "$f" \ -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" \ -r 25 -c:v libx264 -preset veryfast -crf 23 \ -an "norm_${f}" done # 生成拼接文件列表 ls norm_*.mp4 | sed 's/^/file /' > concat_list.txt # 先拼视频轨，字幕最后统一烧 ffmpeg -y -f concat -safe 0 -i concat_list.txt -c:v libx264 -r 25 "video_noaudio.mp4"

三个参数需要说明。-vf scale...pad这段是核心：scale先把素材等比缩放到能放进1080x1920的框里，pad再把不足的部分用黑边补齐，这样横屏素材不会变形。-an表示丢弃素材自带音频，短剧的声音完全来自TTS生成的配音，素材原声混进来会非常乱。-crf 23是画质与体积的平衡点，数值越小画质越高文件越大，我日常够用。

字幕我不会在拼接阶段做，而是等视频轨拼完、配音也混流之后，一次性烧录。烧录字幕最稳的方式是把台词先写成ass字幕文件，再重新编码一遍。

# 生成ass后，把配音和视频合成，同时烧字幕 ffmpeg -y -i video_noaudio.mp4 -i "TTS_audio.mp3" \ -vf "subtitles=subtitle.ass" \ -c:v libx264 -crf 20 -c:a aac -b:a 192k \ -shortest final_episode.mp4

-shortest在这里的意思是输出在视频和音频中较短的那个结束时停止。之所以要在最后一步才烧字幕，是因为字幕文本来自分镜JSON里的line字段，如果你在拼接阶段就烧，后面一旦发现某句台词配音读错了，整个视频都要重新转码一遍。顺序反过来，配音只需要重合成那一句，再用上面的命令重跑最后一步。

4. 拿到源码后的安装部署流程：环境、配置与首次全链路跑通

很多读者拿到源码后第一件事是直接python main.py，然后在一堆ModuleNotFoundError里耗掉半天。这类AI短剧生成平台对运行环境的要求比普通Web项目高：需要Python环境、ffmpeg、模型服务地址、素材目录，缺一样都跑不通。我在部署时会固定按“环境准备→配置文件→跑通demo”的顺序来，不跳步。

4.1 环境准备：Python版本、ffmpeg、依赖包一次装齐

先说硬件结论：短剧生成平台里最重的是LLM推理和TTS合成，这两块如果都跑在本地，显卡显存至少16G起步，而且生成一集短剧可能要等十几分钟。所以我一般建议LLM走云端API，TTS按3.1的方案走在线合成，本地只跑素材检索和ffmpeg合成。这样一台8G内存的普通服务器也带得动。

环境准备命令如下，适用于Ubuntu或Debian系系统。

# 1. 系统依赖 sudo apt update sudo apt install -y ffmpeg python3-venv python3-pip # 2. 项目依赖 python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai pydantic edge-tts python-dotenv # 3. 验证ffmpeg可用 ffmpeg -version | head -n 1

依赖清单里我特意没有锁版本号，因为这类项目的下游接口更新频繁，锁死旧版本反而容易撞上接口不兼容。openai库不只是给OpenAI官方服务用的，大部分国产大模型服务都提供兼容OpenAI协议的端点，所以只需要改base_url和api_key，代码不用动。这也是我在2.1里把客户端初始化单独写出来的原因——部署时只要填环境变量，不用翻代码。

要注意，如果你拿到的那份源码里还有额外的依赖文件，比如requirements.txt，先看一遍里面的包名，把跟音频、视频处理相关的都装上。遇到装不上的包，优先检查Python版本，我在Python 3.10和3.11上都跑过这类项目，3.9以下很容易出现二进制包缺失。

4.2 配置文件与路径约定：API端点、素材库、输出目录

这类项目的配置一般集中在settings.yaml或.env里。我习惯用settings.yaml管理业务参数，用.env管理密钥，前者的结构更清晰，后者的密钥不会误提交到版本库。配置文件里最重要的三块：LLM服务、素材库路径、输出参数。

llm: model: "your_model_name" temperature: 0.3 # 默认温度，各stage可在调用时覆盖 max_tokens: 3000 tts: engine: "edge-tts" rate: "-6%" pitch: "+0Hz" material: csv_path: "./materials/index.csv" video_dir: "./materials/videos" aspect: "9:16" output: resolution: "1080x1920" fps: 25 subtitle_font: "思源黑体"

material.csv_path指向3.2里的素材索引清单，video_dir指向实际视频文件目录，这两个路径一定要在启动前确认存在。多数人部署翻车就是栽在这一步：源码里默认的素材路径是作者机器上的绝对路径，你在自己机器上没建这个目录，程序跑到素材匹配阶段才报FileNotFoundError。另外注意output.resolution要和素材匹配时的aspect保持一致，竖屏短剧就用1080x1920，如果还带fps: 25，那第3.3里的转码参数就要跟着对齐，任何一处不一致都会在最后合成时暴露。

4.3 首次全链路跑通：按stage日志逐段确认产物

环境装好、配置填完，终于可以跑第一次全链路。启动命令通常长这样，具体以你手里源码的入口文件为准。

source .venv/bin/activate export LLM_API_KEY="你的密钥" export LLM_BASE_URL="https://你的服务端点" python main.py --story "失恋的都市女孩回到乡下老宅，在邻居男孩的帮助下修复旧钢琴" \ --output ./demo_out

跑起来之后不要盯着屏幕等结果，而是按stage日志逐段确认产物。一个设计合理的平台，每个阶段结束时都会在输出目录留下中间文件，我一般会一边跑一边对照下面的表格检查。

第一次跑通后，立刻把整套流程固化下来。我见过不少团队在demo跑通后直接投入批量生成，结果第二集就翻车，原因往往是第一次跑的时候漏了某个手动步骤，之后每次都手动补。正确做法是：把涉及路径和密钥的手动操作全部写进配置文件和启动脚本，让后续生成做到一条命令完成。

5. 调参避坑与常见问题：先看五个参数，再对五个故障

到这个阶段，项目已经能产出成片，但质量可能忽高忽低。接下来的问题不再是“能不能跑通”，而是“怎么稳定地跑出能看的片子”。我把调试经验分成两类：一类是LLM生成参数，另一类是工程一致性参数。参数调不对，输出的东西就充满玄学色彩，同样的prompt今天能用明天就废。

5.1 温度、top_p、max_tokens：不同stage各用各的参数

很多人在整个平台里只设置一个temperature值，这是最常见的误解。剧本扩写、信息抽取、分镜切分，三类任务的稳定性要求完全不同，必须分开设置。我常用的参数组合如下。

抽取类的temperature必须压低到0.1附近，否则同一个剧本跑两遍，抽出来的角色名可能都不一样。剧本扩写则相反，temperature太低会让故事变得干巴巴。top_p的作用是限制候选词范围，和temperature叠加使用，两个值都调低会让输出更保守。我一般不会让temperature和top_p同时调很高，否则长剧本很容易在结尾开始胡言乱语。

5.2 一致性参数：音色映射表、画幅规格与字幕模板

一致性是短剧和单条AI短视频最本质的区别。单条视频可以追求单个镜头的精美，短剧必须保证角色声音、画幅、字幕风格在全集里前后统一。我把这部分参数单独维护在一份consistency.yaml里，每次生成前加载，不改代码。

character_voices: 林小雨: {voice: "zh-CN-XiaoxiaoNeural", rate: "-8%", pitch: "+2Hz"} 陈默: {voice: "zh-CN-YunxiNeural", rate: "-4%", pitch: "-3Hz"} video: width: 1080 height: 1920 fps: 25 aspect: "9:16" subtitle: margin_v: 48 font_size: 36 font_style: "bold"

音色表的作用前面已经讲过，这里不再重复。画幅和帧率参数必须和素材库保持一致，如果你的素材库里混着横屏和竖屏，宁可先花半天时间把所有素材统一转码，也不要指望ffmpeg在合成时智能处理。字幕模板里的margin_v和font_size是经验值，1080x1920的分辨率下，margin_v: 48能让字幕避开底部进度条区域，font_size: 36在手机上看刚好合适。这些参数定了之后，整个项目周期内不要再改，改一次就意味着所有已生成的片子都要重新烧字幕。

5.3 五个必踩的坑：现象、原因、解决

下面这五个问题，是我在搭这套平台和帮朋友排查时反复遇到的故障，按“现象→原因→解决”记录。它们不是小概率事件，几乎是每套这类系统都会撞上的坎。

坑一：分镜JSON解析失败，脚本报JSONDecodeError。 现象是分镜阶段偶尔返回截断的JSON，数组没闭合。原因通常是max_tokens不够，模型输出到一半被截断。解决方法是先做一次“失败重试”，把temperature临时再调低0.1重跑一次；连续失败两次就把max_tokens从1500加到2000。不要在代码里用正则去“修复”半个JSON，那只会制造更隐蔽的脏数据。

坑二：素材匹配结果为空，或者匹配到完全无关的画面。 现象是“老宅客厅”匹配到了海边沙滩。原因是素材标签不全，或者粗筛条件太苛刻。解决方法是先看3.2里的score函数，确认分镜里的location_tags和素材CSV里的location字段用的是同一套词汇表；其次检查画幅否决逻辑，如果只有横屏素材却要求9:16，结果必然为空。想省钱的做法是给匹配失败的分镜配一个通用转场素材，而不是让整个流程直接崩溃。

坑三：成片音画不同步，前面几秒正常，后面越来越对不上。 现象是配音在说话，画面已经切到下一个镜头，或者反过来。原因基本可以锁定在素材源帧率不统一上。解决方法是严格执行3.3的“先转码再concat”，每个片段进拼接前都过一遍-r 25的参数。不要偷懒省掉统一转码这一步，concat对时间戳的要求非常严格，哪怕只有一个素材是30fps，整个时间轴都会漂移。

坑四：字幕和配音文本对不上，TTS读的是A句，字幕显示B句。 现象是画面里字幕明明写着“我回来了”，配音念出来的却是“我到家了”。原因是台词在LLM生成分镜后又被某个后处理环节改写了一次，两个模块各自拿着不同版本的文本。解决方法是全平台只从分镜JSON里的line字段读取台词文本，TTS和字幕生成都引用同一个字段，任何文本修正都写回line后再继续。

坑五：ass字幕显示乱码，中文字幕变成方块。 现象是视频里字幕不显示或显示乱码，英文正常中文全挂。原因是ass文件缺中文字体声明或文件编码不是UTF-8。解决方法是生成ass时强制用UTF-8编码写文件，并在Style行里显式指定字体名，比如Fontname: 思源黑体。如果你在生成ass时用了open()函数，记得加上encoding="utf-8"，Windows环境下漏了这个参数是必炸的。

6. 进阶验证：用一份输出自检清单守住成片质量底线

平台能批量出片之后，下一个问题是怎么在“没时间逐条看”的前提下保证质量。我的做法是在每次批量生成后跑一个自检脚本，它不管剧情好不好看，只负责核对三个可以量化的硬指标：视频时长是否与分镜计划吻合、TTS音频总时长与视频时长误差是否在容忍范围内、字幕条数是否等于分镜台词条数。

import json, os, subprocess def get_duration(path: str) -> float: r = subprocess.run( ["ffprobe", "-v", "quiet", "-print_format", "json", "-show_format", path], capture_output=True, text=True, ) return float(json.loads(r.stdout)["format"]["duration"]) def self_check(output_dir: str): shots = json.load(open(os.path.join(output_dir, "shots.json"), encoding="utf-8")) video_dur = get_duration(os.path.join(output_dir, "final_episode.mp4")) audio_dur = get_duration(os.path.join(output_dir, "tts_audio.mp3")) line_count = sum(1 for s in shots if s.get("line")) checks = { "video_audio_diff_lt_1s": abs(video_dur - audio_dur) < 1.0, "subtitle_count_match": line_count == len(os.listdir(os.path.join(output_dir, "subtitle"))), "video_len_in_range": int(video_dur) >= 150, # 按实际目标时长调整 } for name, ok in checks.items(): print(f"[{'PASS' if ok else 'FAIL'}] {name}")

这三个指标只能筛掉“物理层面不达标”的片子，剧情质量还是得靠人看。我习惯在批量生成前先跑一条30秒的demo片，总时长比正式集短一大截，但走完全部stage，确认音色表、画幅、字幕样式都正常后，再放开全量生成。这套流程帮我避免了太多次批量产出一堆废片的尴尬——一旦正式集用了新音色或者新字体，自检脚本是查不出来的，只有demo能暴露。希望帮到你。

本文还有配套的精品资源，点击获取