看到“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 GPU16GB 显存会更顺畅。操作系统方面Windows、macOS、Linux 都行本文示例基于 Windows 环境加命令行工具Linux 服务器部署也能照用。先检查基础环境是否正常python --version ffmpeg -version如果没有安装 FFmpegWindows 用户可以从官方地址下载静态编译版本并配置 PATHmacOS 用户可以用 Homebrew 执行brew install ffmpegLinux 用户一般通过系统包管理器安装。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_KEYyour_api_key_here set AI_BASE_URLhttps://api.example.com/v1 set AI_TEXT_MODELyour-text-model set AI_IMAGE_MODELyour-image-model set AI_VIDEO_MODELyour-video-model3. 从剧本到成片的六个核心环节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, temperature0.7, max_tokens2000, retries3): 调用文本生成接口OpenAI 兼容格式失败自动重试 url f{BASE_URL}/chat/completions headers {Authorization: fBearer {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, jsonpayload, headersheaders, timeout120) 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_tokens4000) # 解析返回 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, encodingutf-8) as f: json.dump(script, f, ensure_asciiFalse, indent2)这里让模型只输出 JSON且字段固定能够最大程度减少下游环节的数据清洗成本。很多新手直接让模型输出整段 Markdown 文本后续反而要二次解析既不稳定又容易出错。4.4 素材清单化当剧本 JSON 足够稳定后用一个脚本把剧本打散成素材清单。每个镜头包含关键帧图片路径、视频输出路径、台词文本文件和字幕时间。下游工序只需要遍历一行清单即可。# scripts/build_manifest.py import json with open(../data/episode_01.json, r, encodingutf-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, encodingutf-8) as f: json.dump(shots, f, ensure_asciiFalse, indent2) 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: fBearer {API_KEY}} resp requests.post(url, jsonpayload, headersheaders, timeout120) 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, encodingutf-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 调用还是本地磁盘问题。验收时可以按下面的标准检查检查项通过标准剧本 JSON能被json解析镜头数符合预期关键帧图片目录文件数量等于镜头数文件大小大于 0视频片段每个片段时长在 3 到 8 秒之间音频字幕SRT 每行都有对应音频时长成片音画同步画面无黑边时长约 90 秒这套验收标准不需要一次全部自动化但建议在脚本里列出对应的检查函数因为人工检查 90 集素材的体力消耗远超你的想象。5. 常见问题与排查思路AI 漫剧量产过程中问题大多数集中在几个固定环节。问题现象常见原因解决思路角色换脸、服装不一致没有固定参考图纯文本 prompt 控制力弱使用角色卡 参考图生成后保留种子视频时长太短无法拼成完整镜头模型单次生成时长限制一个镜头拆为多个片段使用转场或静帧补充字幕时间轴对不上字幕时长靠估算未按真实音频校准从音频文件读取时长计算字幕或进行语音识别对齐批量请求报 429 或超时并发过高或账户额度不足降并发、增加退避重试、预检查额度画面构图奇怪主体被裁剪未统一分辨率与 prompt 描述所有生成请求固定 9:16并写明主体位置导出成片体积过大码率设置过高使用 CRF 23 或按目标文件大小设置二压参数输出视频音画不同步音频拼接顺序与视频不一致统一使用素材清单排序并在合成前对比时长排查时建议按“数据层 → 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_workers8) 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 集。先把单集跑通再慢慢加并发、加缓存、加自动审查。希望这份流程能帮你少踩一些坑也欢迎在评论区聊聊你踩过最多的生成问题。 
长河君 · 2026/10/13 11:50:35 · 阅读 1.2k 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 GPU16GB 显存会更顺畅。操作系统方面Windows、macOS、Linux 都行本文示例基于 Windows 环境加命令行工具Linux 服务器部署也能照用。先检查基础环境是否正常python --version ffmpeg -version如果没有安装 FFmpegWindows 用户可以从官方地址下载静态编译版本并配置 PATHmacOS 用户可以用 Homebrew 执行brew install ffmpegLinux 用户一般通过系统包管理器安装。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_KEYyour_api_key_here set AI_BASE_URLhttps://api.example.com/v1 set AI_TEXT_MODELyour-text-model set AI_IMAGE_MODELyour-image-model set AI_VIDEO_MODELyour-video-model3. 从剧本到成片的六个核心环节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, temperature0.7, max_tokens2000, retries3): 调用文本生成接口OpenAI 兼容格式失败自动重试 url f{BASE_URL}/chat/completions headers {Authorization: fBearer {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, jsonpayload, headersheaders, timeout120) 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_tokens4000) # 解析返回 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, encodingutf-8) as f: json.dump(script, f, ensure_asciiFalse, indent2)这里让模型只输出 JSON且字段固定能够最大程度减少下游环节的数据清洗成本。很多新手直接让模型输出整段 Markdown 文本后续反而要二次解析既不稳定又容易出错。4.4 素材清单化当剧本 JSON 足够稳定后用一个脚本把剧本打散成素材清单。每个镜头包含关键帧图片路径、视频输出路径、台词文本文件和字幕时间。下游工序只需要遍历一行清单即可。# scripts/build_manifest.py import json with open(../data/episode_01.json, r, encodingutf-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, encodingutf-8) as f: json.dump(shots, f, ensure_asciiFalse, indent2) 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: fBearer {API_KEY}} resp requests.post(url, jsonpayload, headersheaders, timeout120) 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, encodingutf-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 调用还是本地磁盘问题。验收时可以按下面的标准检查检查项通过标准剧本 JSON能被json解析镜头数符合预期关键帧图片目录文件数量等于镜头数文件大小大于 0视频片段每个片段时长在 3 到 8 秒之间音频字幕SRT 每行都有对应音频时长成片音画同步画面无黑边时长约 90 秒这套验收标准不需要一次全部自动化但建议在脚本里列出对应的检查函数因为人工检查 90 集素材的体力消耗远超你的想象。5. 常见问题与排查思路AI 漫剧量产过程中问题大多数集中在几个固定环节。问题现象常见原因解决思路角色换脸、服装不一致没有固定参考图纯文本 prompt 控制力弱使用角色卡 参考图生成后保留种子视频时长太短无法拼成完整镜头模型单次生成时长限制一个镜头拆为多个片段使用转场或静帧补充字幕时间轴对不上字幕时长靠估算未按真实音频校准从音频文件读取时长计算字幕或进行语音识别对齐批量请求报 429 或超时并发过高或账户额度不足降并发、增加退避重试、预检查额度画面构图奇怪主体被裁剪未统一分辨率与 prompt 描述所有生成请求固定 9:16并写明主体位置导出成片体积过大码率设置过高使用 CRF 23 或按目标文件大小设置二压参数输出视频音画不同步音频拼接顺序与视频不一致统一使用素材清单排序并在合成前对比时长排查时建议按“数据层 → 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_workers8) 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 集。先把单集跑通再慢慢加并发、加缓存、加自动审查。希望这份流程能帮你少踩一些坑也欢迎在评论区聊聊你踩过最多的生成问题。