每天早上十点半我的微信会准时收到一份 AI 日报当天值得关注的 AI 行业动态、模型发布、开源项目以及几条我自定义关注方向的热点全部被压成一篇可以直接读完的摘要。这不是哪个资讯 App 的订阅推送而是我用 WorkBuddy 搭出来的一条自动化链路。做法说起来很直白——给 WorkBuddy 设一个每天十点半的闹钟定时任务到点让它自动收集信息、生成日报再通过 Webhook 把内容推进微信。真正跑起来之后我从每天花一小时刷信息变成每天花五分钟看日报。这篇文章适合两类人一是想给自己或团队搭定时 AI 日报、但不知道从哪下手的人二是已经在用 WorkBuddy 这类 AI 工具、想把它从问答助手升级成自动干活的小跟班的人。我会把链路设计、定时触发、日报生成、微信推送四条线全部拆开讲最后附上我这两个月踩过的坑和排查思路。1. 为什么我要折腾这么一条日报链路1.1 信息过载的真实痛点先说背景。我每天要跟踪的东西包括AI 圈的模型和工具发布、几个垂直方向的技术动态、还有竞品相关的消息。以前我的做法是早上到工位先刷一遍 RSS、再扫几个群聊记录、然后点开一堆公众号文章。这个过程看起来没什么实际消耗非常大半小时起步而且经常刷完发现真正有价值的信息只有两三条大部分时间是浪费在过滤噪音上。更重要的问题是不及时。有些动态是半夜发的等我早上刷到已经过了大半天有些信息被群聊淹没了等想到去翻记录早就不知道沉到哪去了。我需要的不是一个搜索工具而是一个每天固定时间主动把信息整理好送到我面前的自动化流程。这其实就是典型的定时任务加 AI 摘要场景采集、过滤、总结、推送四件事每天重复做。1.2 WorkBuddy 在这个需求里的位置一开始我想过两种方案写纯脚本抓 RSS 再套模板或者直接用一个现成的新闻简报服务。前者的问题是只能做关键词匹配做不了理解——同样是发布了新模型有的值得展开有的只是一行带过脚本判断不了后者的问题是信息源不可控我给你推送什么你就看什么。然后我注意到 WorkBuddy。它本身是个 AI Agent 工具除了能对话之外可以自定义 skill技能也就是把一系列工具调用和提示词打包成一个可复用的任务。这正好命中我的需求我可以把读 RSS、抓网页、按我的关注点总结、输出固定格式定义成一个 skill然后让定时任务每天触发它跑一次。WorkBuddy 负责理解和生成的部分定时任务负责到点叫醒它微信推送负责把结果送到眼前。三者各管一段互不干扰出问题也容易定位。这里我多说一句很多人在这一步就把架构搞复杂了想着让 WorkBuddy 自己带调度器、自己跑定时、自己推送。其实没必要。AI Agent 擅长的不是守时而是理解任务和生成内容。把调度交给系统级的 cron把推送交给现成的 Webhook 渠道才是最少出错的分工。2. 整条链路的设计闹钟、Agent 和微信的分工2.1 三个角色各干各的我的链路拆成三段每段一个明确职责环节负责角色核心任务出问题时的表现定时触发服务器 crontab每天 10:30 唤醒整个流程什么都不发生日志里没有记录日报生成WorkBuddy采集信息、AI 总结、格式化输出有触发记录但日报内容为空或跑偏微信推送Webhook 脚本把日报文本推送到微信日报生成成功但微信收不到这个拆法的好处是任何一环出问题我可以根据哪一步断了快速缩小范围。比如日志里显示 WorkBuddy 已经输出了日报但我没收到微信那问题一定出在推送环节不需要重新排查前面两段。2.2 为什么不让 WorkBuddy 自己记住定时WorkBuddy 确实有任务和流程的概念但它本质上是被调用方你给它一个指令它执行并返回结果。让它自己记住每天十点半要干活等于把可靠性寄托在一个 AI 系统的内部状态上。万一它更新了、重启了、或者上下文被重置这个记忆可能就没了。而 crontab 是操作系统级的定时器只要服务器不宕机、配置没写错它就会按时执行。我用了一个特别朴素的比喻来给朋友解释这件事WorkBuddy 是那个负责写稿的编辑cron 是那个每天早上准时敲他门的闹钟微信机器人是送报的。编辑可能忘事但闹钟不会——所以我把守时这个最重要的职责交给最不会出错的角色。2.3 数据流向完整链路是这样的crontab 在 10:30 执行一个 shell 脚本脚本调用 WorkBuddy 的 CLI 或 API传入今天要执行的 skill 任务生成今日 AI 日报WorkBuddy 按 skill 定义去读取信息源RSS、网页、配置好的关键词搜索做去重和 AI 总结输出一段 Markdown 文本脚本拿到输出把它拼成微信消息的 payload脚本用 curl 请求企业微信机器人 Webhook或 Server酱把消息推送出去所有步骤写入本地日志文件方便事后排查。这个顺序看起来很简单但每一步都有不少细节下面我分开讲。3. 定时触发落地cron 才是真正可靠的闹钟3.1 候选方案对比定时任务听起来是个老生常谈的东西但真到选型的时候还是有几个岔路。我梳理了四个方案crontab最终选择系统级简单可靠任何 Linux 机器都有。缺点是语法有点反直觉五个星号很多人第一次看会懵而且没有内置的失败重试。systemd timer比 cron 更现代支持更精确的控制和依赖关系但配置相对麻烦适合已经有 systemd 服务化习惯的人。Python APScheduler适合整个流程都用 Python 写的场景可以在代码里直接定义任务和重试逻辑但依赖进程常驻进程挂了任务就没了。WorkBuddy 自带调度如果工具有这类功能可以用但我不建议作为唯一方案原因上面说过——可靠性依赖 AI 系统的内部状态。我的结论是链路里最不能出错的一环用最保守的技术。cron 在 Unix 世界里跑了四十多年为一个每天一次的日报任务没必要上更复杂的调度器。3.2 cron 配置与时区坑cron 的语法是分 时 日 月 周每天 10:30 对应的表达式是30 10 * * *对应到 crontab 文件里完整的一行是这样30 10 * * * /home/user/workbuddy-daily-report/run.sh /home/user/workbuddy-daily-report/cron.log 21这里有个我踩过的坑cron 默认使用系统时区。如果你的服务器时区是 UTC那30 10 * * *触发的是 UTC 10:30也就是北京时间 18:30。第一次配完我下午六点半收到了日报还以为是延迟了。排查之后才发现是时区问题。解决办法是在脚本开头显式设置时区export TZAsia/Shanghai或者在 crontab 里用CRON_TZAsia/Shanghai不同发行版支持情况不一样还是export TZ最通用。配置完记得跑一下timedatectl确认服务器时区养成习惯。提示改完 crontab 后先跑crontab -l确认配置已写入再手动执行一次脚本验证别等第二天早上才发现没生效。3.3 一个完整的触发脚本我的run.sh大致长这样#!/bin/bash export TZAsia/Shanghai cd $(dirname $0) LOG_DIR./logs mkdir -p $LOG_DIR STAMP$(date %Y-%m-%d %H:%M:%S) echo [$STAMP] 任务开始 $LOG_DIR/run.log # 1. 调用 WorkBuddy 生成日报输出保存到 report.md python3 generate_report.py $LOG_DIR/generate.log 21 if [ -s report.md ]; then echo [$STAMP] 日报生成成功开始推送 $LOG_DIR/run.log # 2. 推送日报到微信 python3 push_wechat.py $LOG_DIR/push.log 21 else echo [$STAMP] 日报文件为空跳过推送请检查 generate_report.py $LOG_DIR/run.log # 这里可以加一个告警比如直接推送一条日报生成失败 python3 push_wechat.py 今日日报生成失败请检查日志 $LOG_DIR/push.log 21 fi echo [$STAMP] 任务结束 $LOG_DIR/run.log这个脚本的重点不是代码多漂亮而是把生成和推送拆成两步并且每一步都有独立日志。report.md为空时宁可推送一条失败告警也不要静默失败——这个习惯帮过我好几次。4. 日报内容生产怎么让 WorkBuddy 不跑偏4.1 任务指令的结构化写法定时跑 AI 日报和你在聊天框里问今天有什么新闻是两回事。手动问可以慢慢补充细节定时任务不行——指令写得含糊输出就跟着含糊今天总结三条明天总结十条格式也漂移。我的做法是把任务指令固定成一段结构化的 prompt核心包含四个部分角色你是一名 AI 行业信息编辑工作是把散落的信源整理成简明日报任务浏览以下信息源筛选出与 AI 相关的动态每一条用一句话概括核心信息约束最多输出 8 条按重要性排序不相关的信息直接忽略只输出事实不加评论格式严格按下面这个模板输出不要额外发挥。约束和格式是重点。没有约束AI 会把我注意到……这种废话写进去没有格式每次输出的排版都不一样推送到微信里看起来就像三流公众号。我建议把格式模板直接写死在 prompt 里# {日期} AI 日报 ## 今日焦点 1. **标题**一句话概述来源 2. ... ## 值得关注 - **标题**一句话概述来源 - ... ## 简评 不超过 100 字的整体观察如果没有可不写4.2 信息源接入WorkBuddy 的 skill 可以挂多个信息源。我的配置里有三类RSS 订阅主流 AI 媒体和开源社区的 RSS每天增量抓取WorkBuddy 负责把标题和摘要拉出来做初筛关键词监控通过搜索接口比如配置好的网页搜索工具跑一遍我关心的关键词如 Agent、多模态、开源模型、几家公司动态内部来源我自己维护的一个值得关注清单比如某个产品的更新页面、某个技术博客WorkBuddy 会定时抓取检查有没有更新。关于信息源我的建议是宁少勿多。一开始我塞了二十多个源结果 WorkBuddy 每天光抓取就要好几分钟输出还经常被低质量内容淹没。后来砍到 8 个高质量源日报质量明显上升生成时间也稳定在 1 分钟内。做日报的核心不是全而是精。4.3 输出模板与格式稳定性即使有了模板AI 还是会有自由发挥的冲动。我做了两道保险第一在 WorkBuddy 的 skill 定义里把输出校验作为一个步骤写进去——生成完日报之后检查是否包含今日焦点和值得关注两个小节如果缺了重新生成。这一步看起来笨但实测能把格式稳定率从八成拉到接近满分。第二脚本侧再兜底。generate_report.py拿到 WorkBuddy 的输出后会做一次基础校验去头尾空格、检查是否有模板标记、计算总长度超过 4000 字截断因为微信消息有长度限制。超出限制的情况确实发生过因为某天信息爆炸WorkBuddy 兴奋地写了五千字。截断逻辑虽然粗暴但至少保证推送不会失败。5. 微信推送四条路我都试过最后留了哪条5.1 候选渠道对比表微信生态的推送渠道五花八门我实际试过的有四条对比如下渠道接入难度每天免费额度适用场景我的评价企业微信群机器人 Webhook最低5 分钟搞定无条数焦虑频率限制约 20 条/分钟推送到企业微信群自己或小团队首选稳定省心Server酱ServerChan低扫码绑定即可免费版每天 5 条个人微信接收个人用够但额度紧张PushPlus低扫码绑定即可免费版每天 200 条个人微信接收额度大方偶尔有延迟微信公众号模板消息中高需要认证服务号、配模板有接口额度限制面向订阅用户适合做产品不适合自己用5.2 企业微信群机器人 Webhook 落地我最终的方案是企业微信群机器人。理由很实在免费、没有每日条数焦虑、Webhook 接入只需要一条 curl。建群之后在群设置里添加群机器人会拿到一个 Webhook 地址长这样https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx推送脚本的核心逻辑就一段import json import urllib.request WEBHOOK_URL https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的key def push_markdown(content: str): payload { msgtype: markdown, markdown: { content: content } } req urllib.request.Request( WEBHOOK_URL, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json}, ) with urllib.request.urlopen(req) as resp: result json.loads(resp.read().decode(utf-8)) if result.get(errcode) ! 0: raise RuntimeError(f推送失败: {result}) if __name__ __main__: with open(report.md, encodingutf-8) as f: push_markdown(f.read())企业微信机器人支持markdown消息类型正好匹配 WorkBuddy 输出的 Markdown 日报。我为了在手机上看着舒服把内容控制在 2000 字以内重点加粗用小标题分隔。实测推送到手机会自动渲染成富文本阅读体验比纯文本好很多。5.3 服务号模板消息和 Server酱的取舍如果你没有企业微信群或者觉得建群麻烦Server酱是另一个不错的选择。它的思路是你登录 Server酱官网用微信扫码绑定然后它给你的微信服务号发一条模板消息。调用方式和 Webhook 一样也是发一个 HTTP POSTcurl https://sctapi.ftqq.com/你的SendKey.send \ -d title今日AI日报 \ -d desp$(cat report.md)注意 Server酱免费版每天 5 条的限制。日报一天一次刚好在 5 条以内但如果你还想推其他通知比如告警、会议提醒额度就很紧张了。这也是我最终选企业微信机器人的原因——不想为了额度精打细算。至于公众号模板消息它需要认证服务号个人主体很难搞定而且模板消息本身就是给业务通知用的拿来给自己推日报属于杀鸡用牛刀。除非你是在做面向用户的产品否则不建议碰这条路线。6. 完整实施记录从零搭到稳定跑两个月6.1 环境准备我的运行环境是一台 2 核 4G 的 Linux 小服务器家里 NAS 也行只要保证常开就行。软件依赖就三样Python 3.9、curl、WorkBuddy 的 CLI 或 API Key。这里重点说一句WorkBuddy 如果装在服务器上务必确认它能正常启动并保持运行状态。我的做法是把它跑在 systemd 服务里防止机器重启后忘了手动拉起。如果你还没有 WorkBuddy安装完第一件事是跑通一次手动任务在终端调用 CLI 执行你要的那个 skill确认它能返回结果再往下做自动化。这一步千万别省否则后面你会分不清是调度问题还是 WorkBuddy 本身没配好。6.2 核心脚本整个自动化其实就三个文件run.sh入口脚本负责设置时区、按顺序调用下面两个 Python 脚本、写主日志generate_report.py调用 WorkBuddy 生成日报保存到report.mdpush_wechat.py读取report.md推送到企业微信机器人。generate_report.py简化后的核心逻辑import subprocess import datetime def generate_report() - str: # 调 WorkBuddy CLI 执行日报 skill # 这里用 workbuddy-cli 作为示例实际以你安装的版本为准 cmd [ workbuddy-cli, run, --skill, daily-ai-report, --date, datetime.date.today().isoformat(), ] result subprocess.run(cmd, capture_outputTrue, textTrue, timeout300) if result.returncode ! 0: raise RuntimeError(fWorkBuddy 执行失败: {result.stderr}) return result.stdout if __name__ __main__: content generate_report() # 简单校验非空、包含模板标记、长度截断 if not content.strip(): raise RuntimeError(日报内容为空) content content[:4000] with open(report.md, w, encodingutf-8) as f: f.write(content)这里最容易被忽略的是timeout300。AI 生成是有耗时的万一某天信息源抓取特别慢WorkBuddy 可能超时。我在脚本里设了 5 分钟超时超时就终止这次执行宁可今天没日报也不要让进程卡死影响下一次任务。6.3 日志与自检日志是这条链路的黑匣子。我的日志目录结构logs/ ├── run.log # 主流程日志每次任务的开始和结束 ├── generate.log # WorkBuddy 执行日志 ├── push.log # 推送日志 └── report-2025-xx-xx.md # 每日日报存档日报存档是个意外收获。跑了两个月之后我手里攒了几十天的日报回头查某件事的发布时间线特别方便。另外我写了一个简单的自检脚本每天任务结束后检查三个东西report.md是否存在且非空、推送接口是否返回errcode0、整个流程是否在 10 分钟内完成。自检结果也推到微信只不过发给自己所在的另一个群不打扰日报群。这样相当于给自动化加了监控日报没来我也能第一时间知道原因。注意第一次跑通后建议连续观察三天再逐步增加信息源避免一次改太多东西导致问题难定位。7. 踩坑复盘那些没收到日报的早晨7.1 连续三天失联的排查链路跑通之后的第二周我连续三天早上没收到日报。按照架构设计我直接从日志开始查。第一步看run.log发现每天早上 10:30 的任务开始日志都在说明 cron 正常。第二步看generate.log结果发现 WorkBuddy 执行报错错误信息是网络请求超时。第三步看信息源发现某个 RSS 源改版了响应时间从原来的几百毫秒变成了 30 秒WorkBuddy 抓取时直接超时。问题找到了不是调度问题不是推送问题是某个信息源拖垮了整个任务。解决办法有两个一是把 WorkBuddy 的抓取超时调短单个源超过 10 秒就跳过二是把那个不稳定源从列表里踢掉。我做了第一件事然后在 skill 里加了一条约束单个源抓取超时超过 10 秒则跳过并继续。之后日报再没因为这个原因断过。这次排查给我的教训是日志一定要分环节写。如果我只在run.log里写任务失败四个字排查范围就得从 cron 一路查到 WorkBuddy 再到网络至少折腾半小时。分日志之后两分钟就能定位到generate.log里的具体错误。7.2 常见故障清单除了上面那次这两个月我还遇到过几个典型故障整理成清单现象可能原因解决办法任务完全没有触发cron 没生效 / 服务器时区不对检查 crontab 是否写入检查时区手动跑一次脚本验证任务触发了但日报为空WorkBuddy 没输出 / skill 配置错误看 generate.log手动执行 CLI 复现日报有了但微信收不到Webhook Key 失效 / 消息长度超限重新获取 Key截断内容看 push.log推送偶尔延迟企业微信接口或网络波动任务时间提前 10 分钟留缓冲不敏感可忽略内容格式乱了模板约束不够 / WorkBuddy 版本更新加强 prompt 约束加输出校验步骤其中 Webhook Key 失效那次最折腾——我换了企业微信账号旧机器人的 Key 自然就吊销了但脚本里的配置没改。这提醒我把 Webhook 地址和 API Key 这类配置单独放在config.py里不要硬编码在业务脚本中换环境的时候只需要改一处。8. 还能怎么玩这套链路的扩展方向8.1 多源多主题日报跑通单条日报之后我顺手扩展了几个变体多主题并行除了 AI 日报我还挂了开源项目周报每周一推送和竞品动态监控有变动时即时推送。做法完全一样的套路只是换 prompt、换信息源、换 cron 时间。早晚双报早报偏行业动态晚报偏技术干货。早报 10:30 发晚报 18:00 发两条 cron 互不干扰。8.2 团队群推送和定时提醒如果你有团队这套链路可以直接搬进团队群。我有朋友按我给的方案搭了一个团队日报每天早上把竞品动态、用户反馈摘要、行业新闻推进公司群群机器人免登录免审核比挨个转发链接高效得多。另外定时推送的用途不只有日报。我在同一台服务器上还用同样的 cron 加 Webhook 套路做了每周提醒比如每周五下午提醒提交周报和项目状态播报。思路一旦打通只要是固定时间、固定动作、内容可变的需求都能用这条链路解决。最后说一点个人体会这类自动化的价值不在于技术多炫而在于它稳定地替你省掉了重复劳动。我最初只是想少刷点新闻后来发现它顺带养成了我每天早上看日报的习惯——因为推送就在那里点开就能看完。如果你也想搭这么一套建议先从最简单的版本开始先手动跑通 WorkBuddy 的单次任务再挂 cron再接微信一步步来别一开始就追求完美。稳定跑起来之后你会感谢那个每天十点半准时出现的闹钟。