WorkBuddy自动化实战：定时生成AI日报并推送企业微信

你有没有算过，自己每天早上到工位后，有多少时间浪费在刷行业新闻上？反正我算过：打开浏览器、挨个扫一遍十几个订阅源，再挑出三五篇值得细读的文章，二十分钟就这么没了。后来我发现 WorkBuddy 支持定时任务编排，就顺手给它加了条规则——每天上午十点半，自动把一份 AI 日报送进微信。到今天这个自动化已经稳定跑了两个多月，每天早上十点半，我在企业微信群里就能收到整理好的当日 AI 情报，打开就能直接读，再也不用盯着十几个标签页来回切换。

这篇文章把我从踩坑到稳定运行的完整过程都梳理了一遍，包括 WorkBuddy 的定时任务怎么配、日报的生成逻辑怎么设计、微信推送怎么用官方 Webhook 打通，以及几个我半夜爬起来修过的诡异坑。如果你也想要一个“到点自动把信息喂到嘴边”的日常系统，这篇文章可以直接照着做。

1. 先摸清 WorkBuddy 的自动化能力边界

1.1 为什么选 WorkBuddy，而不是自己写脚本

说实话，这个需求拿 Python 写也完全可行：定时库触发、requests 抓 RSS、再调大模型接口、最后发微信 Webhook，满打满算一百多行代码。但我最后还是选择在 WorkBuddy 里做，核心原因有三个。

一是省掉胶水代码的维护成本。WorkBuddy 把采集、处理、推送做成了节点编排，每一步的输入输出都看得到，出问题定位很快。自己写的脚本跑三周还好，跑三个月之后大概率因为某个 RSS 字段变了就悄悄挂掉，而且日志分散在好几个文件里，排查起来特别费劲。

二是生成环节天然接入了大模型。日报不是简单搬运标题，而是要按主题去重、摘要、排序、用自然语言总结。在 WorkBuddy 里可以直接调用调度好的大模型节点，提示词统一管理，不用自己拿着 SDK 拼请求。

三是有现成的异常重试和通知机制。某个上游站点超时了、推送失败了，WorkBuddy 自带重试策略，还能把失败原因写进日志。这个能力自己用 cron 实现起来倒也不难，但远没有它做得顺手。

我顺便查了下 WorkBuddy 和 CodeBuddy 的分工：前者偏向工作流编排和自动化任务，后者更侧重编码辅助。两个一起用的时候，WorkBuddy 里的任务节点可以直接复用 CodeBuddy 生成的代码片段。不过日报这个场景用不到代码，纯编排就够了。

1.2 一条完整的自动化链路长什么样

整个“日报自动进微信”的链路，我拆成五个环节：

1. 定时触发器：每天 10:30 触发一次，用的是 cron 表达式，WorkBuddy 的触发器节点原生支持。
2. 资讯采集器：按订阅源列表去拉取 RSS 或 API 数据，这一步要注意超时和限流。
3. AI 摘要与聚合：大模型节点对抓回来的原始条目做三件事——去重、相关性筛选、生成摘要。
4. 日报排版：把筛选后的内容按固定模板组装成结构化文本。
5. 微信推送：调用企业微信群机器人 Webhook，把日报以文本或 Markdown 消息发送出去。

可能有人会问，推送渠道为什么选微信而不选邮件或 Slack？因为邮件的打开率越来越低，而微信的触达效率是最直接的——消息推过来，你扫一眼就知道今天有没有值得关注的事，想细看再往下翻。对我个人来说，企业微信群机器人方案走的是官方 Webhook，稳定、免费、不需要申请额外权限，是个人自动化最合适的通道。

注意：微信里能“自动发消息”的合规方案其实不算多。个人微信没有对普通用户开放推送 API，那些号称能托管个人微信发消息的库都有封号风险。所以我的方案全程走企业微信群机器人，这是最稳妥的姿势。

1.3 为什么把时间定在 10:30

这个时间点是我试过三个方案之后才固定下来的。最早设过 08:30，跑了两天就发现问题：早上的资讯源大多还没更新完，很多媒体第一篇稿子是 9 点以后才发的，八点半抓到的内容明显偏少，日报像“早报残废版”。后来改 09:30，情况好一些，但又跟团队早会撞车，推送消息被一堆工作消息淹没了。最后定在 10:30，等于给采集和生成留了充足的缓冲，头部科技媒体的早间更新基本都出来了，群里也不会太吵。

对应的 cron 表达式是0 30 10 * * ?（有些平台是0 30 10 * * *），含义是“每天的 10:30:00 触发一次”。如果不想周末被打扰，可以改成0 30 10 ? * MON-FRI，只有周一到周五发。我后来就是这么改的——周末大家不怎么看工作群，日报发了反而容易沉底，不如不发。

