1. 为什么我要给 WorkBuddy 装一个“定时投递”的闹钟

每天早上到工位，第一件事不是打开编辑器，而是先刷一遍昨天夜里各个渠道冒出来的 AI 动态：新模型发布、工具更新、行业讨论、开源项目冒泡。刷完一圈，半小时没了，真正要动手的活儿还没开始。更麻烦的是，这些信息散落在各种地方，手动整理成一份能看的日报，光是复制粘贴和排版就得再花二十分钟。我试过用收藏夹、用笔记软件、用待办清单，最后都败给了“懒得整理”这四个字。

后来我换了个思路：与其让我去追信息，不如让信息在固定时间主动来找我。具体做法就是给 WorkBuddy 设一个“闹钟”——每天上午十点半，让它自动跑一遍我预设好的信息采集与整理流程，把结果直接推送到微信里。这样我十点半端起咖啡的时候，一份结构清晰的 AI 日报已经躺在聊天窗口里了。

这套东西的核心其实不复杂，关键词就几个：WorkBuddy、AI、微信、自动化、deepseek。WorkBuddy 负责调度和执行任务，deepseek 这类模型负责把原始信息加工成可读的摘要，微信负责最后的触达。整条链路跑通之后，我基本不用再操心“今天有没有漏掉什么重要动态”。

这篇文章适合两类人看：一类是每天需要跟踪大量信息、但又不想被信息淹没的从业者；另一类是想拿 WorkBuddy 做点自动化小工具、却不知道从哪下手的新手。我会把整个搭建过程拆开讲，包括为什么这么设计、每一步在干什么、踩过哪些坑，以及怎么让它稳定跑下去。你不需要有很深的编程基础，但需要对“定时任务”和“接口调用”这两个概念有个模糊的认识。

提示：本文提到的所有自动化操作，都建立在合规使用工具和接口的前提下。请确保你的使用场景符合相关平台的服务条款。

2. 拆解这条自动化链路：谁在什么时候做什么

2.1 把“日报”拆成三个独立环节

很多人一上来就想写一个“大而全”的脚本，结果卡在第一步就放弃了。我的经验是，先把整件事拆成三个互不干扰的环节，每个环节单独跑通，最后再串起来。

第一个环节是信息采集。我需要从几个固定的来源拿到原始内容，比如某些公开的技术社区、开源项目的更新日志、我关注的几个信息聚合页面。这个环节的关键是“稳定”，不要求快，但要求每次都能拿到东西。

第二个环节是内容加工。原始信息往往是零散的、重复的、甚至夹杂大量噪音。这时候就需要 deepseek 这类模型出场，让它按照我给定的模板，把原始内容压缩成几条要点，并且加上一句简短的点评。这个环节的关键是“可控”，模型输出不能太放飞，得有明确的格式约束。

第三个环节是消息投递。加工好的内容要送到微信里，最稳妥的方式是通过微信提供的官方消息推送能力，把内容以文本或图文卡片的形式发到我的对话窗口。这个环节的关键是“准时”，十点半就是十点半，不能因为前面环节慢了就拖到十一点。

把这三个环节分开之后，每个环节我都可以单独测试、单独优化。采集慢了就优化采集，模型输出跑偏了就调整提示词，投递失败就检查接口配置。互不影响，排查起来非常清爽。

2.2 为什么选 WorkBuddy 来做调度

市面上能做定时任务的工具很多，系统自带的计划任务、各种自动化平台、甚至自己写个 cron 都能实现。我选 WorkBuddy 的原因有三个。

第一，它把“任务编排”这件事做得足够直观。我不需要去记复杂的 cron 表达式，也不用在服务器上折腾环境，直接在界面里设定触发时间、执行步骤和失败重试策略就行。对于我这种不想在运维上花太多时间的人来说，这一点非常关键。

