从零搭建AI视频生产链路：文案、分镜、合成全流程实战

AI 视频相关的词条，几乎每天都会出现在热搜和技术社区的讨论里。有人关心文生视频模型的效果，有人关注 AI Agent 能不能自动完成内容生产，也有人把生成一段视频当成快速变现的入口。工具确实在快速迭代，但市面上的教程大多停留在单点演示：怎么生成一张图、怎么生成一段视频、怎么配音，却很少讲清楚这些步骤如何串成一条可持续运行的生产链路。对内容创作者和应用开发者来说，真正有价值的不是某个模型的新奇效果，而是把文案、分镜、画面生成、配音、字幕、合成、审核串成一条可复用的流水线。

这篇文章就以“AI 视频生产链路”为主线，从零搭建一条最小可运行的 AI 视频制作流程。你会看到完整的目录结构、脚本设计思路、分镜 JSON 数据格式、提示词模板、FFmpeg 合成命令，以及发布前需要检查的合规要点。学完之后，你可以在自己的电脑或服务器上跑通从文案到成片的完整过程，并且根据实际项目扩展成更复杂的自动化工序。本文不讨论任何“短期内保证收益”的说法，只讨论一个更可控的问题：如何让一条 AI 视频从选题、到素材、再到成片，变得稳定、可复现、可迭代。

1. 先拆清楚 AI 视频生产流程的技术边界

1.1 一个可以复现的 AI 视频流水线

很多教程把 AI 视频讲得很神秘，好像只要输入一句话就能得到成片。真实情况是，主流工作流通常包含六个环节：文案脚本、分镜拆解、视觉素材生成、语音合成、字幕对齐、视频合成。任何一环靠手工做，都会消耗大量时间；任何一环完全自动化，又会导致画面和文案脱节。所以正确做法是先定义流程，再逐步提高每一环的自动化程度。

一个最小可运行的流水线可以这样划分：

1. 写作文案脚本。
2. 把文案拆成若干镜头，每个镜头包含画面描述、运镜方式、配音文本和时长。
3. 根据画面描述生成静态图片，必要时先出图，再做图生视频。
4. 根据配音文本合成语音。
5. 把配音切分成与镜头对应的片段，并生成字幕。
6. 用 FFmpeg 或者其他剪辑工具把画面、配音、字幕合成为成片。

这个流程的核心思想是把“一段长视频”拆成“一组短视频片段”。每一段都是独立生成、独立检查、独立替换。这样做的原因是：生成式模型的输出带有随机性，一次性让模型生成整段视频，失败后需要全部重来；拆成小片段后，哪个镜头有问题就只处理哪个镜头，排错成本会低很多。

1.2 拆解“普通人做 AI 视频”里的技术分工

“普通人”这个词容易让人误解。做 AI 视频并不需要从零训练模型，但也需要掌握几种基本功：

• 提示词设计能力：能写清楚画面主体、风格、光线、镜头语言和负面提示词。
• 基础脚本能力：至少能用 Python 或 Shell 批量调用接口、处理 JSON 文件、调用 FFmpeg。
• 数据组织能力：分镜、素材、字幕、音频文件需要规范的命名和目录管理。
• 内容判断能力：哪些文字和画面不能生成、哪些素材不能商用、哪些平台规则需要注意。
• 排错能力：能根据日志、输出文件、耗时和成本判断问题出在哪一环。

从技术岗位来看，这和 AI 应用开发有很强的重叠。现代 AI 应用开发不只是在写一个模型接口的调用，而是在设计输入输出结构、缓存策略、任务队列、失败重试和内容审核。AI 视频流水线本质上就是一个多模型应用系统：大模型负责生成文案，文生图模型负责画面，图生视频模型负责动态效果，TTS 负责配音，FFmpeg 负责合成。如果进一步封装成服务，它就已经具备 AI Agent 或 AI Infra 的雏形了。

1.3 工具选型：质量、成本、可控性三者怎么平衡

AI 视频工具链没有唯一的正确答案。选型时主要权衡三个指标：生成质量、单条成本、可控程度。