2. 日报内容怎么设计，才有读下去的欲望

2.1 先想清楚日报是给谁看的

做自动化最忌讳一上来就“先把链路跑通再说内容”。如果你推送到微信的日报只是把新闻标题机械地罗列一遍，那它和订阅号推送没有任何区别，读两天就烦了。所以设计日报之前，我花了不少时间想清楚一个问题：这份日报的服务对象是谁？

我自己是 AI 方向的工程师，早上看日报的诉求主要有三类：行业里有大事（发版、融资、重要进展）、有什么值得试的新模型或开源项目、社区里有没有值得细读的技术观点。所以我的日报定位是“技术向 AI 情报”，不是泛科技新闻。

如果你不是这个方向，也可以用同样的思路自定义：做前端的人可能关心框架发版和新工具，做产品的人可能关心竞品动态和行业报告，做投资的人可能关心融资和趋势。这个定位直接决定了后面的信息源和提示词，可以说是一份日报的灵魂。跑了两周之后我最大的体会是：内容定位清晰，比链路跑通要难十倍，但也重要十倍。

2.2 信息源清单与筛选逻辑

我梳理信息源的原则是“少而精”，宁可只订阅六七个高质量源，也不要一口气塞二十个源进来。源越多，重复和噪音就越多，给大模型的去重压力也越大，最后生成的日报反而越水。

目前我订阅的源大概是这一批：

筛选逻辑在 WorkBuddy 的大模型节点里用一句提示词描述清楚就够了：只保留和“大模型、Agent、AI 编程、AI 产品、开源 AI”强相关的内容，删除纯商业宣传稿和重复报道。这一步做完之后，一天的原始条目从七八十条能压到十条以内，日报一下子清爽很多。

这里多说一句：RSS 源的质量是会退化的。有些站点的 RSS 会停更、字段会变、域名会改，所以每隔两周我都会检查一次采集节点的原始输出，看看有没有“静默失败”——也就是接口还在跑、但抓回来的数据已经全是旧闻的情况。这种问题在线性脚本里几乎察觉不到，有了可视化节点之后，你才能一眼看出哪里不对劲。

2.3 日报模板与提示词设计

模板决定了日报的骨架，提示词决定了它的血肉。我用的模板结构大致是下面这样，固定不变：

【AI日报】{date} 今日趋势：{一句话总览} 1. 头条动态 - {标题}：{一句话摘要}（来源：{站点}） 2. 模型与产品 - {条目列表} 3. 值得关注的开源项目 - {项目名}：{一句话说明}（Star 情况/更新动态） 4. 观点与评论 - {链接}：{核心观点} 附：今日值得细读的 {n} 个链接 {链接列表}

提示词方面，我写了一段固定的 System Prompt 挂在“生成日报”节点上，简化版大概是这样：

你是一名 AI 行业编辑。请根据我提供的原始资讯列表，产出一份中文日报，要求： 1. 先做相关性过滤：只保留与大模型、Agent、AI 编程、AI 基础设施、AI 产品相关的内容。 2. 对标题做适度改写，避免直接复制原文标题，控制在 20 字以内。 3. 每条内容配一句话摘要，摘要里必须包含“发生了什么”和“为什么重要”。 4. 按模板格式输出，不要输出模板以外的寒暄或评论。 5. 如果原始信息为空或全部不相关，输出“今日暂无值得关注的内容”，不要编造。

最后一条尤其重要。大模型在信息不足的时候非常容易幻觉出“编的新闻”，千万不能让日报变成小说。这点我在排障部分还会细讲，因为这是我实际踩过的大坑。

3. 实战：Skill 编写、定时器配置、微信推送打通

3.1 准备阶段：装好 WorkBuddy 并确认能力

安装这一步比较简单，从官方渠道下载对应平台的安装包，一路下一步就行。装完之后我建议先干两件事，别急着建任务。

第一件是把大模型 API 配置好。日报生成依赖大模型节点，你需要在 WorkBuddy 的模型配置里填好服务商和 API Key。不同发行版的菜单路径可能不太一样，重点是要确认“生成日报”节点能正常调用到模型。我遇到过配置里填了 Key 但模型列表拉取失败的情况，排查半天发现是网络代理设置的问题，把模型服务地址加到白名单就好了。

第二件是确认当前版本的触发器类型。WorkBuddy 不同版本对定时触发的支持程度有差异，老版本可能只支持手动触发或事件触发，新版本才有 cron。如果你手里的版本没有定时器，先升级到较新的版本；如果实在升不了，也可以用系统自带的计划任务定时调用 WorkBuddy 的命令行入口，效果一样。只要最后能“到点触发”就行，实现形式不重要。

3.2 编写日报生成 Skill

