n8n保姆级教程：拆解开源自动化神器，从部署到 GitHub Trending 追踪全流程

作为一个经常需要关注技术动态的程序员，我一直有追踪 GitHub Trending 项目的需求——但每次都手动去 GitHub 逐个浏览仓库内容实在效率太低。直到接触了 n8n，一个想法浮现出来：用 n8n 自动抓取 GitHub Trending、结合 AI 做内容总结，然后推送到邮箱甚至自动发布到博客。

周末两天，我搭完了这个全自动工作流并成功运行。这篇文章把整个过程完整拆解——从 n8n 是什么、怎么部署，到工作流中每个关键节点的配置细节，再到独立站 SEO 从业者能用 n8n 做什么。

一、n8n 初识：一个自动化超级英雄

n8n 是 “nodemation” 的简称，是一个开源、高度可扩展的工作流自动化工具。GitHub 仓库地址为 n8n-io/n8n，截至 2026 年 Star 数已突破 108K——这个数字本身就说明了它在开发者社区的地位。

它通过一个直观的可视化界面，让你用拖拽连接的方式把不同应用、服务和数据串联起来，创建复杂的自动化流程。

五大核心特点

特点	说明
可视化工作流编辑器	拖拽式界面，无需编程基础也能构建复杂自动化流程
丰富的节点库	400+ 预置节点，覆盖 API、数据库（Supabase/MySQL）、SaaS 平台（GitHub/Slack）和自定义 Webhook
高度灵活性	支持条件分支（if/else）、循环（loop）、并行执行等复杂逻辑控制
自托管部署	支持私有化部署在自己的服务器上，完全掌控数据安全；也提供云服务选项
低代码 + 代码混合	非技术人员用拖拽操作，开发者在工作流中嵌入 JavaScript/Python 代码做深层次定制

n8n 的核心优势在于开源 + 可扩展性。开源意味着透明、社区驱动、可深度定制；可扩展性意味着它不只是简单的”A 触发 B”工具——通过内嵌代码节点和 LLM 链节点，它能处理复杂的企业级自动化需求。

二、部署 n8n 环境：生产级部署

n8n 提供多种自托管部署方式，官方维护了一个参考仓库 n8n-io/n8n-hosting。以下是基于 Docker Compose + PostgreSQL + Redis + Worker 架构的生产级部署流程。

Step 1：创建部署目录

mkdir n8n-compose && cd n8n-compose

Step 2：创建 docker-compose.yml 和 init-data.sh

参考官方示例：withPostgresAndWorker，这里使用的是带 PostgreSQL 持久化存储和独立 Worker 进程的架构——生产环境必备，因为单容器模式在任务并发时会卡顿。

Step 3：配置环境变量

创建 .env 文件：

POSTGRES_USER=changeUser
POSTGRES_PASSWORD=changePassword
POSTGRES_DB=n8n
POSTGRES_NON_ROOT_USER=changeUser
POSTGRES_NON_ROOT_PASSWORD=changePassword
ENCRYPTION_KEY=changeEncryptionKey
N8N_EDITOR_BASE_URL=https://n8n.example.com
WEBHOOK_URL=https://n8n.example.com

⚠️ ENCRYPTION_KEY 是用于加密 n8n 中存储的凭证信息的密钥，一定要设置且妥善保存。丢失后无法恢复已保存的 API Key。

Step 4：docker-compose.yml 中添加环境变量

x-shared: &shared
  environment:
    - QUEUE_BULL_REDIS_HOST=redis
    - QUEUE_HEALTH_CHECK_ACTIVE=true
    - N8N_ENCRYPTION_KEY=${ENCRYPTION_KEY}
    - N8N_EDITOR_BASE_URL=${N8N_EDITOR_BASE_URL}
    - WEBHOOK_URL=${WEBHOOK_URL}

Step 5-6：启动并检查

docker-compose up -d
docker-compose ps

期望看到以下四个容器全部 running 且 PostgreSQL 和 Redis 状态为 healthy：

容器	端口
n8n (主服务)	5678
n8n-worker (任务执行)	5678 (内部)
postgres	5432
redis	6379

Step 7：配置反向代理

使用 Caddy Server 为例，在 /etc/caddy/Caddyfile 中添加：

n8n.example.com {
    reverse_proxy localhost:5678
}

配置完成后，访问 https://n8n.example.com，首次需要创建管理员账号和密码。

三、实战工作流：GitHub Trending 每日追踪

整体架构设计

