1. 从一条定时任务说起为什么我要给 WorkBuddy 设个闹钟每天早上到工位第一件事是打开各种信息源翻一遍昨天夜里到今早的行业动态、项目进展、待办提醒然后再开始干活。这个动作看起来不起眼但日积月累消耗的时间非常可观而且状态好的时候翻得细状态差的时候直接跳过信息获取的稳定性完全靠人肉自觉。我试过用 RSS 订阅、用邮件简报、用各种聚合工具最后都因为“要主动去打开”而慢慢荒废。真正能坚持下来的信息流一定是主动推送到你已经在用的高频入口上的而不是等你想起它。WorkBuddy 这个工具本身是一个偏工作台形态的助手类产品支持自定义规则、技能skill和任务编排可以把它理解成一个能听懂自然语言指令、又能调用外部能力的自动化中枢。我给它设的这条规则非常朴素每天上午十点半自动生成一份 AI 日报然后通过微信推送到我手机上。十点半这个时间点是刻意选的早于它的日报要么信息不全晚于它又已经进入工作节奏十点半刚好是上午第一波事务处理完、需要重新校准方向的窗口。这份日报里我关心的东西包括当天值得关注的 AI 领域动态、我关注的几个项目的状态变化、以及我自己预设的一些追踪项。生成环节交给大模型来做摘要和归类推送环节走微信因为微信是我打开频率最高的应用没有之一。整条链路的核心关键词就是WorkBuddy、AI日报、微信推送、自动化而底层调用的模型我选的是deepseek-v4-flash原因后面会详细讲。这篇文章适合两类人看一类是已经在用 WorkBuddy、想把它从“偶尔问问”变成“每天自动干活”的进阶用户另一类是还没上手、但手里有一堆重复性信息整理工作、想找个靠谱自动化方案的人。我会把整条链路的搭建思路、关键配置、踩过的坑和排查方法全部摊开讲你照着抄作业基本能跑通。2. 整体方案设计与选型思路拆解2.1 为什么是“定时任务 大模型摘要 微信推送”这个组合先把整条链路拆成三段来看触发段、生成段、投递段。触发段负责在指定时间把任务叫醒生成段负责把原始信息加工成可读的日报投递段负责把成品送到我面前。这三段里任何一段依赖“我主动操作”整条链路就会退化成一个普通工具所以设计的第一原则是全链路无人值守。触发段我选择 WorkBuddy 自带的定时/规则能力而不是外部再挂一个系统级的定时器。原因很实际外部定时器比如操作系统的计划任务只能触发一个脚本脚本里还得自己处理鉴权、上下文、模型调用等于把 WorkBuddy 的能力绕过去了。而用 WorkBuddy 自身的规则机制任务是在它的上下文里跑的能直接复用已经配置好的技能和模型维护成本低一个量级。生成段选大模型做摘要是因为日报的原始素材往往是多来源、格式不统一的用规则引擎做抽取会写死一堆正则信息源一改就崩。大模型的好处是对输入格式的容忍度高你给它一段杂乱的文本它也能提炼出结构化的要点。这里我用的模型是 deepseek-v4-flash选它的核心理由是快和便宜。日报这种场景对模型的推理深度要求不高但对响应速度和调用成本敏感因为每天都要跑一个月三十次模型选贵了整个方案的经济性就没了。flash 版本在摘要、归类、格式化这类任务上完全够用实测下来生成一份千字左右的日报延迟和成本都在可接受范围内。投递段选微信是因为推送的到达率和打开率。邮件会被淹没在收件箱里App 推送会被系统折叠只有微信是大多数人会主动点开红点的入口。把日报送进微信本质上是借用了微信的通知能力让日报和日常聊天信息处在同一个注意力池子里被看到的概率大幅提升。2.2 微信侧的实现路径选择小程序、服务号还是其他把内容送进微信有好几条路我逐一评估过。第一条是微信服务号的模板消息优点是到达稳定、格式规范缺点是模板消息有严格的类目和内容限制日报这种自由格式的长文本塞进去会被截断而且申请和审核流程对个人开发者不友好。第二条是企业微信机器人配置简单、支持 Markdown但前提是你得用企业微信个人场景下多装一个 App 本身就是负担。第三条是微信小程序可以自己做一个展示页把日报渲染得漂漂亮亮但小程序的问题是“要主动打开”又回到了最初那个悖论。最后我采用的是一种更轻的组合用 WorkBuddy 把日报生成好通过一个极简的转发通道送到微信的文件传输助手或指定会话。这样既保留了微信的高到达率又不需要维护复杂的小程序前端。如果你确实想要一个更正式的展示形态可以再叠一层微信小程序做归档和检索但那是第二阶段的事第一阶段先把“每天准时收到”这件事跑通。提示微信侧的通道选择没有绝对最优解核心判断标准是“你每天会不会主动看”。如果你的工作流重度依赖企业微信那企业微信机器人就是最优解如果就是个人微信那就选最轻的转发方式别为了形式感上小程序。2.3 模型选型为什么是 deepseek-v4-flash 而不是更大的模型这里展开讲一下模型选型的逻辑因为这是很多人容易纠结的地方。日报生成这个任务拆开看包含三个子动作信息抽取、要点归类、语言润色。这三个动作里信息抽取和归类是相对确定性的任务模型只要具备基本的指令遵循能力就能做好语言润色是锦上添花日报不需要文采飞扬通顺即可。在这种任务画像下大参数模型带来的边际收益很低但成本和延迟的劣势很明显。deepseek-v4-flash 这类轻量模型的设计目标就是高吞吐、低延迟非常适合这种“高频、低复杂度”的日常任务。我实测过用更大的模型跑同样的日报输出质量的主观差异很小但等待时间和调用成本差了好几倍。对于每天都要跑的自动化任务稳定性和经济性比峰值质量更重要。当然如果你的日报里包含复杂的推理分析比如需要跨多个数据源做因果推断那确实应该上更强的模型。选型的本质是让任务复杂度和模型能力匹配而不是无脑选最强的。3. 核心配置细节与实操要点3.1 WorkBuddy 规则配置让任务每天自动触发WorkBuddy 的规则机制是整条链路的起点。配置的核心是两件事触发条件和执行动作。触发条件我设的是每天上午十点半这个在规则编辑器里可以直接选时间。执行动作则是一段自然语言指令告诉它到点之后要做什么。指令的写法有讲究。我一开始写得很随意比如“帮我整理一份 AI 日报”结果生成的内容时好时坏有时候只给两三条有时候又啰嗦一大篇。后来我把指令拆得更具体明确了输出结构、信息范围、字数区间和格式要求稳定性立刻上来了。下面是我现在用的指令模板你可以直接参考每天上午十点半执行以下任务 1. 汇总过去24小时内我关注的 AI 领域重要动态控制在5到8条 2. 每条动态用一句话概括再附一句我的关注点提示 3. 列出我预设的追踪项当前状态 4. 输出格式为纯文本分三个板块动态速览、追踪项、今日提醒 5. 总字数控制在800到1200字之间。这里的关键经验是给模型的指令要像给实习生派活一样具体。你越模糊它越自由发挥你越具体它越稳定。尤其是“字数区间”和“板块划分”这两个约束能极大提升输出的可预期性。注意WorkBuddy 的规则一旦设定后续对所有匹配的任务都会生效。所以如果你有多条规则务必确认它们之间不会互相干扰。我踩过的坑是两条规则的时间窗口重叠导致同一天生成了两份日报后来把时间错开就好了。3.2 信息源的接入与清洗日报的质量七分靠信息源三分靠模型。信息源接得不好模型再强也提炼不出有价值的内容。我的做法是把信息源分成两类结构化源和非结构化源。结构化源比如我关注的几个项目的更新日志、待办清单这些本身就有固定格式直接喂给模型即可。非结构化源比如行业资讯、社区讨论需要先做一轮粗筛把明显无关的内容过滤掉再交给模型。粗筛这一步很多人会忽略觉得反正模型能处理。但实测下来如果原始素材里噪音太多模型会被带偏输出的日报里混进一堆无关内容。我的做法是在指令里加一句“忽略与 AI 领域无关的内容”同时在信息源层面做一次关键词过滤双保险。另外信息源的更新频率要和日报的生成频率匹配。日报是每天生成那信息源最好是每天都有更新否则会出现“今天和昨天日报几乎一样”的尴尬。我遇到过某个源一周才更新一次导致连续几天日报里都有重复条目后来把它从每日源降级成了每周源。3.3 微信推送通道的打通推送通道这块核心是把 WorkBuddy 的输出和微信的接收端连起来。我的方案是让 WorkBuddy 把日报写到一个约定的位置然后由一个轻量的转发环节把它送进微信。这个转发环节可以是一个简单的脚本也可以是 WorkBuddy 自带的输出能力取决于你的具体环境。如果你走的是脚本转发关键点是鉴权和格式。鉴权方面微信侧的接口调用需要凭证这个凭证要妥善保管不要硬编码在脚本里明文存储建议用环境变量的方式注入。格式方面微信对消息长度有限制超过限制会被截断所以日报的字数控制不只是为了可读性也是为了适配通道限制。我前面把日报控制在800到1200字一部分原因就在这里。提示推送失败是这条链路里最常见的故障。建议在转发环节加一个失败重试和日志记录这样出问题的时候能快速定位是生成环节挂了还是推送环节挂了。3.4 时间点的选择与调整十点半这个时间点不是拍脑袋定的。我观察了自己一周的工作节奏发现上午九点到十点是处理紧急事务的高峰期这时候推日报会被忽略十点半到十一点是相对空闲的窗口适合接收和阅读信息。所以时间点的选择应该基于你自己的注意力曲线而不是照搬别人的配置。如果你发现十点半不合适调整也很简单改规则里的时间即可。但要注意调整之后最好观察几天确认新的时间点确实更合适不要频繁改来改去否则会打乱自己的信息接收习惯。4. 完整实操流程与关键环节实现4.1 环境准备与基础配置在开始配置之前先把基础环境理清楚。你需要一个可用的 WorkBuddy 环境以及一个能接收微信消息的通道。WorkBuddy 的安装和初始化按照官方指引走即可这里不展开。重点说一下配置的顺序因为顺序错了会返工。正确的顺序是先打通推送通道再配置生成逻辑最后设定时触发。为什么是这个顺序因为推送通道是最容易出问题的一环先把它跑通你就能用一个固定的测试消息验证整条链路是通的。如果先配生成逻辑生成了一堆日报却推不出去排查起来会分不清是生成的问题还是推送的问题。推送通道打通后用一个简单的“Hello”消息测试确认微信能收到。这一步过了再往上叠生成逻辑。生成逻辑跑通后用一个手动触发的方式验证输出质量确认没问题了最后再设定时规则。这样每一步都有明确的验证点出问题能快速定位。4.2 日报生成逻辑的调试与优化生成逻辑的调试是个迭代过程。我的做法是先跑一版最简的看输出长什么样然后针对问题逐条改指令。第一版我遇到的问题主要有三个内容太散、重点不突出、格式不统一。针对这三个问题我在指令里分别加了约束用“控制在5到8条”解决太散用“每条附一句关注点提示”解决重点不突出用“分三个板块”解决格式不统一。调试的时候有个技巧把模型的输出和你的预期做逐条对比而不是整体感觉“还行”就过了。比如它给了六条动态你逐条看是不是你真正关心的它给的关注点提示是不是你真正想看到的。这种逐条对比能帮你发现指令里模糊的地方然后针对性收紧。另外模型的输出有随机性同样的指令跑两次结果可能不一样。所以调试的时候不要只看一次输出就下结论至少跑三次看稳定性。如果三次输出质量波动很大说明指令还不够具体需要继续收紧。4.3 定时触发的验证与监控定时触发配好之后最怕的是“以为它在跑其实没跑”。我的做法是加一个心跳机制每天日报推送成功后在日志里记一条如果某天到了十一点还没看到日报我就知道出问题了。这个心跳不需要很复杂一个简单的日志文件就够。验证定时触发是否生效最直接的方法是等一天看结果。但如果你不想等可以临时把触发时间改成几分钟后验证一次确认没问题再改回十点半。这个技巧在调试阶段非常实用能省下大量等待时间。监控方面我建议至少记录三个信息触发时间、生成耗时、推送结果。这三个信息能覆盖绝大多数故障场景。触发时间没记录说明规则没生效生成耗时异常长说明模型调用出了问题推送结果失败说明通道有问题。有了这三个信息排查效率会高很多。4.4 日报内容的持续迭代日报跑起来之后不是一劳永逸的。你的关注点会变信息源会变所以日报的内容也需要持续迭代。我的做法是每周花十分钟回顾一下这周的日报看看哪些内容我实际看了、哪些直接跳过。看了的保留甚至加强跳过的考虑删掉或降频。这个回顾动作看起来不起眼但它是让日报保持价值的关键。很多人的自动化日报跑着跑着就变成“每天收到但从不看”根本原因就是内容没有跟着需求迭代慢慢就变成了噪音。日报的价值不在于生成而在于被阅读所以迭代的锚点应该是你的阅读行为而不是生成的技术指标。5. 常见问题与排查技巧实录5.1 日报没收到从哪开始查日报没收到是最常见的故障排查要按链路顺序来不要跳步。第一步查触发是否发生看日志里有没有当天的触发记录。如果没有说明规则没生效去检查规则配置重点看时间设置和规则是否被禁用。第二步查生成是否完成看日志里有没有生成完成的记录。如果没有说明模型调用卡住了去检查模型服务的状态和调用凭证。第三步查推送是否成功看日志里推送环节的返回结果。如果失败去检查推送通道的鉴权和格式。这个顺序的逻辑是从上游到下游因为上游的问题会伪装成下游的问题。比如触发没发生你却在拼命查推送通道就是白费功夫。按顺序查能最快定位到真正的故障点。5.2 日报内容质量不稳定内容质量不稳定的根源通常在指令的模糊性。如果你的指令里有“整理一下”“汇总一些”这类模糊词模型的输出就会飘。解决办法是把模糊词替换成具体约束比如“整理一下”改成“列出5到8条每条一句话概括”。约束越具体输出越稳定。另一个原因是信息源本身的波动。如果某天信息源更新很少模型只能硬凑质量自然下降。这种情况可以在指令里加一句“如果有效信息不足5条就如实说明不要硬凑”给模型一个退路。5.3 推送被截断或格式错乱推送被截断通常是字数超限。微信侧对消息长度有硬限制超过就会被截。解决办法是在生成环节就把字数控制住或者在推送前加一个截断逻辑超长部分转成第二条消息。格式错乱则通常是 Markdown 和纯文本的转换问题微信对 Markdown 的支持有限建议日报用纯文本加简单符号的格式兼容性最好。5.4 模型调用超时或失败模型调用失败的原因有几个凭证过期、服务限流、网络波动。凭证过期是最常见的建议定期检查凭证有效期。服务限流的话可以在调用环节加一个重试逻辑失败后等几秒再试。网络波动相对少见但如果你的环境网络不稳定也会导致调用失败这种情况只能靠重试兜底。下面这张表是我整理的常见问题速查表遇到问题可以直接对照现象可能原因排查动作日报完全没收到触发规则未生效检查规则时间配置和启用状态日报收到但内容为空生成环节失败检查模型调用日志和凭证日报内容重复信息源更新频率低调整信息源或降低日报频率推送被截断字数超限收紧生成字数或拆分推送格式错乱Markdown 兼容问题改用纯文本格式模型调用超时限流或网络波动加重试逻辑检查网络5.5 几个我踩过的坑第一个坑是规则冲突。我一开始设了两条规则一条生成日报一条生成周报结果周报的规则在周一触发了日报的生成逻辑导致周一收到两份内容重叠的日报。后来把两条规则的时间窗口明确错开问题解决。第二个坑是信息源失效。我接的某个信息源悄悄改了接口格式导致连续几天日报里那个板块都是空的。因为日报整体还在生成我没第一时间发现。后来加了“板块为空时告警”的逻辑才避免类似问题。第三个坑是过度依赖单一模型。有段时间模型服务不稳定日报时有时无。后来我加了一个降级逻辑主模型不可用时自动切到备用模型虽然质量略有下降但至少保证日报不断供。对于每天都要跑的任务可用性比峰值质量更重要。提示自动化任务的可靠性很大程度上取决于你对失败场景的覆盖程度。每遇到一次故障就把它变成一个可检测、可恢复的场景链路就会越来越稳。6. 这套方案还能怎么扩展跑通日报之后我陆续做了一些扩展这里分享几个方向。第一个方向是多频道分发同样的日报内容除了推微信还可以同步到其他你常用的入口比如笔记软件或者待办工具让信息在不同场景下都能触达。第二个方向是交互式日报在日报末尾附上几个可点击的选项比如“展开详情”“标记已读”“推迟到下午”让日报从单向推送变成双向交互。第三个方向是日报的归档与检索。每天生成的日报如果只是推完就丢价值会随时间衰减。把它们存下来按日期和主题建索引过一段时间回看能发现很多当时没注意到的趋势。这个扩展的技术门槛不高但长期价值很大。第四个方向是把日报机制复用到其他场景。日报只是“定时生成 推送”这个模式的一个实例同样的模式可以套用到周报、项目进度同步、竞品监控等场景。把核心链路抽象出来换一个生成指令和信息源就是一个新的自动化任务。这也是我一开始选择用 WorkBuddy 规则机制而不是外部脚本的原因复用成本低。我个人在实际操作中的体会是自动化任务的价值不在于技术多复杂而在于它是否真的融入了你的日常。一个每天准时出现在微信里的日报哪怕技术实现很朴素只要内容对你有用它的价值就远超过一个技术炫酷但你从不打开的复杂系统。先把最简单的链路跑通让它在你的生活里占住一个位置然后再慢慢迭代这个顺序不能反。