1. 项目缘起与整体思路拆解1.1 为什么三个人的小团队要自己搭视频流水线先说背景。我们团队一共三个人一个负责脚本和文案一个负责剪辑和后期我负责技术。日常业务需要大量产出短视频内容主要是知识科普和产品介绍类每条视频大概三到五分钟需要配音、字幕、画面素材拼接、背景音乐、片头片尾。一开始我们用的是人工流程写稿、录音、剪辑软件里拖时间线、手动加字幕。一条视频从脚本到成片熟练工也要三到四个小时。三个人一天最多出两三条产能完全跟不上需求。外包配音和剪辑的成本我们也算过。配音按字数计费一条三分钟的视频大概八百到一千字外包配音加后期剪辑单条成本在三百到六百之间。一个月出六十条光外包费就两万起步。而且沟通成本极高改一版等一天节奏完全不受自己控制。所以核心诉求很明确用最低的硬件成本把视频生产流程自动化把单条视频的制作时间压缩到十分钟以内同时保证输出质量稳定可控。我们三个人用的都是普通办公笔记本没有独立显卡更不可能去买服务器。这就决定了整个方案必须走云端 API 加本地开源工具的路子本地只做轻量的编排和合成。1.2 整体架构API 负责智能开源工具负责合成整个流水线的设计思路可以用一句话概括让云端大模型和语音合成 API 做它们擅长的事让本地开源工具做它们擅长的事中间用脚本串起来。具体分工是这样的。文案生成和分镜脚本交给大语言模型 API我们用的是 DeepSeek 的官方接口主要是便宜、中文理解好、响应快。语音合成用 edge-tts这是微软 Edge 浏览器内置的语音引擎通过开源 Python 库调用完全免费音色自然度在免费方案里属于第一梯队。视频合成用 ffmpeg这是音视频处理领域的瑞士军刀命令行操作可以脚本化批量处理。字幕生成用 whisper 的轻量版本或者直接让大模型按时间轴输出我们两种方案都试过后面会详细说。为什么不直接用剪映或者 CapCut 的自动剪辑功能因为我们需要批量化和可编程。剪映适合单条精修但我们要的是流水线是输入一个主题、输出一条成片的全自动流程。ffmpeg 虽然学习曲线陡但一旦脚本写好批量处理一百条和一条的时间成本几乎一样。提示这套方案的核心不是某个工具多厉害而是把多个免费或低成本的工具用脚本串成流水线。单点工具都有替代品但流水线的思路是可以复用的。1.3 硬件和成本的真实账本先算硬件账。三台笔记本配置分别是两台 Windows 轻薄本和一台 MacBook Air M1都没有独立显卡。本地跑 Stable Diffusion 或者本地大模型完全不现实所以所有 AI 推理都走云端 API。再算 API 成本。DeepSeek 的 API 价格在同类产品里属于很低的档位我们生成一条三分钟视频的脚本大概消耗两千到三千 token按官方定价算下来单条成本不到一毛钱。edge-tts 完全免费没有调用次数限制。ffmpeg 开源免费。所以整个流水线的边际成本几乎可以忽略不计主要成本是前期搭建的时间投入。这里要特别说明一点零显卡不等于零算力。我们只是把算力需求转移到了云端本地只负责网络请求和文件处理。这个思路对于预算有限的小团队来说非常关键不要被“本地部署”的思路框住。1.4 适合谁来参考这套方案这套方案适合以下几类人一是内容创业小团队需要批量产出视频但预算有限二是个人自媒体想提升更新频率但不想学复杂的剪辑软件三是技术爱好者想了解 AI 能力如何与传统音视频工具结合。不适合的情况也要说清楚如果你需要电影级画质、复杂的转场特效、精细的色彩调整这套方案满足不了还是得用专业剪辑软件。我们的定位是稳定产出合格线以上的内容不是追求艺术品质。2. 核心工具选型与关键细节解析2.1 大语言模型 API 的选择与调用要点我们对比过几个主流的大模型 API。DeepSeek 的优势在于中文脚本生成质量稳定对分镜格式的理解准确而且价格便宜。智谱的 API 我们也试过质量也不错但在长文本分镜生成上偶尔会漏掉时间轴信息。免费额度和稳定性需要综合考虑我们最终主力用 DeepSeek备用智谱。调用方式很简单Python 的 requests 库直接发 POST 请求就行。关键是要把 prompt 设计好。我们的 prompt 模板大概是这样的结构先给角色设定说明是短视频脚本再给输出格式要求明确每一段的时间轴、画面描述、旁白文案最后给主题和风格要求。输出格式我们强制要求 JSON方便后续程序解析。import requests import json def generate_script(topic, duration180): prompt f你是一个短视频脚本编剧。请为主题{topic}生成一个{duration}秒的视频脚本。 输出格式为JSON数组每个元素包含 - start: 开始时间秒 - end: 结束时间秒 - visual: 画面描述 - narration: 旁白文案 要求旁白总字数控制在{int(duration/3.5)}字左右语速适中。 response requests.post( https://api.deepseek.com/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.7 } ) return json.loads(response.json()[choices][0][message][content])这里有个坑要注意大模型输出的 JSON 有时候会带 markdown 代码块标记直接解析会报错。我的做法是在解析前先做字符串清洗把json 和去掉。另外 temperature 不要设太高0.7 左右比较合适太高了脚本会跑偏太低了又很死板。注意API key 千万不要硬编码在脚本里用环境变量或者配置文件管理。我们团队三个人共用一套脚本key 放在统一的配置文件中通过 .gitignore 排除避免泄露。2.2 edge-tts 的语音合成实战edge-tts 是我们整个流水线里最满意的环节。安装很简单pip install edge-tts 就行。它的原理是调用微软 Edge 浏览器的在线语音合成服务所以需要联网但不需要任何 API key也没有调用次数限制。音色选择上中文推荐这几个zh-CN-XiaoxiaoNeural 是女声自然度最高适合知识科普zh-CN-YunxiNeural 是男声偏年轻适合产品介绍zh-CN-YunyangNeural 是男声偏沉稳适合新闻播报类。我们主力用 Xiaoxiao偶尔根据内容换 Yunxi。语速和音调的调整通过参数控制。默认语速是 0%我们一般设成 10% 到 15%因为短视频节奏需要快一点。音调默认就行调多了反而不自然。edge-tts --voice zh-CN-XiaoxiaoNeural \ --rate12% \ --text 这里是需要合成的文案内容 \ --write-media output.mp3批量合成的时候我们写了一个 Python 脚本把脚本里的旁白按段落切分逐段合成然后按时间轴拼接。这里有个细节edge-tts 每次合成会有几十毫秒的静音头尾如果直接拼接会有明显的停顿感。我的处理方式是用 ffmpeg 的 silenceremove 滤镜把首尾静音裁掉再拼接。ffmpeg -i segment.mp3 -af silenceremovestart_periods1:start_threshold-50dB:start_silence0.1 output.mp3实测下来edge-tts 的合成速度大概是实时语速的十倍左右三分钟的音频大概二十秒就能合成完。稳定性方面偶尔会遇到网络超时加重试机制就行我们设的是重试三次间隔两秒。2.3 ffmpeg 的核心作用与命令拆解ffmpeg 是整个流水线的合成引擎负责把音频、图片、字幕、背景音乐拼成最终视频。它的功能极其强大但命令参数也确实复杂。我刚开始用的时候光是理解 -filter_complex 就花了两天。这里把我们的核心用法拆开讲。最基本的合成命令是把一张图片和一段音频合成视频ffmpeg -loop 1 -i background.jpg -i narration.mp3 \ -c:v libx264 -tune stillimage -c:a aac -b:a 192k \ -pix_fmt yuv420p -shortest output.mp4参数解释-loop 1 让图片循环-tune stillimage 优化静态图片编码-shortest 让视频长度跟随音频-pix_fmt yuv420p 保证兼容性。这个命令是所有合成的基础模板。如果要加字幕用 subtitles 滤镜ffmpeg -i input.mp4 -vf subtitlessubtitle.srt:force_styleFontSize24,PrimaryColourHFFFFFF output.mp4字幕样式可以在 force_style 里调字体大小、颜色、描边、位置都能控制。我们一般用白色字体加黑色描边保证在任何背景上都看得清。背景音乐的处理稍微复杂一点需要把旁白和背景音乐混音同时背景音乐音量要压低ffmpeg -i narration.mp3 -i bgm.mp3 \ -filter_complex [1:a]volume0.15[bgm];[0:a][bgm]amixinputs2:durationfirst \ output.mp3volume0.15 是把背景音乐降到 15% 音量amix 是混音durationfirst 表示以第一路音频的长度为准。这个比例是我们试出来的15% 左右既能听到背景音乐又不影响旁白清晰度。2.4 字幕生成的两种方案对比字幕生成我们试过两种方案各有优劣。第一种是用 whisper 本地转写。whisper 有不同大小的模型tiny 和 base 版本在普通笔记本上跑没问题不需要显卡。但准确率一般尤其是专业术语容易错。medium 以上准确率好很多但没显卡跑起来很慢三分钟音频要跑十几分钟不实用。第二种是让大模型直接输出带时间轴的字幕。我们在生成脚本的时候就要求大模型按句输出每句带开始和结束时间。然后程序把旁白文案和时间轴转成 SRT 格式。这个方案的好处是零额外成本时间轴和脚本天然对齐。坏处是大模型给的时间轴是估算的和实际语音合成后的时长有偏差。我们最终的方案是混合用大模型生成初始时间轴然后用 edge-tts 合成后获取每段音频的实际时长按比例调整时间轴。这样既省去了语音识别的步骤又保证了字幕和语音对齐。方案准确率速度成本适用场景whisper tiny/base中等快免费对字幕要求不高的场景whisper medium高慢无显卡免费有显卡或能等待的场景大模型直接输出中等快极低脚本和字幕同步生成的场景混合方案高快极低推荐方案3. 完整流水线的实操过程3.1 环境准备与依赖安装先说环境。三台电脑分别是 Windows 11 和 macOSPython 版本统一用 3.10太新的版本有些库兼容性不好。ffmpeg 需要单独安装Windows 上推荐用 winget 或者直接下载编译好的二进制文件macOS 用 brew install ffmpeg 就行。Python 依赖主要这几个requests 用于 API 调用edge-tts 用于语音合成pydub 用于音频处理srt 用于字幕文件生成。安装命令一行搞定pip install requests edge-tts pydub srtffmpeg 安装后要确认在命令行能直接调用Windows 上需要把 ffmpeg 的 bin 目录加到 PATH 环境变量里。验证方法是运行 ffmpeg -version能看到版本信息就说明装好了。提示ffmpeg 的 GPL 和 LGPL 版本区别主要在于是否包含某些特定编码器。我们用的功能不涉及这些所以哪个版本都行。Windows 上直接下载官方推荐的编译版本即可。3.2 从主题到脚本API 调用的完整流程整个流水线的入口是一个主题关键词比如“如何提高工作效率”。程序拿到主题后第一步是调用大模型 API 生成结构化脚本。我们的脚本生成分两步走。第一步生成大纲确定视频分几个部分、每部分讲什么。第二步基于大纲生成详细的分镜脚本包括每段的旁白文案和画面描述。分两步的好处是结构更清晰避免大模型一次性生成太长内容导致质量下降。def generate_outline(topic): prompt f为主题{topic}生成一个3分钟短视频的大纲分4-5个部分每部分用一句话概括。 # 调用API... return outline def generate_detailed_script(topic, outline): prompt f基于以下大纲为主题{topic}生成详细分镜脚本。 大纲{outline} 输出JSON数组每个元素包含start、end、visual、narration字段。 # 调用API... return script这里有个经验prompt 里一定要给输出格式的示例。我们一开始只说了“输出 JSON”结果大模型返回的字段名每次都不一样。后来在 prompt 里加了一个完整的示例输出就稳定了。API 调用的错误处理也要做好。常见错误有网络超时、额度不足、返回格式异常。我们的做法是每个错误类型单独处理超时重试额度不足发通知格式异常则尝试用正则提取 JSON 部分。3.3 语音合成与时间轴对齐拿到脚本后下一步是把旁白文案逐段合成语音。这里的关键是时间轴对齐。具体做法是先把脚本里的旁白按段落切分每段单独合成音频文件。合成完成后用 ffprobe 获取每段音频的实际时长。然后根据实际时长重新计算每段的时间轴确保字幕和画面切换与语音同步。import subprocess import json def get_audio_duration(filepath): result subprocess.run( [ffprobe, -v, quiet, -print_format, json, -show_format, filepath], capture_outputTrue, textTrue ) return float(json.loads(result.stdout)[format][duration])拿到每段实际时长后累加得到总时长然后按比例调整大模型给的初始时间轴。如果某段实际时长和预估偏差超过 30%我们会重新调整该段的文案长度或者调整语速参数重新合成。这个环节的注意事项edge-tts 合成是并发的但不要开太多线程否则容易被限流。我们设的是同时最多五个请求实测稳定。3.4 画面素材的准备与处理画面素材我们主要用三种来源一是免费图库的图片二是用 AI 生成的配图三是简单的文字卡片。免费图库推荐 Pexels 和 Unsplash都有 API 可以按关键词搜索下载。我们写了一个函数根据分镜里的 visual 描述提取关键词自动搜索下载相关图片。AI 生成配图我们用的是国内可访问的文生图 API按张计费成本很低。但生成速度不稳定所以只在高优先级视频里用。文字卡片是用 ffmpeg 的 drawtext 滤镜生成的适合纯文字内容。比如关键数据、要点总结这类画面直接用文字卡片比找图更清晰。ffmpeg -f lavfi -i colorc0x1a1a2e:s1920x1080:d5 \ -vf drawtexttext关键要点:fontsize72:fontcolorwhite:x(w-text_w)/2:y(h-text_h)/2 \ card.mp4所有素材统一处理成 1920x1080 分辨率图片用 scale 和 pad 滤镜适配避免变形。3.5 最终合成ffmpeg 命令的组装与执行所有素材准备好后最后一步是用 ffmpeg 合成。我们的做法是先生成每个片段的视频再用 concat 拼接。单个片段的合成命令模板ffmpeg -loop 1 -i segment_image.jpg -i segment_audio.mp3 \ -vf scale1920:1080:force_original_aspect_ratiodecrease,pad1920:1080:(ow-iw)/2:(oh-ih)/2,subtitlessegment.srt \ -c:v libx264 -tune stillimage -c:a aac -b:a 192k \ -pix_fmt yuv420p -shortest segment_video.mp4所有片段合成完后用 concat 拼接ffmpeg -f concat -safe 0 -i filelist.txt -c copy final_video.mp4filelist.txt 里列出所有片段文件的路径。-c copy 表示直接复制流不重新编码速度极快。最后加上片头片尾和背景音乐一条视频就完成了。整个流程从主题输入到成片输出实测平均耗时八到十二分钟其中大部分时间花在 API 调用和素材下载上ffmpeg 合成本身很快。4. 常见问题与排查技巧实录4.1 API 调用失败的典型场景与解决问题一返回 400 错误提示 context length 超限。这个我们遇到过几次原因是分镜脚本太长加上 prompt 超过了模型的上下文窗口。解决办法是把长脚本拆成多次调用每次只处理一部分。另外可以在 prompt 里明确要求“简洁输出”减少不必要的描述。问题二返回内容不是合法 JSON。大模型有时候会在 JSON 前后加解释性文字或者用 markdown 代码块包裹。我们的处理方式是先用正则提取第一个 { 到最后一个 } 之间的内容再尝试解析。如果还失败就调用一次修复 prompt让模型重新输出纯 JSON。问题三API key 无效或额度不足。这个错误信息很明确检查 key 是否正确、账户是否有余额即可。我们设了额度预警低于一定金额就发邮件通知。问题四网络超时。国内访问某些 API 偶尔会超时加重试机制就行。我们的重试策略是三次间隔分别是 2 秒、5 秒、10 秒。4.2 edge-tts 合成中的坑与应对edge-tts 最常见的问题是网络不稳定导致合成失败。表现是命令执行到一半报错退出或者生成的音频文件不完整。我们的应对方式是每次合成后检查文件大小和时长异常就重试。另一个问题是音色不一致。edge-tts 的不同音色在语速、停顿习惯上有差异如果一条视频里混用了多个音色听起来会很奇怪。我们的做法是一条视频固定用一个音色需要区分角色时通过语速和音调微调来区分。还有一个细节edge-tts 对某些标点符号的处理和预期不一样。比如省略号会停顿很久破折号有时候会被忽略。我们的做法是在文案阶段就把这些符号替换成更明确的表达比如省略号换成句号破折号换成逗号。4.3 ffmpeg 合成报错速查ffmpeg 的报错信息有时候很晦涩这里整理几个我们常遇到的报错信息原因解决方法No such filter: subtitles编译时未包含 libass换用包含 libass 的编译版本Invalid argument参数格式错误检查参数拼写和格式Permission denied文件被占用或无权限关闭占用程序检查文件权限Conversion failed编码器不支持换用 libx264 或检查编码器安装Output file is empty输入文件有问题检查输入文件是否完整注意ffmpeg 的命令参数顺序很重要输入文件在前输出文件在后滤镜参数放在对应输入之后。顺序错了会报各种奇怪的错误。4.4 字幕不同步的排查思路字幕不同步是最常见的问题表现是字幕比语音快或者慢。排查思路是这样的先检查时间轴来源。如果是大模型直接给的偏差通常在一到两秒属于正常范围。如果是 whisper 转写的检查音频采样率是否一致。再检查合成环节。edge-tts 合成的音频首尾有静音如果没裁掉会导致实际语音比时间轴晚开始。用 silenceremove 滤镜处理后就能对齐。最后检查拼接环节。如果多个片段拼接时时间轴没有累加正确后面所有字幕都会偏移。我们的做法是每个片段单独生成字幕拼接时字幕也按顺序拼接避免全局时间轴计算错误。4.5 批量处理时的性能优化经验批量处理一百条视频和一条视频瓶颈完全不一样。单条视频的瓶颈在 API 调用和网络下载批量处理的瓶颈在 CPU 和磁盘 IO。我们的优化措施API 调用和素材下载用异步并发ffmpeg 合成用队列串行。因为 ffmpeg 本身会吃满 CPU并发跑多个合成任务反而更慢。实测下来串行合成加异步下载整体效率最高。另外临时文件要及时清理。每条视频的中间文件加起来有好几百 MB不清理的话磁盘很快就满了。我们在每条视频完成后自动删除临时目录只保留最终成片和脚本源文件。5. 实际运行效果与个人体会5.1 产能和成本的真实数据跑了一个月下来数据是这样的平均每天产出八到十条视频单条从主题输入到成片输出平均十分钟。三个人分工是一个人负责选题和审核脚本一个人负责检查成片质量我负责维护流水线和处理异常。成本方面API 调用费用一个月不到五十块其他全是免费工具。相比之前外包每月两万多的成本省下来的钱相当可观。当然前期搭建花了我大概两周的业余时间这个时间投入要算进去。质量方面说实话肯定比不上专业剪辑师精修的效果但用于日常内容更新完全够用。观众反馈里很少有人吐槽制作质量说明合格线以上的内容大家是能接受的。5.2 这套方案最值得复用的几个点第一个是流水线思维。不要想着用一个工具解决所有问题而是把问题拆开每个环节用最合适的工具。API 做智能生成开源工具做确定性处理脚本做编排。第二个是时间轴对齐的处理方式。先估算再按实际时长调整这个思路可以用在任何需要音画同步的场景。第三个是错误处理和重试机制。自动化流程最怕的就是中途失败做好错误分类和重试能省掉大量人工干预。5.3 后续可以扩展的方向目前这套流水线还是以图片加旁白为主画面比较静态。后续想加入一些动态元素比如简单的动画效果、转场过渡。ffmpeg 的 zoompan 滤镜可以实现图片缓慢缩放xfade 滤镜可以做转场这些都在测试中。另一个方向是接入更多的素材来源比如自动从视频素材库匹配相关片段。这个技术难度不大主要是素材版权和搜索准确率的问题。还有一个想法是把整个流程做成 Web 界面让团队里不写代码的成员也能直接操作。用 FastAPI 搭个简单的后端前端用现成的低代码工具这个还在规划中。说实话这套方案不是什么高深的技术核心就是把免费工具用对地方用脚本串起来。零显卡不是限制关键是思路要对。我们踩过的坑基本都写在上面了希望能帮到有类似需求的团队。