在项目起步阶段，不建议直接追求本地部署文生视频模型。视频生成模型对显存和推理时延要求很高，个人机器很难稳定跑大批量任务。更稳妥的做法是：先用可申请的 API 跑通流程，把数据结构和流程验证好，再决定哪些环节值得本地化。这就像做后端开发时先画清楚接口，再决定哪些模块用自研服务，而不是一开始就重造基础组件。

注意：不同服务商对 API 字段、限流、内容审核规则差异很大。下面的示例请求只用于说明思路，实际接入时必须以服务商文档为准。

2. 搭建最小可复用的 AI 视频生成环境

2.1 学习环境和生产环境的差异

学习环境的目标是快速跑通。你可以用示例代码、少量素材和在线服务免费额度完成验证。生产环境的目标是稳定产出，需要额外考虑：任务失败重试、API 调用频率限制、费用监控、素材备份、内容审核、权限管理。很多人在本地跑通一次之后就以为已经完成了，其实那只是最小验证。

这两类环境对目录结构、配置管理、日志设计的要求也不一样。

第一步不需要这些全部实现，但目录结构最好一开始就按可扩展的方式设计。否则后面生成几百个文件时，文件名会乱到无法排查。

2.2 依赖与项目目录

推荐使用 Python 3.10 以上版本。不同系统环境下，Python 的安装方式不同，这里略过。项目依赖不建议一次性装很多库，按需安装即可。最核心的是requests（调用 HTTP 接口）、pyyaml（读取配置文件）、以及本机已经安装好的 FFmpeg。如果你需要用脚本生成字幕或者处理时间轴，再考虑pysrt之类的小工具。

FFmpeg 是视频合成的核心工具，几乎绕不开。安装完成后，在命令行执行：

ffmpeg -version

如果输出版本信息，说明 FFmpeg 可用。接下来创建项目目录：

ai-video-pipeline/ ├── config/ │ └── settings.yaml ├── scripts/ │ ├── generate_storyboard.py │ ├── generate_image.py │ ├── generate_video.py │ ├── generate_tts.py │ └── compose.py ├── storyboards/ ├── assets/ │ ├── images/ │ ├── videos/ │ └── audio/ ├── subtitles/ └── output/

这个目录结构有一个明显好处：每一类产物都有固定位置。分镜文件放在storyboards，原始图片放在assets/images，生成的视频片段放在assets/videos，音频放在assets/audio，字幕放在subtitles，最终成片统一放到output。这样即使流程跑了几百次，也能按路径快速定位是哪一步产生的文件。

2.3 环境验证脚本

在写正式流程前，建议先做一个简单的验证脚本。它不调用任何真实生成模型，只检查当前目录结构、FFmpeg 版本、配置文件和密钥占位符是否存在。这一步能在项目早期暴露环境问题，而不是等生成图片时才发现依赖缺失。

看一个简化示例，保存为scripts/check_env.py：

import os import sys import subprocess import yaml REQUIRED_DIRS = [ "config", "storyboards", "assets/images", "assets/videos", "assets/audio", "subtitles", "output", ] def main(): # 1. 检查目录结构 for d in REQUIRED_DIRS: os.makedirs(d, exist_ok=True) # 2. 检查 ffmpeg try: result = subprocess.run( ["ffmpeg", "-version"], capture_output=True, text=True, ) if result.returncode == 0: print("ffmpeg ok:", result.stdout.splitlines()[0]) else: print("ffmpeg error") except FileNotFoundError: print("ffmpeg not found") sys.exit(1) # 3. 检查配置文件 if os.path.exists("config/settings.yaml"): with open("config/settings.yaml", "r", encoding="utf-8") as f: settings = yaml.safe_load(f) if not settings.get("api", {}).get("key"): print("warning: api key is empty") else: print("config file missing") sys.exit(1) print("env check done") if __name__ == "__main__": main()

关键点有两处：目录检查用os.makedirs(..., exist_ok=True)而不是手动判断，这样脚本可以反复执行；FFmpeg 检查用子进程调用而不是直接依赖 Python 包，因为 FFmpeg 本身不是 Python 库。配置文件里如果缺少 API Key，程序仍能启动，但会在日志中明确提示，避免后续接口调用时出现让人困惑的鉴权错误。

