简介这是一份基于n8n构建全自动短视频生产线的项目源码包适合具备一定n8n基础、希望实现AI文案生成、自动成片并发布到YouTube的内容创作者或开发者。资源将n8n、Gemini API、MoneyPrinterTurbo与YouTube Data API串联为完整工作流支持Ubuntu/Debian/macOS/WSL2环境纯CPU即可运行。压缩包共11个文件包含yml编排文件、sh安装脚本、env环境变量示例、json工作流定义、py辅助脚本及md说明文档等结构清晰便于快速部署与二次开发。目前已有118人学习参考。通过本包可直接导入n8n工作流、了解Docker环境搭建要点与脚本部署方法同时获得常见问题解决方案和后续扩展方向可有效缩短从创意到视频上线的开发周期。1. 为什么是n8n短视频工厂的底座选型逻辑先交代一下背景。我手上同时运营着三个垂直领域的短视频账号每周要产出15条以上的成片。最开始完全是手工作坊找素材、写脚本、配音、剪辑、加字幕、发布、定时维护评论一个团队三个人每天被流程黏死产出还不稳定。后来我意识到这个事儿本质上不是创作问题而是流水线问题——短视频的生产链条极其标准化完全可以拆成独立的环节用自动化把它们串起来。当时摆在我面前的有三条路一是直接用Python写一套调度系统配合Celery或Airflow二是用现成的RPA工具比如按键精灵或某商业自动化平台三是用n8n这种可视化工作流引擎。第一条路我直接否了因为纯代码方案意味着以后每个环节的改动都要动代码、重新部署、处理各种依赖运营同学完全没法参与一个人扛全部迭代成本。第二条路的问题在于商业RPA对API支持极差遇到开放平台接口就要写自定义组件最后一样变成半代码项目。最后选了n8n核心逻辑很简单n8n把流程编排和业务逻辑解耦了。脚本生成、素材抓取、视频渲染这些重度逻辑我用自定义节点或Python脚本来做而流程编排、触发条件、数据传递、失败重试、多平台分发这些通用能力直接靠n8n的节点图来实现。运营同学想要调整发布频率、修改分发平台画流程图就能改不需要找我写代码。这个取舍在后来的半年里被证明是划算的。n8n本身是开源的可以完全自托管数据不会经过第三方云。这一点对后面接入各平台API、批量发视频很重要——用云服务版我反而会担心凭证和素材安全。项目落地后整体架构长这样数据层MySQL存账号信息和内容清单Redis做队列和缓存编排层n8n主服务负责流程调度、定时触发、条件分支、重试策略执行层自定义Python脚本节点处理AI文案、素材抓取、视频渲染分发层通过各平台开放API批量发布状态回写到数据层这套架构跑通之后从选题到发布全程无人值守人力从三个人缩到一个人产出量还翻了一倍。下面我把搭建过程中的关键决策和踩坑都写出来。2. 本地部署到企业级集群环境准备是第一个大坑n8n的安装本身不复杂复杂的是装完能不能稳定跑生产。我最初是在一台4核8G的云服务器上直接用Docker跑单机版结果跑了不到两周就出问题定时任务一多节点执行到一半就OOMn8n主进程直接挂掉。后来我查了日志发现是执行线程队列堆积每个视频渲染节点要开一个Python子进程内存一下就爆了。所以如果你想跑真正的生产负载单机Docker只适合开发测试不太适合直接上线。我的建议是直接从企业级部署方案起步一步到位。2.1 生产环境的部署架构我现在的部署方式是经典的n8n主实例worker模式主实例main跑Web界面、webhook触发器、负责编排调度不执行重型任务worker节点worker执行所有实际业务节点可以水平扩容Redis作为队列后端主实例把任务分发给workerPostgreSQL生产数据库比默认的SQLite更适合高并发Nginx反向代理配置HTTPS用Docker Compose可以把这套堆起来关键配置如下version: 3.8 services: n8n-main: image: n8nio/n8n:latest command: start environment: - N8N_MODEmain - N8N_ENCRYPTION_KEYyour-encryption-key - DB_TYPEpostgresdb - DB_POSTGRESDB_DATABASEn8n - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_PORT5432 - DB_POSTGRESDB_USERn8n - DB_POSTGRESDB_PASSWORDyour-db-password - QUEUE_BULL_REDIS_HOSTredis - QUEUE_BULL_REDIS_PORT6379 - N8N_DIAGNOSTICS_ENABLEDfalse - N8N_PERSONALIZATION_ENABLEDfalse ports: - 5678:5678 depends_on: - postgres - redis n8n-worker: image: n8nio/n8n:latest command: worker --concurrency10 environment: - N8N_MODEworker - N8N_ENCRYPTION_KEYyour-encryption-key - DB_TYPEpostgresdb - DB_POSTGRESDB_DATABASEn8n - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_PORT5432 - DB_POSTGRESDB_USERn8n - DB_POSTGRESDB_PASSWORDyour-db-password - QUEUE_BULL_REDIS_HOSTredis - QUEUE_BULL_REDIS_PORT6379 depends_on: - postgres - redis - n8n-main postgres: image: postgres:15 environment: - POSTGRES_USERn8n - POSTGRES_PASSWORDyour-db-password - POSTGRES_DBn8n volumes: - postgres_data:/var/lib/postgresql/data redis: image: redis:7-alpine command: redis-server --appendonly yes volumes: - redis_data:/data volumes: postgres_data: redis_data:这里有个非常关键的配置N8N_ENCRYPTION_KEY。这个值是用来加密保存凭证信息的密钥如果你不手动指定n8n首次启动时会自动生成一个。问题在于当你从单机版迁移到集群模式、或者重新部署容器时如果加密密钥变了之前保存的所有credentials都没法解密了。我早期就吃过这个亏所有平台的API密钥全部重配了一遍。生产环境务必在部署时固定这个环境变量。2.2 凭证管理的几个细节紧接着上面的话题说说credentials。短视频工厂要接的内容平台和AI服务非常多我维护着十几组凭证大模型API的Key文案生成各短视频平台的开放平台凭证发布素材网站的抓取凭证对象存储的AccessKey存视频文件n8n的凭证管理本身做得不错它会把凭证加密后存入数据库Web界面上不会明文显示。但有几个坑需要注意第一凭证作用域。n8n里凭证默认是所有用户共享的。如果团队多个人都在编辑工作流任何能编辑工作流的人都能调用但看不到明文这一点还好。不过我的建议是创建专门的服务账号来做自动化不要把个人账号的凭证绑进去防止有人离职导致凭证失效。第二凭证轮换机制。很多平台API的token有有效期比如有的平台access_token是7天过期需要refresh_token刷新。n8n本身不负责token轮换我是在工作流里专门做了一个定时刷新token子工作流每天早上跑一次把新token写回数据库其他工作流从数据库动态读取。这个子工作流属于整个工厂的基础设施一旦挂了所有发布流程都会挂所以我给它配了独立的失败告警。第三不要在凭证内容里用特殊字符。这是我实际遇到过的问题某个平台的client_secret里带有$符号在n8n环境变量里被解析成了变量引用导致鉴权一直失败。排查了很久才定位到是环境变量转义问题。后来我统一把包含特殊字符的凭证改成通过n8n界面的credential管理录入不再走环境变量注入。3. 核心流水线的设计从热点抓取到多平台发布短视频工厂的整个流程我把它分成了7个核心环节。如果你要用n8n搭一套类似的系统这7个环节可以作为你设计工作流的骨架。这是一个完整的工作流流转定时触发每天8点和14点各触发一次热点选题从各平台热榜抓取关键词AI文案生成基于热点生成3个方向的脚本素材采集根据脚本关键词自动搜索并下载免费素材字幕与配音调用TTS服务生成配音语音识别生成字幕视频渲染用FFmpeg合成最终成片多平台分发发布到各短视频平台并更新内容管理表在n8n中我并不是把这7个环节全画在一张巨大的画布里——那样维护成本太高。正确的做法是拆成多个子工作流用n8n-nodes-base.executeWorkflow来调用或者用webhook做跨工作流触发。我是这样拆的主调度流定时触发维护任务状态按顺序调用下面的子工作流处理成功/失败分支热点获取流负责抓取各平台热榜清洗数据输出关键词列表文案生成流接收关键词调用大模型生成文案输出结构化脚本素材抓取流根据关键词搜索素材站下载素材到本地/NAS渲染发布流调用FFmpeg合成视频调用各平台API发布这样拆的好处是任何一个环节挂了只需要重启对应的子工作流就好了不会把整个工厂拖垮。而且你可以单独给每个子工作流设置重试次数、超时时间、告警策略。主调度流的逻辑是n8n中比较核心的部分它有点像一个状态机。每个子工作流执行完之后返回一个JSON对象包含status和data字段。主调度流读取这些字段来做下一步决策{ status: success, data: { videoPath: /data/videos/20240215_001.mp4, duration: 58, fileSize: 23456789 } }如果某一步返回status: failed主调度流会执行一个失败处理分支把任务信息写入数据库同时通过企业微信机器人/钉钉机器人发告警通知。这个失败处理分支很重要否则某个环节悄悄失败了你可能要过好几天才能从一堆静默日志里发现。4. 关键节点的代码级实现这五个节点撑起整个工厂画流程节点只是第一步真正决定工厂产能上限的是那些自定义逻辑节点。下面我把五个最核心的节点实现写出来这些是我在项目里反复打磨过的。4.1 热点获取节点的实现热点获取我用的是HTTP Request节点 数据清洗的组合。n8n内置的HTTP Request节点可以直接请求各平台热榜API但返回的数据通常是嵌套JSON需要做转换。这里有个实用的技巧请求热榜API时很多平台对高频请求有严格限流而热榜数据其实几分钟内变化不大。我的做法是在n8n里加了一个缓存判断逻辑——用Redis节点读取上次请求的时间戳如果距上次请求小于10分钟直接用缓存的关键词列表否则才发起新的HTTP请求。这个优化让我的触发频率可以设得很高但API调用量被压到了一个非常低的水平。数据清洗阶段我写了一个Function节点把返回的JSON标准化为统一格式// n8n Function节点代码 const items $input.all(); const result []; for (const item of items) { const raw item.json.data || item.json; const list raw.list || raw.hotList || raw.data || []; for (const entry of list) { const title entry.title || entry.word || entry.name; const hotValue entry.hotValue || entry.heat || entry.num || 0; if (title hotValue 10000) { result.push({ json: { title: title.trim(), hotValue: Number(hotValue), platform: item.json.platform || unknown, capturedAt: new Date().toISOString() } }); } } } return result;清洗后的数据会写入数据库同时作为下一个节点的输入。有个细节关键词去重很重要。不同平台热榜常常会出现同一个热点词如果不做去重后面文案生成环节会对同样的话题反复写脚本浪费模型调用费用。4.2 AI文案生成结构化输出是关键文案生成节点是整条流水线的大脑。我用的是OpenAI节点但在prompt设计上花了很多心思。最初我试过直接把热点词丢给模型帮我就这个话题写一个短视频脚本返回的内容完全不可控有时是散文有时是纯对话有时带着emoji根本没法直接进入后面的配音和渲染环节。后来我改成要求模型返回固定结构的JSON并且把约束条件写死在系统提示词里你是短视频脚本策划专家。请根据给定主题生成一个适合口播的短视频脚本要求 1. 字数控制在200字以内适合35-45秒的语音播报 2. 开头3秒必须抓住注意力使用疑问句或反常识观点 3. 结构为钩子-铺垫-核心观点-行动号召 4. 返回格式必须是JSON包含以下字段 { title: 视频标题不超过20字, hook: 开头钩子不超过30字, script: 完整口播文案, suggested_keywords: [标签1, 标签2, 标签3], visual_notes: 画面建议描述每个段落应配的画面内容 } 5. 只返回JSON不要有其他文字说明配合n8n OpenAI节点的JSON模式在节点配置里把responseFormat设置为json_object返回内容可以直接用JSON.parse解析再拆成多个字段供下游节点使用。这个设计让文案质量和生产稳定性都有了保障。因为script字段是纯文本直接就可以丢给TTS去生成配音不需要额外清洗。visual_notes则作为素材抓取节点的搜索关键词参考。4.3 素材抓取的合法性处理素材是整个流程里最敏感的环节。我的原则是只用明确提供免费商用授权的素材源并且把素材的出处信息随视频一起存档防止日后产生版权纠纷。素材抓取节点用的是n8n的HTTP Request节点自定义循环。核心逻辑是从visual_notes中解析出场景关键词每个关键词去素材站搜索一次取前几个结果下载。这里有个问题素材站通常会把大文件放在CDN上重定向URL有时效性直接下载容易失败。我的方案是先请求搜索API拿到素材ID再调用专门的文件下载接口获取临时直链然后交给Execute Command节点用wget或curl下载。下载完成之后一定要做文件完整性校验。我吃过一次亏某个素材文件下载了一半FFmpeg合成时完全没有报错视频输出就是花屏。后来我在下载节点后面加了一个ffprobe校验步骤检查每个素材的时长和编码信息不合格的直接标记为失败并重新下载。4.4 视频渲染FFmpeg的工业化封装视频渲染是整个工厂里计算压力最大的环节。我没有用专门的视频编辑软件那没法自动化而是直接用FFmpeg命令拼素材。把流程简化后渲染节点做的事情是把文案转成配音音频文件TTS生成把配音音频的时长作为基准按visual_notes切分素材片段用FFmpeg的scale、crop、fps参数统一素材分辨率拼接片段、混入配音、叠加字幕核心FFmpeg命令大致长这样ffmpeg -y \ -f concat -safe 0 -i filelist.txt \ -i audio.mp3 \ -vf scale1080:1920:force_original_aspect_ratiodecrease,pad1080:1920:(ow-iw)/2:(oh-ih)/2,fps30,subtitlessubtitle.ass \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 192k \ -shortest \ output.mp4这里filelist.txt是需要拼接的素材文件清单subtitle.ass是用配音音频自动生成的 ASS 字幕文件。整个合成过程在n8n里通过Execute Command节点调用用exec执行命令并等待返回。FFmpeg命令没有做一刀切的参数统一。我按视频类型分了三个预设口播类1080x1920竖屏30fpscrf 23图文类1080x1920竖屏静态图加Ken Burns效果混剪类1920x1080横屏25fpscrf 20画质更高不同预设之间的切换通过n8n的条件节点判断文案的video_type字段来路由。这个设计让同一个工厂能产出不同风格的视频不是千篇一律的套模板。4.5 多平台分发状态回写与幂等性设计分发节点是直接面对用户的环节也是出错风险最高的环节。我接入了两个短视频平台的开放API核心要点是幂等性。什么是幂等简单说就是同一个发布请求无论执行多少次结果都一样。平台的发布接口本质上是创建一个视频资源如果网络超时导致你重试就很容易创建出重复视频。为了防止这个问题我在每条视频生成时都会创建一个全局唯一的videoIdUUID发布请求中把这个ID作为client_video_id传过去。平台如果收到相同的ID会返回已创建的视频信息而不是再创建一个新的。发布成功之后工作流会把平台的返回信息视频ID、发布URL、审核状态写回MySQL内容管理表。这个表是整个工厂的成果台账我会基于它做数据统计分析哪类选题播放量高、哪个时段发布效果好、哪个平台的推荐算法更友好。平台分发环节还有一个容易被忽略的点不同平台对视频封面的要求不同有的要求9:16的JPG有的要求PNG还有的要带文字标题的封面层。我在渲染节点就已经把这些变体一次性生成好了分发节点按平台规则选择对应的封面文件提交即可。5. 上线半年的踩坑清单与排查链路任何自动化系统上线只是开始真正的挑战都在后续的日常运行里。这半年我记了一堆踩坑记录挑几个有代表性的分享出来都是文档里不会告诉你的。5.1 凭证失效引发的连锁崩溃最严重的一次事故某个平台的refresh_token静默过了有效期导致所有发布任务鉴权失败。由于发布失败会走失败处理分支理论上应该报警但那个子工作流的报警节点本身因为凭证失效也挂了——告警通道和业务通道绑了同一个凭证体系一出事全出事。这次事故之后我把告警通知改成了完全不依赖第三方平台凭证的方案直接给运维邮箱发SMTP邮件。SMTP凭证独立保存在服务器环境变量里和业务凭证完全隔离。从那以后凡是核心基础设施告警、健康检查、心跳检测都走独立凭证坚决不和业务凭证混用。5.2 定时任务堆积时区与触发频率的冲突n8n的定时触发节点默认使用服务器时区如果你服务器设的是UTC定时任务的每天8点实际执行时间是北京时间下午4点。这个坑在单机部署时可能不明显因为很多人会无意识地把服务器时区设成北京时间。但如果你用了容器化部署基础镜像默认都是UTC设置定时任务时就要特别注意。另一个问题是触发频率过高导致的多实例冲突。我最初把主调度流设为每5分钟跑一次用来检查待处理任务。但n8n的定时触发器在worker模式下如果多个worker同时在线同一个定时任务可能被触发多次。这会导致同一个视频被重复生产。解决方案有两个一是把定时任务改为只让主实例执行在worker环境变量里禁用定时触发二是在任务表里加状态锁通过数据库原子操作抢占任务抢不到的实例直接跳过。我用的是第二种方案更保险。5.3 大文件传输n8n数据流的内存瓶颈n8n的工作流设计里上一个节点的输出会作为下一个节点的输入在内存中传递。如果你把视频文件本身放进节点间的数据流里内存会迅速被打爆。比如素材下载节点如果直接返回整个文件内容后面所有节点都会很卡。解决方式文件不要进n8n数据流只在节点之间传递文件路径。我用的模式是素材下载节点把文件存到NAS的固定目录返回文件路径渲染节点通过Execute Command节点访问该路径输出成片到一个新目录返回输出路径发布节点从路径读取文件通过平台的文件上传接口发送这个模式把n8n当成了指挥中心而不是搬运工内存占用一下就降下来了。6. 把工作流当代码管理项目结构重构与版本化方案n8n项目跑起来不难难的是持续迭代。等你有了几十个工作流、上百个节点时如果还在Web界面上手动拖拽修改迟早会把生产环境改坏。我后来做了一次比较大的重构把整个项目按照工程化的标准来管理借鉴了很多后端工程的最佳实践。6.1 工作流的JSON导出与版本管理n8n的每个工作流本质上是一个JSON文件n8n内置了导出功能。我的做法是把每个工作流从n8n界面导出成JSON文件放进Git仓库管理和项目代码放在一起。每个工作流的修改都先在测试环境改完、验证通过然后导出JSON提交到Git再通过n8n的CLI工具导入到生产环境。仓库结构大概是这样n8n-shortvideo-factory/ ├── workflows/ │ ├── main_scheduler.json # 主调度流 │ ├── hot_topic_fetcher.json # 热点获取流 │ ├── script_generator.json # 文案生成流 │ ├── material_downloader.json # 素材抓取流 │ ├── video_renderer.json # 渲染发布流 │ └── token_refresher.json # 凭证刷新流 ├── scripts/ │ ├── deploy.sh # 导入导出脚本 │ ├── render_preset_a.sh # FFmpeg预设A │ ├── render_preset_b.sh # FFmpeg预设B │ └── check_material.sh # 素材完整性校验 ├── docker-compose.yml └── .env.example你可能觉得这有点杀鸡用牛刀但经历过一次手滑在生产环境误删节点之后我发誓再也不用纯Web界面管理生产工作流。有人说n8n不是有内置的版本历史吗确实有但那个版本历史保存在n8n数据库里没法做代码评审也没法做多人协作的分支管理。只有放到Git里才能走diff、review、回滚的完整流程。6.2 把重复逻辑封装成子工作流在项目管理领域有个说法叫单一职责这个原则同样适用于n8n。我在重构前主调度流里塞了各种业务逻辑热点清洗、关键词去重、文案解析、素材判断……一个工作流里堆了七八十个节点改一个条件分支就要小心翼翼翻半天。重构后的方案是把通用能力沉淀为可复用的子工作流。比如AI文案解析这个能力它接收任意文本解析成结构化的JSON。这个子工作流被三个上游工作流复用逻辑只维护一份。再比如发送告警子工作流任何环节失败都可以调用它。这就像写代码时抽取公共函数避免了到处复制粘贴。n8n里调用子工作流有两种方式一种是executeWorkflow节点直接在当前流程中同步执行另一种是通过webhook触发异步调用。对于需要获取返回结果的场景我用同步方式对于通知记录日志这类不关心结果的我用异步方式避免拖慢主流程。6.3 环境隔离开发、测试、生产三套环境最后一个工程化建议至少要开两套n8n环境。我自己维护了一个本地Docker测试环境和一台生产服务器。所有工作流的改动先在测试环境验证数据源用mock数据和真实脱敏数据混合确认没问题再导入生产。开多套环境会带来一个额外问题不同环境下的凭证、webhook URL、数据库连接串都不一样。我通过n8n的变量功能解决——在n8n设置里维护了环境级别的变量测试环境的变量值指向测试数据库和mock服务生产环境的变量值指向真实服务。工作流里引用变量时用{{$vars.xxx}}这样同一个JSON文件在测试环境和生产环境都能跑得通。如果你团队有多个人建议再引入一个定义即代码的流程工作流的变更必须走Git提交加人工review禁止直接在测试环境上改完就跑不然很容易出现测试环境能跑生产环境跑不了的玄学问题。7. 项目上线后的实际效果与可复用经验最后说一下实际运行数据给想搭这套系统的人一个参考。目前这套n8n自动短视频工厂跑了半年三个账号稳定更新每周产出15条成片人工介入的时间每周不超过两小时。对比搭建之前产能提升了接近3倍而且因为AI参与内容生产选题覆盖的广度比原来人工选题要宽不少。但我也想说一句实话自动化解决的是流程效率不是内容质量。工厂跑出来的视频是合格品不是爆款。它的定位是帮你省掉重复劳动时间让你有更多精力去做真正需要创意的那部分——比如优化选题策略、打磨内容差异化、设计更好的开头钩子。如果你想复刻这套系统我的建议是从最小闭环开始先只做热点获取→文案生成→手动渲染→手动发布这条半自动链路跑通之后再逐步加上素材抓取、自动渲染、自动发布。一次到位的大而全是灾难的源头小步快跑才能及时调整方向。我后来还做了一些锦上添花的扩展接入了数据统计看板每天早上推送前一天的播放数据到企业微信加了素材库自动分类逻辑按主题归档素材方便人工作业时快速查找还做了一套简单的AB文案测试同一热点自动生成两个版本的标题和封面发布后对比数据。这些扩展都是用n8n的新工作流完成的没有改核心代码。如果你也在用n8n搭内容生产的自动化管道希望这篇笔记能帮你少走一些弯路。自动化这条路的尽头不是机器替人而是人做更有价值的事。本文还有配套的精品资源点击获取