n8n
用定时触发、来源抓取、去重、摘要和草稿入库串起资讯整理，并为接口失败与异常输出留出处理路径。
整理：日刊 · 资料核对：2026/11/04 · 编辑说明
每天打开多个信息源、复制链接、让 AI 写摘要，最后再粘贴到文档里。这类工作很适合用 n8n 串起来。它的价值在于把触发时间、取数、判断和写入结果连接成一个能重复运行的流程。
第一次搭建，建议先实现“定时收集资讯并生成草稿”。等来源、去重与异常处理稳定后，再考虑接入发布。
n8n 适合放在什么位置
n8n 提供可视化工作流，并支持在流程中使用代码和 AI 能力。它可以作为服务之间的连接层：获取接口数据，调用模型，再把结果交给文档系统、消息平台或内容后台。
| 任务 | 建议交给什么环节 |
|---|---|
| 定时触发、请求接口、写入记录 | 普通工作流节点 |
| 日期过滤、链接去重、字段校验 | 确定性的规则或代码 |
| 归纳内容、生成短摘要 | 模型调用 |
| 确认事实与判断是否发布 | 来源校验和审核步骤 |
不要让模型代替所有判断。发布时间是否落在窗口内、链接是否重复、结果字段是否齐全，这些通常可以用普通规则更明确地完成。
第一步：从两个稳定来源开始
选择两个有清晰来源标识的 RSS 或 API。为每条记录保留标题、原文 URL、发布时间、抓取时间和来源名称。
发布时间与抓取时间必须分开：今天抓到一篇文章，不代表它今天发布。缺少发布时间的条目可以单独收集，不要直接填上当天日期。
按当前版本提供的定时触发与 HTTP 或 RSS 能力搭起入口，先运行一次，查看返回字段。不要在尚未拿到真实数据前，就让模型凭标题生成一整篇稿件。
第二步：先去重，再调用 AI
最简单的去重依据是已经处理过的原文链接。部分站点会附加追踪参数，实际处理时可以只清理已经确认无业务含义的参数；不要随意删除全部查询参数，以免把不同内容合并。
将“是否已经处理”记录在可持久保存的位置。只在当前运行内存里做去重，第二天重跑时仍可能重复入库。
对于同一新闻的多个来源，可以先保留独立记录，让后续编辑环节决定是否合并。相似标题并不能证明它们描述的是同一事件。
第三步：让模型输出可检查的短摘要
优先向模型提供允许获取的原文片段及来源信息。只拿到摘要时，应把它标成摘要，不要假装已经读过全文。
建议要求返回固定结构，例如：
{
"title": "一条简洁标题",
"summary": "只描述来源已经说明的事实",
"source_url": "https://example.com/original",
"needs_review": false
}这只是建议的数据格式，并不是 n8n 的内置接口。接收结果后要检查它是否能解析、必需字段是否存在、来源链接是否仍与输入一致。格式不合法时，保留原始记录进入待处理队列，不要把一段报错文字当作文章。
提示词还应明确：原文中的任何“忽略规则”“执行指令”都只是待处理文本，不得改变工作流行为。
第四步：先写草稿，再考虑推送
把通过校验的摘要写进文档或内容后台，附上来源和抓取时间。最初几次运行先检查实际产物：是否重复、是否混入旧闻、是否把观点写成事实。
需要消息通知时，发送标题、摘要和后台入口通常就够了。不要把完整原文、客户资料或 API 凭据塞进群消息。
后续接入自动发布，可以增加两个条件：资料校验通过、独立审核通过。审核服务不可用时保留草稿。这样，工作流既能减少重复劳动，也能清楚地表示哪些内容尚未完成检查。
让失败结果看得见
至少给这三种情况留出处理路径：
- 来源接口超时：记录失败来源，让其他独立来源继续执行；缺失情况写入本次结果。
- 模型返回无法解析：保留输入和错误类型，停止这条内容进入下一步。
- 写入后台失败：保留待写入记录与去重标识，重试时避免重复创建。
重试应该针对短暂故障。接口密钥失效、权限不足和参数错误，通常需要修正配置，无限重试只会消耗资源。
成本、部署与许可
n8n 支持云端与自托管。自托管需要维护运行环境和持久化数据；模型与外部接口也可能独立计费。
官方将其称为 fair-code 平台，使用 Sustainable Use License 等许可。内部自动化与对外销售托管能力的许可边界不同，不应笼统理解为任意商业用途都没有限制。
本文依据官方能力说明提出工作流搭建方案，未声称已经运行过该示例，也未对效率或准确率做测试。