WorkBuddy+DeepSeek+微信：搭建每日AI日报自动化推送系统

1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”每天早上到工位第一件事不是泡茶而是打开各种信息源项目群里的讨论、订阅的技术博客、几个固定的行业资讯站还有自己关注的几个开源仓库的更新。一圈刷下来二十分钟没了而且信息是碎的——今天看到一条模型更新的消息明天可能就忘了它跟手头哪个项目有关。这种“手动聚合”的活儿本质上就是重复劳动而且人脑在早上刚开机的时候处理效率并不高。我想要的其实很简单每天上午十点半一份已经整理好的 AI 日报自动出现在微信里。不用我主动去问不用我打开任何 App它就像闹钟一样准时。这个需求听起来不复杂但真要做起来涉及几个关键环节谁来抓信息、谁来整理、谁来推送、怎么保证每天准时触发。WorkBuddy 在这个链路里扮演的是“调度中枢”的角色它负责把定时触发、任务执行和消息推送串起来。这篇文章适合两类人看。一类是已经用过 WorkBuddy 或者类似自动化工具但还没把它跟微信生态打通的另一类是听说过 AI 日报、想自己搭一套但不知道从哪下手的。我会把整个搭建过程拆开讲包括为什么选这个方案、每个环节的坑在哪、参数怎么调以及我实测下来哪些做法是稳的、哪些是花架子。核心关键词就几个WorkBuddy、AI、微信、自动化、DeepSeek整篇内容都围绕这几个词展开。先说结论这套方案跑通之后我每天早上十点半准时收到一份结构化的日报包含模型动态、工具更新、值得看的文章摘要以及一条“今日建议关注”的提示。整个过程不需要我干预唯一要做的就是偶尔调整一下信息源的权重。2. 拆解这条自动化链路从触发到落地的四个环节2.1 定时触发为什么选十点半而不是更早时间点的选择是有讲究的。我试过早上八点推送结果发现那个时间段我还在通勤或者刚坐下根本没心思看。也试过中午十二点但那时候信息已经积压了一上午日报的“新鲜度”下降了。十点半这个时间点是我实测下来最舒服的早上的紧急事务已经处理得差不多离午饭还有一段完整的时间可以静下心来看一份整理好的内容。在 WorkBuddy 里设置定时触发核心是 cron 表达式的配置。如果你不熟悉 cron可以把它理解成一个“闹钟语法”用五个或六个字段来描述“什么时候执行”。比如每天上午十点半对应的表达式是30 10 * * *这五个字段分别代表分钟、小时、日、月、星期。30 10 * * *的意思就是“每天十点三十分”。如果你只想在工作日推送可以改成30 10 * * 1-5这样周六周日就不会打扰你。注意WorkBuddy 的定时任务默认使用服务器时区。如果你的服务器是 UTC 时间而你在东八区那30 10 * * *实际会在北京时间下午六点半触发。我踩过这个坑第一次配置完等了一天没收到消息后来才发现是时区没改。解决办法是在任务配置里显式指定时区或者把 cron 表达式换算成 UTC 时间。2.2 信息抓取日报的“原料”从哪来日报的质量取决于原料的质量。我一开始贪多塞了十几个信息源进去结果每天生成的日报又长又杂反而增加了阅读负担。后来我做了减法只保留三类来源模型与工具官方动态比如 DeepSeek 的 API 更新日志、常用开源库的 release notes。这类信息时效性强错过可能影响手头的开发计划。技术社区的高赞讨论筛选过去 24 小时内热度上升最快的几个话题取摘要和链接。我自己的待办与关注列表从笔记工具里同步过来的“今天需要跟进的事项”让日报跟我的实际工作挂钩。抓取方式上能用 API 的优先用 API没有 API 的就用 RSS。RSS 虽然老但胜在稳定、结构化好解析。实在没有 API 也没有 RSS 的才考虑用页面解析但这种方式维护成本高对方页面一改版就得跟着改。import feedparser import requests def fetch_rss(url): feed feedparser.parse(url) items [] for entry in feed.entries[:5]: items.append({ title: entry.title, link: entry.link, summary: entry.get(summary, )[:200] }) return items def fetch_api(endpoint, headers): resp requests.get(endpoint, headersheaders, timeout10) if resp.status_code 200: return resp.json() return None这段代码没什么特别的但有一个细节值得说timeout10一定要加。我遇到过某个源响应极慢导致整个抓取任务卡住后面的推送全部延迟。加了超时之后即使某个源挂了也不会影响整体流程。2.3 内容整理DeepSeek 在中间做了什么抓回来的原始信息是散的直接推送到微信里阅读体验很差。这时候需要一层“整理”把多条信息压缩成一段可读的摘要并且按重要性排序。我用的是 DeepSeek 的 API 来做这件事。具体做法是把抓取到的标题和摘要拼成一个 prompt让模型输出一份结构化的日报。prompt 的设计很关键我试过几种写法最后稳定下来的版本大概是这样的prompt f 你是一个技术日报编辑。请根据以下原始信息生成一份简洁的 AI 日报。 要求 1. 按重要性排序最重要的放在最前面。 2. 每条信息用一句话概括不超过 50 字。 3. 如果某条信息与模型更新、工具发布相关标注出来。 4. 最后给出一条“今日建议关注”说明为什么值得看。 原始信息 {raw_content} 这里有个经验不要让模型自由发挥。早期我给的指令太宽松结果模型加了很多“综上所述”“值得关注”之类的废话日报变得又臭又长。后来我把输出格式卡死要求每条不超过 50 字整体控制在 500 字以内可读性立刻上来了。另外DeepSeek 的 API 调用要注意 token 消耗。如果原始信息很多可以先做一轮本地过滤把明显不相关的条目去掉再送给模型。这样既省钱又减少模型“分心”的概率。2.4 推送落地怎么把消息送进微信这是整个链路里最容易被卡住的一环。微信不像 Slack 或 Telegram 那样有开放的机器人 API个人开发者想往微信里推消息通常有几条路方式优点缺点适用场景企业微信机器人配置简单稳定需要企业微信账号个人或小团队服务号模板消息可直接推到微信需要认证服务号有资质门槛有公众号的开发者微信小程序订阅消息用户体验好需要用户主动订阅有次数限制面向 C 端产品第三方推送服务接入快稳定性和安全性参差不齐临时方案我最终选的是企业微信机器人。原因很简单它本质上是一个 webhook你往一个固定的 URL 发 POST 请求消息就会出现在企业微信的群里。如果你把企业微信和微信绑定消息还能同步到微信上。配置过程大概是这样在企业微信里创建一个群群成员可以只有你自己。在群设置里找到“群机器人”添加一个机器人。复制机器人的 webhook 地址格式类似https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxxx。在 WorkBuddy 的任务里用 HTTP 请求节点往这个地址发消息。import requests import json def send_to_wechat(webhook_url, content): headers {Content-Type: application/json} payload { msgtype: markdown, markdown: { content: content } } resp requests.post(webhook_url, headersheaders, datajson.dumps(payload)) return resp.status_code提示企业微信机器人的消息频率有限制每分钟最多 20 条。对于日报这种一天一条的场景完全够用。但如果你打算做实时告警就要注意这个限制。3. WorkBuddy 任务配置的实操细节与参数调优3.1 任务编排把四个环节串成一条流水线WorkBuddy 的任务编排界面支持把多个步骤串起来前一步的输出可以作为后一步的输入。我的日报任务大概长这样触发节点cron 定时每天 10:30。抓取节点并行请求多个信息源汇总结果。整理节点调用 DeepSeek API生成日报文本。推送节点发送到企业微信 webhook。日志节点把本次执行的结果写入本地文件方便回溯。这里有个设计上的取舍抓取节点要不要并行我一开始用的是串行结果发现如果某个源响应慢整体时间会被拉长。后来改成并行之后总耗时从平均 40 秒降到了 12 秒左右。WorkBuddy 支持并行分支配置起来也不复杂把多个抓取步骤放在同一个并行组里就行。但并行也有代价如果某个源挂了错误处理会麻烦一些。我的做法是给每个抓取步骤单独设置超时和重试次数并且允许“部分失败”——也就是说即使有一个源没抓到其他源的结果照样往下走不影响整体流程。3.2 错误处理日报没收到时怎么排查自动化任务最怕的就是“静默失败”——你以为它在跑其实早就挂了。我遇到过几次十点半没收到日报的情况排查下来原因各不相同时区问题前面提过服务器 UTC 时间导致触发时间偏移。API 额度耗尽DeepSeek 的免费额度用完之后整理节点直接报错。webhook 失效企业微信机器人被移除或者 key 被重置。网络抖动某个信息源临时不可达导致抓取节点超时。为了快速定位问题我在任务里加了一个“执行日志”节点每次运行都把关键信息写到一个本地文件里包括触发时间、各节点耗时、抓取到的条目数、API 返回状态、推送结果。这样一旦出问题直接看日志就能知道是哪一环挂了。# 日志文件示例 2025-01-15 10:30:01 | trigger | cron fired 2025-01-15 10:30:03 | fetch | rss_source_a: 5 items 2025-01-15 10:30:05 | fetch | api_source_b: 3 items 2025-01-15 10:30:08 | fetch | rss_source_c: timeout, skipped 2025-01-15 10:30:12 | summarize | deepseek api: 200 OK, tokens: 1200 2025-01-15 10:30:13 | push | wechat webhook: 200 OK注意日志文件要定期清理不然跑几个月之后会占不少空间。我一般设置保留最近 30 天的日志更早的自动删除。3.3 内容质量调优怎么让日报“说人话”日报生成出来之后我自己会读一遍看看有没有需要调整的地方。早期版本有几个典型问题信息密度太低每条都是“某某发布了某某更新”但没有说这个更新意味着什么。排序不合理把一些边角料信息放在了前面真正重要的反而沉底了。语气太机械读起来像机器翻译没有“人味”。针对这些问题我做了几轮 prompt 调优。核心思路是给模型更明确的“编辑角色”和“读者画像”。比如在 prompt 里加上“你是一个有五年经验的技术编辑读者是每天需要快速了解 AI 动态的开发者。请用简洁、直接的语言避免套话。”这样模型输出的内容会明显更贴近真实阅读习惯。另外我还会在 prompt 里给几个“好例子”和“坏例子”让模型知道什么样的输出是合格的。这种做法在少样本学习里很常见实测下来对输出质量的提升很明显。4. 实测中踩过的坑与稳定运行的经验4.1 微信推送的“隐形门槛”企业微信机器人虽然配置简单但有几个细节容易忽略。第一webhook 地址里的 key 是敏感信息不要直接写在代码里更不要提交到公开仓库。我的做法是把它放在环境变量里任务配置时通过变量引用。第二企业微信机器人默认只支持文本和 markdown 两种消息类型。markdown 的语法支持有限比如不支持表格、不支持图片嵌入。如果你想让日报看起来更丰富可以用 markdown 的标题和列表但别指望能做出复杂的排版。第三消息长度有限制。markdown 类型的消息最长 4096 字节超过会被截断。我的日报控制在 500 字以内所以没遇到过这个问题但如果你打算推送长文就要考虑分段发送。4.2 DeepSeek API 的调用节奏DeepSeek 的 API 性价比很高但有几个使用上的细节值得注意。首先是 rate limit免费额度和付费额度的限制不同如果你在短时间内频繁调用可能会触发限流。我的日报任务一天只调用一次所以没遇到这个问题但如果你打算做实时摘要就要考虑加一个队列或者退避重试。其次是 token 计算。DeepSeek 的计费是按输入和输出的 token 总数来的。如果你的原始信息很长输入 token 会很大。我的做法是在本地先做一轮过滤把明显不相关的条目去掉只把最相关的 10 到 15 条送给模型。这样既省钱又提高输出质量。# 本地过滤示例只保留包含关键词的条目 keywords [模型, 更新, 发布, 开源, API, 工具] filtered [item for item in items if any(kw in item[title] for kw in keywords)]4.3 让日报“活”起来的几个小技巧跑了一段时间之后我发现日报如果每天格式完全一样读起来会腻。后来我加了几个小变化随机排序在保证重要信息靠前的前提下次要信息随机排列每天看起来略有不同。一句话点评让模型在每条信息后面加一句简短的点评比如“这个更新对做 RAG 的同学影响较大”。周末特辑周六周日的日报改成“本周回顾”汇总过去七天的重点而不是只报当天。这些改动都不复杂但让日报从“机器输出”变成了“有人味的内容”。我甚至收到过同事的反馈说看到我转发的日报之后也跟着搭了一套。5. 从日报到更广的自动化这套思路还能怎么用5.1 把“闹钟”扩展到其他场景日报只是这套链路的一个应用。同样的结构——定时触发、抓取、整理、推送——可以套用到很多场景每日站会提醒早上九点推送当天待办和昨日进展。竞品动态监控定时抓取竞品官网和社交账号整理成简报。个人知识库更新把每天读到的好文章自动归档到笔记工具。运维告警聚合把多个监控系统的告警汇总成一条消息避免被刷屏。关键是把“触发、抓取、整理、推送”这四个环节抽象出来每个环节都可以替换成不同的实现。比如推送环节除了企业微信还可以换成邮件、Slack、Telegram甚至短信。5.2 关于 WorkBuddy 和 CodeBuddy 的配合如果你同时用 WorkBuddy 和 CodeBuddy可以把两者串起来。CodeBuddy 负责代码相关的任务比如自动跑测试、生成代码摘要WorkBuddy 负责调度和推送。我试过让 CodeBuddy 每天跑一次项目的单元测试把结果交给 WorkBuddy 整理成报告再推送到微信。这样即使我不在电脑前也能随时掌握项目状态。5.3 一些值得关注的扩展方向这套方案目前跑得挺稳但还有几个方向可以继续优化。一是增加“反馈闭环”比如我在微信里回复某个关键词系统能根据回复调整第二天的日报内容。二是引入更细粒度的权限控制如果日报要分享给团队不同角色看到的内容可以不一样。三是把日报数据存下来做趋势分析比如“过去一个月模型更新频率的变化”。这些扩展不一定都要做但思路是通的自动化的价值不在于一步到位而在于持续迭代。先跑通最小闭环再根据实际使用中的痛点逐步优化这样每一步都踩在真实需求上不会为了自动化而自动化。我个人在实际操作中的体会是这套东西最大的门槛不是技术而是“想清楚自己要什么”。信息源选哪些、日报给谁看、推送频率多少这些问题想明白了剩下的就是配置和调试。十点半的闹钟只是一个开始真正有意思的是你开始用自动化的思维去重新审视那些每天重复的事情。