用 n8n 搭 RSS→AI 改写→多平台自动发布工作流：节点配置 SOP

做自媒体一人多平台分发的人都有过这种体验：每天早上打开十几个 RSS 源，挑出能写的，改写成适合 Telegram、邮件订阅、飞书群、公众号的几种格式，再逐个平台粘贴发布。一整套下来两小时，还经常漏发、错发、格式串台。问题不在内容能力，在搬运——重复、机械、易错的事本不该人做。

这篇 SOP 交付一个可复用的 n8n 工作流模板：RSS Feed Read Trigger 抓源 → AI 节点改写并适配各平台格式 → Switch 按内容类型分路 → 多路输出到 Telegram、邮件、飞书 webhook。每一步给真实节点名、关键参数和表达式，你照着画布搭就能跑通。节点名以 n8n 官方文档为准，查不到的参数不编造、标「以官方文档为准」。

一句话定位：这个工作流不是「AI 帮你写文章」，是「AI 帮你把一条 RSS 改写成 N 种平台格式并自动发出去」，解决的是分发环节的搬运负担，不是创作环节。

一、场景与痛点

设想你是 AI 工具测评博主，订阅了 20 个 AI 资讯 RSS（Hacker News、厂商博客、GitHub Releases）。每天新条目上百条，你不可能全发，但也不能漏。痛点集中在三处：

• 搬运累：同一条新闻，Telegram 要短句+链接，邮件要长摘要，飞书群要带标签的结构化卡片。手动改三遍格式，时间全耗在贴来贴去。
• 漏发错发：复制粘贴时粘错频道、忘了发某个平台、把草稿当正文发了。人肉调度没有状态追踪，出错了难复盘。
• 时效差：热点新闻晚两小时发，流量差一截。等你有空手动处理，黄花菜都凉了。

根本矛盾：分发是确定性流程（收到内容→变形→投递），但它被包装成了需要人盯的创意任务。n8n 把它还原成自动化流水线，人只管选题规则和 prompt，搬运交给机器。

二、工具选型：为什么是 n8n

多平台分发工具不少，为什么用 n8n 搭这条流水线：

选 n8n 的核心理由：自托管免费 + 原生 AI 节点 + HTTP Request 能打任意平台 webhook。飞书没有官方 n8n 节点，但飞书自定义机器人就是个 webhook，HTTP Request 一发就通，这正是 n8n「不挑食」的价值。Coze 上手更快但闭源、数据在云端、外部 webhook 弱，做「多平台 webhook 分发」反而别扭。

前置条件：一个 n8n 实例（自托管 docker run -d --name n8n -p 5678:5678 -v ~/.n8n:/home/node/.n8n n8nio/n8n，或用 n8n.io 云端）、一个 OpenAI 兼容模型的 API Key、各平台凭证（Telegram Bot Token、SMTP、飞书机器人 webhook 地址）。

三、分步搭建：RSS → AI 改写 → 多平台分发

工作流主干 5 个节点，外加去重。先画主干再加固。

RSS Feed Read Trigger → [去重 Filter] → AI Agent(改写) → Switch(分路) → 多路输出
                                                              ├→ Telegram
                                                              ├→ Email Send
                                                              └→ HTTP Request(飞书 webhook)

步骤 1：触发器——RSS Feed Read Trigger

拖一个 RSS Feed Read Trigger 节点。这个节点本身就是触发器（内置轮询），不需要再接 Schedule Trigger。关键配置：

URL：https://hnrss.org/frontpage          # 你的 RSS 源地址
Limit：20                                  # 每次拉取最多条数
Poll Times：每 30 分钟                     # 轮询频率，按源刷新速度设

节点输出每条 item 的字段（来自底层 rss-parser，以官方文档为准）：title、link、content、contentSnippet、pubDate、guid、isoDate、creator。后面 AI 节点和去重都靠这些字段。

也可用 Schedule Trigger + RSS Feed Read（非触发器版本）组合：Schedule 定时跑，RSS Feed Read 读一次。区别是触发器版自带「只推新条目」的状态记忆，组合版要自己处理去重。新手直接用 RSS Feed Read Trigger 更省事。

步骤 2：AI 节点改写——适配各平台格式

拖一个 AI Agent 节点，输入接 RSS 输出。挂 Language Model 子节点（选 OpenAI Chat Model，API Key 存为 n8n Credential，别硬编码；接国产模型就选 OpenAI 兼容类型填 Base URL）。

本例的 AI 任务不是「自由发挥写文章」，是「把一条 RSS 改写成三种平台格式 + 打分类标签」，所以要写死输出结构。System Prompt 示例：

你是一个多平台分发改写器。收到一条 RSS 条目（title + link + content）。
输出严格 JSON，字段如下：
- telegram: ≤200 字短摘要，结尾附 link
- email: 300-500 字长摘要，Markdown 格式，保留 link
- feishu: 一句话标题 + 3 条要点 bullet
- category: 从 [breaking, digest, skip] 三选一
规则：不编造原文没有的事实；与 AI 无关的条目 category=skip；输出只能是 JSON，不要 markdown 代码块包裹。

AI Agent 输出的是文本，下游要用结构化字段，加一个 Code 节点把 JSON 字符串解析成对象：

// Code 节点：解析 AI 输出的 JSON
const raw = $json.text || $json.output; // 字段名以你的 AI Agent 输出为准
const parsed = JSON.parse(raw);
return { json: { ...$('RSS Feed Read Trigger').item.json, ...parsed } };

