用n8n搭建带异常告警的资讯筛选流

把 RSS 新文章交给 AI 摘要，再发进 Slack，搭起来并不难。难的是它能否持续运行：模型输出不合规怎么办，接口限流怎么办，执行到一半失败后，文章还会不会再处理？

作者给出的 n8n 方案，把校验、重试和告警放进了主流程。它最有用的提醒是：收到失败通知，不等于失败任务已经得到补偿。对于想搭技术资讯流的开发者，这个区别比选哪个模型更值得先弄清。

什么时候值得在 RSS 后面接 AI

作者先划了一条边界：如果需求只是把每条新文章转发到 Slack，用 RSS Feed Trigger 加 Slack 两个节点就够了。原文称这种做法没有成本，但没有交代 n8n 的部署和运行成本，不能理解成整套服务免费。

需要摘要、相关性评分、实体提取，或者面向特定读者改写时，再接入 LLM。

完整链路是 RSS Feed Trigger → Basic LLM Chain（Claude）→ Code（校验 JSON）→ IF（相关性过滤）→ Slack，另建一条 Error Workflow 负责告警。

RSS Feed Trigger 每 30 分钟轮询一次。作者解释，RSS 没有 webhook，因此通过定时检查发现更新。n8n 会记住已输出的条目，提供去重；但首次激活可能一次吐出多条历史内容，建议先拿更新较少的订阅源测试。

模型部分使用 Basic LLM Chain，挂接 Anthropic Chat Model 子节点并配置凭据。原文没有指定模型版本，要求从下拉菜单选择，并核对 Anthropic 文档中的当前名称。

下面这段输入限制了每条文章送给模型的内容长度：

Title: {{ $json.title }}

Content: {{ ($json.contentSnippet || $json.content || '').slice(0, 6000) }}

要看的是 .slice(0, 6000)：它截取的是字符串长度，并非精确限制 6000 个 token。它能约束输入规模，但订阅源如果返回完整 HTML，截断后的内容仍可能夹杂大量标签。

系统消息要求只输出 JSON，字段为 summary、relevance 和 tags：摘要最多 2 句，相关性为 1-10 分，标签为字符串数组，不带 Markdown 和开场说明。IF 节点再判断 {{ $json.relevance }} 是否大于等于 6，只让通过的条目进入 Slack。

AI 是否值得花钱，取决于这道筛选能不能减少读者需要处理的信息。

能发出消息，还不算能持续运行

作者在模型节点的 Settings 中开启 Retry On Fail，设置 3 次尝试，间隔几秒，用来应对限流和临时 API 错误。但网络请求成功，模型返回的内容也可能不能用。

因此，Code 节点使用 JavaScript，并选择 Run Once for Each Item。校验逻辑先解析 JSON，再检查 summary 是否为字符串、relevance 是否为数字、tags 是否为数组；不符合就抛错，让异常进入可见的失败流程。

这里有个缺口：这段校验没有完整执行提示词约束。它没检查分数是否在 1-10 之间，也没检查标签数组里的每一项是否都是字符串，更没有验证摘要最多 2 句。原文还提到可以使用 Structured Output Parser，通过 schema 约束输出；Code 节点的优势则是能自行控制错误信息。

通过筛选后，Slack 的 Send Message 使用以下模板：

*<{{ $json.link }}|{{ $json.title }}>* ({{ $json.relevance }}/10)
{{ $json.summary }}
_{{ $json.tags.join(', ') }}_

最后一行依赖 tags.join(', ')。前面的类型校验能避免对普通字符串或空值调用数组方法，但标签内容是否合适，还需要额外约束。

告警需要另建名为「Alert on failure」的工作流，以 Error Trigger 开始，再接 Slack 或邮件节点，发送 {{ $json.workflow.name }} 和 {{ $json.execution.error.message }}。随后在主工作流的 Settings 中，将 Error Workflow 指向它。

订阅源不可用、模型输出坏 JSON、Slack 发送失败，都应变成可见的告警；限流先交给重试，尝试耗尽后再告警。首次历史条目过多，则可以在触发器后加 Limit，例如限制为 20 条，控制回填成本。

不过，作者特别提醒：条目一旦被触发器输出，即使后续节点失败，下次轮询也不会自动重新处理它。关键任务需要保存失败条目，或从 Executions 页面手动重新运行失败执行。

告警解决的是发现问题，补偿解决的是把事情做完。

我的判断

这套方案说得对的地方，是把「输出是否合法」和「失败后如何处理」当作流程的一部分。相比直接把模型回答发进群，它至少能把部分异常拦在发布之前。

但作者没有提供持续运行时长、失败率、费用或相关性筛选准确率，也没有给出不同模型、不同阈值的对照数据。所谓适合持续运行，目前更接近工程经验，不能当作可靠性实测结论。

6 分也只是一个起点。不同模型、提示词和订阅源可能给出不同的评分分布，需要拿实际文章检查误删和误放。Structured Output Parser 能帮助约束数据结构，内容是否准确、是否相关，仍需另行验证。

失败条目存进 Google Sheet 或数据库的建议有价值，但原文没有讲清保存位置、重放方式和重复发送控制。Limit 限制之外的历史条目是否还能被后续处理，也没有说明。把它用于重要资讯流之前，这些行为都要验证。

能拿来做什么

• 搭建前端或全栈技术订阅流时，先验证 RSS Feed Trigger 到 Slack 的基本转发，再按需求增加摘要和筛选，确认 AI 确实减少了阅读负担。
• 使用 Code 校验模型输出时，补齐 1-10 分范围和标签元素类型检查，并把输入截断长度纳入成本控制。
• 上线前分别测试坏 JSON、模型接口失败和 Slack 发送失败，确认重试次数、告警内容及 Executions 中的手动重跑路径。
• 如果后续让模型起草社交内容，可以按原文建议加入 Wait 和人工审批步骤，再进入发布环节。