AI短视频自动制作与多平台分发：从文案生成到FFmpeg合成全流程实战

做了大半年内容矩阵，最让我崩溃的不是写不出东西，而是同样的流程要反复做几十遍。从找选题、写口播稿，到录音、剪素材、加字幕，再到一条条复制粘贴发去各个平台，一条一分钟的短视频，人工做至少要两三个小时。所以我花了几周时间，搭了一套AI短视频自动制作与多平台分发的智能解决方案：让大模型写文案，让TTS念稿，让FFmpeg自动合成画面和字幕，最后用脚本批量发布到抖音、快手、B站和小红书。整套系统跑通之后，我只需要在前一天晚上确认几个选题，第二天早上起来，成片已经躺在各平台的草稿箱里等着我点发布。这篇就是我这套方案从设计到落地的完整记录，包括每个环节的工具选型、关键参数、踩过的坑，以及为什么有些看起来更省事的方案我最后没有选。

1. 方案整体设计：先把一条短视频拆成六个环节

1.1 为什么我把"效率"放在第一位

做短视频自动化，很多人第一反应是找一个现成的"AI一键成片"工具。这类工具确实快，输入一个主题，几分钟就能给你生成一条带配音、带字幕的视频。但用一段时间你会发现两个问题：一是模板感太重，素材库翻来覆去就那些，视频发出去很难有差异化；二是你无法干预中间过程，想换一个配音音色、想调整某句字幕的样式，都要看工具的心情，更别说批量生产时成本高得离谱。

我的思路反过来：不追求"全自动",而是把一条视频从创意到发布拆成几个独立环节，每个环节用最合适的工具单独解决，再用脚本把它们串起来。这样做的最大好处是每个环节都可插拔、可替换、可干预。今天觉得这个TTS音色不好，换一个引擎只改一个模块；明天平台调整了视频比例，改一个参数就能全量重跑。流水线式的架构，让整个方案的长期维护成本远低于任何"全家桶"式工具。

1.2 六个环节的拆解与角色分配

我把一条短视频的完整生产过程拆成六个环节：

1. 选题：确定今天做什么主题，来源可以是热点词、评论区高频问题，或者自己维护的一个选题池。
2. 文案：围绕主题生成口播稿，包括标题、正文、结尾引导语，并控制字数与时长匹配。
3. 配音：把文案转成语音，输出音频文件，同时记录每一句的时间点。
4. 画面：收集或生成与文案匹配的画面素材，包括背景视频、图片、字幕样式。
5. 合成：用剪辑程序把音频、画面、字幕合成为一个视频文件，输出不同平台需要的分辨率版本。
6. 分发：把成片和对应的标题、话题标签批量提交到各平台。

在人工流程里，这六步是线性串联的，一个人从头做到尾。在自动化方案里，这六步可以并行：上午同时生成10条文案，下午统一合成配音，晚上批量渲染，第二天早上统一分发。效率提升不是简单的"省掉人工",而是把等待时间也压缩掉了。

1.3 选型判断：稳定、成本、可控

每个环节都有很多工具可选，我的选型标准只有三个：稳定性、成本、可控性。

• 稳定性：工具要能长期运行不出幺蛾子，尤其是配音、合成这类高频调用环节。免费方案虽然香，但如果动不动报错、限流，整套流水线就断了。
• 成本：按条核算，而不是按套餐核算。一条1分钟视频，文案成本、TTS成本、渲染成本分别多少，心里要有数。商业方案要算清楚边际成本，开源方案要算清楚服务器成本。
• 可控性：我能否拿到中间产物，能否自定义参数，能否在某个环节替换自己的实现。这决定了方案能走多远。

基于这三个标准，我最终选型如下：文案用大模型API（本地部署的也行），配音用微软Edge TTS（免费、稳定、音色自然），画面素材用Pexels/Pixabay的免费视频素材API，合成本地用FFmpeg，分发用各平台的开放接口加无头浏览器。

2. 核心技术选型与配置解析

2.1 文案生成：让大模型按"口播稿"格式输出

文案环节是整个流水线的上游，它的质量直接影响配音、字幕、画面匹配。我踩过的最大坑是：直接让模型写"一段短视频文案"，结果它给你一段书面语，念出来生硬，字幕也长。后来我把提示词改成了严格的结构化输出，要求它按场景、口播、时长逐句拆分。

我常用的提示词框架（以一条知识类口播为例）：

