WorkBuddy定时任务+微信推送：打造每日AI日报自动化流程

1. 为什么我要给 WorkBuddy 设一个"十点半闹钟"

每天早上到工位，第一件事不是泡咖啡，而是打开各种信息源翻一遍：行业新闻、竞品动态、技术社区热帖、昨天没看完的文档更新。这套动作熟练之后大概要花二十分钟，但问题是它没有任何创造性——纯粹是信息搬运。更烦的是，有时候一忙起来就忘了看，等到下午才发现某个重要更新已经过去大半天了。

我用的工具是 WorkBuddy，一个可以挂载各种技能（Skill）的 AI 助手类产品。它本身支持定时触发任务，也能通过 Webhook 或者中间层把结果推送到微信。于是我就想：能不能让它每天早上十点半自动帮我跑一遍信息收集和摘要，然后把一份结构化的 AI 日报直接送到微信里？这样我打开微信就能看到今天该知道的事，不用再手动翻。

这个想法落地之后，实际效果比我预期好不少。整个链路跑通大概花了一个周末的零碎时间，核心难点不在 AI 本身，而在"怎么让 WorkBuddy 在指定时间自动执行"和"怎么把结果稳定地送进微信"这两个环节。下面我把完整思路和踩过的坑都拆开讲，适合有一定动手能力、想用 AI 工具做自动化信息流的朋友参考。如果你完全没接触过 WorkBuddy，也不用担心，我会把关键概念顺带解释清楚。

提示：本文涉及的自动化流程仅用于个人信息聚合与效率提升，所有操作均在合规范围内进行，不涉及任何敏感数据的采集或传输。

2. 拆解需求：一份"AI 日报"到底该包含什么

2.1 先想清楚信息源的边界

很多人做自动化日报的第一个误区是"什么都想要"。我一开始也犯了这个毛病，把 RSS、推特、GitHub Trending、Hacker News、几个技术公众号全塞进去，结果每天生成的内容又长又杂，看两眼就不想看了。后来我砍到三个核心板块：

• 行业动态：跟我工作直接相关的几条新闻，控制在 5 条以内
• 技术更新：我关注的几个开源项目有没有新 release 或者重要 issue
• 值得读的长文：一到两篇深度内容，附上摘要和原文链接

这个边界定下来之后，整个流程的复杂度下降了一个量级。信息源少了，WorkBuddy 处理起来更快，生成的内容也更聚焦。我的建议是，一开始只放你最离不开的两三个源，跑一周之后再根据实际阅读情况增减。

2.2 日报的格式决定了后续所有环节

格式这件事看起来是小事，但它直接影响你后面怎么推送、怎么阅读。我试过三种格式：

格式	优点	缺点	适用场景
纯文本	兼容性最好，微信直接显示	没有层级，长内容难读	信息量少的简版日报
Markdown	结构清晰，可读性强	微信不渲染，需要转换	推送到支持 MD 的平台
图文卡片	视觉效果好	生成复杂，需要额外服务	对排版有要求的场景

最后我选了"精简 Markdown + 纯文本兜底"的方案。具体做法是让 WorkBuddy 输出 Markdown，但在推送前做一个轻量转换，把标题变成加粗、列表变成短横线，这样在微信里看起来不会太乱。如果你用的是企业微信或者飞书，可以直接用 Markdown 格式，体验会更好。

2.3 十点半这个时间点不是随便定的

为什么选上午十点半？我实测下来有几个考虑。太早的话，很多海外信息源还没更新完，抓到的内容是昨天的；太晚的话，上午的工作节奏已经被打乱，你也没心思看。十点半左右，大部分夜间更新的内容已经稳定，同时你还没进入深度工作状态，花五分钟扫一遍日报刚刚好。

当然这个时间可以根据你的作息调整。如果你习惯早到，九点半也行；如果你是夜猫子，放到下午两点也没问题。关键是固定下来，让身体形成"这个时间看日报"的习惯。

3. 让 WorkBuddy 按时干活：定时触发的几种实现路径

3.1 WorkBuddy 自身的定时能力够不够用

WorkBuddy 本身是支持任务调度的，你可以在它的配置里设定某个 Skill 在指定时间执行。这是最直接的方式，不需要额外搭任何东西。具体操作逻辑是：创建一个定时任务，绑定你要执行的 Skill，设置 cron 表达式为30 10 * * *，也就是每天上午十点半触发。

但这里有个细节要注意：WorkBuddy 的定时任务依赖于它的运行环境是否在线。如果你把它部署在自己的电脑上，那电脑休眠了任务就不会执行。我的做法是把它挂在一台常开的小主机上，或者用云端的定时触发服务来唤醒它。这一点在后面讲部署的时候会展开。

3.2 用外部定时器做兜底

