我用 n8n 搭了结合去重、核验、写日报的情报编辑部

很多人第一次做“新闻自动化”时，脑中只有一个画面：每天搜几个关键词，把链接发到群里。

但真正跑过一段时间就会发现，难点根本不在“搜到新闻”。难点在于你会收到大量你并不想看的东西：同一篇稿子被不同网站转载、搜索结果里混进无关广告、两年前的旧新闻因为 SEO 又排到前面、标题看起来相关但正文完全不是那家公司，最后你还要手工判断哪些值得读、哪些根本不该出现。

如果自动化只是把更多链接塞进飞书，它不是帮你省时间，而是在更快地制造噪音。

所以这份 n8n 工作流没有把“搜索”当成终点，而是把它设计成一条完整的信息编辑流水线：

先由人定义什么值得关注；再让不同第三方搜索源帮我们广泛召回；接着用代码和长期记忆去重；再提取正文交给 AI 做相关性与时效审查；最后仍用规则拦住不合格内容，才把一份可以追溯来源的日报发出去。

它更像一间小型行业情报编辑部，而不是一个“会搜新闻的机器人”。

这篇文章会按工作流实际运行顺序，把每个节点都讲明白：它在做什么、为什么必须放在这里、如果不做会出什么问题，以及这种方法还能迁移到哪些领域。

先看全流程：一份日报是怎样被编辑出来的

把整个工作流放进“编辑部”的画面里，会立刻变得清楚：

固定时间开工
  ↓
主编把关注清单交给编辑部
  ↓
两组外采记者从不同搜索源收集候选消息
  ↓
收稿台合并稿件
  ↓
档案管理员删除已发过的稿件和重复链接
  ↓
文字录入员提取网页正文
  ↓
AI 事实核查编辑判断相关性、时效性并写摘要
  ↓
版面主编再次拦截无效项，按主题编排日报
  ↓
送报员把日报送到飞书

对应到 n8n 的真实节点，关系如下：

最重要的不是节点数量，而是它们的分工顺序：低成本、确定性的规则在前；昂贵、带理解能力的 AI 在后；AI 输出之后仍然有规则复核。

这正是这份工作流值得复用的地方。

第一部分：主动检索和第三方检索，为什么要分开理解？

用户经常会问：这个工作流到底是“主动搜新闻”，还是“接第三方 API 搜新闻”？

答案是：两者都有，但它们解决的是不同问题。

主动检索：人先决定“什么值得被找”

第一个 Code 节点叫 Init_Search_Params。它不是搜索引擎，它更像主编手上的选题本。

你在里面写的不是一段固定搜索词，而是一份可持续维护的关注清单。原始逻辑支持三种写法：

公司名称 : 产品关键词1, 产品关键词2
【行业主题】 : 关键词1, 关键词2
公司名称 : news, press release, update

第一种是“公司 + 产品”。例如你关心某家公司是否发布了新品、技术升级或新项目，就把公司名和产品词写在一起。

第二种是“纯行业主题”。用【】括住主题，表示你不想限定某家公司，而是想关注一个领域本身。例如某种新技术、某个细分市场或一个政策话题。

第三种是“公司 + 动态词”。当你关心的不是某个具体产品，而是公司的新闻稿、展会、业绩说明或活动更新时，可以使用这类组合。

这一步叫“主动”，不是因为 n8n 自己会主动思考，而是因为你提前告诉了它你的注意力应该放在哪里。

生活中，主编不会对记者说“去找世界上所有新闻”。主编会说：今天盯这几家公司、这几种技术和这几个话题。没有这张选题本，后面检索得越多，噪音只会越多。

第三方检索：n8n 不造搜索引擎，它负责编排搜索能力

第二层才是外部搜索能力。

这份工作流会把每一条整理好的搜索任务，同时交给两个第三方搜索来源：一条分支获取百度搜索结果，另一条分支获取 Google 搜索结果。

这里要建立一个很重要的认知：

n8n 不负责替你搭建搜索引擎。它负责把你的选题本变成任务，同时调用已有搜索能力，再把结果接回来整理。

这就像编辑部不会自己发射卫星、建通讯社。它让不同地区的记者去各自擅长的地方采集消息，最后回到同一个编辑台。