第二，它对模型调用的支持比较友好。deepseek 的接口调用在 WorkBuddy 里可以作为一个标准步骤来配置，我只需要填好接口地址和密钥，剩下的参数传递和结果解析它帮我处理了。这省掉了很多胶水代码。

第三，它的执行记录比较清晰。每次任务跑完，我都能看到每一步的输入输出和耗时。有一次日报内容不对，我顺着执行记录一路查下去，发现是采集环节某个页面的结构变了，导致拿到的内容为空。如果没有这个记录，我可能得花半天去猜问题出在哪。

注意：不同版本的 WorkBuddy 在功能入口上可能有差异，如果你找不到某个配置项，先确认一下自己的版本，再对照官方文档找对应的位置。

2.3 十点半这个时间点是怎么定下来的

时间点的选择其实有讲究。我试过几个不同的时间段，最后锁定在上午十点半，原因如下。

太早不行。比如早上八点，那时候很多信息源还没有更新完，夜里积累的内容可能还在陆续发布，跑早了会漏掉一部分。而且八点我可能还在通勤路上，推送到手机上也未必有时间看。

太晚也不行。比如中午十二点，那时候上午的工作已经进行了一半，日报来得太迟，对我上午的决策帮助就小了。我需要的是在上午工作节奏真正铺开之前，拿到一份能帮我判断“今天该关注什么”的摘要。

十点半这个位置刚好卡在一个平衡点上：大部分信息源已经完成了当天的第一波更新，我又刚好处理完早上的例行事务，有几分钟空闲可以快速浏览日报。而且这个时间点离午饭还有一段距离，如果日报里发现了值得深挖的内容，我上午还有时间跟进。

这个时间不是拍脑袋定的，你可以根据自己的作息和信息源的更新规律来调整。核心原则是：在你需要做判断之前，让信息刚好到位。

3. 信息采集环节：怎么让原始内容稳定流进来

3.1 先确定“日报里到底要有什么”

在动手写采集逻辑之前，我先拿纸笔列了一个清单：我到底希望每天在日报里看到什么？列完之后发现，我真正关心的其实只有四类内容。

第一类是模型与工具的动态，比如某个我常用的模型发布了新版本，或者某个开源工具更新了重要功能。第二类是行业内的讨论热点，不要求全面，但要知道大家在聊什么。第三类是值得收藏的技术文章或教程，可能当时没空看，但需要留个记录。第四类是我自己设定的关键词监控，比如某个特定技术方向出现了新内容。

这四类内容对应到采集环节，就是四个不同的信息来源。我不需要把全网都爬一遍，只需要盯住这几个固定的口子就行。这样做的好处是采集逻辑简单、稳定，而且出来的内容跟我的实际需求高度匹配。

3.2 采集源的选择与取舍

选择采集源的时候，我遵循一个原则：宁少勿多，宁精勿杂。一开始我贪心，加了十几个来源，结果每天采集回来的内容有大量重复，加工环节的压力非常大，模型经常被冗余信息带偏。后来我砍到四个来源，每个来源只取最近24小时内更新的一到两条内容，质量反而上去了。

具体来说，我会优先选择那些有稳定更新节奏、内容质量有基本保障的来源。比如某个项目的官方更新日志，它每次更新都是实打实的功能变化，不会夹杂太多噪音。再比如某个技术社区的精选板块，它的内容已经经过了一轮筛选，我拿过来直接用就行。

对于那些更新频率极高、内容质量参差不齐的来源，我选择放弃。因为采集回来之后，我花在筛选上的时间可能比我自己去看还多，得不偿失。

3.3 采集频率与去重策略

采集频率我设定的是每天一次，就在十点半任务触发的时候跑。为什么不设成每小时跑一次？因为我的日报是每天一份，跑那么多次没有意义，反而会增加接口调用的压力和出错概率。