先梳理整个自动化链条：

定时触发 → 获取 GitHub Trending 列表 → 存储到 Supabase
                                              ↓
                         挑选未推送项目 → 获取 README → LLM 总结 → 邮件/博客发布

• 数据存储用 Supabase（PostgreSQL）
• AI 总结用 Google Gemini
• 博客发布用 GitHub 节点写入 Hugo 站点仓库

由于”获取列表存储”和”AI 总结发布”的触发周期不同，我将其分为两个独立工作流。

涉及的核心 n8n 节点

节点	用途	官方文档
HTTP Request	自定义 API 调用	https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/
GitHub	GitHub 仓库操作	https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.github/
Supabase	数据库读写	https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.supabase/
Code	自定义 JS/Python 逻辑	https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.code/
Basic LLM Chain	AI 文本生成	https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.chainllm/

四、工作流 1：获取 GitHub Trending 并存储

数据获取

我启动了一个 GitHub Trending API 服务，让它和 n8n 跑在同一个 Docker 网络中：

docker run -d \
  -p 18000:8000 \
  --name github-trending \
  --restart always \
  --network n8n-compose_default \
  ghcr.io/tomowang/github-trending:latest

在 n8n 中用 HTTP Request 节点访问该服务。因为两者在同一个 Docker 网络中，URL 可以直接使用容器名：

