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 的好处是它把这些“脏活”封装好了，我只需要定义“每天十点半做什么”，剩下的它来管。这就是选型的核心逻辑：把精力花在内容质量上，而不是花在调度代码上。

3. 核心细节解析与实操要点

3.1 定时触发：十点半这个时间点是怎么定的

时间点的选择不是拍脑袋。我观察了自己两周的工作节奏，发现九点到十点这段时间基本在处理昨晚积压的消息和邮件，十点之后才真正进入“需要信息输入”的状态。十点半推送，正好卡在我处理完杂事、准备开始正经工作之前，这时候一份日报进来，能直接指导我接下来干什么。

在 WorkBuddy 里设定时任务，核心是搞清楚它的时间表达式和时区。我踩过一个坑：默认时区如果没确认，任务可能按 UTC 跑，那十点半就变成下午六点半了。所以第一件事就是确认时区设置，这个细节后面在排查章节还会细说。

3.2 内容生成：一份“能看”的日报需要哪些字段

日报最怕的就是“信息堆砌”。我一开始让模型把抓到的内容全列出来，结果每天收到一大坨，看两眼就烦了。后来我重新设计了日报的结构，固定成四个板块：

• 今日要闻：3 条，每条一句话概括 + 一句我的关注点
• 技术动态：2 到 3 条，偏工具、框架、模型更新
• 值得一读：1 到 2 篇长文或深度内容，附一句推荐理由
• 一句话提醒：当天需要我特别留意的事，比如某个截止时间

这个结构的好处是信息密度可控，每条都有“为什么值得看”的判断，而不是干巴巴的标题列表。这里 DeepSeek 的作用就体现出来了——它不只是摘要，而是带着“编辑视角”在筛选和点评。

3.3 推送落地：微信小程序这条路的几个关键决策

小程序这块我做了几个取舍，值得说一下。

第一，不做复杂 UI。日报就是纯文本加简单排版，页面就一个列表，点进去看详情。做复杂了开发成本高，而且我根本不需要。

第二，用订阅消息而不是常驻页面。订阅消息能主动弹提醒，比让我自己去点开小程序强。但订阅消息有个限制：需要用户授权，而且模板消息的格式有约束。所以我的做法是：订阅消息只推“日报已生成”的提醒，正文还是在小程序里看。这样既保证了触达，又不受模板格式限制。

第三，数据缓存策略。日报内容我设置成缓存 24 小时，第二天新日报生成时覆盖。这样即使某天推送失败，我打开小程序还能看到最近一份，不至于空着。微信小程序的缓存时间设置这个点，很多人会忽略，但对个人工具来说，“有兜底”比“完美”更重要。

3.4 提示词设计：让 DeepSeek 输出稳定格式的三个技巧

模型输出不稳定是自动化的大敌。今天给你 Markdown，明天给你纯文本，后天多一段废话，解析起来就崩了。我用了三个技巧把输出稳住：

1. 在提示词里明确给出输出模板，包括字段名、分隔符、字数上限。比如“每条不超过 40 字，用竖线分隔标题和点评”。
2. 要求模型先思考再输出，但思考过程用特定标记包起来，解析时直接丢弃。这样既保留了推理质量，又不污染最终结果。
3. 加一个自检指令，让模型输出前确认“是否严格符合模板”，不符合就重来。实测下来，这一条能把格式错误率压到很低。

提示：提示词里千万不要写“尽量”“大概”这类模糊词，模型会理解成“可以自由发挥”。要写“必须”“只能”“不超过”这种硬约束。

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_n=15) # 粗筛 report = call_deepseek(filtered, prompt) # 加工 parsed = parse_report(report) # 解析 save_temp(parsed) # 暂存 return parsed

4.3 微信小程序的对接实现

小程序这边，我用 uniapp 开发，一套代码后面想扩展到其他端也方便。核心页面就两个：日报列表页和日报详情页。

列表页展示最近几天的日报标题和摘要，详情页展示完整内容。数据从哪来？我在小程序里做了一个简单的请求封装，统一处理请求头、错误码和缓存。请求封装这个点看着小，但统一封装之后，后面加接口、改逻辑都只改一个地方，省事很多。

订阅消息的对接是重点。流程是：用户在小程序里点一次“订阅”，拿到授权，之后 WorkBuddy 生成日报后调用服务端接口，触发订阅消息推送。这里要注意订阅消息的模板字段要和实际内容对应，不然推送会失败。我一开始字段名写错了，排查了半天才发现是模板 ID 和字段不匹配。