WorkBuddy 里的“Skill”可以理解成一个可复用的技能包，包含触发条件、处理步骤和输出动作。我这里给一个类 YAML 风格的示例骨架，你手里版本如果用的是可视化编排，按同样的节点关系去搭即可：

name: ai_daily_report_to_wechat description: 每天10:30生成AI日报并推送到企业微信群 trigger: type: cron expression: "0 30 10 ? * MON-FRI" # 周一至周五 10:30，不打扰周末 timezone: "Asia/Shanghai" steps: - id: collect_news type: http_batch sources: - "rss://jiqizhixin" # 实际填你订阅的机器之心地址 - "rss://qbitai" # 实际填你订阅的量子位地址 - "https://example.com/rss/ai" # 占位示例：替换为自己确认可用的RSS timeout: 15s max_items: 50 - id: ai_summarize type: llm model: "gpt-4o-mini" # 按自己的模型配置替换 system_prompt: "{{prompts.ai_editor}}" input: "{{collect_news.output}}" temperature: 0.3 # 摘要类任务温度要低，避免胡编 max_tokens: 1500 - id: format_report type: template template: "{{templates.ai_daily}}" data: "{{ai_summarize.output}}" - id: push_wechat type: webhook url: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key={{secrets.wechat_key}}" method: POST headers: Content-Type: application/json body: msgtype: text text: content: "{{format_report.output}}"

这个骨架里的四个步骤对整体链路来说缺一不可。实际搭建时，我的建议是一个节点一个节点地建，每建完一个就先看它的输出，确认没问题再接下一个。别一口气全连上再调，不然出了问题你根本分不清是采集挂了还是模型挂了。

我一开始就是没按这个顺序来，四个节点一口气全接好，结果第一次测试返回空日报，排查了一上午才发现是采集节点直接把超时当成空数据返回了。拆开一个个测，半小时就定位到了。

3.3 企业微信群机器人：把微信通道打通

微信推送这部分，我从测试到上线试过两种通道，最后固定用企业微信群机器人。配置步骤很简单：

1. 在企微里建一个群，哪怕只有自己一个人也行。
2. 在群设置里找到“群机器人”，添加一个机器人，名字可以起成“AI日报助手”。
3. 添加成功后，会拿到一个 Webhook 地址，格式类似https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。
4. 把这个 key 填到 WorkBuddy 的密钥管理里，别写死到 Skill 配置里。

拿到 Webhook 后，先用 curl 手测一发，确认通道是通的：

curl -X POST \ 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key' \ -H 'Content-Type: application/json' \ -d '{ "msgtype": "text", "text": { "content": "测试消息：AI日报通道正常" } }'

如果返回{"errcode":0,"errmsg":"ok"}，说明通道已经通了。这一步千万别跳过，能在链路之外单独验证的问题，就不要拖到链路里排。

这里有几个参数细节值得说明。消息类型选择上，text 支持换行，适合长文；markdown 支持标题、加粗和链接语法，排版更好看，但字节限制更小。我日报正文用的是 text 文本加简洁结构，因为里面有多个链接，text 的可读性更稳。频率方面，每个机器人每分钟最多只能发 20 条消息，日报每天一条完全够用，但如果你后面给 WorkBuddy 加了别的推送任务，要留意别把同一个机器人当免费消息通道滥用。字节方面，text 消息单条不能超过 2048 字节，markdown 不能超过 4096 字节，日报太长会被截断或发送失败，我一般让生成节点把日报压到 1200 字以内，跑两周没出过截断问题。

还有一点：Webhook 配置里可以开启“签名校验”，开启后请求头需要带timestamp和sign字段。虽然是个人用，我还是建议开启，因为 WorkBuddy 里配签名只需多填两个字段，成本极低，安全性上了一个台阶。

3.4 定时任务配置与一次完整测试

配置完 Skill 后，别急着把触发器打开，按下面顺序来一遍：

1. 手动触发一次“collect_news”节点，看返回的原始条目数量和字段是否正常。此时如果条目数为空，别往后走，先换源或检查网络。
2. 手动执行整条 Skill，确认日报能正常生成并推送到群里。这次测试的内容可以打上“测试”标记，验证链路完整性。
3. 把触发器时间临时改成 2 分钟后，跑一次真实触发，确认 cron 表达式被系统正确解析、时区用的是东八区。
4. 一切正常后，改回 10:30，开启定时。

我那次启用时还犯过一个低级错误：把触发器时间设成 10:30，但部署时系统时间用的还是 UTC，结果真正触发的时间是北京时间 18:30。后来在 Skill 配置里显式声明了timezone: Asia/Shanghai才解决。这个点不难，但特别容易被忽略。

4. 排障实录：自动化跑起来的那些坑

4.1 定时器没触发怎么办

定时器“到点没反应”是这类自动化最容易出的问题，我遇到的集中在这三类。

