AI短视频在 2024 年之后已经不是概念而是能直接跑通的生产流程。以“奇妙萌可”这类卡通角色短剧为例真正要解决的问题不是“哪个工具能生成视频”而是如何把文案、分镜、画面、配音、剪辑串成一条可复现、可批量执行的流水线。很多做短视频的人尝试 AI 生成后都会卡在同一个位置单张图可以生成单段视频也能生成但把几十个片段拼成一条有剧情、有配音、有节奏的成片时流程就断了。这篇内容会按照一条完整的工程链路把“文字到成片”的每一步拆开给出可运行的示例代码、参数解释、验证方式和排错路径。适合读这篇文章的读者有两类。一类是想做 AI 动画短剧、AI 漫剧、AI 带货视频的内容创作者需要把零散工具串成工作台另一类是后端或全栈开发想理解 AI 视频生产系统的模块边界、任务调度和素材管理逻辑。学完以后你可以根据自己的业务场景把下面这套流程改造成自己的批量成片系统。1. AI短视频不是“一个工具生成全部”而是一条流水线1.1 到底什么是 AI 短视频工作流AI 短视频工作流的核心思想是“拆解”。一个 30 秒的动画短片看起来是一段连续视频实际上可以拆成脚本、分镜、画面、语音、音乐、剪辑六层产物。每一层由不同的 AI 模型或传统程序负责再通过脚本拼接成一个完整文件。为什么要拆因为当前没有哪个通用模型能一次生成“带剧情、带角色一致性、带配音、带转场”的 30 秒成片。即便有些平台支持“一句话生成视频”生成结果往往不可控时长也有限。工程化的做法是每个环节用最合适的模型把确定性交给代码把创造性交给模型。以“奇妙萌可”为例这套工作流的输入是一个主题词输出是一个 mp4 文件。中间的 JSON 脚本、PNG 分镜、片段 mp4、配音音频都是可检查、可替换的中间产物。这种做法的好处是某一环节效果不好时只需要替换该环节的工具或参数不用推翻整个流程。1.2 一条标准生产链路包含哪些环节一个最小可运行的 AI 短视频链路通常包含五个环节脚本生成用大语言模型生成分镜脚本包含镜头序号、画面描述、旁白文案、氛围要求。画面生成根据分镜画面描述生成单帧图也就是关键帧。视频生成把关键帧或画面描述转成 3 到 5 秒的动态片段。声音生成把旁白文案转成配音音频并生成或选择背景音乐。视频合成用 FFmpeg 或剪辑库把多个片段拼接、混音、转码输出最终视频。每个环节的输入输出必须是结构化、可追踪的。脚本阶段的输出是 JSON这样后续程序才能解析画面阶段的输出是 PNG 或 JPG 文件文件名要带场景编号视频阶段的输出是 mp4 片段统一编码格式声音阶段的输出是 mp3 或 wav最终合成是 mp4。这样做的好处是调试时可以定位到具体环节。比如成片里第 3 个镜头角色穿帮直接回到scene_003.png看画面是否已经出错而不是重新生成整条视频。1.3 先选路线云端 API 优先还是本地开源优先实现这条链路有两种路线选择会直接影响环境配置、硬件要求和成本。云端 API 路线的优点是部署简单、模型效果好、不需要高端 GPU。缺点是有调用成本、接口限流、素材要上传到外部平台。适合快速验证流程、内容生产量不大的团队。本地开源路线的优点是没有按次调用费用、数据不出内网、可以批量跑。缺点是需要 GPU 资源环境配置复杂模型效果调优成本高。适合有 GPU 服务器、内容生产量很大的团队。对比项云端 API 路线本地开源路线硬件要求普通开发机即可建议 NVIDIA GPU显存 8G 以上模型效果通常更好更新快依赖所选开源模型成本按调用量计费主要是硬件和电费数据安全素材会传到第三方数据不出内网上线速度快慢需要搭建推理服务适合场景验证、中小批量生产大批量、数据敏感场景本文示例以云端 API 为主因为它的主流程最容易被理解。本地路线的差异点会在第 7 章里单独说明。2. 环境准备与项目骨架2.1 运行环境与依赖在动手写代码前先把环境准备好。建议使用 Python 3.10 或更高版本因为类型标注和异步支持更完整。需要安装的依赖如下pip install requests python-dotenv pyyaml edge-tts如果要用 MoviePy 做更精细的转场或字幕可以额外安装pip install moviepy需要注意MoviePy 依赖 imageio-ffmpeg首次运行时可能会自动下载 FFmpeg 二进制文件。如果网络环境受限也可以直接使用系统安装的 FFmpeg并把 MoviePy 的配置指向本地路径。FFmpeg 是视频合成的核心工具。检查是否安装ffmpeg -version如果没有安装在 macOS 上可以用brew install ffmpeg在 Ubuntu 上可以用apt install ffmpeg在 Windows 上可以从 FFmpeg 官网下载后加入 PATH。生产环境建议固定 FFmpeg 版本避免不同版本对滤镜和编码参数的支持不一致。2.2 项目目录如何组织这里给出一个适合单人开发、也适合后续扩展的目录结构ai_short_video/ ├── .env ├── config.yaml ├── main.py ├── requirements.txt ├── work/ │ ├── scripts/ │ │ └── script_001.json │ ├── images/ │ │ ├── scene_001.png │ │ ├── scene_002.png │ │ └── scene_003.png │ ├── clips/ │ │ ├── clip_001.mp4 │ │ ├── clip_002.mp4 │ │ └── clip_003.mp4 │ ├── audio/ │ │ ├── voice.mp3 │ │ └── music.mp3 │ └── output/ │ └── final_001.mp4work目录按产物类型分目录是这条链路里最重要的工程约定。每一轮生成只往对应目录写文件文件名带场景编号这样即使某个环节失败也只需要重新生成对应文件不用从头开始。配置文件方面.env保存密钥、Base URL 等不能提交到代码仓库的信息config.yaml保存模型名称、分辨率、配音角色、语速等业务参数。2.3 通过 .env 和配置文件隔离密钥与参数先看.env文件它保存 API Key 和接口地址# .env LLM_API_KEYyour_llm_api_key IMAGE_API_KEYyour_image_api_key VIDEO_API_KEYyour_video_api_key LLM_BASE_URLhttps://api.openai.com/v1 IMAGE_BASE_URLhttps://api.your-image-service.com/v1 VIDEO_BASE_URLhttps://api.your-video-service.com/v1注意不同平台的 Base URL、模型名、鉴权方式可能不同落地前要确认你所使用的平台的接口文档。不要假设所有平台都兼容 OpenAI 格式。再看config.yaml# config.yaml llm: model: your-llm-model temperature: 0.8 max_tokens: 2048 image: model: your-image-model size: 1024x1792 seed: 42 video: model: your-video-model duration: 5 fps: 24 resolution: 1080x1920 tts: voice: zh-CN-XiaoxiaoNeural rate: 10% output: fps: 24 resolution: 1080x1920 audio_bitrate: 192k使用配置文件的目的是把“模型选择”和“代码逻辑”分离。模型迭代很快今天用的图像模型可能过两个月就不是最优选择。把模型名和参数放到配置里换模型时只需要改配置不需要改 Python 代码。3. 用 Python 实现一条“文字到成片”的自动工作流3.1 第一步用大模型生成分镜脚本分镜脚本是整个流程的地基。脚本结构直接决定后续每个环节的输入质量。创建一个script_generator.py核心代码如下import json import os import requests from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) def generate_script(topic: str, scenes: int 6) - list: prompt f 你是短视频分镜导演。请围绕主题{topic}写一个适合动画短片的脚本。 要求 1. 共{scenes}个分镜每个分镜时长控制在3到5秒。 2. 只输出JSON数组不要输出其他文字。 3. 每个分镜包含以下字段 - scene_id: 分镜序号 - image_prompt: 画面描述包含主体、动作、背景、光线、风格写给图像生成模型 - narrator_text: 旁白文案口语化适合配音 - atmosphere: 氛围描述如温馨紧张奇幻 示例格式 [ {{ scene_id: 1, image_prompt: 小萌可在森林中跳跃阳光透过树叶卡通风格明亮全身, narrator_text: 清晨萌可来到了魔法森林。, atmosphere: 温暖 }} ] headers { Authorization: fBearer {LLM_API_KEY}, Content-Type: application/json, } payload { model: os.getenv(LLM_MODEL, your-llm-model), messages: [ {role: system, content: 你是一个严谨的分镜脚本生成助手。}, {role: user, content: prompt}, ], temperature: 0.8, max_tokens: 2048, } resp requests.post(f{LLM_BASE_URL}/chat/completions, headersheaders, jsonpayload) resp.raise_for_status() content resp.json()[choices][0][message][content] # 大模型有时会输出带 json 标记的内容需要清理 if content.startswith(): content content.strip() if content.startswith(json): content content[4:] return json.loads(content) if __name__ __main__: script generate_script(奇妙萌可的魔法森林冒险, scenes6) with open(work/scripts/script_001.json, w, encodingutf-8) as f: json.dump(script, f, ensure_asciiFalse, indent2) print(json.dumps(script, ensure_asciiFalse, indent2))这段代码里有两个值得注意的点。第一提示词明确要求“只输出 JSON 数组”并且给了字段示例这能显著提高结构化输出的成功率。第二清除了可能出现的 Markdown 代码块标记避免json.loads解析失败。实际项目中如果模型支持 JSON 输出模式或函数调用优先使用官方结构化输出能力比在提示词里要求更稳定。如果模型没有结构化输出能力可以用一个简单的“截取第一个[到最后一个]”的兜底逻辑。3.2 第二步批量生成分镜画面拿到分镜 JSON 后下一步是生成图像。这个环节最容易出现角色不一致问题所以提示词里要尽量把主角的描述固定下来。创建一个image_generator.pyimport json import os import requests from dotenv import load_dotenv load_dotenv() IMAGE_API_KEY os.getenv(IMAGE_API_KEY) IMAGE_BASE_URL os.getenv(IMAGE_BASE_URL, https://api.your-image-service.com/v1) # 角色锁定描述尽量放在每个画面提示词前 CHARACTER_DESCRIPTION 一个圆滚滚的粉色小精灵戴黄色星星发卡大眼睛卡通3D风格 def build_image_prompt(scene: dict) - str: return f{CHARACTER_DESCRIPTION}。{scene[image_prompt]}。动画电影风格高细节明亮光线 def generate_image(prompt: str, output_path: str, seed: int 42, size: str 1024x1792): headers { Authorization: fBearer {IMAGE_API_KEY}, Content-Type: application/json, } payload { model: os.getenv(IMAGE_MODEL, your-image-model), prompt: prompt, size: size, seed: seed, } resp requests.post(f{IMAGE_BASE_URL}/images/generations, headersheaders, jsonpayload) resp.raise_for_status() data resp.json()[data][0] # 不同平台返回 URL 或 b64_json这里做兼容 if url in data: img_resp requests.get(data[url], timeout30) img_resp.raise_for_status() with open(output_path, wb) as f: f.write(img_resp.content) elif b64_json in data: import base64 with open(output_path, wb) as f: f.write(base64.b64decode(data[b64_json])) else: raise ValueError(未知图像返回格式) if __name__ __main__: with open(work/scripts/script_001.json, r, encodingutf-8) as f: scenes json.load(f) for scene in scenes: scene_id scene[scene_id] prompt build_image_prompt(scene) output_path fwork/images/scene_{scene_id:03d}.png generate_image(prompt, output_path, seed42) print(f已生成 {output_path})这里的核心技巧是CHARACTER_DESCRIPTION。在连续画面中角色外观描述必须一致。如果每个分镜都让模型自由发挥画面里的主角会出现完全不同的服装、发型甚至物种。推荐做法是把角色描述单独提取成常量统一拼接到每个画面提示词前。另外seed参数在部分图像模型中决定了随机噪声的初值。固定 seed 可以提高同一角色不同画面之间的稳定性但不是所有平台都支持 seed。如果不支持就要靠角色参考图或风格模型来保证一致性。3.3 第三步让静态画面变成短视频片段图像生成之后进入视频生成环节。这个环节的工具差异最大有的平台支持“图生视频”有的支持“文生视频”还有的需要提交图片 URL 后轮询任务状态。下面给出一个通用轮询示例思路是提交任务 - 获取任务 ID - 轮询查询状态 - 下载结果。具体接口字段按平台文档调整。import time import os import requests from dotenv import load_dotenv load_dotenv() VIDEO_API_KEY os.getenv(VIDEO_API_KEY) VIDEO_BASE_URL os.getenv(VIDEO_BASE_URL, https://api.your-video-service.com/v1) def submit_video_task(image_path: str, duration: int 5) - str: # 假设平台支持图片上传 with open(image_path, rb) as f: files {image: f} headers {Authorization: fBearer {VIDEO_API_KEY}} data {duration: duration} resp requests.post( f{VIDEO_BASE_URL}/videos/generations, headersheaders, filesfiles, datadata, timeout60 ) resp.raise_for_status() return resp.json()[task_id] def poll_video_task(task_id: str, interval: int 10, timeout: int 300) - str: headers {Authorization: fBearer {VIDEO_API_KEY}} start time.time() while time.time() - start timeout: resp requests.get( f{VIDEO_BASE_URL}/videos/tasks/{task_id}, headersheaders, timeout30 ) resp.raise_for_status() task resp.json() status task.get(status) if status succeeded: return task[result_url] elif status in (failed, cancelled): raise RuntimeError(f视频生成失败: {task.get(error)}) time.sleep(interval) raise TimeoutError(视频生成超时) if __name__ __main__: os.makedirs(work/clips, exist_okTrue) for scene_id in range(1, 7): image_path fwork/images/scene_{scene_id:03d}.png task_id submit_video_task(image_path, duration5) result_url poll_video_task(task_id) clip_resp requests.get(result_url, timeout60) clip_resp.raise_for_status() clip_path fwork/clips/clip_{scene_id:03d}.mp4 with open(clip_path, wb) as f: f.write(clip_resp.content) print(f已生成 {clip_path})视频生成接口大多采用异步任务模式因为单段视频生成需要几秒到几分钟。这里把轮询逻辑单独封装超时时间和轮询间隔都做成参数避免长时间阻塞。需要注意视频生成平台通常对“图片尺寸”“分辨率”“时长”有明确限制。比如部分平台只支持 768x768 或 1024x576而短视频平台更常用 1080x1920。如果输入图比例和视频生成要求不一致需要先在图像生成阶段统一尺寸或者在提交前用 FFmpeg 裁剪。3.4 第四步生成配音和背景音乐配音使用edge-tts库它调用微软在线语音合成服务支持中文自然发音并且不需要注册 API Key。生成配音的代码如下import asyncio import edge_tts async def generate_voice(text: str, output_path: str, voice: str zh-CN-XiaoxiaoNeural, rate: str 10%): communicate edge_tts.Communicate(text, voice, raterate) await communicate.save(output_path) def create_voice_for_scene(narrator_text: str, output_path: str): asyncio.run(generate_voice(narrator_text, output_path)) if __name__ __main__: scenes [ {scene_id: 1, narrator_text: 清晨萌可来到了魔法森林。}, {scene_id: 2, narrator_text: 它发现了一颗会发光的星星果实。}, ] for scene in scenes: create_voice_for_scene(scene[narrator_text], fwork/audio/voice_{scene[scene_id]:03d}.mp3)这里有个工程问题如果每个分镜单独生成配音合成时每个片段的配音时长可能与画面时长不一致。推荐做法是先生成全部画面片段再测量每个片段的实际时长然后按比例调整配音语速或者在最终合成时统一对齐。背景音乐可以用生成式音乐工具也可以从免版权音乐库选择。工程上避免让模型参与背景音乐生成因为它和旁白混音后可能出现人声相位冲突。更稳妥的做法是找一段干净的无损 BGM统一压到低音量再用 FFmpeg 混音。3.5 第五步用 FFmpeg 自动合成最终成片所有素材准备好后进入合成阶段。直接用-f concat拼接的前提是所有视频片段编码参数一致。不同平台的视频输出编码不一定相同因此建议先统一转码再拼接最后混音。创建一个compose.sh脚本#!/bin/bash set -e WORK_DIRwork OUTPUT_DIR$WORK_DIR/output mkdir -p $OUTPUT_DIR # 第一步统一转码所有片段 for f in $WORK_DIR/clips/clip_*.mp4; do name$(basename $f) ffmpeg -y -i $f \ -c:v libx264 -preset medium -crf 18 \ -c:a aac -b:a 192k \ -pix_fmt yuv420p \ $WORK_DIR/clips/transcoded_$name done # 第二步生成拼接列表 : $WORK_DIR/videolist.txt for f in $WORK_DIR/clips/transcoded_clip_*.mp4; do echo file $PWD/$f $WORK_DIR/videolist.txt done # 第三步拼接视频 ffmpeg -y -f concat -safe 0 -i $WORK_DIR/videolist.txt -c copy $WORK_DIR/concat.mp4 # 第四步合并所有旁白音频 ffmpeg -y -i $WORK_DIR/concat.mp4 -i $WORK_DIR/audio/voice.mp3 \ -filter_complex [1:a]volume1.0[voice] \ -map 0:v -map [voice] \ -c:v copy -c:a aac -shortest \ $OUTPUT_DIR/final_001.mp4 echo 合成完成: $OUTPUT_DIR/final_001.mp4转码时选择libx264和yuv420p是兼容性最稳妥的组合。yuv420p能保证视频在多数播放器和短视频平台上正常显示不会出现绿屏或无法播放的问题。如果所有片段的旁白是分开的文件需要先把多个配音按顺序拼接成一个长音频。可以用 FFmpeg 的concat过滤器也可以通过 Python 的pydub拼接。这里需要注意每个配音文件之间是否需要留 300 到 500 毫秒的空隙避免听起来过于急促。4. 关键参数详解与画面一致性调优4.1 大模型生成脚本时的参数选择脚本生成阶段的参数影响的是创意质量而不是格式稳定性。最常调整的参数是temperature和max_tokens。temperature控制模型输出的随机性。取值越低输出越保守、越稳定取值越高输出越有创意但也越容易出现结构混乱。生成分镜脚本时推荐设置在 0.7 到 0.9 之间。如果发现脚本经常格式不规范、字段缺失调低到 0.5 左右更稳妥。max_tokens决定输出长度上限。6 个分镜的 JSON 脚本每个分镜的image_prompt和narrator_text加起来大约 100 到 200 个 token总脚本可能需要 1500 到 2500 个 token。设置 2048 比较常见如果脚本内容多需要调整到 4096。参数默认建议调低影响调高影响temperature0.8更稳定但可能缺乏创意更发散但可能结构混乱max_tokens2048输出可能被截断可生成更多分镜但耗时增加top_p1.0输出更集中输出更多样4.2 图生视频与文生视频的参数差异图生视频是指定一张起始图片让模型根据图片内容生成后续动态文生视频是只给文字描述让模型从空白画面开始生成。在动漫短剧场景里图生视频明显更可控因为角色外观已经被图片锁住。视频生成的几个关键参数duration单片段时长。3 到 5 秒是短视频常见选择过短会导致画面信息不够过长会增加生成失败率和成本。fps帧率。24 fps 足够用于短视频平台30 fps 更流畅但生成时间更长。多数平台限制帧率无需过度追求。resolution分辨率。优先与发布平台保持一致抖音、快手常用 1080x1920 竖屏B 站横屏常用 1920x1080。seed部分平台支持固定 seed 可以稳定生成风格。图生视频时输入图片的质量直接决定输出质量。图片分辨率过低、比例不对、画面主体过小都会导致生成结果抖动严重。建议在图像生成时就直接输出最终视频需要的比例不要在视频环节再裁剪裁剪会损失信息。4.3 角色一致性AI 短片最需要优先解决的问题角色一致性是 AI 动画短视频里最难解决的问题也是“奇妙萌可”这类固定角色项目的核心痛点。一个角色的形象在每个分镜中都要一致否则观众一眼就会出戏。目前常见的解决方案有三种提示词锁定法在每个画面提示词前固定角色描述。优点是简单缺点是不够精确尤其在复杂场景中容易失效。参考图法部分平台支持上传角色参考图生成时参考该图保持角色一致。效果最好但依赖平台能力。模型微调法用角色图片集微调图像模型让模型学会生成该角色。效果最稳定但训练成本和门槛高。按工程优先级先用提示词锁定再尝试参考图最后才考虑微调。不要一开始就训练模型因为角色设定可能还在频繁调整训练一次的成本不低。5. 运行验证与成片检查5.1 最小验证流程先跑通再调效果第一次跑通流程时不要一上来就生成 6 个分镜、每段 5 秒。建议先用 2 个分镜、每段 3 秒把整条链路跑通。验证链路本身就足够脚本能生成、图片能保存、视频任务能提交、配音能落地、FFmpeg 能合成。跑通之后再逐步加参数。每加一个环节先确认上一环节的产物是否正确。最小验证命令# 1. 生成 2 个分镜脚本 python script_generator.py # 2. 生成 2 张分镜图 python image_generator.py # 3. 生成 2 段视频 python video_generator.py # 4. 生成配音 python tts_generator.py # 5. 合成最终视频 bash compose.sh运行过程中任何一步报错都先看它依赖的输入文件是否存在。比如视频生成失败先确认图片是否 200 可读尺寸是否合规。5.2 分步产物检查清单为了快速定位问题每步产物都要做“可检查项”。下面的检查清单可以直接复用步骤检查项合格标准脚本生成JSON 能否解析字段完整无缺失脚本生成分镜数量与预期一致画面生成图片是否可打开无损坏文件画面生成角色描述是否连续多张图主体一致视频生成片段时长与设定时长接近视频生成播放是否流畅无严重卡顿、抽帧配音生成音频时长与画面时长差异在 1 秒内配音生成听感无吞字、爆音最终合成音画是否同步旁白与画面内容对应最终合成是否可以播放无绿屏、无花屏这个清单在批量生产时尤其重要。如果第 3 个分镜在画面生成阶段就出现了角色不一致那后面所有步骤都不用继续做直接回去重新生成第 3 个分镜可以节省大量视频生成费用。5.3 成片合格标准怎么定成片合格不只是“能播放”。对于“奇妙萌可”这类短剧至少要满足三条标准第一剧情能看懂。旁白和画面表达的是同一个事件不能画面在森林里旁白却在讲城市。第二角色连续。主角的样子在第 1 秒和第 29 秒必须一致。第三节奏不拖沓。单镜头停留时间不宜超过 5 秒否则观众容易流失。内容创作者可以把这三条标准写到脚本生成提示词里让模型在生成分镜时就避免“一镜到底”的写法。开发者则可以把这些标准抽象成自动化检查规则比如统计每个分镜的画面主体相似度、旁白文本和image_prompt的主题语义相似度。6. 常见问题排查6.1 接口报错、超时和限流在接入任何 AI 接口时最先碰到的问题就是请求失败。常见现象和排查方式如下问题现象可能原因检查方式处理建议401 UnauthorizedAPI Key 错误或已过期检查.env中的 Key 是否匹配重新生成 Key确认环境变量加载正确429 Too Many Requests超出配额或并发限制查看平台控制台配额降低并发增加重试和退避500 或 503平台服务异常查看平台状态页等待后重试做好失败重试请求超时网络不稳定或生成耗时过长打印请求耗时日志增大超时时间转异步任务建议所有接口调用统一封装重试逻辑。用 Python 的tenacity库可以简化实现from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type import requests retry( stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max30), retryretry_if_exception_type((requests.exceptions.Timeout, requests.exceptions.HTTPError)) ) def call_api_with_retry(url, **kwargs): resp requests.post(url, **kwargs) resp.raise_for_status() return resp.json()注意retry只对临时性问题有效。如果返回的是 400 参数错误、401 鉴权错误重试只会浪费配额应该在抛出前做类型判断。6.2 生成图像出现手指、文字和比例异常图像生成模型在生成手部、文字和复杂图案时仍容易出错。这种现象在卡通风格中相对少见但也可能出现。处理方式有三种局部重绘在支持局部重绘的平台上用蒙版遮住异常区域重新生成。修改提示词把“手”相关的描述去掉改用“双手放在身后”这类规避描述。换图重生成成本最低重新换一个 seed 生成。生成图片里出现乱码文字时检查image_prompt是否要求了“不要文字”。可以在提示词末尾追加“无文字无水印无标志”来降低概率。但这不是绝对最重要的是把生成结果纳入人工检查环节不要让异常图片直接进入视频生成。6.3 拼接后转场生硬、画面闪烁多个 AI 生成的片段直接拼在一起容易出现两种问题。一种是画面没有任何转场看起来像幻灯片另一种是相邻两段画面的光线、色调差异很大产生闪烁感。解决方案是引入转场。最简单的是给每个片段头部和尾部做 0.3 秒的淡入淡出ffmpeg -i input.mp4 -vf fadetin:st0:d0.3,fadetout:st4.4:d0.3 -c:v libx264 -crf 18 output.mp4更进一步的方案是在图像生成阶段要求“镜头衔接”即在当前分镜的image_prompt里补充上一分镜的结束画面要素。这会显著提高相邻镜头的连贯性。6.4 配音对不上画面、音频缺失配音与画面不同步通常是实际片段时长与预期时长不一致造成的。每个平台生成的视频时长都有波动不能假设“设置了 5 秒就一定是 5 秒”。通过 FFmpeg 检查每个片段的实际时长ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 clip_001.mp4拿到每个片段的实际时长后再生成或调整配音。如果配音长了可以在合成时用aresample或atempo做轻微变速。如果配音短了可以把该片段放慢 3% 到 5%但不要超过 10%否则画面会明显卡顿。6.5 FFmpeg 合成失败或音画不同步FFmpeg 最常见的合成失败原因是编码不一致。用-f concat拼接时如果某个片段的编码格式、分辨率、帧率与其他的不同会直接报错。检查所有片段的编码信息ffprobe -v error -select_streams v:0 -show_entries streamcodec_name,width,height,r_frame_rate -of defaultnoprint_wrappers1 clip_001.mp4处理方式是统一转码后再拼接不要试图直接拼接原始文件。如果音画不同步优先检查音频采样率是否统一。建议在最终合成前把所有音频统一转成 44100 Hz 或 48000 Hz AAC。7. 生产环境最佳实践7.1 三条最容易踩的坑第一个坑是把所有生成结果直接覆盖保存。AI 生成有随机性哪怕固定了 seed不同批次也可能有差异。如果覆盖了原始图片或视频想回退到之前效果好的一版就不行了。正确做法是按批次建目录例如work/run_20250101/和work/run_20250102/每次生成都写新目录。第二个坑是忽略中间产物的审核。很多开发者在脚本里把 6 个分镜全部生成完才去看图片。结果发现第 3 个分镜角色穿帮前 5 个分镜的视频成本都白花了。应该在每个环节设置“自动生成 人工抽检”的节点图片阶段发现问题只损失图片成本视频阶段发现问题会损失更多。第三个坑是提示词里没有锁定角色。一次生成看不出问题连续生成 6 个分镜后角色可能从粉色小精灵变成蓝色小动物。这在项目初期就要定义CHARACTER_DESCRIPTION和风格词并由专人维护不能散落在各个脚本里。7.2 从学习环境到生产环境的配置差异学习环境里跑通流程只需要 API Key 和代码。进入生产环境后还需要补齐以下能力维度学习环境生产环境密钥管理.env本地管理使用密钥管理服务不落盘到服务器日志print 输出结构化日志带任务 ID 和耗时任务调度同步循环用消息队列异步处理支持重试素材存储本地磁盘对象存储带版本管理成本控制手动观察配额告警、预算冻结监控无接口成功率、平均延迟、失败原因统计回滚无保留上一批产物支持快速切换生产环境尤其要注意并发控制。视频生成接口通常按并发数计费或限流不加控制地并发提交几十个任务很可能触发平台限流导致大量失败重试。7.3 可复用的产出检查清单上线前用下面的清单做一次全面检查[ ] 脚本 JSON 是否有解析失败风险是否做了 Markdown 标记清理[ ] 所有 API Key 是否通过环境变量或密钥服务加载没有硬编码[ ] 图像生成是否固定了角色描述和风格词[ ] 所有视频片段是否统一转码编码参数是否一致[ ] 旁白音频是否对齐到实际片段时长[ ] 最终视频是否在目标平台测试播放过有没有绿屏、花屏[ ] 每一批生成产物是否完整归档失败后能否快速回退[ ] 是否有成本告警单条视频的成本是否在预期范围这个清单同时适用于内容团队和开发团队。前者关注产物效果后者关注流程稳定性但两者本质上都在避免同一个问题流程跑到最后一步才发现前面的环节已经错了。8. 扩展方向8.1 从单条成片到批量生产管道跑通单条视频后可以把它改造成批量管道。核心是把脚本生成、图片生成、视频生成拆成独立任务放到任务队列里异步执行。例如用 Redis 做任务队列每一条视频的 6 个分镜可以并行提交视频生成任务全部完成后统一合成。这样一条视频的生成时间会显著缩短前提是平台允许并发并且成本可控。批量管道还需要引入“批次管理”。每一批视频有批次号每个任务记录所属批次、状态、耗时、成本。这样出现问题后可以快速定位是哪一批的哪个环节。8.2 引入“AI 审片”和人工审核节点当生成量变大后纯人工检查会成为瓶颈。初步方案是把审核拆成两层。第一层是自动化规则检查。用脚本统计分镜 JSON 字段是否完整、图片分辨率是否达标、视频时长是否在范围内、音频是否存在爆音。这些规则不依赖大模型执行成本低。第二层是用多模态大模型做内容审核检查画面是否包含不适内容、文字是否清晰、角色是否一致。多模态审核不能替代人工但可以大幅缩小人工需要查看的范围。快速变化的行业里稳妥的做法是让 AI 先筛选人只审核 AI 无法判断的样本。8.3 从短剧到 AI 智能体小镇的联动探索AI 短视频的下一步不仅是“生成更长的视频”而是“生成有逻辑的事件”。开源社区里出现过类似 AI 小镇的项目让多个大模型驱动的角色在虚拟小镇里自主行动、对话、产生社会关系。这些角色行为日志天然就是剧本素材。如果把“奇妙萌可”这样的角色放进一个 AI 小镇让角色的互动行为自动生成剧本再喂给短视频流水线就能实现“事件自动发生 - 剧本自动生成 - 视频自动成片”。这个方向还在早期工程难点在于事件日志怎么转成高质量分镜提示词以及如何避免角色行为失控。但它的想象力明显比手动写脚本大得多。对新手来说最重要的不是追求复杂的智能体联动而是先把本文这套基础流水线完整跑通。从脚本生成到 FFmpeg 合成把每一步都跑出确定性。跑通之后你会立刻明白AI 短视频真正的瓶颈不在于某个模型强不强而在于流程是否稳定、产物是否可控、出问题能不能快速定位。 AI短视频自动化生产：从分镜脚本到FFmpeg合成的完整工程链路
AI短视频在 2024 年之后已经不是概念而是能直接跑通的生产流程。以“奇妙萌可”这类卡通角色短剧为例真正要解决的问题不是“哪个工具能生成视频”而是如何把文案、分镜、画面、配音、剪辑串成一条可复现、可批量执行的流水线。很多做短视频的人尝试 AI 生成后都会卡在同一个位置单张图可以生成单段视频也能生成但把几十个片段拼成一条有剧情、有配音、有节奏的成片时流程就断了。这篇内容会按照一条完整的工程链路把“文字到成片”的每一步拆开给出可运行的示例代码、参数解释、验证方式和排错路径。适合读这篇文章的读者有两类。一类是想做 AI 动画短剧、AI 漫剧、AI 带货视频的内容创作者需要把零散工具串成工作台另一类是后端或全栈开发想理解 AI 视频生产系统的模块边界、任务调度和素材管理逻辑。学完以后你可以根据自己的业务场景把下面这套流程改造成自己的批量成片系统。1. AI短视频不是“一个工具生成全部”而是一条流水线1.1 到底什么是 AI 短视频工作流AI 短视频工作流的核心思想是“拆解”。一个 30 秒的动画短片看起来是一段连续视频实际上可以拆成脚本、分镜、画面、语音、音乐、剪辑六层产物。每一层由不同的 AI 模型或传统程序负责再通过脚本拼接成一个完整文件。为什么要拆因为当前没有哪个通用模型能一次生成“带剧情、带角色一致性、带配音、带转场”的 30 秒成片。即便有些平台支持“一句话生成视频”生成结果往往不可控时长也有限。工程化的做法是每个环节用最合适的模型把确定性交给代码把创造性交给模型。以“奇妙萌可”为例这套工作流的输入是一个主题词输出是一个 mp4 文件。中间的 JSON 脚本、PNG 分镜、片段 mp4、配音音频都是可检查、可替换的中间产物。这种做法的好处是某一环节效果不好时只需要替换该环节的工具或参数不用推翻整个流程。1.2 一条标准生产链路包含哪些环节一个最小可运行的 AI 短视频链路通常包含五个环节脚本生成用大语言模型生成分镜脚本包含镜头序号、画面描述、旁白文案、氛围要求。画面生成根据分镜画面描述生成单帧图也就是关键帧。视频生成把关键帧或画面描述转成 3 到 5 秒的动态片段。声音生成把旁白文案转成配音音频并生成或选择背景音乐。视频合成用 FFmpeg 或剪辑库把多个片段拼接、混音、转码输出最终视频。每个环节的输入输出必须是结构化、可追踪的。脚本阶段的输出是 JSON这样后续程序才能解析画面阶段的输出是 PNG 或 JPG 文件文件名要带场景编号视频阶段的输出是 mp4 片段统一编码格式声音阶段的输出是 mp3 或 wav最终合成是 mp4。这样做的好处是调试时可以定位到具体环节。比如成片里第 3 个镜头角色穿帮直接回到scene_003.png看画面是否已经出错而不是重新生成整条视频。1.3 先选路线云端 API 优先还是本地开源优先实现这条链路有两种路线选择会直接影响环境配置、硬件要求和成本。云端 API 路线的优点是部署简单、模型效果好、不需要高端 GPU。缺点是有调用成本、接口限流、素材要上传到外部平台。适合快速验证流程、内容生产量不大的团队。本地开源路线的优点是没有按次调用费用、数据不出内网、可以批量跑。缺点是需要 GPU 资源环境配置复杂模型效果调优成本高。适合有 GPU 服务器、内容生产量很大的团队。对比项云端 API 路线本地开源路线硬件要求普通开发机即可建议 NVIDIA GPU显存 8G 以上模型效果通常更好更新快依赖所选开源模型成本按调用量计费主要是硬件和电费数据安全素材会传到第三方数据不出内网上线速度快慢需要搭建推理服务适合场景验证、中小批量生产大批量、数据敏感场景本文示例以云端 API 为主因为它的主流程最容易被理解。本地路线的差异点会在第 7 章里单独说明。2. 环境准备与项目骨架2.1 运行环境与依赖在动手写代码前先把环境准备好。建议使用 Python 3.10 或更高版本因为类型标注和异步支持更完整。需要安装的依赖如下pip install requests python-dotenv pyyaml edge-tts如果要用 MoviePy 做更精细的转场或字幕可以额外安装pip install moviepy需要注意MoviePy 依赖 imageio-ffmpeg首次运行时可能会自动下载 FFmpeg 二进制文件。如果网络环境受限也可以直接使用系统安装的 FFmpeg并把 MoviePy 的配置指向本地路径。FFmpeg 是视频合成的核心工具。检查是否安装ffmpeg -version如果没有安装在 macOS 上可以用brew install ffmpeg在 Ubuntu 上可以用apt install ffmpeg在 Windows 上可以从 FFmpeg 官网下载后加入 PATH。生产环境建议固定 FFmpeg 版本避免不同版本对滤镜和编码参数的支持不一致。2.2 项目目录如何组织这里给出一个适合单人开发、也适合后续扩展的目录结构ai_short_video/ ├── .env ├── config.yaml ├── main.py ├── requirements.txt ├── work/ │ ├── scripts/ │ │ └── script_001.json │ ├── images/ │ │ ├── scene_001.png │ │ ├── scene_002.png │ │ └── scene_003.png │ ├── clips/ │ │ ├── clip_001.mp4 │ │ ├── clip_002.mp4 │ │ └── clip_003.mp4 │ ├── audio/ │ │ ├── voice.mp3 │ │ └── music.mp3 │ └── output/ │ └── final_001.mp4work目录按产物类型分目录是这条链路里最重要的工程约定。每一轮生成只往对应目录写文件文件名带场景编号这样即使某个环节失败也只需要重新生成对应文件不用从头开始。配置文件方面.env保存密钥、Base URL 等不能提交到代码仓库的信息config.yaml保存模型名称、分辨率、配音角色、语速等业务参数。2.3 通过 .env 和配置文件隔离密钥与参数先看.env文件它保存 API Key 和接口地址# .env LLM_API_KEYyour_llm_api_key IMAGE_API_KEYyour_image_api_key VIDEO_API_KEYyour_video_api_key LLM_BASE_URLhttps://api.openai.com/v1 IMAGE_BASE_URLhttps://api.your-image-service.com/v1 VIDEO_BASE_URLhttps://api.your-video-service.com/v1注意不同平台的 Base URL、模型名、鉴权方式可能不同落地前要确认你所使用的平台的接口文档。不要假设所有平台都兼容 OpenAI 格式。再看config.yaml# config.yaml llm: model: your-llm-model temperature: 0.8 max_tokens: 2048 image: model: your-image-model size: 1024x1792 seed: 42 video: model: your-video-model duration: 5 fps: 24 resolution: 1080x1920 tts: voice: zh-CN-XiaoxiaoNeural rate: 10% output: fps: 24 resolution: 1080x1920 audio_bitrate: 192k使用配置文件的目的是把“模型选择”和“代码逻辑”分离。模型迭代很快今天用的图像模型可能过两个月就不是最优选择。把模型名和参数放到配置里换模型时只需要改配置不需要改 Python 代码。3. 用 Python 实现一条“文字到成片”的自动工作流3.1 第一步用大模型生成分镜脚本分镜脚本是整个流程的地基。脚本结构直接决定后续每个环节的输入质量。创建一个script_generator.py核心代码如下import json import os import requests from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) def generate_script(topic: str, scenes: int 6) - list: prompt f 你是短视频分镜导演。请围绕主题{topic}写一个适合动画短片的脚本。 要求 1. 共{scenes}个分镜每个分镜时长控制在3到5秒。 2. 只输出JSON数组不要输出其他文字。 3. 每个分镜包含以下字段 - scene_id: 分镜序号 - image_prompt: 画面描述包含主体、动作、背景、光线、风格写给图像生成模型 - narrator_text: 旁白文案口语化适合配音 - atmosphere: 氛围描述如温馨紧张奇幻 示例格式 [ {{ scene_id: 1, image_prompt: 小萌可在森林中跳跃阳光透过树叶卡通风格明亮全身, narrator_text: 清晨萌可来到了魔法森林。, atmosphere: 温暖 }} ] headers { Authorization: fBearer {LLM_API_KEY}, Content-Type: application/json, } payload { model: os.getenv(LLM_MODEL, your-llm-model), messages: [ {role: system, content: 你是一个严谨的分镜脚本生成助手。}, {role: user, content: prompt}, ], temperature: 0.8, max_tokens: 2048, } resp requests.post(f{LLM_BASE_URL}/chat/completions, headersheaders, jsonpayload) resp.raise_for_status() content resp.json()[choices][0][message][content] # 大模型有时会输出带 json 标记的内容需要清理 if content.startswith(): content content.strip() if content.startswith(json): content content[4:] return json.loads(content) if __name__ __main__: script generate_script(奇妙萌可的魔法森林冒险, scenes6) with open(work/scripts/script_001.json, w, encodingutf-8) as f: json.dump(script, f, ensure_asciiFalse, indent2) print(json.dumps(script, ensure_asciiFalse, indent2))这段代码里有两个值得注意的点。第一提示词明确要求“只输出 JSON 数组”并且给了字段示例这能显著提高结构化输出的成功率。第二清除了可能出现的 Markdown 代码块标记避免json.loads解析失败。实际项目中如果模型支持 JSON 输出模式或函数调用优先使用官方结构化输出能力比在提示词里要求更稳定。如果模型没有结构化输出能力可以用一个简单的“截取第一个[到最后一个]”的兜底逻辑。3.2 第二步批量生成分镜画面拿到分镜 JSON 后下一步是生成图像。这个环节最容易出现角色不一致问题所以提示词里要尽量把主角的描述固定下来。创建一个image_generator.pyimport json import os import requests from dotenv import load_dotenv load_dotenv() IMAGE_API_KEY os.getenv(IMAGE_API_KEY) IMAGE_BASE_URL os.getenv(IMAGE_BASE_URL, https://api.your-image-service.com/v1) # 角色锁定描述尽量放在每个画面提示词前 CHARACTER_DESCRIPTION 一个圆滚滚的粉色小精灵戴黄色星星发卡大眼睛卡通3D风格 def build_image_prompt(scene: dict) - str: return f{CHARACTER_DESCRIPTION}。{scene[image_prompt]}。动画电影风格高细节明亮光线 def generate_image(prompt: str, output_path: str, seed: int 42, size: str 1024x1792): headers { Authorization: fBearer {IMAGE_API_KEY}, Content-Type: application/json, } payload { model: os.getenv(IMAGE_MODEL, your-image-model), prompt: prompt, size: size, seed: seed, } resp requests.post(f{IMAGE_BASE_URL}/images/generations, headersheaders, jsonpayload) resp.raise_for_status() data resp.json()[data][0] # 不同平台返回 URL 或 b64_json这里做兼容 if url in data: img_resp requests.get(data[url], timeout30) img_resp.raise_for_status() with open(output_path, wb) as f: f.write(img_resp.content) elif b64_json in data: import base64 with open(output_path, wb) as f: f.write(base64.b64decode(data[b64_json])) else: raise ValueError(未知图像返回格式) if __name__ __main__: with open(work/scripts/script_001.json, r, encodingutf-8) as f: scenes json.load(f) for scene in scenes: scene_id scene[scene_id] prompt build_image_prompt(scene) output_path fwork/images/scene_{scene_id:03d}.png generate_image(prompt, output_path, seed42) print(f已生成 {output_path})这里的核心技巧是CHARACTER_DESCRIPTION。在连续画面中角色外观描述必须一致。如果每个分镜都让模型自由发挥画面里的主角会出现完全不同的服装、发型甚至物种。推荐做法是把角色描述单独提取成常量统一拼接到每个画面提示词前。另外seed参数在部分图像模型中决定了随机噪声的初值。固定 seed 可以提高同一角色不同画面之间的稳定性但不是所有平台都支持 seed。如果不支持就要靠角色参考图或风格模型来保证一致性。3.3 第三步让静态画面变成短视频片段图像生成之后进入视频生成环节。这个环节的工具差异最大有的平台支持“图生视频”有的支持“文生视频”还有的需要提交图片 URL 后轮询任务状态。下面给出一个通用轮询示例思路是提交任务 - 获取任务 ID - 轮询查询状态 - 下载结果。具体接口字段按平台文档调整。import time import os import requests from dotenv import load_dotenv load_dotenv() VIDEO_API_KEY os.getenv(VIDEO_API_KEY) VIDEO_BASE_URL os.getenv(VIDEO_BASE_URL, https://api.your-video-service.com/v1) def submit_video_task(image_path: str, duration: int 5) - str: # 假设平台支持图片上传 with open(image_path, rb) as f: files {image: f} headers {Authorization: fBearer {VIDEO_API_KEY}} data {duration: duration} resp requests.post( f{VIDEO_BASE_URL}/videos/generations, headersheaders, filesfiles, datadata, timeout60 ) resp.raise_for_status() return resp.json()[task_id] def poll_video_task(task_id: str, interval: int 10, timeout: int 300) - str: headers {Authorization: fBearer {VIDEO_API_KEY}} start time.time() while time.time() - start timeout: resp requests.get( f{VIDEO_BASE_URL}/videos/tasks/{task_id}, headersheaders, timeout30 ) resp.raise_for_status() task resp.json() status task.get(status) if status succeeded: return task[result_url] elif status in (failed, cancelled): raise RuntimeError(f视频生成失败: {task.get(error)}) time.sleep(interval) raise TimeoutError(视频生成超时) if __name__ __main__: os.makedirs(work/clips, exist_okTrue) for scene_id in range(1, 7): image_path fwork/images/scene_{scene_id:03d}.png task_id submit_video_task(image_path, duration5) result_url poll_video_task(task_id) clip_resp requests.get(result_url, timeout60) clip_resp.raise_for_status() clip_path fwork/clips/clip_{scene_id:03d}.mp4 with open(clip_path, wb) as f: f.write(clip_resp.content) print(f已生成 {clip_path})视频生成接口大多采用异步任务模式因为单段视频生成需要几秒到几分钟。这里把轮询逻辑单独封装超时时间和轮询间隔都做成参数避免长时间阻塞。需要注意视频生成平台通常对“图片尺寸”“分辨率”“时长”有明确限制。比如部分平台只支持 768x768 或 1024x576而短视频平台更常用 1080x1920。如果输入图比例和视频生成要求不一致需要先在图像生成阶段统一尺寸或者在提交前用 FFmpeg 裁剪。3.4 第四步生成配音和背景音乐配音使用edge-tts库它调用微软在线语音合成服务支持中文自然发音并且不需要注册 API Key。生成配音的代码如下import asyncio import edge_tts async def generate_voice(text: str, output_path: str, voice: str zh-CN-XiaoxiaoNeural, rate: str 10%): communicate edge_tts.Communicate(text, voice, raterate) await communicate.save(output_path) def create_voice_for_scene(narrator_text: str, output_path: str): asyncio.run(generate_voice(narrator_text, output_path)) if __name__ __main__: scenes [ {scene_id: 1, narrator_text: 清晨萌可来到了魔法森林。}, {scene_id: 2, narrator_text: 它发现了一颗会发光的星星果实。}, ] for scene in scenes: create_voice_for_scene(scene[narrator_text], fwork/audio/voice_{scene[scene_id]:03d}.mp3)这里有个工程问题如果每个分镜单独生成配音合成时每个片段的配音时长可能与画面时长不一致。推荐做法是先生成全部画面片段再测量每个片段的实际时长然后按比例调整配音语速或者在最终合成时统一对齐。背景音乐可以用生成式音乐工具也可以从免版权音乐库选择。工程上避免让模型参与背景音乐生成因为它和旁白混音后可能出现人声相位冲突。更稳妥的做法是找一段干净的无损 BGM统一压到低音量再用 FFmpeg 混音。3.5 第五步用 FFmpeg 自动合成最终成片所有素材准备好后进入合成阶段。直接用-f concat拼接的前提是所有视频片段编码参数一致。不同平台的视频输出编码不一定相同因此建议先统一转码再拼接最后混音。创建一个compose.sh脚本#!/bin/bash set -e WORK_DIRwork OUTPUT_DIR$WORK_DIR/output mkdir -p $OUTPUT_DIR # 第一步统一转码所有片段 for f in $WORK_DIR/clips/clip_*.mp4; do name$(basename $f) ffmpeg -y -i $f \ -c:v libx264 -preset medium -crf 18 \ -c:a aac -b:a 192k \ -pix_fmt yuv420p \ $WORK_DIR/clips/transcoded_$name done # 第二步生成拼接列表 : $WORK_DIR/videolist.txt for f in $WORK_DIR/clips/transcoded_clip_*.mp4; do echo file $PWD/$f $WORK_DIR/videolist.txt done # 第三步拼接视频 ffmpeg -y -f concat -safe 0 -i $WORK_DIR/videolist.txt -c copy $WORK_DIR/concat.mp4 # 第四步合并所有旁白音频 ffmpeg -y -i $WORK_DIR/concat.mp4 -i $WORK_DIR/audio/voice.mp3 \ -filter_complex [1:a]volume1.0[voice] \ -map 0:v -map [voice] \ -c:v copy -c:a aac -shortest \ $OUTPUT_DIR/final_001.mp4 echo 合成完成: $OUTPUT_DIR/final_001.mp4转码时选择libx264和yuv420p是兼容性最稳妥的组合。yuv420p能保证视频在多数播放器和短视频平台上正常显示不会出现绿屏或无法播放的问题。如果所有片段的旁白是分开的文件需要先把多个配音按顺序拼接成一个长音频。可以用 FFmpeg 的concat过滤器也可以通过 Python 的pydub拼接。这里需要注意每个配音文件之间是否需要留 300 到 500 毫秒的空隙避免听起来过于急促。4. 关键参数详解与画面一致性调优4.1 大模型生成脚本时的参数选择脚本生成阶段的参数影响的是创意质量而不是格式稳定性。最常调整的参数是temperature和max_tokens。temperature控制模型输出的随机性。取值越低输出越保守、越稳定取值越高输出越有创意但也越容易出现结构混乱。生成分镜脚本时推荐设置在 0.7 到 0.9 之间。如果发现脚本经常格式不规范、字段缺失调低到 0.5 左右更稳妥。max_tokens决定输出长度上限。6 个分镜的 JSON 脚本每个分镜的image_prompt和narrator_text加起来大约 100 到 200 个 token总脚本可能需要 1500 到 2500 个 token。设置 2048 比较常见如果脚本内容多需要调整到 4096。参数默认建议调低影响调高影响temperature0.8更稳定但可能缺乏创意更发散但可能结构混乱max_tokens2048输出可能被截断可生成更多分镜但耗时增加top_p1.0输出更集中输出更多样4.2 图生视频与文生视频的参数差异图生视频是指定一张起始图片让模型根据图片内容生成后续动态文生视频是只给文字描述让模型从空白画面开始生成。在动漫短剧场景里图生视频明显更可控因为角色外观已经被图片锁住。视频生成的几个关键参数duration单片段时长。3 到 5 秒是短视频常见选择过短会导致画面信息不够过长会增加生成失败率和成本。fps帧率。24 fps 足够用于短视频平台30 fps 更流畅但生成时间更长。多数平台限制帧率无需过度追求。resolution分辨率。优先与发布平台保持一致抖音、快手常用 1080x1920 竖屏B 站横屏常用 1920x1080。seed部分平台支持固定 seed 可以稳定生成风格。图生视频时输入图片的质量直接决定输出质量。图片分辨率过低、比例不对、画面主体过小都会导致生成结果抖动严重。建议在图像生成时就直接输出最终视频需要的比例不要在视频环节再裁剪裁剪会损失信息。4.3 角色一致性AI 短片最需要优先解决的问题角色一致性是 AI 动画短视频里最难解决的问题也是“奇妙萌可”这类固定角色项目的核心痛点。一个角色的形象在每个分镜中都要一致否则观众一眼就会出戏。目前常见的解决方案有三种提示词锁定法在每个画面提示词前固定角色描述。优点是简单缺点是不够精确尤其在复杂场景中容易失效。参考图法部分平台支持上传角色参考图生成时参考该图保持角色一致。效果最好但依赖平台能力。模型微调法用角色图片集微调图像模型让模型学会生成该角色。效果最稳定但训练成本和门槛高。按工程优先级先用提示词锁定再尝试参考图最后才考虑微调。不要一开始就训练模型因为角色设定可能还在频繁调整训练一次的成本不低。5. 运行验证与成片检查5.1 最小验证流程先跑通再调效果第一次跑通流程时不要一上来就生成 6 个分镜、每段 5 秒。建议先用 2 个分镜、每段 3 秒把整条链路跑通。验证链路本身就足够脚本能生成、图片能保存、视频任务能提交、配音能落地、FFmpeg 能合成。跑通之后再逐步加参数。每加一个环节先确认上一环节的产物是否正确。最小验证命令# 1. 生成 2 个分镜脚本 python script_generator.py # 2. 生成 2 张分镜图 python image_generator.py # 3. 生成 2 段视频 python video_generator.py # 4. 生成配音 python tts_generator.py # 5. 合成最终视频 bash compose.sh运行过程中任何一步报错都先看它依赖的输入文件是否存在。比如视频生成失败先确认图片是否 200 可读尺寸是否合规。5.2 分步产物检查清单为了快速定位问题每步产物都要做“可检查项”。下面的检查清单可以直接复用步骤检查项合格标准脚本生成JSON 能否解析字段完整无缺失脚本生成分镜数量与预期一致画面生成图片是否可打开无损坏文件画面生成角色描述是否连续多张图主体一致视频生成片段时长与设定时长接近视频生成播放是否流畅无严重卡顿、抽帧配音生成音频时长与画面时长差异在 1 秒内配音生成听感无吞字、爆音最终合成音画是否同步旁白与画面内容对应最终合成是否可以播放无绿屏、无花屏这个清单在批量生产时尤其重要。如果第 3 个分镜在画面生成阶段就出现了角色不一致那后面所有步骤都不用继续做直接回去重新生成第 3 个分镜可以节省大量视频生成费用。5.3 成片合格标准怎么定成片合格不只是“能播放”。对于“奇妙萌可”这类短剧至少要满足三条标准第一剧情能看懂。旁白和画面表达的是同一个事件不能画面在森林里旁白却在讲城市。第二角色连续。主角的样子在第 1 秒和第 29 秒必须一致。第三节奏不拖沓。单镜头停留时间不宜超过 5 秒否则观众容易流失。内容创作者可以把这三条标准写到脚本生成提示词里让模型在生成分镜时就避免“一镜到底”的写法。开发者则可以把这些标准抽象成自动化检查规则比如统计每个分镜的画面主体相似度、旁白文本和image_prompt的主题语义相似度。6. 常见问题排查6.1 接口报错、超时和限流在接入任何 AI 接口时最先碰到的问题就是请求失败。常见现象和排查方式如下问题现象可能原因检查方式处理建议401 UnauthorizedAPI Key 错误或已过期检查.env中的 Key 是否匹配重新生成 Key确认环境变量加载正确429 Too Many Requests超出配额或并发限制查看平台控制台配额降低并发增加重试和退避500 或 503平台服务异常查看平台状态页等待后重试做好失败重试请求超时网络不稳定或生成耗时过长打印请求耗时日志增大超时时间转异步任务建议所有接口调用统一封装重试逻辑。用 Python 的tenacity库可以简化实现from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type import requests retry( stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max30), retryretry_if_exception_type((requests.exceptions.Timeout, requests.exceptions.HTTPError)) ) def call_api_with_retry(url, **kwargs): resp requests.post(url, **kwargs) resp.raise_for_status() return resp.json()注意retry只对临时性问题有效。如果返回的是 400 参数错误、401 鉴权错误重试只会浪费配额应该在抛出前做类型判断。6.2 生成图像出现手指、文字和比例异常图像生成模型在生成手部、文字和复杂图案时仍容易出错。这种现象在卡通风格中相对少见但也可能出现。处理方式有三种局部重绘在支持局部重绘的平台上用蒙版遮住异常区域重新生成。修改提示词把“手”相关的描述去掉改用“双手放在身后”这类规避描述。换图重生成成本最低重新换一个 seed 生成。生成图片里出现乱码文字时检查image_prompt是否要求了“不要文字”。可以在提示词末尾追加“无文字无水印无标志”来降低概率。但这不是绝对最重要的是把生成结果纳入人工检查环节不要让异常图片直接进入视频生成。6.3 拼接后转场生硬、画面闪烁多个 AI 生成的片段直接拼在一起容易出现两种问题。一种是画面没有任何转场看起来像幻灯片另一种是相邻两段画面的光线、色调差异很大产生闪烁感。解决方案是引入转场。最简单的是给每个片段头部和尾部做 0.3 秒的淡入淡出ffmpeg -i input.mp4 -vf fadetin:st0:d0.3,fadetout:st4.4:d0.3 -c:v libx264 -crf 18 output.mp4更进一步的方案是在图像生成阶段要求“镜头衔接”即在当前分镜的image_prompt里补充上一分镜的结束画面要素。这会显著提高相邻镜头的连贯性。6.4 配音对不上画面、音频缺失配音与画面不同步通常是实际片段时长与预期时长不一致造成的。每个平台生成的视频时长都有波动不能假设“设置了 5 秒就一定是 5 秒”。通过 FFmpeg 检查每个片段的实际时长ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 clip_001.mp4拿到每个片段的实际时长后再生成或调整配音。如果配音长了可以在合成时用aresample或atempo做轻微变速。如果配音短了可以把该片段放慢 3% 到 5%但不要超过 10%否则画面会明显卡顿。6.5 FFmpeg 合成失败或音画不同步FFmpeg 最常见的合成失败原因是编码不一致。用-f concat拼接时如果某个片段的编码格式、分辨率、帧率与其他的不同会直接报错。检查所有片段的编码信息ffprobe -v error -select_streams v:0 -show_entries streamcodec_name,width,height,r_frame_rate -of defaultnoprint_wrappers1 clip_001.mp4处理方式是统一转码后再拼接不要试图直接拼接原始文件。如果音画不同步优先检查音频采样率是否统一。建议在最终合成前把所有音频统一转成 44100 Hz 或 48000 Hz AAC。7. 生产环境最佳实践7.1 三条最容易踩的坑第一个坑是把所有生成结果直接覆盖保存。AI 生成有随机性哪怕固定了 seed不同批次也可能有差异。如果覆盖了原始图片或视频想回退到之前效果好的一版就不行了。正确做法是按批次建目录例如work/run_20250101/和work/run_20250102/每次生成都写新目录。第二个坑是忽略中间产物的审核。很多开发者在脚本里把 6 个分镜全部生成完才去看图片。结果发现第 3 个分镜角色穿帮前 5 个分镜的视频成本都白花了。应该在每个环节设置“自动生成 人工抽检”的节点图片阶段发现问题只损失图片成本视频阶段发现问题会损失更多。第三个坑是提示词里没有锁定角色。一次生成看不出问题连续生成 6 个分镜后角色可能从粉色小精灵变成蓝色小动物。这在项目初期就要定义CHARACTER_DESCRIPTION和风格词并由专人维护不能散落在各个脚本里。7.2 从学习环境到生产环境的配置差异学习环境里跑通流程只需要 API Key 和代码。进入生产环境后还需要补齐以下能力维度学习环境生产环境密钥管理.env本地管理使用密钥管理服务不落盘到服务器日志print 输出结构化日志带任务 ID 和耗时任务调度同步循环用消息队列异步处理支持重试素材存储本地磁盘对象存储带版本管理成本控制手动观察配额告警、预算冻结监控无接口成功率、平均延迟、失败原因统计回滚无保留上一批产物支持快速切换生产环境尤其要注意并发控制。视频生成接口通常按并发数计费或限流不加控制地并发提交几十个任务很可能触发平台限流导致大量失败重试。7.3 可复用的产出检查清单上线前用下面的清单做一次全面检查[ ] 脚本 JSON 是否有解析失败风险是否做了 Markdown 标记清理[ ] 所有 API Key 是否通过环境变量或密钥服务加载没有硬编码[ ] 图像生成是否固定了角色描述和风格词[ ] 所有视频片段是否统一转码编码参数是否一致[ ] 旁白音频是否对齐到实际片段时长[ ] 最终视频是否在目标平台测试播放过有没有绿屏、花屏[ ] 每一批生成产物是否完整归档失败后能否快速回退[ ] 是否有成本告警单条视频的成本是否在预期范围这个清单同时适用于内容团队和开发团队。前者关注产物效果后者关注流程稳定性但两者本质上都在避免同一个问题流程跑到最后一步才发现前面的环节已经错了。8. 扩展方向8.1 从单条成片到批量生产管道跑通单条视频后可以把它改造成批量管道。核心是把脚本生成、图片生成、视频生成拆成独立任务放到任务队列里异步执行。例如用 Redis 做任务队列每一条视频的 6 个分镜可以并行提交视频生成任务全部完成后统一合成。这样一条视频的生成时间会显著缩短前提是平台允许并发并且成本可控。批量管道还需要引入“批次管理”。每一批视频有批次号每个任务记录所属批次、状态、耗时、成本。这样出现问题后可以快速定位是哪一批的哪个环节。8.2 引入“AI 审片”和人工审核节点当生成量变大后纯人工检查会成为瓶颈。初步方案是把审核拆成两层。第一层是自动化规则检查。用脚本统计分镜 JSON 字段是否完整、图片分辨率是否达标、视频时长是否在范围内、音频是否存在爆音。这些规则不依赖大模型执行成本低。第二层是用多模态大模型做内容审核检查画面是否包含不适内容、文字是否清晰、角色是否一致。多模态审核不能替代人工但可以大幅缩小人工需要查看的范围。快速变化的行业里稳妥的做法是让 AI 先筛选人只审核 AI 无法判断的样本。8.3 从短剧到 AI 智能体小镇的联动探索AI 短视频的下一步不仅是“生成更长的视频”而是“生成有逻辑的事件”。开源社区里出现过类似 AI 小镇的项目让多个大模型驱动的角色在虚拟小镇里自主行动、对话、产生社会关系。这些角色行为日志天然就是剧本素材。如果把“奇妙萌可”这样的角色放进一个 AI 小镇让角色的互动行为自动生成剧本再喂给短视频流水线就能实现“事件自动发生 - 剧本自动生成 - 视频自动成片”。这个方向还在早期工程难点在于事件日志怎么转成高质量分镜提示词以及如何避免角色行为失控。但它的想象力明显比手动写脚本大得多。对新手来说最重要的不是追求复杂的智能体联动而是先把本文这套基础流水线完整跑通。从脚本生成到 FFmpeg 合成把每一步都跑出确定性。跑通之后你会立刻明白AI 短视频真正的瓶颈不在于某个模型强不强而在于流程是否稳定、产物是否可控、出问题能不能快速定位。