你是一名短视频口播文案策划。请根据以下主题，输出一条时长约60秒的口播稿。 要求： 1. 全文口语化，每句话不超过30字，适合朗读。 2. 结构分为三部分：开头3秒吸引力钩子、中间核心内容、结尾引导互动。 3. 输出格式为JSON，字段包括： - title：视频标题（不超过20字） - lines：口播句子数组，每句是一个对象，包含text（句子文本）和duration（预计朗读秒数） 4. 句子之间要有逻辑递进，不要重复。 主题：{主题关键词}

为什么要求逐句拆分并估算时长？因为下游配音和字幕都需要知道每一句的时间跨度。TTS合成后虽然能拿到音频总时长，但逐句对齐更精准，方便后面做逐句字幕，也方便根据时长自动截取画面素材。

如果要做批量生产，我还会在主题后面加一个"风格"字段：轻松、严肃、悬念、励志。不同风格对应不同的开场句式。这个字段同时会传给配音环节，用来选择不同的音色和语速参数。

2.2 语音合成：选TTS要看这4个参数

TTS引擎决定了一条视频听起来的"人味"。我对比过多个方案：商业API（火山、阿里云、讯飞）、开源模型（CosyVoice、GPT-SoVITS）、以及微软Edge TTS。最终在流水线里默认用了Edge TTS，原因是它在免费的前提下，音色自然度和稳定性都满足我的需求。但如果你追求某个特定的音色克隆能力，那还是要上开源模型，比如CosyVoice可以微调自己的音色，只是部署成本高一些。

不管用哪个TTS，都要关注4个参数：

我踩过一个坑：合成时没注意采样率，结果音频是16kHz，合成到视频后某些平台播放正常，但B站上传后高频部分明显发闷，审核波形也有异常。后来我在TTS脚本里强制重采样到44100Hz，问题彻底解决。Edge TTS本身是流式返回音频，我封了一层缓存：同样的文案如果合成过一次，直接读缓存，避免重复请求，既能省时间也能降低被限流的概率。

2.3 画面素材与自动剪辑：FFmpeg是拼图的核心

画面素材我优先用Pexels和Pixabay的免费视频素材API。按文案的关键词去搜索素材，保证画面和内容相关。素材下载后统一转成竖屏9:16，分辨率1080x1920，再按每句音频的时长裁剪。中间用FFmpeg的filter_complex拼接，叠加上标题文字和逐句字幕。

FFmpeg是整个合成环节的核心，它做的事情可以理解为"拼图工人"：把一段段视频、一张张图片、一条条音频，按照时间线拼成一个完整文件。之所以不用剪映的自动化接口，是因为FFmpeg完全本地执行，没有网络依赖，批量处理50条视频也不会触发任何风控，而且每个参数都可控。

字幕我不用硬编码烧进画面的方式，而是用ASS字幕文件嵌入。这样做的好处是，字幕的字体、大小、位置、描边、渐显动画都能用代码定义，修改样式只需要改一个模板文件，不用重新渲染每一帧画面。ASS字幕配合libass库在FFmpeg里可以直接渲染成硬字幕，几乎所有播放器和平台都兼容。

3. 从零搭建自动化流水线：完整实操记录

3.1 环境准备与目录规划

我建议整套流水线跑在一台Linux服务器上，4核8G起步。如果是Windows本机开发，WSL2也可以，但路径和编码要注意，后面章节会细说。首先要装好以下基础环境：

# 服务器环境（Ubuntu/Debian） sudo apt update sudo apt install -y ffmpeg python3 python3-pip fonts-noto-cjk pip3 install requests edge-tts openai pillow

目录结构我习惯这样规划，每个环节的输出相互独立，方便出问题时单独重跑某一步：

auto-video/ ├── config/ # 配置文件：平台账号信息、模型参数、风格模板 ├── scripts/ # 各环节的Python脚本 ├── queue/ # 待生产的选题列表（JSON格式） ├── output/ │ ├── audio/ # 配音音频 │ ├── subtitle/ # ASS字幕文件 │ ├── source/ # 下载的原始画面素材 │ ├── render/ # 合成好的成片 │ └── manifest/ # 每条视频的元数据（标题、话题、描述） └── logs/ # 各环节日志

之所以专门放一个manifest目录，是因为分发环节需要知道每条视频的标题、描述、话题标签。这些信息在文案生成时就应该一并结构化输出，而不是在发布时手动填。这个设计能让分发环节完全自动化。