去重策略是必须的。我的做法是给每条采集到的内容生成一个简单的指纹，比如把标题和来源拼在一起做一个哈希，然后跟昨天采集到的指纹列表做对比。如果发现重复，就直接跳过。这个逻辑不复杂，但能省掉很多后续的麻烦。

还有一个细节：采集的时候要带上时间戳。这样在加工环节，模型可以判断这条内容是不是“新鲜”的。如果某条内容的时间戳显示是三天前的，那它就不应该出现在今天的日报里。

提示：采集环节一定要加超时和重试机制。有些来源的响应时间不稳定，如果不设超时，整个任务可能会卡在那里。我的做法是单个来源最多等10秒，超时就跳过，记录一条日志，但不影响其他来源的采集。

4. 用 deepseek 把原始信息“压”成可读日报

4.1 提示词的设计比模型选择更重要

很多人觉得只要模型够强，输出就一定好。实际用下来，我发现提示词的设计才是决定输出质量的关键。同样的 deepseek 接口，提示词写得粗糙，出来的日报就是一堆废话；提示词写得精细，出来的内容直接能用。

我的提示词结构是这样的：先给模型一个明确的角色设定，比如“你是一个技术日报编辑，负责把原始信息整理成简洁的要点”。然后给出输出格式的硬性要求，比如“每条要点不超过两句话”“必须包含来源”“按重要程度排序”。最后再给一两个示例，让模型知道什么样的输出是合格的。

这个结构看起来简单，但每一条都有讲究。角色设定是为了让模型的语气和视角保持一致，不会一会儿像新闻播报，一会儿像技术文档。格式要求是为了让输出可以直接投递到微信，不需要我再手动调整。示例是为了让模型有一个具体的参照，减少跑偏的概率。

4.2 怎么防止模型“自由发挥”

模型有时候会自作主张，比如把一条普通更新描述成“重大突破”，或者加一些原文里没有的评论。为了防止这种情况，我在提示词里加了几条硬约束。

第一条是“只使用提供的原始内容，不要添加任何外部信息”。第二条是“如果原始内容不足以形成一条要点，就跳过，不要编造”。第三条是“点评部分必须基于原文事实，不要使用夸张词汇”。

加了这几条之后，输出的稳定性明显提升。当然，偶尔还是会有跑偏的时候，所以我在投递之前加了一个人工检查的环节——日报先发到我的文件传输助手，我扫一眼，确认没问题再转发到自己的主对话。这一步看起来多余，但实际上帮我避免了好几次尴尬。

4.3 输出格式的约束与微信的适配

微信对消息格式的支持有限，太复杂的 Markdown 渲染不出来，表格也显示不好。所以我在提示词里明确要求模型输出纯文本，用简单的符号来区分层级，比如用短横线表示列表项，用方括号表示来源。

另外，微信单条消息有长度限制，如果日报内容太长，会被截断。我的做法是让模型把内容控制在800字以内，如果确实有更多内容，就分成两条消息发送。这个长度限制我也写进了提示词里，让模型自己控制。

还有一个细节：微信里链接的展示效果不太好，所以我让模型在提到某个来源时，只写来源名称，不写完整链接。如果我真的需要链接，可以去采集记录里找。这样日报看起来更干净，也避免了链接被截断的问题。

5. 把日报送进微信：投递环节的几种做法

5.1 为什么我选择官方消息推送能力

把内容送进微信，市面上有几种做法。一种是模拟客户端操作，一种是利用微信提供的官方接口。我选择后者，原因很简单：稳定、合规、不容易出问题。

官方接口的调用方式不复杂，核心就是拿到一个访问凭证，然后调用消息发送接口，把内容推送到指定的对话。凭证有有效期，需要定时刷新，这个刷新逻辑我放在了 WorkBuddy 的任务里，每次投递之前先检查凭证是否有效，无效就自动刷新。

这种方式的缺点是配置稍微麻烦一点，需要先在相关平台完成一些设置。但一旦配好，后面基本不用管，每天准时送达，很少出问题。

