每天上午十点半微信准时弹出一条消息点开是一份排版清爽的 AI 日报——这件事我已经稳定跑了小半年。最开始只是想省掉每天早上手动刷各种信息源、复制粘贴到备忘录的十分钟后来发现真正有意思的不是省时间而是把定时触发 内容聚合 消息推送这条链路彻底跑通之后你能往里塞任何东西竞品动态、行业新闻、自己关注的几个技术方向的更新、甚至每天固定要提醒自己做的几件事。这篇就把我给 WorkBuddy 设这个闹钟的完整思路拆开讲从为什么要这么设计、每个环节怎么选、到实际跑起来之后踩的那些坑尽量说透。核心链路其实就三段定时调度负责在十点半这个点把任务叫醒内容生成负责把原始信息变成一份能读的日报消息投递负责把结果塞进微信。听起来简单但每一段都有好几种做法选错了后面全是返工。下面按我实际落地的顺序来讲。1. 为什么是十点半和微信这两个锚点1.1 时间点的选择不是拍脑袋很多人做自动化第一反应是越早越好设个早上七点醒来就能看。我一开始也这么干结果发现两个问题一是七点这个时间大部分信息源还没更新完抓到的内容是残缺的日报质量很差二是那个点我自己根本没心思看消息躺在那里等真正需要的时候已经过时了。十点半这个点是我试了大概两周之后定下来的。原因很实在大部分我关注的信息源在上午九点到十点之间完成当天的首轮更新十点半抓取能拿到相对完整的内容同时这个时间点我通常已经进入工作状态扫一眼日报正好用来规划当天要做的事。定时任务的时间点应该服务于你什么时候真的会看而不是你想什么时候看这两个经常不是一回事。1.2 微信作为投递终端的现实考量投递渠道我对比过几种邮件、企业协作工具、独立 App 推送、微信。最后选微信不是因为它技术上有优势恰恰相反微信的推送限制是最多的。选它的唯一理由是打开率——微信是我一天里打开次数最多的应用消息进来几乎不可能漏看而邮件我可能两天才翻一次。这里有个关键认知自动化任务的价值不在于生成了什么而在于生成的东西有没有被消费。一份躺在邮箱里没人看的日报和没生成是一样的。所以投递渠道的选择标准应该是你最高频查看的入口而不是技术上最优雅的方案。提示如果你的日报是给团队看的投递渠道要选团队最高频使用的协作工具而不是你自己习惯的那个。个人习惯和团队习惯经常冲突以团队为准。1.3 WorkBuddy 在这个链路里的角色定位WorkBuddy 在这里承担的是调度中枢 任务编排的角色。它本身不生产内容也不直接投递消息而是负责在指定时间把整条流水线拉起来按顺序执行各个步骤处理中间的错误和重试。理解这一点很重要因为很多人会误以为 WorkBuddy 是个内容工具然后试图把所有逻辑都塞进它里面结果就是配置越来越臃肿出了问题根本不知道是哪一环。我的做法是把职责切干净WorkBuddy 只管什么时候、按什么顺序、调用谁具体的内容抓取、格式化、推送各自独立成模块。这样任何一环出问题我都能单独定位和替换不会牵一发动全身。2. 定时调度这一环WorkBuddy 的规则怎么定才不返工2.1 从一次性任务到长期规则的思维转变新手最容易犯的错是把定时任务当成一次性任务来配。比如直接设一个每天十点半执行的简单触发器跑起来发现某天失败了第二天不会自动补或者失败了也没有任何通知你根本不知道它挂了。正确的做法是从一开始就按长期运行的服务来设计。我在 WorkBuddy 里给这个日报任务定的规则大致是这几条触发时间每天 10:30但允许 ±5 分钟的浮动窗口避免整点资源竞争导致的延迟失败重试单次执行失败后间隔 3 分钟重试最多重试 2 次超时控制整个任务链路超过 8 分钟未完成则强制终止并告警执行日志每次执行都记录开始时间、各步骤耗时、最终状态这几条规则看起来琐碎但每一条都是踩坑之后加的。比如超时控制是因为有一次某个信息源响应极慢任务卡在那里半个多小时后面的步骤全乱了。2.2 规则要对后续所有任务生效该怎么理解WorkBuddy 里有个很容易被忽略的点规则的作用域。你可以给单个任务定规则也可以定一套全局规则让后续所有任务继承。我建议通用的容错规则重试、超时、日志设成全局业务相关的规则触发时间、内容范围设在单个任务上。这么分的好处是以后你再加新的自动化任务容错能力是白送的不用每次重新配一遍。我现在的全局规则里就固定了重试策略、超时阈值、日志格式这几项新任务接进来直接继承省了大量重复配置。2.3 调度失败的三种典型表现和排查顺序调度这一环出问题表现通常有三种排查顺序也不一样表现最可能的原因排查入口到点完全没触发触发器配置错误或任务被禁用先看任务状态是否 active触发了但没产出中间步骤报错被吞掉看执行日志的步骤级状态产出了但没收到投递环节失败单独测投递模块我遇到最多的是第二种——任务显示已执行但日报没出来。这种情况九成是某个中间步骤抛了异常但被上层捕获后静默处理了。所以日志一定要记录到步骤级别不能只记任务成功/失败否则你永远不知道是哪一步断的。3. 日报内容从哪来信息聚合的取舍逻辑3.1 信息源不是越多越好我一开始贪心接了十几个信息源结果日报长得像流水账自己都不想看。后来砍到五个反而每天都会认真读完。这里有个反直觉的结论日报的价值和信源数量成反比。信源越多单条信息的筛选成本越高最后你干脆不看了。我现在的信源结构是这样的两个行业新闻源、一个竞品动态源、一个技术社区热榜、一个我自己维护的待办清单。前四个负责输入最后一个负责提醒。这个结构跑下来日报长度稳定在一屏半左右五分钟能读完。3.2 抓取环节的稳定性处理抓取是整条链路里最脆弱的一环因为外部信息源你控制不了。我的处理原则是**抓不到就跳过绝不阻塞**。具体做法是每个信源独立抓取单个失败不影响其他失败的源在日报末尾标注本次未获取而不是让整个任务挂掉。另外抓取一定要设超时。我见过太多因为某个源响应慢导致整个任务卡死的案例。单个源的超时我设的是 15 秒超过就放弃记录到日志里。这个值可以根据你的源的实际响应速度调整但一定要有。3.3 内容清洗和去重原始抓取的内容通常很脏有 HTML 标签残留、有重复条目、有广告。这一步不能省否则日报读起来很难受。我的清洗流程是去掉所有 HTML 标签只保留纯文本按标题做去重相似度超过阈值的只保留一条过滤掉包含特定关键词的条目比如明显的推广内容每条内容截断到合理长度避免单条占满整个日报去重这一步特别重要。很多信息源之间会互相转载不去重的话你会在日报里看到同一条新闻出现三四次体验极差。4. 用 DeepSeek 把原始信息变成能读的日报4.1 为什么需要模型介入原始抓取的内容是碎片化的直接拼起来就是一堆标题和摘要的堆砌读起来累。模型在这里的作用是做二次加工把碎片信息归纳成有逻辑的段落、提炼出当天最值得关注的几条、用统一的语气重写。我用的 DeepSeek主要是因为它在这个任务上的性价比合适——日报生成不需要特别强的推理能力但需要稳定的中文表达和足够低的调用成本因为这是每天都要跑的任务。4.2 提示词的设计要点提示词我改了很多版最后稳定下来的结构是这样的你是一个日报编辑。以下是今天从各个信息源抓取到的原始内容 {raw_content} 请完成以下任务 1. 从中筛选出最重要的 5-8 条按重要性排序 2. 每条用一句话概括不超过 40 字 3. 在开头写一段 2-3 句的今日概览 4. 保持客观不要添加原文没有的信息 5. 输出格式为纯文本不要用 Markdown 标记几个关键点明确数量范围不然模型可能给你 20 条也可能给你 2 条、限制单条长度不然会写得很啰嗦、要求纯文本因为最终要进微信Markdown 标记会显示成乱码、强调不添加原文没有的信息防止模型编造。4.3 模型输出的兜底处理模型不是每次都听话偶尔会输出格式不对、或者内容明显跑偏。所以一定要有兜底如果模型返回的内容为空、或者长度异常比如超过正常范围太多就降级使用原始内容的简单拼接版本保证日报至少能出来而不是整个任务失败。这个兜底逻辑我强烈建议加上。我遇到过模型服务临时波动返回了空内容如果没有兜底那天的日报就彻底没了。5. 把日报送进微信投递环节的实操细节5.1 投递方式的选择把内容送进微信有几种路径我实际用过的是通过微信生态内的消息通道推送。这里不展开具体的技术实现细节重点讲选择逻辑优先选官方支持的、稳定的通道不要为了省事用非正规手段。非正规手段短期能跑通但随时可能失效维护成本极高。5.2 消息格式的适配微信里显示的内容对格式很敏感。我踩过的坑包括换行符处理不当导致所有内容挤成一行、特殊字符导致消息发送失败、内容过长被截断。处理经验是发送前一定要做一次格式预检。具体包括把连续多个换行合并成一个、去掉所有可能引起解析问题的特殊字符、如果内容超过长度限制就自动分段发送。这几步加起来代码不多但能避免 90% 的显示问题。5.3 投递失败的感知投递失败最麻烦的地方是静默失败——你以为发出去了其实没有。所以投递环节必须要有回执确认。我的做法是投递后检查返回状态如果失败就记录到日志并触发一次告警可以是通过另一个渠道给自己发个提醒。注意不要假设投递一定成功。任何跨系统的调用都要当作可能失败来处理这是自动化任务稳定运行的基本心态。6. 跑稳之后才发现的几个坑6.1 时间漂移问题定时任务跑久了会出现时间漂移——本来该十点半触发的慢慢变成十点三十五分、十点四十。原因是任务执行时间不固定如果调度器是基于上次执行完成后间隔多久来算下一次误差会累积。解决办法是用绝对时间触发而不是相对间隔触发。也就是明确指定每天 10:30而不是每 24 小时一次。这个区别在短期看不出来跑一两个月就很明显了。6.2 内容重复的隐蔽来源前面说了去重但有一种重复很隐蔽同一个事件在不同信源里的表述不同简单的标题去重抓不到。比如A 公司发布新产品和A 公司今日推出新品标题不一样但说的是同一件事。我的处理是在模型加工那一步让模型自己判断并合并而不是在抓取阶段做。因为模型对语义的理解比字符串匹配强得多让它来合并同类项效果更好。6.3 日报越来越水的退化跑了一两个月之后我发现日报质量在下降具体表现是内容越来越泛、越来越像通稿。排查后发现是信源本身的问题——有些源更新频率下降开始用旧内容充数。这个坑的教训是信源要定期体检。我现在每个月会看一次各信源的贡献度长期贡献低质量内容的源直接砍掉。日报质量不是一劳永逸的需要持续维护。6.4 别把链路搞得太长我一度想加很多功能自动分类、情感分析、趋势图。后来发现每加一个环节失败概率就上升一次而且调试难度指数级增长。最后砍回到抓取-清洗-加工-投递四步稳定性和可维护性都好了很多。自动化任务的设计哲学应该是**够用就好稳定优先**。花哨的功能不如稳定跑一年。7. 如果你想复刻这套东西我的建议顺序先跑通最小闭环一个信源、一次抓取、一次模型加工、一次投递。这四步能跑通整条链路就成立了。然后再逐步加信源、加容错、加日志、加告警。不要一上来就追求完美架构。我见过太多人花两周设计了一套完美的方案结果第一步抓取就没跑通然后整个项目就搁置了。先让它跑起来再让它跑得好这个顺序不能反。另外日志从第一天就要认真做。不是为了好看是为了出问题的时候你能快速定位。我现在回头看最有价值的投入就是那套步骤级的日志它让我在每次出问题时都能在几分钟内找到原因而不是靠猜。这套东西跑到现在最大的感受是自动化的价值不在于省了多少时间而在于它把一件需要记得做的事变成了不需要记得也会发生的事。这种确定感比省下来的那十分钟值钱得多。