![HTTP Request 节点配置：Method=GET, URL=http://github-trending:8000/trending]

数据加工与存储

获取到 Trending 数据后，用 Code 节点（Python）填充时间戳、排名等字段，然后通过 Supabase 节点写入数据库。

Supabase 数据表结构：

CREATE TABLE public.trending_repos (
  id BIGINT GENERATED BY DEFAULT AS IDENTITY NOT NULL,
  name CHARACTER VARYING NOT NULL DEFAULT ''::CHARACTER VARYING,
  description TEXT NULL DEFAULT ''::TEXT,
  language CHARACTER VARYING NULL DEFAULT ''::CHARACTER VARYING,
  stars INTEGER NULL,
  forks INTEGER NULL,
  today_stars INTEGER NULL,
  built_by TEXT[] NULL,
  date TIMESTAMP WITHOUT TIME ZONE NULL,
  rank SMALLINT NULL,
  CONSTRAINT trending_repos_pkey PRIMARY KEY (id)
);

Supabase 认证配置：

• Project URL：Project Settings → Data API → Project URL
• API Key：Project Settings → API Keys → service_role（使用 service_role 密钥而非 anon key，因为需要写权限）

这个工作流设置为每小时执行一次（Cron 触发器），持续积累 GitHub Trending 数据作为后续工作流的数据源。

五、工作流 2：AI 总结与自动化发布

核心需求

在搭建第二个工作流之前，需要梳理几个关键需求：

1. 每小时抓取一次数据，但不能每次都把所有项目都总结一遍——需要筛选策略
2. 已经推送过的项目必须记录在案，避免重复推送
3. 项目信息需要包括 README，因为真正的项目价值在 README 里

为解决需求 2，额外创建一张 pushed_repos 表：

CREATE TABLE public.pushed_repos (
  id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL,
  pushed_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
  name CHARACTER VARYING NOT NULL,
  CONSTRAINT pushed_repos_pkey PRIMARY KEY (id)
);

工作流完整流程

Supabase 获取趋势项目
       ↓
Code 节点过滤已推送项目（去重）
       ↓
Code 节点按 star 数排序，选 Top N
       ↓
HTTP Request 节点调用 GitHub API 获取 README
       ↓
Basic LLM Chain 节点（Gemini）生成总结
       ↓
├─ Email 节点推送邮件
└─ GitHub 节点写入博客仓库
       ↓
Supabase 写入已推送记录

关键节点详解

1. Code 节点：过滤已推送项目

n8n 支持 JavaScript 和 Python 两种代码节点（Python 使用 Pyodide 提供支持）。节点默认对每一条输入数据循环执行，但在这个场景中我们需要对整个数组做统一处理，所以需要将 运行模式切换为 Run Once for All Items。

Python 代码示例：

trending_repos = _('Last 24h trending repo').all()
pushed_repos = [item.json['name'] for item in _('Last 30d push history').all()]

return [
    item.json
    for item in trending_repos
    if item.json['name'] not in pushed_repos
]

n8n 中节点间的数据传输使用对象数组结构，每个 item 包含 json 和可选的 binary 字段，详见官方文档 Data Structure。

2. HTTP Request 节点：获取 README

GitHub 原生节点不支持直接获取 README，所以使用 HTTP Request 节点调用 REST API：

GET /repos/{owner}/{repo}/readme
Header: Accept: application/vnd.github.raw+json

URL 中使用表达式 {{ $json.name }} 动态获取上游节点传递的项目名。认证方式选择 GitHub API 预置凭证类型——n8n 建议优先使用预定义凭证类型而非手动设置 Header，因为预置凭证会自动处理 Token 刷新。

3. Basic LLM Chain 节点：AI 内容总结

这是 n8n 的高级功能之一。LLM Chain 属于集群节点（Cluster Nodes），由一根节点和若干子节点组成——根节点负责定义 Prompt 模板和输入输出连接，子节点负责实际的模型调用。

Prompt 模板的核心片段：

以下为 Github 仓库名称：{{ $node['Calc top repos'].item.json.name }}
仓库信息：
{{ JSON.stringify($node['Calc top repos'].item.json, null, 2) }}
仓库原始 README 信息：
{{ $json.data }}

子节点选择 Google Gemini Chat Model，API Key 从 Google AI Studio 获取，模型版本使用 gemini-2.5-flash。

LLM Chain 会基于 Prompt 模板 + 变量注入，生成一份结构化的项目总结（包含项目简介、核心功能、技术栈、适用场景），然后通过 Email 节点推送到指定邮箱、通过 GitHub 节点提交到 Hugo 博客仓库。

通过 Execution 面板，可以追踪每一步的实际输入输出数据，甚至看到 Gemini 的预估 Token 消耗量。

六、独立站 SEO 人员能用 n8n 做什么？

这个 GitHub Trending 案例只是 n8n 能力的冰山一角。对独立站 SEO 从业者来说，n8n 可以承担大量重复性、跨系统的自动化任务：

场景	n8n 工作流链路	SEO 价值
竞品价格监控	Cron 定时 → HTTP Request 抓取竞品页面 → 价格对比（Code 节点）→ 波动超过阈值时 Slack/邮件告警	第一时间知道竞品调价，快速调整策略
GSC 数据自动同步	Google Search Console API → 数据清洗（Code 节点）→ 写入 Google Sheets 或 Supabase → 生成周报邮件	不再手动导出 CSV、做数据透视表
AI 批量生成 SEO 内容	Supabase 获取关键词列表 → HTTP Request 调 SERP API 获取搜索结果 → Gemini/GPT 生成文章框架 → 人工审核后通过 Webhook 发布到 WordPress	内容生产流水线化
404 死链自动检测	Cron 触发 → Screaming Frog API / HTTP Request 爬取 → 检测 4xx 状态码 → 汇总邮件通知	不再等 GSC 报错才发现，每天主动巡检
外链监控	HTTP Request 调 Ahrefs/Semrush API → 对比前后两次数据（Code 节点）→ 新外链/丢外链接告警	追踪外链变化，及时回收失效链接
社交媒体监听	Reddit/Quora/YouTube API → 关键词过滤（Code 节点）→ AI 提取提到你品牌的帖子 → 自动汇总	关注行业口碑，抓住品牌曝光机会

这些场景的核心价值只有一个：把 SEO 从业者从每天的”打开工具→导出数据→复制粘贴→汇总报告”中解放出来，把时间花在分析和策略上。

七、总结与展望

从部署 n8n 到搭建 GitHub Trending 追踪工作流，再到 AI 自动总结与发布——整个链条跑通只需要一个周末。n8n 的节点式设计让复杂的自动化逻辑可视化、可调试、可复用。

这个实战案例展示了 n8n 的几项核心能力：

• 跨系统集成： HTTP Request + GitHub API + Supabase + Gemini 无缝协作
• 数据持久化 + 去重： PostgreSQL 管理状态，避免重复处理和推送
• AI 自动化： LLM Chain 节点让 AI 参与内容加工，不再是简单的”触发→转发”
• 灵活的代码扩展： Python/JS 代码节点处理筛选、排序、格式化等定制逻辑

对独立站 SEO 团队来说，n8n 是极其值得投资时间的工具。一次搭建，持续运行——不需要为每个自动化需求单独采购 SaaS 工具，不需要为”每月超了任务限额”付费升级。这就是开源的力量。

推荐继续看：

• 什么是 n8n：一文看懂开源自动化神器 n8n
• 推荐 4 个免费的独立站服务器
• 独立站新手怎么开始做 SEO