n8n 每三小时把 20 个 RSS 源变成 WordPress 草稿

一个 n8n 流程每三小时检查约 20 个 RSS 源，丢弃已见内容后用廉价模型打分，只对值得的新闻调用更强模型改写，最后生成带封面图的 WordPress 草稿并发送 Telegram 提醒。这个流程的目标不是自动发布，而是去掉阅读来源、判断价值和写初稿的机械工作。

20 个 RSS 源每三小时变草稿，省掉的到底是哪些重复劳动

对个人博主或两三人的小团队来说，每天打开几十个 RSS 阅读器、刷一遍标题、点开看内容、判断是否值得写、然后手动起草一篇初稿，是最耗时间的机械劳动。信号里明确提到，这个 n8n 流程针对的正是“reading dozens of sources, deciding what deserves coverage, and leaving a first draft ready to review”。

以前一个人可能要花两三个小时才能完成筛选和初稿，现在每三小时自动跑一次，系统把重复部分全部接管。RSS 源本身更新频率高，人工跟踪容易漏掉或重复劳动，而流程先记录已处理条目，彻底避免重复。判断价值这一步过去全靠主观感觉，现在交给模型打分，标准相对固定。小团队最缺的不是创意，而是时间，把这些底层工作交给机器后，人力可以集中在最终审稿、添加观点和优化表达上。

这种痛点在内容运营里非常普遍。很多独立开发者或小媒体每天要面对信息过载，却只有有限精力产出高质量文章。n8n 把“看、选、写初稿”三个环节打包自动化，实际释放出来的不是几分钟，而是每天几个小时的专注时间。这对预算有限、无法雇佣专职编辑的团队来说，等于把生产力直接提升了一个数量级。

先廉价模型打分再强模型改写，两步设计如何控制成本

整个流程最聪明的部分在于把 LLM 调用分成两步：先用廉价模型对每条新闻打分，只把得分高的那部分交给能力更强的模型进行改写。信号明确描述为“scores each story with a cheap model, rewrites only the ones worth covering with a more capable model”。

假设 20 个 RSS 源每三小时产生 60-80 条新内容，如果每条都调用 GPT-4 级别模型，成本会迅速累积。而先用便宜模型过滤，可能只有 10-20% 的内容进入第二步，整体费用能控制在原来的几分之一。这种分层设计直接解决了小团队最关心的预算问题——不是完全不用大模型，而是只在必要时用。

对个人运营者而言，这意味着每月 API 开支可以稳定在可接受范围，而不是随着内容量线性增长。廉价模型负责粗筛，强模型负责高质量改写，两者结合既保证了效率也兼顾了输出质量。这种思路也给其他自动化场景提供了参考：不是追求单一最强模型，而是根据任务难度匹配不同成本的工具。

从 RSS 到 WordPress 草稿，n8n 里真正关键的四步节点串联

信号提到“what matters isn’t the nodes but the three or four design decisions”。真正重要的是流程背后的判断逻辑，而不是具体用了哪些 n8n 节点。大致可以归纳为四个关键环节：RSS 监控与去重、廉价模型打分、条件分支触发强模型改写、最终生成 WordPress 草稿并附加封面图。

RSS 监控节点定时拉取源，配合数据库或缓存节点记录已处理 GUID，避免重复处理。打分环节调用轻量模型，给出 0-100 的相关性或质量分数，设定阈值后用 IF 节点决定是否继续。改写环节调用能力更强的模型，提示词里包含目标站点风格、长度要求等。最后一环把改写后的文本、自动生成的标题、通过 Unsplash 或类似服务抓取的封面图一起推送到 WordPress draft 接口，同时触发 Telegram 消息。

这四个决策串起来形成闭环。节点本身只是实现工具，真正价值在于“只处理值得的内容”和“输出可直接审阅的草稿”这两个设计目标。明白这一点后，即使换其他工具，核心逻辑依然可以复用。