3.2 文案生成与结构化输出

我写了一个generate_script.py，它的输入是queue/queue.json里的一个选题，输出是一个结构化文案文件output/manifest/{id}.json。核心代码如下：

import json import time from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="your-model-endpoint", # 兼容OpenAI格式的接口 ) SYSTEM_PROMPT = """你是短视频口播文案策划。根据主题生成一条60秒口播稿。 要求： 1. 全文口语化，每句不超过30字。 2. 结构：开头3秒钩子，中间核心内容，结尾引导互动。 3. 按JSON格式输出，字段包括 title、lines。 lines是数组，每项包含text和duration字段。 """ def generate_script(topic: str) -> dict: resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"主题：{topic}"}, ], temperature=0.8, max_tokens=800, ) content = resp.choices[0].message.content.strip() # 模型可能输出```json包裹，去掉前后缀 if content.startswith("```"): content = content.split("```")[1].strip() if content.startswith("json"): content = content[4:].strip() data = json.loads(content) # 校验字段完整性 assert "title" in data and "lines" in data return data

温度参数我调到0.8，这样能保证文案风格稳定，又不至于每次生成完全一样。max_tokens控制在800左右，因为60秒口播大约240~260字，800 token足够覆盖。生成之后不要直接进配音，我习惯先落一个manifest文件，人工扫一眼再继续，尤其是标题里的敏感词和事实性错误，大模型偶尔会犯。

3.3 配音生成与时间轴对齐

配音脚本generate_audio.py的任务是把上一步的lines逐句合成音频，并记录每句在完整时间轴上的起始时间。这个时间轴信息对后续字幕和画面裁剪都至关重要。

import asyncio import json import edge_tts VOICE = "zh-CN-YunxiNeural" # 云希，自然度较高的男声 RATE = "+10%" async def synthesize_line(text: str, index: int, out_path: str) -> dict: communicate = edge_tts.Communicate(text, VOICE, rate=RATE) durations = [] start = 0.0 async for chunk in communicate.stream(): if chunk["type"] == "audio": # 这里用ffprobe获取真实时长更准确，但流式里可以先估算 duration = len(chunk["data"]) / (32000 / 8) # 近似，实际用ffprobe校准 durations.append(duration) # 为简化，这里用ffprobe再校准一次 import subprocess result = subprocess.run( ["ffprobe", "-v", "error", "-show_entries", "format=duration", "-of", "csv=p=0", out_path], capture_output=True, text=True ) real_duration = float(result.stdout.strip()) return {"index": index, "start": start, "duration": real_duration}

这段代码里我用了Edge TTS的流式接口，逐句生成音频文件。最需要注意的地方是：每句之间的停顿要显式加进去。我在合成每条语音后，会在下一句前插入0.2秒的静音，用FFmpeg的adelay过滤器实现。这样做出来的口播听起来有呼吸感，不会像机关枪一样一句接一句。

合成完成后，生成一个audio_timeline.json，里面记录每句的start和end毫秒值。这个文件是字幕和画面的"节拍器"。

3.4 合成成片与字幕压制

合成环节render_video.py是整套流水线里最复杂的一步，它要做三件事：

1. 根据每句的时长，从素材库中裁剪对应时长的视频片段。
2. 把裁剪好的片段按顺序拼接。
3. 叠加字幕和标题，混入配音音频，输出成品。

核心的FFmpeg命令我封装成函数：

