用OpenClaw做了一个自动写周刊的机器人


title: 用OpenClaw做了一个自动写周刊的机器人

用OpenClaw做了一个自动写周刊的机器人

事情的起因是我们团队有个技术周刊,之前一直是人工维护的。每周五下午有个倒霉蛋要花两三个小时去各个平台搜集热门文章,写摘要,排版成Markdown,然后发到飞书群。干了半年大家都烦了,轮到谁谁摆烂,周刊质量越来越拉。

后来我想,这不就是OpenClaw最擅长的事情吗?数据抓取+AI摘要+定时任务,完美匹配。于是花了一个周末搭了一套自动化流程,到现在已经稳定运行三个月了。

数据来源和抓取策略

周刊的内容主要来自四个渠道:

GitHub Trending。每周的热门开源项目,按Star增长量排序。这个数据比较好抓,GitHub Trending的页面结构很稳定,用一个简单的Web Scraping Skill就能搞定。我设置了按语言过滤,主要关注JavaScript、Python、Go、Rust这几个主力语言。

Hacker News。取过去一周点赞数Top 20的帖子。HN有官方API,直接调就行,不用爬虫。这个数据源的质量一直很高,基本上每周都有值得看的内容。

V2EX热帖。V2EX的技术节点过去一周回复数最多的帖子。这个稍微麻烦一点,V2EX的API有频率限制,需要做好请求间隔控制。

掘金热门。掘金的热门文章API相对友好,按照热度排序取Top 15就行。主要关注前端、后端、AI这几个分类。

完整的处理流程

每周日晚上9点,Cron定时任务自动触发,流程大概是这样的:

第一步,数据抓取。四个渠道的Skill并行运行,分别拉取过去一周的数据。每个Skill抓完之后输出一个JSON格式的列表,包含标题、链接、简介、热度指标。这一步大概需要3-5分钟,主要耗时在V2EX的频率限制上。

第二步,去重和分类。把四个数据源的内容合并,按照URL去重(同一篇文章可能同时出现在HN和掘金上)。然后用AI对内容进行分类,分成"开源项目"、“技术文章”、“行业动态”、"工具推荐"四个板块。

第三步,AI撰写摘要。这是最核心的环节。对每一条内容,AI会读取原文(如果能访问的话),然后生成一段100-150字的中文摘要。摘要要求突出核心价值点,说清楚"这个东西是什么"和"为什么值得关注"。

第四步,生成Markdown。把分类好的内容按模板组装成Markdown格式的周刊。包括标题、期数、日期、各板块内容、编辑推荐等。

第五步,推送分发。生成的Markdown通过飞书群机器人Webhook推送到团队群,同时通过邮件API发送到订阅列表。

技术实现细节

Cron配置其实很简单,OpenClaw支持标准的Cron表达式:

0 21 * * 0

周日晚上9点执行。我加了一个失败重试机制,如果某个数据源抓取失败,会在30分钟后自动重试一次。

用到的Skill主要有这几个:

  • Web Scraping Skill:负责抓取GitHub Trending和V2EX
  • HTTP Request Skill:调用HN和掘金的API
  • Text Summary Skill:AI生成摘要
  • Webhook Skill:推送到飞书
  • Email Skill:发送订阅邮件

整个流程串起来用了OpenClaw的Pipeline功能,每个步骤的输出作为下一个步骤的输入,中间有错误会自动catch并记录日志。

三个月运行数据

到目前为止已经自动生成了12期周刊,分享一些数据:

  • 飞书群订阅人数:从最初的15人(纯团队内部)增长到了87人,有其他部门的同事也加进来了
  • 邮件订阅人数:43人
  • 平均打开率:飞书群消息约65%,邮件约38%
  • 读者反馈:大部分人觉得内容筛选得还不错,摘要质量"比人写的还好"(因为人写的时候经常偷懒只写一句话)

最让我惊喜的是,周刊的质量反而比人工维护的时候更稳定了。人工写的话状态好的时候质量很高,状态差的时候就糊弄。AI每一期的水准都差不多,虽然没有特别惊艳的时候,但也没有拉胯的时候。

踩过的坑

当然也不是一帆风顺,说几个踩过的坑:

内容重复问题。前几期经常出现同一个项目或文章在不同板块重复出现的情况。后来加了一个全局去重的步骤,不仅按URL去重,还用AI判断内容相似度,相似度超过80%的只保留热度更高的那条。

AI摘要质量波动。有时候AI的摘要写得太泛,像是在水字数。解决方案是优化了Prompt,明确要求"必须包含具体的技术细节或数据点",并且给了几个好摘要的示例作为Few-shot。

抓取被反爬。V2EX是重灾区,频繁抓取会被暂时封IP。解决方案是控制请求频率,加随机延迟,并且缓存已经抓过的数据。GitHub偶尔也会429,做好重试就行。

飞书消息长度限制。飞书群机器人单条消息有字数限制,周刊内容太长会被截断。后来改成了分多条消息发送,或者发送一个在线文档链接。

时区问题。Cron定时任务的时区设置搞错了一次,导致周一早上才生成周刊。虽然不是大问题,但被同事吐槽了。

后续优化计划

接下来打算做几个改进:

第一是加入个性化推荐,根据读者过去的点击记录,调整内容权重。前端工程师可能更关注React生态的更新,后端工程师可能更关注数据库和中间件。

第二是增加"编辑精选"板块,每期让AI挑出一篇最值得深入阅读的文章,写一段更长的推荐语。

第三是考虑做一个Web版的归档页面,把历史周刊都存起来,方便回顾和搜索。

整体来说,这个项目让我对OpenClaw的自动化能力刮目相看。很多看起来需要人工介入的工作,拆解成标准步骤之后,AI Agent完全可以胜任。

有在做类似自动化内容生成项目的朋友吗?欢迎交流一下经验,特别是反爬和内容质量控制方面的心得。

4 个赞

这个太实用了!我们团队每周也要写技术周刊,每次都是轮流值班的人抓瞎——不知道这周团队做了什么、哪些PR合了、什么bug修了。如果能自动从GitHub和Jira拉数据生成,省事太多了。

请问数据源是怎么接的?是通过MCP还是直接调API?

1 个赞

我做了一个类似的,不过是自动写日报而不是周刊。每天下班前自动从我的Git commit记录、Calendar日程、Jira工单状态生成一份日报,直接发到飞书群里。领导以为我每天花半小时写日报,其实全自动的哈哈。

不过AI生成的日报有时候太「正式」了,我加了一个Prompt让它用轻松口语的风格写,效果好了很多。

2 个赞

自动周刊的关键是数据源的覆盖度。如果只拉Git数据,写出来的周刊只有代码层面的内容。要想有价值还需要接入项目管理工具(进度、里程碑)、沟通工具(重要讨论、决策)、文档工具(新写的文档)等。数据越全面,生成的周刊越有料。

1 个赞

好奇一下,生成的周刊质量怎么样?需要人工Review修改吗?还是直接就能发?

1 个赞

一般需要花5-10分钟过一遍。AI会遗漏一些它不了解的上下文(比如某个PR的业务背景),也偶尔会把两个不相关的事情混在一起。但主体结构和80%的内容是OK的,人工润色一下就能发了。

2 个赞

硬件投入还是得舍得花钱