基于WorkBuddy与DeepSeek的AI日报自动化：微信定时推送实战

1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”每天上午十点半我的微信会准时弹出一条消息。不是老板催进度也不是群里有人艾特我而是一份排版整齐的 AI 日报——昨天我关注的几个技术方向有什么新动态、我手头项目的待办有没有卡点、当天值得留意的行业信息全部浓缩在一条消息里。这件事我已经跑了小半年从最初手动复制粘贴到后来用 WorkBuddy 配合自动化流程全权托管中间踩的坑足够写一篇长文。先说清楚这套东西到底是什么。WorkBuddy在这里扮演的是“任务编排中枢”的角色它负责把 DeepSeek 这类大模型的调用、数据的抓取整理、消息的推送这几件事串成一条流水线。AI 日报是最终产物一份由模型根据我预设的关注点自动生成、经过格式化处理的简报。微信是投递渠道因为这是我每天打开频率最高的应用消息送到这里我不需要额外装 App、不需要记着去某个后台看。自动化是灵魂整个流程从触发到送达没有人工干预我要做的只是在前一天晚上把关注方向微调一下。这套方案解决的核心痛点很具体信息过载。做技术的人都有体会每天要跟的东西太多——某个开源项目更新了、某个模型发了新版本、某个工具链出了新玩法。靠人肉刷要么刷不过来要么刷得碎片化看完就忘。我需要的不是“更多信息”而是“经过筛选和归纳的信息”并且最好在我刚坐到工位上、还没被会议打断的那个时间点送到眼前。十点半这个时间是我反复调过的太早前一天晚上的数据还没沉淀完太晚上午的节奏已经被打乱。十点半刚好是处理完紧急邮件、可以喘口气看看方向的窗口。适合谁来参考这套东西三类人。第一类是像我这样的一线开发者或技术负责人需要持续跟踪特定技术栈的动态但没时间做信息聚合。第二类是做运营、产品、投资的朋友需要每天盯某个赛道的变化逻辑完全一样只是关注点从“代码库更新”换成“竞品动作”。第三类是想入门 AI Agent 自动化但不知道从哪下手的人这套流程麻雀虽小五脏俱全涵盖了触发、调用、处理、推送四个环节跑通一遍对理解自动化编排很有帮助。哪怕你完全不懂编程只要愿意照着步骤配置也能把这套东西搭起来。2. 整体架构拆解一条消息背后的四段流水线2.1 从触发到送达数据到底走了哪几步很多人一听“自动化日报”觉得玄乎其实拆开看就是四段流水线每一段各司其职段与段之间用标准接口衔接。我用一个生活化的类比来解释这就像你订了一份早餐外卖。触发环节是“闹钟响了”相当于你下单的动作数据采集是“骑手去店里取餐”把原材料拿到手AI 处理是“厨师加工”把生的变成熟的、把散的变成整的推送是“骑手送到你家门口”最终交付。具体到这套系统第一段是定时触发。WorkBuddy 内置了调度能力我设置了一个每天上午十点半执行的定时任务。这里有个细节值得说触发时间不要设成整点因为整点是各种系统任务的高峰期容易排队延迟。我设成十点半实测下来比十点整稳定得多。第二段是数据采集与预处理从几个预设的信息源拉取原始内容做去重、截断、格式清洗。第三段是模型调用与内容生成把清洗后的素材喂给 DeepSeek用我写好的提示词模板生成日报正文。第四段是消息推送把生成的内容通过微信的接口发到我的对话里。这四段里最容易出问题的是第二段和第三段。数据采集的难点在于信息源格式不统一有的返回 JSON有的返回 HTML有的干脆是一坨纯文本。模型调用的难点在于提示词要足够稳定否则今天生成得像模像样明天就给你胡言乱语。后面我会专门讲这两块的实操细节。2.2 为什么选 WorkBuddy 而不是自己写脚本有人会问这东西用 Python 写个脚本不就完了为什么要用 WorkBuddy我一开始也是这么想的甚至真写过一个版本用定时任务加 requests 库加模型 API跑是能跑但维护成本高得离谱。信息源改个字段名脚本就崩模型 API 换个版本参数就得重调想加个新信息源得改代码重新部署。WorkBuddy 的价值在于它把这些“胶水逻辑”可视化了改信息源、调提示词、换推送渠道都是在界面上点几下的事不用碰代码。更关键的是容错和重试机制。自己写的脚本一旦某一步失败整个流程就断了你得手动去查日志、手动重跑。WorkBuddy 的编排引擎支持节点级重试比如数据采集失败了它会自动重试三次三次都失败才走异常分支给我发一条“今天日报生成失败”的提醒。这个机制在实际运行中救了我很多次尤其是某个信息源临时抽风的时候。还有一个隐性好处是可观测性。自己写脚本想看某一步花了多久、返回了什么得自己打日志。WorkBuddy 每个节点的输入输出都能在界面上看到调试的时候一目了然。我调提示词的那几天就是靠这个功能快速对比不同版本的效果。2.3 微信作为投递渠道的取舍投递渠道的选择其实是个挺重要的决策。我试过邮件、试过飞书、试过钉钉最后回到微信。原因很简单触达率和打开率。邮件我一天可能只看两次飞书和钉钉在工作时间之外基本不打开只有微信是全天候在线的。日报这种东西价值在于“被看到”如果送到一个我三天才看一次的地方那跟没送一样。微信推送有几种实现路径我选的是企业微信应用消息这条路。个人微信没有官方的机器人接口第三方方案要么不稳定要么有合规风险不建议碰。企业微信可以创建一个内部应用拿到 CorpID 和 Secret就能通过接口给自己的账号发消息。这个方案的好处是稳定、官方支持、不需要额外装东西消息直接出现在企业微信的对话列表里。如果你没有企业微信也可以注册一个个人也能注册企业流程不复杂。注意推送渠道的选择要优先考虑“你每天一定会打开的应用”而不是“技术上最酷的方案”。我见过有人费半天劲接了个 fancy 的推送渠道结果自己一周都不看一次纯属自嗨。3. 核心环节实操从零把这条流水线搭起来3.1 环境准备与 WorkBuddy 的基础配置动手之前先把地基打好。你需要准备的东西不多一个 WorkBuddy 账号国际版和国内版功能有差异日报这种场景国内版够用、一个 DeepSeek 的 API Key、一个企业微信的管理员权限。这三样齐了就能开工。WorkBuddy 的安装和初始化不复杂注册后在控制台创建一个新的工作流。这里有个新手容易忽略的点工作流的命名和分组要提前规划好。我一开始随手建了一堆“测试1”“测试2”后来自己都分不清哪个是哪个。建议按“用途-频率”来命名比如“日报-每日”“周报-每周一”一眼就能认出来。DeepSeek 的 API Key 在官网的控制台申请申请完记得把 Key 存到一个安全的地方不要直接写在代码或配置的明文里。WorkBuddy 支持环境变量和密钥管理把 Key 配到密钥管理里工作流里引用变量名就行。这一步多花两分钟能避免以后 Key 泄露的麻烦。企业微信这边登录管理后台在“应用管理”里创建一个自建应用记下 AgentId、Secret 和企业的 CorpID。这三个值后面推送节点要用。创建应用的时候可见范围记得把自己加进去否则收不到消息。3.2 定时触发节点的参数怎么设触发节点是整个流水线的发令枪。WorkBuddy 的定时触发支持 Cron 表达式也支持可视化配置。我建议用可视化配置不容易写错。设置项主要有三个执行频率、执行时间、时区。执行频率选“每天”执行时间填“10:30”时区选你所在的时区。这里有个坑时区一定要确认清楚。我有一次忘了设时区系统默认用了 UTC结果日报在北京时间下午六点半才到完全错过了上午的窗口。改过来之后就好了。还有一个进阶设置是错过执行的处理策略。如果十点半那一刻系统正好在维护或者网络抖动任务没触发是跳过还是补执行我选的是“补执行”但延迟不超过一小时。这样即使有小概率的抖动日报还是能到只是晚一点。如果选“跳过”那就得等第二天了。实操心得定时任务的时间不要设在整点或半点之外的“奇怪时间”比如 10:37 这种。虽然理论上没问题但有些调度系统对非标准时间点的支持不够好容易出玄学问题。10:30 这种整点后的半点既避开了整点高峰又在标准调度粒度内最稳。3.3 数据采集把散落的信息源收拢起来数据采集是决定日报质量的上游环节。你喂给模型什么它就产出什么。我目前配了四类信息源技术社区的热门讨论、几个核心开源项目的更新日志、行业媒体的头条、以及我自己维护的一个待办清单。采集方式分两种。对于有公开接口的信息源直接用 HTTP 请求节点拉取返回 JSON 后用脚本节点提取需要的字段。对于没有接口的用网页抓取节点配置好选择器把正文抠出来。这里的关键是做减法不要贪多每个信息源只取最核心的三五条取多了模型处理不过来日报也会变得冗长。清洗环节容易被忽视但很重要。原始数据里往往有大量噪音HTML 标签、广告文案、重复内容。我加了一个清洗脚本节点做三件事去 HTML 标签、按标题去重、超长内容截断到 500 字以内。截断这一步是为了控制后面模型调用的 token 消耗500 字足够模型理解大意了再长就是浪费。# 数据清洗脚本示例WorkBuddy 脚本节点 import re def clean_items(raw_items): seen_titles set() cleaned [] for item in raw_items: title item.get(title, ).strip() # 去重 if title in seen_titles: continue seen_titles.add(title) # 去 HTML 标签 content re.sub(r[^], , item.get(content, )) # 截断 content content[:500] cleaned.append({title: title, content: content}) return cleaned这段脚本不复杂但能省掉后面很多麻烦。我试过不清洗直接喂给模型结果模型把 HTML 标签也当成内容处理了生成的日报里夹杂着一堆尖括号很难看。3.4 DeepSeek 调用与提示词工程这是整套系统的核心。模型调用本身很简单填上 API Key、选好模型、把清洗后的数据拼进提示词就行。难的是提示词的设计它直接决定日报的质量和稳定性。我的提示词模板经过十几版迭代现在稳定下来的结构是这样的先给模型一个角色设定告诉它“你是一个技术情报分析师”然后给输出格式要求明确日报分几个板块、每个板块写几条、每条多少字接着给素材把清洗后的数据按类别贴进去最后给约束条件比如“不要编造素材中没有的信息”“如果某类素材为空就跳过该板块”。你是一名技术情报分析师请根据以下素材生成一份简洁的日报。 输出格式要求 1. 分三个板块技术动态、项目进展、今日待办 2. 每个板块最多三条每条不超过 80 字 3. 用简洁的陈述句不要用营销腔 素材 【技术动态】{tech_news} 【项目进展】{project_updates} 【今日待办】{todo_list} 约束 - 只使用素材中出现的信息不要自行补充 - 如果某个板块素材为空直接跳过该板块 - 不要输出任何解释性文字直接输出日报正文这个模板的关键在于约束条件。不加约束的话模型会“脑补”把没有的信息编进去日报就失真了。加了“只使用素材中出现的信息”之后幻觉问题基本消失。另一个关键是输出格式的明确性你告诉它分三个板块、每板块三条它就老老实实照做不会自由发挥。注意提示词里的变量占位符要和上游节点的输出字段名严格对应。我踩过一次坑上游输出的字段叫news_list提示词里写的是tech_news结果模型收到的是空字符串日报里技术动态板块直接没了。排查了半天才发现是字段名对不上。3.5 微信推送节点的配置细节推送节点是把成果送到眼前的一步。企业微信应用消息的接口调用不复杂WorkBuddy 里有现成的节点填上 CorpID、Secret、AgentId 和接收人的 UserID 就行。消息格式我选的是markdown 类型因为日报有标题、有列表用 markdown 渲染出来层次清晰。纯文本的话所有内容挤在一起阅读体验差很多。企业微信的 markdown 支持有限不支持表格和复杂嵌套但标题、加粗、列表这些基础语法都支持够用了。{ touser: your_user_id, msgtype: markdown, agentid: 1000002, markdown: { content: ## AI 日报\n\n### 技术动态\n- 条目一\n- 条目二\n\n### 项目进展\n- 条目一 } }这里有个细节消息长度有限制。企业微信的 markdown 消息有字数上限超过会被截断。我的日报控制在 800 字以内从来没触发过限制。如果你要推的内容很长建议拆成多条发或者只推摘要详情放个链接。还有一个体验优化在消息开头加一个日期和一句话摘要。比如“7月15日 AI 日报 | 今日重点关注XX 项目发布新版本”。这样即使我不点开在消息列表里也能看到今天日报的核心看点决定要不要马上看。4. 踩坑记录与常见问题排查4.1 日报内容质量不稳定的排查思路跑了小半年遇到最多的问题就是“今天的日报怎么怪怪的”。表现有好几种内容空洞、格式错乱、出现幻觉、板块缺失。排查的时候按上游到下游的顺序查效率最高。先查数据采集。打开工作流的执行记录看采集节点的输出。如果输出是空的或者只有一两条那问题在上游可能是信息源挂了或者选择器失效了。我遇到过一次某个技术社区的页面改版选择器匹配不到内容采集回来全是空字符串日报自然就空了。解决办法是定期检查采集节点的输出发现异常及时更新选择器。再查模型调用。如果采集正常但日报质量差看模型节点的输入和输出。输入里如果素材很乱输出肯定好不了。输出如果格式不对那就是提示词的问题。我建议把提示词里的格式要求写得更“死”一点比如明确说“用 - 开头表示列表项”模型就更不容易跑偏。最后查推送。如果前面都正常但消息没到检查推送节点的返回码。企业微信的接口返回 errcode 为 0 才是成功非 0 的话对照文档查原因。常见的是 access_token 过期WorkBuddy 一般会自动刷新但如果配置有问题也可能失败。问题表现可能原因排查动作解决方式日报为空采集节点无输出查看采集节点执行记录检查信息源可用性、更新选择器内容空洞素材太少或太碎查看模型节点输入增加信息源、提高素材质量格式错乱提示词约束不足对比输入输出强化格式要求、增加示例出现幻觉提示词未限制检查约束条件加“只使用素材信息”约束消息未送达推送接口报错查看返回 errcode检查 token、UserID 配置4.2 定时任务不触发的几种可能定时任务不触发是个让人抓狂的问题因为你不盯着就不知道它没跑。我的做法是加一个心跳检测如果十点半没收到日报十点四十自动发一条提醒告诉我“今天的日报生成失败了”。这个提醒本身也是通过 WorkBuddy 发的形成一个兜底。不触发的原因我遇到过三种。第一种是时区配置错误前面提过改成正确时区就好。第二种是工作流被意外停用有次我调试的时候手动停用了工作流忘了重新启用结果第二天没收到日报。第三种是调度系统资源紧张任务排队了。这种情况比较少见但如果你的任务正好和其他大任务撞在一起可能会延迟。解决办法是把执行时间错开或者设置补执行策略。实操心得给关键任务加一个“失败告警”分支。WorkBuddy 支持在节点失败时走异常分支我在异常分支里配了一个推送节点一旦主流程失败就给我发消息。这样即使日报没生成我也能第一时间知道而不是等到发现今天怎么没收到才去查。4.3 API 调用频率与成本控制DeepSeek 的 API 是按 token 计费的日报这种每天跑一次的场景成本其实很低。我算过一笔账每天采集的素材大概 3000 字提示词模板 500 字输出 800 字加起来不到 5000 token。按 DeepSeek 的价格一天的成本不到一分钱一个月也就几毛钱。这个成本完全可以忽略。但如果你把频率调高比如每小时跑一次或者素材量很大成本就会上去。控制成本的手段有几个控制素材长度清洗时截断到合理长度选对模型日报这种任务不需要最强的模型用标准版就够加缓存如果某个信息源一小时内的内容没变化就不用重复采集和调用。频率方面我建议日报就一天一次最多早晚各一次。跑太频繁意义不大信息没那么多更新反而增加噪音。我试过一天跑四次结果每次日报内容都差不多纯属浪费。4.4 微信推送的合规与稳定性注意事项推送这块有几个红线要注意。不要用个人微信的第三方机器人方案这类方案不稳定且有合规风险账号可能被限制。企业微信的自建应用是官方支持的路径稳定性和合规性都有保障。消息内容要干净。不要推送任何敏感、争议性内容日报就聚焦技术和业务信息。我见过有人把日报做成了“全网热点聚合”什么话题都往里塞这种很容易出问题。聚焦你的专业领域既安全又有价值。控制推送频率。即使是企业微信短时间内大量推送也可能触发限制。一天一条日报完全没问题但如果你要推多条建议合并成一条发或者间隔开时间。5. 让日报更懂你的几个进阶玩法5.1 用历史反馈微调关注方向日报跑了一段时间后你会发现有些内容你每次都看有些内容你每次都跳过。这个反馈信号很有价值可以用来优化信息源和提示词。我的做法是每周花五分钟回顾一下这周的日报把“总是跳过”的信息源降权或去掉把“总是细看”的方向在提示词里加重。更进阶的做法是让模型自己学习你的偏好。你可以在提示词里加一段“历史偏好说明”比如“用户对 XX 方向的内容关注度较高请优先呈现”。这个说明可以手动维护也可以从你的阅读行为里自动提取。我目前是手动维护每两周更新一次效果已经很明显了。5.2 从日报到周报时间维度的扩展日报跑顺了之后自然会想能不能自动生成周报。逻辑是一样的只是把时间窗口从一天拉长到一周提示词里加上“请总结本周的趋势和变化”。周报的价值在于看趋势日报看的是“今天发生了什么”周报看的是“这一周整体在往哪个方向走”。实现上周报可以复用日报的大部分节点只需要改触发频率每周一早上跑和提示词从“汇总”改成“总结趋势”。我建议周报和日报用两个独立的工作流不要混在一起否则逻辑会变复杂维护起来麻烦。5.3 把待办清单接进来形成闭环我现在的日报里有一个“今日待办”板块数据来自我自己维护的一个清单。这个清单可以是简单的文本文件也可以是 Notion、飞书表格之类的在线文档。WorkBuddy 采集节点把清单拉过来模型整理成待办事项推到微信里。这个闭环的价值在于提醒。待办写在文档里容易忘推到微信里每天十点半准时出现想忘都难。更进一步你可以在日报里加一个“昨日待办完成情况”的回顾形成“计划-执行-回顾”的循环。我试过一段时间对推进项目的效果很明显。5.4 多端同步与备份策略最后说个容易被忽视但很重要的事备份。工作流配置、提示词模板、脚本代码这些东西一旦丢了重建很麻烦。我的做法是定期把工作流导出成 JSON 文件存到本地和云盘各一份。提示词模板单独维护一个文档每次修改都记一笔方便回溯。多端同步方面WorkBuddy 的工作流是云端存储的换设备登录就能用这点很方便。但如果你在多个环境里跑比如测试环境和生产环境要注意配置的隔离不要把测试的 Key 用到生产上。我给每个环境建了独立的工作流命名上区分清楚避免混淆。这套东西从最初的想法到稳定运行前后折腾了大概两周其中大部分时间花在调提示词和排查采集问题上。现在它已经成了我每天工作流的一部分十点半那条消息弹出来的时候我基本能在一分钟内扫完知道今天该关注什么、该推进什么。如果你也想搭一套建议从最简单的版本开始——一个信息源、一个模型调用、一个推送跑通了再逐步加东西。别一上来就追求大而全那样很容易在调试阶段就放弃了。