想更简单可用 Basic LLM Chain 节点替 AI Agent——它就是单轮 prompt→LLM→输出，不带工具和记忆，恰好匹配「改写」这种确定性任务。AI Agent 的优势在能挂工具（如让模型自己抓原文全文），本例不需要。

步骤 3：Switch 分路

拖一个 Switch 节点，输入接 Code 节点输出。Switch 按条件把数据路由到不同出口。这里按上一步 AI 打的 category 分路：

Routing：
  规则 1：{{ $json.category }} equals "breaking"  → 输出 0（即时推送 Telegram）
  规则 2：{{ $json.category }} equals "digest"    → 输出 1（进邮件摘要 + 飞书）
  规则 3：{{ $json.category }} equals "skip"      → 输出 2（丢弃）
  Fallback（都不匹配）                          → 输出 3（人工审核队列）

Switch 的价值是条件分发：breaking 走即时通道，digest 进批量通道，skip 直接丢，省得每条都全平台轰炸。

步骤 4：多路输出

Switch 每个输出接对应的发布节点。

Telegram（即时推送）——用 Telegram 节点：

Credential：Telegram Bot API（存 Bot Token，从 @BotFather 获取）
Resource / Operation：Message / Send
Chat ID：{{ $env.TELEGRAM_CHANNEL_ID }}    # 频道 ID，用环境变量别硬编码
Text：{{ $json.telegram }}                 # 引用 AI 生成的短摘要

邮件（摘要订阅）——用 Email Send 节点（SMTP 凭证）：

Credential：SMTP（存 SMTP 账号密码）
To：[email protected]
Subject：AI 资讯日报 - {{ $now.toFormat('yyyy-MM-dd') }}
Text / HTML：{{ $json.email }}

飞书 webhook（群卡片）——飞书无官方 n8n 节点，用 HTTP Request 打自定义机器人 webhook：

Method：POST
URL：{{ $env.FEISHU_WEBHOOK_URL }}      # 飞书群机器人 webhook 地址
Headers：Content-Type: application/json
Body（JSON）：
{
  "msg_type": "text",
  "content": { "text": "{{ $json.feishu }}" }
}

飞书机器人支持交互卡片（msg_type: interactive），卡片 JSON 结构较复杂，以飞书开放平台文档为准。先跑通 text 消息，再升级卡片。

步骤 5：去重与激活

RSS Feed Read Trigger 自带「只推新条目」，但若你重启实例或换触发器，会重复推老条目。加固方法：在 AI 节点前加一个 Filter 或 Code 节点，用 guid 去重——把已处理的 guid 存到 Postgres / SQLite / Google Sheets 节点，每次拉取后过滤掉已存在的：

// Code 节点：简易去重（伪代码，数据源以你选的存储为准）
const seen = $('Postgres').item.json.ids || []; // 查询已存 guid 集合，以官方文档为准
const fresh = $('RSS Feed Read Trigger').all.filter(
  item => !seen.includes(item.json.guid)
);
return fresh;

调通后点画布右上角切到 Active，工作流按 Poll Times 自动跑。测试阶段先用 Manual Trigger 手动喂数据，别直接开轮询。

四、踩坑速查

FAQ

Q1：RSS Feed Read Trigger 和 RSS Feed Read 有什么区别？ A：前者是触发器，内置轮询和「只推新条目」的状态记忆，激活后自动跑；后者是普通节点，读一次返回全部条目，需配 Schedule Trigger 定时调用、且要自己处理去重。新手用前者，想精细控制轮询逻辑用后者。

Q2：能不用 AI、直接把原文转发到各平台吗？ A：能。去掉 AI Agent 和 Code 节点，Switch 直接接 RSS 输出，下游用 {{ $json.contentSnippet }} 透传。但这样各平台格式一样，Telegram 会超长、邮件会太短，分发的意义就没了。AI 改写正是为了「一源多形态」。

Q3：接 DeepSeek / 通义等国产模型怎么配？ A：Language Model 子节点选 OpenAI 兼容类型，Base URL 填对应服务的 OpenAI 兼容端点，API Key 存为 Credential，模型名按服务商文档填。DeepSeek、通义千问、智谱都有 OpenAI 兼容端点，具体端点和模型名以各服务商文档为准。

Q4：飞书没有 n8n 节点怎么办？ A：用 HTTP Request 节点打飞书自定义机器人的 webhook 地址，Body 用飞书的消息 JSON 格式（msg_type + content）。这是 n8n 的通用解法——任何平台只要有 webhook 或 API，HTTP Request 都能接，不依赖是否有官方节点。

Q5：自托管 n8n 跑这个工作流要什么配置？ A：个人测试 2 核 4G 够用。这条流水线不重，吃资源的是 AI 调用频率和 RSS 拉取量。若接的源多、轮询密，升到 4 核 8G。生产部署务必加反代 + HTTPS + 强密码 + N8N_ENCRYPTION_KEY 环境变量加密凭证。

参考来源

• n8n 官方文档：https://docs.n8n.io
• n8n 集成节点库：https://docs.n8n.io/integrations
• RSS Feed Read Trigger 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.rssfeedreadtrigger/
• n8n 模板库（含 RSS 工作流模板）：https://n8n.io/workflows/
• n8n GitHub 仓库（n8n-io/n8n）：https://github.com/n8n-io/n8n
• 飞书开放平台-自定义机器人：https://open.feishu.cn/document/client-docs/bot-v3/add-custom-bot
• 本文 n8n 节点名与参数以官方文档为准；因网络受限未能逐一在线核验节点参数，未核实处已标注「以官方文档为准」，搭建时请对照 docs.n8n.io 确认