def render_video( audio_path: str, segments: list[str], # 每个片段对应的素材路径 subtitle_path: str, # ASS字幕文件 output_path: str, width: int = 1080, height: int = 1920, ): # 先拼接视频片段，再叠加字幕和音频 concat_file = "/tmp/concat.txt" with open(concat_file, "w") as f: for seg in segments: f.write(f"file '{seg}'\n") filter_complex = ( "[0:v]scale={w}:{h}:force_original_aspect_ratio=increase," "crop={w}:{h},setsar=1,fps=30[v];" "[v]subtitles='{sub}':force_style='FontName=Noto Sans CJK SC," "FontSize=12,PrimaryColour=&H00FFFFFF,OutlineColour=&H00000000," "BorderStyle=1,Outline=2'[vout]" ).format(w=width, h=height, sub=subtitle_path.replace(":", "\\:")) cmd = [ "ffmpeg", "-y", "-f", "concat", "-safe", "0", "-i", concat_file, "-i", audio_path, "-filter_complex", filter_complex, "-map", "[vout]", "-map", "1:a", "-c:v", "libx264", "-preset", "medium", "-crf", "20", "-c:a", "aac", "-b:a", "192k", "-shortest", "-movflags", "+faststart", output_path, ] subprocess.run(cmd, check=True, capture_output=True)

几个关键参数解释一下：

• force_original_aspect_ratio=increase加crop组合，是从横屏素材中间裁出竖屏区域，而不是把画面压扁。素材如果是1920x1080，裁完1080x1920，画质足够。
• crf 20是画质与体积的平衡点。数值越小画质越好，文件也越大。平台上传一般有大小限制，我实测crf 20在1080x1920 30fps下，一条60秒视频大约20~40MB，各平台都能接受。
• subtitles过滤器里的字体路径和特殊字符转义是重灾区。如果你的字幕路径有冒号，需要转义成\:；字体名如果带空格，也要用引号包好。这个坑我花了不少时间才彻底绕过去。

ASS字幕文件我单独用generate_subtitle.py生成，模板固定，只需要传入每句文字和时间轴：

[Script Info] ScriptType: v4.00+ PlayResX: 1080 PlayResY: 1920 [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, OutlineColour, BackColour, Bold, Outline, Shadow, Alignment, MarginL, MarginR, MarginV Style: Default, Noto Sans CJK SC, 72, &H00FFFFFF, &H00000000, &H80000000, -1, 3, 1, 2, 60, 60, 120 [Events] Format: Layer, Start, End, Style, Text Dialogue: 0,0:00:00.20,0:00:02.50,Default,这是第一句字幕 Dialogue: 0,0:00:02.70,0:00:05.10,Default,这是第二句字幕

字幕位置我设置在画面下方约四分之一处，也就是MarginV=120，避免被平台UI遮挡。字体用思源黑体，在Linux下装好fonts-noto-cjk即可覆盖绝大部分中文显示场景。

3.5 定时调度：让流水线自己跑起来

成片渲染好后，最后一步是定时调度。我用了最简单的crontab：

# 每天早上6点生成3条视频 0 6 * * * cd /opt/auto-video && python3 scripts/pipeline.py --limit 3 >> logs/cron.log 2>&1 # 每天早上8点执行分发 0 8 * * * cd /opt/auto-video && python3 scripts/publish_douyin.py >> logs/publish.log 2>&1

pipeline.py是一个总控脚本，从队列里面取选题，依次调用文案、配音、字幕、渲染四个模块，最后生成一个发布清单。如果某一步失败，不会中断后续视频，而是把失败的原因写入日志，并把任务放回队列，等下一轮重跑。这种"失败不阻塞"的设计非常关键，否则某一条视频的临时问题会导致整个批次的视频都发不出去。

调度间隔不要设置得太密集，我试过每10分钟跑一次，结果某个TTS接口因为请求太频繁返回了限流错误。后来改成每天固定批量生成，既稳定又省心。

4. 多平台分发的正确姿势：不只是"一键发布"

4.1 不同平台的规则差异对照

多平台分发最容易犯的错误，是一个视频文件走天下。实际上各平台的格式偏好、时长限制、封面要求、违禁词策略都不一样。我整理了一个对照表，这是我反复测试后得出的经验值：

分发时我按平台生成不同的描述文案：抖音的文案短、口语化，带2~3个话题；小红书则改为"干货笔记体"，强调收藏价值；B站需要标题和简介更正式。这个差异化工作也交给大模型完成，在分发模块里传入平台名和原始标题，让它生成每个平台的专属描述。

4.2 对接API与第三方工具的组合打法

分发环节有两条技术路线：

1. 平台开放接口：抖音开放平台、B站开放平台等都提供了视频上传API。优点是稳定、合规，数据能回传；缺点是申请权限门槛不一，有些需要企业资质，个人开发者申请周期长。
2. 无头浏览器自动化：通过Playwright或Selenium模拟登录、上传、填写标题和标签。优点是不受接口权限限制，几乎所有平台都能跑；缺点是脆弱，平台页面一改版就要修脚本，而且有风控风险。

我给这套体系定的策略是：能走API的走API，走不了API的用无头浏览器，且发布频率严格控制。比如B站有开放平台的口子，就直接调API；抖音个人号没申请到接口，就用Playwright模拟操作。但模拟操作时，我会让每次发布的间隔随机化，比如8到12分钟之间随机，避免固定节奏触发风控。实测下来，每天一个账号发3~5条，目前没出过问题。

无头浏览器的一个关键细节是登录态管理。不能每次发布都重新扫码登录，要保存Cookie或storage state，在启动浏览器时直接加载。我用的Playwright可以这样保持会话：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=True) context = browser.new_context(storage_state="state/douyin.json") page = context.new_page() # 自动上传逻辑从这里开始

第一次运行时不加storage_state参数，手动登录一次，然后执行context.storage_state(path="state/douyin.json")把登录态存下来。之后每次启动都加载这个文件，就不会被登出了。

4.3 从"发出去"到"收回来"：数据回流

分发不是终点，数据回收才是下一轮内容优化的起点。我在脚本里加了一个数据采集模块，每天定时抓取各平台账号下的播放量、点赞、评论、转发数据，写入数据库。为什么要做这一步？因为自动化的效率优势如果不能转化为内容质量的提升，那生产出来的只是"更快地制造垃圾"。

我把数据分成三个维度去看：

• 完播率：如果多数视频在开头3秒流失，说明钩子文案或画面开场有问题。
• 互动率：点赞、评论、收藏的比例。互动率高但播放量低，权重模型可能没给够推荐，需要优化标题和话题标签。
• 涨粉成本：每增加一个粉丝需要多少播放量，用来评估内容的长期价值。

数据回流到选题模块后，我会把播放量高的视频标题和主题提取出来，作为下一轮创作的种子词。这样整个系统就形成了一个闭环：生产、分发、回收、再生产。这也是我认为自动化内容最有价值的地方——它不是替代创意，而是让创意更快地试错。

5. 踩坑实录与排查技巧

5.1 高频异常问题速查表

运行这套系统三个月，我修过的Bug数量远超预期。以下是最常遇到的几类问题：

5.2 最值得展开说的三个坑

第一个坑是素材版权。Pexels和Pixabay虽然号称免费商用，但部分视频素材依然有"不得用于敏感内容""不得重新打包售卖"等限制。我的原则是：只用明确标注"免费可商用"的资源，并且在manifest里记录素材来源链接。这样做不仅是规避法律风险，也是对自己内容品牌的尊重。如果你规模化商用，更稳妥的办法是自己拍摄一部分素材，或者订阅正版素材库。

第二个坑是平台风控的"软屏蔽"。发布脚本偶尔会遇到一种情况：视频正常上传、正常显示，但播放量长期在200左右徘徊。我排查了很久，怀疑是无头浏览器的环境指纹被标记了。后来给Playwright加了随机UA、禁用了WebDriver标志，发布时间也改到当天热门的流量时段，情况才明显好转。这里想提醒一点：自动化分发不是越快越好，模仿真人节奏永远是最安全的方式。

第三个坑是踩到"敏感词误判"。有一次我生产的一条科技类视频，标题里含了"最"字，发布后直接被限流。后来我在文案生成环节加了一道敏感词过滤程序，接入了常见违禁词库，生成文案后先跑一遍过滤，命中可疑词就自动改写。要注意，各平台规则不同，最稳妥的做法是分发前让大模型针对每个平台单独改写标题和描述，把可能存在风险的表达提前消化掉。

5.3 内容质量的底线：自动化不是"无人化"

最后我想谈一个比较主观但很重要的话题：这套流水线虽然叫"自动制作",但我始终保留了人工审核这个环节。每天系统生成完视频后，我会花10分钟快速过一遍标题、听一遍配音、扫一眼关键画面。为什么？因为AI偶尔会生成事实性错误、不合时宜的表述，或者把某个素材用在完全不对的语境里。这些错误在其他环节很难被自动捕捉，只能靠人眼把关。

我个人的体会是，自动化方案真正应该接手的是"重复劳动",而不是"判断"。素材筛选、文案初稿、音画合成、定时发布，这些环节机器做得又快又好；但最终的内容调性、选题价值、风险把控，仍然需要人来负责。把这套方案跑顺之后，我每天在短视频上投入的时间从三小时降到了半小时，多出来的时间我用来研究选题和复盘数据，而不是坐在剪辑软件前一遍遍拖动时间轴。这大概就是我最初想解决的那个问题的最好答案。