1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”

每天早上到工位，第一件事不是泡茶，而是打开各种信息源：项目群里的讨论、订阅的技术博客、几个固定的行业资讯站，还有自己关注的几个开源仓库的更新。一圈刷下来，二十分钟没了，而且信息是碎的——今天看到一条模型更新的消息，明天可能就忘了它跟手头哪个项目有关。这种“手动聚合”的活儿，本质上就是重复劳动，而且人脑在早上刚开机的时候，处理效率并不高。

我想要的其实很简单：每天上午十点半，一份已经整理好的 AI 日报，自动出现在微信里。不用我主动去问，不用我打开任何 App，它就像闹钟一样准时。这个需求听起来不复杂，但真要做起来，涉及几个关键环节：谁来抓信息、谁来整理、谁来推送、怎么保证每天准时触发。WorkBuddy 在这个链路里扮演的是“调度中枢”的角色，它负责把定时触发、任务执行和消息推送串起来。

这篇文章适合两类人看。一类是已经用过 WorkBuddy 或者类似自动化工具，但还没把它跟微信生态打通的；另一类是听说过 AI 日报、想自己搭一套但不知道从哪下手的。我会把整个搭建过程拆开讲，包括为什么选这个方案、每个环节的坑在哪、参数怎么调，以及我实测下来哪些做法是稳的、哪些是花架子。核心关键词就几个：WorkBuddy、AI、微信、自动化、DeepSeek，整篇内容都围绕这几个词展开。

先说结论：这套方案跑通之后，我每天早上十点半准时收到一份结构化的日报，包含模型动态、工具更新、值得看的文章摘要，以及一条“今日建议关注”的提示。整个过程不需要我干预，唯一要做的就是偶尔调整一下信息源的权重。

2. 拆解这条自动化链路：从触发到落地的四个环节

2.1 定时触发：为什么选十点半而不是更早

时间点的选择是有讲究的。我试过早上八点推送，结果发现那个时间段我还在通勤或者刚坐下，根本没心思看。也试过中午十二点，但那时候信息已经积压了一上午，日报的“新鲜度”下降了。十点半这个时间点，是我实测下来最舒服的：早上的紧急事务已经处理得差不多，离午饭还有一段完整的时间，可以静下心来看一份整理好的内容。

在 WorkBuddy 里设置定时触发，核心是 cron 表达式的配置。如果你不熟悉 cron，可以把它理解成一个“闹钟语法”，用五个或六个字段来描述“什么时候执行”。比如每天上午十点半，对应的表达式是：

30 10 * * *

这五个字段分别代表分钟、小时、日、月、星期。30 10 * * *的意思就是“每天十点三十分”。如果你只想在工作日推送，可以改成30 10 * * 1-5，这样周六周日就不会打扰你。

注意：WorkBuddy 的定时任务默认使用服务器时区。如果你的服务器是 UTC 时间，而你在东八区，那30 10 * * *实际会在北京时间下午六点半触发。我踩过这个坑，第一次配置完等了一天没收到消息，后来才发现是时区没改。解决办法是在任务配置里显式指定时区，或者把 cron 表达式换算成 UTC 时间。

2.2 信息抓取：日报的“原料”从哪来

日报的质量取决于原料的质量。我一开始贪多，塞了十几个信息源进去，结果每天生成的日报又长又杂，反而增加了阅读负担。后来我做了减法，只保留三类来源：

• 模型与工具官方动态：比如 DeepSeek 的 API 更新日志、常用开源库的 release notes。这类信息时效性强，错过可能影响手头的开发计划。
• 技术社区的高赞讨论：筛选过去 24 小时内热度上升最快的几个话题，取摘要和链接。
• 我自己的待办与关注列表：从笔记工具里同步过来的“今天需要跟进的事项”，让日报跟我的实际工作挂钩。

