AI漫剧量产全流程：从剧本、分镜到成片的工程化搭建指南

看到“XX模型满血开源、一键量产90集短剧”之类的标题，很多技术人第一反应是点进去看看有没有新玩具。我并不打算替某个模型站台，也不会只介绍某一张功能页，而是把 AI 漫剧/短剧量产从剧本、角色、分镜、视频、配音到剪辑的完整链路拆给你看。这里有个前提要先讲清楚：网络上“满血开源”的说法是否准确，建议以模型官方文档为准，工具圈的信息扩散往往快过事实；真正能让内容持续生产的，是稳定的工程流程而不是某一次热点。无论你用的是 MiniMax 系列生成服务、其他多模态 API，还是本地 Stable Diffusion 加 Video 模型，这套工作流思路都能直接复用。适合正在做 AI 内容工具、短视频批量生产、数字人漫剧尝试的同学参考。

1. 背景与核心概念

1.1 什么是 AI 短剧与 AI 漫剧

AI 短剧是指利用大语言模型生成剧本、利用图像模型生成画面、利用视频模型生成动态镜头、利用语音模型生成台词配音，最终通过剪辑工具拼合成片的短视频内容类型。漫剧这个说法，通常指以动漫风格画面为主、单集约 1 到 3 分钟、剧情密度高的竖屏视频形态。相比纯文本创作，它的门槛在于“画面一致性”和“多镜头连贯性”，这也是很多量产教程翻车的地方。

从观众角度看，AI 漫剧把传统动画生产的昂贵环节，比如原画、分镜、中间帧、配音统筹，压缩成了一个个生成请求。它看起来像是在做“视频”，实际上更接近一条自动化内容生产线。对开发者来说，理解这条线的关键在于：不要把它当成一个“模型”的问题，而要当成一个“数据流”和“任务流水线”的问题。你设计的每一层数据格式、文件命名、错误处理机制，都直接决定批量生产的稳定性。

1.2 “一键量产”的真实拆解

所谓一键量产90集，除非是高度模板化的内容，否则大概率是一套任务流水线：批量生成30个剧本，每个剧本拆成6集，每集拆成9个镜头；再批量生成180张关键帧图片和270段视频素材；最后按分数规整成一集成片。这个过程中真正的“一键”，不过是你写好脚本之后按一次回车。所以本文后面所有的代码都在帮你把“回车”之前的工作做好。

还有一个容易被忽略的事实：任何视频生成接口都有并发限制、超时和成本问题。真正量产时要面对的是“失败重试”和“局部重跑”，而不是像宣传文案里那样把素材一次全量生成。把长视频切割成镜头级别的短片段，一方面绕开了视频模型单次生成时长的限制，另一方面也方便局部替换、修改和重生成，这是工程上更务实的路径。

1.3 为什么掌握这套流程有价值

从技术角度，这套流程让内容生产从“单人用剪辑软件一帧帧调”变成“用 API 调度批量生成”。工程上你处理的是并发、重试、成本预算和文件命名，这些都是音视频自动化中通用的问题。从产品角度，如果要对齐短剧平台的内容节奏，你会频繁调整剧本格式、镜头时长、字幕样式，这些需求最后都会落到批量脚本上。所以本文不是教你怎么靠“某个模型”爆流量，而是教你把内容生产工具链沉淀成稳定的脚本工程。

2. 环境准备与工具选型

2.1 硬件与运行环境

如果主要使用各家大模型 API，本地电脑运行脚本不需要独立显卡，普通笔记本也能跑通工作流；如果打算在本地跑图像生成或视频生成，建议至少 8GB 显存的 NVIDIA GPU，16GB 显存会更顺畅。操作系统方面，Windows、macOS、Linux 都行，本文示例基于 Windows 环境加命令行工具，Linux 服务器部署也能照用。

先检查基础环境是否正常：

python --version ffmpeg -version

如果没有安装 FFmpeg，Windows 用户可以从官方地址下载静态编译版本并配置 PATH，macOS 用户可以用 Homebrew 执行brew install ffmpeg，Linux 用户一般通过系统包管理器安装。FFmpeg 是整个链路里最不可能出错、也最值得提前稳定的依赖，强烈建议先把它跑通。

2.2 软件与 Python 依赖

需要准备的核心组件包括：Python 3.10 或更高版本、FFmpeg、requests、openai（部分平台提供 OpenAI 兼容接口）、Pillow、pandas 或纯 CSV 模块。安装命令如下：