5.2 投递失败时的兜底方案

再稳定的系统也有出问题的时候。我遇到过几次投递失败，原因各不相同：有时候是凭证过期了没刷新，有时候是网络波动导致请求超时，有时候是内容里包含了特殊字符导致接口报错。

针对这些情况，我做了两层兜底。第一层是重试机制：投递失败后自动重试两次，每次间隔30秒。第二层是备用通道：如果重试两次还是失败，就把日报内容写入一个本地文件，同时给我发一封邮件提醒。这样即使微信投递挂了，我也不会完全丢失当天的日报。

这个兜底方案看起来有点过度设计，但实际用下来，它帮我挽回了好几次“日报失踪”的情况。尤其是凭证过期这种问题，如果没有兜底，我可能要到第二天才发现。

5.3 消息内容的最终检查清单

在投递之前，我会让 WorkBuddy 做一次最终检查。检查项包括：内容是否为空、长度是否超限、是否包含敏感词、格式是否符合预期。任何一项不通过，就跳过投递，转入兜底流程。

这个检查清单是我根据实际踩坑经验总结出来的。比如有一次模型输出里带了一个特殊符号，导致接口直接报错，整条日报都没发出去。后来我加了特殊字符过滤，这个问题就再也没出现过。

注意：检查清单不要设得太复杂，否则会增加任务执行时间。我的原则是只检查那些“一旦出问题就会导致投递失败”的项，其他细节问题可以容忍。

6. 让这套东西稳定跑下去的几条经验

6.1 日志要记，但不要记太多

WorkBuddy 自带执行记录，但我还是额外加了一个简单的日志文件。日志里只记三样东西：任务开始时间、每个环节的耗时、最终投递结果。其他的中间数据一概不记。

为什么这么克制？因为我试过记全量日志，结果文件膨胀得很快，查问题的时候反而要在海量信息里翻找。精简之后的日志，一眼就能看出哪个环节慢了、哪个环节失败了，排查效率高很多。

6.2 定期检查采集源的有效性

采集源不是一成不变的。有些页面会改版，有些接口会调整，有些内容会停止更新。如果不定期检查，可能会出现“采集环节正常执行，但拿到的内容为空”的情况，而任务本身不会报错，你就以为日报正常，实际上里面什么都没有。

我的做法是每周花五分钟看一眼最近的采集记录，确认每个来源都有内容进来。如果某个来源连续两天没有内容，就去检查一下是不是页面结构变了或者接口调整了。

6.3 模型输出要定期“校准”

deepseek 的输出质量整体稳定，但偶尔会有波动。我每个月会抽一天，把当天的原始内容和模型输出放在一起对比，看看有没有明显的偏差。如果发现模型开始“偷懒”或者“加戏”，就调整一下提示词，重新校准。

这个习惯帮我保持日报质量在一个稳定的水平线上。毕竟自动化工具最怕的就是“看起来在跑，实际上输出已经不能用了”，定期校准是发现这种问题的有效手段。

6.4 不要把整条链路绑得太死

最后一个经验是关于架构的。我一开始把采集、加工、投递写在一个大任务里，任何一个环节出问题，整个任务就挂了。后来我把它拆成了三个独立的任务，用 WorkBuddy 的依赖关系串起来。采集任务先跑，跑完触发加工任务，加工完触发投递任务。

这样做的好处是，如果加工环节出了问题，采集环节的结果还在，我可以手动触发加工，不需要重新采集。同样，如果投递失败，加工好的内容也还在，我可以手动重发。每个环节都可以单独重跑，灵活性高了很多。

这套东西跑到现在，已经成了我每天上午的一个固定节奏。十点半，咖啡端起来，日报刚好弹出来。我不需要再去想“今天有没有漏掉什么”，因为我知道该来的都会来。如果你也在被信息追着跑，不妨试试给它设个闹钟，让信息在你需要的时候主动来找你。