从“人工搬砖”到“睡后执行”：我用 Cursor + n8n + OpenClaw 搭了一套全自动内容分发系统

这是一篇完整的AI Agent实战笔记。核心任务是打通内容生产到多平台分发的自动化链路。市面上工具方案很多，但真正能把“自动抓取→AI处理→跨平台分发”串起来的详细教程极少。本文涉及三个工具的实战组合：n8n做流程编排、Cursor做自主编码、OpenClaw做自动化发布。全文按时间线推进：周一搭建底层数据流，周二集成AI生成能力，周三完成分发闭环，周四调试熔断和异常处理。每个环节提供可直接复用的配置代码和实际踩过的坑。

原创

林语琛

找找AI

先交代一下背景。

我手头运营着一个科技资讯类的内容账号，每天需要在飞书群里推送最新动态，同时在几个内部平台同步更新。之前这套流程全靠手动——早上起来刷RSS找选题，复制标题，写摘要，生成卡片配图，然后打开飞书逐条粘贴发送。每天雷打不动一个多小时，还容易漏消息。

我决定把这套流程彻底自动化。目标只有一个：每天早上一睁眼，一条包含当天最新内容精华的飞书消息已经躺在群里，同时内部平台的日报也更新完毕。

花了一周时间，搭了一套基于三个工具的自动化系统——n8n做流程编排，Cursor写核心代码，OpenClaw做最终分发。现在每天早上打开手机就能看到它帮我干完的活。

下面完整拆解这条链路。

一、工具选型：为什么是这三个？

如果你也在考虑类似的自动化项目，先别急着看代码，想清楚一个根本问题：你到底想自动化什么？

我的需求其实可以拆解成三块：

每天固定时间从几个RSS源和API拉取最新资讯
用AI把拉到的内容做摘要、分类、生成简报
把处理好的内容推到飞书群和内部平台

单一工具很难搞定这三件事。RSS轮询需要后台服务跑定时任务，这块n8n很擅长，它有现成的RSS节点和定时触发器。内容加工涉及AI推理，虽然n8n也有AI节点，但跟本地跑的大模型集成起来不够灵活。跨平台分发更麻烦，飞书和内部平台的接口不一样，有些甚至没有开放API。

我最后确定的方案是：n8n做主流程编排，Cursor写核心处理脚本，OpenClaw解决没有API的分发场景。 三者分工明确，不会打架。

二、Day 1：用n8n搭数据采集层

周一晚上开始动手。目标是让系统自动抓取几个科技资讯RSS源，把原始数据清洗成统一的JSON格式。

第一步：拉取RSS

n8n的RSS Feed Trigger节点可以直接用。配置了三个RSS源，每个设置每2小时拉取一次。注意RSS Trigger是读节点不是写节点，要配合Schedule Trigger用。我就是在这里踩了第一个坑：一开始以为RSS Trigger自带轮询，结果发现它只是按需读取，需要Schedule Trigger在前面定时触发。

正确的配置：Schedule Trigger（每2小时）→ RSS Feed节点1 → RSS Feed节点2 → RSS Feed节点3。

第二步：数据去重

RSS抓回来的内容会有大量重复——同一个新闻被不同源转载，或者上一次轮询已经处理过的条目重复出现。我的解法是用一个Code节点，把抓到的每篇文章的标题和URL拼接生成MD5，存进一个Redis Set里，每次新来一条先去Set里查一下，存在就跳过。

下面是去重节点的JavaScript代码：

// 从上一个节点拿到文章列表
const items = $input.all();
const processed = [];

// 这里用了一个全局对象做临时存储，生产环境建议用Redis
if (!$nodeMeta.hasOwnProperty('processedSet')) {
  $nodeMeta.processedSet = new Set();
}

for (const item of items) {
  const hash = crypto.createHash('md5')
    .update(item.json.title + item.json.link)
    .digest('hex');
  
  if (!$nodeMeta.processedSet.has(hash)) {
    $nodeMeta.processedSet.add(hash);
    processed.push(item.json);
  }
}

return processed;

这个去重逻辑跑了三天，累计处理了两百多条，没有一个重复。

第三步：结构化输出

去重之后的数据是格式各异的，不同RSS源的字段命名不一致。再用一个Code节点做字段映射，统一成title、url、summary、pubDate四个字段。字段映射这块没有技巧，就是手写Mapping，但一定要做，否则后面AI处理和分发时会乱套。

Day 1 踩坑记录：

RSS Trigger的数据结构与文档示例有出入，实际返回的json对象里，文章列表藏在item字段下面，需要先解析一遍
某些RSS源返回的pubDate格式五花八门，解析前先做了一次格式归一化处理
Code节点中调用外部npm包需要先在n8n中全局安装，折腾了半小时才搞定

三、Day 2：Cursor写核心处理脚本

目标是把原始资讯转换成各平台需要的格式——飞书消息、内部平台结构化数据。

这个环节用n8n的JavaScript Code节点也能写，但稍微复杂一点的逻辑就会变成难以维护的“面条代码”。我的做法是在n8n里调用一个外部API，这个API的接口逻辑由Cursor帮我生成并部署在本地。

第一步：让Cursor生成FastAPI服务

打开Cursor的Agent模式，输入需求描述：

帮我写一个FastAPI服务，接收POST请求，传入一个包含多篇文章的数组，每篇文章有title、url、summary、pubDate四个字段。对每篇文章做三件事：1）用大模型将summary字段扩写成150字左右的简报；2）根据内容推断合适的消息优先级（高/中/低）；3）生成一条适合飞书群发布的markdown格式消息。

Agent模式自动生成了完整代码，包括模型调用逻辑、异常处理、请求响应结构。全程没有动过一行代码。生成的代码质量很高，唯一需要手动改的是模型endpoint地址，换成了本地运行的Ollama。

