1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”每天早上到工位第一件事不是打开编辑器而是先刷一遍昨天夜里堆积的消息、群聊、邮件和几个内容平台的热榜。这个动作看起来只花十几分钟但真正消耗的是注意力切换成本——你刚进入状态又被一条新消息拽走等回过神来半小时没了。我试过用各种待办工具、RSS 阅读器、聚合面板最后发现真正能解决问题的不是“再多一个看板”而是让信息主动来找我而且只来一次、来在固定时间。这就是我给 WorkBuddy 设“十点半闹钟”的出发点每天上午 10:30让一个 AI 代理自动把过去 24 小时里我关心的内容整理成一份日报直接推送到微信。我不需要打开任何新 App不需要记任何网址微信里那条消息就是我的“信息早餐”。关键词里的WorkBuddy、AI、微信、自动化、deepseek基本就是这套方案的五个支柱WorkBuddy 负责调度和技能编排AI 负责摘要与筛选微信负责触达自动化负责定时deepseek 这类模型负责把原始内容压成可读的短句。这套东西适合谁如果你每天需要跟踪固定几个信息源、又不想被信息流牵着走或者你已经在用 WorkBuddy 做零散任务、想把它升级成“有节奏的助手”那这篇内容可以直接抄作业。它不要求你会写复杂后端也不要求你懂微信底层协议核心就是定时触发 数据抓取 模型摘要 微信推送这四步。下面我会把每一步拆开讲包括我踩过的坑和最后稳定下来的配置思路。提示整条链路里最容易被低估的是“推送触达”这一步。很多人把摘要做得很漂亮结果卡在微信侧发不出去或者发出去格式全乱。所以我会把微信推送单独拎出来讲透。2. WorkBuddy 的定时机制闹钟到底挂在哪里2.1 为什么不用系统 cron 而用 WorkBuddy 自带调度一开始我图省事直接在服务器上写了个 crontab每天 10:30 跑一个 Python 脚本。跑了两天就发现问题脚本本身能跑但 WorkBuddy 里的技能状态、上下文、模型调用配额是分散的cron 触发的脚本和 WorkBuddy 里的会话完全是两套东西。结果就是日报内容和我平时在 WorkBuddy 里积累的偏好对不上模型每次都要重新“认识”我。后来我把触发点挪回 WorkBuddy 内部用它的定时任务/计划任务能力来挂这个闹钟。这样做的好处很直接任务运行时天然带着我的技能配置、自定义指令和历史上下文模型不需要从零开始。WorkBuddy 的调度粒度通常支持到分钟级设10:30完全没问题。如果你用的是国际版或者 Linux 环境调度入口位置可能略有差异但逻辑一致——找到“计划任务”或“定时触发”这一类入口新建一个每天固定时间执行的任务。这里有个细节时区。我有一次把任务设成 10:30结果实际推送是 18:30排查半天发现是容器时区默认 UTC。所以设完闹钟第一件事就是确认运行环境的时区和你所在时区一致。可以在任务里先跑一条打印当前时间的指令验证。2.2 任务里到底放什么技能编排的基本结构WorkBuddy 的定时任务不是一个空壳它里面要挂具体的执行逻辑。我的做法是把整个日报拆成三个可复用的技能/步骤采集技能负责从固定信息源拉取过去 24 小时的内容。信息源可以是 RSS、公开 API、你关注的几个页面甚至是你自己维护的一份链接清单。摘要技能把采集到的原始文本交给模型按我给定的模板压缩成日报格式。推送技能把最终文本通过微信通道发给我。这三个技能在 WorkBuddy 里可以串成一条流水线。关键点是每一步的输出格式要约定好否则第二步拿到的是一坨乱文本模型摘要质量会断崖式下跌。我一般让采集技能输出 JSON字段固定为title、source、time、raw_text摘要技能只读这几个字段推送技能只认摘要技能输出的digest字段。这样任何一步出问题都能快速定位是哪一环。注意如果你的 WorkBuddy 版本支持“自定义指令”强烈建议把日报的格式要求写进指令里而不是每次在提示词里重复。比如“输出必须包含今日要闻三条、值得关注的一条、一句话总结”这样模型每次输出结构都稳定。2.3 十点半这个时间点是怎么选出来的很多人会问为什么是 10:30 而不是早上 8:00。我实测下来的原因是8 点推送的信息很多是凌晨产生的质量参差10:30 刚好是上午工作节奏稳定下来、昨夜到今晨的信息也基本沉淀完毕的时间点。而且 10:30 推送不会和早会冲突你开完会回来正好看到一份已经整理好的日报直接进入深度工作。如果你所在团队有固定的站会时间可以把闹钟往后挪到站会结束后 15 分钟。核心原则是推送时间要落在你“愿意停下来读两分钟”的窗口里而不是你最忙的时候。我试过 9:00 推送结果连续一周都是已读不回后来改到 10:30 才真正用起来。3. 日报内容从哪来采集环节的取舍与清洗3.1 信息源不是越多越好而是要“可摘要”我最初贪心一口气接了十几个源结果日报变成了一篇三千字的流水账模型摘要完还是很长读起来比我自己刷还累。后来砍到5 个以内并且每个源都问自己一句这个源的内容模型能不能在 200 字内说清楚如果不能要么换源要么只取标题。比较稳的源类型包括结构化的 RSS、有稳定字段的公开接口、你自己整理的链接列表。不太适合直接丢给模型的是纯图片流、需要登录才能看全文的页面、以及评论区比正文还长的社区帖。后者不是不能做而是清洗成本高容易把噪声带进日报。采集时我会做一层轻量清洗去掉 HTML 标签、去掉重复的空行、把超长正文截断到 2000 字以内。截断这一步很关键因为模型上下文有限你把一篇一万字的文章塞进去摘要质量反而下降。截断策略我一般用“前 1500 字 后 500 字”保证开头和结论都在。3.2 去重和时间窗口过去 24 小时怎么算“过去 24 小时”听起来简单实际做起来有两个坑。第一个坑是时间字段格式不统一有的源给的是时间戳有的是 ISO 字符串有的是“3 小时前”这种相对时间。我的处理方式是统一转成时间戳再比较相对时间就按当前时间倒推。第二个坑是重复内容同一个事件被多个源报道如果不去重日报里会出现三条几乎一样的要闻。去重我用的方法比较土但有效对标题做归一化去标点、转小写然后算相似度超过阈值就只保留最早的那一条。阈值我设在 0.8 左右实测能干掉大部分重复又不会误杀真正不同的内容。如果你不想写相似度计算也可以简单按“标题前 10 个字符”做粗去重效果差一点但够用。3.3 采集失败的兜底不要让一条源拖垮整份日报任何自动化链路都会遇到某个源挂掉的情况。我的原则是单源失败不影响整体每个源单独 try-catch失败就记录一条“该源今日不可用”继续跑下一个。这样即使某个源临时抽风你收到的日报里只是少了一块而不是整份消失。另外我会在日报末尾附一行“数据源状态”比如“5 个源中 4 个正常”。这行信息看起来不起眼但能让你快速判断今天这份日报的可信度。如果连续几天某个源都失败你就知道该去修它了而不是等到某天发现漏了重要信息才回头查。4. 让 deepseek 把原始内容压成“人话日报”4.1 提示词结构角色、任务、格式、约束摘要环节是整个链路里最影响体验的一步。我试过直接丢一句“帮我总结一下”结果模型输出要么太啰嗦要么抓不住重点。后来固定成四段式提示词结构角色你是一名信息筛选助手服务对象是每天只有两分钟阅读时间的从业者。任务从以下内容中选出最重要的三条每条用一句话说明“发生了什么”和“为什么值得关注”。格式严格按“今日要闻 / 值得关注 / 一句话总结”三段输出不要额外解释。约束总字数不超过 300 字不要编造原文没有的信息不确定的内容标注“待确认”。这个结构的好处是可复现。你不需要每次调提示词只要把原始内容塞进“以下内容”部分就行。deepseek 这类模型对结构化提示词的遵循度比较高输出格式基本稳定。4.2 为什么我坚持让模型“标注不确定”这是我从一次翻车里学到的。有次日报里出现了一条“某项目已上线”的消息我转发给同事后才发现是模型把“计划上线”理解成了“已上线”。从那以后我在提示词里强制要求凡是原文没有明确说“已完成/已发布”的一律保留原文的时态不确定就写“待确认”。这个约束看起来降低了日报的“干脆感”但它极大提升了可信度。你读日报是为了快速判断不是为了被误导。宁可看到“某项目计划本周上线待确认”也不要看到一句斩钉截铁的错话。4.3 摘要长度和条数的实测调参我试过几种组合5 条 × 60 字、3 条 × 100 字、3 条 × 80 字。最后稳定在3 条要闻 1 条关注 1 句总结总字数 250 到 300 字。原因是微信消息在手机上阅读超过 300 字就需要滑动滑动就会打断阅读节奏。3 条要闻刚好覆盖“必须知道”的信息量再多就开始稀释重点。如果你跟踪的领域信息量特别大可以做成“要闻 3 条 简讯 5 条每条 20 字”的两级结构。简讯只给标题和来源不展开需要细节再点链接。这样既保证覆盖面又不牺牲可读性。5. 把日报送进微信推送通道的选择与格式处理5.1 为什么微信推送比邮件和 App 通知更有效我对比过邮件、系统通知、微信三种触达方式。邮件的打开率最低因为邮箱里全是别的东西系统通知容易被忽略而且换设备就没了微信的优势是它本来就是你每天高频打开的应用消息到达即被看到。而且微信消息可以转发、可以收藏、可以稍后读天然适合“日报”这种需要二次处理的内容。需要说明的是这里说的微信推送指的是合规的消息触达方式比如通过企业微信应用消息、微信服务号模板消息、或者你自己搭建的合规通知通道。具体用哪种取决于你的账号类型和开发权限。我个人的选择是走企业微信应用消息因为配置相对直接消息格式支持 Markdown 子集适合日报排版。5.2 消息格式Markdown 在微信里的实际表现微信消息对 Markdown 的支持是有限的。我实测下来加粗、换行、有序列表基本可用但表格、代码块、复杂嵌套列表经常渲染异常。所以日报的格式我做了简化用**今日要闻**做小标题不用多级标题。每条要闻用1. 2. 3.有序列表不用嵌套。来源和链接放在每条末尾用短横线分隔。不用表格需要对比的信息改成“AxxxBxxx”这种一行式表达。这样处理之后消息在 iOS 和 Android 微信里显示基本一致不会出现“我这边好看、你那边乱码”的情况。5.3 推送失败的常见原因和排查顺序推送环节出问题我一般按这个顺序查排查项常见现象处理方式凭证过期返回鉴权错误重新获取 access token检查有效期消息体超长发送成功但内容被截断压缩到 300 字以内或拆成两条格式不合法返回参数错误去掉表格和代码块只保留基础 Markdown频率限制偶发发送失败加退避重试避免短时间重复发送网络超时任务卡住不结束设置超时时间失败后记录日志我遇到最多的是消息体超长和格式不合法。前者靠控制字数解决后者靠简化格式解决。这两个问题解决后推送稳定性基本在 99% 以上。提示推送成功后建议在日志里记一条“已送达 时间戳”。这样当你某天没收到日报时能快速判断是“没发出去”还是“发出去了但你没看到”。6. 跑通之后我才发现的几个坑6.1 模型调用超时导致整条链路卡死定时任务最怕的不是报错而是卡住不动。我有一次任务跑了 40 分钟还没结束最后发现是模型调用没有设超时网络抖动时一直挂着。后来我给每个步骤都加了超时采集 60 秒、摘要 120 秒、推送 30 秒。任何一步超时就跳过并记录保证整条链路在 5 分钟内一定结束。这个改动看起来简单但它把“偶发卡死”变成了“可控降级”。即使模型服务临时不稳定你最多收到一份不完整的日报而不是什么都收不到。6.2 日报内容“太像 AI 写的”怎么破早期日报读起来有一股明显的机器味比如“综上所述”“值得注意的是”这种词反复出现。我的解决办法是在提示词里加一条禁用词列表明确要求不要使用“综上所述、值得注意的是、随着……的发展、在……背景下”这类表达。同时要求每条要闻以具体主语开头比如“某团队发布了……”“某平台调整了……”而不是“有消息称……”。另外一个技巧是给模型一个示例。我在提示词里放了一条我手写的要闻作为范例模型会模仿这个语气。实测下来加了示例之后日报的可读性提升非常明显。6.3 周末和节假日的“空日报”问题工作日信息量大日报很充实。但周末信息源更新少模型经常输出“今日无重要更新”。这种日报推过来反而让人烦躁。我的处理方式是加一个最小条数判断如果采集到的有效内容少于 3 条就跳过推送或者只推一句“今日信息较少已跳过”。这样既避免打扰又不会让你怀疑系统是不是挂了。如果你希望周末也收到可以把周末的采集窗口拉长到 48 小时或者把阈值降低到 1 条。这个完全看个人习惯没有标准答案。7. 我现在的日常使用方式和一点个人体会这套东西跑稳之后我的早晨节奏变成了这样10:30 微信弹出一条日报我花两分钟读完把其中一条转发给相关同事把另一条收藏进待办然后继续手头的事。整个过程不需要打开任何新页面也不需要做任何筛选决策——筛选已经在后台完成了。我最大的体会是自动化的价值不在于“省了多少时间”而在于“减少了多少次注意力切换”。你省下的那十几分钟刷信息的时间真正珍贵的是它让你保持在一个连续的思考状态里。WorkBuddy 在这里扮演的角色不是“更聪明的搜索”而是“有节奏的过滤器”。如果你准备动手我的建议是先从一个信息源 一条推送跑通确认微信能收到、格式能看再逐步加源、加摘要逻辑。不要一上来就搭大而全的流水线那样任何一环出问题你都会卡住。先跑通最小闭环再迭代这是我踩了多次坑之后最想分享的一条经验。