每天早起刷完一圈公众号和社区热榜才能把当天 AI 圈发生了什么事理清楚。这套动作看起来不费事但日复一日重复说实话挺耗精力。后来我在 WorkBuddy 里给自己设了个“闹钟”在智能体工作台上定义一个日报任务每天上午十点半自动抓取资讯源让大模型整理成一份精简的 AI 日报再通过 Webhook 推进微信。这套流程已经稳定跑了一个多月中间踩了不少坑也改了好几版配置。这篇文章想把从选型、搭建、调试到日常维护的完整过程讲清楚包括那些文档里不会写的细节。如果你也想让 Agent 代替手工盯资讯或者想把定时推送这类小事自动化可以照着这套思路做能少走很多弯路。1. 这个自动化跑起来长什么样先看最终效果1.1 每天十点半收到一份怎样的微信日报先说我每天在微信里实际收到的内容。上午十点半企业微信群机器人会准时推一条 Markdown 消息标题类似“AI 日报 2025-06-12”下面分“今日速览”和“延伸阅读”两段。速览部分就是 3 到 5 条摘要每条控制在 100 字以内只留下信息增量明确的内容延伸阅读部分放原始链接和来源名称方便点开核实。整体算下来从打开微信到把当天重点看完两分钟足够。这里有一个设计细节很关键日报不是简单把链接扔给大模型让它“看着写”而是把摘要和原文分离。摘要负责让人快速判断值不值得看链接负责保留可追溯性。我见过很多自动日报翻车就是因为只给了一段 AI 生成的综述读者想点开原文核实却发现根本没有出处信任感一下就没了。消息模板大概是这样的结构# AI 日报 2025-06-12 **今日速览** 1. **模型**某开源模型发布新版本推理速度提升约 40% 2. **工具**某 AI 编程工具上线 Agent 模式可自动定位并修复 bug 3. **论文**一篇关于 RAG 优化的论文登上技术热榜 4. **开源**某团队发布轻量级向量数据库支持本地部署 **延伸阅读** - [模型发布详情](https://example.com) | 来源xxx - [Agent 模式介绍](https://example.com) | 来源xxx选十点半也是有讲究的。太早的话很多资讯源还停留在前一天的更新抓出来的是旧闻太晚的话大家已经开始干活推送容易被忽略。十点半这个时间点上班族基本已经进入工作状态信息源该更新的也更新完了正好适合在地铁上或者刚坐下时扫一眼。1.2 这套流程的三个关键环节拆解整套自动化可以拆成三个环节采集、生成、推送。采集环节负责把散落在不同资讯源的内容拉回来。我用的主力是 RSS 和一些公开 API这部分不需要大模型参与属于确定性操作脚本和 Skill 都能干。生成环节是 WorkBuddy 的核心价值所在把抓到的原始条目整理成有条理的日报。这一步必须用大模型因为原始内容通常带着噪声——同一件事多个源都在报、标题党、广告、时效性不强的科普内容都需要模型来判断取舍。推送环节最简单把渲染好的 Markdown 文本 POST 到企业微信群机器人 Webhook 上微信自动就弹出来了。我把这三个环节设计成独立步骤而不是一个大 prompt 从头干到尾。原因很简单链路中任何一环出问题独立步骤能让故障定位变得非常容易。推送失败就查 Webhook内容质量差就调总结规则抓取为空就看源有没有挂。这个思路有点像编辑部流程——记者负责采写编辑负责定稿发行部负责派送各管一段出了事能找到具体责任人。2. 技术选型为什么是 WorkBuddy 加微信 Webhook 这条链路2.1 为什么用 WorkBuddy 而不是裸写 Python 脚本老实说用 Python 脚本也能实现同样的事。你可以用 requests 抓 RSS用 jieba 或者干脆截取前几百字当摘要再用 requests 推送到 Webhook。但问题是一旦你想让日报质量“像人写的”脚本的复杂度会快速上升摘要怎么做、重复条目怎么去重、不同源的格式怎么统一、大模型 API 的 Key 怎么管理、超时怎么重试、Token 费用怎么控制这些全是工程细节。WorkBuddy 这类智能体工作台的价值在于它把这些外围工程封装好了。我不需要自己维护抓取框架也不用处理大模型 API 的鉴权和重试只需要用自然语言和结构化配置告诉它抓哪些源、按什么规则总结、发到哪里。它内置的 Skill 机制还能让这套流程变成可复用的任务我今天想让日报多包含一个资讯源改几行配置就能生效不用重新部署代码。当然WorkBuddy 不是万能的。如果你的数据规模很大比如每天要处理十几万条资讯或者对延迟有极高要求那该写代码还是得写代码。我这个场景是“每天几十分钟内处理几十条信息”属于典型的轻量自动化WorkBuddy 的编排能力刚好覆盖而且改起来特别快。这是我认为它比裸写脚本更适合这个任务的根本原因。2.2 推送到微信的几种通道对比“送进微信”看起来是一句话实际有四种完全不同的实现路径。我评估过 Server酱、WxPusher、微信测试号模板消息、企业微信群机器人这四个方案最后选了企业微信群机器人。为什么看下表就清楚了方案接收方式是否免费Markdown 支持维护难度企业微信群机器人微信内群聊免费部分支持最低Server酱个人微信服务号免费额度支持低WxPusher个人微信服务号免费额度支持低微信测试号模板消息微信内模板消息免费不支持高企业微信群机器人最吸引我的一点是它可以开一个只有自己的群把群当作私人通知中心兼历史存档。所有日报都在同一个群里想回溯哪天内容直接翻聊天记录就行。Server酱和 WxPusher 虽然也能推到个人微信但毕竟经过第三方服务中转多一层依赖就多一个故障点。微信测试号模板消息的格式限制太多只适合发简单通知不适合承载日报这种结构化内容。2.3 AI 日报数据源的取舍数据源是整个日报的地基源选不好后面模型再强也白搭。我第一版贪心一口气配了七八个源结果一半是低质量自媒体每天生成的日报充斥着标题党。后来砍到三个稳定源质量反而上来了。我的取舍标准是三条内容质量稳定、更新频率可靠、抓取成本低。RSS 是最适合的载体因为它的结构统一、没有复杂的反爬逻辑解析成本极低。一些网站提供官方 API比如 GitHub Trending 和 Hacker News API这些可以直接用来抓开源和海外开发者动态。微信公众号的内容质量高但抓取难度大而且涉及各种限制第一版完全没必要碰。热榜类接口也先不加很多需要维护 Cookie 和签名稳定性堪忧。建议读者起步阶段选 3 到 4 个源就够先跑一周看看效果再根据日报的实际质量做加减法。源不在多能持续产出可靠信息才重要。2.4 定时触发方案的说明定时这块WorkBuddy 的调度器直接支持 Cron 表达式我配置的是0 30 10 * * ?表示每天上午十点半运行。这里有一点值得提醒尽量不要用整点。整点往往是服务器上各种定时任务的集中执行时间无论是 WorkBuddy 所在的机器还是资讯源的更新频率都可能出现资源竞争。用10:30这类带偏差的时间能避开不少偶发问题。另一个容易踩的坑是时区。如果 WorkBuddy 运行环境默认是 UTC配置完十点半不校验时区真实执行时间就会变成北京时间下午六点半。所以配置定时任务时一定要显式确认时区设置我这边直接锁死成Asia/Shanghai。3. 环境准备把地基打好再写技能3.1 WorkBuddy 安装与工作台配置安装部分没什么特别的从官网下载对应你系统的安装包Windows、macOS、Linux 都有对应版本装完登录账号就能进工作台。需要注意的一点不同版本之间的菜单位置可能有差异但核心逻辑是一样的——工作台、Skill 配置、任务调度、运行日志这几个模块是跑自动化流程必不可少的部分。我建议新装完先别急着做自定义任务花十分钟把 WorkBuddy 自带的示例 Skill 跑一遍。这样做不是为了看演示而是为了确认三件事大模型服务是不是正常的、工作台能不能正常执行任务、日志输出在哪个位置。确认这三个基础点之后再做自定义配置会顺畅得多至少不会把“模型没配置好”误判成“我的 Skill 写错了”。3.2 拿到企业微信群机器人的 Webhook 地址微信推送给日报需要先有一个接收消息的“信箱”这个信箱就是企业微信群的群机器人。操作路径很简单在微信里新建一个群可以只拉自己一个人也可以拉一个常用的同事群然后在群设置里找到“群机器人”添加一个机器人系统会生成一个 Webhook 地址形如https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx把它复制下来备用。这里有个安全提醒keyxxx这部分等于是这个群的专属身份凭证任何人拿到它都能往你群里推消息。千万不要把它提交到公开的代码仓库或配置文件里我的做法是保存在本地配置中设置好权限。如果哪天发现群里出现不明消息第一时间到群机器人设置里重置这个 key。3.3 配置数据源RSS 与 API 的整合数据源配置文件我建议单独维护不要和 Skill 的逻辑混在一起。这样换源、加源都只是改配置不用动流程。我用的源清单是 YAML 格式大致长这样sources: - name: hacker_news type: rss url: https://news.ycombinator.com/rss max_items: 20 - name: github_trending type: api url: https://github.com/trending max_items: 10 - name: tech_weekly type: rss url: https://example.com/feed.xml max_items: 15每个源除了名称、类型、URL还配了max_items字段限制每个源最多取多少条原始内容。这个字段很重要如果不限制大模型处理的内容量会忽高忽低日报的长度也很难控制。我额外加了一个兜底机制如果某个源连续三次抓取失败就自动把它从本次结果里剔除并在日志里标注防止一个源出问题拖垮整条日报。3.4 验证推送链路通不通配置完数据源先别急着写 Skill。花一分钟验证 Webhook 通不通这个步骤能省掉后面大量的排查时间。在 WorkBuddy 的 HTTP 执行器里或者直接在终端里用 curl 模拟一条消息curl https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d {msgtype:markdown,markdown:{content:**链路测试**WorkBuddy 日报通道正常}}如果返回{errcode:0,errmsg:ok}说明推送链路完全正常。如果返回错误码先别慌把错误信息打出来看大多数时候是 URL 拼接错了或者 JSON 格式不对。这一步做完后面 Skill 跑起来只要专注内容逻辑不用再怀疑通道是否可靠。4. 核心实现用 Skill 定义“日报生成器”4.1 给 WorkBuddy 定几条长期规则这是整个项目里我认为最值得花心思的一步。WorkBuddy 支持定义全局规则一旦设定后续所有任务都会自动继承不用在每次调用时重复输入。我给日报定的规则主要有五条所有日报必须使用简体中文每条新闻摘要不超过 100 字只保留有明确信息增量的内容只保留能提供可点击原始来源的消息无法追溯的不收录拒绝广告、标题党、纯科普无干货的内容如果当天有效信息不足 3 条直接说明“今日无重大更新”不要硬凑。这些规则看起来简单但实际效果立竿见影。在设规则之前模型隔三差五会塞进来一些“震惊体”内容设完之后输出稳定了很多。更重要的是这些规则后续可以被周报、竞品监控等其他任务重复使用属于典型的“一次配置、长期受益”。4.2 创建日报 Skill从抓取到推送的完整流程有了规则接下来就是创建日报 Skill。我给这个 Skill 起名daily_ai_report它的输入是当天的日期输出是一份待推送的 Markdown 文本。整个流程分成四步抓取源、去重过滤、大模型总结、渲染并推送。配置结构大致如下name: daily_ai_report schedule: 0 30 10 * * ? timezone: Asia/Shanghai default_timeout: 120s sources_file: ./config/sources.yaml steps: - fetch_sources - dedupe_and_filter - summarize_with_llm - render_and_push这里我特意把四个步骤拆开而不是写成一个“一句话让模型干完”的 Prompt。原因在于可调试性如果推送出去的日报内容不对我可以单独运行fetch_sources看看原始抓取是否正常再单独运行summarize_with_llm看总结质量。每步独立运行日志里能看到每步消耗的时间和输出条数问题一下子就能定位。4.3 配置定时任务从每分钟到每天十点半Skill 创建好之后进入 WorkBuddy 的任务调度页面新建一个定时任务绑定daily_ai_report调度表达式填0 30 10 * * ?时区选Asia/Shanghai保存即可。但我强烈建议第一次调试时不要直接设成十点半。正确流程是先把它改成每分钟执行一次手动触发验证内容没问题之后再改成每天执行。我第一版就是直接设好十点半结果等第二天看到日报已经坏了白白浪费了一个调试周期。改成每分钟跑一次之后任何改动最多一分钟就能看到结果调试速度提升了不止一个量级。确认没问题后把调度改回0 30 10 * * ?再观察两天。稳定之后就可以彻底不管了。4.4 用一条测试指令跑通全流程定时任务配置完之后先别急着等第二天。直接在 WorkBuddy 里手动触发一次daily_ai_report把日期参数传成当天然后盯着任务日志看每一步的输出。手动触发时重点检查三件事第一日报内容是否为空如果为空多半是数据源抓取出问题第二链接是否可点击如果模型生成的链接格式不对点开会报错第三Markdown 渲染是否正常尤其要注意企业微信对 Markdown 的兼容性限制。这三项都通过了再让定时任务自动跑。这个“先手动后定时”的原则做自动化的人应该都深有体会能少踩无数坑。5. 上线后我踩过的坑实测排错记录5.1 Webhook 推送失败错误码解读第一个坑来得很快。手动触发时 Webhook 返回了一个非零错误码日报没有推出去。我把常见错误码整理成了下表方便对照返回码含义处理方式0成功无需处理400参数错误或消息超长压缩正文到 1MB 以内实际建议控制在 4096 字节内44004content 为空检查渲染步骤输出是否有内容45009频率超限等待 60 秒后重试调试时不要高频推送93000key 无效检查 Webhook URL 拼接是否正确我那次遇到的是 400原因就是日报正文太长。企业微信群机器人的消息体对长度有限制而大模型生成的 Markdown 带着各种符号字节数很容易膨胀。解决办法很简单在渲染环节加一个字符长度控制超过 4096 字节就自动截断并保留完整版在日志里供查看。5.2 Markdown 兼容性表格和代码块不要用第二个坑是格式问题。我第一版日报模板里用了表格结果推送到微信后显示成一堆乱糟糟的纯文本完全没法看。查了之后才发现企业微信群机器人的 Markdown 只支持一个子集标题、加粗、链接、无序列表、引用这些基础语法没问题但表格、复杂代码块、图片这类高级语法要么被忽略要么直接展示成原始字符。解决方案很朴素模板全部改用加粗加无序列表链接用标准 Markdown 格式。改完之后再推送渲染就稳定了。这条经验也适合所有群机器人推送场景——宁可模板简单一点也别挑战兼容性边界。5.3 定时任务没触发时区与进程问题有一天我等到十一点也没收到日报去翻任务历史发现定时任务压根没跑。排查下来有三个可能最终锁定在 WorkBuddy 所在机器的时区设置上系统时区是 UTC我配置的Asia/Shanghai没生效十点半实际被当成了某个 UTC 时间执行结果自然是错乱的。这类问题比较隐蔽因为配置界面显示的是北京时间但底层调度可能读的是系统时区。解决的套路是先看任务执行历史里最近一次成功时间如果时间明显不对先调整系统时区再测试如果历史为空说明任务根本没被调度起来检查是否被暂停或者调度表达式写错。另外注意WorkBuddy 本身需要保持运行状态如果设备关机或者进程退出定时任务自然也不会触发。这个属于使用习惯问题没有代码能解决。5.4 日报空转数据源超时和去重误杀跑了一周后又出现一个怪现象某天日报只推了一条消息内容还是“今日无重大更新”。我去查日志发现其实是数据源出问题了——一个 RSS 源抓取超时另一个源返回了空列表去重逻辑又把昨天已经收录过的条目全过滤掉了最后留给模型的有效输入几乎为零。这个问题暴露了初始设计的一个缺陷我太依赖单一数据源的可靠性。改进方案是双管齐下。第一给每个抓取步骤加上超时和重试机制连续三次失败才算真正的失败第二设置日报“最小条数兜底”如果有效信息少于 3 条就从最近一周的未重复条目里补充而不是直接宣告“无更新”。这样即使某个源临时抽风日报也能保持基本内容不会出现白板。5.5 排错的核心方法论踩了这几个坑之后我总结出一套排错顺序基本能覆盖大多数自动化任务的问题先看日志。WorkBuddy 的执行历史里记录了每次任务的成功失败状态这是第一个信息源。再看中间输出。手动单独跑一遍“抓取”“总结”“推送”三个步骤用二分法定位问题到底出在哪段。比如推送失败直接用 curl 测 Webhook内容差让 Skill 先输出原始抓取结果看看是不是源本身就脏。最后是迭代验证。改完配置后不要干等定时手动触发一次确认没问题再放回定时。这套方法看起来普通但确实比瞎猜高效得多。自动化任务最怕的不是错误多而是定位错误的路径太长。6. 从日报到自动化工作台后续还能怎么扩展6.1 把同一套流程迁移到行业监控日报跑通之后我很快就发现这套流程的价值不止于 AI 资讯。把数据源换成财经 RSS、把过滤规则改成“只保留企业服务相关内容”一个竞品监控器就出来了。再改一下 Prompt要求模型重点提炼与指定公司相关的动态日报就变成了情报雷达。这个迁移成本之所以低是因为整个 Skill 的结构没有变变的只有配置和规则。WorkBuddy 的全局规则在这里起了作用我之前定的“只保留有明确信息增量、提供可点击来源”的规则在竞品监控里同样适用。对多数人来说建一个自己的自动化信息枢纽比写一个通用爬虫系统要有价值得多。6.2 多端推送把日报同时发到钉钉、飞书和邮件单一通道推送有个风险万一微信临时出问题日报就送不到了。为此我把推送环节做成了“适配器”模式——日报内容只生成一次然后通过不同渠道推送到多个目标。企业微信群机器人、钉钉群机器人、飞书群机器人的 Webhook 结构大同小异核心都是 POST 一段特定格式的 JSON只是字段名略有区别。改造之后每份日报会同时推送到微信和预留的备用通道概率上大大降低了“推送失败导致当天断更”的风险。如果你有团队还可以把日报自动推到团队群里让整个团队共享早间情报。这个扩展本身工作量不大但价值非常直观。6.3 与周报、月度报告联动日报内容每天都会产生一份已经排版好的 Markdown我让 WorkBuddy 把它自动存档到一个本地目录。每周五再运行一个周报 Skill读取这一周的日报文件交给模型合并提炼生成一份“本周 AI 圈动态周报”同样推到微信群里。这一步能实现的前提是我在一开始就定好了全局规则。周报 Skill 不需要重新写一套总结标准模型会自动继承“只保留有信息增量”的原则输出风格和日报一脉相承。如果你有月报、季度回顾之类的需求原理完全一样——把日报当作原料库让模型做二次加工。6.4 如果不想用 WorkBuddy还有什么替代方案最后说一下替代方案。如果不想引入 WorkBuddy 这类工作台最朴素的方式是 GitHub Actions 加 Python 脚本加 Webhook 推送。Python 脚本负责抓取和生成日报GitHub Actions 负责每天定时触发推送还是走企业微信群机器人 Webhook。这个方案的好处是无需本地常驻进程代码完全可控缺点是大模型调用的鉴权、超时重试这些工程细节都需要自己写而且改需求时得动代码不像 WorkBuddy 改规则那么快。两个方案没有绝对优劣。我选 WorkBuddy主要是因为它让“修改日报规则”变成了一次对话级别的操作而不是一次代码变更。如果你更喜欢折腾代码或者希望流程完全依赖云端运行GitHub Actions 也是值得一试的路线。核心逻辑是通用的采集、生成、推送三段式永远不会变。整套流程从能跑到稳定我花了大约两天时间。最大的体会不是技术难点而是规则要定得足够细。第一次跑出来的日报像一篇什么都要提一下的综述看完等于没看后来把规则改成“只保留有明确信息增量、能点开原文核实”之后质量才真正上来。所以如果你想复制这套东西我的建议是先别急着追求全自动化先手动跑十天把你的阅读偏好沉淀成几条清晰的规则再交给定时任务。规则越像你自己日报就越像你想看的样子。
用WorkBuddy自动生成AI日报并推送企业微信：从RSS到Webhook的实践
每天早起刷完一圈公众号和社区热榜才能把当天 AI 圈发生了什么事理清楚。这套动作看起来不费事但日复一日重复说实话挺耗精力。后来我在 WorkBuddy 里给自己设了个“闹钟”在智能体工作台上定义一个日报任务每天上午十点半自动抓取资讯源让大模型整理成一份精简的 AI 日报再通过 Webhook 推进微信。这套流程已经稳定跑了一个多月中间踩了不少坑也改了好几版配置。这篇文章想把从选型、搭建、调试到日常维护的完整过程讲清楚包括那些文档里不会写的细节。如果你也想让 Agent 代替手工盯资讯或者想把定时推送这类小事自动化可以照着这套思路做能少走很多弯路。1. 这个自动化跑起来长什么样先看最终效果1.1 每天十点半收到一份怎样的微信日报先说我每天在微信里实际收到的内容。上午十点半企业微信群机器人会准时推一条 Markdown 消息标题类似“AI 日报 2025-06-12”下面分“今日速览”和“延伸阅读”两段。速览部分就是 3 到 5 条摘要每条控制在 100 字以内只留下信息增量明确的内容延伸阅读部分放原始链接和来源名称方便点开核实。整体算下来从打开微信到把当天重点看完两分钟足够。这里有一个设计细节很关键日报不是简单把链接扔给大模型让它“看着写”而是把摘要和原文分离。摘要负责让人快速判断值不值得看链接负责保留可追溯性。我见过很多自动日报翻车就是因为只给了一段 AI 生成的综述读者想点开原文核实却发现根本没有出处信任感一下就没了。消息模板大概是这样的结构# AI 日报 2025-06-12 **今日速览** 1. **模型**某开源模型发布新版本推理速度提升约 40% 2. **工具**某 AI 编程工具上线 Agent 模式可自动定位并修复 bug 3. **论文**一篇关于 RAG 优化的论文登上技术热榜 4. **开源**某团队发布轻量级向量数据库支持本地部署 **延伸阅读** - [模型发布详情](https://example.com) | 来源xxx - [Agent 模式介绍](https://example.com) | 来源xxx选十点半也是有讲究的。太早的话很多资讯源还停留在前一天的更新抓出来的是旧闻太晚的话大家已经开始干活推送容易被忽略。十点半这个时间点上班族基本已经进入工作状态信息源该更新的也更新完了正好适合在地铁上或者刚坐下时扫一眼。1.2 这套流程的三个关键环节拆解整套自动化可以拆成三个环节采集、生成、推送。采集环节负责把散落在不同资讯源的内容拉回来。我用的主力是 RSS 和一些公开 API这部分不需要大模型参与属于确定性操作脚本和 Skill 都能干。生成环节是 WorkBuddy 的核心价值所在把抓到的原始条目整理成有条理的日报。这一步必须用大模型因为原始内容通常带着噪声——同一件事多个源都在报、标题党、广告、时效性不强的科普内容都需要模型来判断取舍。推送环节最简单把渲染好的 Markdown 文本 POST 到企业微信群机器人 Webhook 上微信自动就弹出来了。我把这三个环节设计成独立步骤而不是一个大 prompt 从头干到尾。原因很简单链路中任何一环出问题独立步骤能让故障定位变得非常容易。推送失败就查 Webhook内容质量差就调总结规则抓取为空就看源有没有挂。这个思路有点像编辑部流程——记者负责采写编辑负责定稿发行部负责派送各管一段出了事能找到具体责任人。2. 技术选型为什么是 WorkBuddy 加微信 Webhook 这条链路2.1 为什么用 WorkBuddy 而不是裸写 Python 脚本老实说用 Python 脚本也能实现同样的事。你可以用 requests 抓 RSS用 jieba 或者干脆截取前几百字当摘要再用 requests 推送到 Webhook。但问题是一旦你想让日报质量“像人写的”脚本的复杂度会快速上升摘要怎么做、重复条目怎么去重、不同源的格式怎么统一、大模型 API 的 Key 怎么管理、超时怎么重试、Token 费用怎么控制这些全是工程细节。WorkBuddy 这类智能体工作台的价值在于它把这些外围工程封装好了。我不需要自己维护抓取框架也不用处理大模型 API 的鉴权和重试只需要用自然语言和结构化配置告诉它抓哪些源、按什么规则总结、发到哪里。它内置的 Skill 机制还能让这套流程变成可复用的任务我今天想让日报多包含一个资讯源改几行配置就能生效不用重新部署代码。当然WorkBuddy 不是万能的。如果你的数据规模很大比如每天要处理十几万条资讯或者对延迟有极高要求那该写代码还是得写代码。我这个场景是“每天几十分钟内处理几十条信息”属于典型的轻量自动化WorkBuddy 的编排能力刚好覆盖而且改起来特别快。这是我认为它比裸写脚本更适合这个任务的根本原因。2.2 推送到微信的几种通道对比“送进微信”看起来是一句话实际有四种完全不同的实现路径。我评估过 Server酱、WxPusher、微信测试号模板消息、企业微信群机器人这四个方案最后选了企业微信群机器人。为什么看下表就清楚了方案接收方式是否免费Markdown 支持维护难度企业微信群机器人微信内群聊免费部分支持最低Server酱个人微信服务号免费额度支持低WxPusher个人微信服务号免费额度支持低微信测试号模板消息微信内模板消息免费不支持高企业微信群机器人最吸引我的一点是它可以开一个只有自己的群把群当作私人通知中心兼历史存档。所有日报都在同一个群里想回溯哪天内容直接翻聊天记录就行。Server酱和 WxPusher 虽然也能推到个人微信但毕竟经过第三方服务中转多一层依赖就多一个故障点。微信测试号模板消息的格式限制太多只适合发简单通知不适合承载日报这种结构化内容。2.3 AI 日报数据源的取舍数据源是整个日报的地基源选不好后面模型再强也白搭。我第一版贪心一口气配了七八个源结果一半是低质量自媒体每天生成的日报充斥着标题党。后来砍到三个稳定源质量反而上来了。我的取舍标准是三条内容质量稳定、更新频率可靠、抓取成本低。RSS 是最适合的载体因为它的结构统一、没有复杂的反爬逻辑解析成本极低。一些网站提供官方 API比如 GitHub Trending 和 Hacker News API这些可以直接用来抓开源和海外开发者动态。微信公众号的内容质量高但抓取难度大而且涉及各种限制第一版完全没必要碰。热榜类接口也先不加很多需要维护 Cookie 和签名稳定性堪忧。建议读者起步阶段选 3 到 4 个源就够先跑一周看看效果再根据日报的实际质量做加减法。源不在多能持续产出可靠信息才重要。2.4 定时触发方案的说明定时这块WorkBuddy 的调度器直接支持 Cron 表达式我配置的是0 30 10 * * ?表示每天上午十点半运行。这里有一点值得提醒尽量不要用整点。整点往往是服务器上各种定时任务的集中执行时间无论是 WorkBuddy 所在的机器还是资讯源的更新频率都可能出现资源竞争。用10:30这类带偏差的时间能避开不少偶发问题。另一个容易踩的坑是时区。如果 WorkBuddy 运行环境默认是 UTC配置完十点半不校验时区真实执行时间就会变成北京时间下午六点半。所以配置定时任务时一定要显式确认时区设置我这边直接锁死成Asia/Shanghai。3. 环境准备把地基打好再写技能3.1 WorkBuddy 安装与工作台配置安装部分没什么特别的从官网下载对应你系统的安装包Windows、macOS、Linux 都有对应版本装完登录账号就能进工作台。需要注意的一点不同版本之间的菜单位置可能有差异但核心逻辑是一样的——工作台、Skill 配置、任务调度、运行日志这几个模块是跑自动化流程必不可少的部分。我建议新装完先别急着做自定义任务花十分钟把 WorkBuddy 自带的示例 Skill 跑一遍。这样做不是为了看演示而是为了确认三件事大模型服务是不是正常的、工作台能不能正常执行任务、日志输出在哪个位置。确认这三个基础点之后再做自定义配置会顺畅得多至少不会把“模型没配置好”误判成“我的 Skill 写错了”。3.2 拿到企业微信群机器人的 Webhook 地址微信推送给日报需要先有一个接收消息的“信箱”这个信箱就是企业微信群的群机器人。操作路径很简单在微信里新建一个群可以只拉自己一个人也可以拉一个常用的同事群然后在群设置里找到“群机器人”添加一个机器人系统会生成一个 Webhook 地址形如https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx把它复制下来备用。这里有个安全提醒keyxxx这部分等于是这个群的专属身份凭证任何人拿到它都能往你群里推消息。千万不要把它提交到公开的代码仓库或配置文件里我的做法是保存在本地配置中设置好权限。如果哪天发现群里出现不明消息第一时间到群机器人设置里重置这个 key。3.3 配置数据源RSS 与 API 的整合数据源配置文件我建议单独维护不要和 Skill 的逻辑混在一起。这样换源、加源都只是改配置不用动流程。我用的源清单是 YAML 格式大致长这样sources: - name: hacker_news type: rss url: https://news.ycombinator.com/rss max_items: 20 - name: github_trending type: api url: https://github.com/trending max_items: 10 - name: tech_weekly type: rss url: https://example.com/feed.xml max_items: 15每个源除了名称、类型、URL还配了max_items字段限制每个源最多取多少条原始内容。这个字段很重要如果不限制大模型处理的内容量会忽高忽低日报的长度也很难控制。我额外加了一个兜底机制如果某个源连续三次抓取失败就自动把它从本次结果里剔除并在日志里标注防止一个源出问题拖垮整条日报。3.4 验证推送链路通不通配置完数据源先别急着写 Skill。花一分钟验证 Webhook 通不通这个步骤能省掉后面大量的排查时间。在 WorkBuddy 的 HTTP 执行器里或者直接在终端里用 curl 模拟一条消息curl https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d {msgtype:markdown,markdown:{content:**链路测试**WorkBuddy 日报通道正常}}如果返回{errcode:0,errmsg:ok}说明推送链路完全正常。如果返回错误码先别慌把错误信息打出来看大多数时候是 URL 拼接错了或者 JSON 格式不对。这一步做完后面 Skill 跑起来只要专注内容逻辑不用再怀疑通道是否可靠。4. 核心实现用 Skill 定义“日报生成器”4.1 给 WorkBuddy 定几条长期规则这是整个项目里我认为最值得花心思的一步。WorkBuddy 支持定义全局规则一旦设定后续所有任务都会自动继承不用在每次调用时重复输入。我给日报定的规则主要有五条所有日报必须使用简体中文每条新闻摘要不超过 100 字只保留有明确信息增量的内容只保留能提供可点击原始来源的消息无法追溯的不收录拒绝广告、标题党、纯科普无干货的内容如果当天有效信息不足 3 条直接说明“今日无重大更新”不要硬凑。这些规则看起来简单但实际效果立竿见影。在设规则之前模型隔三差五会塞进来一些“震惊体”内容设完之后输出稳定了很多。更重要的是这些规则后续可以被周报、竞品监控等其他任务重复使用属于典型的“一次配置、长期受益”。4.2 创建日报 Skill从抓取到推送的完整流程有了规则接下来就是创建日报 Skill。我给这个 Skill 起名daily_ai_report它的输入是当天的日期输出是一份待推送的 Markdown 文本。整个流程分成四步抓取源、去重过滤、大模型总结、渲染并推送。配置结构大致如下name: daily_ai_report schedule: 0 30 10 * * ? timezone: Asia/Shanghai default_timeout: 120s sources_file: ./config/sources.yaml steps: - fetch_sources - dedupe_and_filter - summarize_with_llm - render_and_push这里我特意把四个步骤拆开而不是写成一个“一句话让模型干完”的 Prompt。原因在于可调试性如果推送出去的日报内容不对我可以单独运行fetch_sources看看原始抓取是否正常再单独运行summarize_with_llm看总结质量。每步独立运行日志里能看到每步消耗的时间和输出条数问题一下子就能定位。4.3 配置定时任务从每分钟到每天十点半Skill 创建好之后进入 WorkBuddy 的任务调度页面新建一个定时任务绑定daily_ai_report调度表达式填0 30 10 * * ?时区选Asia/Shanghai保存即可。但我强烈建议第一次调试时不要直接设成十点半。正确流程是先把它改成每分钟执行一次手动触发验证内容没问题之后再改成每天执行。我第一版就是直接设好十点半结果等第二天看到日报已经坏了白白浪费了一个调试周期。改成每分钟跑一次之后任何改动最多一分钟就能看到结果调试速度提升了不止一个量级。确认没问题后把调度改回0 30 10 * * ?再观察两天。稳定之后就可以彻底不管了。4.4 用一条测试指令跑通全流程定时任务配置完之后先别急着等第二天。直接在 WorkBuddy 里手动触发一次daily_ai_report把日期参数传成当天然后盯着任务日志看每一步的输出。手动触发时重点检查三件事第一日报内容是否为空如果为空多半是数据源抓取出问题第二链接是否可点击如果模型生成的链接格式不对点开会报错第三Markdown 渲染是否正常尤其要注意企业微信对 Markdown 的兼容性限制。这三项都通过了再让定时任务自动跑。这个“先手动后定时”的原则做自动化的人应该都深有体会能少踩无数坑。5. 上线后我踩过的坑实测排错记录5.1 Webhook 推送失败错误码解读第一个坑来得很快。手动触发时 Webhook 返回了一个非零错误码日报没有推出去。我把常见错误码整理成了下表方便对照返回码含义处理方式0成功无需处理400参数错误或消息超长压缩正文到 1MB 以内实际建议控制在 4096 字节内44004content 为空检查渲染步骤输出是否有内容45009频率超限等待 60 秒后重试调试时不要高频推送93000key 无效检查 Webhook URL 拼接是否正确我那次遇到的是 400原因就是日报正文太长。企业微信群机器人的消息体对长度有限制而大模型生成的 Markdown 带着各种符号字节数很容易膨胀。解决办法很简单在渲染环节加一个字符长度控制超过 4096 字节就自动截断并保留完整版在日志里供查看。5.2 Markdown 兼容性表格和代码块不要用第二个坑是格式问题。我第一版日报模板里用了表格结果推送到微信后显示成一堆乱糟糟的纯文本完全没法看。查了之后才发现企业微信群机器人的 Markdown 只支持一个子集标题、加粗、链接、无序列表、引用这些基础语法没问题但表格、复杂代码块、图片这类高级语法要么被忽略要么直接展示成原始字符。解决方案很朴素模板全部改用加粗加无序列表链接用标准 Markdown 格式。改完之后再推送渲染就稳定了。这条经验也适合所有群机器人推送场景——宁可模板简单一点也别挑战兼容性边界。5.3 定时任务没触发时区与进程问题有一天我等到十一点也没收到日报去翻任务历史发现定时任务压根没跑。排查下来有三个可能最终锁定在 WorkBuddy 所在机器的时区设置上系统时区是 UTC我配置的Asia/Shanghai没生效十点半实际被当成了某个 UTC 时间执行结果自然是错乱的。这类问题比较隐蔽因为配置界面显示的是北京时间但底层调度可能读的是系统时区。解决的套路是先看任务执行历史里最近一次成功时间如果时间明显不对先调整系统时区再测试如果历史为空说明任务根本没被调度起来检查是否被暂停或者调度表达式写错。另外注意WorkBuddy 本身需要保持运行状态如果设备关机或者进程退出定时任务自然也不会触发。这个属于使用习惯问题没有代码能解决。5.4 日报空转数据源超时和去重误杀跑了一周后又出现一个怪现象某天日报只推了一条消息内容还是“今日无重大更新”。我去查日志发现其实是数据源出问题了——一个 RSS 源抓取超时另一个源返回了空列表去重逻辑又把昨天已经收录过的条目全过滤掉了最后留给模型的有效输入几乎为零。这个问题暴露了初始设计的一个缺陷我太依赖单一数据源的可靠性。改进方案是双管齐下。第一给每个抓取步骤加上超时和重试机制连续三次失败才算真正的失败第二设置日报“最小条数兜底”如果有效信息少于 3 条就从最近一周的未重复条目里补充而不是直接宣告“无更新”。这样即使某个源临时抽风日报也能保持基本内容不会出现白板。5.5 排错的核心方法论踩了这几个坑之后我总结出一套排错顺序基本能覆盖大多数自动化任务的问题先看日志。WorkBuddy 的执行历史里记录了每次任务的成功失败状态这是第一个信息源。再看中间输出。手动单独跑一遍“抓取”“总结”“推送”三个步骤用二分法定位问题到底出在哪段。比如推送失败直接用 curl 测 Webhook内容差让 Skill 先输出原始抓取结果看看是不是源本身就脏。最后是迭代验证。改完配置后不要干等定时手动触发一次确认没问题再放回定时。这套方法看起来普通但确实比瞎猜高效得多。自动化任务最怕的不是错误多而是定位错误的路径太长。6. 从日报到自动化工作台后续还能怎么扩展6.1 把同一套流程迁移到行业监控日报跑通之后我很快就发现这套流程的价值不止于 AI 资讯。把数据源换成财经 RSS、把过滤规则改成“只保留企业服务相关内容”一个竞品监控器就出来了。再改一下 Prompt要求模型重点提炼与指定公司相关的动态日报就变成了情报雷达。这个迁移成本之所以低是因为整个 Skill 的结构没有变变的只有配置和规则。WorkBuddy 的全局规则在这里起了作用我之前定的“只保留有明确信息增量、提供可点击来源”的规则在竞品监控里同样适用。对多数人来说建一个自己的自动化信息枢纽比写一个通用爬虫系统要有价值得多。6.2 多端推送把日报同时发到钉钉、飞书和邮件单一通道推送有个风险万一微信临时出问题日报就送不到了。为此我把推送环节做成了“适配器”模式——日报内容只生成一次然后通过不同渠道推送到多个目标。企业微信群机器人、钉钉群机器人、飞书群机器人的 Webhook 结构大同小异核心都是 POST 一段特定格式的 JSON只是字段名略有区别。改造之后每份日报会同时推送到微信和预留的备用通道概率上大大降低了“推送失败导致当天断更”的风险。如果你有团队还可以把日报自动推到团队群里让整个团队共享早间情报。这个扩展本身工作量不大但价值非常直观。6.3 与周报、月度报告联动日报内容每天都会产生一份已经排版好的 Markdown我让 WorkBuddy 把它自动存档到一个本地目录。每周五再运行一个周报 Skill读取这一周的日报文件交给模型合并提炼生成一份“本周 AI 圈动态周报”同样推到微信群里。这一步能实现的前提是我在一开始就定好了全局规则。周报 Skill 不需要重新写一套总结标准模型会自动继承“只保留有信息增量”的原则输出风格和日报一脉相承。如果你有月报、季度回顾之类的需求原理完全一样——把日报当作原料库让模型做二次加工。6.4 如果不想用 WorkBuddy还有什么替代方案最后说一下替代方案。如果不想引入 WorkBuddy 这类工作台最朴素的方式是 GitHub Actions 加 Python 脚本加 Webhook 推送。Python 脚本负责抓取和生成日报GitHub Actions 负责每天定时触发推送还是走企业微信群机器人 Webhook。这个方案的好处是无需本地常驻进程代码完全可控缺点是大模型调用的鉴权、超时重试这些工程细节都需要自己写而且改需求时得动代码不像 WorkBuddy 改规则那么快。两个方案没有绝对优劣。我选 WorkBuddy主要是因为它让“修改日报规则”变成了一次对话级别的操作而不是一次代码变更。如果你更喜欢折腾代码或者希望流程完全依赖云端运行GitHub Actions 也是值得一试的路线。核心逻辑是通用的采集、生成、推送三段式永远不会变。整套流程从能跑到稳定我花了大约两天时间。最大的体会不是技术难点而是规则要定得足够细。第一次跑出来的日报像一篇什么都要提一下的综述看完等于没看后来把规则改成“只保留有明确信息增量、能点开原文核实”之后质量才真正上来。所以如果你想复制这套东西我的建议是先别急着追求全自动化先手动跑十天把你的阅读偏好沉淀成几条清晰的规则再交给定时任务。规则越像你自己日报就越像你想看的样子。
