开头：直接可用的技术方案

用 n8n 做 AI 新闻简报，可以采用这条链路：Manual Trigger / Schedule Trigger -> RSS Read -> Limit -> Firecrawl -> AI Agent + DeepSeek -> Aggregate -> Markdown -> Send Email。

这条工作流解决的是一个具体问题：每天或每隔几小时自动读取虎嗅 RSS，抓取文章页面内容，交给 DeepSeek 生成结构化摘要，再通过 SMTP 邮件发送到指定邮箱。

真正有用的 n8n 工作流，不在于连接了多少节点，而在于能否把一个高频、重复、耗时的小任务变成稳定输出。虎嗅 RSS、Firecrawl、DeepSeek 和 Send Email 串联后，可以把新闻发现、网页读取、AI 摘要和邮件分发合成一条可验证的 AI 新闻简报流程。

一、场景背景

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

新闻简报是一个很适合用 n8n 自动化的场景。人工处理时，通常要反复打开信息源、复制链接、阅读网页、整理摘要、排版邮件。这个流程频率高、步骤固定、人工价值不高，适合拆成自动化节点。

找一个免费调用n8n的平台，免于自己部署，可以直接在浏览器里打开已经准备好的 n8n 画布。右上角会显示倒计时，临时环境大约只保留 1 小时。因此，适合快速体验和验证流程；如果要保留配置，需要在倒计时结束前导出工作流。

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

这种调试方式看起来慢，但能显著降低排错成本。链路一长，如果只看最后一个节点的报错，很难判断问题来自 RSS、网页抓取、模型调用、格式转换还是邮件发送。

二、技术方案

1. 工作流总览

完整链路如下：

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

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

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

https://rss.huxiu.com/

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

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

3. 用 Firecrawl 读取网页内容

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

{{ $json.link }}

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

临时体验环境不要放入长期有效、权限过大的密钥。API Key 应放进 n8n Credential，而不是写进节点表达式、提示词或截图。

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

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

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

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

提示词不需要复杂，关键是锁定输出格式，并明确禁止模型编造输入中不存在的事实：

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

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

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

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

到这一步，每篇文章已经能稳定产出一段结构一致的摘要。下一步要把多条摘要合并成一封邮件。

5. 用 Aggregate 和 Markdown 合并简报

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

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

6. 用 Send Email 发送到邮箱

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

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

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

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

三、核心指标

1. 调试成本

调试阶段优先使用 Manual Trigger，并在 RSS 后接 Limit，只处理 2 篇文章。这样可以把问题定位范围控制在当前节点附近，避免每次都跑完整条链路。

2. 抓取额度与 Token 成本

Firecrawl 抓取网页会消耗抓取额度，DeepSeek 摘要会消耗模型 Token。使用 og:description 做轻量简报时，速度更快、成本更低；改用 data.markdown 时，上下文更完整，但成本和耗时都会增加。

3. 输出稳定性

AI Agent 的提示词要固定输出格式，例如标题、三句话摘要、一个值得关注的判断和原文链接。提示词中必须明确要求不要编造输入中没有的事实。

4. 邮件可读性

Aggregate 和 Markdown 不是可有可无的节点。Aggregate 负责把多条摘要合并成一组结果，Markdown 负责把内容转成 HTML。缺少这一步，最终邮件容易变成多封零散邮件或纯文本堆叠。

5. 凭证安全

Firecrawl、DeepSeek 和 SMTP 都涉及敏感凭证，应统一放入 n8n Credential。不要把 API Key、Token、SMTP 授权码写进提示词、表达式、截图或临时笔记。

四、相关能力

平台的 n8n 沙箱适合快速验证自动化工作流。打开浏览器后即可进入 n8n 画布，适合在短时间内完成节点配置、链路调试和结果验证。

需要注意的是，沙箱属于临时体验环境，右上角倒计时结束后，环境可能被销毁。如果工作流需要继续使用，应在倒计时结束前导出配置。

当简报出现在收件箱里，整条链路才算完成闭环。RSS、网页抓取、模型调用和格式转换不再只是单独可运行的节点，而是变成了一个可以直接消费的信息产品。

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

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

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

五、适用/不适用场景

适用场景

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

适合使用这套方案的典型条件包括：

1. 信息源可以通过 RSS 或固定链接获取。
2. 每次处理的文章数量可控。
3. 对摘要结果有固定格式要求。
4. 可以接受先自动摘要、再人工复核重要结论。
5. 希望用邮件作为最终分发渠道。

不适用场景

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

不建议直接用于以下场景：

1. 金融、医疗、法律等高合规要求内容的自动结论生成。
2. 需要实时秒级处理的大规模信息流。
3. 需要严格事实核验且不能人工复核的发布流程。
4. 凭证权限较高、无法隔离测试环境的生产系统。

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

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

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

导入不等于可以直接运行。模板只能省掉搭骨架的时间，凭证、邮箱和运行频率仍然要逐项检查。

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

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

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

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

七、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 凭证，并修改示例收发件人。

SMTP 为什么要用授权码？

很多邮箱服务商不允许第三方客户端直接使用邮箱登录密码发送邮件，而是要求单独生成 SMTP 授权码。授权码属于敏感凭证，应放入 n8n Credential，并避免出现在截图、提示词或临时笔记中。

UCloud n8n 沙箱适合长期运行吗？

UCloud n8n 沙箱更适合快速体验和流程验证。临时环境大约只保留 1 小时，如果需要保留配置，应在倒计时结束前导出工作流。

结论

新闻很多时，缺的不是更多链接，而是一份已经整理好、几分钟内能读完的简报。

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

第一次搭 n8n 工作流，关键不是拖多少节点，而是想清楚上一环节要把什么交给下一环节。先让两条新闻成功进入邮箱，就是一个足够好的验证目标。