pip install requests openai pillow pandas

其中 pandas 主要用于生成素材清单和管理剧本表格，如果你更倾向轻量方案，只用 Python 内置的json和csv模块也完全够用。依赖永远不要贪多，每多一个第三方库，就多一层版本兼容风险。

2.3 模型与平台接入

项目建设强烈建议在代码里统一封装一个AIService模块，把所有模型调用接口集中到一起。这样后续换模型、换厂商都只需改一个文件。API Key 一律放在环境变量里，不要提交到代码仓库。平台选择上没有绝对标准，以生成的稳定性、价格和并发限制为主要参考。本文的示例调用方式为“OpenAI 兼容接口”，这是目前国内模型平台比较常见的形式，但具体 endpoint 与模型名以所选平台官方文档为准。

环境变量示例：

set AI_API_KEY=your_api_key_here set AI_BASE_URL=https://api.example.com/v1 set AI_TEXT_MODEL=your-text-model set AI_IMAGE_MODEL=your-image-model set AI_VIDEO_MODEL=your-video-model

3. 从剧本到成片的六个核心环节

3.1 剧本批量生成

剧本是所有下游环节的基础。在写代码之前，先设计好数据格式：一部短剧包含多集，每集包含多场戏，每场戏包含多个镜头；镜头下面有画面描述、动作和台词。先把格式定成 JSON，后续生成图片、生成视频、生成 SRT 都会从这个 JSON 读取数据。先用 LLM 生成“每集大纲”，再为每一集生成“剧本 JSON”，可以减少一次生成长文本时出现内容走形的问题。

系统提示词可以设计成：

你是一个短剧编剧。请输出符合 JSON 格式的剧本，字段包括 scene_id、location、characters、shots。每个 shot 必须包含 camera、action、dialogue、visual。

批量调用时，把大纲列表逐条传入并解析返回 JSON。需要特别注意的是：无论写提示词还是处理返回结果，都要对“非法 JSON”“截断”“空 dialogue”做好兜底。批量生产时，宁可中间改数据，也不要让单条错误中断整批任务。实际项目中，我遇到的几乎所有批量中断问题，都是因为“一条数据格式错误”导致脚本崩溃，而不是模型本身生成失败。

3.2 角色设定与一致性

短剧最怕角色换个镜头就换脸。单靠固定 prompt 很难保证一致性，常见的工程化做法有三个：第一，为每个角色建立“角色描述卡片”，包括年龄、服装、发型、五官特征、画风关键词，所有 prompt 都引用同一卡片；第二，如果图像平台支持参考图，把某个已经生成的角色立绘作为参考图一并传给图像模型；第三，生成后人工抽检关键帧，不合格的镜头直接标记重生成。

一个示例 prompt：

主角色：小夏，20岁，黑色短发，红色外套，写实动漫风。 背景：城市夜晚便利店。 镜头：中景，侧光，小夏望向窗外。 风格：竖屏9:16，高质量插画，稳定构图。

角色一致性永远优先于画面丰富度。宁可画面平淡一点，也不能出现同一个角色在两集之间“换了个人”的情况。在批量生产阶段，为你自己的项目定义一个“角色配置表”，每次生成都从配置表读取角色描述，这样后续要修改服装或发型，只需要改动配置再重新生成受影响的素材即可。

3.3 分镜设计与关键帧生成

把剧本 JSON 转换为分镜表，一个镜头对应一行。分镜表至少包含：镜头编号、镜头类别（全景/中景/近景/特写）、画面描述、台词、时长预估。生成图片时，每一行构造一次图像生成请求，输出统一命名的 PNG 文件。建议统一横纵比，短剧通常使用 9:16，分辨率可以按平台要求设置。

这套环节最容易出现的坑是“描述不完整导致画面不可控”，例如只说人物没说环境光、只说动作没说景别。分镜表越结构化，生成的画面越稳定。写画面描述时，固定顺序可以大幅度提升有效性：先写主体角色，再写动作和表情，第三写环境与光线，最后写画风和镜头。

3.4 视频片段生成

值得先说清楚：现在大部分视频生成模型单次生成的时长还比较有限，要做 90 秒一集的短片，常见的做法是把每个镜头独立成 3 到 8 秒的小片段，再剪辑拼合。生成方式可以分为两类：一类是文字直接生成视频，一类是以关键帧图片为第一帧的图生视频。后者在保持角色与场景一致性上明显更有优势，所以漫剧工作流中优先级更高。

