1. 为什么我要给 WorkBuddy 定一个“上午十点半”的闹钟
每天早上到工位，第一件事不是泡咖啡，而是打开各种信息源翻一遍：行业动态、竞品更新、社区里冒出来的新工具、昨天没看完的技术讨论。这件事本身不复杂，但极其消耗注意力——你会在不知不觉中刷掉四十分钟，然后发现自己真正想干的活还没开始。更麻烦的是，信息是碎片化的，今天看到一条，明天忘了，等到真正需要某个资料的时候，又得重新搜一遍。
我用的工具是 WorkBuddy，一个可以挂载技能、按规则执行任务的工作台。它本身支持定时触发和消息推送，这就给了我一个很自然的想法：能不能让它每天早上自动帮我跑一遍信息收集，整理成一份结构化的日报，然后直接推送到微信里？这样我通勤路上或者刚到工位的时候，打开微信就能看到一份已经整理好的内容，而不是自己去各个地方翻。
这个想法落地之后，实际效果比我预期的好。核心链路其实就三段：定时触发 → 调用 AI 能力做内容整理 → 通过微信通道推送。听起来简单，但中间有几个地方如果不注意，要么推不出来，要么推出来的东西没法看。下面我把整套流程拆开讲，包括我踩过的坑和最后稳定运行的配置方式。
提示：这篇文章面向的是已经对 WorkBuddy 有基本了解、想把它用在实际自动化场景里的人。如果你还没装过，建议先把基础环境跑通再回来看，不然有些概念会对不上。
2. 拆解这条自动化链路：从定时器到微信消息的完整路径
2.1 整条链路的三个关键节点
把“每天十点半收到一份 AI 日报”这件事拆开，本质上是一条流水线：
| 节点 | 职责 | 常见实现方式 |
|---|---|---|
| 触发层 | 在指定时间启动任务 | WorkBuddy 内置定时规则 / 系统级计划任务 |
| 处理层 | 抓取信息、调用模型整理 | WorkBuddy 技能 + DeepSeek 等模型接口 |
| 推送层 | 把结果送到微信 | 微信通道（服务号模板消息 / 企业微信应用消息 / 小程序订阅消息） |
这三个节点里，触发层最容易被低估。很多人以为“设个时间就行”，但实际上定时任务的时区、错过补偿、并发控制都会影响最终能不能稳定收到消息。处理层是内容质量的核心，模型选得好不好、提示词写得清不清楚，直接决定日报是“能看”还是“废话连篇”。推送层则是最后一公里，微信的通道限制比较多，选错通道会导致消息被折叠、延迟甚至收不到。
2.2 为什么选上午十点半而不是更早
时间点的选择不是随便定的。我试过几个时间：
- 早上七点：太早，信息源本身还没更新完，抓到的内容偏少，而且我自己还没进入工作状态，看了也记不住。
- 早上九点：刚好是通勤和到岗的混乱期，消息推过来容易被其他通知淹没。
- 上午十点半：这个时间点大部分信息源已经完成当日首轮更新，我自己也处理完了紧急邮件，正好有几分钟可以安静看一份日报。
另外从任务执行角度看，十点半这个时间点系统负载相对平稳，模型接口的响应速度也比早晚高峰更稳定。这个细节看起来无关紧要，但实际跑下来，接口超时的概率确实低了不少。
2.3 推送通道的选择逻辑
微信侧能用的推送方式主要有三种，我逐一试过：
- 服务号模板消息：需要认证服务号，有明确的模板格式限制，适合结构化数据，但申请门槛较高。
- 企业微信应用消息：如果本身在用企业微信，这是最省事的方式，支持 Markdown 格式，消息不会折叠。
- 小程序订阅消息：需要用户主动订阅，适合 C 端场景，但每次订阅只能推有限条数。
我最后选的是企业微信应用消息，原因是它对内容格式的容忍度最高，支持 Markdown 渲染，日报里的标题、列表、加粗都能正常显示。如果你没有企业微信，服务号模板消息也能用，但需要把日报内容压缩成固定字段，可读性会打折扣。
注意：不管用哪种通道，都要先确认消息发送频率限制。企业微信应用消息默认有频率控制，短时间内大量推送会被限流，日报这种一天一条的场景完全没问题，但如果你打算做多条推送，要提前算好配额。
3. 让 WorkBuddy 按规则干活：定时触发与技能配置的实操细节
3.1 定时规则的写法与常见误区
WorkBuddy 的定时触发支持类似 cron 的表达式，但有几个地方和标准 cron 不太一样。我一开始直接套用标准写法，结果任务根本没跑起来。
正确的配置思路是这样的：
schedule: type: cron expression: "30 10 * * *" timezone: "Asia/Shanghai" misfire_policy: "fire_once"这里有几个关键点：
- 时区必须显式指定。WorkBuddy 默认可能使用 UTC，如果不写时区，你设的十点半实际会在北京时间下午六点半执行。我第一次跑的时候就是这个问题，等了半天没动静，查日志才发现时间对不上。
- misfire_policy 决定错过任务后的行为。如果十点半那一刻服务正好在重启，任务被错过了，
fire_once会在恢复后补跑一次，skip则直接跳过。日报场景建议用fire_once，避免某天完全收不到。 - 表达式字段顺序要确认清楚。有些工具是“分 时 日 月 周”，有些是“秒 分 时 日 月 周”，写错一位就全乱了。
3.2 技能挂载：让 WorkBuddy 知道“做什么”
定时只是告诉它“什么时候动”，具体“动什么”要靠技能配置。我的做法是把整个日报生成流程拆成三个技能，按顺序执行：
- 信息采集技能：负责从预设的信息源拉取内容。这里我用的是 HTTP 请求节点，配置了几个固定的数据源地址，每个源设置独立的超时和重试次数。
- 内容整理技能：把采集到的原始内容交给模型处理，输出结构化的日报。这一步是核心，提示词的设计直接决定输出质量。
- 消息推送技能：把整理好的内容通过微信通道发出去。
技能之间的数据传递用 WorkBuddy 的上下文变量，前一个技能的输出存到变量里，后一个技能直接引用。这样做的好处是每个环节可以独立调试，出问题的时候能快速定位是哪一步挂了。
3.3 信息采集环节的容错设计
采集环节最容易出问题。信息源可能超时、可能返回格式变了、可能直接挂掉。如果不做容错，一个源出问题就会导致整个任务失败。
我的处理方式是：
- 每个源独立请求，互不影响。一个源失败不影响其他源继续采集。
- 设置合理的超时时间，我一般给 10 秒。超过 10 秒还没返回的源，直接放弃，记录日志但不阻塞流程。
- 对返回内容做基本校验，比如检查是否为空、是否包含预期字段。校验不通过的内容直接丢弃，不进入后续处理。
这样即使某个源当天不可用，日报里少一块内容，但整体流程不会断。实测下来，这种设计让任务的日成功率从最初的七成左右提升到了接近百分之百。
4. 日报内容怎么整理才不像“机器拼凑”：模型调用与提示词设计
4.1 模型选型：为什么我用 DeepSeek 做内容整理
内容整理这一步，我试过几个不同的模型接口。最后选 DeepSeek 的原因是它在中文内容的理解和重组上表现比较稳，尤其是把零散信息归纳成有条理的段落这件事，输出质量明显好于一些通用模型。
调用方式上，我用的是标准的 API 接口，通过 WorkBuddy 的 HTTP 请求节点发送。关键参数配置如下：
{ "model": "deepseek-chat", "temperature": 0.3, "max_tokens": 2000, "top_p": 0.9 }temperature 设成 0.3是刻意压低的。日报需要的是稳定、准确的信息归纳，不需要创意发挥。温度太高会导致每天的输出风格飘忽不定，有时候还会自己编内容。0.3 这个值实测下来既能保证语言流畅，又不会偏离原始信息太远。
max_tokens 控制在 2000是因为微信消息有长度限制，而且太长的日报我自己也看不完。2000 个 token 大概能输出一千多字的中文，足够覆盖当天的重要信息。
4.2 提示词的结构化设计
提示词是决定日报质量的关键。我前后改了十几版，最后稳定下来的结构是这样的：
你是一个信息整理助手。请根据以下原始内容，生成一份简洁的日报。 要求： 1. 按主题分类，每类用二级标题 2. 每条信息用一句话概括，不超过 50 字 3. 保留关键数据和来源 4. 如果某类信息为空，跳过该类 5. 不要添加原文中没有的内容 6. 输出格式为 Markdown 原始内容： {{collected_content}}这里有几个设计意图：
- 明确分类要求：不分类的话，模型会把所有内容堆成一大段，读起来很累。
- 限制单条长度：一句话概括逼着模型做信息压缩，避免把原文直接复制过来。
- 禁止编造：这条很重要。模型有时候会“脑补”一些看起来合理但原文没有的内容，明确禁止之后这种情况少了很多。
- 指定输出格式：直接要求 Markdown，省去了后续格式转换的步骤。
4.3 处理模型返回的异常情况
模型接口不是每次都稳定返回。我遇到过几种异常：
- 返回内容为空：偶尔会发生，可能是接口波动。我的处理是重试一次，如果还是空就跳过当天日报，记录日志。
- 返回格式不对：比如要求 Markdown 但返回了纯文本。这种情况我会做一个简单的格式检查，不符合就重新请求。
- 返回内容过长：超过微信消息限制。这时候需要做截断，保留前面的核心内容，末尾加一个“内容过长已截断”的提示。
这些异常处理逻辑看起来繁琐，但正是这些细节决定了自动化任务能不能长期稳定运行。我见过太多人把流程跑通一次就放着不管，结果过几天就悄无声息地挂了。
5. 把日报送进微信：推送环节的配置与踩坑记录
5.1 企业微信应用消息的配置步骤
如果你也用企业微信，配置流程大致如下：
- 在企业微信管理后台创建一个自建应用，记录下
AgentId和Secret。 - 获取企业的
CorpId。 - 在 WorkBuddy 的推送技能里填入这三个参数。
- 构造消息体，指定接收人和内容格式。
消息体的结构大概是：
{ "touser": "@all", "msgtype": "markdown", "agentid": YOUR_AGENT_ID, "markdown": { "content": "{{daily_report_content}}" } }touser填@all会发给应用可见范围内的所有人，如果只想发给自己，填自己的用户 ID。
5.2 我踩过的三个坑
第一个坑：消息内容里的特殊字符导致发送失败。日报内容里如果有某些特殊符号，会导致 JSON 解析出错。解决办法是在拼接消息体之前，对内容做一次转义处理，把引号、换行符这些转成合法格式。
第二个坑：access_token 过期。企业微信的 access_token 有效期是两小时，如果 WorkBuddy 的任务间隔超过两小时，每次都要重新获取。我的做法是在推送技能里先请求一次 token，拿到之后立即使用，不做缓存。这样虽然多一次请求，但避免了 token 过期的问题。
第三个坑：消息发送成功但没收到。这种情况一般是接收人配置有问题，或者应用可见范围没设置对。排查的时候先确认touser是否正确，再去企业微信后台检查应用的可见范围。
5.3 消息格式的优化
企业微信的 Markdown 支持有限，不是所有语法都能渲染。我实测下来，这些是有效的：
- 标题（
#、##、###） - 加粗（
**text**） - 无序列表（
-） - 引用（
>） - 链接（
[text](url)）
表格和代码块不支持，所以日报内容里要避免这两种格式。我在提示词里也做了相应约束，让模型输出时避开不支持的语法。
6. 稳定运行一个月后，我总结出的几条经验
6.1 日志是排查问题的第一手资料
WorkBuddy 每次执行任务都会产生日志，包括每个技能的执行状态、耗时、输出摘要。我养成了一个习惯，每周抽五分钟翻一下日志，看看有没有异常重试、超时或者格式错误。大部分问题在变成故障之前，都会先在日志里露出苗头。
比如有一次我发现采集环节的耗时从平均 3 秒涨到了 15 秒，查下来是某个信息源的响应变慢了。虽然还没到超时阈值，但我提前把那个源的超时时间调低，避免了后续可能的失败。
6.2 内容质量需要定期校准
模型输出的日报质量不是一成不变的。信息源的内容风格变化、模型本身的更新，都可能影响输出效果。我大概每两周会完整看一遍当天的日报，检查几个点：
- 分类是否合理，有没有该合并的类别被拆开
- 单条概括是否准确，有没有偏离原文
- 有没有出现原文没有的内容
发现偏差就调整提示词，重新跑一次验证。这个过程不需要很频繁，但完全不管的话，日报会慢慢变得没法看。
6.3 不要把鸡蛋放在一个篮子里
我现在的工作流里，除了微信推送，还会把日报同时存一份到本地文件。这样即使推送环节出问题，我还能从文件里找到当天内容。多一个备份的成本很低，但关键时刻能省很多事。
另外，如果某天任务完全失败，我会收到一个简单的告警通知——不是通过微信，而是通过另一个独立通道。这样避免了“推送通道本身出问题导致告警也收不到”的死循环。
6.4 关于 WorkBuddy 规则的一些补充
WorkBuddy 支持设置全局规则，对所有任务生效。我设了几条：
- 所有 HTTP 请求默认超时 10 秒
- 所有任务失败后最多重试 2 次
- 所有输出内容默认做敏感词过滤
这些规则省去了在每个技能里重复配置的麻烦，也保证了行为的一致性。如果你还没用过这个功能，建议花几分钟设一下，长期来看能省不少事。
整套流程跑下来，我最大的感受是：自动化工具的价值不在于“炫技”，而在于把那些重复、琐碎但又不得不做的事接管过去，让你能把注意力放在真正需要思考的地方。一份每天准时出现的日报，看起来只是省了十几分钟，但它带来的是一种“信息不会漏掉”的安心感。这种安心感，才是持续使用自动化工具的真正动力。
