1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是泡咖啡而是打开各种信息源翻一遍行业动态、竞品更新、技术社区热帖、几个固定关注的博客。翻完一圈二十分钟没了真正记下来的东西可能就两三条。更麻烦的是这事儿一旦忙起来就断断了几天再捡起来信息链就接不上了。我用的工具是 WorkBuddy一个偏工作流编排的助手类工具配合 DeepSeek 的模型能力做内容生成。用了一段时间之后我发现它最大的价值不是“能聊天”而是“能定时干活”。于是我就想能不能让它每天早上十点半自动把我要的那份 AI 日报整理好直接推到我微信里这样我人到工位日报已经在手机上了扫一眼就能进入状态。这个项目说白了就三件事定时触发、内容生成、消息推送。听起来简单但真做起来坑主要集中在“怎么把生成好的内容稳定地送进微信”这一步。下面我把整套思路、选型理由、实操步骤和踩过的坑完整拆一遍适合两类人看一类是想给自己搭个自动化信息流但不知道从哪下手的另一类是已经在用 WorkBuddy 或类似工具、想把“手动问”升级成“自动送”的。核心关键词先摆出来WorkBuddy、AI日报、微信小程序、自动化、DeepSeek。这五个词基本就是整个项目的骨架后面每一节都会围绕它们展开。2. 整体方案设计与选型思路拆解2.1 为什么是“定时任务 生成 推送”三段式很多人做自动化信息流第一反应是写个爬虫脚本抓完存数据库再写个前端页面看。这套方案不是不行但对个人使用来说太重了你得有服务器、有数据库、有前端维护成本高而且“看”这个动作还得你主动去打开页面本质上没解决“送到眼前”的问题。我选的是三段式定时器负责“什么时候做”WorkBuddy DeepSeek 负责“做什么内容”微信负责“送到哪里”。这三段各自独立任何一段出问题都不影响另外两段排查起来也简单。比如日报内容不对那大概率是提示词或模型的问题如果内容对了但没收到那就是推送环节的问题。这种解耦思路是我做自动化项目一贯的原则——能拆开的绝不耦合。2.2 为什么推送端选微信而不是邮件或钉钉推送渠道的选择其实挺关键的。邮件的问题是打开率低我自己的邮箱一天几十封日报混在里面很容易被忽略。钉钉、飞书这类工具适合团队协作但我这个是个人用的没必要再装一个 App。微信的优势在于它是我每天必看的东西没有之一。日报送到微信里我打开微信就能看到不需要额外养成一个新习惯。这一点在做个人自动化的时候特别重要——任何需要你“额外记得去看”的方案最后都会荒废。那微信怎么接收直接给个人微信发消息官方是没有开放接口的第三方方案又不稳定还有风险。所以我的选择是走微信小程序这条路自己做一个极简的小程序日报内容通过小程序的订阅消息或者页面展示来触达。小程序的好处是开发门槛不高用 uniapp 一套代码还能兼顾多端后面想扩展也方便。2.3 WorkBuddy 和 DeepSeek 的分工这里要说清楚一个容易混淆的点WorkBuddy 和 DeepSeek 不是二选一的关系而是配合关系。WorkBuddy 更像是一个“调度中枢 技能容器”它负责按规则触发任务、调用能力、组织输出DeepSeek 则是背后的“内容大脑”负责把原始信息加工成一份像样的日报。我试过只用 DeepSeek 的 API 直接写脚本调用也能跑通但问题是所有的触发逻辑、重试逻辑、格式整理都得自己写代码量不小。用 WorkBuddy 的好处是它把这些“脏活”封装好了我只需要定义“每天十点半做什么”剩下的它来管。这就是选型的核心逻辑把精力花在内容质量上而不是花在调度代码上。方案触发实现内容生成推送维护成本我的评价纯脚本自建自己写 cron自己调 API自己写推送高灵活但费人WorkBuddy DeepSeek内置定时技能调用对接小程序中平衡点最好现成日报类 App不可控固定模板App 内查看低内容不贴合3. 核心细节解析与实操要点3.1 定时触发十点半这个时间点是怎么定的时间点的选择不是拍脑袋。我观察了自己两周的工作节奏发现九点到十点这段时间基本在处理昨晚积压的消息和邮件十点之后才真正进入“需要信息输入”的状态。十点半推送正好卡在我处理完杂事、准备开始正经工作之前这时候一份日报进来能直接指导我接下来干什么。在 WorkBuddy 里设定时任务核心是搞清楚它的时间表达式和时区。我踩过一个坑默认时区如果没确认任务可能按 UTC 跑那十点半就变成下午六点半了。所以第一件事就是确认时区设置这个细节后面在排查章节还会细说。3.2 内容生成一份“能看”的日报需要哪些字段日报最怕的就是“信息堆砌”。我一开始让模型把抓到的内容全列出来结果每天收到一大坨看两眼就烦了。后来我重新设计了日报的结构固定成四个板块今日要闻3 条每条一句话概括 一句我的关注点技术动态2 到 3 条偏工具、框架、模型更新值得一读1 到 2 篇长文或深度内容附一句推荐理由一句话提醒当天需要我特别留意的事比如某个截止时间这个结构的好处是信息密度可控每条都有“为什么值得看”的判断而不是干巴巴的标题列表。这里 DeepSeek 的作用就体现出来了——它不只是摘要而是带着“编辑视角”在筛选和点评。3.3 推送落地微信小程序这条路的几个关键决策小程序这块我做了几个取舍值得说一下。第一不做复杂 UI。日报就是纯文本加简单排版页面就一个列表点进去看详情。做复杂了开发成本高而且我根本不需要。第二用订阅消息而不是常驻页面。订阅消息能主动弹提醒比让我自己去点开小程序强。但订阅消息有个限制需要用户授权而且模板消息的格式有约束。所以我的做法是订阅消息只推“日报已生成”的提醒正文还是在小程序里看。这样既保证了触达又不受模板格式限制。第三数据缓存策略。日报内容我设置成缓存 24 小时第二天新日报生成时覆盖。这样即使某天推送失败我打开小程序还能看到最近一份不至于空着。微信小程序的缓存时间设置这个点很多人会忽略但对个人工具来说“有兜底”比“完美”更重要。3.4 提示词设计让 DeepSeek 输出稳定格式的三个技巧模型输出不稳定是自动化的大敌。今天给你 Markdown明天给你纯文本后天多一段废话解析起来就崩了。我用了三个技巧把输出稳住在提示词里明确给出输出模板包括字段名、分隔符、字数上限。比如“每条不超过 40 字用竖线分隔标题和点评”。要求模型先思考再输出但思考过程用特定标记包起来解析时直接丢弃。这样既保留了推理质量又不污染最终结果。加一个自检指令让模型输出前确认“是否严格符合模板”不符合就重来。实测下来这一条能把格式错误率压到很低。提示提示词里千万不要写“尽量”“大概”这类模糊词模型会理解成“可以自由发挥”。要写“必须”“只能”“不超过”这种硬约束。4. 实操过程与核心环节实现4.1 环境准备与 WorkBuddy 基础配置先把基础环境搭起来。WorkBuddy 的安装按官方教程走就行装完之后重点是两件事配置模型接入和确认时区。模型接入这块我用的是 DeepSeek 的 API。配置的时候需要填 API Key 和接口地址这里注意 Key 的权限范围别用权限过大的 Key个人项目够用就行。填完之后一定要做个连通性测试发一条最简单的请求确认能正常返回。时区确认我单独拎出来说因为这是最容易翻车的地方。在 WorkBuddy 的设置里找到时区选项确认是东八区。如果不确定就设一个五分钟后的测试任务看它是不是按你预期的时间触发。这个测试花五分钟能省掉后面半小时的排查。4.2 编写日报生成技能的核心逻辑WorkBuddy 的“技能”概念可以理解成一个可复用的任务模板。我把日报生成拆成一个技能核心逻辑分三步第一步信息采集。我固定了几个信息源通过接口或页面抓取的方式拿到原始内容。这一步的关键是做好去重同一个新闻可能在多个源出现不去重的话日报里会重复。第二步内容加工。把原始内容喂给 DeepSeek用前面设计好的提示词生成结构化日报。这里我加了一个长度控制如果原始内容太多先做一轮粗筛只把最相关的送进模型避免超出上下文限制。第三步格式化输出。把模型返回的内容解析成 JSON字段对应日报的四个板块然后存到一个临时位置等推送环节来取。# 日报生成核心逻辑示意伪代码 def generate_daily_report(): raw_items fetch_all_sources() # 采集 deduped deduplicate(raw_items) # 去重 filtered pre_filter(deduped, top_n15) # 粗筛 report call_deepseek(filtered, prompt) # 加工 parsed parse_report(report) # 解析 save_temp(parsed) # 暂存 return parsed4.3 微信小程序的对接实现小程序这边我用 uniapp 开发一套代码后面想扩展到其他端也方便。核心页面就两个日报列表页和日报详情页。列表页展示最近几天的日报标题和摘要详情页展示完整内容。数据从哪来我在小程序里做了一个简单的请求封装统一处理请求头、错误码和缓存。请求封装这个点看着小但统一封装之后后面加接口、改逻辑都只改一个地方省事很多。订阅消息的对接是重点。流程是用户在小程序里点一次“订阅”拿到授权之后 WorkBuddy 生成日报后调用服务端接口触发订阅消息推送。这里要注意订阅消息的模板字段要和实际内容对应不然推送会失败。我一开始字段名写错了排查了半天才发现是模板 ID 和字段不匹配。4.4 把三段串起来完整的自动化链路三段各自跑通之后最后一步是串起来。我在 WorkBuddy 里建了一个主任务定时十点半触发依次执行调用日报生成技能 → 拿到结果 → 调用推送接口 → 记录执行日志。这里有个细节每一步都要有失败处理。比如生成失败就推一条“今日日报生成异常”的提醒而不是静默失败。静默失败是最坑的你以为它在跑其实早就断了。我现在的做法是只要主任务没在预期时间完成就发一条告警这样我能第一时间知道。环节触发方式失败处理日志记录日报生成主任务调用重试 2 次后告警记录耗时和状态内容推送生成成功后调用失败重推 1 次记录推送结果兜底展示小程序打开时展示最近缓存记录访问时间5. 常见问题与排查技巧实录5.1 定时任务没触发或触发时间不对这是最高频的问题。排查顺序我总结成三步先看时区再看任务状态最后看日志。时区问题前面说过不再重复。任务状态这块WorkBuddy 里能看到任务的启用状态和上次执行时间如果显示“未启用”或者上次执行是很久以前那基本就是配置问题。日志是最直接的证据如果日志里根本没有这次执行的记录说明任务压根没触发如果有记录但报错那就往下看具体错误。注意有些平台的定时任务在服务重启后会丢失如果你的 WorkBuddy 是跑在会重启的环境里记得确认任务是否持久化。5.2 日报内容格式错乱或字段缺失模型输出不稳定导致的。解决办法有两个方向一是加强提示词约束二是加解析容错。提示词约束前面讲了核心是给模板、给硬约束。解析容错是指在解析模型返回内容时不要假设格式一定完美。比如某个字段缺失就给个默认值某个分隔符没找到就尝试用备选分隔符。我现在的解析逻辑里每个字段都有兜底值这样即使模型抽风日报也不会整个崩掉。5.3 微信推送收不到推送收不到的原因比较多我整理成一个速查表现象可能原因排查方法完全没提醒订阅未授权或已过期检查小程序订阅状态提醒到了但内容空模板字段不匹配核对模板 ID 和字段名偶尔收不到接口限流或超时看推送日志的重试记录内容乱码编码问题确认传输编码为 UTF-8我遇到最多的是订阅过期。微信的订阅消息是一次授权一次推送用户点一次只能收一条。所以我的做法是在小程序里做了个“续订”按钮每次打开日报时提醒续订这样能保证推送不断。5.4 几个我踩过的坑和独家技巧第一个坑API Key 硬编码在代码里。这个习惯很危险一旦代码泄露 Key 就废了。正确做法是把 Key 放到环境变量或配置中心代码里只引用变量名。第二个坑没有做幂等。有一次任务因为网络问题重试了结果同一天生成了两份日报推送了两条。后来我加了幂等判断同一天只允许生成一份日报重复触发直接跳过。第三个技巧给日报加一个“历史归档”。每天生成的日报除了推送还存一份到本地或云盘按日期命名。这样时间长了能回看也能做趋势分析。我用的是最简单的按年月分文件夹存文本文件够用就行。第三个坑忽略小程序的年审和合规。小程序上线后是有年审要求的如果只是自己用可以走体验版或者开发版避免年审的麻烦。但如果要长期稳定用还是得把合规这块处理好不然某天突然不能用了会很被动。6. 这套方案还能怎么扩展跑通之后我发现这套“定时 生成 推送”的骨架其实很通用换个内容源和提示词就能变成别的工具。比如把信息源换成我关注的几个技术博客日报就变成“技术阅读清单”换成行业新闻就变成“行业简报”甚至可以做成“每周复盘提醒”每周五下午自动把这一周的工作记录汇总成一份复盘草稿推给我。核心逻辑没变变的只是喂给模型什么和提示词怎么写。另外一个扩展方向是多端触达。现在只推微信后面如果我想在电脑上也能看可以用 uniapp 的多端能力再编译一个桌面端或者网页版数据源还是同一份。这就是当初选 uniapp 而不是原生小程序的原因——给自己留了扩展的余地。我个人在实际操作中的体会是做这类个人自动化工具别追求一步到位。先把最小闭环跑通哪怕日报内容很粗糙只要“定时生成 能收到”这条链路通了后面优化内容质量就是水到渠成的事。最怕的是一开始就想做完美结果卡在某个细节上最后整个项目不了了之。先跑起来再慢慢调这是我做了这么多自动化项目最实在的一条经验。