批量生成时，限制并发数，设置失败重试。每次调用前记录镜头 ID，生成后把视频文件名和镜头 ID 对应起来，后续如果你要重跑某个镜头，只需要拿着 ID 重发一次请求，不需要重新生成其他素材。有一个容易被忽视的细节是“生成结果的随机性”：同一段 prompt 每次生成都会有细微差异，所以每次调用保存好种子参数或者请求截图，是成本最低的可追溯方案。

3.5 配音与字幕生成

配音有两种思路：如果台词量少，直接使用 TTS 接口为每句台词生成单独音频文件；如果台词很多，可以先把整集剧本按句导出，再逐句合成。多角色配音要尽量做到每个角色保持同一个音色，因此角色与音色参数的映射关系应写进配置文件。生成后为每句音频记录起始时间，用于自动生成字幕。

更省事的办法是先用文案直接生成 SRT 骨架，再用音频时长校准每句字幕开始、结束时间。实际项目中常出现“台词过快、字幕对不上”的问题，需要预留人工分段检查，或把每句之间强制加 200 到 300ms 静音。字幕文件里能表达的信息量很低，一旦批量错位，返工成本会让人崩溃，所以这一环节值得多花时间做质量校验。

3.6 剪辑合成与批量导出

最后一步是合成。FFmpeg 是这里的主力工具。把所有视频片段按镜头顺序拼接，再把配音和背景音混流，最后压制字幕。如果是 30 集同制式内容，可以用同一条 FFmpeg 命令循环处理所有集数，输出统一的成片目录和预览目录。考虑到平台对封面、水印和编码格式的要求，可以在导出阶段做分版本输出，例如“剪辑版”“字幕版”“审核精简版”。

合成阶段要注意编码器一致性。如果部分视频片段来自不同生成参数，它们的分辨率、帧率可能不一样，直接 concat 会出问题，需要先统一转码。统一转码这一步看起来很浪费时间和存储，但它是批量合成不翻车的最可靠保障。

4. 完整实战：跑通一集 90 秒 AI 漫剧

4.1 项目结构

auto-drama-craft/ ├── config/ │ └── settings.json ├── data/ │ ├── outline.json │ └── episode_01.json ├── assets/ │ ├── characters/ │ ├── keyframes/ │ ├── clips/ │ └── audio/ ├── output/ │ ├── episode_01_raw.mp4 │ └── episode_01_final.mp4 ├── scripts/ │ ├── ai_service.py │ ├── generate_script.py │ ├── generate_keyframes.py │ ├── generate_clips.py │ ├── generate_audio.py │ └── build_video.py └── requirements.txt

这个项目结构把配置、数据、中间产物和成片严格分离。刚开始练习时，你可能会想把它全部塞进一个文件夹，但在 90 集量产场景下，磁盘上有几十个 G 的中间素材，没有清晰目录结构会完全失控。

4.2 编写统一调用模块

先封装一个最基础的请求函数，不引入过重依赖：

# scripts/ai_service.py import os import time import requests API_KEY = os.getenv("AI_API_KEY") BASE_URL = os.getenv("AI_BASE_URL", "https://api.example.com/v1") def chat_completion(messages, temperature=0.7, max_tokens=2000, retries=3): """调用文本生成接口（OpenAI 兼容格式），失败自动重试""" url = f"{BASE_URL}/chat/completions" headers = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"} payload = { "model": os.getenv("AI_TEXT_MODEL", "your-text-model"), "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } for attempt in range(retries): try: resp = requests.post(url, json=payload, headers=headers, timeout=120) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] except Exception as exc: print(f"第{attempt + 1}次调用失败: {exc}") time.sleep(2 * (attempt + 1)) raise RuntimeError("文本生成接口调用失败")

这段代码把 API 地址、密钥、重试逻辑统一管理。之所以单独封装，是因为后续剧本、配音脚本里都要复用类似接口，避免每个脚本各自写一遍鉴权逻辑。

4.3 批量生成剧本

接下来编写根据大纲生成一集剧本 JSON 的脚本。为了便于理解，这里用一个本地大纲示例替代复杂的数据读取：