抓取方式上，能用 API 的优先用 API，没有 API 的就用 RSS。RSS 虽然老，但胜在稳定、结构化好解析。实在没有 API 也没有 RSS 的，才考虑用页面解析，但这种方式维护成本高，对方页面一改版就得跟着改。

import feedparser import requests def fetch_rss(url): feed = feedparser.parse(url) items = [] for entry in feed.entries[:5]: items.append({ "title": entry.title, "link": entry.link, "summary": entry.get("summary", "")[:200] }) return items def fetch_api(endpoint, headers): resp = requests.get(endpoint, headers=headers, timeout=10) if resp.status_code == 200: return resp.json() return None

这段代码没什么特别的，但有一个细节值得说：timeout=10一定要加。我遇到过某个源响应极慢，导致整个抓取任务卡住，后面的推送全部延迟。加了超时之后，即使某个源挂了，也不会影响整体流程。

2.3 内容整理：DeepSeek 在中间做了什么

抓回来的原始信息是散的，直接推送到微信里阅读体验很差。这时候需要一层“整理”，把多条信息压缩成一段可读的摘要，并且按重要性排序。我用的是 DeepSeek 的 API 来做这件事。

具体做法是：把抓取到的标题和摘要拼成一个 prompt，让模型输出一份结构化的日报。prompt 的设计很关键，我试过几种写法，最后稳定下来的版本大概是这样的：

prompt = f""" 你是一个技术日报编辑。请根据以下原始信息，生成一份简洁的 AI 日报。 要求： 1. 按重要性排序，最重要的放在最前面。 2. 每条信息用一句话概括，不超过 50 字。 3. 如果某条信息与模型更新、工具发布相关，标注出来。 4. 最后给出一条“今日建议关注”，说明为什么值得看。 原始信息： {raw_content} """

这里有个经验：不要让模型自由发挥。早期我给的指令太宽松，结果模型加了很多“综上所述”“值得关注”之类的废话，日报变得又臭又长。后来我把输出格式卡死，要求每条不超过 50 字，整体控制在 500 字以内，可读性立刻上来了。

另外，DeepSeek 的 API 调用要注意 token 消耗。如果原始信息很多，可以先做一轮本地过滤，把明显不相关的条目去掉，再送给模型。这样既省钱，又减少模型“分心”的概率。

2.4 推送落地：怎么把消息送进微信

这是整个链路里最容易被卡住的一环。微信不像 Slack 或 Telegram 那样有开放的机器人 API，个人开发者想往微信里推消息，通常有几条路：

我最终选的是企业微信机器人。原因很简单：它本质上是一个 webhook，你往一个固定的 URL 发 POST 请求，消息就会出现在企业微信的群里。如果你把企业微信和微信绑定，消息还能同步到微信上。配置过程大概是这样：

1. 在企业微信里创建一个群，群成员可以只有你自己。
2. 在群设置里找到“群机器人”，添加一个机器人。
3. 复制机器人的 webhook 地址，格式类似https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx。
4. 在 WorkBuddy 的任务里，用 HTTP 请求节点往这个地址发消息。

import requests import json def send_to_wechat(webhook_url, content): headers = {"Content-Type": "application/json"} payload = { "msgtype": "markdown", "markdown": { "content": content } } resp = requests.post(webhook_url, headers=headers, data=json.dumps(payload)) return resp.status_code

提示：企业微信机器人的消息频率有限制，每分钟最多 20 条。对于日报这种一天一条的场景，完全够用。但如果你打算做实时告警，就要注意这个限制。

3. WorkBuddy 任务配置的实操细节与参数调优

3.1 任务编排：把四个环节串成一条流水线

WorkBuddy 的任务编排界面支持把多个步骤串起来，前一步的输出可以作为后一步的输入。我的日报任务大概长这样：

1. 触发节点：cron 定时，每天 10:30。
2. 抓取节点：并行请求多个信息源，汇总结果。
3. 整理节点：调用 DeepSeek API，生成日报文本。
4. 推送节点：发送到企业微信 webhook。
5. 日志节点：把本次执行的结果写入本地文件，方便回溯。

