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

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

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

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

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

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

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

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

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

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

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

搭 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 节点，把地址填成：

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 节点的配置位置。涉及账号的字段，对外发布前应打码。

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

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

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

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

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

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

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

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

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

模板获取可以留言

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

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

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

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

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

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

先稳住。再扩展。