3. 从文案到分镜：用提示词工程控制生成结果

3.1 文案脚本的模块化结构

生成式视频的最大问题是“提示词写得太含糊”。如果用一句话描述整段视频，模型只能生成一个泛化的画面，无法和具体文案对应。正确做法是先写文案，再按镜头拆分。

一段短视频文案可以拆成多个叙事块，每个叙事块对应一个或多个镜头。例如：

开场：提出问题 很多人以为 AI 视频只是把一段文字变成画面。 冲突：点出难度 真正麻烦的是画面一致性、镜头衔接和内容是否过审。 转折：给出方案 把长视频拆成小镜头，逐个生成，再组合起来。 结尾：总结 流程稳定之后，剩下的就是持续迭代。

这里的每个叙事块都可以成为一个分镜单元。不要把一个超过 20 字的句子硬塞给视频模型，模型很难同时处理复杂动作、场景变化和角色情绪。叙事块越小，后续生成越可控。

3.2 分镜 JSON 的数据结构

分镜是整个流水线的中间层。它既要从文案生成，又要驱动图片、视频、TTS 和字幕生成。如果这里的数据结构设计得不完整，后面每个环节都要返工。

建议使用 JSON 保存分镜数据，基本结构如下：

[ { "scene_id": 1, "duration": 5, "narration": "很多人以为 AI 视频只是把一段文字变成画面。", "character": "穿深色外套的普通上班族", "scene": "城市清晨，办公楼外部", "action": "站在路边抬头看大楼", "camera": "远景，缓慢推进", "style": "写实电影感", "lighting": "自然晨光", "negative_prompt": "lowres, bad anatomy, extra fingers, watermark, text", "image_prompt": "cinematic wide shot, an ordinary office worker in a dark coat, standing on the street, looking up at a building, city morning, natural light, realistic style", "video_prompt": "the camera slowly pushes in, the character raises his head slightly, wind blows across the street, subtle motion, cinematic" } ]

注意这个结构里的字段设计：narration用于配音，image_prompt用于文生图，video_prompt用于图生视频或文生视频，negative_prompt用于排除常见画面问题。每个字段都有明确的下游消费者，不会出现“生成画面时不知道该用哪个字段”的混乱。

3.3 提示词模板与变量注入

提示词不建议直接写死在代码里，因为不同模型对提示词格式的敏感度不同。把模板和变量分开，后续调整会方便得多。

以 Python 为例，可以维护一个提示词模板字典：

PROMPT_TEMPLATE = { "image": ( "cinematic {style}, {camera}, {character}, {scene}, " "{action}, {lighting}, high quality" ), "video": ( "{motion}, {camera_motion}, consistent character, " "smooth transition, detailed texture" ), } def build_prompt(scene, template_name): values = { "style": scene["style"], "camera": scene["camera"], "character": scene["character"], "scene": scene["scene"], "action": scene["action"], "lighting": scene["lighting"], "motion": scene.get("motion", "subtle natural motion"), "camera_motion": scene.get("camera_motion", "stationary shot"), } return PROMPT_TEMPLATE[template_name].format(**values)

这里最关键的是把容易变化的要素拆出来，比如角色、场景、动作。如果生成结果中角色外貌不稳定，重点调整character字段，而不是重写整段提示词。后续做批量测试时，也可以用这些字段做组合实验，而不是手工复制粘贴。

3.4 用脚本批量生成分镜文件

当文案和模板都准备好之后，可以用脚本把文案拆成分镜。需要一个基础映射关系：每段文案对应一个镜头；每个镜头使用指定的叙事文本；时间为默认时长。

示例脚本scripts/generate_storyboard.py：

