# n8n 劝退我三次，直到我搭出了这个 AI 新闻简报

> 作者/来源: admin
> 发布时间: 2026-08-13T10:15:11.833Z
> 分类: AI专区
> 标签: DeepSeek, n8n, AI新闻简报, 工作流自动化, RSS
> 原文链接: http://117.50.162.249:3000/yun/articles/2694

---

## 一条真正有用的 n8n 工作流，不在于连接了多少节点，而在于能不能把一个高频、重复、耗时的小问题变成稳定输出。

如果业务里经常需要跟踪行业新闻、竞品动态或公开信息源，可以用 n8n 把 RSS 读取、网页抓取、AI 摘要和邮件发送串起来。以虎嗅 RSS、Firecrawl、DeepSeek 和 Send Email 为例，这条链路可以完成：定时发现新闻，抓取网页内容，生成结构化摘要，最后自动发送到邮箱。

判断这类方案值不值得做，别一上来就问“能不能搭一个复杂自动化系统”。更现实的起点是：能不能先让 2 篇新闻稳定进入收件箱。能做到这一点，再谈扩展，才不容易把自动化做成另一种手工活。

## 一、问题背景：为什么会想到用 n8n 做 AI 新闻简报

很多团队的信息处理工作，看起来都不重：看看行业媒体，追踪竞品动态，整理几条新闻摘要，再发给自己或团队成员。单次操作确实不难，但只要每天重复，它就会变成一枚小齿轮，稳定地咬走时间。

n8n 的价值就在这个缝隙里。它是一款工作流自动化工具，可以通过节点把触发器、数据源、AI 模型和外部服务连接起来，让重复任务按预设流程自动运行。

不过，真到动手阶段，也别把 n8n 想得过于“零门槛”。它的画布很直观，但部署、节点配置、API Key、第三方服务授权和报错排查，都会抬高第一次上手的成本。对刚开始验证的人来说，先用 ucloud（优刻得）开发者中心里的 n8n 沙箱，会更轻一点。浏览器打开后，画布已经准备好，右上角会显示倒计时，这个临时环境大约只保留 1 小时。

这次要搭的不是一个复杂系统，而是一个能跑通闭环的 AI 新闻编辑部：读取虎嗅 RSS，抓取文章信息，交给 DeepSeek 生成简报，再自动发到邮箱。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894883-6404528ecfae1abe4e8df5b148d3cb4b.jpg)

下面是刚进入 n8n 时的空白工作流，右上角可以看到沙箱倒计时。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894810-f5e4b0ed9f94f059a368364a707d82e7.jpg)

## 二、核心痛点：这类自动化最容易卡在哪里

搭 AI 新闻简报，最容易误判的一点是：以为难点在某个“高级节点”。实际更常见的问题，是整条链路不够稳。一个节点跑通不算什么，节点之间能持续交接，才算真正可用。

第一，信息入口要稳定。RSS 通常能提供标题、链接、发布时间和摘要，但不一定提供完整正文，所以只靠 RSS 很难让 AI 生成质量稳定的摘要。

第二，网页内容要能被读取。RSS 后面需要接网页抓取节点，把链接中的页面内容转成 AI 可以处理的输入。

第三，模型输出要可控。AI 摘要不能只追求“看起来像总结”，还要固定格式，并明确要求不要编造输入中没有的事实。

第四，调试成本要可控。工作流越长，最后一个节点报错时越难判断问题来自 RSS、网页抓取、模型调用还是邮件发送。

第五，凭证安全要放在前面。Firecrawl、DeepSeek 和 SMTP 都涉及敏感凭证，不能写进提示词、表达式、截图或临时笔记。

## 三、不同方案怎么选

如果只是偶尔看几篇文章，手动打开网页、复制内容给 AI 总结，成本最低，也最灵活。它像临时搭一座小桥，够用，但不适合每天反复走。

如果自己写脚本，灵活性更高，也更容易做深度定制。但脚本需要处理定时任务、抓取、API 调用、异常重试、邮件发送和凭证管理，对非工程团队不够友好。

