你有没有过这种体验早上眼睛还没完全睁开先条件反射地打开公众号、技术群、科技媒体生怕漏掉一条和 AI 相关的新闻。页面刷了不少真正记住的没几条时间倒是搭进去半个多小时。后来我干脆把这活儿外包了——给 WorkBuddy 设了个“闹钟”每天上午十点半一份整理好的 AI 日报自动送到我的微信里。WorkBuddy 是一款偏智能体AI Agent思路的 AI 工作台支持给 Agent 设置定时任务和长期规则Skill它可以自主完成“搜索信息源 → 筛选判断 → 编写日报 → 调用接口推送到微信”这一整条链路。说白了就是雇了一个不要工资、每周七天固定上班的信息编辑。这篇文章不聊概念我就完整复盘一下这套日报流水线的搭建过程从需求拆解、规则配置、推送选型到踩坑排查和后续扩展全记录下来。无论你是刚开始用 WorkBuddy还是已经在电脑上装好了它想找个实战场景这份记录应该都能直接抄作业。1. 先拆需求每天 10:30 的日报到底在解决什么问题1.1 痛点是“信息太多”不是“信息太少”我从去年开始密集跟进 AI 方向的动态。每天要看的东西大致有这几类几个头部媒体的 AI 板块、大模型厂商的官方博客、GitHub 上的热门项目、arXiv 上值得读的论文再加上朋友圈和群里被转发的文章。人肉刷一遍至少一两个小时而且刷到的内容严重重复——同一个模型发布新版本可能五六个账号在写写的内容差别还不大。所以我要的根本不是又一个信息聚合器而是一个能帮我做筛选和判断的“助理”。它不需要把全网信息都给我只需要回答一个问题过去 24 小时里哪些 AI 动态值得我花时间看。标题里写的“每三十分钟日报”听起来很简单真正难的部分在“筛选”和“判断”而不是“抓取”。1.2 方案选型为什么是 WorkBuddy而不是自己写个定时脚本最早我考虑过最传统的方案写一个 Python 脚本定时拉取几个 RSS 源把标题拼起来再通过推送接口发到微信。这个方案确实能跑通但用了几天我就发现几个问题信息源多了以后每个网站的解析规则都不一样有的有 RSS 能用有的没有 RSS有的改了页面结构脚本就拉不到内容了。拼接出来的“日报”没有判断力。它只是把一堆标题堆在一起没有优先级、没有归类、更没有观点。每次想调整日报格式都要回去改代码、重启服务维护成本不低。换成 WorkBuddy 之后这几个问题基本被绕开了。WorkBuddy 自带定时调度不用自己维护 crontab任务用自然语言定义想改格式直接改提示词最关键的是它是 Agent 架构能自己决定下一步调用什么工具——搜索网页、读取链接、发送 HTTP 请求全流程自动串联。对比下来大概是这么个感觉对比维度传统定时脚本WorkBuddy 方案定时调度需要自己配 crontab 和守护进程内置定时触发管理信息抓取每类源要写解析规则Agent 自主搜索和读取页面内容整理只能拼接标题能总结、筛选、排序格式调整改代码再部署改提示词即可规则复用每个脚本独立维护定义一次 Skill后续任务全局生效用 WorkBuddy 唯一要适应的是它的思维方式从“写命令”变成了“写规矩”。你告诉它目标、边界、输出格式剩下的执行路径由 Agent 自己规划。一开始会不太放心觉得不受控跑几天之后你会习惯的——它比大多数人想象的靠谱。1.3 整条链路三大件定时、生成、推送整套日报流水线拆开来看就是三个环节定时触发、内容生产、消息送达。定时触发是那个“闹钟”每天 10:30 把 Agent 叫醒内容生产是“编辑”让 Agent 按照指定规则写日报消息送达是“邮差”把最终日报通过微信通道送到你手上。这三个环节必须分开考虑因为出问题时排查逻辑完全不同。定时没触发问题多出在时区或调度配置日报内容质量差问题多在提示词和 Skill 规则消息没收到问题基本在推送通道。下面我会按这三个环节逐个讲配置细节再讲实操和排查。2. 核心设计WorkBuddy 定时任务与 Skill 规则的配置要点2.1 定时触发10:30 这个时间点怎么设置定时任务在 WorkBuddy 里属于基础能力配置入口一般在任务或自动化面板。支持两种方式一种是直接在界面上选“每天”然后填具体时间另一种是填 cron 表达式。如果要用 cron 表达式每天上午 10:30 对应的写法是30 10 * * *。拆开来看第一个星号位置是分钟填 30第二个星号位置是小时填 10后面三个分别是日、月、星期全部留星号表示“每天都执行”。这里我建议尽量用 cron 表达式因为它的表达能力更强你以后想改成“工作日执行”或“每周一三五执行”改配置就行不用重新创建任务。有一个非常容易踩的坑时区。如果你运行的 WorkBuddy 是在 Docker 容器或者海外服务器上系统默认时区很可能是 UTC。UTC 早上 10:30 换算成北京时间就是晚上 18:30你会在一个错误的时间收到日报。我一开始就是没注意这个连续两天下午收到日报才发现问题。解决办法很直接把容器的时区环境变量设为Asia/Shanghai或者在 WorkBuddy 的设置里看看有没有时区选项实在不行写 cron 的时候直接把 8 小时差换算进表达式里。2.2 Skill 规则把“日报怎么写”沉淀成长期约束Skill 是 WorkBuddy 的一个关键设计相当于给 AI 立规矩。和每次写提示词不同Skill 一旦定义好可以设成全局生效——后面你新建任何任务它都会自动带上这套规则这就对应了标题里说的“给 WorkBuddy 定几条规则后续对所有任务都生效”。我给日报任务立的规则是这五条日报是写给懂技术的朋友看的不要公文腔不要“重磅”“震惊”这类标题党用语。每一条信息必须有来源链接没有明确来源的内容不允许写进日报。同一事件如果有多篇报道只保留信息最完整的一篇其余直接丢弃。每条信息先写结论再补细节全文控制在 150 字以内。某个板块如果当天没有足够重要的内容就省略该板块宁缺毋滥。写这些规则的时候有个心得体会规则越具体Agent 的产出越稳定。比如只说“要附来源”它可能会写一个看起来像链接的字符串改成“没有明确来源的内容不允许写进日报”它的行为就会严谨很多。规则不是越多越好而是每条都是可执行的硬约束。2.3 Agent 的日报提示词模板有了全局 Skill 之后再给 Agent 一条核心提示词告诉它每天具体要干什么。下面这个模板我用了很久可以直接复制你是一名深耕 AI 领域的科技编辑每天必须产出一份中文 AI 日报。 信息获取方式 1. 主动检索并浏览多个优质信息源包括 AI 科技媒体、大模型厂商官方博客、开源社区热门项目、论文发布平台。 2. 优先选择过去 24 小时内发布的、有明确出处的内容。 3. 对同一事件的多篇报道进行交叉比对只保留信息最完整的一篇。 日报结构 【今日焦点】2-3 条最重要的动态每条用 2-3 句话说明核心信息和影响。 【大模型与产品】模型发布、能力升级、产品功能更新。 【开源与开发者】GitHub 热门项目、开发工具链、框架版本更新。 【行业与观点】重要融资、合作案例、值得一读的观点文章。 硬性要求 1. 每条必须附原始链接。 2. 每条正文不超过 150 字先写结论再补充细节。 3. 用自己的话转述不抄原文。 4. 某板块没有重要内容时直接省略不凑数。说下这个模板的设计逻辑。“角色设定”那段非常关键你不告诉 Agent 它是一个编辑它就会默认自己是搜索引擎给你罗列一堆链接你告诉它“是编辑”它才会去判断“哪些值得写”。“板块结构”是为了让微信端的阅读体验更清晰读者扫一眼就能定位到自己关心的内容。“硬性要求”是为了对抗大模型的输出毛病——它特别容易在摘要里写废话限字数、要求先结论后细节能有效提升信息密度。2.4 微信推送通道选型四个方案对比日报写好了下一步是送到微信。这一环的选择直接决定了整个方案的稳定性。我实际调研和试用过四种方式推送方案原理上手难度适用场景Server酱通过方糖提供的接口调用微信服务号模板消息低注册拿 Key 即可个人自用最适合快速起步PushPlus类似 Server酱微信公众号推送支持多种格式低Token 即用个人自用消息格式更丰富企业微信群机器人在企业微信群中添加机器人向 Webhook 地址 POST 消息中需注册企业微信团队共享消息支持 Markdown微信测试号自己开发公众号测试号调用微信接口高需服务端逻辑深度定制基本不建议我个人最终的选择是“企业微信群机器人”加“Server酱”双通道。企业微信群机器人负责把日报发到团队的群里所有人 看早报Server酱再单独给我个人发一份保证就算我没看群也不会漏。两个通道互不干扰一个挂了另一个还能兜底。这里有个方向性的建议做微信推送优先选官方接口通道比如 Server酱这种基于微信服务号的方案或者企业微信的 Webhook。不要自己去研究个人微信的协议对接那种方案一是不稳定二是有合规风险完全没有必要。走正规通道配置一次能用很久。2.5 信息源怎么选决定了日报质量的上限日报质量一半由提示词决定另一半由信息源决定。我给 WorkBuddy 设置的信息源分为两个梯队。第一梯队是每天必看的主流科技媒体的 AI 板块、几家头部大模型公司的官方博客、开源社区的热门项目榜、开发者社区的热帖。第二梯队是按需调用的学术论文平台的 AI 分类、几个长期更新的深度分析博客。信息源总数我控制在 10 个以内。原因很简单信息源太多 Agent 光搜索就花掉大量时间而且容易抓到过时或低质量的内容。设置了优先级之后它会把注意力放在第一梯队上第二梯队只在第一梯队信息不足时补充。还有一个实用技巧如果某个信息源没有提供 RSS可以在给 Agent 的指令里直接描述“打开某个入口页面定位最新发布区块”Agent 会自动点击进去找新内容不需要你再提前写好解析规则。3. 实操记录从装好 WorkBuddy 到 10:30 准点推送3.1 准备阶段需要做的事在动手配置之前先把三样东西准备好WorkBuddy 本体、大模型 API Key、推送通道的凭证。WorkBuddy 安装本身不复杂从官方渠道下载对应平台的安装包安装后登录账号在设置里填入大模型服务的 API Key 就行。有一点提醒如果你的电脑比较老注意看一下 WorkBuddy 对系统版本的要求太旧的系统可能不支持新版这时候找历史版本比折腾升级系统省事。推送通道以 Server酱为例去它的官网用 GitHub 或微信扫码登录得到一个 SendKey后面调用接口时会用到。整个过程几分钟就能搞定不需要配置服务器。3.2 创建 Agent 和 Skill打开 WorkBuddy新建一个智能体我起的名字叫“早报编辑”。这个名字不是随便起的Agent 的名字会出现在上下文里起一个明确的功能名比叫“助手”更能让它理解自己的职责。然后进入 Skill 管理新建一个全局规则把 2.2 里的五条规则写进去生效范围选择“所有任务”。这里要注意Skill 保存后最好先在对话里测一下用最简单的一句话比如“请按照全局规则评价这条消息”看它是不是真的遵守了规则。我遇到过规则写得太模糊Agent 完全无视的情况当场改掉比等日报上线后才发现好得多。3.3 配置定时任务和推送节点接下来就是重头戏在任务页面新建一个定时任务。我的配置过程分四步任务名称填“AI日报-10:30”方便之后在任务列表里一眼认出来。触发条件选“每天”时间填 10:30如果支持 cron 就直接填30 10 * * *。任务内容里绑定“早报编辑”Agent并指定执行日报生成的核心提示词。添加一个“HTTP 请求”节点把日报内容发送到推送通道。第四步是整条链路里最技术化的地方。企业微信群机器人的 Webhook 地址是固定的HTTP 请求节点里只需要配置 POST 方法和请求体。以 Server酱为例请求体大致是这个结构{ title: AI 日报每日 10:30, desp: 这里填入 Agent 生成的日报内容 }对应到 curl 命令就是这个效果curl -X POST https://sctapi.ftqq.com/你的SendKey.send \ -H Content-Type: application/json \ -d {title: AI 日报每日 10:30, desp: 日报正文内容}要说明的是实际配置时你不一定真的执行 curl。多数情况下 WorkBuddy 的 HTTP 请求节点里可以直接填 URL、请求方法和 Body 模板把 Agent 输出的内容映射到desp字段即可。如果你需要在其他脚本里复用这套逻辑上面的 curl 命令就是一个标准的参照。3.4 首次联调的正确姿势配置完成后先别急着开定时手动触发一次任务验证三件事日报内容是否完整、链接是否真实有效、微信有没有收到推送。我第一次跑的时候日报倒是生成出来了但推送消息里只有标题没有正文。排查后发现是 HTTP 请求节点里变量映射的问题——它默认发送的是会话的标题字段而不是 Agent 输出的正文内容。把变量改成指向最后一条消息的正文字段之后问题就解决了。这里分享一个非常重要的小技巧先用“随便别的什么时间”验证整条链路确认没问题再改成 10:30。比如你可以把定时先设在 10:29假设你正在调试坐等一分钟看它跑不跑不要直接设成 10:30然后等一天后才发现没推成功那就白等了。3.5 跑起来之后的迭代节奏定时任务上线后建议不要频繁改配置先让它跑一周。一周后回看每天的日报你会明显看出哪些内容你会点开、哪些内容你根本不会看。我的日报最开始是大模型新闻偏多后来发现真正给我价值的是“开源工具”板块于是我把提示词里的板块顺序调整了一下把“开源与开发者”提到了第二位。日报的格式稳定之后基本不用再管它只需要每隔一段时间检查一下数据源是不是失效了。Agent 挂在某个不可用的数据源上时它会自动找其他源但如果所有源都老了日报的质量就会明显下降——这时候需要更新一下信息源列表。4. 踩坑实录日报流水线的调试笔记与避坑建议4.1 到点了没推送先排查三件事定时任务到点没触发不用慌按顺序排查。第一是时区问题很多情况下容器默认是 UTC日报会“准时”在错误的时区推送。第二是 cron 表达式本身有没有写对有些 WorkBuddy 版本只认标准五段式表达式不要想当然地用类似H 10 * * *这种 Jenkins 语法——它根本不认。第三是进程是否常驻WorkBuddy 所在的那台电脑或服务器有没有休眠、断网、重启任何一环断了任务都不会执行。我的经验是定时任务这类东西一定不要放在日常办公笔记本上。笔记本一合盖就休眠了日报自然就歇菜了。找一台长期在线的设备比如家里的迷你主机、NAS 里的虚拟机来跑一劳永逸。4.2 推送成功但内容为空大概率是变量映射问题日报生成了微信也收到消息了但正文是空的。这种情况如果出现在配置阶段九成是 HTTP 请求节点里变量映射没配对。你要发送的是 Agent 生成的完整日报正文而不是会话标题、任务名称这样别的内容。检查一下请求体里对应的模板变量是否指向了正确的字段。如果正文字段被截断则多半是推送通道的长度限制。Server酱这类服务对单条消息长度有上限日报写太长就会丢内容。解决方法是压缩日报长度——我后来把每条摘要限制在 150 字以内总条数控制在 8 到 12 条截断问题基本不再出现。4.3 日报内容同质化、像“新闻联播摘抄”怎么治跑了几周后你会遇到一个质量瓶颈日报里的每条新闻都能看但都是一句话复述原文没有观点、没有分析。这个问题的根源不在信息源而在于提示词里缺少“编辑视角”的要求。我的解决办法是在 Skill 里补了一条规则所有信息必须用自己的话重新组织并写清楚这条新闻对谁有影响、意味着什么。听起来简单但效果非常明显。比如同样写一个开源框架发布新版之前 Agent 写“某框架发布 2.0 版本包含多项新特性”补上规则之后它会写成“某框架 2.0 发布新增功能主要用于简化 Agent 状态管理正在做相关项目的开发者可以重点关注”。哪个有阅读价值一目了然。4.4 链接失效怎么办让“无法确认来源的信息”写不出来AI 生成的日报最让人头疼的问题之一是链接。大模型有概率生成“看起来像真的”但实际不存在的链接这是模型训练时的记忆偏差导致的。我在早期就吃过几次亏点开日报里的一个链接结果是 404。解决办法是在提示词里加一条硬约束所有链接必须来自 Agent 实际访问过的页面如果无法确认来源就不写链接只写“信息来源于某平台”。比这个更稳的做法是让 Agent 优先从 RSS 源获取条目因为 RSS 里的链接通常就是真实有效的原始链接拿到链接后再去抓取页面内容做摘要既保证链接真实又有摘要质量。4.5 常见问题速查表问题现象可能原因处理方法到点没收到推送时区配置错误或机器休眠改时区为Asia/Shanghai确保设备常驻在线推送消息只有标题HTTP 节点变量映射错误检查请求体变量是否指向 Agent 正文输出正文被截断推送通道长度限制压缩摘要字数减少总条数日报内容全是复述缺少编辑视角约束在 Skill 中增加“重写 价值判断”规则链接打不开模型生成了不存在的链接约束链接来源必须真实访问过内容严重过期信息源失效或场景过时定期检查和更新信息源列表5. 日报流水线的更多打开方式5.1 多人、多主题日报并行这套模板建好之后复制成本极低。我现在给团队分别跑了三个日报AI 技术动态、产品市场观察、行业融资信息。每个日报只需要新建一个 Agent、配置不同的信息源和提示词再指向不同的企业微信群即可。Skill 里的全局规则完全复用不需要重复定义。如果你需要跟进多个方向又不想手动分流信息这个思路可以直接照搬。5.2 日报自动沉淀成周报日报看的是“今天发生了什么”但时间长了你会需要一个“这周到底发生了什么”的总结视角。我的做法是在 WorkBuddy 里再加一个周五下午的定时任务让一个分析助手读取本周所有日报任务的输出自动生成一份“本周 AI 要事回顾 趋势判断”推送到同一个群里。因为日报规则是全局生效的周报生成时也会自动保持“附来源、先结论”的底线不会跑偏。5.3 和知识库联动构建个人 AI 信息库更进一步的玩法是把每一期日报归档到知识库日积月累形成一个可检索的个人 AI 情报库。之后你可以直接问 Agent“这个月有哪些值得关注的开源 Agent 框架”“那家公司上个月发布了什么模型”让它在历史日报里检索答案。注意归档时只保留合规、干净的内容不要把敏感信息往里面存。这条链路跑通之后你相当于给自己建了一个私人的领域知识库时间和信息的复利效应会越来越明显。最后说说我个人的真实体会。这套方案跑到现在最让我满意的不是“每天自动推送”这件事本身而是它把“追信息”变成了“收信息”。以前是我主动去刷现在每天十点半微信准时响起我花一两分钟扫完日报有感兴趣的再点开链接细读整个早上的信息摄入效率是完全不同的体验。最后再分享一个小技巧搭建初期不用追求日报格式完美先让链路从“生成到推送”通起来再说后期靠改规则和 prompt 逐步迭代。你可能会发现跑了一个月之后这份日报越来越像你自己写的——因为是你亲手把规矩一条条教给它的。