1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是泡茶而是打开各种窗口项目群、邮件、任务看板、代码仓库通知、还有几个 AI 工具的对话记录。信息散落在七八个地方光是“今天该干什么”这个判断就要花掉十几分钟。我试过用待办清单也试过用日历提醒但问题在于信息不会自动汇总汇总了也不会自动提炼提炼了也不会自动送到我眼前。WorkBuddy 这个工具我最初是把它当成一个“AI 助手聚合器”来用的。它能把 DeepSeek 这类模型的调用、任务编排、定时触发串起来形成一个轻量的自动化流水线。但用了一段时间后我发现真正高频的需求不是“我主动去问 AI”而是“AI 在固定时间把结果推给我”。换句话说我需要的是一个闹钟而不是一个对话框。于是就有了这个项目每天上午十点半WorkBuddy 自动跑一遍我预设的数据源调用 DeepSeek 生成一份结构化的 AI 日报然后通过微信推送到我的手机上。整个过程不需要我点任何按钮也不需要我打开任何网页。十点半这个时间点是我反复测试后定下来的——太早数据源还没更新完太晚上午的决策窗口就错过了。十点半刚好卡在“信息已经沉淀、但还没到午饭前冲刺”的节点上。这篇文章适合两类人看一类是已经装了 WorkBuddy 但只把它当聊天窗口用的朋友另一类是想用 AI 做自动化推送但不知道从哪下手的朋友。我会把整个链路的搭建过程拆开讲包括 WorkBuddy 的定时配置、DeepSeek 的调用方式、微信推送的几种可行路径以及我在调试过程中踩过的坑。代码和配置都会给到你可以直接抄作业也可以按自己的需求改。提示本文涉及的自动化推送仅用于个人效率场景所有数据源均为公开或自有数据不涉及任何敏感信息的采集与传输。2. 整体架构拆解从数据源到微信的完整链路2.1 为什么选 WorkBuddy 做调度中心市面上能做定时任务的东西很多Linux 的 crontab、Windows 的任务计划、各种云函数、还有 n8n、Zapier 这类自动化平台。我最后选 WorkBuddy 作为调度中心原因有三个。第一它原生支持 AI 调用。我的日报核心不是“把数据罗列出来”而是“让模型帮我提炼重点”。如果用 crontab 加脚本我还得自己处理 API 请求、重试、超时、结果解析这一整套逻辑。WorkBuddy 把这些封装好了我只需要写清楚“输入什么、让模型做什么、输出什么格式”。第二它的任务编排是可视化的。我可以把“抓取数据”“调用模型”“格式化输出”“推送微信”拆成四个节点每个节点单独调试。哪个环节出问题一眼就能看出来。用纯脚本的话日志混在一起排查起来很痛苦。第三它对 DeepSeek 的支持比较顺。我试过在别的平台接 DeepSeek要么是接口格式对不上要么是流式输出处理麻烦。WorkBuddy 里直接选模型、填 Key 就能跑省掉了很多胶水代码。当然WorkBuddy 也不是没有缺点。它的定时精度是分钟级不支持秒级触发免费版的任务执行时长有限制如果数据源太多、模型响应太慢可能会超时。所以我在设计的时候刻意控制了数据源的规模把“重”的处理放在本地预处理阶段WorkBuddy 只负责“轻量汇总模型提炼推送”。2.2 数据源的选择与预处理日报的内容质量七成取决于数据源。我一开始贪多把 RSS、邮件、GitHub 通知、天气、待办全塞进去结果模型输出了一大段废话重点反而被淹没了。后来我做了减法只保留三类数据项目动态我关注的几个代码仓库的提交记录和 Issue 更新通过公开 API 拉取。行业资讯三到五个垂直领域的 RSS 源每天新增内容控制在二十条以内。个人待办从我的任务管理工具里导出当天到期的条目用 CSV 格式读取。这三类数据有一个共同点结构化程度高噪声少。RSS 和 API 返回的都是带标题、时间、摘要的条目待办本身就是结构化的。这样模型在提炼的时候不需要花精力去“理解格式”而是直接做“归纳和排序”。预处理这一步我放在本地做用一个 Python 脚本跑。脚本干三件事拉取数据、去重、截断。去重是按标题和链接做的截断是限制每条摘要不超过 200 字。为什么要截断因为 DeepSeek 的上下文窗口虽然大但输入越长响应越慢而且容易“跑偏”。把每条数据压到 200 字以内整体输入控制在 3000 字左右模型输出的稳定性和速度都明显更好。# 预处理脚本的核心逻辑简化版 import feedparser import requests import csv from datetime import datetime def fetch_rss(url, limit10): feed feedparser.parse(url) items [] for entry in feed.entries[:limit]: items.append({ title: entry.title, link: entry.link, summary: entry.summary[:200] }) return items def fetch_github_events(repo, token): headers {Authorization: ftoken {token}} url fhttps://api.github.com/repos/{repo}/events resp requests.get(url, headersheaders) events [] for event in resp.json()[:10]: events.append({ type: event[type], actor: event[actor][login], repo: repo, time: event[created_at] }) return events def load_todos(csv_path): todos [] with open(csv_path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: if row[due_date] datetime.now().strftime(%Y-%m-%d): todos.append(row) return todos这个脚本跑完之后会把所有数据合并成一个 JSON 文件存到本地。WorkBuddy 的定时任务只需要读取这个文件不需要自己去拉数据。这样做的好处是数据抓取和 AI 生成解耦了。如果某个 RSS 源挂了或者 GitHub API 限流了不会影响 WorkBuddy 的任务执行我只需要重新跑一遍预处理脚本就行。2.3 微信推送的三种可行路径把消息送进微信是整条链路里最“折腾”的一环。我前后试了三种方案各有优劣这里把实测结果摊开讲。方案一企业微信机器人。这是最稳的路径。企业微信的群机器人支持 Webhook往一个 URL 发 POST 请求就能推消息支持 Markdown 格式而且没有频率限制的烦恼。缺点是消息落在企业微信里不是个人微信。如果你平时企业微信和微信是分开的这个方案就不太顺手。方案二微信文件传输助手。这个思路是通过自动化工具模拟“给自己发消息”。我试过用 Windows 的 UI 自动化工具去操作微信客户端找到文件传输助手的窗口把日报内容粘贴进去再发送。实测下来稳定性很差。微信客户端的界面会随版本更新变化控件定位经常失效而且电脑锁屏或者微信最小化的时候自动化就断了。方案三微信小程序 服务号模板消息。这个方案最“正规”但门槛也最高。你需要注册一个服务号配置模板消息然后通过服务号的接口把日报推给关注者。优点是消息直接出现在微信聊天列表里体验最好缺点是需要备案、需要服务器、需要处理 access_token 的刷新。如果你只是个人用不想折腾这些这个方案可以直接跳过。我最后选的是方案一的企业微信机器人然后在手机微信里把企业微信的消息通知打开。这样日报会以通知的形式出现在手机锁屏上点开就能看。虽然多了一层跳转但胜在稳定、零维护。注意无论选哪种推送方案都不要在消息里包含任何个人隐私数据。日报的内容应该是“可公开的摘要”而不是“原始数据”。3. WorkBuddy 定时任务的配置细节3.1 任务触发器的参数怎么填WorkBuddy 的定时任务配置界面里有几个参数需要仔细填。我拿我的实际配置来举例。触发时间我填的是30 10 * * *这是标准的 cron 表达式意思是每天上午 10:30 触发。这里有个坑WorkBuddy 的时区默认是 UTC如果你在中国需要手动改成 UTC8否则任务会在下午六点半才跑。我一开始没注意等了三天才发现日报总是傍晚才到。任务超时默认是 60 秒我改成了 180 秒。因为 DeepSeek 生成 3000 字左右的输入响应时间通常在 20 到 40 秒之间加上网络波动60 秒有时候会卡在边缘。给到 180 秒留足余量。重试策略我设的是“失败后重试 2 次间隔 30 秒”。这个策略救过我几次——有一次 DeepSeek 的 API 返回了 503第一次失败第二次重试就成功了。如果不设重试那天的日报就断了。并发控制WorkBuddy 允许同一个任务并行执行但我把它关掉了。因为我的预处理脚本会写同一个 JSON 文件如果两个任务同时跑可能会读到写了一半的文件。关掉并发之后任务串行执行虽然慢一点但数据一致性有保障。3.2 调用 DeepSeek 的提示词设计提示词是日报质量的“命门”。我前后改了十几版最后稳定下来的结构是这样的你是一个信息提炼助手。请根据以下数据生成一份简洁的日报。 要求 1. 分成三个板块项目动态、行业资讯、今日待办。 2. 每个板块用无序列表每条不超过两句话。 3. 项目动态里优先列出有代码提交或 Issue 关闭的条目。 4. 行业资讯里只保留与“自动化”“AI 工具”“开发效率”相关的条目。 5. 今日待办按优先级排序高优先级的放前面。 6. 最后用一句话总结今天的重点。 数据如下 {data}这个提示词有几个关键点。第一明确输出格式。如果不指定“无序列表”和“不超过两句话”模型会写出一大段散文读起来很累。第二给出筛选规则。“只保留与自动化、AI 工具、开发效率相关的条目”这一句让模型帮我做了第一层过滤省掉了我自己筛的时间。第三要求总结。最后那句话是我每天最先看的它相当于一个“一句话摘要”让我在三十秒内抓住重点。实测下来DeepSeek 对这个提示词的响应很稳定输出格式基本不会跑偏。偶尔会有条目超过两句话的情况但整体可读性没问题。3.3 输出格式化与微信消息组装DeepSeek 返回的是纯文本但企业微信机器人需要的是 Markdown 格式的 JSON。所以中间需要一个“格式化”节点把模型输出转成机器人能识别的结构。import json import requests def send_to_wecom(content, webhook_url): headers {Content-Type: application/json} payload { msgtype: markdown, markdown: { content: content } } resp requests.post(webhook_url, headersheaders, datajson.dumps(payload)) return resp.status_code这里有个细节企业微信的 Markdown 不支持所有语法比如表格就不行但支持标题、加粗、列表、链接。所以我在格式化的时候会把模型输出的“板块标题”转成###开头的三级标题把“条目”转成-开头的列表项。这样在手机上看层次很清晰。另外我会在消息末尾加一行“生成时间YYYY-MM-DD HH:MM”方便我判断这份日报是不是最新的。有时候网络延迟日报可能会晚几分钟到有了时间戳就能一眼看出来。4. 实操全流程从零搭建到稳定运行4.1 环境准备与依赖安装我是在一台 Ubuntu 的云服务器上跑预处理脚本的WorkBuddy 的任务配置在网页端完成。如果你没有云服务器用本地电脑也行但要注意本地电脑不能关机否则定时任务不会触发。需要的依赖不多pip install feedparser requestsWorkBuddy 本身不需要安装它是网页端工具注册账号就能用。DeepSeek 的 API Key 需要在 DeepSeek 的开发者后台申请申请完之后在 WorkBuddy 的“模型配置”里填进去。企业微信机器人的 Webhook URL 获取方式在企业微信里建一个群群设置里找到“群机器人”添加一个机器人复制它的 Webhook 地址。这个地址就是推送的入口。4.2 预处理脚本的定时执行预处理脚本我设的是每天早上十点跑比 WorkBuddy 的任务早半小时。这样十点半的时候JSON 文件已经准备好了。在 Ubuntu 上我用 crontab 来定时# 每天早上 10:00 跑预处理脚本 0 10 * * * /usr/bin/python3 /home/user/preprocess.py /home/user/preprocess.log 21日志我保留着方便排查问题。有一次 RSS 源返回了 403日志里看得很清楚我换了个源就好了。4.3 WorkBuddy 任务的完整配置WorkBuddy 的任务配置分四步第一步选择触发器。选“定时触发”填 cron 表达式30 10 * * *时区选 UTC8。第二步添加“读取文件”节点。把预处理生成的 JSON 文件路径填进去。WorkBuddy 支持从本地文件读取内容也支持从 URL 读取。我用的是本地文件因为数据已经在服务器上了。第三步添加“调用模型”节点。模型选 DeepSeek把前面写的提示词粘贴进去在提示词末尾用{data}占位符引用上一步的输出。温度参数我设的是 0.3因为日报需要稳定、可预测的输出不需要太多“创意”。第四步添加“HTTP 请求”节点。方法选 POSTURL 填企业微信机器人的 Webhook 地址Body 里用上一步的输出组装成 Markdown 格式的 JSON。配置完之后点“测试运行”看看整条链路能不能跑通。我第一次测试的时候模型输出里带了 Markdown 的代码块标记导致企业微信显示异常。后来在格式化节点里加了一个“去除代码块标记”的处理就正常了。4.4 实测效果与调整记录稳定运行两周后我记录了一些数据指标数值平均生成耗时35 秒成功率93%14 天里失败 1 次日报平均字数480 字我最常看的板块今日待办失败的那一次是因为 DeepSeek 的 API 返回了超时重试两次后仍然失败。我在 WorkBuddy 里加了一个“失败通知”节点如果任务失败就通过另一个 Webhook 给我发一条告警消息。这样我不会“以为日报没生成是因为没数据”而是知道“任务挂了需要手动处理”。调整方面我做过两次比较大的改动。一次是把“行业资讯”的筛选规则从“与自动化相关”改成“与自动化、AI 工具、开发效率相关”因为原来的范围太窄有时候一条都筛不出来。另一次是把日报的生成时间从十点改到十点半因为十点的时候有些 RSS 源还没更新完日报里会缺当天的内容。5. 常见问题与排查技巧实录5.1 任务不触发怎么办这是最常见的问题。排查顺序是这样的先看 WorkBuddy 的任务日志确认任务有没有被调度。如果日志里没有记录说明触发器配置有问题。检查 cron 表达式和时区特别是时区很多人栽在这里。如果日志里有“任务开始”但没有“任务完成”说明任务执行到一半卡住了。这时候看超时设置把超时时间调大。如果还是卡住看是不是某个节点的输入为空——比如预处理脚本没跑JSON 文件不存在WorkBuddy 读取文件时就会一直等待。如果日志里显示“任务成功”但微信没收到消息那就是推送节点的问题。检查 Webhook URL 有没有过期企业微信机器人的 Webhook 在群解散或者机器人被移除后会失效。5.2 模型输出格式跑偏怎么修DeepSeek 大部分时候很听话但偶尔会“自由发挥”。我遇到过三种跑偏情况第一种输出里带了“好的以下是您的日报”这种开场白。解决办法是在提示词里加一句“直接输出日报内容不要任何开场白和结束语”。第二种板块顺序乱了。解决办法是在提示词里明确“严格按照项目动态、行业资讯、今日待办的顺序输出”。第三种条目太长。解决办法是在提示词里加“每条不超过 50 字”比“不超过两句话”更精确。如果改了提示词还是不稳定可以在格式化节点里加一层“后处理”用正则表达式把不符合格式的行过滤掉。但这是下策优先还是调提示词。5.3 微信推送被限流或屏蔽企业微信机器人有频率限制每分钟最多发 20 条消息。日报一天只发一条正常不会触发限流。但如果你在调试的时候频繁测试可能会被临时限制。等几分钟再试就好。另一个坑是消息内容里如果有特殊字符比如或企业微信可能会解析异常。解决办法是在格式化的时候做 HTML 转义把转成lt;转成gt;。还有一个情况是消息太长企业微信的 Markdown 消息有长度限制好像是 4096 字节。我的日报一般在 500 字左右远没到限制。但如果你把原始数据全塞进去可能会超。解决办法就是在预处理阶段截断控制输入长度。5.4 常见问题速查表现象可能原因解决办法任务不触发时区错误改成 UTC8任务卡住输入文件不存在检查预处理脚本是否执行微信收不到Webhook 失效重新生成机器人地址输出格式乱提示词不明确加格式约束和示例消息被截断内容超长预处理阶段截断模型响应慢输入太长压缩数据源控制 3000 字以内提示每次修改配置后先点“测试运行”验证不要直接等定时触发。测试运行能立刻看到结果省时间。6. 这套方案还能怎么扩展跑通之后我陆续加了一些小功能。比如在日报末尾加一个“昨日回顾”把前一天没完成的待办自动带过来。再比如加一个“本周趋势”统计一周内项目动态的数量变化用简单的文字描述“本周提交比上周多了 30%”。如果你想让日报更“聪明”可以试试在提示词里加一句“如果某个板块没有内容就写‘今日无更新’不要编造”。这个约束能防止模型在数据为空的时候胡编乱造。另一个扩展方向是把推送渠道从企业微信扩展到邮件或者 Telegram。WorkBuddy 的 HTTP 请求节点是通用的只要目标服务有 Webhook 或者 API就能接进去。我试过接邮件用 SMTP 发效果也不错但邮件的阅读体验不如微信即时。最后分享一个小技巧如果你觉得每天十点半太固定可以把 cron 表达式改成30 10 * * 1-5这样就只在工作日推送周末不打扰。我用了这个配置之后周末的手机清净了很多。