为了保险，我额外加了一层外部定时器。思路很简单：用一个独立的定时服务，每天十点半给 WorkBuddy 发一个触发信号。这个信号可以是一个 HTTP 请求，也可以是一条消息。WorkBuddy 收到之后开始执行日报生成流程。

这样做的好处是解耦。即使 WorkBuddy 自身的调度出了问题，外部定时器依然能把它叫醒。我用的是系统自带的 cron（Linux/macOS）或者任务计划程序（Windows），写一条简单的命令就行：

# Linux/macOS 下用 crontab -e 添加 30 10 * * * curl -X POST http://your-workbuddy-host/trigger/daily-report

Windows 的话用任务计划程序创建一个基本任务，触发时间设为每天十点半，操作选"启动程序"，填入 curl 命令即可。如果你不想用 curl，也可以写一个简单的 Python 脚本来发请求：

import requests import datetime def trigger_report(): url = "http://your-workbuddy-host/trigger/daily-report" try: resp = requests.post(url, timeout=30) print(f"[{datetime.datetime.now()}] 触发结果: {resp.status_code}") except Exception as e: print(f"触发失败: {e}") if __name__ == "__main__": trigger_report()

这个脚本可以配合系统的定时任务使用，也可以直接放在 WorkBuddy 所在的环境里跑。

3.3 触发之后 WorkBuddy 要做什么

触发只是第一步，真正的工作是 WorkBuddy 收到信号后执行的那套流程。我给它设定的动作顺序是这样的：

1. 拉取预设的信息源列表，逐个抓取最新内容
2. 对抓到的内容做去重和初步筛选，去掉明显不相关的
3. 调用 AI 模型对筛选后的内容做摘要和归类
4. 按照预设模板生成日报文本
5. 把日报推送到微信

这五步里，第三步是耗时最长的，通常需要十几秒到半分钟。所以整个流程从触发到收到日报，大概有三十秒左右的延迟。这个延迟完全可以接受，你不需要盯着看。

注意：如果你的信息源比较多，建议给每一步设置超时时间，避免某个源卡住导致整个流程挂起。我在实际运行中给抓取步骤设了 15 秒超时，摘要步骤设了 60 秒超时，超过就跳过并记录日志。

4. 把日报送进微信：推送链路的选型与实操

4.1 为什么不用微信个人号直接发

最直觉的想法是让程序直接给微信个人号发消息。但这条路实际上走不通，因为微信个人号没有开放的 API 供外部程序调用。市面上一些所谓的"微信机器人"方案，要么依赖逆向工程，稳定性极差，要么违反平台规则，随时可能失效。我一开始也尝试过，折腾了半天，消息发出去十条有八条被拦截，完全不靠谱。

所以正确的思路是找一个"微信生态内、有正规接口"的通道。目前比较稳妥的有两个方向：企业微信应用消息和服务号模板消息。这两个都是官方支持的，稳定性有保障。

4.2 企业微信应用消息：最省事的方案

企业微信的好处是你可以自己注册一个企业（个人也能注册），然后在管理后台创建一个自建应用。这个应用可以给指定的成员发送消息，而且支持文本、Markdown、图文等多种格式。

具体步骤：

1. 注册企业微信，进入管理后台
2. 在"应用管理"里创建一个自建应用，记下 AgentId 和 Secret
3. 在"我的企业"里找到企业 ID（CorpId）
4. 用这三个参数换取 access_token
5. 调用发送消息接口，把日报内容推给指定成员

获取 token 的代码大概长这样：

import requests def get_access_token(corp_id, corp_secret): url = f"https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid={corp_id}&corpsecret={corp_secret}" resp = requests.get(url, timeout=10) data = resp.json() if data.get("errcode") == 0: return data["access_token"] else: raise Exception(f"获取 token 失败: {data}")

拿到 token 之后，发送消息就很简单了：

def send_message(token, agent_id, content): url = f"https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token={token}" payload = { "touser": "@all", "msgtype": "text", "agentid": agent_id, "text": {"content": content}, "safe": 0 } resp = requests.post(url, json=payload, timeout=10) return resp.json()

这套方案我跑了大半年，没有出现过消息丢失的情况。唯一需要注意的是 access_token 有有效期（通常 7200 秒），需要做缓存和自动刷新。我的做法是在内存里存一个 token 和过期时间，每次发送前检查是否过期，过期就重新获取。

4.3 服务号模板消息：适合有开发基础的人

如果你已经有认证的服务号，也可以用模板消息来推送。这种方式的好处是消息会出现在微信的"服务通知"里，跟其他服务号消息在一起，不会太打扰。但缺点是模板消息的格式受限于模板本身，不能随意排版，而且需要用户先跟服务号产生过交互才能收到消息。