如果用 n8n 这类工作流工具，优势是链路可视化，节点输入输出容易检查，适合快速验证。代价也要提前看清：仍然需要理解每个节点的数据结构、第三方服务限制和凭证配置方式。

这条 AI 新闻简报的完整链路是：

| 环节 | 节点或服务 | 作用 | 调试重点 |
| --- | --- | --- | --- |
| 触发 | Manual Trigger / Schedule Trigger | 手动测试或定时运行 | 先手动，跑通后再定时 |
| 信息入口 | RSS Read | 读取虎嗅 RSS 标题、链接、发布时间和摘要 | 确认 RSS 字段是否完整 |
| 数量控制 | Limit | 限制测试文章数量 | 调试阶段建议设为 2 |
| 网页读取 | Firecrawl | 抓取文章页面内容 | 检查社区节点来源和 API Key |
| 摘要生成 | AI Agent + DeepSeek | 输出标题、三句话摘要、判断和链接 | 固定格式，禁止编造 |
| 汇总排版 | Aggregate + Markdown | 合并多条摘要并转成 HTML | 避免多封零散邮件 |
| 分发 | Send Email | 通过 SMTP 发送邮件 | 使用授权码，不使用登录密码 |

我的建议是：第一次验证，不要直接奔着企业级知识中台或复杂情报系统去。先从“每天自动发一封新闻简报”这种边界清晰的小任务开始，投入产出比更容易看出来。

## 四、为什么选择优刻得 n8n 沙箱做第一轮验证

优刻得n8n 沙箱适合快速体验。它的主要价值，不是让你长期运行一套正式系统，而是把第一次上手时最麻烦的部署环节先挪开。打开沙箱后可以直接创建 Workflow，在有限时间里判断 n8n 是否适合自己的业务场景。

体验入口：优刻得开发者中心

但边界也要说清楚：沙箱环境大约只存在 1 小时。如果要保留配置，应在倒计时结束前导出工作流。不要把临时沙箱当作正式生产环境，也不要在里面保存长期有效、权限过大的密钥。

第一轮验证的目标不用贪多：确认 RSS、Firecrawl、DeepSeek、Markdown 和 Send Email 能否跑通闭环。只要新闻能稳定进入收件箱，关键验证就已经完成。

## 五、实际搭建步骤

### 1. 先用 Manual Trigger 调试

进入优刻得开发者中心，打开内置的 n8n 沙箱，新建一个 Workflow。

调试阶段先使用 Manual Trigger。每改完一个节点，就手动执行一次，检查输入和输出是否符合预期。等整条链路跑通后，再把触发器换成 Schedule Trigger。

这一步看起来慢，其实是在给后面省时间。链路一长，如果只盯着最后一个节点的报错，很难判断问题到底出在哪一段。

### 2. 用 RSS Read 获取虎嗅新闻列表

添加 RSS Read 节点，把地址填成：

```text
https://rss.huxiu.com/
```

RSS 适合作为信息入口。它通常提供标题、链接、发布时间和摘要，但不一定提供完整正文。因此，RSS 后面还需要接一个网页抓取节点，把链接中的页面内容取出来。

调试时不要一次处理几十篇文章。先接一个 Limit 节点，把数量设为 2。两篇文章足够验证流程，也能减少抓取额度和模型 Token 消耗。正式运行时，再根据预算和阅读习惯调到 5 篇或更多。

### 3. 用 Firecrawl 读取网页内容

RSS 节点会把每篇文章的链接传给 Firecrawl。Firecrawl 节点选择 `Scrape A URL And Get Its Content`，URL 设置为：

```text
{{ $json.link }}
```

Firecrawl 在这里承担网页内容抓取的角色。它把 RSS 中的链接转成后续 AI 节点可以处理的网页内容。由于 Firecrawl 属于社区节点，安装前要确认发布者和包来源可信。