这里有个设计上的取舍：抓取节点要不要并行？我一开始用的是串行，结果发现如果某个源响应慢，整体时间会被拉长。后来改成并行之后，总耗时从平均 40 秒降到了 12 秒左右。WorkBuddy 支持并行分支，配置起来也不复杂，把多个抓取步骤放在同一个并行组里就行。

但并行也有代价：如果某个源挂了，错误处理会麻烦一些。我的做法是给每个抓取步骤单独设置超时和重试次数，并且允许“部分失败”——也就是说，即使有一个源没抓到，其他源的结果照样往下走，不影响整体流程。

3.2 错误处理：日报没收到时怎么排查

自动化任务最怕的就是“静默失败”——你以为它在跑，其实早就挂了。我遇到过几次十点半没收到日报的情况，排查下来原因各不相同：

• 时区问题：前面提过，服务器 UTC 时间导致触发时间偏移。
• API 额度耗尽：DeepSeek 的免费额度用完之后，整理节点直接报错。
• webhook 失效：企业微信机器人被移除或者 key 被重置。
• 网络抖动：某个信息源临时不可达，导致抓取节点超时。

为了快速定位问题，我在任务里加了一个“执行日志”节点，每次运行都把关键信息写到一个本地文件里，包括：触发时间、各节点耗时、抓取到的条目数、API 返回状态、推送结果。这样一旦出问题，直接看日志就能知道是哪一环挂了。

# 日志文件示例 2025-01-15 10:30:01 | trigger | cron fired 2025-01-15 10:30:03 | fetch | rss_source_a: 5 items 2025-01-15 10:30:05 | fetch | api_source_b: 3 items 2025-01-15 10:30:08 | fetch | rss_source_c: timeout, skipped 2025-01-15 10:30:12 | summarize | deepseek api: 200 OK, tokens: 1200 2025-01-15 10:30:13 | push | wechat webhook: 200 OK

注意：日志文件要定期清理，不然跑几个月之后会占不少空间。我一般设置保留最近 30 天的日志，更早的自动删除。

3.3 内容质量调优：怎么让日报“说人话”

日报生成出来之后，我自己会读一遍，看看有没有需要调整的地方。早期版本有几个典型问题：

• 信息密度太低：每条都是“某某发布了某某更新”，但没有说这个更新意味着什么。
• 排序不合理：把一些边角料信息放在了前面，真正重要的反而沉底了。
• 语气太机械：读起来像机器翻译，没有“人味”。

针对这些问题，我做了几轮 prompt 调优。核心思路是给模型更明确的“编辑角色”和“读者画像”。比如在 prompt 里加上：“你是一个有五年经验的技术编辑，读者是每天需要快速了解 AI 动态的开发者。请用简洁、直接的语言，避免套话。”这样模型输出的内容会明显更贴近真实阅读习惯。

另外，我还会在 prompt 里给几个“好例子”和“坏例子”，让模型知道什么样的输出是合格的。这种做法在少样本学习里很常见，实测下来对输出质量的提升很明显。

4. 实测中踩过的坑与稳定运行的经验

4.1 微信推送的“隐形门槛”

企业微信机器人虽然配置简单，但有几个细节容易忽略。第一，webhook 地址里的 key 是敏感信息，不要直接写在代码里，更不要提交到公开仓库。我的做法是把它放在环境变量里，任务配置时通过变量引用。

第二，企业微信机器人默认只支持文本和 markdown 两种消息类型。markdown 的语法支持有限，比如不支持表格、不支持图片嵌入。如果你想让日报看起来更丰富，可以用 markdown 的标题和列表，但别指望能做出复杂的排版。

第三，消息长度有限制。markdown 类型的消息最长 4096 字节，超过会被截断。我的日报控制在 500 字以内，所以没遇到过这个问题，但如果你打算推送长文，就要考虑分段发送。