# scripts/generate_script.py import json from ai_service import chat_completion outline_text = "第1集：女主角小夏在便利店值夜班，发现一名神秘顾客留下的线索。" messages = [ {"role": "system", "content": "你是短视频编剧，只输出 JSON。"}, {"role": "user", "content": f"根据大纲生成一集短剧剧本：{outline_text}"}, ] raw = chat_completion(messages, max_tokens=4000) # 解析返回 JSON，做异常兜底 try: script = json.loads(raw) except json.JSONDecodeError: start = raw.find("{") end = raw.rfind("}") + 1 script = json.loads(raw[start:end]) with open("../data/episode_01.json", "w", encoding="utf-8") as f: json.dump(script, f, ensure_ascii=False, indent=2)

这里让模型只输出 JSON，且字段固定，能够最大程度减少下游环节的数据清洗成本。很多新手直接让模型输出整段 Markdown 文本，后续反而要二次解析，既不稳定又容易出错。

4.4 素材清单化

当剧本 JSON 足够稳定后，用一个脚本把剧本打散成素材清单。每个镜头包含关键帧图片路径、视频输出路径、台词文本文件和字幕时间。下游工序只需要遍历一行清单即可。

# scripts/build_manifest.py import json with open("../data/episode_01.json", "r", encoding="utf-8") as f: script = json.load(f) shots = [] for scene in script["scenes"]: for idx, shot in enumerate(scene["shots"]): shots.append({ "shot_id": f"{scene['scene_id']}_{idx:02d}", "scene_id": scene["scene_id"], "camera": shot.get("camera", "中景"), "action": shot["action"], "dialogue": shot.get("dialogue", ""), "keyframe": f"../assets/keyframes/{scene['scene_id']}_{idx:02d}.png", "clip": f"../assets/clips/{scene['scene_id']}_{idx:02d}.mp4", "audio": f"../assets/audio/{scene['scene_id']}_{idx:02d}.mp3", "duration": 4, }) with open("../data/manifest.json", "w", encoding="utf-8") as f: json.dump(shots, f, ensure_ascii=False, indent=2) print(f"共生成 {len(shots)} 个镜头的素材清单")

素材清单是整个量产流水线的“单文件真相源”。后续生成图片、生成视频、生成音频、剪辑合成，全部读这一个文件；你只要把清单里的路径和预计时长改对，流水线就能自动往前走。建议每个镜头 ID 从生成一直延续到成片里，排查问题时能直接定位。

4.5 生成关键帧与视频片段

关键帧生成与视频生成脚本在结构上非常相似，区别在于请求接口参数不同。图片生成适合先用文本到图片，拿到稳定角色后，再跑图生视频。下面给一个关键帧生成的调用示例，具体字段由你使用的平台决定：

# scripts/generate_keyframes.py 核心逻辑 import json import base64 import os import requests from ai_service import API_KEY, BASE_URL def generate_image(prompt, output_path): url = f"{BASE_URL}/images/generations" payload = { "model": os.getenv("AI_IMAGE_MODEL", "your-image-model"), "prompt": prompt, "size": "832x1472", "response_format": "b64_json", } headers = {"Authorization": f"Bearer {API_KEY}"} resp = requests.post(url, json=payload, headers=headers, timeout=120) resp.raise_for_status() img_data = resp.json()["data"][0]["b64_json"] with open(output_path, "wb") as f: f.write(base64.b64decode(img_data))

这里展示的是常见平台返回 base64 图片的通用写法，字段名可能不同。更稳妥的方式是先从文档拿到“返回 URL”或“临时存储地址”，再用 requests 下载文件。视频生成同理，只是把/images/generations换成视频接口，并且轮询任务状态。

4.6 生成配音与字幕

音频生成同样使用通用逻辑：先为每个镜头拼接一个“台词 + 音色风格”的请求，调用 TTS 接口保存音频；再用音频时长计算对应的 SRT 字幕块。下面是一个手动生成 SRT 的简单函数：

# scripts/build_subtitle.py 核心逻辑 def ms_to_srt_time(ms): hours = ms // 3600000 minutes = (ms % 3600000) // 60000 seconds = (ms % 60000) // 1000 millis = ms % 1000 return f"{hours:02d}:{minutes:02d}:{seconds:02d},{millis:03d}" def make_srt(shots, output_path): lines = [] counter = 1 current_time = 0 for shot in shots: if not shot["dialogue"]: current_time += int(shot["duration"] * 1000) continue text = shot["dialogue"] start = current_time end = start + max(1000, min(6000, len(text) * 300)) current_time = end lines.append(f"{counter}") lines.append(f"{ms_to_srt_time(start)} --> {ms_to_srt_time(end)}") lines.append(text) lines.append("") counter += 1 with open(output_path, "w", encoding="utf-8") as f: f.write("\n".join(lines))

