简介这套全自动短视频引擎面向短视频创作者、自媒体运营及AI工具爱好者针对“从主题到成片”耗时长、工序繁琐的痛点只需输入主题或关键词即可自动生成文案、素材、字幕与背景音乐并合成高清短视频还支持一键将音视频转为小红书/公众号/知识笔记/思维导图/视频字幕等不同风格文档。压缩包共291个文件以98个Python脚本作为核心逻辑配合42个Markdown说明文档、31个HTML页面、30个JSON配置及批量启停脚本等整体仅8.35MB体量轻巧却功能完整。已有71人学习下载适合希望快速搭建自动化短视频生产线或研究AI内容生成流程的入门与进阶用户。通过阅读脚本注释和文档可二次修改调整生成风格与模板形成属于自己的内容工厂。1. 全自动短视频引擎不是「一键生成」而是一条无人值守的生产流水线先把话说清楚市面上绝大多数 AI 短视频工具解决的是「从一句话到一条片子」但「AI 全自动短视频引擎」解决的是另一件事——让「选题、脚本、配音、画面、字幕、剪辑、成片」这一整条链路在无人值守的情况下批量跑完。换句话说它要的不是帮某个创作者省掉一次剪辑而是把「生产短视频」这件事本身做成一个可以挂机运行的流水线。这个方向的受众很明确做矩阵号的团队、做批量素材分发的运营、以及手里有几十个账号需要持续出片的内容工作室。反直觉的结论是全自动引擎最难的部分根本不是 AI 生成而是流程编排和失败恢复——让一条流水线在半夜两点跑挂之后还能自己爬起来比让画面好看难得多。2. 引擎的模块拆分从选题到成片每一步都是独立 worker2.1 为什么不用「一个大脚本跑到底」全自动的关键是状态机很多人第一次接触这类引擎第一反应是「我把工具栏里的功能拼成一个 Python 脚本不就行了」。表面上看确实可以写一个脚本依次调用大模型生成文案、调用 TTS 合成语音、调用文生图接口出画面、再用 FFmpeg 拼成视频。但这样做的结果必然是翻车——因为短视频生产的每一步都有概率失败而且失败的方式千奇百怪大模型返回了空字符串、TTS 服务超时、图片生成接口报错、FFmpeg 编码到一半进程被杀。如果是一个线性脚本任何一步失败整条任务就得从头再来而从头再来的代价是前面已经花掉的 API 费用和等待时间全部报废。正确的做法是引入状态机思维把整条流水线拆成「选题 → 脚本 → 配音 → 画面 → 字幕 → 渲染 → 发布」若干个独立状态每个状态之间的数据通过文件或数据库传递每个状态都可以单独重试、单独跳过、单独人工介入。这就是「引擎」和「脚本」的本质区别——脚本是一条路走到黑引擎是每个节点都在记账。具体到实现上我会用 Python 里的枚举或者简单的状态字典来定义每一条视频任务的生命周期。一个比较实用的状态定义是这样的from enum import Enum class TaskState(str, Enum): WAITING waiting # 排队中还没开始 TOPIC_GENERATED topic_done # 选题已生成 SCRIPT_GENERATED script_done # 脚本已生成 AUDIO_GENERATED audio_done # 配音已生成 VISUAL_GENERATED visual_done # 画面素材已生成 RENDER_READY render_ready # 所有素材就绪可以渲染 RENDERED rendered # 成片已输出 PUBLISHED published # 已发布或已转存 FAILED failed # 终态需要人工介入这段状态的逻辑很清楚每个任务在数据库里都有一个 current_state 字段引擎的调度器只做一件事——扫描所有任务看哪些任务满足「上一个状态已经完成」的条件然后把它们推进到下一个状态。这样做的好处是某个任务在渲染阶段崩溃了重启引擎后只需要找到那个卡在 render_ready 之前的任务从断点继续跑而不是重新生成一遍文案和配音。2.2 六大模块的职责边界与数据流引擎的功能模块划分我一般按「内容生产」和「工程支撑」两个维度来拆。内容生产侧是四件事选题生成、脚本撰写、语音合成、画面生成。工程支撑侧也是两件事渲染合成、任务调度。有人会把「发布」也纳入引擎但我的建议是发布单独拆出去因为各平台的发布接口风控策略一直在变把发布做成可插拔模块比做成引擎内置功能更稳妥。模块之间的数据流是沿着文件系统走的。每个任务在 workdir 下有一个独立目录结构大致是tasks/20250315_001/ ├── topic.txt # 选题 ├── script.json # 脚本含分镜信息 ├── audio/ │ └── scene_1.mp3 # 每段配音 ├── visual/ │ └── scene_1.png # 每段画面 ├── work/ │ └── temp_clips/ # 渲染中间产物 └── output/ └── final.mp4 # 成片这个目录结构是这套引擎最重要的「约定」——所有模块都只认目录和文件不直接互相调用函数。做选题的模块往 topic.txt 里写一行字做脚本的模块读到这行字之后生成 script.json后面的模块依此类推。这个设计可能看起来笨但实际运维时非常香任何一个模块挂了它下游的模块会一直等待或者标记失败而不会出现「A 模块的内存里还留着数据B 模块拿不到」这种黑匣子问题。所有中间产物都在磁盘上这既是后悔药也是排查问题时最直接的线索。2.3 消息队列与任务持久化让引擎在断电后还能继续干活如果只是本地跑几条视频用文件目录调度就够了。但引擎要解决的是「没人值守」没人值守最怕的是进程挂掉。所以任务状态一定要落在数据库里不能用内存变量扛着。我的做法是用 Redis 做队列用 SQLite单机场景或 PostgreSQL多机场景做任务表。为什么用 Redis 而不是直接扫数据库因为 Redis 的 BRPOP 可以阻塞等待调度器不需要轮询数据库省掉大量无效查询。任务状态则必须持久化到数据库里Redis 只当信号灯用。一个典型的任务投递流程是这样的import redis import json import sqlite3 r redis.Redis(hostlocalhost, port6379, db0) def submit_task(topic, params): task_id ftask_{int(time.time())} # 先写数据库持久化 conn sqlite3.connect(engine.db) conn.execute( INSERT INTO tasks (id, topic, state, params) VALUES (?, ?, ?, ?), (task_id, topic, waiting, json.dumps(params)), ) conn.commit() conn.close() # 再往队列里丢一个消息 r.rpush(engine:queue, json.dumps({task_id: task_id})) return task_id这段代码里有个细节必须先写数据库、再往队列里投递。如果反过来消费端从队列里拿到 task_id 再去数据库查发现任务不存在就会空转甚至报错。先写库再投递能保证消费端任何时候都能查到完整任务。这是全自动引擎最基础的可靠性设计——宁可队列里多一条重复消息不能让队列里的消息对应不上真实任务。3. 把引擎跑起来最小部署与第一条成片3.1 Python 3.11 Redis FFmpeg这套组合的选型理由拿到压缩包之后第一件事不是跑代码而是先把环境确认清楚。这套引擎的运行时依赖非常固定Python 3.11 以上、Redis 6.2 以上、FFmpeg 4.4 以上。Python 3.11 之前版本对 asyncio 的支持不够顺滑而调度器要同时管几十个任务异步是刚需Redis 负责队列和轻量缓存选它是因为生态成熟、单机部署简单FFmpeg 负责所有视频合成和转码没有替代品。操作系统方面建议直接用 LinuxUbuntu 22.04 或 Debian 12因为之后要挂后台跑Windows 的进程管理和开机自启都太别扭。如果手上只有 Windows 机器用 WSL2 也行但注意 WSL2 里 Redis 的网络配置和文件 IO 性能都要单独调新手建议直接用一台 2C4G 的云服务器起步一个月成本不高但能省掉大量本地环境折腾的时间。3.2 解压工程与安装依赖三个容易卡住的细节假设你已经把 AI 全自动短视频引擎.zip 解压到了 ~/engine 目录。安装依赖前先看一遍 requirements.txt 里锁了哪些版本。引擎类项目最怕依赖冲突尤其是一旦用了 torch 或者 diffusers 这类重库版本错一个就全链跑不起来。我一般会创建一个干净的虚拟环境再装cd ~/engine python3.11 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt如果机器上没装 Python 3.11 或者默认 python 版本不对用 deadsnakes 或者源码编译都会浪费不少时间。所以装依赖前先跑一下python --version确认版本版本不对就别硬装先把解释器换对。这是第一个容易卡住的点。第二个容易卡住的点是 FFmpeg 的 PATH。引擎在渲染阶段会调用 FFmpeg 可执行文件如果你用的是静态编译版 FFmpeg记得把解压目录加进 PATH或者直接在引擎的配置里指定 ffmpeg_path 为绝对路径。第三个点是 Redis 的密码和端口默认引擎会连 localhost:6379如果你改了 Redis 配置在 config 文件里同步改掉否则任务会一直卡在「投递成功但消费端收不到」的状态表面上人畜无害实际队列已经堵死了。3.3 修改配置第一次打开这个「黑匣子」依赖装好之后去 config 目录下找到配置文件。这套引擎的核心配置有两块模型 API 配置和生产参数配置。模型 API 配置是让引擎能调用大模型、TTS、图片生成服务的钥匙生产参数配置决定「一条视频怎么做出来」。用 YAML 管理配置是个好习惯我一般把敏感配置拆到独立文件里并用环境变量引用避免不小心把 key 提交到代码仓库。一个常见的最小化配置长这样# config/engine.yaml engine: workdir: ./tasks concurrency: 3 # 同时执行的任务数先别调太大 redis_url: redis://localhost:6379/0 llm: provider: openai_compatible base_url: http://localhost:8000/v1 # 本地推理服务的地址 model: qwen2.5-7b-instruct api_key: ${LLM_API_KEY} tts: provider: edge_tts # 免费、速度快适合起步 voice: zh-CN-YunxiNeural rate: 8% # 语速比默认快 8%后面细说 visual: provider: stable_diffusion base_url: http://localhost:7860 steps: 25 # 采样步数步数越多越慢 width: 720 height: 1280 # 竖屏 9:16 render: fps: 30 resolution: [720, 1280] subtitle_font: /usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc bgm_volume: 0.25这段配置看起来平平无奇但每一条都是踩过坑之后的产物。比如 visual.height 从 1080 改到 1280是因为视频平台对竖屏素材的推荐分辨率是 720x1280而不是 1080x1920——后者文件体积大、上传转码慢但画质并不会更好。又比如 bgm_volume 我习惯先设到 0.25因为 AI 配音的响度普遍偏低BGM 稍微大一点人声就被淹了。3.4 用命令行跑通第一条流水线配置改好之后别急着把整个引擎推到后台先在前台跑一条测试任务。引擎一般会提供一个 CLI 入口比如 submit 命令。把任务投进去之后它会打日志告诉你每个节点的执行结果这是观察引擎运行状态最好的窗口。第一条任务建议用最简单的方式验证链路也就是直接指定一个选题文本让引擎全部自动完成python -m engine.cli submit \ --topic 为什么深夜刷短视频会越刷越清醒 \ --mode full_auto \ --duration 45 \ --output ./tasks/demo_001这条命令的关键参数是--mode full_auto表示从选题到成片全自动跑。跑之前先去终端开一个窗口监控引擎 worker 的日志命令是python -m engine.worker。看到日志里依次出现 TOPIC_GENERATED、SCRIPT_GENERATED、AUDIO_GENERATED、VISUAL_GENERATED、RENDER_READY 这些状态流转最后出现 RENDERED说明链路通了。第一次跑通时画面难看一点、配音断句怪一点都正常重点是确认状态机能完整走完一遍。链路通了后面所有调优都有意义链路不通调什么都是白费。第一次跑完去 output 目录看看 final.mp4 的大小和时长。如果时长跟预期不符比如你要求 45 秒生成出来只有 20 秒大概率是脚本阶段生成的分镜数太少导致画面不够撑。这个问题后面在参数调整章节单独说。4. 参数调优成本、速度与成片质量的三角平衡4.1 TTS 语音参数语速、停顿与音色到底怎么调全自动引擎里配音质量直接决定观众能不能听得下去。很多 AI 视频翻车第一句话就露馅——语速忽快忽慢、断句位置不对、机械感重。我自己常用的经验是先固定一个音色不要频繁换因为观众对声音是有记忆的。矩阵号尤其如此一个账号固定一个声音人设才立得住。engine.yaml 里 tts.voice 改成 zh-CN-YunxiNeural 和 zh-CN-YunyangNeural 出来的完全是两种气质一个偏年轻一个偏沉稳。语速 rate 这个参数不同平台的默认习惯不一样。抖音快手这类快节奏平台内容密度高语速比默认快 8% 到 12% 比较合适B 站和视频号快 4% 到 6% 就够了。切记不要统一设成 20%那样听起来像是在赶场子反而让完播率往下掉。断句方面如果引擎支持标点停顿权重把逗号的停顿时长稍微调长一点AI 配音读长句的时候会自然得多。4.2 画面生成节奏关键帧密度与转场时间的权衡画面部分最常见的翻车是「一个画面撑太久视频像幻灯片」。我一般建议一条 45 秒的竖屏视频划分 6 到 8 个分镜每个分镜的画面时长控制在 5 到 7 秒。在 visual 配置里每一步生成多少张候选图、每张图的提示词风格权重都是可调的。这里有个核心取舍文生图服务每生成一张图平均耗时 3 到 8 秒取决于硬件和采样步数而一条 45 秒的视频需要 6 到 8 张图这是纯串行的耗时。我习惯把这个过程拆成并行用多 agent 协作的方式让画面生成模块一次并行发起多个生图请求每个分镜同时生成两到三张候选图然后按「画面文字是否清晰、人物比例是否正常、与分镜描述的相关性」做一次简单评分选最好的那张进入渲染。这个方案的代价是 API 费用变成 2 到 3 倍但成片质量的提升值得这个成本。如果是本地跑并发数取决于显卡显存一张 8G 显存的卡不建议同时跑超过 2 个生图任务否则显存溢出直接 OOM。4.3 并发数与成本控制引擎最容易「杀不住车」的参数concurrency 是引擎里最危险也最好用的参数。它决定同时有多少个任务在飞。我看过有人把 concurrency 调到 20结果十几张显卡全部跑满API 账单一天下来吓死人。全自动引擎的核心价值是省人力不是烧机器所以并发数一定要结合成本上限倒推。比如你的预算是一天 500 次生图调用单条视频 8 张图那每天最多 62 条视频的量根据这个配额去反推 concurrency 值。一个稳妥做法是给引擎加一个「日配额」配置引擎每天投递的任务量达到阈值就自动停止接新任务等第二天再放开。调度器里本来就该有这种阀门但很多项目的默认配置是「无限跑」所以拿到任何引擎的第一步就是找到配额配置并设好上限。这是给所有后来者的建议别指望自觉要靠机制拦住。4.4 素材去重与查重矩阵号翻车的重灾区批量跑视频的时候最丑的不是画质差而是同一个选题下素材高度相似——两台手机刷到的内容一模一样平台一旦判重整个矩阵号都有风险。查重这件事一定要在引擎里做成硬节点而不是靠事后人工看。做法是每一帧画面生成后计算感知哈希pHash存到数据库里新画面生成时先查一遍现有库如果出现过相似的图就直接丢弃重生成。好在很多现成的图像去重库能直接用我一般用 imagededup 这个工具包它支持 CNN 特征提取比单纯算哈希准确不少。脚本和文案也要查重。大模型生成文案时如果提示词里没有加「与已有文案语义不同」的约束同一个选题下跑出来的两条文案可能只是换了几句话的位置。查重方面用一个简单做法就够了把已有文案向量化存库新文案进来算余弦相似度超过 0.85 就判定重复并重新生成。这个逻辑放在脚本生成模块里属于性价比最高的防翻车投入。5. 避坑指南全自动引擎最常见的 5 个翻车现场5.1 现象任务卡死在「渲染中」队列越积越长引擎跑了一个晚上第二天早上看日志发现所有任务都停在 RENDER_READY 和 RENDERED 之间队列里堆了上百条消息。原因FFmpeg 进程因为编码参数错误而静默退出渲染模块又没有检查退出码任务状态一直停在渲染中。最常见的是字体文件路径不存在导致字幕滤镜失败但 FFmpeg 的报错信息被吞掉了看起来像卡死。解决在渲染模块里强制检查 FFmpeg 的 return code并设置超时。FFmpeg 渲染一条 45 秒视频正常机器 2 分钟内一定能完成超过 5 分钟直接杀进程并标记失败。同时把 FFmpeg 的 stderr 完整记录到日志文件里排查时第一件事就是去翻这段输出。5.2 现象成片音画不同步字幕比声音慢半拍生成出的视频播放到中后段字幕和嘴形对不上有时字幕先出、声音后到有时反过来。原因引擎分两条链路在处理——一条生成画面序列一条合成配音最后渲染阶段才合流。当配音比较长、而画面分镜数量不够时引擎为了撑时长会给某些画面重复加长导致音轨和字幕轨的时间基准错位。解决把字幕的渲染从「后期压进视频」改成「先用字幕文件确定时间轴再渲染画面」。也就是强制以字幕文件的时间轴为准画面长度必须服从时间轴不允许反过来。在配置里找到subtitle_align: true这个开关打开它问题就能解决。5.3 现象同一个选题跑十次十次画风完全不一样做系列视频时第一条是写实风格第二条变成了插画风第三条又像纪录片。整个账号的内容风格乱了套。原因文生图的提示词里缺少风格锚点。大模型对「保持同样风格」的理解比我们想象中弱得多它每次都重新理解一遍提示词。解决在 visual 模块的提示词拼接逻辑里把所有分镜共用的一段「风格锚点」前置固定。比如统一加上 cinematic lighting, photorealistic, 35mm lens, muted color palette 这一段然后设置风格权重为固定值。更省事的做法是选一个固定的 LoRA 或者风格模型引擎配置里指向同一个模型标识画风问题才算根治。5.4 现象批量跑完几千条后本地磁盘被中间产物占满任务跑完成片也发了但磁盘空间告警。一看全是 work 目录下的临时素材和音频原始文件。原因任务清理策略没启用或者清理策略只清理 output 目录忘了清理 work 目录里的中间产物。解决把中间文件的保留期限设置为 48 小时。任务状态变为 PUBLISHED 后启动一个定时清理任务把该任务 work 目录下所有文件删除只保留最终成片。如果想让施工过程有后悔药那就保留 72 小时超过直接删。磁盘满导致引擎宕机的代价比误删中间文件高得多。5.5 现象AI 生成画面里出现乱码文字和畸形手指短视频画面里出现明显 bug——招牌上的文字是乱码人物手指有 6 根或者画面边缘扭曲。原因文生图模型本质是概率模型它对文字的正确性没有语言学理解对复杂结构尤其是手部的生成能力也不稳定。这种问题在选材上特别容易出现——如果选题涉及招牌、路牌、屏幕截图文字崩坏概率直线上升。解决三层防空策略。第一层是选题层自动检测选题里的「文字敏感词」遇到招牌、菜单、证件这类天然带文字的题材直接标记为高风险并降低优先级。第二层是生成层提示词里加一批负面提示词把 text, watermark, letters, extra fingers, deformed hands 这些内容压掉。第三层是质检层跑一个简单分类器对成品图做检查检测到文字区域直接打回重生成。第二层就能解决大部分问题第三层是为了快速代答捡漏。6. 从「单条流水线」到「多 AI 协作」一个可落地的进阶思路当一条流水线跑顺之后下一步不是调参而是思考怎么让多条流水线协作。这套引擎目前的架构里每个 worker 都在独立处理任务它们之间没有信息交换。但在真实运营场景里一个矩阵账号需要的是「系列感」——第一条视频讲认知第二条讲案例第三条讲落地方法这三条必须围绕同一个主题主线展开不能各说各话。所以我建议做一步升级在调度器上层加一个「主编 agent」。这个 agent 不直接生产内容它只负责任务规划——把本周的选题库拆成若干个「系列」每个系列由 3 到 5 条视频组成然后把单条视频任务按顺序投递给现有的引擎 worker。这就是所谓多 AI 协作本质是用一个 agent 负责编排、让生成 agent 负责执行。实现上并不难主编 agent 只需维护一个系列表每次跑完一条视频后把实际生成的文案摘要回填到系列表里决定下一条要补什么角度。最后给出一个验证引擎健康度的方式比看任何日志都有用。用两个指标衡量成片率和单条任务平均耗时。成片率 成功渲染的任务数 / 总任务数这条指标低于 90%说明链路里一定有不稳定的环节先去查 5.1 到 5.5 的排查项单条任务平均耗时如果超过 15 分钟不含排队时间说明有环节在超时边缘反复试探。我自己的习惯是每周把这两个指标拉一次表看趋势不看出生点周五比周三慢就说明有问题。这套方法帮我从最早「天天半夜爬起来看日志」熬到了「一周看一次表」希望帮到你。本文还有配套的精品资源点击获取