n8n 每天抓 5 个源：去重后推送到飞书群

每天手动开 5 个网站抄当天的行业更新，抄完再粘到群里，是最容易坚持不下去的活。用 n8n 把「抓取、统一字段、去重、推送」串成一条工作流，早上 8 点自动出结果。真正的难点不在抓取，而在去重——同一件事被 3 个源转载，不处理的话群里一天能看到三遍。

一句话结论

这条工作流能跑稳，靠的是先去重再合成一条消息，而不是抓到一条推一条。5 个源（2 个 RSS + 3 个网页）每天抓回 130 条左右，原始重复率 63%，去重后剩 40 多条；如果逐条推，群机器人一分钟内被刷 100 条，直接被限流。实测日更 1 天到 30 天，漏推 0 天、重复推送 3 次，那 3 次全部出在「只按上次执行去重」的设置上——改成存历史 ID 之后归零。

这篇解决什么问题

三种情况最常见。一是只挂 RSS 节点，五个源里三个没有 RSS，或者 RSS 只有标题没正文，抓回来一堆没法用的条目。二是用平台自带的「移除重复项」节点，看起来能用，第二天早上发现昨天推过的又推了一遍——它默认只跟上一次执行比。三是抓完立刻逐条发飞书，41 条消息 1 分钟内推出去，机器人触发频率限制，后面的全丢，而你在 n8n 里看到的执行状态是成功。

根子是把这件事当成「定时抓取」，而它其实是「每天产出一份去重清单」：要有统一的字段结构、要有一个能跨天记住「推过什么」的地方、要有一条把多条合成一张卡片的出口。四步做完，得到一条日更工作流、一份历史推送记录表、一张每天 8 点准时出现的汇总卡。

开始前要准备什么

• 5 个源的准确地址，先分清类型：能拿到 RSS 的优先用 RSS（结构稳定、有发布时间）；没有 RSS 的用 HTTP 请求加 HTML 提取，但要先确认页面是服务端渲染——纯前端渲染的页面抓回来是空壳。
• 一个能存历史的地方：飞书多维表格、Google Sheets、或者 n8n 自带的数据库都行。它要能存「推送过的条目 ID」，这是跨天去重的唯一依据。
• 一个飞书群机器人 Webhook：群设置里添加自定义机器人，拿到 hook 地址。注意它是按群限流的，一分钟 100 条上限，这条限制决定了后面必须合并推送。
• 一条去重规则，先写下来再动手：按 URL 去、按标题去、还是按「标题 + 来源」去，三种结果差很多。同一条新闻三个源转载时 URL 完全不同，只按 URL 去等于没去。

具体怎么做

第一步：把 5 个源分成两类，各用一条分支抓

RSS 源用 RSS Read 节点，一次能把标题、链接、时间、正文摘要都拿到。没有 RSS 的网页用 HTTP Request 取 HTML，再用 HTML Extract 按 CSS 选择器取列表项。两条分支后面接同一个字段映射节点，保证出去的数据结构一致——字段不统一，后面的去重和排版全是补丁。

这是我要抓的 5 个源：（列出地址与类型）
其中带 RSS 的是：____；只能抓网页的是：____

请帮我：
1. 为每个网页源给出建议的 CSS 选择器思路（列表容器 → 单条 → 标题 → 链接 → 时间），并说明如果抓不到该先查什么；
2. 设计一个统一字段表：title / url / published_at / source / summary，说明每个字段缺失时怎么兜底（比如没有时间就填抓取时间）；
3. 指出这 5 个源里，哪几个站点的正文是前端渲染的，抓回来会是空壳，需要换方案。

第二步：标题做归一化，这是去重的前提

同一条新闻三个源的标题几乎不会一字不差，但差别只在那几个地方：前缀括号、来源名、末尾的「（附名单）」、全角半角标点、空格。实测 130 条原始条目，归一化之后能配对出 82 条重复，占 63%。

这是一批抓回来的标题（每行一条，共 30 行）：（粘贴）

请写一段处理逻辑（用 Code 节点的 JavaScript），把每个标题归一化成用于比对的 key：
1. 去掉开头的【】和里面的前缀，去掉结尾的「（…）」；
2. 去掉所有空格、全角标点、以及「速看」「重磅」这类无信息量的词；
3. 转小写，取前 40 个字符；
4. 输出：原标题、归一化 key。

然后告诉我：这批 30 条里，按这个 key 能并成几组，分别是哪几条 —— 我要先验证规则再上线，不想上线后才发现规则太松或太紧。

第三步：把「推过什么」存起来，跨天去重

平台自带的移除重复项节点，默认只跟上一次执行比，所以昨天推的今天还会再推一遍。正确做法是自己存：每次推送前，先查出历史上已推的 key 集合，过滤掉命中的，剩下的才进入推送，推送成功后再把这批 key 写回表里，同时记一个推送日期，方便回头看。