这里把“逐句字幕的预估时长”粗略算成“文本长度 × 300 毫秒”，并设置了最小 1 秒、最大 6 秒的边界。实际合成后仍然要人工校准，尤其是一句话较长、语速较快的时候，字幕容易延后。

4.7 FFmpeg 合成一集成片

把片段、音频、字幕合成最终的竖屏成片，这是整条链路里最稳定的一段路。先拼接所有素材清单中的片段：

ffmpeg -f concat -safe 0 -i filelist.txt -c copy ../output/episode_01_raw.mp4

其中filelist.txt内容为：

file '../assets/clips/scene_01_00.mp4' file '../assets/clips/scene_01_01.mp4' file '../assets/clips/scene_02_00.mp4'

再把音频混入并压制字幕：

ffmpeg -i ../output/episode_01_raw.mp4 -i ../assets/audio/all_audio.mp3 \ -vf "subtitles=../output/episode_01.srt" \ -c:v libx264 -crf 23 -c:a aac -shortest ../output/episode_01_final.mp4

这里用subtitles滤镜把字幕烧进画面，libx264是常见 H.264 编码器。如果你想保留字幕开关，可以导出不带字幕的视频和独立 SRT 文件，这样能覆盖不同平台需求。字幕文件中的冒号和逗号需要转义，中文路径也容易出问题，建议路径中不要出现空格。

4.8 运行与效果验证

跑一个微型冒烟测试：先拿 1 集、1 个场景、3 个镜头，按“剧本生成→关键帧→视频片段→配音→合成”走一遍，确认每个中间产物都成功输出，再决定是否全量跑 90 集或更多集数。运行时不建议直接在终端观察全部日志，最好把每次调用的状态写入日志文件，出现批量失败时能快速定位是哪个镜头、哪个 API 调用还是本地磁盘问题。

验收时可以按下面的标准检查：

这套验收标准不需要一次全部自动化，但建议在脚本里列出对应的检查函数，因为人工检查 90 集素材的体力消耗远超你的想象。

5. 常见问题与排查思路

AI 漫剧量产过程中，问题大多数集中在几个固定环节。

排查时建议按“数据层 → API 层 → 文件层 → 合成层”的顺序进行。数据层看剧本 JSON、素材清单字段是否完整；API 层看请求返回码和 message；文件层检查产物是否真的生成、大小是否为零；合成层则逐段检查拼接后的片段和音频对齐情况。

批量数量大的时候，日志里记录的镜头 ID 和文件 MD5 是排查利器。每次生成完成之后，第一时间把产物以及它的 MD5 写入索引文件，后续定位问题时会发现节省大量时间。

6. 工程化与量产建议

6.1 把流水线拆成可恢复的步骤

真正的量产，不是一个大脚本从头跑到尾，而是把生成分成多个 stage：剧本、关键帧、视频、音频、合成。每个 stage 结束后，检查产物数量是否匹配素材清单，到这一步再继续下一步。任何一步断了，只需要重跑对应 stage，而不需要从剧本重新生成，这也意味着你必须从一开始就确定规范的文件命名规则。

# 示例：检查某个目录下产物数量是否齐全 from pathlib import Path def check_artifacts(manifest, asset_type, asset_dir): missing = [] for item in manifest: name = item[asset_type] if not Path(asset_dir, name).exists(): missing.append(name) return missing

如果发现缺失数量过多，要考虑检查 API 配额和并发数；缺失少量则直接补跑。这种“按清单核对资产”的思路，和游戏美术资产管理类似，非常适合短剧量产。

6.2 成本与并发策略

调用 API 生成的每一张图、每一段视频都要花钱，所以成本控制的要点是：不要对同一个镜头反复调用接口。先本地缓存，以 prompt 文本的 Hash 为键，如果同样的 prompt 已生成过文件，直接跳过。并发数不要盲目拉满，尤其在你的 API 套餐较低时，建议把并发控制在一个比较保守的数值，避免触发限流后反而拖慢整体进度。

实现上可以用信号量控制并发上限，或者简单的多线程批次调度：

