拓冰网站定制 
直接进入正题。这篇不是概念介绍是把我自己跑通的一套“新闻雷达”完整拆给你看从 n8n 部署、钉钉机器人接入、RSS 源配置到关键词过滤、AI 摘要、定时推送再到后续优化和踩坑记录。你能照着搭一套也能拿来当 n8n 工作流设计的参考。1. 为什么我会用 n8n 搭“新闻雷达”先说需求背景。我平时要盯的资讯源很杂科技媒体、开源社区、行业论坛、几个竞品的官方博客。最早我靠的是“早上刷一遍 零散订阅”但这种方式有两个致命问题一是信息滞后等我在群里看到转发时往往是几个小时甚至一天之后二是噪音太大真正有用的可能只有几条但为了找这几条我要把几十个页面翻一遍。后来我试过专门的 RSS 阅读器也试过 Python 脚本定时抓取但都有各自的麻烦。RSS 阅读器只解决“聚合”不解决“推送”我还是要主动打开Python 脚本能推送但改规则、加源、调试要动代码我这种三天两头想调过滤词的人改脚本的成本实在太高。于是我把目光放到了 n8n 上。n8n 是一个可视化的工作流自动化工具你可以把它理解成一个“可视化管道”左边接数据源中间做加工右边推到目标系统。它自带的节点非常多HTTP 请求、RSS Feed、定时触发、Webhook、各类消息平台都有现成节点。更重要的是它是开源自托管的数据完全在自己手里不会出现“某个免费云服务突然停止运营”这种问题。整个方案的最终形态是这样的n8n 每隔 15 分钟抓取一次各信息源的 RSS 数据经过去重、关键词过滤、AI 摘要、排序这几个步骤最后通过钉钉自定义机器人把消息推送到群聊里。整个链路跑起来之后我每天早上一打开钉钉就能看到一份已经整理好的资讯摘要。下面我分步讲清楚每个环节的选型和实现。2. n8n 部署方式对比与 Docker 部署实操2.1 本地、云主机还是 Dockern8n 的部署方式大体有三种npx 直接跑、Docker 部署、官方云服务。我个人的建议是如果你打算把它当作一个长期跑的“基础设施”优先选 Docker 部署在自己的云主机或 NAS 上。npx 方式启动最简单的一条命令npx n8n但问题也很明显它是前台进程一旦终端断开进程就没了升级和管理依赖也比较麻烦。官方云服务虽然省心但要按月付费而且工作流里的数据都在第三方平台上对一部分场景来说会有隐私顾虑。Docker 部署则兼顾了可控性和可维护性尤其适合挂在服务器上长期运行。2.2 Docker Compose 部署步骤我的环境是一台 2 核 4G 的云主机操作系统是 Ubuntu 22.04Docker 版本 24.x。部署用的 docker-compose.yml 我直接贴出来version: 3.8 services: n8n: image: n8nio/n8n:latest container_name: n8n restart: unless-stopped ports: - 5678:5678 environment: - N8N_HOSTyourdomain.com - N8N_PROTOCOLhttps - N8N_PORT5678 - TZAsia/Shanghai - WEBHOOK_URLhttps://yourdomain.com/ - GENERIC_TIMEZONEAsia/Shanghai - N8N_SECURE_COOKIEfalse volumes: - n8n_data:/home/node/.n8n networks: - n8n_net volumes: n8n_data: networks: n8n_net: driver: bridge我这里解释几个关键点。N8N_SECURE_COOKIEfalse这个比较重要。如果你用的是 HTTP 访问不把这个设成 false登录之后 Cookie 可能保存不了会出现反复跳登录页的问题。如果你配置了 HTTPS 反向代理可以不加这个环境变量或者保持默认的安全设置。WEBHOOK_URL是给外部 Webhook 回调用的。新闻雷达主要是 n8n 主动抓取所以这个参数不是必须的但我建议提前设好因为后面如果要加“手动触发”或者“外部系统上报”功能没有这个会踩坑。数据目录使用命名卷n8n_data挂载到容器内/home/node/.n8n这样升级容器镜像时工作流、凭证都不会丢失。启动命令就两条docker compose up -d docker compose logs -f n8n第一次启动会自动初始化数据库默认使用 SQLite对咱们这种个人使用规模完全足够。等日志里出现Editor is now accessible via字样就可以通过http://服务器IP:5678访问 n8n 编辑器了。2.3 反向代理与 HTTPS 配置钉钉自定义机器人回调要求必须是公网可达的 HTTPS 地址吗这个后面会说。但是为了安全我建议给 n8n 套一层 Nginx 反向代理加上 HTTPS。因为 n8n 里保存着凭证信息明文 HTTP 传输还是不太放心。Nginx 配置核心部分如下server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { proxy_pass http://127.0.0.1:5678; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }这里有个关键点是proxy_set_header Connection upgrade因为 n8n 编辑器界面需要用 WebSocket 和后台通信少了这个头编辑器打开后可能一直是加载状态。我把这个配置放到/etc/nginx/conf.d/n8n.conf之后 reload 一下再用浏览器访问 https 域名一切正常。注意如果 n8n 容器内设置了N8N_PROTOCOLhttps和N8N_HOSTNginx 反代时会透传 Host否则页面会不断跳转这是最常见的部署问题之一。3. 钉钉机器人的创建与安全配置3.1 创建自定义机器人推送消息的目标我选的是钉钉群自定义机器人。创建流程很简单在钉钉群聊中点击右上角的群设置 - 智能群助手 - 添加机器人 - 自定义。创建完成后会给你一个 Webhook 地址形态类似https://oapi.dingtalk.com/robot/send?access_tokenxxxxxxxx这个地址就是钉钉群的“收信邮箱”请求它就能往群里发消息。需要注意Webhook 地址本身已经携带了 token 凭证不能泄露否则任何人都能往你的群里发垃圾消息。我个人的做法是把这个地址作为 n8n 里的凭证保存而不是直接写在工作流 JSON 里这样即使导出工作流文件也不容易暴露。3.2 加签模式钉钉机器人支持两种安全设置自定义关键词、加签。我强烈建议用“加签”因为新闻推送内容里的关键词是动态的你很难固定一个词。如果只设置关键词而推送内容里恰好没有那个词消息就会被钉钉拦截。加签模式的原理是你在机器人设置里拿到一个加签密钥通常以SEC开头在发送请求时需要把时间戳加上密钥做 HMAC-SHA256 签名然后拼到请求参数里。签名生成逻辑如下import time import hmac import hashlib import base64 import urllib.parse timestamp str(round(time.time() * 1000)) secret SECxxxxxxxxxxxxxxxxxxxx string_to_sign f{timestamp}\n{secret} hmac_code hmac.new(secret.encode(utf-8), string_to_sign.encode(utf-8), digestmodhashlib.sha256).digest() sign urllib.parse.quote_plus(base64.b64encode(hmac_code))请求 URL 就变成https://oapi.dingtalk.com/robot/send?access_tokenxxxxxxxxtimestampxxxsignxxxn8n 里做这个签名比 Python 简单因为它有一个 Crypto 节点。但更推荐的方式是直接在钉钉机器人节点里填 Webhook 和密钥n8n 官方钉钉节点的实现会自动处理加签。不过要注意n8n 自带的钉钉节点在推送 markdown 类型消息时的格式支持有限我自己绕过了自带节点直接用 HTTP Request 节点发送原始请求。这个选择我后面会展开说。3.3 钉钉消息格式钉钉自定义机器人支持 text、markdown、link、actionCard 等消息类型。对于资讯推送我用的是markdown类型因为可以设置标题正文里支持链接阅读体验比纯文本好很多。一个最小可用的 markdown 推送请求体格式为{ msgtype: markdown, markdown: { title: 新闻雷达日报, text: ### 今日热点\n\n**[标题](https://链接)**\n\n摘要内容\n\n---\n } }如果推送给自己的私聊消息或者在群里 某些人也可以在请求体中加at字段。我一般不加因为群里有不同角色频繁 会打扰人。如果你只有自己一个“机器人管理员”也可以设置at: {isAtAll: false}表示不所有人这是默认行为。4. 工作流整体设计与核心节点解析4.1 工作流大纲打开 n8n 编辑器后新建一个 Workflow。我的工作流节点从上到下依次为Schedule Trigger定时触发RSS Feed Read读取多路源Merge合并数据Code数据清洗去重、解析、格式化Code关键词过滤 评分HTTP Request调用大模型接口做摘要可选Code组装钉钉消息 MarkdownHTTP Request推送到钉钉下面每个步骤展开。4.2 定时触发Schedule Trigger 配置Schedule Trigger 的配置很简单点击节点后选择Cron模式。我用的表达式是*/15 * * * *表示每 15 分钟执行一次。这个频率是基于资讯时效性和钉钉推送频率权衡后选的。高于这个频率比如每分钟意义不大因为 RSS 源更新本身有延迟低于这个频率比如每小时又会错过一些突发消息。如果你对某些源有特殊时效要求可以把它们拆成单独的工作流单独设置更高的频率。比如我的竞品公告流是 5 分钟一次行业媒体流是 30 分钟一次。提示n8n 的 Cron 表达式使用 5 位标准格式分别是分、时、日、月、周。注意*/15 * * * *和0 */4 * * *这类写法因为 n8n 不会像 Jenkins 那样自动补?写错段位会导致触发时间完全不对。4.3 多源读取RSS Feed Read 节点n8n 内置的 RSS Read 节点支持输入一个 URL 数组它会对每个 URL 分别发起请求并输出一组结果。我这里配了大约 10 个源包括行业内几个头部媒体、开源社区的 news feed、两个竞品官方博客。在配置 URL 列表的时候我建议把不稳定的源“隔离”开。RSS Read 节点在默认情况下如果其中一个源返回 500 错误整个节点可能会执行失败工作流会在这一步报错导致后面所有推送都中断。解决方案有两种在节点设置里打开Continue On Fail遇到错误继续执行这样某个源挂了不影响整体为每个重要源单独建一个 RSS Read 节点后续再用 Merge 合并。我最终用的是第二种方案因为第一种方案虽然不会中断但失败源当天可能完全不输出数据容易产生“静默丢失”。单独节点后当我看到某一路输出为空时我能立刻知道是那个源出了问题。4.4 数据合并与清洗合并节点我选择了Append模式因为不同源之间是并列关系不是需要按字段对齐的关系。之后接一个 Code 节点做数据清洗。清洗的核心逻辑有三块字段标准化把每个 RSS 源的title、contentSnippet、link、isoDate字段都统一成同一个结构。去重同一篇文章可能同时出现在多个源里以链接 URL 作为去重键保留最早一条记录。剔除旧文章n8n 每次运行会拿到 RSS 的最新 N 条我们需要设定一个时间阈值比如此次运行时只保留最近 12 小时内的文章避免重复推送历史内容。写这个 Code 节点的脚本我用了 Python因为 n8n 支持 Python Code 节点需要额外开启大多数时候用的是 JavaScript Code 节点因为 JavaScript 节点是内置的。我的 JavaScript 示例大概是下面这样const items $input.all(); const now Date.now(); const THRESHOLD_MS 12 * 60 * 60 * 1000; const seen new Set(); const cleanItems []; for (const item of items) { const json item.json; const link json.link ? json.link.trim() : ; const gmtDate json.isoDate ? new Date(json.isoDate).getTime() : now; if (!link || gmtDate now - THRESHOLD_MS) continue; if (seen.has(link)) continue; seen.add(link); cleanItems.push({ title: (json.title || ).replace(/\s/g, ).trim(), link: link, content: (json.contentSnippet || json.content || ).slice(0, 300), date: new Date(gmtDate).toISOString() }); } return cleanItems.map(item ({ json: item }));这段代码的细节contentSnippet通常是 HTML 标签被剥离后的纯文本但仍可能有实体字符比如amp;如果你看到推送内容里一堆乱麻记得加一步 HTML 实体解码。我后来直接用npm包的方式在 Code 节点里引入he库来解码或者干脆用正则简单替换常见实体。4.5 关键词过滤与评分这一步是整个“雷达”含金量最高的地方。我维护了两类规则白名单关键词和黑名单关键词。白名单比如大模型、开源、融资、收购、安全漏洞、架构、发布等黑名单比如招聘、广告、抽奖、直播预约等。每条新闻会打一个分命中白名单 1命中黑名单直接剔除。最后只保留分数大于等于 1 的条目。如果用 JavaScript 实现大概是这样的const items $input.all().map(i i.json); const whiteWords [大模型, 开源, 融资, 收购, 安全漏洞, 发布, 架构]; const blackWords [招聘, 广告, 抽奖, 直播预约, 推广]; const result []; for (const item of items) { const text ${item.title} ${item.content}.toLowerCase(); let score 0; let blocked false; for (const word of blackWords) { if (text.includes(word.toLowerCase())) { blocked true; break; } } if (blocked) continue; for (const word of whiteWords) { if (text.includes(word.toLowerCase())) score; } if (score 0) { item.score score; result.push(item); } } result.sort((a, b) b.score - a.score || new Date(b.date) - new Date(a.date)); return result.map(item ({ json: item }));这个过滤规则的粒度你可以根据自己的需求增加比如给不同关键词加权、设置“必须同时命中两个关键词”之类。但我的建议是初版不要做太复杂先让每 15 分钟平均能推 1~5 条再根据这 1~5 条的质量慢慢调词表。这是最稳的调优路径。4.6 可选的 AI 摘要增强最开始我直接把contentSnippet截断到 300 字推送到钉钉。但 RSS 的 contentSnippet 质量参差不齐有的就是页面首段无意义文字有的干脆为空。后来我在过滤节点后面加了一步把新闻标题和正文片段发到大模型接口让它生成一句 50 字以内的摘要。这里用的方式是 HTTP Request 节点调用一个兼容 OpenAI API 的本地模型服务比如 Ollama 或者其他兼容接口这样数据不出内网。请求体大致是{ model: qwen2.5:7b, messages: [ { role: system, content: 你是一个科技资讯编辑请用不超过50字总结新闻要点直接输出摘要内容不要输出其他文字。 }, { role: user, content: 新闻标题{{title}}\n正文{{content}} } ], temperature: 0.3, max_tokens: 200 }注意 n8n 的 HTTP Request 节点可以在 JSON body 里用{{ }}表达式引用前面节点的数据。如果你用 OpenAI 或者兼容接口返回格式一般是choices[0].message.content。我用 Code 节点把这个字段取出来作为摘要字段加到条目里。为什么要加这一步因为新闻标题本身的表达方式差异很大有的标题能看懂有的标题是“震惊体”。AI 摘要能统一信息的表达方式把“最新消息某某公司宣布完成 B 轮融资”重新说成“某某公司获 B 轮融资金额未披露资金将用于产品研发”。这种一致性对于快速浏览非常有帮助。不过加 AI 摘要也有代价增加处理时延如果一次有 10 条串行处理可能要 1~2 分钟另外本地模型对长文本理解有限偶尔会“发挥”。我的处理方式是设置超时为 30 秒同时如果 AI 摘要失败就退回原始 contentSnippet保证推送不断。对于使用场景偏实时的朋友这一步甚至可以完全省掉直接用标题过滤推送。5. 钉钉消息推送细节与工作流调试5.1 为什么用 HTTP Request 而不是钉钉节点n8n 官方有钉钉节点的但实际用下来有两个痛点新版 n8n 的钉钉节点对凭证配置要求比较多有些版本还存在 Bug钉钉节点对 markdown 消息类型封装的字段比较固定无法完全自定义title和text的样式。所以我最终选用了 HTTP Request 节点。配置方式为Method: POSTURL:https://oapi.dingtalk.com/robot/send?access_tokenxxxtimestamp{{ $json.timestamp }}sign{{ $json.sign }}Body Type: JSONBody 内容为{ msgtype: markdown, markdown: { title: 新闻雷达速递, text: {{ $json.content }} } }签名、时间戳、正文我都在前面的 Code 节点统一生成HTTP Request 节点只负责把组装好的内容打出去。这样职责清晰也方便调试。5.2 消息分组策略如果过滤后的新闻有 20 条你直接推到钉钉群里会刷屏机器人的 20 次请求还可能触发限流。我采用分组合并策略定时触发后过滤结果少于 5 条时合并成一条消息发送每条新闻占一行多于 5 条时拆成多条 markdown 消息但每条消息最多塞 5 条新闻编号排序让阅读没有那么大的压迫感。这个分组逻辑可以用一个 Code 节点实现核心是循环切割数组const items $input.all().map(i i.json); const groupSize 5; const groups []; for (let i 0; i items.length; i groupSize) { groups.push(items.slice(i, i groupSize)); } return groups.map(g ({ json: { content: buildContent(g) } }));实际推送时n8n 对 HTTP Request 节点返回的 JSON 数组会自动循环调用也就是说如果上一个 Code 节点返回了 4 个分组对象HTTP Request 会自动发 4 次请求不需要自己写循环。这个机制很关键我第一次以为只发一条结果把整个钉钉群刷了满屏后来才意识到 n8n 的节点会遍历输入数组。5.3 调试技巧手动执行与节点状态搭建过程中调试占了我一半以上的时间。n8n 的调试体验还算友好每个节点下方都有Execute Node按钮最上方也有工作流级的 Execute Workflow 按钮。我习惯按下面的顺序调试先执行 RSS Read 节点确认能取到数据再执行清洗节点查看输出 JSON确认没有报错然后执行过滤节点观察关键词命中情况其次执行钉钉组装节点直接看生成的消息长什么样最后执行 HTTP Request 节点看钉钉群消息是否成功。每个节点执行完后可以在右下角 Output 面板看到完整的 JSON 数据方便定位问题。比如某个源返回的字段名不是contentSnippet而是summary这一步就会发现。注意n8n 默认的 Code 节点执行超时是 240 秒如果你在 AI 摘要节点中串行处理太多条数据可能会触发超时。建议限制每次最多处理 10 条或者使用 n8n 的Execute Sub-Workflow节点做并行处理但这个复杂度比较高初版不建议上。5.4 限流与幂等问题钉钉自定义机器人的发送频率限制是每分钟最多 20 条消息。正常情况分组后不会触及但如果你重启工作流或者手动执行了好几次可能触发限流钉钉会返回错误码130101对应错误消息为Too Many Requests。我在 HTTP Request 节点的 Options 里启用了Retry On Fail重试次数 3重试间隔 2 秒基本能扛过临时限流。但还是建议手动测试时留个心眼不要一口气执行十几次。另一个问题是幂等。如果 n8n 工作流因为上一个节点失败而重跑可能在下一个周期重复推送同一篇文章。我的去重在清洗节点已经处理了但这里还有一个时间窗口问题如果 RSS 源在第一次运行时没有把最新数据完全吐出来下一次运行时我 12 小时阈值内仍会看到它就会产生一次重复推送。为此我在清洗节点里增加了一个“最近推送文章链接缓存”利用 n8n 的 Static Data 功能保存最近 50 条link如果一条链接已经在缓存里就跳过。这个做法能有效避免绝大多数重复。Static Data 的读取写入方式如下const workflowStaticData $getWorkflowStaticData(global); const sentLinks workflowStaticData.sentLinks || []; // 判断 if (sentLinks.includes(link)) continue; // 写入 sentLinks.push(link); if (sentLinks.length 50) sentLinks.shift(); workflowStaticData.sentLinks sentLinks;这种方式不需要外部数据库纯粹用 n8n 工作流自带的小存储来记录状态对个人项目来说足够轻量。6. 生产环境稳定运行的经验与踩坑记录6.1 忘记 n8n 密码与账号恢复部署完成后的第一道坑可能就是忘记密码。n8n 默认管理员账号是邮箱密码模式如果你忘了密码或者迁移服务器时数据库是旧的登录不进去。这时可以直接操作容器内 SQLite 数据库来重置。先进入容器docker exec -it n8n /bin/sh然后使用 node 脚本修改密码。n8n 的密码是用 bcrypt 哈希存储的最简单的做法是写一段临时脚本生成新密码哈希。我这里提供一种比较稳的方法先在本地用 node 的 bcryptjs 生成哈希串然后更新到数据库。SQLite 文件在容器内的路径是/home/node/.n8n/database.sqlite用 sqlite3 命令更新user表sqlite3 /home/node/.n8n/database.sqlite UPDATE user SET password 新哈希串 WHERE email 你的邮箱;执行完后重启 n8n 容器再用新密码登录即可。这个操作会重置你的密码不影响工作流数据。其实更推荐的方式是直接用 n8n CLI 提供的用户管理命令但在某些版本中 CLI 命令不完整所以我最后用 SQL 直接改效果是等价的。6.2 内存占用过高与容器自动重启n8n 本身的内存占用不算低Node.js 运行时加上工作流执行环境空闲时大概 300~500MB。如果工作流里加入了大模型调用一次执行内存可能飙到 1GB 以上。我在部署初期的教训是没有设置资源限制结果某次 RSS 源返回了异常巨大的 content 字段工作流处理到一半时进程 OOM整个 n8n 直接挂掉。解决方案分两层在 docker-compose 中给 n8n 容器设置内存上限例如mem_limit: 1g在清洗节点的最开始对content字段做截断只保留前 500 字符防止大文本进入后续大模型接口。另外我开启了 Docker 的自动重启策略restart: unless-stopped这样即使进程崩溃容器也会在几秒内恢复。工作流执行失败时消息会留在“Execution 历史”里不会丢失方便事后复盘。6.3 时区与 Cron 的偏差因为服务器默认时区是 UTC我的定时 Cron 如果写0 8 * * *实际触发的是北京时间下午 4 点。这个问题很容易被忽略。我在 docker-compose 环境变量里已经设置了TZAsia/Shanghai但还需要在 n8n 工作流的节点设置里把 Schedule Trigger 时区选为 Asia/Shanghai。否则节点仍然按服务器时区执行。提示n8n 工作流设置页的右上角可以单独设置工作流的时区。如果你同一个 n8n 里既有中国时区的工作流又有需要 UTC 的时间记录建议统一设置成 Asia/Shanghai然后所有时间相关的转换都在 Code 节点里手动处理。6.4 Unicode、HTML 实体与钉钉 Markdown 渲染推送内容里偶尔会出现amp;、lt;这类 HTML 实体如果标题或摘要里有下划线、星号甚至可能破坏钉钉的 Markdown 渲染。比如技术文章标题里如果包含_Markdown 会把它当作斜体标记导致整个标题显示变形。我的解决办法是在组装消息之前统一做一次转义处理function escapeDingMarkdown(text) { return text .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(/([\\*_[\]])/g, \\$1); }注意顺序先处理 HTML 实体再处理 Markdown 特殊字符否则会二次转义出错。钉钉 Markdown 对链接的渲染也有限制标准写法为[文本](链接)是支持的但链接文本里的括号要小心。避免把整个长 URL 直接扔在正文里钉钉会把它显示得很长且不可点击体验很差。6.5 网络中断与超时RSS 源和 AI 接口都存在超时风险。我在 HTTP Request 节点中统一设置超时时间为 30 秒并在On Error分支中发送一条静默日志到另一个调试群而不是直接抛异常停止整个流程。n8n 的 Error Trigger 节点可以捕获工作流级的异常把它接到一个专门发错误通知的 HTTP Request 节点这样当工作流某一步出错时我只会在调试群里看到一条“某节点执行失败”的消息主流程仍然正常推进。这个方法极其重要因为你不可能天天盯着 n8n 后台。7. 进阶玩法与扩展方向这套新闻雷达跑通后我基本处于“只需要偶尔调一下关键词”的维护状态。但它作为 n8n 的一个地基型工作流扩展起来非常顺手。我自己后续已经试过的几个方向也给你参考多端推送钉钉之外再加一个企业微信机器人或者 Telegram Bot逻辑几乎一致多复制两个 HTTP Request 节点就行。考虑到不同团队的协作工具不同这个扩展很实用。每日日报定时器从每 15 分钟改成每天 08:30 执行把所有命中高分的新闻汇总成一个长 Markdown推送到群。我现在是工作日早上推日报白天保持实时推送晚间降低频率。与 RAGFlow 联动n8n 的 HTTP 节点也可以把新闻内容输出到 RAGFlow 的知识库接口实现“资讯自动入库”。这样后续做内部问答、资料检索时能直接检索到最新的行业新闻。这部分我还在调但已经把“抓取 → 清洗 → 入库”走通了。大模型二次筛选在关键词过滤后再加一个大模型节点把一些低质量、无价值的内容剔除。这个比纯关键词更智能但成本会上去适合对精准度要求更高的场景。多账号多群分流不同团队关注不同方向比如前端组关注前端框架动态AI 组关注模型论文和框架发布。我可以通过 n8n 的子工作流来按不同关键词分发到不同的钉钉群避免一刀切全量推送。8. 常见问题速查表我把这段时间遇到的典型问题整理成了一张速查表方便你排查。现象可能原因解决方案钉钉群里没有消息Schedule Trigger 时区不对或 RSS 源返回空检查执行记录确认 RSS 输出是否有数据消息推送了但内容是空的contentSnippet 为空或过滤条件全部未命中打印 RSS 原始 JSON确认字段名推送报错 130101超过钉钉机器人限流减少分组数开启 Retry On Fail推送报错 310000加签错误或 timestamp 与服务器时间差过大检查签名生成逻辑时间戳使用毫秒级n8n 页面一直转圈反向代理缺少 WebSocket 升级头在 Nginx 配置中加上 Upgrade 和 Connection 头登录后跳回登录页N8N_SECURE_COOKIE 问题在 HTTP 场景下设置 false或改用 HTTPS工作流执行失败但不知道原因没有配置错误通知增加 Error Trigger 节点推送到调试群运行一段时间后 n8n 变慢执行历史数据累积过多定期清理 Executions 历史或关闭部分工作流的持久化如果你也正在搭类似的资讯推送流建议第一次跑通时不要追求完美抓取 → 过滤 → 推送是最小闭环。先把这条链路跑通再逐步加入 AI 摘要、分组策略、扩展推送渠道。这套方案的精髓在于“中间层用 n8n 做胶水”你完全可以根据自己的信源类型和推送目标做出千变万化的版本。我自己实际跑下来最明显的感受是每天省下的信息筛选时间远超搭建这套系统的时间这也是我愿意花篇幅把这些细节写出来的原因。 用n8n搭建新闻雷达：RSS订阅+钉钉推送+AI摘要全流程实战
直接进入正题。这篇不是概念介绍是把我自己跑通的一套“新闻雷达”完整拆给你看从 n8n 部署、钉钉机器人接入、RSS 源配置到关键词过滤、AI 摘要、定时推送再到后续优化和踩坑记录。你能照着搭一套也能拿来当 n8n 工作流设计的参考。1. 为什么我会用 n8n 搭“新闻雷达”先说需求背景。我平时要盯的资讯源很杂科技媒体、开源社区、行业论坛、几个竞品的官方博客。最早我靠的是“早上刷一遍 零散订阅”但这种方式有两个致命问题一是信息滞后等我在群里看到转发时往往是几个小时甚至一天之后二是噪音太大真正有用的可能只有几条但为了找这几条我要把几十个页面翻一遍。后来我试过专门的 RSS 阅读器也试过 Python 脚本定时抓取但都有各自的麻烦。RSS 阅读器只解决“聚合”不解决“推送”我还是要主动打开Python 脚本能推送但改规则、加源、调试要动代码我这种三天两头想调过滤词的人改脚本的成本实在太高。于是我把目光放到了 n8n 上。n8n 是一个可视化的工作流自动化工具你可以把它理解成一个“可视化管道”左边接数据源中间做加工右边推到目标系统。它自带的节点非常多HTTP 请求、RSS Feed、定时触发、Webhook、各类消息平台都有现成节点。更重要的是它是开源自托管的数据完全在自己手里不会出现“某个免费云服务突然停止运营”这种问题。整个方案的最终形态是这样的n8n 每隔 15 分钟抓取一次各信息源的 RSS 数据经过去重、关键词过滤、AI 摘要、排序这几个步骤最后通过钉钉自定义机器人把消息推送到群聊里。整个链路跑起来之后我每天早上一打开钉钉就能看到一份已经整理好的资讯摘要。下面我分步讲清楚每个环节的选型和实现。2. n8n 部署方式对比与 Docker 部署实操2.1 本地、云主机还是 Dockern8n 的部署方式大体有三种npx 直接跑、Docker 部署、官方云服务。我个人的建议是如果你打算把它当作一个长期跑的“基础设施”优先选 Docker 部署在自己的云主机或 NAS 上。npx 方式启动最简单的一条命令npx n8n但问题也很明显它是前台进程一旦终端断开进程就没了升级和管理依赖也比较麻烦。官方云服务虽然省心但要按月付费而且工作流里的数据都在第三方平台上对一部分场景来说会有隐私顾虑。Docker 部署则兼顾了可控性和可维护性尤其适合挂在服务器上长期运行。2.2 Docker Compose 部署步骤我的环境是一台 2 核 4G 的云主机操作系统是 Ubuntu 22.04Docker 版本 24.x。部署用的 docker-compose.yml 我直接贴出来version: 3.8 services: n8n: image: n8nio/n8n:latest container_name: n8n restart: unless-stopped ports: - 5678:5678 environment: - N8N_HOSTyourdomain.com - N8N_PROTOCOLhttps - N8N_PORT5678 - TZAsia/Shanghai - WEBHOOK_URLhttps://yourdomain.com/ - GENERIC_TIMEZONEAsia/Shanghai - N8N_SECURE_COOKIEfalse volumes: - n8n_data:/home/node/.n8n networks: - n8n_net volumes: n8n_data: networks: n8n_net: driver: bridge我这里解释几个关键点。N8N_SECURE_COOKIEfalse这个比较重要。如果你用的是 HTTP 访问不把这个设成 false登录之后 Cookie 可能保存不了会出现反复跳登录页的问题。如果你配置了 HTTPS 反向代理可以不加这个环境变量或者保持默认的安全设置。WEBHOOK_URL是给外部 Webhook 回调用的。新闻雷达主要是 n8n 主动抓取所以这个参数不是必须的但我建议提前设好因为后面如果要加“手动触发”或者“外部系统上报”功能没有这个会踩坑。数据目录使用命名卷n8n_data挂载到容器内/home/node/.n8n这样升级容器镜像时工作流、凭证都不会丢失。启动命令就两条docker compose up -d docker compose logs -f n8n第一次启动会自动初始化数据库默认使用 SQLite对咱们这种个人使用规模完全足够。等日志里出现Editor is now accessible via字样就可以通过http://服务器IP:5678访问 n8n 编辑器了。2.3 反向代理与 HTTPS 配置钉钉自定义机器人回调要求必须是公网可达的 HTTPS 地址吗这个后面会说。但是为了安全我建议给 n8n 套一层 Nginx 反向代理加上 HTTPS。因为 n8n 里保存着凭证信息明文 HTTP 传输还是不太放心。Nginx 配置核心部分如下server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { proxy_pass http://127.0.0.1:5678; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }这里有个关键点是proxy_set_header Connection upgrade因为 n8n 编辑器界面需要用 WebSocket 和后台通信少了这个头编辑器打开后可能一直是加载状态。我把这个配置放到/etc/nginx/conf.d/n8n.conf之后 reload 一下再用浏览器访问 https 域名一切正常。注意如果 n8n 容器内设置了N8N_PROTOCOLhttps和N8N_HOSTNginx 反代时会透传 Host否则页面会不断跳转这是最常见的部署问题之一。3. 钉钉机器人的创建与安全配置3.1 创建自定义机器人推送消息的目标我选的是钉钉群自定义机器人。创建流程很简单在钉钉群聊中点击右上角的群设置 - 智能群助手 - 添加机器人 - 自定义。创建完成后会给你一个 Webhook 地址形态类似https://oapi.dingtalk.com/robot/send?access_tokenxxxxxxxx这个地址就是钉钉群的“收信邮箱”请求它就能往群里发消息。需要注意Webhook 地址本身已经携带了 token 凭证不能泄露否则任何人都能往你的群里发垃圾消息。我个人的做法是把这个地址作为 n8n 里的凭证保存而不是直接写在工作流 JSON 里这样即使导出工作流文件也不容易暴露。3.2 加签模式钉钉机器人支持两种安全设置自定义关键词、加签。我强烈建议用“加签”因为新闻推送内容里的关键词是动态的你很难固定一个词。如果只设置关键词而推送内容里恰好没有那个词消息就会被钉钉拦截。加签模式的原理是你在机器人设置里拿到一个加签密钥通常以SEC开头在发送请求时需要把时间戳加上密钥做 HMAC-SHA256 签名然后拼到请求参数里。签名生成逻辑如下import time import hmac import hashlib import base64 import urllib.parse timestamp str(round(time.time() * 1000)) secret SECxxxxxxxxxxxxxxxxxxxx string_to_sign f{timestamp}\n{secret} hmac_code hmac.new(secret.encode(utf-8), string_to_sign.encode(utf-8), digestmodhashlib.sha256).digest() sign urllib.parse.quote_plus(base64.b64encode(hmac_code))请求 URL 就变成https://oapi.dingtalk.com/robot/send?access_tokenxxxxxxxxtimestampxxxsignxxxn8n 里做这个签名比 Python 简单因为它有一个 Crypto 节点。但更推荐的方式是直接在钉钉机器人节点里填 Webhook 和密钥n8n 官方钉钉节点的实现会自动处理加签。不过要注意n8n 自带的钉钉节点在推送 markdown 类型消息时的格式支持有限我自己绕过了自带节点直接用 HTTP Request 节点发送原始请求。这个选择我后面会展开说。3.3 钉钉消息格式钉钉自定义机器人支持 text、markdown、link、actionCard 等消息类型。对于资讯推送我用的是markdown类型因为可以设置标题正文里支持链接阅读体验比纯文本好很多。一个最小可用的 markdown 推送请求体格式为{ msgtype: markdown, markdown: { title: 新闻雷达日报, text: ### 今日热点\n\n**[标题](https://链接)**\n\n摘要内容\n\n---\n } }如果推送给自己的私聊消息或者在群里 某些人也可以在请求体中加at字段。我一般不加因为群里有不同角色频繁 会打扰人。如果你只有自己一个“机器人管理员”也可以设置at: {isAtAll: false}表示不所有人这是默认行为。4. 工作流整体设计与核心节点解析4.1 工作流大纲打开 n8n 编辑器后新建一个 Workflow。我的工作流节点从上到下依次为Schedule Trigger定时触发RSS Feed Read读取多路源Merge合并数据Code数据清洗去重、解析、格式化Code关键词过滤 评分HTTP Request调用大模型接口做摘要可选Code组装钉钉消息 MarkdownHTTP Request推送到钉钉下面每个步骤展开。4.2 定时触发Schedule Trigger 配置Schedule Trigger 的配置很简单点击节点后选择Cron模式。我用的表达式是*/15 * * * *表示每 15 分钟执行一次。这个频率是基于资讯时效性和钉钉推送频率权衡后选的。高于这个频率比如每分钟意义不大因为 RSS 源更新本身有延迟低于这个频率比如每小时又会错过一些突发消息。如果你对某些源有特殊时效要求可以把它们拆成单独的工作流单独设置更高的频率。比如我的竞品公告流是 5 分钟一次行业媒体流是 30 分钟一次。提示n8n 的 Cron 表达式使用 5 位标准格式分别是分、时、日、月、周。注意*/15 * * * *和0 */4 * * *这类写法因为 n8n 不会像 Jenkins 那样自动补?写错段位会导致触发时间完全不对。4.3 多源读取RSS Feed Read 节点n8n 内置的 RSS Read 节点支持输入一个 URL 数组它会对每个 URL 分别发起请求并输出一组结果。我这里配了大约 10 个源包括行业内几个头部媒体、开源社区的 news feed、两个竞品官方博客。在配置 URL 列表的时候我建议把不稳定的源“隔离”开。RSS Read 节点在默认情况下如果其中一个源返回 500 错误整个节点可能会执行失败工作流会在这一步报错导致后面所有推送都中断。解决方案有两种在节点设置里打开Continue On Fail遇到错误继续执行这样某个源挂了不影响整体为每个重要源单独建一个 RSS Read 节点后续再用 Merge 合并。我最终用的是第二种方案因为第一种方案虽然不会中断但失败源当天可能完全不输出数据容易产生“静默丢失”。单独节点后当我看到某一路输出为空时我能立刻知道是那个源出了问题。4.4 数据合并与清洗合并节点我选择了Append模式因为不同源之间是并列关系不是需要按字段对齐的关系。之后接一个 Code 节点做数据清洗。清洗的核心逻辑有三块字段标准化把每个 RSS 源的title、contentSnippet、link、isoDate字段都统一成同一个结构。去重同一篇文章可能同时出现在多个源里以链接 URL 作为去重键保留最早一条记录。剔除旧文章n8n 每次运行会拿到 RSS 的最新 N 条我们需要设定一个时间阈值比如此次运行时只保留最近 12 小时内的文章避免重复推送历史内容。写这个 Code 节点的脚本我用了 Python因为 n8n 支持 Python Code 节点需要额外开启大多数时候用的是 JavaScript Code 节点因为 JavaScript 节点是内置的。我的 JavaScript 示例大概是下面这样const items $input.all(); const now Date.now(); const THRESHOLD_MS 12 * 60 * 60 * 1000; const seen new Set(); const cleanItems []; for (const item of items) { const json item.json; const link json.link ? json.link.trim() : ; const gmtDate json.isoDate ? new Date(json.isoDate).getTime() : now; if (!link || gmtDate now - THRESHOLD_MS) continue; if (seen.has(link)) continue; seen.add(link); cleanItems.push({ title: (json.title || ).replace(/\s/g, ).trim(), link: link, content: (json.contentSnippet || json.content || ).slice(0, 300), date: new Date(gmtDate).toISOString() }); } return cleanItems.map(item ({ json: item }));这段代码的细节contentSnippet通常是 HTML 标签被剥离后的纯文本但仍可能有实体字符比如amp;如果你看到推送内容里一堆乱麻记得加一步 HTML 实体解码。我后来直接用npm包的方式在 Code 节点里引入he库来解码或者干脆用正则简单替换常见实体。4.5 关键词过滤与评分这一步是整个“雷达”含金量最高的地方。我维护了两类规则白名单关键词和黑名单关键词。白名单比如大模型、开源、融资、收购、安全漏洞、架构、发布等黑名单比如招聘、广告、抽奖、直播预约等。每条新闻会打一个分命中白名单 1命中黑名单直接剔除。最后只保留分数大于等于 1 的条目。如果用 JavaScript 实现大概是这样的const items $input.all().map(i i.json); const whiteWords [大模型, 开源, 融资, 收购, 安全漏洞, 发布, 架构]; const blackWords [招聘, 广告, 抽奖, 直播预约, 推广]; const result []; for (const item of items) { const text ${item.title} ${item.content}.toLowerCase(); let score 0; let blocked false; for (const word of blackWords) { if (text.includes(word.toLowerCase())) { blocked true; break; } } if (blocked) continue; for (const word of whiteWords) { if (text.includes(word.toLowerCase())) score; } if (score 0) { item.score score; result.push(item); } } result.sort((a, b) b.score - a.score || new Date(b.date) - new Date(a.date)); return result.map(item ({ json: item }));这个过滤规则的粒度你可以根据自己的需求增加比如给不同关键词加权、设置“必须同时命中两个关键词”之类。但我的建议是初版不要做太复杂先让每 15 分钟平均能推 1~5 条再根据这 1~5 条的质量慢慢调词表。这是最稳的调优路径。4.6 可选的 AI 摘要增强最开始我直接把contentSnippet截断到 300 字推送到钉钉。但 RSS 的 contentSnippet 质量参差不齐有的就是页面首段无意义文字有的干脆为空。后来我在过滤节点后面加了一步把新闻标题和正文片段发到大模型接口让它生成一句 50 字以内的摘要。这里用的方式是 HTTP Request 节点调用一个兼容 OpenAI API 的本地模型服务比如 Ollama 或者其他兼容接口这样数据不出内网。请求体大致是{ model: qwen2.5:7b, messages: [ { role: system, content: 你是一个科技资讯编辑请用不超过50字总结新闻要点直接输出摘要内容不要输出其他文字。 }, { role: user, content: 新闻标题{{title}}\n正文{{content}} } ], temperature: 0.3, max_tokens: 200 }注意 n8n 的 HTTP Request 节点可以在 JSON body 里用{{ }}表达式引用前面节点的数据。如果你用 OpenAI 或者兼容接口返回格式一般是choices[0].message.content。我用 Code 节点把这个字段取出来作为摘要字段加到条目里。为什么要加这一步因为新闻标题本身的表达方式差异很大有的标题能看懂有的标题是“震惊体”。AI 摘要能统一信息的表达方式把“最新消息某某公司宣布完成 B 轮融资”重新说成“某某公司获 B 轮融资金额未披露资金将用于产品研发”。这种一致性对于快速浏览非常有帮助。不过加 AI 摘要也有代价增加处理时延如果一次有 10 条串行处理可能要 1~2 分钟另外本地模型对长文本理解有限偶尔会“发挥”。我的处理方式是设置超时为 30 秒同时如果 AI 摘要失败就退回原始 contentSnippet保证推送不断。对于使用场景偏实时的朋友这一步甚至可以完全省掉直接用标题过滤推送。5. 钉钉消息推送细节与工作流调试5.1 为什么用 HTTP Request 而不是钉钉节点n8n 官方有钉钉节点的但实际用下来有两个痛点新版 n8n 的钉钉节点对凭证配置要求比较多有些版本还存在 Bug钉钉节点对 markdown 消息类型封装的字段比较固定无法完全自定义title和text的样式。所以我最终选用了 HTTP Request 节点。配置方式为Method: POSTURL:https://oapi.dingtalk.com/robot/send?access_tokenxxxtimestamp{{ $json.timestamp }}sign{{ $json.sign }}Body Type: JSONBody 内容为{ msgtype: markdown, markdown: { title: 新闻雷达速递, text: {{ $json.content }} } }签名、时间戳、正文我都在前面的 Code 节点统一生成HTTP Request 节点只负责把组装好的内容打出去。这样职责清晰也方便调试。5.2 消息分组策略如果过滤后的新闻有 20 条你直接推到钉钉群里会刷屏机器人的 20 次请求还可能触发限流。我采用分组合并策略定时触发后过滤结果少于 5 条时合并成一条消息发送每条新闻占一行多于 5 条时拆成多条 markdown 消息但每条消息最多塞 5 条新闻编号排序让阅读没有那么大的压迫感。这个分组逻辑可以用一个 Code 节点实现核心是循环切割数组const items $input.all().map(i i.json); const groupSize 5; const groups []; for (let i 0; i items.length; i groupSize) { groups.push(items.slice(i, i groupSize)); } return groups.map(g ({ json: { content: buildContent(g) } }));实际推送时n8n 对 HTTP Request 节点返回的 JSON 数组会自动循环调用也就是说如果上一个 Code 节点返回了 4 个分组对象HTTP Request 会自动发 4 次请求不需要自己写循环。这个机制很关键我第一次以为只发一条结果把整个钉钉群刷了满屏后来才意识到 n8n 的节点会遍历输入数组。5.3 调试技巧手动执行与节点状态搭建过程中调试占了我一半以上的时间。n8n 的调试体验还算友好每个节点下方都有Execute Node按钮最上方也有工作流级的 Execute Workflow 按钮。我习惯按下面的顺序调试先执行 RSS Read 节点确认能取到数据再执行清洗节点查看输出 JSON确认没有报错然后执行过滤节点观察关键词命中情况其次执行钉钉组装节点直接看生成的消息长什么样最后执行 HTTP Request 节点看钉钉群消息是否成功。每个节点执行完后可以在右下角 Output 面板看到完整的 JSON 数据方便定位问题。比如某个源返回的字段名不是contentSnippet而是summary这一步就会发现。注意n8n 默认的 Code 节点执行超时是 240 秒如果你在 AI 摘要节点中串行处理太多条数据可能会触发超时。建议限制每次最多处理 10 条或者使用 n8n 的Execute Sub-Workflow节点做并行处理但这个复杂度比较高初版不建议上。5.4 限流与幂等问题钉钉自定义机器人的发送频率限制是每分钟最多 20 条消息。正常情况分组后不会触及但如果你重启工作流或者手动执行了好几次可能触发限流钉钉会返回错误码130101对应错误消息为Too Many Requests。我在 HTTP Request 节点的 Options 里启用了Retry On Fail重试次数 3重试间隔 2 秒基本能扛过临时限流。但还是建议手动测试时留个心眼不要一口气执行十几次。另一个问题是幂等。如果 n8n 工作流因为上一个节点失败而重跑可能在下一个周期重复推送同一篇文章。我的去重在清洗节点已经处理了但这里还有一个时间窗口问题如果 RSS 源在第一次运行时没有把最新数据完全吐出来下一次运行时我 12 小时阈值内仍会看到它就会产生一次重复推送。为此我在清洗节点里增加了一个“最近推送文章链接缓存”利用 n8n 的 Static Data 功能保存最近 50 条link如果一条链接已经在缓存里就跳过。这个做法能有效避免绝大多数重复。Static Data 的读取写入方式如下const workflowStaticData $getWorkflowStaticData(global); const sentLinks workflowStaticData.sentLinks || []; // 判断 if (sentLinks.includes(link)) continue; // 写入 sentLinks.push(link); if (sentLinks.length 50) sentLinks.shift(); workflowStaticData.sentLinks sentLinks;这种方式不需要外部数据库纯粹用 n8n 工作流自带的小存储来记录状态对个人项目来说足够轻量。6. 生产环境稳定运行的经验与踩坑记录6.1 忘记 n8n 密码与账号恢复部署完成后的第一道坑可能就是忘记密码。n8n 默认管理员账号是邮箱密码模式如果你忘了密码或者迁移服务器时数据库是旧的登录不进去。这时可以直接操作容器内 SQLite 数据库来重置。先进入容器docker exec -it n8n /bin/sh然后使用 node 脚本修改密码。n8n 的密码是用 bcrypt 哈希存储的最简单的做法是写一段临时脚本生成新密码哈希。我这里提供一种比较稳的方法先在本地用 node 的 bcryptjs 生成哈希串然后更新到数据库。SQLite 文件在容器内的路径是/home/node/.n8n/database.sqlite用 sqlite3 命令更新user表sqlite3 /home/node/.n8n/database.sqlite UPDATE user SET password 新哈希串 WHERE email 你的邮箱;执行完后重启 n8n 容器再用新密码登录即可。这个操作会重置你的密码不影响工作流数据。其实更推荐的方式是直接用 n8n CLI 提供的用户管理命令但在某些版本中 CLI 命令不完整所以我最后用 SQL 直接改效果是等价的。6.2 内存占用过高与容器自动重启n8n 本身的内存占用不算低Node.js 运行时加上工作流执行环境空闲时大概 300~500MB。如果工作流里加入了大模型调用一次执行内存可能飙到 1GB 以上。我在部署初期的教训是没有设置资源限制结果某次 RSS 源返回了异常巨大的 content 字段工作流处理到一半时进程 OOM整个 n8n 直接挂掉。解决方案分两层在 docker-compose 中给 n8n 容器设置内存上限例如mem_limit: 1g在清洗节点的最开始对content字段做截断只保留前 500 字符防止大文本进入后续大模型接口。另外我开启了 Docker 的自动重启策略restart: unless-stopped这样即使进程崩溃容器也会在几秒内恢复。工作流执行失败时消息会留在“Execution 历史”里不会丢失方便事后复盘。6.3 时区与 Cron 的偏差因为服务器默认时区是 UTC我的定时 Cron 如果写0 8 * * *实际触发的是北京时间下午 4 点。这个问题很容易被忽略。我在 docker-compose 环境变量里已经设置了TZAsia/Shanghai但还需要在 n8n 工作流的节点设置里把 Schedule Trigger 时区选为 Asia/Shanghai。否则节点仍然按服务器时区执行。提示n8n 工作流设置页的右上角可以单独设置工作流的时区。如果你同一个 n8n 里既有中国时区的工作流又有需要 UTC 的时间记录建议统一设置成 Asia/Shanghai然后所有时间相关的转换都在 Code 节点里手动处理。6.4 Unicode、HTML 实体与钉钉 Markdown 渲染推送内容里偶尔会出现amp;、lt;这类 HTML 实体如果标题或摘要里有下划线、星号甚至可能破坏钉钉的 Markdown 渲染。比如技术文章标题里如果包含_Markdown 会把它当作斜体标记导致整个标题显示变形。我的解决办法是在组装消息之前统一做一次转义处理function escapeDingMarkdown(text) { return text .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(/([\\*_[\]])/g, \\$1); }注意顺序先处理 HTML 实体再处理 Markdown 特殊字符否则会二次转义出错。钉钉 Markdown 对链接的渲染也有限制标准写法为[文本](链接)是支持的但链接文本里的括号要小心。避免把整个长 URL 直接扔在正文里钉钉会把它显示得很长且不可点击体验很差。6.5 网络中断与超时RSS 源和 AI 接口都存在超时风险。我在 HTTP Request 节点中统一设置超时时间为 30 秒并在On Error分支中发送一条静默日志到另一个调试群而不是直接抛异常停止整个流程。n8n 的 Error Trigger 节点可以捕获工作流级的异常把它接到一个专门发错误通知的 HTTP Request 节点这样当工作流某一步出错时我只会在调试群里看到一条“某节点执行失败”的消息主流程仍然正常推进。这个方法极其重要因为你不可能天天盯着 n8n 后台。7. 进阶玩法与扩展方向这套新闻雷达跑通后我基本处于“只需要偶尔调一下关键词”的维护状态。但它作为 n8n 的一个地基型工作流扩展起来非常顺手。我自己后续已经试过的几个方向也给你参考多端推送钉钉之外再加一个企业微信机器人或者 Telegram Bot逻辑几乎一致多复制两个 HTTP Request 节点就行。考虑到不同团队的协作工具不同这个扩展很实用。每日日报定时器从每 15 分钟改成每天 08:30 执行把所有命中高分的新闻汇总成一个长 Markdown推送到群。我现在是工作日早上推日报白天保持实时推送晚间降低频率。与 RAGFlow 联动n8n 的 HTTP 节点也可以把新闻内容输出到 RAGFlow 的知识库接口实现“资讯自动入库”。这样后续做内部问答、资料检索时能直接检索到最新的行业新闻。这部分我还在调但已经把“抓取 → 清洗 → 入库”走通了。大模型二次筛选在关键词过滤后再加一个大模型节点把一些低质量、无价值的内容剔除。这个比纯关键词更智能但成本会上去适合对精准度要求更高的场景。多账号多群分流不同团队关注不同方向比如前端组关注前端框架动态AI 组关注模型论文和框架发布。我可以通过 n8n 的子工作流来按不同关键词分发到不同的钉钉群避免一刀切全量推送。8. 常见问题速查表我把这段时间遇到的典型问题整理成了一张速查表方便你排查。现象可能原因解决方案钉钉群里没有消息Schedule Trigger 时区不对或 RSS 源返回空检查执行记录确认 RSS 输出是否有数据消息推送了但内容是空的contentSnippet 为空或过滤条件全部未命中打印 RSS 原始 JSON确认字段名推送报错 130101超过钉钉机器人限流减少分组数开启 Retry On Fail推送报错 310000加签错误或 timestamp 与服务器时间差过大检查签名生成逻辑时间戳使用毫秒级n8n 页面一直转圈反向代理缺少 WebSocket 升级头在 Nginx 配置中加上 Upgrade 和 Connection 头登录后跳回登录页N8N_SECURE_COOKIE 问题在 HTTP 场景下设置 false或改用 HTTPS工作流执行失败但不知道原因没有配置错误通知增加 Error Trigger 节点推送到调试群运行一段时间后 n8n 变慢执行历史数据累积过多定期清理 Executions 历史或关闭部分工作流的持久化如果你也正在搭类似的资讯推送流建议第一次跑通时不要追求完美抓取 → 过滤 → 推送是最小闭环。先把这条链路跑通再逐步加入 AI 摘要、分组策略、扩展推送渠道。这套方案的精髓在于“中间层用 n8n 做胶水”你完全可以根据自己的信源类型和推送目标做出千变万化的版本。我自己实际跑下来最明显的感受是每天省下的信息筛选时间远超搭建这套系统的时间这也是我愿意花篇幅把这些细节写出来的原因。