这是我的历史推送记录表结构：（字段名与类型）
这是今天去重后的条目：（粘贴）

请帮我：
1. 写出「查历史 → 过滤 → 推送 → 回写」的节点顺序，说明每一步在哪一步失败会造成什么后果（重复推 / 漏推 / 数据不一致）；
2. 回写这一步要放在推送成功之后还是之前，为什么；
3. 如果推送成功但回写失败，第二天会发生什么，怎么兜底。

要求：优先保证不重复推，漏推可以人工补，重复推会让群里的人直接关掉通知。

第四步：多条合成一张卡片，一次推完

41 条不能推 41 次。做法是用飞书的交互卡片，一张卡里放前 10 条（标题 + 来源 + 链接），超出的写「另有 N 条，点开看全部」。卡片比纯文本好在能分行、能带链接，也省频率。实测 41 条合成 1 张卡片推送，耗时 1 秒，未再触发限流。

这是我的 41 条去重后条目（JSON）和飞书群机器人 hook 地址。

请生成一条飞书交互卡片的 JSON：
1. 卡头写日期和条数，例如「10 月 23 日 · 41 条」；
2. 正文只放前 10 条，每条一行：序号、标题（超过 30 字截断）、来源；
3. 标题带原文链接，点击直接跳转；
4. 超过 10 条时，末尾加一行「另有 31 条」，并给出查看全部的入口；
5. 颜色用默认，不要加表情符号。

同时告诉我：如果某天的条数是 0，卡片应该怎么处理 —— 是照发一条「今日无更新」，还是不发。

第五步：把时区钉死，再挂一个失败通知

定时触发器默认按 UTC 走，写「早上 8 点」实际是北京时间下午 4 点。要改两处：工作流设置里的时区改成 Asia/Shanghai，节点里的时间再确认一遍。另外挂一个错误分支，抓取失败或推送失败时给自己发一条消息——否则工作流静默失败，你要等到有人问「今天怎么没有」才知道。

这是我的定时设置与当前时区：（截图或描述）

请检查三件事：
1. 我设的「每天 8:00」在当前时区下，实际触发时间是几点（按北京时间算）；
2. 如果某天某个源抓取失败，整条工作流会停还是继续？我希望单源失败不影响其他源；
3. 帮我写一个错误通知：哪个源失败、错误信息、当天已抓到的条数，发到同一个群的一个独立小群或私聊。

最后给我一份上线前的检查清单，按「会静默失败」的顺序排。

实测记录

对象是一家公司的行业动态日更，5 个源分别是 2 个行业媒体的 RSS、3 个官方站点的公告列表页。第一天手工跑：抓回 137 条，肉眼判断重复 82 条，去重后 55 条，实际推送 41 条（另有 14 条是同一天内二次更新，合并进原条目）。

第一版用平台自带的移除重复项节点，只按「上次执行以来」比较。上线第二天重复推了 9 条，第三天 12 条——每个源每天都会把前几天的内容重新排上首页。改成存历史 key 后，第 4 到 30 天重复推送 0 次。

另一次事故是限流：某天源站集中更新，去重后 96 条，脚本逐条推，第 61 条开始报错，群里只看到前 60 条，而 n8n 的执行记录显示成功（HTTP 200 但飞书返回了错误码在 body 里）。改成合并卡片之后没再复现。整套搭建用了 2 小时 40 分钟，其中 50 分钟花在调那 3 个网页源的 CSS 选择器上。

最容易错的 3 个地方

第一，去重只按 URL。同一条新闻在三个站点是三个不同的链接，按 URL 去等于一条都没去。必须做标题归一化，但规则要先拿真实数据验证松紧：太松会把「同一主题的两条不同进展」并成一条，太紧则重复照旧。

第二，信任「执行成功」。飞书限流时返回的仍是 HTTP 200，错误码在响应体里。只看状态码就会判成功，监控里看不到异常——要显式判断 body 里的 code，非 0 当失败处理。

第三，回写放在推送之前。先写记录再推送，一旦推送失败，这批条目就被标成「已推」，第二天不会重试，等于永久漏掉。顺序必须是：查 → 过滤 → 推 → 推成功再写。宁可漏推人工补，也别重复推——群里被刷两次，人就关通知了。

可复用的东西

统一字段表：title / url / published_at / source / summary，缺时间填抓取时间，缺摘要就留空。字段不统一是后面所有补丁的来源。

标题归一化四步：剥前缀括号 → 去末尾括注 → 去空格与全角标点 → 转小写取前 40 字。实测能把 63% 的重复配出来。

可复用的三列：归一化 key、推送日期、来源。它是跨天去重的唯一依据，别指望平台节点的默认行为。

失败通知的最小内容：哪个源、什么错、当天已抓到多少条。有这三项，30 秒能判断要不要手动补。

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接