为什么不只用一个搜索来源？因为同一条信息在不同搜索源中的覆盖、排序和收录速度可能不同。一个来源擅长中文网页，另一个可能更容易发现海外官网、新闻稿或英文资料。双源并行不是为了“看起来高级”，而是为了提升召回的覆盖面。

第二部分：Schedule Trigger——不是自动化越频繁越好，而是要有明确节奏

当前工作流最左侧是一个 Schedule Trigger，实际设置为：

每周一 09:30 触发

它像编辑部的开工铃。

为什么一定要先有这个节点？因为没有固定节奏，后面的流程再完整也只是“手动工具”。你还得记得点一下执行；当你忙起来时，它就失去价值。

不过，频率不是越高越好。

如果你监控的是行业新闻或公司动态，每周一次可能足够，让你得到一份有节制的周报；如果你关心热点、舆情或高频市场信息，可以改成每天一次；如果你监控的是突发事件，还可以增加更高频的触发，但必须同时收紧筛选条件，否则飞书会变成噪音机器。

请把定时触发理解成“报纸的出刊周期”。日报、周报和即时快讯，选的是不同的节奏，而不是谁更先进。

第三部分：监控清单如何变成真正可执行的搜索任务？

Init_Search_Params 节点做了一件看似简单、实际很关键的事情：它把人写的清单，变成机器可以逐条执行的任务。

例如，假设你写：

示例公司A : product update, press release, technology
【行业主题】 : industry trend, emerging technology

它会把逗号分隔的关键词拼成 OR 检索式。

对“示例公司A”，最终搜索式会接近：

"示例公司A" (product update OR press release OR technology)

对【行业主题】，最终会接近：

(industry trend OR emerging technology)

两者差别非常大。

前者要求结果里必须围绕具体公司，因此更适合竞品、客户、供应商和目标企业监控；后者不绑定公司，适合你观察技术趋势、政策变化、行业大会和新概念。

节点还给每条任务加了两个重要参数：

为什么不是每个查询都取 100 条？

因为新闻监控不是把互联网整个下载下来。每多一条候选，就多一份网页提取成本、多一次 AI 判断机会、也多一份误判和重复的可能。先用有限结果获取高概率候选，再层层筛选，往往比无限扩张更有效。

第四部分：两路搜索 + Merge——让不同记者交稿，但不要让他们各走各的

工作流会把每条搜索任务同时送给两路 HTTP Request：

监控清单
  ├── 第三方搜索（来源 A）
  └── 第三方搜索（来源 B）

一条使用第三方服务请求百度搜索，另一条使用第三方服务请求 Google 搜索。它们各自返回的 JSON 结构并不一定相同。

这也是为什么后面不能简单地“把两份结果拼起来”。它们先汇入 Merge 节点，再交给去重节点统一处理。

Merge 在这里像收稿台：两组记者把稿件放到同一个地方，后面只需要维护一套编辑流程。

如果不合并，你就得为每个搜索源各写一套去重、正文提取、AI 审查和日报生成逻辑。将来多接一个来源，整个工作流会迅速变得难以维护。

合并之后的原则是：入口可以不同，后面的质量标准必须统一。

第五部分：为什么在 AI 之前，必须先做代码去重？

很多人会说：反正 AI 很聪明，让它判断重复不就行了吗？

不建议这样做。

AI 应该被用在“规则很难表达、需要理解语义”的地方；而链接是否已经发过、同一批里是否出现相同 URL，这些是非常确定、非常便宜的规则，应该先交给 Code 节点处理。

Filter_and_Deduplicate 节点就是编辑部的档案管理员。

它做了四件事。

1. 兼容不同搜索服务的返回格式

不同搜索服务可能把结果放在：

organic
organic_results
data

等不同字段里。

这个 Code 节点会按顺序尝试读取这些位置。你可以把它理解为档案管理员知道不同记者的稿件格式：有人用蓝色文件夹、有人用红色文件夹、有人直接拿散页纸来，但他都知道从哪里找到“候选新闻列表”。

这一步的重要性在于：你未来切换搜索服务、增加来源时，不必把整条工作流推倒重来。只需要在这里补充一种识别方式。

2. 找回“这条新闻原本属于谁”

搜索服务返回结果后，原来的 company_name 有时会被包在别的结构里，甚至丢失。

节点会优先读取保留下来的公司名；如果没有，就从搜索表达式中反向提取被双引号包住的对象名称；再不行才归到“行业全局动态”。

