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 模型调用超时或失败

模型调用失败的原因有几个：凭证过期、服务限流、网络波动。凭证过期是最常见的，建议定期检查凭证有效期。服务限流的话，可以在调用环节加一个重试逻辑，失败后等几秒再试。网络波动相对少见，但如果你的环境网络不稳定，也会导致调用失败，这种情况只能靠重试兜底。

下面这张表是我整理的常见问题速查表，遇到问题可以直接对照：

5.5 几个我踩过的坑

第一个坑是规则冲突。我一开始设了两条规则，一条生成日报，一条生成周报，结果周报的规则在周一触发了日报的生成逻辑，导致周一收到两份内容重叠的日报。后来把两条规则的时间窗口明确错开，问题解决。

第二个坑是信息源失效。我接的某个信息源悄悄改了接口格式，导致连续几天日报里那个板块都是空的。因为日报整体还在生成，我没第一时间发现。后来加了“板块为空时告警”的逻辑，才避免类似问题。

第三个坑是过度依赖单一模型。有段时间模型服务不稳定，日报时有时无。后来我加了一个降级逻辑，主模型不可用时自动切到备用模型，虽然质量略有下降，但至少保证日报不断供。对于每天都要跑的任务，可用性比峰值质量更重要。

提示：自动化任务的可靠性，很大程度上取决于你对失败场景的覆盖程度。每遇到一次故障，就把它变成一个可检测、可恢复的场景，链路就会越来越稳。

6. 这套方案还能怎么扩展

跑通日报之后，我陆续做了一些扩展，这里分享几个方向。第一个方向是多频道分发，同样的日报内容，除了推微信，还可以同步到其他你常用的入口，比如笔记软件或者待办工具，让信息在不同场景下都能触达。第二个方向是交互式日报，在日报末尾附上几个可点击的选项，比如“展开详情”“标记已读”“推迟到下午”，让日报从单向推送变成双向交互。

第三个方向是日报的归档与检索。每天生成的日报如果只是推完就丢，价值会随时间衰减。把它们存下来，按日期和主题建索引，过一段时间回看，能发现很多当时没注意到的趋势。这个扩展的技术门槛不高，但长期价值很大。

第四个方向是把日报机制复用到其他场景。日报只是“定时生成 + 推送”这个模式的一个实例，同样的模式可以套用到周报、项目进度同步、竞品监控等场景。把核心链路抽象出来，换一个生成指令和信息源，就是一个新的自动化任务。这也是我一开始选择用 WorkBuddy 规则机制而不是外部脚本的原因，复用成本低。

我个人在实际操作中的体会是，自动化任务的价值不在于技术多复杂，而在于它是否真的融入了你的日常。一个每天准时出现在微信里的日报，哪怕技术实现很朴素，只要内容对你有用，它的价值就远超过一个技术炫酷但你从不打开的复杂系统。先把最简单的链路跑通，让它在你的生活里占住一个位置，然后再慢慢迭代，这个顺序不能反。