每天早上 10:30我的微信会准时收到一条推送标题是“AI 日报”里面七八条消息每条一两句话讲完当天 AI 圈最值得看的事末尾附原文链接。这不是哪个订阅号替我整理好的是我给 WorkBuddy 设的闹钟它替我盯着几十个信息源抓取、去重、让大模型提炼再把结果送进微信。这套东西从搭好到现在跑了两个多月翻过车也优化过好几轮。今天把完整的方案写出来包括为什么选 WorkBuddy 来做这件事、定时任务怎么配、日报内容怎么生成、微信推送走什么渠道合规又稳定以及我踩过的那些坑。适合想搭个人信息流水线的开发者、AI Agent 玩家还有每天早上不想刷几十个网站的职场人参考。1. 为什么给 WorkBuddy 设闹钟而不是自己攒脚本1.1 先想明白你要的其实不是“日报”是“筛选后的注意力”信息过载这件事说起来大家都懂收藏夹里几百篇“稍后读”真正点开的不超过 10%。我做 AI 相关的工作每天要看的源头特别多——Hacker News、GitHub Trending、ArXiv、技术公众号、几个 Product Hunt 上榜产品……如果全靠自己刷光点开标签页就要半小时更别说读完。所以日报这个需求本质不是“收集”是“筛选和压缩”。我要的不是把所有链接罗列出来而是有人帮我把 100 条信息变成 8 条每条都告诉我“这件事为什么值得看”。如果直接用 Python 写个爬虫加 cron也能实现但那等于我自己又造了一个需要维护的系统要处理反爬、要管理数据库、要写摘要逻辑、要处理各种异常。这违背了做日报的初衷——省时间。那时候我刚接触 WorkBuddy发现它跟我理解的那种“聊天机器人”不一样它更像一个 Agent 工作台能编排任务、能定时触发、能调用外部接口、能手写规则约束模型行为还能把流程封装成 Skill 复用。于是我决定把这个“闹钟”交给它试试。1.2 WorkBuddy 到底适合干这件事吗选型对比说结论适合但要看你怎么用。我拿它和几种常见方案做过对比方案上手难度定时能力自定义摘要逻辑维护成本适合场景cron Python 脚本高强全靠自己写高数据管道复杂、需要精细控制无代码自动化平台类 Zapier低强弱靠模板中轻量通知不折腾 promptWorkBuddy 编排中强强可写规则和 Skill低Agent 类任务、需要 LLM 参与的流程纯 LLM 聊天框低无强但每次都要重复说低临时性提问不适合定时任务我实际体验下来WorkBuddy 在这件事里最舒服的一点是它把“调度”、“模型调用”、“HTTP 请求”这些原本要我自己写代码的活变成了可视化节点。我只需要关心业务逻辑不需要自己写一个调度器也不用管请求重试这些脏活。另一个加分项是它的 Skill 和全局规则机制。后面我会详细说简单讲就是我可以在全局定几条规则让所有任务都遵守不用每次都在 prompt 里重复。这对我这种说话经常省略的人来说太省事了。如果你只是需要一个“每天定时发一句话”的提醒那用任何工具都行但要生成高质量日报WorkBuddy 的编排优势就出来了。2. 拆解“10:30 日报自动进微信”的完整链路2.1 定时触发闹钟是怎么响起来的定时这部分本质是一个 cron 表达式。我要的是每天早上 10:30 执行一次表达式是0 30 10 * * *。拆开看分0时10日、月、周都是*意思是每天 10:30 的 0 分 0 秒触发。为什么选 10:30 而不是 10:00我有两个考虑一是整点是很多公司定时任务的集中时段外部接口容易出现瞬时拥堵晚半小时跑各家的推送、榜单基本已经更新完了二是我自己的习惯10 点刚坐下处理邮件10:30 收到的日报正好可以当“第二杯咖啡”配着看。这里有个容易踩的坑时区。WorkBuddy 或者其他平台的定时调度默认可能走 UTC。如果你写0 30 10 * * *但系统按 UTC 执行那实际触发时间是北京时间 18:30日报变晚报。我配置完后第一件事就是确认时区设置把它固定成 Asia/Shanghai。别以为这是小事我身边真有人日报一个月都没收到最后发现是时区差了 8 小时。还有一点测试时别干等。很多平台支持“立即执行一次”用来验证流程是否跑通。我的习惯是先在配置界面找到手动触发按钮把整条链路验证通过后再挂上定时规则。先人肉触发再相信闹钟。2.2 信息采集日报的“料”从哪里来日报好不好看信息源决定 80%。我现在的信息源分成三类官方 APIGitHub Trending、Hacker NewsAlgolia API、ArXiv、Product Hunt这些有稳定接口优先用。RSS个人博客、技术媒体、少数不支持 API 的站点用 RSS 兜底。页面解析基本不用只对极个别“只有网页没有 feed”的站点保留而且做好了随时失效的心理准备。优先级很好记官方 API 大于结构化 JSON大于 RSS最后才是页面解析抓取。原因很简单页面改版就会抓挂RSS 至少是半结构化API 最稳。我最早偷懒直接用页面解析抓一个科技媒体结果对方一改版我的日报里连续三天出现“解析失败无法定位标题节点”这种话后来老老实实换成了 RSS。实操里我在 WorkBuddy 的采集节点里维护一个信息源列表每个源都标了类型、地址、拉取策略。比如 GitHub Trending 每天拉一次就够了频率设低点Hacker News 的 hot 列表可以稍微频繁点但日报任务本身一天就执行一次所以单次抓取即可。每个源我给 10 秒超时失败就跳过绝不让单个源的异常拖垮整个任务。还有个细节采集结果千万别一股脑塞给模型。我的做法是先做预处理只保留每篇文章的标题、链接、摘要RSS 自带摘要最好没有就截取正文前一两百字把正文全文留在“需要深读时再点进去”。这样既省 token又避免模型被长文本带偏节奏。2.3 摘要生成怎么让 AI 把 100 条变成 8 条这一步是整个日报的灵魂。我踩过两个极端一是让模型自由发挥结果它写出来的东西像公关稿每条都在“赋能”“助力”二是约束太死只准列标题结果信息密度太低跟看榜单没区别。后来我把摘要任务的核心逻辑固定成一套提示词模板效果稳定了很多你是一名 AI 领域的信息编辑现在根据我提供的抓取结果生成今日日报。 要求 1. 最多输出 8 条按“重要性”降序排列。 2. 每条先写一句话结论这条信息是什么再写一句点评为什么值得关注。 3. 必须保留原始标题并在末尾附上原文链接。 4. 语气克制、直接禁止“赋能、抓手、助力”这类空话。 5. 如果某条信息与其他条目高度重复只保留最完整的一条。 6. 全部输出为 Markdown 列表每条不超过两行。这套 prompt 跑出来的日报基本就是我想要的样子有结论、有观点、有出处。注意第 6 条我强制了输出格式模型在约束明确的时候表现会稳定很多。为了避免重复我还在 WorkBuddy 里加了个前置去重逻辑对抓取结果的标题做简单归一化转小写、去掉空格和特殊符号再跟前一天的标题集合做比对完全一致的直接排除。这个“前一天的集合”我存成缓存数据任务启动时读取结束后更新。效果很明显GitHub 上同一项目连续两天霸榜时我的日报不会再出现两条一模一样的消息。模型参数方面摘要这种任务我建议把 temperature 调低0.2 左右让输出尽量稳定不要每天风格都不一样。最大输出 token 也要设我一般设 1000够写 8 条了超出会被截断反而难看。2.4 消息推送把日报平安送进微信标题说的是“自动送进微信”但这里必须非常讲究。想让消息进微信最直接想到的是个人微信号自动化登录去发消息但这条路径我强烈不建议一方面协议风险很高号可能被限制另一方面实现方案依赖非官方接口稳定性极差今天能用明天可能就挂。合规又稳的方案有三类我都试过方案推送形式优点注意点企业微信群机器人 Webhook群内消息免费、简单、支持 Markdown每分钟限 20 条需建一个群Server酱 / PushPlus个人微信通知适合“只有自己”的推送依赖第三方服务免费版有限额企业微信应用消息个人微信/企微通知官方接口、稳定要创建自建应用配置稍多我现在主力用的是企业微信群机器人 Webhook理由很朴素我拉了一个只有我自己还有两个小号的群把 Webhook 地址填到 WorkBuddy 的 HTTP 节点里POST 一段 JSON 就完事Markdown 格式也支持看起来舒服。示例数据长这样{ msgtype: markdown, markdown: { content: ## AI 日报 2024-12-18\n1. [标题]链接\n 点评文字 } }Server酱我也用过适合不想折腾企业微信的人注册后拿一个 SendKey用 GET 请求就能推送延迟通常一两秒接受度很高。注意不要把 Webhook 地址或者 SendKey 写死在公开仓库里泄露出去的 token 等于把推送能力交到别人手上被刷消息还是小事关键是你的“数字身份”被人利用了。我在 WorkBuddy 里是把密钥放配置项的不写进日报流程本身。3. 手把手配置从零搭一条可复用的日报流水线3.1 第一步创建工作流先手动跑通再定时我的建议是无论你用 WorkBuddy 还是别的编排平台都遵循一个原则先手动跑通再加定时。原因很简单定时任务的错误成本比手动高得多——如果你让它每天 10:30 跑结果提示词写错了你得到第二天才能发现问题。具体步骤我这么做的在 WorkBuddy 里新建一个任务/工作流命名为ai-daily-digest。先不加定时触发器直接用平台提供的“运行一次”功能手动执行采集节点。确认采集返回的数据里有标题、链接没有乱码和空值。再手动执行摘要节点看输出格式是否符合预期。最后手动执行推送节点给自己发一条测试消息检查微信里显示是否正常。全部通过后再去配置里加上 cron 定时规则设为每天 10:30。这套“三步手动验证法”我几乎是铁律采集、摘要、推送每段都单独验一遍而不是等整条链路串起来后对着失败日志猜问题。实测下来90% 的配置失误都能在第一步阶段暴露。还有一个不起眼但重要的设置任务日志。WorkBuddy 里每个节点的输入输出都会留日志初期的几次运行我会专门把日志调成“详细模式”看看中间数据到底长什么样。别嫌日志麻烦自动化任务出问题时日志就是你唯一的现场。3.2 第二步把“日报专家”沉淀成 Skill跑了小半个月我发现每天新建任务、重新填信息源和提示词太蠢了于是把整个日报流程封装成了 WorkBuddy 里的一个 Skill。打个比方Skill 像一个可复用的“能力包”它有名字有输入参数有内嵌的 prompt 和执行步骤。我把“AI 日报”这个 Skill 定义成输入信息源列表、期望条数、日期输出一份 Markdown 日报文本。内部逻辑就是采集、去重、摘要、格式化那套。这样做的好处是什么之后我想做一个“AI 论文早报”或者“前端动态日报”不需要重新搭工作流新建一个任务引用同一个 Skill只改信息源列表就行。这跟写代码里“把重复逻辑抽成函数”是同一个思路只不过 WorkBuddy 把它做成了可视化操作不写代码也能复用。封装 Skill 的时候我的经验是把“可变的东西”全部设计成输入参数而不是写死在 Skill 内部。比如信息源列表、条数限制、语气偏好这些都作为入参Skill 内部只保留稳定的规则和流程。否则你会为了“今天想看 10 条”又去改 Skill 本体反而难维护。3.3 第三步给 WorkBuddy 定规则让后续所有任务都遵守这一步是让整个系统真正“省心”的关键。WorkBuddy 支持设置一些全局规则这些规则不写在单个任务的 prompt 里而是对所有任务统一生效。你可以理解成“宪法”下层的每个 Skill、每个任务的具体 prompt都不能和它冲突。我给自己定了这么几条所有 AI 生成的内容涉及事实信息时必须附来源链接。禁止使用“赋能、抓手、闭环、助力”等空话套词。生成的日报/报告必须标注数据日期防止读者误以为是当天更新。输出格式优先使用 Markdown便于阅读和转发。当信息不足或抓取失败时要明确说明失败原因不许编造内容。这几条规则加上去之后最直观的变化是我不再需要在每个任务里重复叮嘱模型“记得附链接”了。以前用纯 LLM 对话时我每次都要重新洗脑一遍模型很累现在规则挂在那里新任务进来自动遵守。尤其是最后一条“不许编造”对自动化内容生产来说特别重要——AI 的幻觉问题加上无人值守的定时任务如果不去约束它会一本正经地给你编一条根本不存在的“业界新闻”而你早上喝着咖啡就相信了。有一点要注意规则不是越多越好。我一开始写了十几条结果模型在单次任务里反而顾此失彼输出变长、格式混乱。后来精简到五条每条都是硬约束效果明显变好。规则的本质是给模型划底线不是教它做事。3.4 第四步参数调优与失败兜底配置的最后一步是把“异常情况”都想好。自动化任务最怕的不是出错而是出错后你还不知道连续错了一个星期才在某个早晨发现“咦今天怎么没日报”。我现在的参数配置大致是这样采集节点每源超时 10 秒失败自动跳过单次任务最多采集 50 条原始信息。摘要节点temperature 0.2max tokens 1000超时 60 秒失败重试 2 次。推送节点超时 15 秒失败重试 1 次重试仍失败时发送一条告警到另一个渠道比如备用邮箱。兜底机制如果摘要节点失败直接推送原始采集链接的标题列表并在开头注明“摘要生成失败先看原始信息”。最后这个兜底非常实用。我的思路很简单日报可以写得粗糙但不能空手。宁可让你看到一份没有点评的清单也比什么都没收到强得多。很多人的自动化任务挂掉其实不是因为技术做不到而是因为“容错设计”缺位——默认一切顺利结果一条链路出问题整个系统静默死亡。另外记得给任务设置执行时间上限。比如整个流程 5 分钟内没跑完就强制结束防止某个节点卡死占着资源。这个我跟平台方的人聊过他们也建议长任务都加个看门狗超时不然排查问题时会很被动。4. 实操中的踩坑与排查实录4.1 常见问题速查表把这两个月的踩坑经历浓缩一下。下面这几个问题基本覆盖了定时推送类任务 90% 的翻车现场先看这张表现象大概率原因排查方式解决办法微信一直没收到日报定时配置时区不对、Webhook token 失效、任务因异常中断查执行日志确认任务有没有真的跑起来先手动执行一次看推送节点日志返回的 HTTP 状态码日报里内容重复同一条新闻在不同信息源出现去重逻辑没生效检查标题集合缓存是否更新增加跨源去重步骤按标题归一化后比对摘要被截断格式乱输出 token 上限太小或模型把 Markdown 写断了查看摘要节点输出长度提高 max tokens把输出限制改为“8 条以内”链接打不开页面解析规则随站点改版失效看采集日志里“解析失败”节点切换到官方 API 或 RSS不要死磕页面解析任务今天跑、明天不跑服务器时区漂移、偶发调度失败看任务的最近执行记录和时间戳加“错过补偿”如 10:45 再补一次检查这里我最想强调的就是日志。很多人配置完就不管了直到某天发现日报断更才追悔莫及。我的经验是每两周翻一次执行日志花十分钟扫一遍有没有“警告”或者“失败重试”的痕迹。自动化系统不是不生病而是生了病要能及早发现。4.2 微信推送的安全边界必须守住的底线关于微信推送我再展开讲一次。市面上有一些开源工具可以模拟个人微信端去自动发消息看起来很美好但我的观点很明确别拿自己的主号开玩笑。这类工具往往需要你扫码登录让第三方脚本控制你的微信账号这背后的风险有三层。第一层是账号安全一旦被平台风控轻则限制登录重则永久封号第二层是隐私风险你的聊天数据、联系人信息全都经过第三方逻辑等于把家门钥匙交给陌生人第三层是稳定性个人微信接口是黑盒版本一升级就可能全线失效。合规渠道虽然多一步配置但换来的是长期稳定。我目前最推荐企业微信群机器人理由前面说过免费、简单、支持 Markdown。如果你没有企业微信那就用 Server酱或 PushPlus它们会把消息推到你绑定的个人微信里本质上也是官方通道安全得多。还有一条安全细节容易被忽略腾讯的 Webhook 地址泄露问题。我曾经看到有人把企业微信群机器人的 Webhook 地址直接贴进博客文章里结果被不明身份的人拿去刷垃圾消息。你在配置时务必把地址放进密钥管理不要写死在任务日志里更不要提交到公开代码仓库。密钥泄露后发现得早还可以在群设置里重置地址发现得晚就真的只能看垃圾消息了。4.3 成本控制让日报“够用”而不是“烧钱”有人可能会想每天让大模型读几十篇文章token 费用会不会爆炸。其实运营下来成本非常低关键看你怎么控制。我的做法是分三层省钱。第一层是内容裁剪进入 LLM 之前先做分层处理抓回来的原始内容只保留标题、链接、摘要全文不进模型。第二层是频率控制日报一天只跑一次没有高频触发如果某个信息源更新很慢我会把它挪到周报里去而不是天天抓。第三层是模型选型摘要任务我用中等能力的模型就够了不需要每次都调最大最强的那个最强的模型留给“需要深度分析”的周报任务。具体成本没细算过但以我的使用强度每天一次、每次二十来个信息源、输出 8 条摘要一个月下来也就是一杯咖啡的钱。如果你用的是有免费额度的模型甚至可以不花钱。这里还要提一个容易被忽略的开销失败重试。如果某个节点设计成“失败就疯狂重试”而外部接口持续超时token 消耗会呈倍级上涨。所以我的重试策略是“最多 2 次间隔拉长”防止一次故障把预算打空。5. 这套“闹钟”还能干什么5.1 同一套底座做晚报、周报、盯盘当你把“日报”抽象成“定时采集 摘要 推送”这套流程后它可以干的事远超“AI 日报”。改一个 cron 表达式它就是另一种产品。比如我想每晚 18:00 收到当天的关键技术动态总结就在定时配置里把表达式改成0 0 18 * * *把信息源收窄到“今天变化比较大的仓库和论文”。每周一早上想看上周的行业大事件就改成0 8 * * 1摘要条数放宽到 15 条语义也从“快速浏览”变成“周度复盘”。更实用的场景是盯变化把某个竞品的官网更新、某个开源项目的 issue、某个平台的价格页面加为信息源每天推送“有变化”的通知正文就是 diff 摘要。以前你得手动刷新、手动比对现在自动化帮你盯着只在真正发生变化时才响。这个“盯变化”的思路比日报本身更值得复用。5.2 把日报路线变成一个可分享的 Agent现在 WorkBuddy 的这套流程在我这是以 Skill 的形态存在的。这意味着它不只是“我电脑里的一个脚本”而是可以被复制、被分享、被别人个性化改用的产品雏形。比如我同事想搭一个“前端周报”他不需要从零设计流程把我这个 Skill 拿过去替换信息源列表和期望条数就能用。我自己也会把一些做得比较通用的 Skill 分享出去别人再用的时候整个流程里最复杂的提示词工程、去重策略、兜底逻辑都已经封装好了。最后说点个人体会。这套“闹钟”用久了我最大的感受不是“我省了多少时间”而是每天早晨打开微信时已经有人替我把这世界过滤了一遍。但越用我越觉得自动化最需要警惕的不是技术故障而是内容失真。AI 会把事实说得像真的一样所以我的日报里有一条铁律永远不变每一条都必须附上原文链接。我不会完全相信模型替我做的判断但链接不会骗人点开检查永远是我的最终保障。如果你也想搭这么一套我的建议是从最简单的三个信息源开始先跑通再慢慢加料。别一上来就追求“大而全”一个能每天稳定送达的 3 源日报远胜于 30 个源却频繁翻车的系统。这跟写代码是一个道理——先让最小闭环跑起来再谈扩展。