我个人的选择是企业微信方案，因为它的自由度更高，而且可以给自己发，不需要用户关注之类的额外步骤。如果你只是想自己收到日报，企业微信自建应用是最省事的路径。

4.4 推送内容的格式处理

微信的文本消息不支持 Markdown 渲染，所以你需要把 WorkBuddy 生成的 Markdown 做一次转换。我的处理方式比较简单粗暴：

• ## 标题转换成【标题】
• - 列表项保持短横线
• **加粗**去掉星号，直接保留文字
• 链接保留原始 URL，方便点击

转换函数大概是这样：

import re def md_to_wechat(md_text): # 标题转换 text = re.sub(r'^#{1,6}\s*(.+)$', r'【\1】', md_text, flags=re.MULTILINE) # 去掉加粗标记 text = re.sub(r'\*\*(.+?)\*\*', r'\1', text) # 去掉斜体标记 text = re.sub(r'\*(.+?)\*', r'\1', text) return text

这个转换不追求完美，够用就行。如果你对排版有更高要求，可以考虑用图文消息（news 类型），把日报做成一张卡片，但那样需要额外处理封面图和摘要，复杂度会上升不少。

5. 日报生成的核心：WorkBuddy 的 Skill 配置与提示词设计

5.1 Skill 是什么，为什么要用它

WorkBuddy 的 Skill 可以理解为一个"预设好的任务模板"。你把要执行的步骤、要调用的工具、要遵循的提示词都写在一个 Skill 里，之后每次触发这个 Skill，它就会按照你定义的方式执行。这比每次手动输入提示词要稳定得多，也更适合自动化场景。

我创建了一个叫daily-ai-report的 Skill，里面定义了三个核心部分：信息源列表、处理逻辑、输出模板。下面分别说。

5.2 信息源列表的配置

信息源我放在一个单独的配置文件里，方便随时增删。格式是 JSON：

{ "sources": [ { "name": "技术社区热帖", "type": "rss", "url": "https://example.com/feed", "max_items": 5 }, { "name": "开源项目更新", "type": "api", "url": "https://api.example.com/releases", "max_items": 3 } ] }

WorkBuddy 在执行时会读取这个文件，逐个抓取。这里的关键是max_items要设小一点，避免一次抓太多导致摘要质量下降。我的经验是每个源不超过 5 条，总条数控制在 15 条以内。

5.3 提示词的设计要点

提示词决定了 AI 怎么处理抓到的内容。我试过很多版本，最后稳定下来的提示词结构是这样的：

你是一个信息摘要助手。下面是我今天需要了解的内容，请按照以下要求处理：

1. 将内容分为"行业动态""技术更新""深度阅读"三个板块
2. 每个板块最多保留 5 条，按重要性排序
3. 每条用一句话概括，不超过 50 字
4. 如果某条内容包含可操作的信息（如新版本发布、API 变更），在概括后补充一句影响说明
5. 最后用一句话总结今天的整体趋势

这个提示词的关键在于"限制条数"和"限制字数"。不加限制的话，AI 会倾向于把所有内容都塞进去，结果就是一篇又长又没重点的流水账。加了限制之后，它被迫做取舍，输出质量明显提升。

另外一个小技巧：在提示词里明确要求"如果某条内容不确定是否相关，直接丢弃"。这样可以避免一些边缘内容混进来。

5.4 输出模板的固定化

为了让每天的日报格式一致，我在 Skill 里定义了一个输出模板：

【AI 日报】{date} 一、行业动态 {industry_news} 二、技术更新 {tech_updates} 三、深度阅读 {deep_reads} 今日趋势：{summary}

WorkBuddy 会把生成的内容填充到对应的占位符里。这样做的好处是你每天收到的日报长得都一样，扫一眼就知道哪部分在哪，阅读效率很高。

6. 实测中遇到的坑与排查过程

6.1 定时任务没触发：从日志倒推原因

上线第三天，我发现十点半没收到日报。第一反应是 WorkBuddy 挂了，但检查发现它运行正常。于是我去看定时任务的日志，发现 cron 确实执行了，但 curl 请求返回了 502。

顺着这个线索查下去，发现是 WorkBuddy 所在的服务在十点半左右刚好在做一次自动更新，端口短暂不可用。解决办法很简单：把触发时间往后挪了五分钟，同时在触发脚本里加了重试逻辑——如果第一次失败，等 30 秒再试一次，最多重试三次。

import time import requests def trigger_with_retry(url, max_retries=3, interval=30): for i in range(max_retries): try: resp = requests.post(url, timeout=30) if resp.status_code == 200: return True except Exception as e: print(f"第 {i+1} 次尝试失败: {e}") if i < max_retries - 1: time.sleep(interval) return False

这个坑给我的教训是：任何自动化流程都要考虑"依赖服务暂时不可用"的情况，重试机制是必须的。