4.2 DeepSeek API 的调用节奏

DeepSeek 的 API 性价比很高，但有几个使用上的细节值得注意。首先是 rate limit，免费额度和付费额度的限制不同，如果你在短时间内频繁调用，可能会触发限流。我的日报任务一天只调用一次，所以没遇到这个问题，但如果你打算做实时摘要，就要考虑加一个队列或者退避重试。

其次是 token 计算。DeepSeek 的计费是按输入和输出的 token 总数来的。如果你的原始信息很长，输入 token 会很大。我的做法是在本地先做一轮过滤，把明显不相关的条目去掉，只把最相关的 10 到 15 条送给模型。这样既省钱，又提高输出质量。

# 本地过滤示例：只保留包含关键词的条目 keywords = ["模型", "更新", "发布", "开源", "API", "工具"] filtered = [item for item in items if any(kw in item["title"] for kw in keywords)]

4.3 让日报“活”起来的几个小技巧

跑了一段时间之后，我发现日报如果每天格式完全一样，读起来会腻。后来我加了几个小变化：

• 随机排序：在保证重要信息靠前的前提下，次要信息随机排列，每天看起来略有不同。
• 一句话点评：让模型在每条信息后面加一句简短的点评，比如“这个更新对做 RAG 的同学影响较大”。
• 周末特辑：周六周日的日报改成“本周回顾”，汇总过去七天的重点，而不是只报当天。

这些改动都不复杂，但让日报从“机器输出”变成了“有人味的内容”。我甚至收到过同事的反馈，说看到我转发的日报之后，也跟着搭了一套。

5. 从日报到更广的自动化：这套思路还能怎么用

5.1 把“闹钟”扩展到其他场景

日报只是这套链路的一个应用。同样的结构——定时触发、抓取、整理、推送——可以套用到很多场景：

• 每日站会提醒：早上九点推送当天待办和昨日进展。
• 竞品动态监控：定时抓取竞品官网和社交账号，整理成简报。
• 个人知识库更新：把每天读到的好文章自动归档到笔记工具。
• 运维告警聚合：把多个监控系统的告警汇总成一条消息，避免被刷屏。

关键是把“触发、抓取、整理、推送”这四个环节抽象出来，每个环节都可以替换成不同的实现。比如推送环节，除了企业微信，还可以换成邮件、Slack、Telegram，甚至短信。

5.2 关于 WorkBuddy 和 CodeBuddy 的配合

如果你同时用 WorkBuddy 和 CodeBuddy，可以把两者串起来。CodeBuddy 负责代码相关的任务，比如自动跑测试、生成代码摘要，WorkBuddy 负责调度和推送。我试过让 CodeBuddy 每天跑一次项目的单元测试，把结果交给 WorkBuddy 整理成报告，再推送到微信。这样即使我不在电脑前，也能随时掌握项目状态。

5.3 一些值得关注的扩展方向

这套方案目前跑得挺稳，但还有几个方向可以继续优化。一是增加“反馈闭环”，比如我在微信里回复某个关键词，系统能根据回复调整第二天的日报内容。二是引入更细粒度的权限控制，如果日报要分享给团队，不同角色看到的内容可以不一样。三是把日报数据存下来，做趋势分析，比如“过去一个月模型更新频率的变化”。

这些扩展不一定都要做，但思路是通的：自动化的价值不在于一步到位，而在于持续迭代。先跑通最小闭环，再根据实际使用中的痛点逐步优化，这样每一步都踩在真实需求上，不会为了自动化而自动化。

我个人在实际操作中的体会是，这套东西最大的门槛不是技术，而是“想清楚自己要什么”。信息源选哪些、日报给谁看、推送频率多少，这些问题想明白了，剩下的就是配置和调试。十点半的闹钟只是一个开始，真正有意思的是，你开始用自动化的思维去重新审视那些每天重复的事情。