为什么一定要保留这个字段？因为日报不是“混在一起的一堆新闻”。它需要按你关心的对象分组：某家公司有什么更新、某个行业主题出现什么变化。

没有归属，后面的报告就失去了阅读结构。

3. 历史去重：不把昨天的新闻再推一次

节点调用了 n8n 的工作流全局静态数据：

const staticData = $getWorkflowStaticData('global');

你可以把它理解为编辑部的“已发稿档案柜”。里面维护一个 pushedUrls 列表，记录已经推送过的链接。

如果某条链接已经在档案柜里，今天即使搜索源又把它排到前面，档案管理员也会把它抽掉，不再交给后面的 AI。

这一步解决的是新闻监控中最烦人的问题：同一篇文章隔三差五重新出现，或者同一新闻被多家搜索结果反复召回。

4. 当次去重：同一次运行里也不允许重复

除了长期档案柜，节点还维护了一个 currentRunUrls 临时列表。

它像今天桌面上的“正在处理”文件堆。即使某链接还没有进入历史档案，只要今天的来源 A 和来源 B 都找到了它，第二次出现时也不会再进入后续流程。

这叫双重去重：

节点还把长期记忆限制在最近 800 条。为什么要限制？档案柜有价值，但不能无限塞旧报纸。保留最近一段时间的链接，既足以防重复，也不会让工作流长期负担不断增长。

第六部分：提取网页正文——不要让 AI 在广告、导航栏和页脚里找新闻

去重后的候选链接，会进入 Extract_Markdown_Content 节点。

它通过一个正文提取服务，把原网页转换为更干净的 Markdown 内容。

生活里，这就像把一篇网页新闻交给文字录入员：录入员把顶部导航、弹窗、推荐位、广告栏和页脚尽量剥掉，只留下文章真正的标题、正文和核心段落。

为什么不能直接把搜索结果里的标题和摘要交给 AI？

因为搜索摘要太短，容易断章取义；而网页原始 HTML 太杂，AI 容易被无关菜单、广告和重复文字干扰。先提取正文，才能让 AI 对“这篇文章到底在说什么”作更可靠的判断。

这个节点还设置了：

onError: continueRegularOutput

人话就是：如果某一个网页打不开、提取失败或格式特殊，不要让整份日报一起停摆，继续处理其他候选项。

这很像报社当天有一位记者联系不上，不代表整张报纸都不能出版。容错不是锦上添花，而是自动化能长期运行的基础。

第七部分：AI 不是第一道筛子，而是事实核查编辑

网页正文提取完成后，才轮到 AI_Summarize_and_Translate 节点和 DeepSeek Chat Model。

请注意：AI 在这个工作流里不负责“海量搜索”，也不负责“第一眼看到什么就全部发送”。它承担的是更适合 AI 的工作：读正文、理解语义、判断相关性、寻找事件时间，并把有效内容压缩成短摘要。

AI 提示词要求它做四项核验。

1. 身份与相关性核验

如果目标是具体公司，正文必须真正提到这家公司。

这能挡住一个很常见的误匹配：搜索标题里碰巧包含关键词，但正文是在讲完全不同的产品、体育用品、电商页面或无关广告。

如果目标是宽泛行业主题，正文则必须和该主题高度相关，而不是只出现一次模糊词汇。

生活里，这像事实核查编辑收到一篇稿子后，先核对它有没有写错采访对象。主编要的是 A 公司动态，不能因为标题里恰好出现 A 的名字，就把一篇讲 B 的文章发出去。

2. 时效性核验：近 7 天内才值得进入日报

搜索结果里的“新”不一定是真的新。旧新闻常常因为被转载、更新页面、SEO 排名变化而重新出现。

因此提示词明确要求 AI 在正文中寻找实际发生时间或发布日期；如果事件距离当前日期超过 7 天，就只输出：

[无效信息]

为什么用 7 天？这是一个可调整的业务窗口。对周报来说，一周是自然的观察周期；对日更热点可以改成 1–2 天；对低频产业趋势可以放宽到 30 天。

关键不是“7 天永远正确”，而是你必须为新闻设定一个明确的新鲜度标准。

3. 有效项只写 100–150 字摘要

这条限制看起来很小，其实很有用。

没有字数上限的 AI 容易把一篇新闻复述成长文章；字数太短又无法说明发生了什么。100–150 字大致足够覆盖：谁发生了什么、有什么商业或技术意义、为什么值得关注。