import json NARRATION_BLOCKS = [ { "narration": "很多人以为 AI 视频只是把一段文字变成画面。", "scene": "城市清晨，办公楼外部", "character": "穿深色外套的普通上班族", "action": "站在路边抬头看大楼", "camera": "远景，缓慢推进", "duration": 5, }, { "narration": "真正麻烦的是画面一致性、镜头衔接和内容审核。", "scene": "电脑桌面，剪辑软件界面", "character": "同一名上班族", "action": "坐在电脑前皱眉查看视频片段", "camera": "中景，越肩视角", "duration": 4, }, ] def default_prompt(scene): return ( f"cinematic {scene['camera']}, {scene['character']}, " f"{scene['scene']}, {scene['action']}, realistic, high quality" ) def build_storyboards(): storyboards = [] for index, block in enumerate(NARRATION_BLOCKS, start=1): storyboards.append({ "scene_id": index, "duration": block.get("duration", 5), "narration": block["narration"], "character": block["character"], "scene": block["scene"], "action": block["action"], "camera": block["camera"], "style": "写实电影感", "lighting": "自然光", "image_prompt": default_prompt(block), "video_prompt": "subtle motion, consistent character, camera slowly moving, cinematic", "negative_prompt": "lowres, watermark, text, extra fingers, bad anatomy", }) return storyboards if __name__ == "__main__": data = build_storyboards() with open("storyboards/script_001.json", "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) print("storyboard saved, scenes:", len(data))

这个脚本只是把样例文案转为结构化分镜。在实际项目中，NARRATION_BLOCKS可以由大模型生成，也可以从稿件管理平台导出。无论来源是什么，只要最终落到统一的 JSON 结构里，后续环节就不用改动。

4. 把分镜变成素材：图片生成、视频生成与一致性控制

4.1 文生图与图生视频的基本调用方式

生成视频素材通常有两种路径：直接文本生成视频，或者先生成图片再做图生视频。直接文生视频的优点是动作设计空间大，缺点是不好控制首帧构图和角色外貌。图生视频的优点是首帧可控，角色和场景的可控性更高，代价是动态范围可能偏小。

在工程实践中，更推荐“文生图 + 图生视频”组合。先用文本生成模型输出一张高清晰度图片，再把它作为视频模型的首帧输入。示例接口调用如下，接口地址和字段名以实际服务商文档为准：

curl -X POST https://api.example.com/v1/images/generations \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "prompt": "cinematic wide shot, an office worker in dark coat standing on the street, city morning, natural light, realistic", "negative_prompt": "lowres, watermark, text, extra fingers", "resolution": "1280x720", "num_images": 1 }'

拿到首帧图片后，再调用视频生成服务：

curl -X POST https://api.example.com/v1/videos \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "prompt": "camera slowly pushes in, character raises head slightly, wind blows, cinematic", "image_url": "https://your-bucket.oss.example.com/images/scene_001.png", "duration": 5, "resolution": "1280x720", "fps": 24 }'

很多时候视频生成服务要求输入图片为公网 URL，因此本地生成的图片需要先上传到对象存储，再传给视频模型。这一步在设计字段时就要考虑：分镜 JSON 里最好预留image_path和image_url两个字段，前者用于本地调试，后者用于接口请求。

4.2 关键参数说明与推荐设置

不同模型对参数的支持范围不同，但下面几个参数几乎都会出现，理解它们的含义有助于排错。

在批量生产时，务必思考参数对单条成本的影响。steps从 30 调到 50，体验上不一定有可见提升，但需要等待的时间会明显增加。建议先生成几张测试图，记录不同步数下的画面和耗时，再确认生产参数。

4.3 控制角色与风格一致性的常用做法

AI 视频最常见的败笔不是画面模糊，而是同一个角色在几个镜头里长得不一样。这个问题无法用一个模型参数彻底解决，必须组合多种手段。

第一，固定角色描述。不要在不同镜头里写“一个年轻人”“一个男生”“一个穿衣服的男子”，而是统一写“28 岁亚洲男性，黑色短发，穿深灰色连帽卫衣”，并且角色描述在每次生成时保持一致。

第二，使用参考图。很多绘图服务支持image或reference_image字段，把第一个镜头的角色图作为后续镜头的参考。视频生成服务通常也支持把首帧图作为一致性锚点。

第三，固定风格后缀。把风格关键词做成固定后缀，例如始终追加cinematic, realistic, natural lighting, high detail，减少模型在风格上的随机漂移。

第四，使用种子值。如果绘图服务支持seed，在批量生成时固定同一个种子，再叠加同一套提示词，输出画面的风格会稳定不少。这只是一种工程手段，并不能保证百分之百一致。

4.4 生成失败与内容异常的排查

素材生成本身就可能失败。常见现象是：接口返回 200，但图片内容不符合预期；接口返回 400，提示字段缺失；视频生成后画面闪烁或有形变。

处理顺序是：先确认请求参数是否符合服务商文档，再对比提示词是否足够具体，最后看内容是否命中模型自身的安全策略。很多时候生成失败不是代码 bug，而是提示词写了模型不允许生成的内容。这类错误需要调整文案，而不是改代码。

推荐为每个镜头记录生成日志，至少包含：分镜 ID、请求时间、接口地址、参数摘要、结果文件路径、耗时和失败原因。这样即使某天批量跑了 100 个镜头，也能快速定位失败集中在哪个环节。

5. 配音、字幕与自动剪辑：把素材拼成成片

5.1 文本转语音与音色选择

视频画面生成之后，下一步是配音。文本转语音服务通常接收纯文本或带 SSML 标注的文本，输出音频文件。选择音色时需要注意语速和重音，AI 语音如果语速过快，观众很难跟上字幕；语速过慢又会拖慢节奏。

TTS 的输入直接使用分镜 JSON 中的narration字段。每个镜头生成一个独立音频片段，这样后续可以按镜头对齐音频和视频。

示例：

curl -X POST https://api.example.com/v1/audio/speech \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "input": "很多人以为 AI 视频只是把一段文字变成画面。", "voice": "zh-CN-XiaoxiaoNeural", "speed": 1.0, "output_format": "mp3" }' \ --output assets/audio/scene_001.mp3

在工程中，需要注意音频文件的实际时长。因为语速不同，5 秒的画面可能配上 4 秒或 6 秒的配音。字幕和画面拼接时都要以音频的实际时长为基准，而不是以分镜里预设的duration为准。

5.2 字幕文件生成与时间轴对齐

字幕不是简单地把文案写进文件，而是要计算出每句话出现的起止时间。最简单的做法是按顺序累计音频时长。假设第一段音频时长 4.2 秒，第二段 3.8 秒，那第一段字幕从 0 开始到 4.2 秒，第二段从 4.2 秒开始到 8.0 秒。

示例 SRT 文件：

1 00:00:00,000 --> 00:00:04,200 很多人以为 AI 视频只是把一段文字变成画面。 2 00:00:04,200 --> 00:00:08,000 真正麻烦的是画面一致性、镜头衔接和内容审核。

注意 SRT 的时间格式是小时:分钟:秒,毫秒，毫秒是三位数。用 Python 生成时，要补零格式化，否则播放器可能解析失败。

5.3 用 FFmpeg 完成自动合成

拿到每个镜头的视频文件和对应的音频文件后，先用 FFmpeg 把每一组画面和配音合并成一个片段，再拼接所有片段。

单个镜头合成：

ffmpeg -y \ -i assets/videos/scene_001.mp4 \ -i assets/audio/scene_001.mp3 \ -c:v libx264 -c:a aac \ -shortest \ output/scene_001.mp4

-shortest表示输出时长以较短的输入流为准，避免音频结束后画面还在继续，或者画面结束后音频还在播放。

把多个镜头拼接成成片时，先创建一个文件列表：

file 'output/scene_001.mp4' file 'output/scene_002.mp4' file 'output/scene_003.mp4'

然后执行拼接：

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

-c copy表示不做重新编码，速度快很多。但前提是所有片段的编码参数一致，如果分辨率、帧率、像素格式不同，拼接时会出现错误或不流畅。稳妥做法是先统一规格，再执行拼接。

烧录字幕：

ffmpeg -y -i output/final.mp4 -vf "subtitles=subtitles/final.srt" -c:a copy output/final_with_sub.mp4

烧录字幕相当于把文字画进画面，输出后的字幕无法关闭。如果追求可切换字幕，就不要烧录，而是单独生成外挂字幕文件。国内主流短视频平台一般建议直接烧录，保证所有设备都能看到，但长视频平台更推荐外挂字幕，便于多语言版本复用。

5.4 成片校验指标

成片生成后，不能只看一眼能不能播放就认为完成。建议做这几项检查：

这里推荐把ffprobe集成到脚本里。它不需要人工打开播放器，就能快速判断文件是否损坏、编码和时长是否符合预期。

6. 内容合规与发布前检查：AI 视频最容易忽略的部分

6.1 内容安全自查

AI 生成内容不能只是“能生成”就发布。任何平台都有自己的内容规则，而且在生成式内容出现之后，平台对来源标识、真实人物、版权素材、违规内容的要求在不断提高。作为技术博客，这里不讨论具体平台内部审核策略，只给出通用检查思路。

发布前要自查以下风险：

• 是否使用或模仿真实人物形象，包括人名、肖像、声音。未经授权的内容存在侵权和误导风险。
• 是否涉及他人的商标、Logo、产品外观。
• 是否伪造新闻事件、专家观点或公共信息。AI 生成的“新闻播报”如果没有真实来源，很容易被判定为虚假信息。
• 是否包含敏感行业、医疗健康、金融理财等领域的绝对化表述。
• 是否已经按照平台要求标注“AI 生成”或“AI 辅助创作”。

注意：AI 生成的视频并不等于“免责内容”。模型生成的结果如果涉及真实人物或受版权保护的素材，发布者同样需要承担责任。合规检查必须放在自动化流程里，而不是发布后才发现问题。

6.2 平台合规与素材权益

很多 AI 视频项目会配背景音乐。从版权角度考虑，不要直接使用来路不明的音乐文件。如果用的是音效库或平台自带音乐库，要保留授权信息。AI 生成的图案、字体、声音素材也要确认是否允许商用。有些模型服务平台明确说明生成内容可以商用，有些则限制使用范围。这个信息要提前查清楚，不能等流量起来之后才发现素材本身存在问题。

内容平台对重复内容也有策略。完全相同的画面和文案反复发布，会被判定为低质重复内容。即使生成过程使用了 AI，也不能把“批量生成”理解为“批量复制”。合理做法是在同一套生产链路中，变化文案、画面和结构，保持分镜的独特性。

6.3 发布前检查清单

将以下清单固定到流程中，每次发布前逐项确认：

1. 成片时长是否适配目标平台。
2. 分辨率是竖屏还是横屏，封面是否单独设计。
3. 标题是否与内容一致，避免标题党。
4. 是否包含需要补充说明的免责声明或 AI 生成标识。
5. 文案中是否有绝对化表述、极限词或未经证实的数据。
6. 背景音乐和字体是否来自授权库。
7. 视频中是否出现未授权的人物、Logo 或商标。
8. 字幕是否有错别字，语法是否通顺。
9. 是否有回放或跳转用的备用素材。
10. 是否记录了发布数据，方便后续分析哪类内容有效。

这份清单属于项目级规范，应该写入团队文档或做成脚本提示。不要依赖个人记忆，因为一旦生产量变大，遗忘是大概率事件。

7. 常见问题与排查路径：从现象定位到解决

7.1 生成画面不稳定

现象：同一个分镜跑两次，生成的画面构图、颜色、角色外貌相差很大。可能原因是提示词不够具体、参数里没有固定种子，或者模型版本本身随机性较高。

先检查提示词里是否写清楚了主体、场景、动作、镜头、光线、风格。再检查请求参数里是否使用了固定seed。如果两个都没有问题，则把参考图或首帧图加入请求。记住一条原则，不要靠反复调用模型来碰运气，要通过结构化的提示词和参数锁定变量，这样才能复现成功结果。

7.2 视频与文案不匹配

现象：配音在讲某个场景，画面却是另一个内容。最常见原因是分镜粒度太粗。一个镜头里塞了过多动作，模型只能选择其中一个表现出来。

处理方法是把一个镜头拆成多个。每段配音只对应一个明确的动作描述。比如“他在路上走，然后停在红灯前”可以拆成两个镜头：一个是行走的中景，一个是红灯前停步的近景。这会让素材生成和合成阶段更可控。

7.3 音画不同步与渲染失败

现象：成片里画面和声音没有对齐，或者 FFmpeg 拼接报错。

先确认每个镜头片段是否使用-shortest合成。再检查输入文件的分辨率、帧率、音频采样率是否一致。使用ffprobe查看每个视频流的编码信息，如果不一致，需要先统一参数再拼接。音频和视频不同步的另一个常见原因是字幕时间轴没有对应各片段的累计时长，需要在脚本里重新计算。

7.4 环境与依赖问题

现象：脚本报ModuleNotFoundError、FFmpeg 命令不存在，或者接口请求报网络错误。

按以下顺序排查：

1. 当前是否激活了正确的 Python 环境。
2. requirements.txt中需要的依赖是否已安装。
3. 本机是否安装了 FFmpeg，是否已加入系统 PATH。
4. 配置文件中的 API Key 是否有效，请求域名是否能正常访问。
5. 查看接口返回的状态码和错误信息，确认是参数问题还是服务端限流。
6. 检查素材文件路径是否有中文、空格或特殊字符，FFmpeg 有时会因为这些路径处理失败。

8. 从“赚 100 万”回到工程现实：先建立产能，再谈放大

8.1 为什么收益承诺不可复制

标题里的“6 个月赚到 100 万”更容易被理解成一个商业目标，而不是技术指标。技术在商业结果中只占一部分。内容定位、平台规则、用户需求、投放预算、运营节奏、变现渠道和运气成分，都会影响最终收入。任何只强调收益数字、却忽略这些因素的说法，都不能作为工程决策依据。

从可执行角度，更合适的做法是把收入目标翻译成工程指标。

一个合理的启动目标不是某个收入数字，而是把单条视频从选题到发布的时间控制住，同时让画面质量、配音质量、字幕准确度都能达到稳定水平。做到这一层之后，再谈放大产能和测试不同内容方向才有意义。

8.2 技术人能做的是把生产流程标准化

与其追逐每一个新模型的效果，不如先建立一套可复用的工程框架。这里给出一个从 0 到 1 的过程：

1. 用 3 到 5 条脚本跑通完整流程，先手工执行，记录人工耗时。
2. 把每一步的输入输出梳理为 JSON 或配置项，形成统一数据格式。
3. 用脚本替换手工调用，保留中间产物，方便失败后断点续跑。
4. 加入批量生成和并发控制，处理限流和重试。
5. 加入内容审核和发布前检查，避免人为漏检。
6. 逐步沉淀提示词模板、分镜模板、素材库，形成团队资产。

这套流程做好之后，如果再引入新的模型或新的提示词策略，只需要改对应环节。这也正是 AI 应用开发的常见模式：模型会快速更替，但数据结构和流程设计才是长期资产。

8.3 下一步扩展方向

当最小流水线跑通后，可以考虑几个扩展方向：

第一，把流程包装成 Agent。将文案生成、分镜生成、素材生成、合成发布封装成一组工具或函数，由一个调度器统一管理。这样用户只需要提交一个选题，就能触发整条链路。这与 AI Agent 的工作方式非常接近：定义任务、拆分步骤、调用工具、产出结果。

第二，建设垂直领域语料。无论做知识科普、行业资讯还是企业文化内容，都需要针对特定领域的术语和表达风格建立提示词库和素材库。通用提示词只能保证画面好看，很难保证内容专业。

第三，打通数据分析回流。发布后的播放量、完播率、评论主题都可以反哺到选题环节。让系统根据数据表现自动调整下一批文案方向，这一步相比单纯增加生成量，会更贴近真实需求。

第四，如果团队使用 Java 技术栈，可以关注 Spring AI 这类框架。它把大模型接口封装成统一抽象，让应用代码可以更方便地切换模型服务商。底层原理与上面提到的方法一致，都是把模型调用、上下文管理和输出解析标准化。

AI 视频工具还会继续更新，但无论模型怎么变化，“拆解任务、控制输入、检查输出、沉淀数据”这套工程思路不会过时。先把一条 20 秒视频的生产流程做到完全可控，再慢慢扩展到更长、更复杂、更垂直的内容。这条路不需要过度追逐风口，需要的是把每个环节的变量都搞清楚。