API Key 应放进 n8n Credential，而不是写进节点表达式、提示词或截图。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894759-cfa774d619134b89c08e3ab07c8b598b.jpg)

API Key 可以在 Firecrawl 控制台创建。复制到 n8n Credential 后，应立即清理剪贴板和临时笔记，并避免让密钥出现在截图里。

凭证测试成功后，Firecrawl 就能接收上一节点传来的文章链接。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894739-60173cc70c1e6603b57fc6a03fbafeb9.jpg)

### 4. 把网页内容交给 DeepSeek 生成摘要

接下来添加 AI Agent，并为它连接 DeepSeek Chat Model。DeepSeek 的 API Key 同样应放入 n8n Credential，不要直接写在提示词或表达式里。

提示词不必写得很花，关键是给模型划清边界：输出格式要固定，输入里没有的事实不要补。

```text
你是一名新闻编辑。请根据输入内容，输出新闻标题、三句话摘要、一个值得关注的判断和原文链接。不要编造输入中没有的事实。
```

模板默认把 `og:description` 传给 AI。这种方式速度快、Token 消耗少，适合做轻量简报。如果希望模型阅读完整正文，可以改用 Firecrawl 返回的 `data.markdown`，但调用成本和处理时间都会上升。

调试 AI 节点时，可以先固定上一节点的测试数据。这样每次修改提示词时，不需要重新抓网页，也能避免重复计费。

模型凭证配置完成后，把 DeepSeek Chat Model 接到 AI Agent 的语言模型入口。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894724-0a10b578daa7679361968f5adb9ad9ab.jpg)

到这一步，每篇文章已经能稳定产出一段结构一致的摘要。再往后，就不是“能不能总结”的问题，而是能不能把多条结果整理成一封适合阅读的邮件。

### 5. 用 Aggregate 和 Markdown 合并简报

AI Agent 会逐篇输出结果。Aggregate 节点负责把这些结果收进同一个数组，Markdown 节点再把数组中的多段摘要用空行连接起来，并转换成 HTML。

这一步很容易被低估，但它直接决定邮件可读性。没有 Aggregate，可能会收到多封零散邮件；没有 Markdown 转 HTML，邮箱里看到的可能是一堆层级不清的纯文本。

### 6. 用 Send Email 发送到邮箱

最后接上 Send Email 节点。按照邮箱服务商要求填写 SMTP 地址、端口、账号和授权码，再把 Markdown 节点输出的 HTML 放进邮件正文。

SMTP 授权码是这里最容易被忽略的安全点。很多邮箱要求使用单独生成的 SMTP 授权码，而不是邮箱登录密码。授权码同样属于敏感凭证，不要截图、不要写进工作流字段，也不要发给别人。

先把收件人填成自己的测试邮箱。确认排版、链接和发送频率都没有问题后，再考虑发给更多人。

下图是 Send Email 节点的配置位置。涉及账号的字段，对外发布前应打码。

https://u.163.com/AgiSwWrVD?uid=lajikexing3@163.com&session_id=_6f37a007058dde534313e5846156078e (二维码自动识别)

## 六、怎么验证这条链路真的跑通了

简报出现在收件箱里，才算真正完成闭环。RSS、网页抓取、模型调用和格式转换，不再是几个孤立可运行的节点，而是合成了一条可以被直接消费的信息流。

下面是最终收到的新闻简报效果。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894709-8b276eda29d637131e52aee8862af818.jpg)

整条链路确认无误后，再把开头换成 Schedule Trigger。模板默认每 4 小时执行一次，可以根据阅读习惯、抓取额度和模型预算调整。

激活之前，至少检查三件事：Limit 是否合理，收件人是不是自己的测试邮箱，Firecrawl 和 DeepSeek 账户是否还有足够额度。

工作流全部连通后，大致如下图所示。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894696-d580dcc82308bcfeaa0b257ab1175276.jpg)

如果只在 ucloud（优刻得）临时沙箱里体验，应在倒计时结束前导出工作流。沙箱被销毁后，画布里的配置可能无法继续访问。