它像编辑给晨报写的“信息卡片”：让读者在几十秒内判断要不要点进原文，而不是替读者读完全部网页。

4. 纯文本输出，不要 Markdown 装饰

提示词要求 AI 不要用星号、井号等 Markdown 符号。

原因不是 Markdown 不好，而是最终版面主编会统一排版。每个编辑自己加粗、分标题、堆符号，最后汇总时格式很容易乱。让 AI 先交一段干净纯文本，后面的 Code 节点再统一决定日报长什么样，结构会更稳定。

批处理、间隔和重试，为什么需要这些“慢一点”的设置？

AI 节点当前设置为：每批 5 条、批次间等待 10 秒、失败最多重试 5 次、每次间隔 5 秒。

这不是让工作流变慢，而是在控制真实世界的不稳定性。

• 每批 5 条：避免一次丢太多网页给模型或 API，降低超时和限流风险。
• 间隔 10 秒：给外部模型服务留出缓冲，减少频繁请求导致的失败。
• 最多 5 次重试：网络偶发错误时不必人工重跑整条流程。
• 每次间隔 5 秒：不是立即反复撞同一扇门，而是等服务恢复一点再尝试。

生活里，编辑部不会让 100 位记者同时挤进同一部电梯；分批上楼，整体反而更稳定。

第八部分：为什么 AI 筛过以后，还要再用 Code 做一次“物理拦截”？

这是这份工作流非常值得学习的一点。

很多自动化做完 AI 摘要，就直接发送了。但这里还有一个 Aggregate_Daily_Report 节点。它不是简单拼接文字，而是最终版面主编。

它仍然会执行三道硬规则：

1. 没有溯源链接的内容直接丢弃。
2. URL 路径中明显带有旧年份的内容直接丢弃。
3. AI 输出包含“无效”“无关”，或摘要少于 20 字的内容直接丢弃。

这就是“AI 判断 + 规则兜底”的组合。

AI 擅长理解一篇文章是否真的相关、时间描述是否可信；代码擅长执行零歧义的条件，例如“链接为空就不许进来”“摘要不到 20 字就不许上版”。

把两者混在一起，反而容易失控。最稳妥的设计是：

用规则处理确定性问题；用 AI 处理理解性问题；再用规则把 AI 输出关进明确的质量边界。

为什么日报必须保留溯源链接？

最终日报会为每条新闻保留原标题、发布时间、AI 简讯和原始链接。

这是对 AI 摘要最基本的尊重方式：摘要可以帮你节省时间，但不能替代原文。真正重要的新闻，你应该能一键回到来源核验上下文。

一份没有链接的 AI 简报，像同事只告诉你“听说发生了一件事”，却不告诉你消息来自哪里。它或许有启发，但很难用于真实判断。

第九部分：最后生成日报，再由飞书送出去

通过最终筛选的内容，会按 company_name 或行业主题分组，生成一份结构化日报：

多源行业情报监控简报
生成日期
今日捕获高价值动态数量

【某个监控对象】最新动态
1. 原文标题
发布时间
简讯内容
溯源链接

这里的“按对象分组”很重要。

如果把所有信息按搜索返回顺序堆在一起，你看到的是一堆链接；按公司、产品或主题分组后，你看到的是“今天这个对象有什么值得关注的更新”。日报从搜索记录变成真正的情报产品，就发生在这一步。

最后，飞书 Webhook 节点把 daily_report 发送出去。

导入脱敏后的工作流时，飞书节点会要求你重新绑定自己的凭据。这是正常的：Webhook 凭据、第三方搜索 API Key 和 AI 模型凭据都像编辑部的门禁卡，必须由每个使用者自己保管，不能跟工作流逻辑一起公开。

新手复刻时，建议按这个顺序测试，不要导入后直接启用

第一步：先改“选题本”，不要先改后面的节点

在“监控清单与检索参数”节点里，替换通用示例为你真正关心的对象。

刚开始不要写几十家公司。先用 2–3 个对象测试，确认每个关键词能召回相关结果，再逐步扩充。自动化最怕一开始把范围开太大，最后不知道是哪条规则出了问题。

第二步：填写自己的两组搜索 API 凭据

脱敏工作流保留了来源 A 和来源 B 的节点结构，但 API Key 已替换为占位值。请在各自节点中填写你自己的密钥或绑定自己的凭据。