第二步：部署接口

用uvicorn main:app --port 8000启动服务。在n8n里加一个HTTP Request节点，把第一步清洗好的文章列表作为POST Body发过去。返回的结果是处理后的增强数据。

第三步：解决幂等性问题

Cursor帮我加了一个基于文章ID的处理记录表，用SQLite存储。服务收到请求后先查数据库，该文章已经处理过就直接返回缓存结果。这样即使n8n重试，也不会重复消耗API调用。

Day 2 踩坑记录：

Cursor生成的代码里模型并发处理用了asyncio.gather，本地CPU不太够用时会超时，改成了串行循环后就稳定了
大模型把“新闻摘要”扩写成了“广告文案”，调了一下prompt加上约束词才解决
服务跑久了内存会涨，后来加了内存上限和定期重启的机制

四、Day 3：用OpenClaw做无API分发

最麻烦的环节来了。飞书群有webhook，直接用n8n就能发。但内部平台没有开放API，只能人工登录后台一条条发。

如果平台网页相对稳定、不需要频繁验证登录，这类场景正适合OpenClaw。它的Skill系统可以用Playwright写浏览器自动化脚本，模拟人工操作。

第一步：部署OpenClaw

阿里云上买了一个2核4G的轻量服务器，Ubuntu 22.04。官方文档有docker-compose一键部署的配置，直接用。注意端口8080要在阿里云安全组里开放。

第二步：写分发Skill

打开OpenClaw的Skills目录，新建一个文件夹platform_poster，下面放SKILL.md（定义Skill的行为规范）和post_to_platform.py（实际执行的Python脚本）。核心逻辑是用Playwright打开内部平台的发布页面，填入标题和正文，点击发布按钮，然后截图保存日志。

Skill配置的关键在于SKILL.md文件，它定义了这个Skill的名字、描述、输入输出。就像一份操作说明书，主Agent根据这份说明书来判断什么时候调用它。

第三步：集成到n8n

在n8n里加一个Webhook节点作为触发器，OpenClaw的流程跑完后向n8n发送信号，告知分发结果。另外加了一个IF节点处理失败重试：如果分发失败，等待5分钟后重试，最多重试3次。

Day 3 踩坑记录：

内部平台的登录态有效期只有一天，需要在Skill里做session持久化，用pickle保存cookie
页面元素定位用selector容易变，改成了XPath相对路径稳定性好了很多
OpenClaw的浏览器实例在Docker里跑，需要提前装好中文字体，否则消息里的中文会乱码

五、Day 4：熔断、日志、异常处理

前三天的核心功能跑通后，还差最后一件重要的事：让系统在出问题时自己知道该怎么办。整个流程串起来之后最怕的是：AI断网导致一分发就失败、某个RSS源宕机导致轮询中断、大模型收费API欠费导致处理停摆。这些都是“自动化做一半，还不如手动做”的根源。

我在n8n里加了三层容错：

超时熔断：在流程开始处加一个Stop节点，运行时如果在3秒内没有收到第一条数据就自动熔断，所有后续节点都跳过，并触发告警。实测超时阈值设到5秒比较安全，3秒在RSS源响应慢时容易误杀。
故障回滚：用IF节点检查每个步骤的成功标志，失败时跳转到清理节点，删除已产生的部分数据，避免脏数据污染系统。
可观测：n8n自带执行日志，但我加了钉钉webhook，流程成功或失败都会推一条消息给手机，内容包括执行时间、处理文章数量、是否有异常。

加完这三层之后，系统才算真正可以脱离人盯着跑。

六、最终效果和避坑总结

系统跑了一周多的效果：

每天自动轮询6次，处理文章20到40篇
AI摘要准确率大约九成，偶尔把技术更新摘要成产品发布
飞书消息定时推送后平均阅读量比手动发布时高出一些
唯一一次失败是OpenClaw的浏览器因为平台页面改版报错，早上醒来发现群消息没发，手工干预后恢复了

如果你打算复刻类似流程，给你几条硬核建议：

对开发者的建议：先把单一工具跑通，再考虑集成。我第一天只调通了n8n的RSS，第二天才加AI处理，第三天加分发，第四天处理异常。一次性搭四个工具会疯掉。
关于工具选择：n8n和Zapier选一个即可。Zapier上手更快但费用和限流需要注意；n8n开源免费可以跑在自己的服务器上，但需要的学习和调试时间会更多。
给零基础读者的最低成本实操方案：从最简版开始——用n8n的默认模板（RSS + Webhook + Email节点）搭一个“抓取RSS并发送邮件通知”，跑通了再加AI节点。阿里云上n8n和OpenClaw都有预置镜像，几乎不用配置环境。
最关键的一条：不要一次性把所有事情交给AI。我的设计里，AI只做“扩写摘要”和“分类优先级”这种不可规则化的非标准任务，其余的取数据、去重、格式转换、分发检查都是确定性逻辑用代码写死。全依赖AI，哪天模型接口崩了整个系统就瘫痪了。

最后，如果你也想尝试搭建类似的自动化流程，强烈建议从最基础的“RSS订阅 → 飞书通知”起步。我在n8n里存了一份完整的工作流JSON，包括去重、AI处理、多平台分发的所有配置，可以直接导入使用。有需要的读者在评论区留言，我把模板分享出来。

这套系统现在每天早上准时替我跑完所有流程，而我只需要喝杯咖啡的时候翻一眼手机。这可能就是Agent最迷人的地方——它干不了什么惊天动地的大事，但它把每天要消耗你的那一个小时，还给了你。

n8nCursorOpenClawAgent工作流自动化发布跨平台分发