from concurrent.futures import ThreadPoolExecutor from threading import Semaphore sem = Semaphore(4) # 同一时间最多4个请求 def guarded_generate(item): with sem: return generate_one(item) with ThreadPoolExecutor(max_workers=8) as pool: results = list(pool.map(guarded_generate, shots))

这里线程数 8、信号量 4 的意思，是允许 8 个任务排队但只有 4 个会同时请求 API。具体数值根据平台配额调整。如果平台提供异步任务接口，更推荐优先使用异步模式，因为它把重试和进度查询的逻辑都封装在服务端，客户端只需要轮询状态。

6.3 数据版本与可维护性

剧本改了、角色设定改了，都是非常常见的迭代场景。如果不加控制，你的产物很快会出现“不同版本混在一起”的灾难。建议每次大规模重跑前，新建一个版本目录，例如run_20250401，素材、清单、日志都放在同一个版本目录下。脚本里不要写死相对路径，尽量把根目录从一个配置项中读取。再有条件，可以每次跑完把日志和清单压缩归档，方便回溯。

配置管理的粒度也要细：角色卡、画风、分辨率、配音音色、字幕样式，这些都应该提到config/settings.json中，而不是散落在代码里。换一种画风时，只需修改配置，不需要动任何代码。我自己在实际项目中踩过最大的坑，就是“新画风效果不错，但旧的 prompt 还散落在各个脚本的字符串里”，最后不得不借助搜索引擎逐个替换。

6.4 日志与断点续跑

量产脚本的日志至少要包含三行信息：请求参数摘要、返回状态、产物文件路径。日志文件名带时间戳，方便回溯。断点续跑不是可选项，而是批量任务的刚需，尤其是每隔一段就会遇到平台限流的情况下。推荐每次循环判断产物文件是否已经存在，如果存在且大小有效，直接跳过生成步骤，这比任何文件级缓存都简单有效。

7. 内容安全、版权与平台规则

7.1 版权与侵权规避

用 AI 生成内容时，版权问题经常被忽视。建议不要生成任何与真实明星、NPC 角色、受版权保护的动漫形象高度相似的角色；不要使用未经授权的音乐、音效；不要直接搬运他人剧本改编。如果要发布到短剧平台，务必提前阅读平台内容规范。自己原创的故事线和角色设计，尽量保留创作过程记录，包括剧本草稿、提示词版本、生成日期，这对日后出现版权争议时非常有利。

翻车案例大多数不是故意的，而是“参考图选得太像某个IP角色”导致的。做内容量产的人一定要在项目启动前就把这条规则写进流程，而不是等收到平台通知再补救。

7.2 AI 生成内容的标识

按照目前的内容治理趋势，AI 生成内容通常需要明确标识。在视频片头或简介中标注“本视频由 AI 辅助生成”，不仅是合规要求，也是降低观众误解、避免平台下架风险的手段。字幕或片尾统一归档标识位置，也会显得项目组足够专业。

7.3 API 安全与最小权限

所有 API Key 放在服务端的环境变量或密钥管理系统中，避免写入前端代码或公开仓库。如果项目有多人协作，为不同角色配置不同权限的密钥；生成、修改、删除素材的操作需要留痕。对涉及删除素材或清空目录的脚本，必须在函数开头做二次确认，防止误删生产数据。

在量产项目中，最典型的事故就是“清理临时目录时把上一轮的原始素材一起删了”。建议所有删除操作用一个集中函数实现，函数内部先打印将删除的文件清单，再等待确认，这样即使手滑也会多一步防御。

8. 学习路线与下一步

通过本文，你已经走完了“一个短剧镜头从文字变成成片”的完整链路：用结构化 prompt 批量生成剧本，用清单驱动素材生产，用 FFmpeg 完成最后的组装。这套方法不依赖某个特定模型，所以即使未来模型频繁换新，你手里的工程骨架仍然有效。

下一步可以沿三个方向深入：第一，学习角色一致性方向的微调，比如基于 LoRA 训练专属角色模型，让角色一致性不再完全依赖平台生成能力；第二，研究自动化配音和口型同步，漫画风格的角色可以做简单的口型驱动；第三，把现有的脚本升级成定时任务或 Web 服务，让运营同学不需要每次手动跑命令。

如果你正在尝试做自己的 AI 漫剧项目，建议从最小的 3 镜头样片开始，不要一上来就追求 90 集。先把单集跑通，再慢慢加并发、加缓存、加自动审查。希望这份流程能帮你少踩一些坑，也欢迎在评论区聊聊你踩过最多的生成问题。