不自动发布只留草稿，这个选择如何降低风险

这个方案明确“wasn’t to ‘publish on its own’”，而是停在 WordPress draft 阶段。这个选择直接降低了内容风险。小团队最担心的是 AI 生成的内容出现事实错误、语气偏差或版权问题，如果直接自动发布，可能带来声誉损害或法律风险。

停在草稿阶段意味着人类始终握有最终决定权。编辑可以快速浏览草稿，检查事实、调整立场、补充独家观点后再发布。这种“人机协作”模式既利用了自动化带来的效率，又保留了内容质量的把关。信号里强调目标是“remove the mechanical work”，而不是取代人的判断，这正是这个设计的精髓。

对内容敏感的科技媒体或个人品牌来说，这个选择尤其重要。它把自动化限定在辅助角色，避免了完全失去控制的潜在问题。同时也降低了试错成本：即使某次改写质量不高，也只是多了一份待审草稿，不会直接对外造成影响。

Telegram 提醒加封面图，自动化之后还需要人工介入哪些部分

流程最终输出包括带封面图的 WordPress 草稿和 Telegram 提醒，这意味着自动化结束后，人工介入仍然必不可少。Telegram 消息大概率包含标题、摘要和 WordPress 编辑链接，编辑收到提醒后打开后台，审阅全文、修改不准确的地方、添加个人评论、调整 SEO 元素，最后点击发布。

封面图虽然自动生成或抓取，但仍需人工确认是否合适、是否涉及版权问题。改写后的正文可能在事实核查、逻辑连贯性、语气一致性上仍有不足，这些都需要人来把关。信号描述的完整输出正是“leaves the result as a WordPress draft—with a cover image and a Telegram alert”，清楚表明自动化只到初稿阶段。

对小团队来说，剩余工作量从原来的“从零开始写”变成了“审改和润色”，工作强度大幅下降，但质量控制点依然存在。人工主要负责创意、判断和最终责任，这部分工作目前还无法被完全替代。

国内替代 n8n 的三种路径：自建脚本、其他低代码平台还是放弃

n8n 作为开源低代码自动化工具，在国内使用面临节点调用海外 API 不稳定、部署需要服务器、以及潜在合规问题等限制。对中文读者来说，有三种现实路径。

第一种是自建脚本。用 Python + Feedparser 抓 RSS，结合 SQLite 记录已读内容，再调用国内大模型 API（如通义千问、豆包、文心一言）实现打分和改写，最后通过 WordPress XML-RPC 或 REST API 创建草稿。这种方式完全可控，成本最低，但需要一定编程能力，调试定时任务和错误处理要花时间。

第二种是使用国内低代码平台。比如钉钉宜搭、腾讯云低代码、或者开源的 Node-RED、Appsmith 等。它们可以实现类似 RSS 监控、条件判断和 API 调用，但模型集成可能需要额外开发，界面友好度各有差异。相比 n8n，这些平台在国内网络环境下更稳定，但节点丰富度和社区支持可能不如 n8n。

第三种是放弃全流程自动化，只保留 RSS 聚合阅读器加人工筛选。这适合对内容质量要求极高、或者人力相对充足的团队。完全依赖人工虽然效率低，但风险最小，也最容易保证独家视角。

n8n 方案的优点是可视化流程搭建快、社区节点多、能快速实验；缺点是依赖海外服务可能不稳定，且中文提示词优化需要额外经验。国内团队需要根据自身技术能力和预算，在自建脚本的灵活性、低代码平台的便利性、以及完全人工的质量保障之间做出权衡。

总体来看，这个 n8n 项目提供了一个清晰的参考模板。小团队内容运营的未来大概率是“自动化做机械劳动，人工做判断和创意”的混合模式。无论最终选择哪条路径，核心都是把有限的人力从重复工作中解放出来，集中在真正产生价值的地方。

参考来源

• I automated a news site with n8n: from 20 RSS feeds to WordPress drafts