第一是时区不匹配。默认时区是 UTC，10:30 被理解成 UTC 时间，导致推送晚了 8 个小时。解决办法是在 Skill 配置里显式声明timezone: Asia/Shanghai，或者在操作系统层把运行 WorkBuddy 的机器时区设成东八区。

第二是 cron 表达式和平台约定的“星期”位写法不一致。有些平台用0-6，有些用1-7，还有的周日是 0。这种问题光看文档不保险，建议改完表达式后先把触发时间临时设成 1 分钟后，实测一次确认能触发，再放开到正式时间。

第三是程序重启后定时任务没有自动恢复。部分版本的服务重启后，定时 Skill 需要手动激活。WorkBuddy 有守护进程的话会好一点，但如果你跑在桌面客户端里，要注意别把进程给关了。我现在养成的习惯是每周随便看一次日志，确认这周每天的日报都如常产生了，有缺失就马上查，不积压。

4.2 微信推送失败怎么排查

推送失败的排查路径比较固定，直接看返回码就行：

有个容易被忽略的点：如果群机器人开启了签名校验，而运行 WorkBuddy 的机器时钟偏差太大，时间差超过一定范围也会导致签名校验失败。解法是确保运行机器的系统时间准确，比如启用 NTP 时间同步。我当时的情况是宿主机时间快了大概两三分钟，白天可能没感觉，但签名校验是毫秒级的严格，直接就挂了。

我线上还出现过一次“推送静默失败”：WorkBuddy 日志里显示 webhook 调用返回成功，但群里就是没有消息。查了半天，发现是推送节点把text.content里的换行符在 YAML 解析时弄丢了，JSON 里被拼成一行，而企微对超长单行内容会拒绝渲染。处理方式是在模板里避免裸换行，改用显式的\n占位符，再在推送节点统一替换成真实换行，这个坑比较冷门，但一旦遇到就很难察觉。

4.3 日报内容太水，怎么优化

链路通了之后，最让我花心思的反而是日报质量。第一版跑出来的日报，摘要经常是“该模型发布了新版本”这种正确的废话。后来我把生成节点的提示词改成了“摘要中必须包含发生了什么和为什么重要”，质量立刻上了一个档次。

另一个高频问题是去重不够。同一件大事，机器之心、量子位、36氪可能都报了，AI 生成节点有时候会合并失败，导致日报里出现两个几乎一样的条目。我的解法是在提示词里明确加一句“如果多个条目标题指向同一事件，只保留信息最完整的一条，并在括号里标注其他来源”，效果不错。

还有一个经验值得分享：给“生成日报”节点设置较低的温度参数。我用的 0.3，摘要类任务温度越低，越不容易自由发挥。如果你做的是娱乐向内容，温度可以高一点，但日报这类偏事实的，低温才是保险选择。

4.4 几个零碎但实用的小技巧

整理几个跑这两个多月才攒下来的经验，这些写不进官方文档，但确实帮了大忙。

节假日停发：我后来把定时表达式改成了“每工作日 10:30”，周末和长假不推送。工作日表达式是0 30 10 ? * MON-FRI，但注意它不会自动识别法定节假日，所以长假那几天如果不想收到，就手动暂停一下，或者额外接一个判断节假日的节点。

日报里的链接时效性：RSS 抓回来的链接大多是原文地址，但有些站点会定期更新 URL 结构，导致日报里的链接点进去是 404。这个没法完全避免，只能在采集节点加一个简单的 URL 预检，把打不开的条目过滤掉。我加了这个预检之后，日报里“死链”的比例从偶尔出现降到了零。

保留一份手动触发入口：WorkBuddy 里我保留了一份 Skill 的手动触发版本，参数允许指定“昨天的信息源”。这样当天没来得及看日报，或者想回看上周五的内容，直接手动跑一次就行，不一定非要等定时。

推送结果留痕：WorkBuddy 的日志默认按天滚动，我会定期把日志导出，主要是为了追查“某天日报为什么缺了某条内容”。查了两三次之后我发现，这类问题七成出在信息源环节而不是生成环节，所以我现在检查的顺序永远是采集节点优先。

写到这里，这套“每天早上十点半 AI 日报自动进微信”的系统就算完整讲清楚了。最后聊点我的真实体会：这类自动化最值钱的部分不是“把链路跑通”那一下，而是你为它设计的内容筛选规则和提示词。系统跑起来之后，你真正要做的是每隔一段时间回去看一眼——信息源是否还活着、提示词能否覆盖新的内容形态、日报结构需不需要调整。它不是一个一劳永逸的项目，而是一个需要你偶尔浇水的小花园。我这两个多月最大的收获，是每天早上打开企业微信，不用再被几十个标签页拽着走，十点半那条日报成了我一天信息输入的起点，剩下的时间是拿去读书还是写代码，终于可以由我自己决定。