1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”每天早上到工位第一件事不是泡咖啡而是打开各种信息源翻一遍昨天夜里项目群有没有新需求、关注的几个技术社区有没有值得看的更新、手头几个自动化任务跑完没有、有没有新的漏洞披露或者框架版本发布。这套动作熟练之后大概要花二十分钟但问题是它极其消耗注意力——你还没开始干正事脑子已经被一堆碎片信息塞满了。我想要的其实很简单每天上午十点半一份整理好的 AI 日报自动推送到微信里我扫一眼就知道今天该关注什么不用自己去翻。这个需求听起来像是要写一个完整的后端服务但实际拆开看无非是三件事——定时触发、内容聚合、消息推送。而 WorkBuddy 恰好能把这三件事串起来它本身就是一个可以挂载各种 skill 的工作台配合定时任务和微信侧的接收通道整个链路并不复杂。这篇内容适合两类人看一类是已经装了 WorkBuddy、想把它从“手动问答工具”变成“自动化助手”的人另一类是还没用过 WorkBuddy但手头有一堆重复性的信息整理工作想找个轻量方案落地的人。我会把整个搭建过程拆开讲包括为什么选这个时间点、内容从哪来、怎么推、以及我踩过的几个坑。核心关键词就几个WorkBuddy、AI日报、微信小程序、deepseek-v4-flash、自动化后面会围绕它们展开。先说结论整套方案跑通之后我每天早上十点半准时收到一条微信消息里面是结构化的日报包含摘要、要点和原文链接。整个链路的维护成本极低唯一需要偶尔调整的就是内容源的筛选规则。下面从设计思路开始讲。2. 拆解需求一份“能看”的日报到底需要什么2.1 时间点为什么选十点半而不是更早很多人第一反应是“日报应该早上七八点推”但我实测下来十点半才是最优解。原因有三个第一太早推送的时候我还没进入工作状态消息容易被划掉第二很多信息源在早晨六七点并没有完成当天的更新尤其是海外技术社区时差导致内容往往在上午九点之后才陆续出来第三十点半正好是我处理完第一波紧急事务、准备规划当天工作的节点这时候一份日报进来能直接影响我接下来几个小时的优先级排序。这个时间点不是拍脑袋定的你可以根据自己的作息调整但建议避开“刚起床”和“午休”两个时段推送效果会差很多。WorkBuddy 的定时能力支持 cron 表达式改时间就是改一个字段的事。2.2 日报的内容结构摘要、要点、链接三层一份能用的日报不能是一堆链接的堆砌。我最终定下来的结构是三层顶部摘要三到五句话概括今天最值得关注的事情由模型生成控制在 150 字以内。分类要点按主题分组每条包含一句话说明和原文链接方便快速扫读。底部备注标注本次日报的数据来源数量和生成时间方便判断信息新鲜度。这个结构的好处是即使我只花十秒钟扫一眼摘要也能抓住重点如果对某条感兴趣直接点链接深入。摘要部分我用的模型是deepseek-v4-flash选它的理由后面会详细说。2.3 为什么走微信而不是邮件或其它渠道推送渠道的选择上我对比过几种方案。邮件的问题是打开率低而且手机上翻邮件体验很差企业协作工具虽然方便但需要额外配置机器人链路更长而微信是我每天打开频率最高的应用消息触达几乎无延迟。这里说的“送进微信”有两种实现路径一种是通过微信小程序的消息订阅能力另一种是通过服务号模板消息。考虑到我本身就在做微信小程序相关的开发最终选了小程序订阅消息这条路配置相对可控也不需要额外的服务器域名备案折腾。提示微信小程序订阅消息需要用户主动授权且每次授权只能推送有限条数。如果你打算长期每天推送需要在用户授权时选择“总是保持以上选择”否则会频繁失效。这一点在开发文档里有说明但很容易被忽略。3. 内容从哪来日报的数据源筛选与聚合逻辑3.1 数据源的三个层次必看、可选、备用日报的质量取决于数据源的质量。我把自己关注的信息源分成三层层次类型处理方式更新频率必看官方博客、版本发布页全量抓取不筛选每日检查可选技术社区热榜、行业资讯按关键词过滤每日检查备用社交媒体讨论、论坛帖按热度阈值筛选隔日检查必看层的内容不管多少都要进日报因为漏掉一个版本更新可能意味着错过一个重要特性。可选层用关键词过滤比如我关注的关键词包括“自动化”“小程序”“模型更新”等命中才收录。备用层则设置一个热度阈值只有讨论量超过一定数量的内容才会进入候选池。3.2 用 WorkBuddy 的 skill 机制做内容抓取WorkBuddy 的 skill 机制是这套方案的核心。你可以把它理解成一个个可插拔的能力模块每个 skill 负责一类任务。我配置了三个 skill抓取 skill负责从各个数据源拉取原始内容输出统一的 JSON 结构。清洗 skill去重、去广告、提取正文把原始内容变成干净文本。摘要 skill调用模型生成摘要和分类要点。这三个 skill 串起来就是一个完整的数据流水线。关键在于第二步的清洗很多抓取工具拿到的是带大量 HTML 标签的原始页面直接丢给模型会浪费 token 且影响摘要质量。我在清洗 skill 里加了一个简单的正文提取逻辑用正则去掉脚本和样式标签再按段落切分效果比直接丢原始 HTML 好很多。3.3 去重和排序让日报不重复、不遗漏去重是日报场景里最容易被低估的环节。同一个事件可能被多个源报道如果不去重日报里会出现三条几乎一样的内容。我的做法是对每条内容的标题做归一化处理去掉标点、转小写然后计算相似度超过阈值的只保留来源最权威的那一条。排序则按“必看优先、时间次之、热度再次”的规则。必看层的内容永远排在最前面同一层内按发布时间倒序这样保证最新鲜的信息在最上面。4. 定时触发与消息推送的完整链路4.1 WorkBuddy 的定时任务配置WorkBuddy 支持通过配置文件定义定时任务我用的是标准的 cron 表达式。每天上午十点半触发对应的表达式是30 10 * * *这个配置写在 WorkBuddy 的任务定义文件里格式大致如下{ name: daily-ai-report, schedule: 30 10 * * *, skill: report-pipeline, output: wechat-miniprogram }这里skill字段指向我前面配置的那条流水线output指定推送通道。WorkBuddy 会在触发时间自动执行 skill 链并把结果交给输出模块。注意cron 表达式使用的是系统时区如果你的服务器时区和本地不一致需要先确认时区设置否则会出现“明明设了十点半却十一点才推”的情况。我一开始就踩了这个坑排查了半天才发现是时区问题。4.2 微信小程序侧的接收设计微信小程序接收消息依赖订阅消息能力。整体流程是用户在小程序内点击“订阅日报”按钮授权接收订阅消息后端在日报生成后调用微信提供的接口把消息推送给已授权的用户。这里有几个关键点模板选择订阅消息需要使用微信提供的模板我选的是“服务通知”类模板字段包括标题、时间和内容摘要。字段映射日报的摘要映射到模板的“内容”字段生成时间映射到“时间”字段标题固定为“今日 AI 日报”。长度限制订阅消息的字段有长度限制摘要需要截断到规定字符数以内超出部分会被截掉。我在生成摘要时就控制了长度避免推送时被截断。小程序端的代码不复杂核心就是调用wx.requestSubscribeMessage获取授权然后把授权结果上报给后端存储。后端在推送时根据存储的授权状态决定是否发送。4.3 推送失败的重试与降级任何自动化链路都要考虑失败的情况。我遇到过两种失败一种是微信接口返回授权失效另一种是网络超时。对于授权失效处理方式是标记该用户为“需重新授权”并在下次用户打开小程序时提示对于网络超时设置最多三次重试间隔分别为 5 秒、30 秒、120 秒。如果三次都失败降级方案是把日报内容写入本地文件并在下一次成功推送时附带说明。这样至少不会丢数据。5. 模型选型为什么用 deepseek-v4-flash 做摘要5.1 摘要任务对模型的核心要求日报摘要这个任务有几个特点输入长度中等几千字、输出长度短150 字以内、对延迟敏感十点半要准时推、对成本敏感每天都要跑。这就决定了模型选型不能只看效果还要看速度和价格。我对比过几个模型在这个任务上的表现。大参数模型效果确实好但延迟高、成本也高每天跑一次虽然不算贵但长期下来不划算。小参数模型速度快但摘要质量不稳定有时候会漏掉关键信息。5.2 deepseek-v4-flash 的实际表现最终我选了deepseek-v4-flash理由是它在速度和效果之间取得了不错的平衡。实测下来处理一篇 3000 字左右的输入生成 150 字摘要耗时在 2 秒以内完全满足定时任务的时间要求。摘要质量方面它能把关键信息提取出来语言也比较通顺偶尔会有个别措辞不够精准但整体可用。我在 prompt 里做了几件事来提升效果一是明确要求“只输出摘要正文不要任何前缀”二是给出摘要的结构要求先总述再分点三是限制字数。这三条加上之后输出稳定性明显提升。5.3 摘要 prompt 的迭代过程第一版 prompt 很简单就是“请总结以下内容”。结果模型有时候会输出“好的以下是总结”这样的前缀有时候又会输出很长的分析。第二版加了格式约束要求直接输出摘要正文。第三版进一步细化了结构要求先一句话总述再列三到五个要点。经过这三轮迭代输出基本稳定了。这里有个经验prompt 里的约束要具体到可执行。比如“简洁一点”这种描述模型理解不了但“控制在 150 字以内”就很明确。6. 踩过的坑从时区错乱到授权失效6.1 时区问题导致推送时间偏移前面提过我第一次配置定时任务时推送时间是十一点而不是十点半。排查过程是这样的先确认 cron 表达式没写错然后检查 WorkBuddy 的日志发现任务确实是在十一点触发的。最后定位到服务器时区是 UTC而 cron 表达式按 UTC 解释十点半 UTC 对应本地时间就是十一点半。改成服务器本地时区后问题解决。这个坑的教训是任何涉及时间的配置第一件事就是确认时区。6.2 订阅消息授权失效的排查运行了大概两周后有一天没收到日报。检查日志发现微信接口返回了“用户未授权”的错误。原因是微信的订阅消息授权是一次性的用户授权一次只能推送一条除非用户在授权时勾选了“总是保持以上选择”。我一开始没注意这个细节导致授权用完后就不再推送。解决方案是在小程序端引导用户勾选“总是保持”同时在授权失效时通过小程序内的站内信提醒用户重新授权。6.3 内容源改版导致抓取失败还有一个坑是数据源网站改版导致抓取 skill 拿不到内容。这种情况没有太好的预防办法只能加监控如果某次抓取返回的内容数量明显低于历史平均值就触发告警。我在 WorkBuddy 里加了一个简单的检查逻辑连续两次抓取数量异常就发通知给我。7. 让日报更耐看的几个细节优化7.1 摘要里的“人话”程度模型生成的摘要有时候会过于书面化读起来像新闻稿。我在 prompt 里加了一条要求“用口语化的方式表达像在跟同事聊天”。这一条改动之后摘要的可读性明显提升。比如原来会写“某框架发布了新版本引入了多项改进”现在会写“某框架更新了这次加了几个挺实用的功能”。7.2 分类标签的自动生成日报里的内容如果只是平铺读起来会很累。我加了一个自动分类的步骤让模型给每条内容打一个标签比如“版本更新”“行业动态”“工具推荐”等。这样在展示时可以按标签分组扫读效率更高。标签的生成也是在摘要 skill 里完成的一次调用同时输出摘要和标签不增加额外开销。7.3 历史日报的存档与检索每天的日报除了推送还会存档到本地。存档格式是 JSON包含日期、摘要、要点列表和原始链接。这样做的目的是方便后续检索比如我想找“上个月关于某个框架的更新”直接搜存档文件就行。存档还有一个好处是可以做趋势分析比如统计某个关键词出现的频率判断某个技术方向的热度变化。这个功能我还没做但数据已经攒着了后面想加随时可以加。8. 后续可以扩展的方向这套方案跑通之后我陆续加了一些小功能。比如周末的日报会精简一些只保留必看层的内容比如遇到重大版本发布时日报会加一个“重点关注”的标记。这些调整都是在 skill 配置里改几行的事不需要动整体架构。再往远一点想日报的接收方不一定只有我一个人。如果团队里其他人也想看可以把推送列表扩展成多人每个人可以配置自己的关注关键词。WorkBuddy 的 skill 机制支持参数化改起来并不麻烦。我个人在实际操作中的体会是自动化的价值不在于省了多少时间而在于它把一件需要主动想起来的事变成了被动接收的事。以前我经常因为忙而忘记看某些更新现在日报每天准时到扫一眼就行心理负担小了很多。如果你也有类似的信息整理需求这套思路可以直接搬过去用改改数据源和推送渠道就行。