上午十点半微信准时弹出一条新消息标题写着“AI 日报第 24 期”。点开以后内容已经被排得清清楚楚今日最值得关注的一件事、三个值得留意的开源项目、一条值得细读的观点。这不是我订阅的某个科技媒体号而是我自己搭的一条自动化流水线——WorkBuddy 负责定时触发和调度 AI 模型我给它配了一个生成日报的 Skill每天上午十点半自动抓取信息源让大模型完成摘要、筛选和排序最后借道 Webhook 把内容送进微信。花了大半天搭好之后它已经连续跑了三周中间踩了不少坑也顺手修了不少问题。这篇文章打算把整套方案、配置思路和排雷过程尽量完整地写出来。如果你也被“每天起床先刷两小时资讯”这件事困扰或者正好想把日常工作里那些重复的信息收集交出去这里面的大部分思路应该可以直接参考。1. 早晨的信息焦虑是自动化最值得解决的第一件事1.1 每天睁眼先刷两个小时资讯的恶性循环先聊聊我为什么折腾这件事。以前我每天早上醒来的第一件事是打开手机里那批固定的资讯入口几个技术媒体、开源社区的热榜、社交平台的时间线、常看的技术博客。目的很简单生怕漏掉 AI 领域的重要动态。但实际效果很差一个多小时刷完脑子里留下的有效信息往往只有两三条大部分时间花在“确认没有大事发生”上。更尴尬的是真正重要的一条消息经常藏在时间线二十条之后手指快速划过时根本注意不到。这个状态说白了就是信息焦虑。表面上每天都在接收信息实际上没有一条真正进入决策层。后来我意识到问题不在于信息量不够恰恰相反是信息量太大但过滤太粗糙。我需要的是每天早上有一份已经整理好的结果放在面前而不是自己去承担那个筛选过程。于是“定时推送一份 AI 日报”这个需求就被记了下来。1.2 为什么候选方案那么多最终锁定了 WorkBuddy想解决这个需求可选方案其实不少。最传统的是 crontab 加 Python 脚本每天定时去爬几个源再调大模型接口做摘要最后通过消息推送服务发到微信。这套方案我早年写过能用但维护成本不低RSS 结构一变要改代码网页布局一变要改解析规则任务跑挂了还没人通知。后来也试过 n8n 这类自动化平台优点是环节都被模块化了但 AI 编排能力偏弱想把“判断一条新闻值不值得进日报”这种模糊逻辑写清楚反而费劲。现成的 AI 日报订阅服务我也试过几个问题在于信息源不透明它推什么我看什么过几天就发现内容偏向严重。最终选中 WorkBuddy主要看中的是它把大模型能力、Skill 机制和定时任务放在了同一个环境里。Skill 允许我用自然语言而不是代码来定义执行规则后续改信息源、改打分标准、改输出模板都只是在配置里调整文字不用重新部署脚本。对不想维护一堆代码的人来说这是最省心的一条路。1.3 一条日报从触发到送进微信中间发生了什么这条流水线可以拆成七个环节定时器触发、抓取信息源、初步清洗、LLM 摘要与筛选、格式排版、调用 Webhook、微信展示。十点半一到WorkBuddy 里的定时任务先唤醒执行器接着按我在 Skill 里配置的抓取清单逐个拉取信息源内容。拿到原始材料后清洗阶段负责去掉广告噪声、剔除重复内容、过滤掉明显低质量的信息。然后进入 LLM 阶段大模型按照提示词完成摘要、打标签、打分、排序。最后一步是把整理好的结果按照日报模板拼装成 markdown 文本通过 Webhook 推到我的微信。整个流程没有什么黑魔法关键就在于每一层都要有明确的输入输出出了问题才查得到是哪一环在报错。2. 给 WorkBuddy 写“日报任务”前我先把规则拆成了三层2.1 Skill 的本质把人的判断标准翻译成机器可执行的指令Skill 这个词在 WorkBuddy 里看着唬人想明白之后就很简单它相当于给一个能力很强但没有任何主观立场的实习生写工作手册。大模型确实什么都知道一点但它不会自动知道“你关心的 AI 动态”具体指什么不会知道你信任哪些站点更不会知道一条信息到底凭什么进你的日报。很多人搭自动化日报失败问题就出在规则太含糊。我一开始写的提示词比这还简单基本是“请帮我整理今天的 AI 新闻”结果得到的日报像一份低配版的新闻联播所有条目平均用力谁也没说清楚它为什么值得我看。后来把规则拆成三层——数据源层决定看什么判断层决定留下什么输出层决定长什么样——日报的质量才真正稳定下来。这个分层思路比具体用什么参数重要得多值得在这里展开说。2.2 我的信息源清单与抓取策略数据源层我现在一共配了五类来源。第一类是聚合型 RSS包括 Hacker News、Product Hunt 和 arXiv 的 AI 分类这类源头信息量大适合做第一轮粗筛。第二类是固定的技术媒体和官方博客通过 RSS 订阅按关键词过滤确保重大发布不漏。第三类是 GitHub Trending 上 AI 相关的仓库重点捕捉新出现的大模型项目和开发工具。第四类是社区讨论里热度快速上升的帖子这种往往是早期信号比媒体报道要快半天到一天。第五类是检索型任务如果前四类跑完内容仍然偏少就让 Agent 使用内置搜索能力补几条关键词热点。抓取顺序也有讲究先抓能拿到全文的源再抓只有标题和链接的源。全文越完整后面摘要的质量越高这一点我是对比试出来的让模型从三十个标题里猜内容远不如给它十篇全文让它挑三篇。为了控制抓取时间我会把每个源的最大抓取条数都限制好避免一次任务拉回来几百条标题反而把真正有效的内容淹没。2.3 分段编排抓取、清洗、摘要、排版各干各的在设计 Skill 的执行流程时我特意没有把所有工作塞进一个智能体对话里而是拆成了四个独立步骤。这样做主要是为了三点。第一是可控性。一个步骤做一件事日志会非常干净。如果日报里突然出现乱码我可以直接定位到摘要这一步的输入输出而不必在一大段对话历史里翻找。第二是成本。分段执行可以在每一段都设置不同的模型档位抓取和清洗用便宜快速的小模型摘要和排版用能力更强的大模型整体花费比所有内容都走同一个高级模型要低不少。第三是排查方便这一点等会讲踩坑时还会提到。每个步骤的输入输出我都做了约定抓取步骤输出的是结构化条目数组清洗步骤输出的是干净文本列表摘要步骤输出的是带字段的对象。字段固定下来之后后面排版才不需要想破脑袋去猜模型吐出来的格式。3. 日报内容结构怎么让大模型替你筛出“真正值得看的东西”3.1 日报模板我要的是“领域雷达”不是“新闻联播”早期那种平铺式日报说实话连我自己都没看完过。我真正需要的是十分钟之内判断出今天 AI 领域发生了什么哪件事跟我当前的工作方向有关哪些变化需要我调整接下来的计划。所以我把日报模板固定成了五个模块。第一个模块是“今日头条”只保留一条最有价值的信息写清楚发生了什么、为什么重要、可能影响哪些人。第二个模块是“值得关注”放三到五条次重要内容每条一句话摘要加一句点评。第三个模块是“开源与工具动态”记录两到三个具体项目写清楚项目是做什么的以及它的看点和适用场景。第四个模块是“数据与观点”挑一条值得细读的评测或者有分歧的讨论附上原文链接。第五个模块是“今日判断”让模型综合当天信息给出一句话倾向性判断这部分相当于模型替我做的二次加工。实际体验下来这五块结构最大的好处是它逼着模型做取舍而不是把所有东西都塞进来。没有“今日头条”这个限制时模型倾向于给每条内容一个差不多的权重结果就是什么都没有被突出。设定了只允许一条之后模型反而需要真正去比较和排序这个比较过程就是筛选价值最大的部分。3.2 筛选规则的核心是“信息权重”不是“关键词”如果只靠“包含 ChatGPT 就保留”这种关键词过滤日报最后一定会变成轰炸式的列表。我的做法是给每条候选信息打四个维度分。第一维是相关性判断这件事是否与 AI、大模型、Agent 工作流直接相关。第二维是时效性看它是不是过去 24 小时内的新变化。第三维是权威性一手信源得分高于二手转述官方发布高于小道消息。第四维是差异度看这条信息跟已经选入日报的内容是否存在视角上的重复。每个维度一到五分加权求和后设定一个入选阈值。这个打分逻辑本身不复杂大模型执行起来很稳关键在于权重可以分阶段调。比如某天正好赶上一场重磅发布会我会把差异度权重调高避免十条内容全在讲同一件事的多篇稿子。这套权重配置不是一次到位的我是跑了快一周之后才慢慢调到目前这个比较顺手的状态。3.3 用自然语言把质量要求写进系统提示词日报质量的上限基本取决于系统提示词写得有多具体。这里分享一段我目前在用的提示词框架可以直接复制到 WorkBuddy 的 Skill 配置里改一改用你是一个面向 AI 领域从业者的情报编辑。我会分批给你原始信息源内容你需要完成筛选和摘要。 约束条件 1. 只保留与 AI 大模型、Agent 产品、AI 开发工具直接相关的信息。 2. 今日头条只能有 1 条必须是你认为最重要的动态要写清楚发生背景和影响面。 3. 值得关注的条目控制在 3-5 条每条摘要不超过 120 字点评不超过 60 字。 4. 开源项目要给出项目名称、主要用途、近期的突出变化。 5. 所有判断必须基于今天的材料不要写泛泛的行业趋势。 6. 整体语气中立不要用夸大词不允许出现“震惊”“重磅”这类表述。这段提示词我迭代过四版。一开始没有约束字数模型把每条都写成两百字日报总长度直奔六千字后来加了硬性字数限制又出现了模型用列表硬凑的毛病。现在的版本强调的是“基于今天的材料”和“不要写泛泛的行业趋势”这两句话确实把输出质量拉高了一截。4. 微信送达方案我绕开了个人号限制用 Webhook 走通4.1 为什么不考虑“直接调用个人微信发消息”微信推送是这套流程的最后一环也是很多人在配置中最纠结的一步。这里面有一个需要明确的边界微信没有向个人用户开放的推送接口你不能写代码直接给你的私人微信发消息。市面上确实有一些方案号称能绕过这个限制基本思路是去操作微信客户端的内部逻辑。我不建议用封号风险是其一稳定性是其二。你现在搭的是一个每天都要跑的生产流程不是做实验通知链路出事会比日报内容出错更麻烦。正确解法是走向上兼容的通道——用 Server酱、PushPlus、企业微信群机器人这类服务它们利用的是微信对外开放的消息接收能力本质上是合规微信生态内成熟的解决方案。4.2 三种方案横向对比Server酱、PushPlus、企业微信群机器人这三条路我都实际跑过简单做一个横向对比方案接入成本免费额度稳定性我的评价Server酱最低注册即拿 SendKey免费额度对个人日报足够很高曲线最平滑适合快速跑通PushPlus低需要关注公众号免费可用部分高级功能收费高支持自定义模板中文体验好企业微信群机器人需要创建企业微信群免费极高适合和团队成员共享日报我日常用的是 Server酱主要原因是接入最简单只需要一个 SendKey 就能发消息推送成功与否还有明确的返回状态码。如果你的日报是给团队里几个人一起看的企业微信群机器人会更合适一条 Webhook 地址就能让一整个群收到消息。4.3 用 Webhook 把日报送进微信完整配置流程以 Server酱为例整个配置过程只需要三步。第一步打开 Server酱官网完成微信登录后复制你的 SendKey。第二步找到 Server酱的推送接口地址地址格式是固定的https://sctapi.ftqq.com/{SendKey}.send。第三步从 WorkBuddy 的“Webhook 发送”步骤发起一个 POST 请求把日报标题和正文分别放在 title 和 desp 两个字段里。我在 WorkBuddy 里的实际做法是让排版步骤直接输出成 markdown然后由推送步骤组装成下面的请求import requests send_key 你的SendKey url fhttps://sctapi.ftqq.com/{send_key}.send payload { title: AI 日报6 月 9 日, desp: # AI 日报\n\n## 今日头条\n...这里放完整日报内容..., } resp requests.post(url, datapayload) print(resp.status_code, resp.text)这里有一个实测下来的细节Server酱的 desp 字段是支持 markdown 渲染的但消息渲染时对表格和超长链接支持一般所以我在排版步骤里刻意少用表格多用简洁的层级标题和项目符号。日报被推送到微信之后是要在手机屏幕上阅读的排版密度低一点、留白多一点阅读感受完全不一样。5. 无人值守的关键首次端到端跑通与定时器配置细节5.1 先手动跑一遍每个环节都要看到中间产物正式交给定时器之前我先手动点击执行了好几次整个 Skill保证每一环节的输出都符合预期。第一次跑通新流程最容易犯的错误就是一次性看到最终推送然后就默认系统健康。等第二天出了问题你根本判断不了是抓取挂了、摘要崩了还是推送接口变了。我的办法是把执行过程拆开验证。先单独测试数据源抓取看返回的条目数量和字段是否完整再单独测试摘要步骤看大模型是否遵守了字数和格式约束然后把排版结果放进 Server酱 的文档里检查渲染效果最后才把整个流程串起来完整跑一次。每一步的中间产物我都会在 WorkBuddy 的执行日志里看一眼确认信息源、清洗逻辑、摘要模板、推送参数这些都是按预期工作的。5.2 十点半这个时间点的选择逻辑定时时间选在十点半是经过一番权衡的。一开始我贪早设过早上八点跑了两天就发现问题夜间更新的信源到八点往往还不完整国外社区的讨论经常是北京时间早上九、十点才开始活跃八点去抓抓到的经常是前一天的旧材料。反过来设到中午十二点也不行等日报送达半天已经过去了时效性打了折。十点半刚好卡在大多数信息源完成夜间更新、白天新内容还没涌进来的空档期。在 WorkBuddy 里配置定时器时我用的表达式是30 10 * * *并额外指定了时区Asia/Shanghai。这一步很容易踩坑我刚开始就没指定时区触发的实际时间直接变成了下午六点半。很多定时调度器默认按 UTC 执行如果你用的是 Day of Week 类型的时间一定要检查清楚时区设置建议直接写成带时区的 cron 表达式。5.3 连续跑三天观察推送时间、内容质量和失败率配置好定时器之后我没有第二天就不管了而是连续盯了三天。每天的检查动作是固定的看推送时间是否稳定在十点半前后五分钟内点开日报内容对照当天的行业动态确认没有明显漏掉的大事扫一遍有没有重复信息和明显废话去执行后台看一眼运行日志是否全绿。三天里遇到过一个问题有一天推送晚到了接近一小时。查了日志发现是信息源里有一个站点响应超时抓取步骤等待了太久。我在该信息源的抓取配置里加了最大等待时间和失败跳过策略之后就没有再出现类似问题。连续三天稳定之后我才真正把这条流水线从“今天想起来就跑一次”的状态切换成“完全无人值守”。6. 三周实测排雷五个问题与完整排查链路6.1 日报迟到半小时时区设置与执行队列的双重原因有几天日报的推送时间从十点半迟到了十一点左右而且不是固定推迟时好时坏。我先去查看了 WorkBuddy 的任务日志发现任务触发时间本身是准时的说明定时器环节没有大碍。再仔细看每一步的执行耗时发现等待时间主要花在抓取步骤上有几个外部源响应非常慢抓取器一直在等超时。顺着这个线索查下去还发现执行队列里的任务优先级问题。我那个时段还挂了几个其他的定时任务它们和日报任务共用执行队列前一个任务还没跑完日报任务只能排队。这次的解决方法是双管齐下给每个外部信息源设置独立的超时上限同时把日报任务的优先级调到最高。改完后再观察一周推送时间稳定回到了十点半前后。6.2 同一篇资讯连续三天出现去重要分三层做日报里持续出现同一篇旧资讯的当天我先把当天的原始信息源列表拉出来发现那篇资讯确实还在信息源头里源头没有把它标记为已读或过期。等于说抓取层直接把旧内容当成新材料又喂给了摘要层摘要层又没有记忆自然不知道这条已经推过。这个问题牵扯到三个层级抓取后会有一个短暂缓存缓存到期后如果源站仍然返回这条去重失效摘要层没有历史记忆面对同一批内容它不会主动标记“这条推过了”输出层也没有维护已推送条目池。我的处理方式是给整个 Skill 加了一个已推送标题数据库存储格式是“标题 链接 哈希值”。每天的日报生成完毕后所有条目的链接哈希都会写入这个库下一次抓取时先做一次哈希比对命中的直接剔除。这一步加上之后重复资讯的问题就彻底消失了。6.3 摘要越写越长定量约束比“简洁一点”更有效有一段时间日报的总长度接近六千字在微信里被折叠得厉害。我本想通过提示词里加一句“请简洁一些”来解决问题结果完全没有用。后来检查了模型输出发现每一条的目标字数都超了标题也很长。这里的根因在于“简洁”是一个模糊词大模型对这句话的理解和执行都不稳定。我把提示词里的要求全部改成硬性数字约束今日头条摘要不超过 150 字值得关注每条不超过 120 字今日判断不超过 80 字。同时给摘要步骤设置了输出 token 上限从源头卡住长度。这两处改动之后日报正文基本控制在 2400 字左右在微信里阅读体验马上不一样了。6.4 某天推送静默失败Webhook 限流与重试策略三周里有过一次推送失败日报内容正常生成但微信里什么都没收到。排查日志发现 HTTP 请求返回了 429 状态码这是 Server酱 在限流。我们的定时任务发送时间比较集中而且手动测试时也在同一时段发了多条正好触到了频控。排查链路是先看推送步骤的返回码确认不是请求格式问题再看 Server酱 的介绍确认它的免费额度有限制最后检查是不是自己在短时间内发多了。解决方案分两层在推送步骤里加入简单的指数退避重试逻辑首次失败等 15 秒重试第二次失败等 60 秒同时增加一个备用通道如果 Server酱 连续失败三次自动调用企业微信机器人再推一次确保关键通知不会静默丢失。6.5 改了 Skill 规则次日没生效版本化与强制回归验证有一次我调整了信息源列表加了一个新的技术博客进去第二天看日报却发现新源的内容完全没出现。检查配置发现我的修改确实保存了但 WorkBuddy 的定时任务当时还在运行旧版本实例需要重新触发才能加载最新配置。这个问题暴露了一个容易忽视的点Skill 配置是带版本的保存草稿不等于线上生效。现在的习惯是每次改动配置后先手动执行一遍整个 Skill 做回归验证确认改动已经加载成功再让它正常定时跑。同时我会在 Skill 的配置说明里写一个版本号比如 V1.3、V1.4每天的日报里也带一个版本字段。确认当天跑的是最新版本这一个小习惯帮我省去了大量“改了没生效”的烦恼。整套系统跑到第三周我最大的感受是每天早上终于不再被不确定的信息流牵着走了。每天十点半我拿到的是一份已经经过筛选和排序的结果而不是十个标签页里乱七八糟的原文。这套用 WorkBuddy 搭的自动日报流程真正价值的核心并不是替我省掉了多少时间而是把“选择看什么”的主动权交回到我手里——这玩意的可扩展性比我想象的大得多社区里那些多 Agent 协作、信息自动归档的玩法我也已经在尝试了。
WorkBuddy实战：搭建每日AI日报自动化流水线，定时推送微信
上午十点半微信准时弹出一条新消息标题写着“AI 日报第 24 期”。点开以后内容已经被排得清清楚楚今日最值得关注的一件事、三个值得留意的开源项目、一条值得细读的观点。这不是我订阅的某个科技媒体号而是我自己搭的一条自动化流水线——WorkBuddy 负责定时触发和调度 AI 模型我给它配了一个生成日报的 Skill每天上午十点半自动抓取信息源让大模型完成摘要、筛选和排序最后借道 Webhook 把内容送进微信。花了大半天搭好之后它已经连续跑了三周中间踩了不少坑也顺手修了不少问题。这篇文章打算把整套方案、配置思路和排雷过程尽量完整地写出来。如果你也被“每天起床先刷两小时资讯”这件事困扰或者正好想把日常工作里那些重复的信息收集交出去这里面的大部分思路应该可以直接参考。1. 早晨的信息焦虑是自动化最值得解决的第一件事1.1 每天睁眼先刷两个小时资讯的恶性循环先聊聊我为什么折腾这件事。以前我每天早上醒来的第一件事是打开手机里那批固定的资讯入口几个技术媒体、开源社区的热榜、社交平台的时间线、常看的技术博客。目的很简单生怕漏掉 AI 领域的重要动态。但实际效果很差一个多小时刷完脑子里留下的有效信息往往只有两三条大部分时间花在“确认没有大事发生”上。更尴尬的是真正重要的一条消息经常藏在时间线二十条之后手指快速划过时根本注意不到。这个状态说白了就是信息焦虑。表面上每天都在接收信息实际上没有一条真正进入决策层。后来我意识到问题不在于信息量不够恰恰相反是信息量太大但过滤太粗糙。我需要的是每天早上有一份已经整理好的结果放在面前而不是自己去承担那个筛选过程。于是“定时推送一份 AI 日报”这个需求就被记了下来。1.2 为什么候选方案那么多最终锁定了 WorkBuddy想解决这个需求可选方案其实不少。最传统的是 crontab 加 Python 脚本每天定时去爬几个源再调大模型接口做摘要最后通过消息推送服务发到微信。这套方案我早年写过能用但维护成本不低RSS 结构一变要改代码网页布局一变要改解析规则任务跑挂了还没人通知。后来也试过 n8n 这类自动化平台优点是环节都被模块化了但 AI 编排能力偏弱想把“判断一条新闻值不值得进日报”这种模糊逻辑写清楚反而费劲。现成的 AI 日报订阅服务我也试过几个问题在于信息源不透明它推什么我看什么过几天就发现内容偏向严重。最终选中 WorkBuddy主要看中的是它把大模型能力、Skill 机制和定时任务放在了同一个环境里。Skill 允许我用自然语言而不是代码来定义执行规则后续改信息源、改打分标准、改输出模板都只是在配置里调整文字不用重新部署脚本。对不想维护一堆代码的人来说这是最省心的一条路。1.3 一条日报从触发到送进微信中间发生了什么这条流水线可以拆成七个环节定时器触发、抓取信息源、初步清洗、LLM 摘要与筛选、格式排版、调用 Webhook、微信展示。十点半一到WorkBuddy 里的定时任务先唤醒执行器接着按我在 Skill 里配置的抓取清单逐个拉取信息源内容。拿到原始材料后清洗阶段负责去掉广告噪声、剔除重复内容、过滤掉明显低质量的信息。然后进入 LLM 阶段大模型按照提示词完成摘要、打标签、打分、排序。最后一步是把整理好的结果按照日报模板拼装成 markdown 文本通过 Webhook 推到我的微信。整个流程没有什么黑魔法关键就在于每一层都要有明确的输入输出出了问题才查得到是哪一环在报错。2. 给 WorkBuddy 写“日报任务”前我先把规则拆成了三层2.1 Skill 的本质把人的判断标准翻译成机器可执行的指令Skill 这个词在 WorkBuddy 里看着唬人想明白之后就很简单它相当于给一个能力很强但没有任何主观立场的实习生写工作手册。大模型确实什么都知道一点但它不会自动知道“你关心的 AI 动态”具体指什么不会知道你信任哪些站点更不会知道一条信息到底凭什么进你的日报。很多人搭自动化日报失败问题就出在规则太含糊。我一开始写的提示词比这还简单基本是“请帮我整理今天的 AI 新闻”结果得到的日报像一份低配版的新闻联播所有条目平均用力谁也没说清楚它为什么值得我看。后来把规则拆成三层——数据源层决定看什么判断层决定留下什么输出层决定长什么样——日报的质量才真正稳定下来。这个分层思路比具体用什么参数重要得多值得在这里展开说。2.2 我的信息源清单与抓取策略数据源层我现在一共配了五类来源。第一类是聚合型 RSS包括 Hacker News、Product Hunt 和 arXiv 的 AI 分类这类源头信息量大适合做第一轮粗筛。第二类是固定的技术媒体和官方博客通过 RSS 订阅按关键词过滤确保重大发布不漏。第三类是 GitHub Trending 上 AI 相关的仓库重点捕捉新出现的大模型项目和开发工具。第四类是社区讨论里热度快速上升的帖子这种往往是早期信号比媒体报道要快半天到一天。第五类是检索型任务如果前四类跑完内容仍然偏少就让 Agent 使用内置搜索能力补几条关键词热点。抓取顺序也有讲究先抓能拿到全文的源再抓只有标题和链接的源。全文越完整后面摘要的质量越高这一点我是对比试出来的让模型从三十个标题里猜内容远不如给它十篇全文让它挑三篇。为了控制抓取时间我会把每个源的最大抓取条数都限制好避免一次任务拉回来几百条标题反而把真正有效的内容淹没。2.3 分段编排抓取、清洗、摘要、排版各干各的在设计 Skill 的执行流程时我特意没有把所有工作塞进一个智能体对话里而是拆成了四个独立步骤。这样做主要是为了三点。第一是可控性。一个步骤做一件事日志会非常干净。如果日报里突然出现乱码我可以直接定位到摘要这一步的输入输出而不必在一大段对话历史里翻找。第二是成本。分段执行可以在每一段都设置不同的模型档位抓取和清洗用便宜快速的小模型摘要和排版用能力更强的大模型整体花费比所有内容都走同一个高级模型要低不少。第三是排查方便这一点等会讲踩坑时还会提到。每个步骤的输入输出我都做了约定抓取步骤输出的是结构化条目数组清洗步骤输出的是干净文本列表摘要步骤输出的是带字段的对象。字段固定下来之后后面排版才不需要想破脑袋去猜模型吐出来的格式。3. 日报内容结构怎么让大模型替你筛出“真正值得看的东西”3.1 日报模板我要的是“领域雷达”不是“新闻联播”早期那种平铺式日报说实话连我自己都没看完过。我真正需要的是十分钟之内判断出今天 AI 领域发生了什么哪件事跟我当前的工作方向有关哪些变化需要我调整接下来的计划。所以我把日报模板固定成了五个模块。第一个模块是“今日头条”只保留一条最有价值的信息写清楚发生了什么、为什么重要、可能影响哪些人。第二个模块是“值得关注”放三到五条次重要内容每条一句话摘要加一句点评。第三个模块是“开源与工具动态”记录两到三个具体项目写清楚项目是做什么的以及它的看点和适用场景。第四个模块是“数据与观点”挑一条值得细读的评测或者有分歧的讨论附上原文链接。第五个模块是“今日判断”让模型综合当天信息给出一句话倾向性判断这部分相当于模型替我做的二次加工。实际体验下来这五块结构最大的好处是它逼着模型做取舍而不是把所有东西都塞进来。没有“今日头条”这个限制时模型倾向于给每条内容一个差不多的权重结果就是什么都没有被突出。设定了只允许一条之后模型反而需要真正去比较和排序这个比较过程就是筛选价值最大的部分。3.2 筛选规则的核心是“信息权重”不是“关键词”如果只靠“包含 ChatGPT 就保留”这种关键词过滤日报最后一定会变成轰炸式的列表。我的做法是给每条候选信息打四个维度分。第一维是相关性判断这件事是否与 AI、大模型、Agent 工作流直接相关。第二维是时效性看它是不是过去 24 小时内的新变化。第三维是权威性一手信源得分高于二手转述官方发布高于小道消息。第四维是差异度看这条信息跟已经选入日报的内容是否存在视角上的重复。每个维度一到五分加权求和后设定一个入选阈值。这个打分逻辑本身不复杂大模型执行起来很稳关键在于权重可以分阶段调。比如某天正好赶上一场重磅发布会我会把差异度权重调高避免十条内容全在讲同一件事的多篇稿子。这套权重配置不是一次到位的我是跑了快一周之后才慢慢调到目前这个比较顺手的状态。3.3 用自然语言把质量要求写进系统提示词日报质量的上限基本取决于系统提示词写得有多具体。这里分享一段我目前在用的提示词框架可以直接复制到 WorkBuddy 的 Skill 配置里改一改用你是一个面向 AI 领域从业者的情报编辑。我会分批给你原始信息源内容你需要完成筛选和摘要。 约束条件 1. 只保留与 AI 大模型、Agent 产品、AI 开发工具直接相关的信息。 2. 今日头条只能有 1 条必须是你认为最重要的动态要写清楚发生背景和影响面。 3. 值得关注的条目控制在 3-5 条每条摘要不超过 120 字点评不超过 60 字。 4. 开源项目要给出项目名称、主要用途、近期的突出变化。 5. 所有判断必须基于今天的材料不要写泛泛的行业趋势。 6. 整体语气中立不要用夸大词不允许出现“震惊”“重磅”这类表述。这段提示词我迭代过四版。一开始没有约束字数模型把每条都写成两百字日报总长度直奔六千字后来加了硬性字数限制又出现了模型用列表硬凑的毛病。现在的版本强调的是“基于今天的材料”和“不要写泛泛的行业趋势”这两句话确实把输出质量拉高了一截。4. 微信送达方案我绕开了个人号限制用 Webhook 走通4.1 为什么不考虑“直接调用个人微信发消息”微信推送是这套流程的最后一环也是很多人在配置中最纠结的一步。这里面有一个需要明确的边界微信没有向个人用户开放的推送接口你不能写代码直接给你的私人微信发消息。市面上确实有一些方案号称能绕过这个限制基本思路是去操作微信客户端的内部逻辑。我不建议用封号风险是其一稳定性是其二。你现在搭的是一个每天都要跑的生产流程不是做实验通知链路出事会比日报内容出错更麻烦。正确解法是走向上兼容的通道——用 Server酱、PushPlus、企业微信群机器人这类服务它们利用的是微信对外开放的消息接收能力本质上是合规微信生态内成熟的解决方案。4.2 三种方案横向对比Server酱、PushPlus、企业微信群机器人这三条路我都实际跑过简单做一个横向对比方案接入成本免费额度稳定性我的评价Server酱最低注册即拿 SendKey免费额度对个人日报足够很高曲线最平滑适合快速跑通PushPlus低需要关注公众号免费可用部分高级功能收费高支持自定义模板中文体验好企业微信群机器人需要创建企业微信群免费极高适合和团队成员共享日报我日常用的是 Server酱主要原因是接入最简单只需要一个 SendKey 就能发消息推送成功与否还有明确的返回状态码。如果你的日报是给团队里几个人一起看的企业微信群机器人会更合适一条 Webhook 地址就能让一整个群收到消息。4.3 用 Webhook 把日报送进微信完整配置流程以 Server酱为例整个配置过程只需要三步。第一步打开 Server酱官网完成微信登录后复制你的 SendKey。第二步找到 Server酱的推送接口地址地址格式是固定的https://sctapi.ftqq.com/{SendKey}.send。第三步从 WorkBuddy 的“Webhook 发送”步骤发起一个 POST 请求把日报标题和正文分别放在 title 和 desp 两个字段里。我在 WorkBuddy 里的实际做法是让排版步骤直接输出成 markdown然后由推送步骤组装成下面的请求import requests send_key 你的SendKey url fhttps://sctapi.ftqq.com/{send_key}.send payload { title: AI 日报6 月 9 日, desp: # AI 日报\n\n## 今日头条\n...这里放完整日报内容..., } resp requests.post(url, datapayload) print(resp.status_code, resp.text)这里有一个实测下来的细节Server酱的 desp 字段是支持 markdown 渲染的但消息渲染时对表格和超长链接支持一般所以我在排版步骤里刻意少用表格多用简洁的层级标题和项目符号。日报被推送到微信之后是要在手机屏幕上阅读的排版密度低一点、留白多一点阅读感受完全不一样。5. 无人值守的关键首次端到端跑通与定时器配置细节5.1 先手动跑一遍每个环节都要看到中间产物正式交给定时器之前我先手动点击执行了好几次整个 Skill保证每一环节的输出都符合预期。第一次跑通新流程最容易犯的错误就是一次性看到最终推送然后就默认系统健康。等第二天出了问题你根本判断不了是抓取挂了、摘要崩了还是推送接口变了。我的办法是把执行过程拆开验证。先单独测试数据源抓取看返回的条目数量和字段是否完整再单独测试摘要步骤看大模型是否遵守了字数和格式约束然后把排版结果放进 Server酱 的文档里检查渲染效果最后才把整个流程串起来完整跑一次。每一步的中间产物我都会在 WorkBuddy 的执行日志里看一眼确认信息源、清洗逻辑、摘要模板、推送参数这些都是按预期工作的。5.2 十点半这个时间点的选择逻辑定时时间选在十点半是经过一番权衡的。一开始我贪早设过早上八点跑了两天就发现问题夜间更新的信源到八点往往还不完整国外社区的讨论经常是北京时间早上九、十点才开始活跃八点去抓抓到的经常是前一天的旧材料。反过来设到中午十二点也不行等日报送达半天已经过去了时效性打了折。十点半刚好卡在大多数信息源完成夜间更新、白天新内容还没涌进来的空档期。在 WorkBuddy 里配置定时器时我用的表达式是30 10 * * *并额外指定了时区Asia/Shanghai。这一步很容易踩坑我刚开始就没指定时区触发的实际时间直接变成了下午六点半。很多定时调度器默认按 UTC 执行如果你用的是 Day of Week 类型的时间一定要检查清楚时区设置建议直接写成带时区的 cron 表达式。5.3 连续跑三天观察推送时间、内容质量和失败率配置好定时器之后我没有第二天就不管了而是连续盯了三天。每天的检查动作是固定的看推送时间是否稳定在十点半前后五分钟内点开日报内容对照当天的行业动态确认没有明显漏掉的大事扫一遍有没有重复信息和明显废话去执行后台看一眼运行日志是否全绿。三天里遇到过一个问题有一天推送晚到了接近一小时。查了日志发现是信息源里有一个站点响应超时抓取步骤等待了太久。我在该信息源的抓取配置里加了最大等待时间和失败跳过策略之后就没有再出现类似问题。连续三天稳定之后我才真正把这条流水线从“今天想起来就跑一次”的状态切换成“完全无人值守”。6. 三周实测排雷五个问题与完整排查链路6.1 日报迟到半小时时区设置与执行队列的双重原因有几天日报的推送时间从十点半迟到了十一点左右而且不是固定推迟时好时坏。我先去查看了 WorkBuddy 的任务日志发现任务触发时间本身是准时的说明定时器环节没有大碍。再仔细看每一步的执行耗时发现等待时间主要花在抓取步骤上有几个外部源响应非常慢抓取器一直在等超时。顺着这个线索查下去还发现执行队列里的任务优先级问题。我那个时段还挂了几个其他的定时任务它们和日报任务共用执行队列前一个任务还没跑完日报任务只能排队。这次的解决方法是双管齐下给每个外部信息源设置独立的超时上限同时把日报任务的优先级调到最高。改完后再观察一周推送时间稳定回到了十点半前后。6.2 同一篇资讯连续三天出现去重要分三层做日报里持续出现同一篇旧资讯的当天我先把当天的原始信息源列表拉出来发现那篇资讯确实还在信息源头里源头没有把它标记为已读或过期。等于说抓取层直接把旧内容当成新材料又喂给了摘要层摘要层又没有记忆自然不知道这条已经推过。这个问题牵扯到三个层级抓取后会有一个短暂缓存缓存到期后如果源站仍然返回这条去重失效摘要层没有历史记忆面对同一批内容它不会主动标记“这条推过了”输出层也没有维护已推送条目池。我的处理方式是给整个 Skill 加了一个已推送标题数据库存储格式是“标题 链接 哈希值”。每天的日报生成完毕后所有条目的链接哈希都会写入这个库下一次抓取时先做一次哈希比对命中的直接剔除。这一步加上之后重复资讯的问题就彻底消失了。6.3 摘要越写越长定量约束比“简洁一点”更有效有一段时间日报的总长度接近六千字在微信里被折叠得厉害。我本想通过提示词里加一句“请简洁一些”来解决问题结果完全没有用。后来检查了模型输出发现每一条的目标字数都超了标题也很长。这里的根因在于“简洁”是一个模糊词大模型对这句话的理解和执行都不稳定。我把提示词里的要求全部改成硬性数字约束今日头条摘要不超过 150 字值得关注每条不超过 120 字今日判断不超过 80 字。同时给摘要步骤设置了输出 token 上限从源头卡住长度。这两处改动之后日报正文基本控制在 2400 字左右在微信里阅读体验马上不一样了。6.4 某天推送静默失败Webhook 限流与重试策略三周里有过一次推送失败日报内容正常生成但微信里什么都没收到。排查日志发现 HTTP 请求返回了 429 状态码这是 Server酱 在限流。我们的定时任务发送时间比较集中而且手动测试时也在同一时段发了多条正好触到了频控。排查链路是先看推送步骤的返回码确认不是请求格式问题再看 Server酱 的介绍确认它的免费额度有限制最后检查是不是自己在短时间内发多了。解决方案分两层在推送步骤里加入简单的指数退避重试逻辑首次失败等 15 秒重试第二次失败等 60 秒同时增加一个备用通道如果 Server酱 连续失败三次自动调用企业微信机器人再推一次确保关键通知不会静默丢失。6.5 改了 Skill 规则次日没生效版本化与强制回归验证有一次我调整了信息源列表加了一个新的技术博客进去第二天看日报却发现新源的内容完全没出现。检查配置发现我的修改确实保存了但 WorkBuddy 的定时任务当时还在运行旧版本实例需要重新触发才能加载最新配置。这个问题暴露了一个容易忽视的点Skill 配置是带版本的保存草稿不等于线上生效。现在的习惯是每次改动配置后先手动执行一遍整个 Skill 做回归验证确认改动已经加载成功再让它正常定时跑。同时我会在 Skill 的配置说明里写一个版本号比如 V1.3、V1.4每天的日报里也带一个版本字段。确认当天跑的是最新版本这一个小习惯帮我省去了大量“改了没生效”的烦恼。整套系统跑到第三周我最大的感受是每天早上终于不再被不确定的信息流牵着走了。每天十点半我拿到的是一份已经经过筛选和排序的结果而不是十个标签页里乱七八糟的原文。这套用 WorkBuddy 搭的自动日报流程真正价值的核心并不是替我省掉了多少时间而是把“选择看什么”的主动权交回到我手里——这玩意的可扩展性比我想象的大得多社区里那些多 Agent 协作、信息自动归档的玩法我也已经在尝试了。