4.4 把三段串起来：完整的自动化链路

三段各自跑通之后，最后一步是串起来。我在 WorkBuddy 里建了一个主任务，定时十点半触发，依次执行：调用日报生成技能 → 拿到结果 → 调用推送接口 → 记录执行日志。

这里有个细节：每一步都要有失败处理。比如生成失败，就推一条“今日日报生成异常”的提醒，而不是静默失败。静默失败是最坑的，你以为它在跑，其实早就断了。我现在的做法是，只要主任务没在预期时间完成，就发一条告警，这样我能第一时间知道。

5. 常见问题与排查技巧实录

5.1 定时任务没触发或触发时间不对

这是最高频的问题。排查顺序我总结成三步：先看时区，再看任务状态，最后看日志。

时区问题前面说过，不再重复。任务状态这块，WorkBuddy 里能看到任务的启用状态和上次执行时间，如果显示“未启用”或者上次执行是很久以前，那基本就是配置问题。日志是最直接的证据，如果日志里根本没有这次执行的记录，说明任务压根没触发；如果有记录但报错，那就往下看具体错误。

注意：有些平台的定时任务在服务重启后会丢失，如果你的 WorkBuddy 是跑在会重启的环境里，记得确认任务是否持久化。

5.2 日报内容格式错乱或字段缺失

模型输出不稳定导致的。解决办法有两个方向：一是加强提示词约束，二是加解析容错。

提示词约束前面讲了，核心是给模板、给硬约束。解析容错是指在解析模型返回内容时，不要假设格式一定完美。比如某个字段缺失，就给个默认值；某个分隔符没找到，就尝试用备选分隔符。我现在的解析逻辑里，每个字段都有兜底值，这样即使模型抽风，日报也不会整个崩掉。

5.3 微信推送收不到

推送收不到的原因比较多，我整理成一个速查表：

我遇到最多的是订阅过期。微信的订阅消息是一次授权一次推送，用户点一次只能收一条。所以我的做法是在小程序里做了个“续订”按钮，每次打开日报时提醒续订，这样能保证推送不断。

5.4 几个我踩过的坑和独家技巧

第一个坑：API Key 硬编码在代码里。这个习惯很危险，一旦代码泄露 Key 就废了。正确做法是把 Key 放到环境变量或配置中心，代码里只引用变量名。

第二个坑：没有做幂等。有一次任务因为网络问题重试了，结果同一天生成了两份日报，推送了两条。后来我加了幂等判断：同一天只允许生成一份日报，重复触发直接跳过。

第三个技巧：给日报加一个“历史归档”。每天生成的日报除了推送，还存一份到本地或云盘，按日期命名。这样时间长了能回看，也能做趋势分析。我用的是最简单的按年月分文件夹存文本文件，够用就行。

第三个坑：忽略小程序的年审和合规。小程序上线后是有年审要求的，如果只是自己用，可以走体验版或者开发版，避免年审的麻烦。但如果要长期稳定用，还是得把合规这块处理好，不然某天突然不能用了会很被动。

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

跑通之后我发现，这套“定时 + 生成 + 推送”的骨架其实很通用，换个内容源和提示词就能变成别的工具。

比如把信息源换成我关注的几个技术博客，日报就变成“技术阅读清单”；换成行业新闻，就变成“行业简报”；甚至可以做成“每周复盘提醒”，每周五下午自动把这一周的工作记录汇总成一份复盘草稿推给我。核心逻辑没变，变的只是喂给模型什么和提示词怎么写。

另外一个扩展方向是多端触达。现在只推微信，后面如果我想在电脑上也能看，可以用 uniapp 的多端能力再编译一个桌面端或者网页版，数据源还是同一份。这就是当初选 uniapp 而不是原生小程序的原因——给自己留了扩展的余地。

我个人在实际操作中的体会是，做这类个人自动化工具，别追求一步到位。先把最小闭环跑通，哪怕日报内容很粗糙，只要“定时生成 + 能收到”这条链路通了，后面优化内容质量就是水到渠成的事。最怕的是一开始就想做完美，结果卡在某个细节上，最后整个项目不了了之。先跑起来，再慢慢调，这是我做了这么多自动化项目最实在的一条经验。