## 七、直接导入模板时要检查什么

模板获取可以留言

这条工作流也可以通过 JSON 模板导入。下载后，在 n8n 里选择 `Import from File`，即可恢复节点和连线。

但导入只是把骨架搭好，不代表能直接跑起来。凭证、邮箱和运行频率，仍然要一个个检查。自动化的门，不能只看门框，钥匙也得配对。

导入后，按顺序完成下面几件事：

1. 确认 Firecrawl 社区节点来自可信来源，再安装缺失节点。
2. 重新创建 Firecrawl、DeepSeek 和 SMTP 凭证。
3. 把模板里的示例发件人和收件人改成自己的邮箱。
4. 把 Limit 调到适合测试的数量，并检查每 4 小时一次的默认频率。
5. 从左到右逐个执行节点，确认输出无误后再激活工作流。

下图是 n8n 的工作流导入入口。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998213383894681-d19b0471737ecedf8cb72e1e45e896dc.jpg)

这个 JSON 中没有 API Key、Token 或私钥。不过它带有示例邮箱地址，导入后仍要先改收发件人，再进行测试。

## 八、适合和不适合的场景

这条工作流适合轻量新闻简报、行业动态监控、竞品信息追踪和内部资料摘要。它最适合处理结构相对稳定、来源清晰、频率可控的信息流。

它不适合直接处理需要高精度事实核验、强合规审查或大量实时数据的场景。AI 摘要可能遗漏细节，也可能误解上下文，因此重要结论仍应回到原始链接复核。

凭证安全是底线。Firecrawl、DeepSeek 和 SMTP 的密钥都应使用 n8n Credential 管理，并按最小权限原则配置。临时沙箱中不要保存长期有效的高权限密钥。

## FAQ

### n8n 是什么？

n8n 是一款工作流自动化工具。它通过节点把触发器、数据源、AI 模型和外部服务连接起来，让重复任务按预设流程自动运行。

### 为什么先用 Manual Trigger，而不是一开始就定时运行？

Manual Trigger 更适合调试。每个节点改完后可以立即手动执行，快速确认输入和输出。等 RSS、Firecrawl、DeepSeek、Markdown 和 Send Email 都跑通后，再改成 Schedule Trigger 更稳妥。

### RSS 已经有摘要，为什么还要接 Firecrawl？

RSS 通常只提供标题、链接、发布时间和摘要，不一定包含完整正文。Firecrawl 可以根据 RSS 链接抓取网页内容，让 AI 摘要有更多上下文。

### 调试时为什么把 Limit 设为 2？

2 篇文章足够验证整条链路，也能减少网页抓取额度和模型 Token 消耗。正式运行时，可以根据预算和阅读频率调整到 5 篇或更多。

### DeepSeek 的提示词应该怎么写？

提示词应优先固定输出格式，并明确要求不要编造输入中没有的事实。轻量简报可以使用 `og:description`，需要更完整上下文时再改用 Firecrawl 返回的 `data.markdown`。

### 导入模板后能直接运行吗？

不能直接运行。模板只包含节点和连线，不包含可用凭证。导入后必须重新创建 Firecrawl、DeepSeek 和 SMTP 凭证，并修改示例收发件人。

## 总结建议

有用的自动化，往往不是从宏大的系统蓝图开始，而是从一个每天都要重复处理的小麻烦开始。新闻很多时，真正缺的不是更多链接，而是一份已经整理好、几分钟内能读完的简报。

RSS 负责发现，Firecrawl 负责读取，DeepSeek 负责整理，邮箱负责分发。每个节点单独看都不复杂，但连起来之后，就能把反复打开网页、复制内容、整理格式的过程，变成一条稳定流程。

第一次搭 n8n 工作流，最该想清楚的不是“还能再加几个节点”，而是上一环节要把什么准确交给下一环节。先让两条新闻成功进入邮箱，这条传送带就已经开始工作了。

先稳住。再扩展。