AI批量短视频自动化：任务单、自动混剪与发布验收

简介这份压缩包围绕AI短视频自动化生产与分发面向内容创作者、品牌运营人员及具备Python基础的开发者针对批量生成、自动混剪与多平台发布中效率低、流程分散的问题提供一套可运行的工程参考。包内共121个文件整体约108.62MB主体为90个Python源码另含Markdown/README/TXT说明、BAT与SH启动脚本、中英文JSON配置、PT模型、TTC字体、MP3音频及示例图片覆盖素材、配置、模型依赖与运行入口等完整结构。已有978人学习下载。读者可据此梳理从视频批量生成、混剪到发布至抖音等平台的实现链路结合说明文档与启动脚本理解模块组织、依赖关系及二次开发入口便于快速定位关键实现并减少环境搭建中的试错成本对需要搭建本地短视频自动化流水线、进行课程设计或技术选型的人员也具备较高的参考与复现价值。1. 一键批量出片到底在自动化什么从选题到发布的三段流水线很多人第一次听到「AI 一键批量生成短视频、自动混剪、自动发布」脑子里浮现的是一个按钮按下去、几十条成片排队上传的画面。真把这条链路跑起来就会发现它不是一个模型而是三段彼此独立的流水线脚本与配音的生成、素材与时间线的混剪、以及发布环节的调度与校验。三段里任何一段没有工程化另外两段再自动化也白搭——配音采样率不对混剪出来的片子全程音画漂移时间线没做帧率统一50 条里能有 20 条带黑帧。这篇讲的是把「批量」两个字做扎实的那套做法一条选题进来最后变成一条能直接投出去、并且能被程序验收的成片。适合已经在做账号矩阵、内容代运营、或者想把手上的剪辑重复劳动压下去的从业者。需要写代码但不需要训练模型——真正吃时间的是参数和边界不是算法。2. 任务单先行把选题池扩成机器能吃的 CSV批量生产最忌讳「边跑边想」。靠谱的顺序是先把这一批要出什么全部落成一张表后面所有脚本只读这张表。这样做的好处很直接任何一个环节翻车你都能拿着 task_id 回到那一行定位是素材问题、参数问题还是文案问题。2.1 任务单字段设计与稳定哈希任务单不是选题表。选题表里是人话任务单里必须是机器能直接消费的字段而且要能重跑不重样。字段含义取值/约束为什么要它task_id任务唯一标识序号 内容哈希 变体号重跑时不覆盖旧产物方便回溯topic选题字符串只做归档剪辑不读script口播稿路径相对路径与文案解耦改稿不动任务单voice音色枚举同一批里声音要统一bgm背景音乐文件名便于按情绪分组ratio画幅9:16 / 16:9 / 1:1决定 scale/crop 参数target_s目标时长秒15–90剪辑侧的硬约束publish_at预定发布时间空表示只产不发把生产和发布解耦account账号别名别名不写真实账号发布侧路由# build_plan.py —— 把选题池扩成可执行的任务单 import csv, hashlib, pathlib TOPICS pathlib.Path(input/topics.csv) # 人工维护一行一个选题 OUT pathlib.Path(work/plan.csv) # 只由脚本写不手工改 OUT.parent.mkdir(parentsTrue, exist_okTrue) def task_id(topic: str, idx: int, variant: int) - str: # 用选题内容做稳定哈希同一选题重跑得到同一个 id不会产生重复任务 h hashlib.md5(topic.encode(utf-8)).hexdigest()[:8] return ft{idx:03d}-{h}-v{variant} rows [] with TOPICS.open(encodingutf-8) as f: for i, r in enumerate(csv.DictReader(f), start1): # variants同一选题出几条不同剪辑靠素材顺序和 BGM 拉开差异 for variant in range(int(r.get(variants, 1))): rows.append({ task_id: task_id(r[topic], i, variant), topic: r[topic], script: r[script_path], voice: r.get(voice, female_01), bgm: r.get(bgm, bgm_calm_01.mp3), ratio: r.get(ratio, 9:16), target_s: int(r.get(target_s, 32)), publish_at: r.get(publish_at, ), account: r.get(account, acct_a), }) with OUT.open(w, encodingutf-8, newline) as f: w csv.DictWriter(f, fieldnameslist(rows[0].keys())) w.writeheader() w.writerows(rows) print(fplan - {OUT} tasks{len(rows)})variants放在任务单里而不是剪辑时随机是为了可复现——一周后你看到某条数据好能顺着 task_id 找回它的素材顺序。target_s是剪辑目标而不是硬裁时长配音 28 秒、目标 32 秒一般靠片头片尾和转场补硬裁会切掉半句话。publish_at留空是常见做法先批量生产、再人工排期比一开始就把发布也塞进同一条流水线稳得多。2.2 上机前的校验闸门任务单里一个错字段会在 50 条以后才炸出来。加一道几十行的校验成本极低。# validate_plan.py —— 不合格的任务直接拦在上机之前 import csv, pathlib REQUIRED {task_id, topic, script, ratio, target_s} RATIOS {9:16, 16:9, 1:1} MIN_S, MAX_S 15, 90 def check(row, seen): errs [] if not REQUIRED row.keys(): errs.append(字段缺失) if row[task_id] in seen: errs.append(task_id 重复) if row[ratio] not in RATIOS: errs.append(f画幅不支持: {row[ratio]}) if not row[target_s].isdigit() or not (MIN_S int(row[target_s]) MAX_S): errs.append(f时长越界: {row[target_s]}) if not pathlib.Path(row[script]).exists(): errs.append(口播稿文件不存在) return errs seen, bad set(), 0 with open(work/plan.csv, encodingutf-8) as f: for row in csv.DictReader(f): e check(row, seen) seen.add(row[task_id]) if e: bad 1 print(row[task_id], |, ; .join(e)) print(fchecked{len(seen)} bad{bad})MIN_S / MAX_S这两个值不是拍脑袋而是由后面的素材库决定的手头素材平均单镜 2 到 3 秒90 秒成片要 30 个以上镜头素材不足就会重复用到同一段观众一眼看得出来。素材少的团队把上限压到 45 秒复用率立刻降下来。2.3 配音字幕与素材索引两个容易做歪的前置件配音和字幕必须一次性生成别分开跑两遍。常见坑是先合成音频再用另一套工具做字幕两边的断句逻辑不同字幕整体偏移一两百毫秒短视频里非常明显。# voice.py —— 配音与字幕一次产出采样率对齐后续 ffmpeg import pathlib, subprocess def synth(text: str, out_wav: pathlib.Path, voicefemale_01): cmd [ tts-cli, --text, text, --voice, voice, --speed, 1.05, # 1.0 偏慢口播类 1.03~1.08 更贴节奏 --sample-rate, 48000, # 后面统一 48k这里千万别用 44.1k --out, str(out_wav), ] subprocess.run(cmd, checkTrue) def to_srt(marks, out_srt: pathlib.Path): # marks: [{start:0.0,end:2.4,text:...}]由引擎的时间戳回传 def ts(t): h, m, s int(t // 3600), int(t % 3600 // 60), t % 60 return f{h:02d}:{m:02d}:{s:06.3f}.replace(., ,) lines [] for i, m in enumerate(marks, start1): lines [str(i), f{ts(m[start])} -- {ts(m[end])}, m[text], ] out_srt.write_text(\n.join(lines), encodingutf-8)--speed 1.05是经验值再快字就糊--sample-rate 48000必须和混音侧一致44.1k 混 48k 会触发重采样某些编码器下直接表现为音画缓慢漂移这就是后面避坑章里第一条的根源。素材库同样要建索引。混剪脚本不该在运行时去扫目录那是几万次 IO。# index_assets.py —— 给素材建索引混剪时按标签抓 import json, pathlib, subprocess ROOT pathlib.Path(assets/clips) rows [] for p in ROOT.rglob(*.mp4): probe subprocess.run( [ffprobe, -v, error, -select_streams, v:0, -show_entries, streamwidth,height,r_frame_rate:formatduration, -of, json, str(p)], capture_outputTrue, textTrue, checkTrue) s json.loads(probe.stdout)[streams][0] dur float(json.loads(probe.stdout)[format][duration]) if dur 1.2: # 太短的镜头进不了 2.4 秒的时间线 continue rows.append({ path: str(p), w: s[width], h: s[height], fps: s[r_frame_rate], dur: round(dur, 2), tag: p.parent.name, # 目录名即标签city/night/food usable: s[width] 1080, }) pathlib.Path(work/assets.json).write_text( json.dumps(rows, ensure_asciiFalse, indent1), encodingutf-8) print(len(rows), clips indexed)tag用目录名是最省事的做法代价是目录结构要一开始就设计好。usable这个布尔值卡掉 720p 以下的素材——9:16 拉到 1080×1920 时低分辨率素材会明显发虚而批量生产里没人有时间逐条看。3. 自动混剪的骨架一条 filter_complex 撑起整批成片混剪的本质是时间线建模哪些片段、什么顺序、每段多长、怎么接。把这件事写成一个纯函数输入任务单和素材索引输出一条 ffmpeg 命令批量就是把这条命令跑 N 次。3.1 用 xfade 拼时间线offset 算错就闪黑先看单条成片的 filter_complex 怎么长出来。所有片段先统一到同一画幅、同一帧率、同一像素格式再做转场——顺序错了xfade 会直接报错或者输出一帧黑。# timeline.py —— 由任务单生成一条 filter_complex 命令 def build(task, clips, out_path, w1080, h1920, fps30, seg2.4, tr0.25): ins, fc [], [] for i, c in enumerate(clips): ins [-i, c[path]] # 顺序很重要scale - crop - fps - format - trim - setpts fc.append( f[{i}:v]scale{w}:{h}:force_original_aspect_ratioincrease, fcrop{w}:{h},fps{fps},formatyuv420p, ftrimduration{seg},setptsPTS-STARTPTS[v{i}] ) cur v0 for i in range(1, len(clips)): off round(i * (seg - tr), 3) # 第 i 次拼接的时间点 fc.append(f[{cur}][v{i}]xfadetransitionfade:duration{tr}:offset{off}[x{i}]) cur fx{i} fc.append(f[{cur}]null[vo]) # 收尾标签方便后面接字幕与水印 n len(clips) fc.append(f[{n}:a]aresample48000,volume1.0[voice]) fc.append(f[{n1}:a]aresample48000,volume0.25,alooploop-1:size2e9[bgm]) fc.append([bgm][voice]sidechaincompress threshold0.05:ratio8:attack20:release300[duck]) fc.append([voice][duck]amixinputs2:durationfirst:dropout_transition0, loudnormI-14:TP-1.5:LRA11[aout]) cmd [ffmpeg, -y, *ins, -i, task[voice_wav], -i, task[bgm], -filter_complex, ;.join(fc), -map, [vo], -map, [aout], -c:v, libx264, -preset, medium, -crf, 20, -pix_fmt, yuv420p, -r, str(fps), -c:a, aac, -b:a, 192k, -ar, 48000, -movflags, faststart, str(out_path)] return cmdoff i * (seg - tr)这一行是整段代码的重心。每接一次转场总时长就少一个tr所以第 i 次拼接的时间点是i × (段长 − 转场长)。写成i * seg的话转场会落在上一段已经结束的位置输出就是「黑一帧再淡入」——这个 bug 在批量里看起来像是随机的特别耗时间。formatyuv420p放在 xfade 之前是硬要求两段像素格式不一致时 xfade 的行为不确定。setptsPTS-STARTPTS用来把每段的时间戳归零漏掉它靠后的片段会带着原始时间戳进来转场点全乱。3.2 三个必调参数段长、转场、响度批量生产里真正需要调的参数就三个其余都是固定值。参数建议区间调大的后果调小的后果单镜时长 seg1.8–2.6 s节奏拖沓完播率掉观众看不清内容像抽帧转场时长 tr0.20–0.30 s整片发软缺少冲击生硬像硬切拼接目标响度 I−16 ~ −13 LUFS平台二次压限后失真手机上听不清响度这一项值得多说一句。loudnormI-14:TP-1.5:LRA11里的TP-1.5是真峰值上限单位 dBTP。留 1.5 dB 余量是为了穿过平台的自动增益不留余量某些平台转码后会削顶听感上就是「滋滋」的破音。LRA11控制响度范围口播类内容压到 7–11 之间比较自然压到 5 会明显听出「压过的痕迹」。BGM 闪避的threshold0.05:ratio8是另一组常用值。threshold 是触发压缩的电平0.05 大约对应 −26 dBFS人声一起就把 BGM 压下去ratio 8 表示输入超阈值 8 dB、输出只涨 1 dB。attack 20ms 保证起音不被削掉release 300ms 避免说话停顿处 BGM 忽大忽小地「呼吸」。3.3 批量封装并发上限与临时文件回收单条能跑通之后最容易犯的错是把 50 条直接丢进for循环。编码是 CPU 密集型并发开满只会互相抢核总耗时反而更长还会把内存顶爆。# run_batch.py —— 有上限的并发失败只留日志尾巴 import csv, subprocess, tempfile from concurrent.futures import ThreadPoolExecutor, as_completed from pathlib import Path from timeline import build MAX_WORKERS 3 # 从 核数/2 起步编码类任务超过这个数基本是负收益 def one(task): with tempfile.TemporaryDirectory(dirwork/tmp) as td: out Path(work/out) / f{task[task_id]}.mp4 out.parent.mkdir(parentsTrue, exist_okTrue) cmd build(task, pick_clips(task), out) # pick_clips 读 assets.json 按 tag 抽 r subprocess.run(cmd, capture_outputTrue, textTrue) if r.returncode ! 0: # stderr 动辄几十 KB只留尾部 800 字符避免日志文件失控 return task[task_id], False, r.stderr[-800:] return task[task_id], True, str(out) tasks list(csv.DictReader(open(work/plan.csv, encodingutf-8))) with ThreadPoolExecutor(max_workersMAX_WORKERS) as ex: futs [ex.submit(one, t) for t in tasks] for f in as_completed(futs): tid, ok, msg f.result() print((OK if ok else FAIL), tid, if ok else msg)tempfile.TemporaryDirectory在这里不是可选项。批量剪辑会产生大量中间音频、字幕、片段文件跑一晚上写满磁盘是血泪经验里的经典桥段。用上下文管理器异常路径也能回收。MAX_WORKERS3在 8 核机器上是保守值跑到 4 到 5 通常还能接受再往上就要看 ffmpeg 的线程设置了。4. 一键发布能自动到哪一步边界在哪里发布这一段最容易被高估。混剪是纯本地计算结果确定发布要跟外部系统打交道登录态、频率限制、内容审核都不在你手里。把它设计成「可失败、可重试、可人工接管」比追求全自动实际得多。4.1 三条路径的选型接口、浏览器自动化、清单式半自动路径门槛稳定性适用场景开放接口需资质审核能力不齐高有明确错误码有机构资质、量大且长期浏览器自动化需要维护选择器中页面改版即失效账号少、发布频率低清单式半自动几乎为零高人工兜底起步阶段、账号在养常见的顺序是先跑清单式半自动把内容质量和账号状态摸清楚再考虑前两条。一上来就硬上浏览器自动化选择器一变整条链路就断而且账号状态出问题时你很难判断是内容问题还是自动化行为被识别。4.2 用 Playwright 做「填好一切、留最后一下」的发布我一般会把自动化停在提交按钮之前文件传完、标题填好、话题带上剩下封面选择和最后点击留给人。这样保留了大量自动化收益又不会被平台的频率策略盯上。# publish.py —— 半自动发布填好最后一步留给人确认 import random, time from pathlib import Path from playwright.sync_api import sync_playwright # 一个账号对应一个持久化目录绝不共用 ACCOUNTS {acct_a: profile/acct_a, acct_b: profile/acct_b} def fill_publish(page, video: Path, caption: str): page.goto(https://创作者后台/upload, wait_untildomcontentloaded) page.set_input_files(input[typefile], str(video)) page.wait_for_selector(text上传完成, timeout180_000) # 大文件给足时间 page.fill(textarea[placeholder*标题], caption) # 到这一步停下人工确认封面、话题、定时再点发布 page.pause() with sync_playwright() as p: acct acct_a ctx p.chromium.launch_persistent_context( user_data_dirACCOUNTS[acct], headlessFalse, viewport{width: 1440, height: 900}) page ctx.pages[0] if ctx.pages else ctx.new_page() fill_publish(page, Path(work/out/t001-3f9a1c2b-v0.mp4), 标题文案 #话题) time.sleep(random.uniform(0.5, 2.0)) # 节奏别整齐得像机器 ctx.close()launch_persistent_context配user_data_dir是关键设计。登录态存在目录里一次登录能用很久不同账号用不同目录就不存在「A 账号的 cookie 串到 B 账号」这种事。headlessFalse是有意为之——半自动环节本来就需要人看着无头模式反而增加排查难度。page.pause()会在这里挂起等人手动操作完再继续。批量场景下更常见的做法不是暂停而是把待发布清单生成成一页 HTML逐条点开后台、人工发布、回来打勾。哪种都行核心是把「不可控的提交动作」和「可控的准备工作」分开。4.3 频率、重试与账号隔离发布环节最贵的不是代码是账号。几条硬规矩单账号每天发布条数按平台正常创作者的节奏走别一晚上刷 30 条两条之间留 2 到 10 分钟随机间隔失败重试最多两次两次都失败就进人工队列不要无限重试同一台机器上同时操作的账号数控制在一两个。重试逻辑写成幂等的最好发布前先查一次「这条 task_id 是否已经发过」用一个本地 json 记录{task_id: {account, status, time, url}}。翻车之后重启流水线从记录里读状态只补没发成功的比重新跑一遍再人工去重省太多时间。5. 避坑与排查批量混剪最容易翻车的 5 个地方这一节全是踩过的。每一条都按「现象 → 原因 → 解决」写遇到时对号入座。第一条成片越往后越音画不同步。现象是 30 秒的片子里前 5 秒字幕还对得上到 25 秒人声已经比嘴型晚半拍。原因是音频采样率不一致——TTS 输出 44.1kHzBGM 是 48kHzamix 时 ffmpeg 做了隐式重采样而重采样会引入微小漂移段数越多累积越明显。解决办法是把aresample48000显式挂在每一路音频上输出再固定-ar 48000别指望默认值。改完重跑漂移直接消失。第二条转场处闪黑一帧。单条抽检很难发现批量跑完一合辑就特别刺眼。原因有两个一是 xfade 的 offset 写成了i * seg转场落在上一段结束之后二是两段素材的像素格式不同xfade 内部转换失败。解决是先formatyuv420p再 xfadeoffset 用i * (seg - tr)并且给每段加setptsPTS-STARTPTS。这三个改完闪黑基本绝迹。第三条跑到第 20 多条时磁盘满了。现象是后面全部返回非零退出码日志里是No space left on device。原因是中间文件没清理加上有些失败任务留下了半截 mp4。解决办法是用TemporaryDirectory包住每条任务输出目录单独挂载并且加一条启动前检查剩余空间少于任务数 × 预估单条体积 × 3就拒绝启动。这个预估值跑两批就有数了。第四条发布脚本跑了三条账号登录态失效。现象是脚本卡在等待元素超时退出手动打开浏览器发现要重新登录。原因是多个账号共用了一个浏览器数据目录或者上一次会话没正常关闭。解决办法是一账号一user_data_dir脚本退出前调ctx.close()并且加一个「登录态自检」步骤进入后台先判断是否出现登录框出现就停机并告警不要带着失效态继续跑。第五条字幕整体偏移、或者烧录后字号忽大忽小。原因是先烧字幕再统一缩放缩放系数把字号一起改了另一种是 SRT 的断句和配音不一致。解决办法是把统一缩放放在最前面字幕烧录放在时间线拼好之后用subtitlesxxx.srt:force_style...直接烧在最终分辨率上。断句问题回到第 2 章配音和字幕一次生成别分两套逻辑。6. 验收用抽检矩阵把「看起来还行」变成可判定批量生产最危险的状态是「没人看得过来」。50 条成片人工每条看 10 秒也要 8 分钟而且注意力很快就不靠谱了。我的习惯是让程序先过一遍硬指标人只看被标记出来的那几条。六个维度够用了时长偏差、分辨率与帧率、黑帧段数、静音段、整体响度、首帧是否为黑。前五个能全自动判定首帧黑不黑直接决定封面观感值得单独查。# qc.py —— 成片硬指标抽检输出可疑项 import json, re, subprocess from pathlib import Path def run(cmd): return subprocess.run(cmd, capture_outputTrue, textTrue).stderr def qc(p: Path, target_s: int): info json.loads(subprocess.run( [ffprobe, -v, error, -show_entries, formatduration:streamcodec_type,width,height,r_frame_rate, -of, json, str(p)], capture_outputTrue, textTrue).stdout) dur float(info[format][duration]) v [s for s in info[streams] if s[codec_type] video][0] lufs re.findall(rI:\s*(-?\d\.\d) LUFS, run([ffmpeg, -i, str(p), -af, ebur128, -f, null, -])) black run([ffmpeg, -i, str(p), -vf, blackdetectd0.1:pix_th0.10, -f, null, -]) silence run([ffmpeg, -i, str(p), -af, silencedetectn-40dB:d1.2, -f, null, -]) return { file: p.name, dur: round(dur, 2), dur_dev: round(dur - target_s, 2), # 与目标时长偏差 res: f{v[width]}x{v[height]}, fps: v[r_frame_rate], i_lufs: float(lufs[-1]) if lufs else None, black: len(re.findall(rblack_start, black)), silence: len(re.findall(rsilence_start, silence)), }判定阈值我一般这么定dur_dev在 ±3 秒内算过超了说明素材抽少了black必须为 0silence出现 1 段以上就要看可能是 TTS 断句长了i_lufs落在 −16 到 −13 之间算过偏离 2 dB 以上重新混音。跑完把不达标的文件名打出来只人工看这些一条 10 秒的话50 条里通常只有五六条需要看。这套矩阵真正的价值不在于省时间而在于它把「感觉这批片子有点糊」变成「第 17 条的响度是 −19.2 LUFS重混」。批量做久了最大的教训就是这个能被程序判定的东西千万别交给眼睛和耳朵人的注意力是最先崩的那一环。希望帮到你。本文还有配套的精品资源点击获取