测试时，先单独执行每个搜索节点，确认确实返回了候选结果。

第三步：手动运行到“历史去重与候选清洗”

重点看它的输出是否还保留：

company_name
title
link
snippet
date

如果 company_name 丢了，后面的日报分组会混乱；如果 link 为空，正文提取和溯源都会失败。

第四步：检查网页正文提取效果

不是所有网站都能被同一种方式完美提取。先随机打开几篇候选项，确认“提取网页正文”输出的确实是文章正文，而不是登录页、验证码页或空内容。

第五步：先看 AI 输出，再接日报

先手动测试 AI 节点。你要看到两种合理结果：

• 无关、过期或广告内容明确输出 [无效信息]；
• 有效内容输出一段 100–150 字左右的纯文本摘要。

如果 AI 总把旧新闻当新新闻，不要急着换模型。先检查原文中是否真的有日期、提示词中的时间窗口是否符合你的场景，以及搜索范围是否过宽。

第六步：最后绑定飞书并启用定时任务

当你确认日报结构、链接和摘要都符合预期后，再绑定飞书并启用。

自动化不是“导入后就永远不用管”。第一次测试越耐心，后面越省心。

这个工作流还能用在哪些方面？它可复制的不是新闻，而是“信息编辑流程”

这套工作流真正可以迁移的，是下面这条能力链：

定义关注范围 → 多源召回 → 去重 → 提取正文 → 相关性与时效审查 → 最终规则拦截 → 带来源的结构化分发。

只要你的问题属于“固定时间内，从分散网页中找到少量真正值得看的信息”，它都可以成为基础模板。

1. 竞品、供应链和客户监控

将选题本改成竞品名称、供应商名称、核心产品和关键地区。

你可以持续追踪新品发布、合作公告、融资、产能扩张、展会活动、招标信息和管理层更新。AI 不应该替你做战略判断，但可以先把真正值得你判断的材料挑出来。

2. 政策法规、招投标与项目机会跟踪

把行业主题改为法规关键词、地方政策、采购平台、招投标项目或资质要求。

这里特别适合保留“时效核验”和“溯源链接”，因为政策与招标对发布时间、来源和原文措辞非常敏感。自动化负责提醒你，最终判断仍应回到正式文件。

3. 个人研究课题与学习主题晨报

你可以不监控公司，而是监控一个问题。

例如 Docker 自托管、n8n 插件、NAS、Obsidian、某类 AI 工具、开源模型或某门技术的最新实践。每天或每周收到一份过滤过的主题简报，比在多个平台反复刷新更容易形成长期学习节奏。

4. 每日热点与内容选题雷达

内容创作者最容易陷入“刷到什么写什么”。更好的方式是先定义自己的内容边界，例如只看效率工具、数码、自动化、某个行业或某类用户问题。

工作流先帮你把候选话题收集起来，AI 帮你判断是否新鲜、是否相关，日报里保留来源链接。你得到的不是“今天什么最热”，而是“今天什么最值得纳入我的内容选题池”。

5. 学术论文、开源项目和技术更新

如果你的信息源是论文数据库、GitHub Releases、项目博客、官方文档更新页或 RSS，整体流程依然成立。

只是“第三方搜索”可以替换成 RSS、GitHub API 或特定站点 API；而“AI 审查”可以改成判断是否与研究方向相关、是否包含实际可复现的技术更新。

最后：真正成熟的信息自动化，不是让你看更多，而是帮你更少地被打扰

一套新闻工作流的质量，不应该用“今天抓了多少篇”来判断。

更好的问题是：

• 它有没有把重复链接挡在门外？
• 它有没有把旧闻和广告挡在门外？
• 它有没有告诉你这条摘要来自哪里？
• 它有没有把信息按你真正关心的对象整理好？
• 它有没有让你少花时间找信息，多花时间判断信息？

这份 n8n 工作流的价值，就在于它没有把 AI 当成万能答案，也没有把搜索结果原样倾倒给你。

它让人负责定义注意力，让第三方搜索负责广泛发现，让代码负责确定性的清洗和去重，让 AI 负责语义理解和摘要，再让最终规则负责守住质量底线。

当你下一次又在多个网站、搜索页和群聊之间来回切换时，不妨问自己一句：

我真正缺的是更多新闻，还是一间能替我做好信息编辑的自动化小型编辑部？