6.2 日报内容重复：去重逻辑的缺失

跑了一周之后，我发现日报里经常出现前几天已经看过的内容。原因是有些信息源的更新频率很低，今天抓到的还是上周那篇。AI 不知道你已经看过，就原样放进来了。

解决办法是在 Skill 里加一个"已读记录"机制。具体做法是每次生成日报后，把内容的唯一标识（比如 URL 或者标题哈希）存到一个本地文件里。下次生成时先读这个文件，把已经出现过的内容过滤掉。

import hashlib import json import os HISTORY_FILE = "report_history.json" def load_history(): if os.path.exists(HISTORY_FILE): with open(HISTORY_FILE, "r") as f: return set(json.load(f)) return set() def save_history(history): with open(HISTORY_FILE, "w") as f: json.dump(list(history), f) def get_content_hash(item): return hashlib.md5(item["title"].encode()).hexdigest() def filter_seen(items, history): new_items = [] for item in items: h = get_content_hash(item) if h not in history: new_items.append(item) history.add(h) return new_items, history

这个逻辑加上之后，日报的重复率大幅下降。唯一需要注意的是历史文件会越来越大，建议定期清理，比如只保留最近 30 天的记录。

6.3 微信消息太长被截断

企业微信的文本消息有长度限制，超过部分会被截断。我一开始没注意，有几次日报内容比较长，后半部分直接没了。后来我在推送前加了一个长度检查，如果超过 2000 字符，就自动拆分成两条消息发送。

def split_message(content, max_len=2000): if len(content) <= max_len: return [content] parts = [] while content: parts.append(content[:max_len]) content = content[max_len:] return parts

拆分的时候尽量在段落边界处切，避免把一句话切成两半。这个细节虽然小，但体验差别很大。

6.4 AI 摘要质量不稳定

有时候 AI 生成的摘要很精准，有时候又很敷衍。排查下来发现，问题出在输入内容的格式上。如果抓到的内容本身就很乱（比如 HTML 标签没清理干净），AI 的处理效果就会打折扣。

解决办法是在把内容喂给 AI 之前，先做一次清洗：去掉 HTML 标签、压缩多余空白、截断过长的正文（只保留前 500 字用于摘要）。这一步做完之后，摘要质量的稳定性明显提升。

import re def clean_text(raw): # 去掉 HTML 标签 text = re.sub(r'<[^>]+>', '', raw) # 压缩空白 text = re.sub(r'\s+', ' ', text) # 截断 return text.strip()[:500]

7. 稳定运行一个月后的经验沉淀

7.1 监控和告警不能省

自动化流程最怕的是"悄悄挂了你还不知道"。我加了一个简单的监控：每次日报推送成功后，往一个日志文件里写一条记录。然后每天下午两点检查一次，如果当天没有推送记录，就通过另一个通道给自己发个提醒。

这个"另一个通道"很关键，不能跟日报用同一个通道，否则日报通道挂了提醒也发不出去。我用的是邮件提醒，虽然土但可靠。

7.2 定期回顾日报质量

我每周会花十分钟翻一下这周的日报，看看有没有明显的问题：是不是某个源一直没内容、是不是摘要越来越水、是不是重复率又上来了。这种定期回顾能帮你及时发现退化，在问题变大之前修掉。

7.3 不要过度优化

我一开始总想着把日报做得更智能，比如加自动分类、加情感分析、加趋势预测。后来发现这些花哨的功能实际使用率极低，反而增加了维护成本。现在的版本就是简单的抓取、筛选、摘要、推送，稳定跑了几个月，够用了。

提示：自动化工具的价值在于"稳定地帮你省时间"，而不是"展示技术有多复杂"。先把核心链路跑稳，再考虑锦上添花。

7.4 关于 WorkBuddy 规则设置的一个心得

如果你想让 WorkBuddy 对所有任务都遵循某些规则（比如输出格式、语气、字数限制），可以在它的全局配置里设定。我设了三条：输出用中文、摘要不超过 50 字、不确定的内容直接丢弃。这三条规则一设，后面所有 Skill 的输出都自动遵循，省了很多重复配置的功夫。

具体操作是在 WorkBuddy 的设置里找到"全局规则"或类似的入口，把规则写成自然语言就行。它会在每次执行任务时把这些规则作为系统提示的一部分。这个功能很多人不知道，但用起来确实方便。

整套流程跑下来，我每天早上花在信息收集上的时间从二十分钟降到了五分钟以内，而且因为日报是结构化的，阅读效率也高了不少。如果你也在用 WorkBuddy 或者类似的工具，强烈建议试试这个思路。核心就是三件事：定好时间、选好推送通道、把提示词调稳。剩下的就是让它自己跑，你该干嘛干嘛。