WorkBuddy+微信：搭建AI日报自动推送工作流

1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事是打开各种信息源行业动态、竞品更新、技术社区热帖、内部项目进展。这件事听起来简单但真正做过的人都知道光是“把信息收拢到一处”就能吃掉半小时。更麻烦的是信息散落在不同平台格式五花八门看完一圈脑子还是乱的。我试过用 RSS 订阅、用收藏夹、用笔记软件剪藏最后都因为“手动整理”这个环节太重而放弃。后来我把这件事拆开看我需要的其实不是“更多信息”而是一份每天早上固定时间送到眼前、已经经过筛选和摘要的简报。这个需求用 WorkBuddy 配合微信就能解决。WorkBuddy 负责在后台跑任务、调模型、做摘要微信负责把结果推到我手机上。整个过程不需要我打开任何网页也不需要我手动复制粘贴。这篇文章要聊的就是这套“AI 日报自动送进微信”的完整搭建思路。我会从整体设计、核心细节、实操步骤、常见问题四个层面展开把我在搭建过程中踩过的坑和验证过的参数都写清楚。适合已经用过 WorkBuddy 基础功能、想进一步做自动化推送的读者也适合对 AI Agent 工作流感兴趣但还没动手的人。读完你至少能拿到一套可复现的方案改改参数就能跑自己的日报。2. 整体设计为什么是 WorkBuddy 微信 定时触发2.1 核心需求拆解我要的到底是什么先把需求写清楚不然后面选型容易跑偏。我的核心诉求有四条定时每天上午十点半准时触发不需要我手动点任何按钮。自动采集从指定的信息源抓取内容不需要我逐个打开。AI 摘要把抓到的原始内容压缩成可读的简报而不是原文堆砌。微信送达结果直接出现在微信里最好是一个文件或一条消息点开就能看。这四条里最容易被低估的是“微信送达”。很多人做自动化推送时习惯用邮件或飞书但我的实际使用场景是手机不离手、微信常驻后台所以微信的触达率最高。WorkBuddy 本身有任务调度和模型调用能力微信这边可以通过企业微信机器人或者服务号模板消息来接收。我最终选的是企业微信机器人 Webhook原因是配置简单、不需要额外申请服务号、消息格式支持 Markdown。2.2 方案选型为什么不用纯脚本或纯模型 API有人可能会问为什么不直接写个 Python 脚本用 requests 抓页面再调模型 API 做摘要最后发到微信这个方案技术上完全可行但我实际对比下来WorkBuddy 的优势在于任务编排和状态管理。纯脚本的问题在于一旦某个环节失败比如某个页面结构变了、模型接口超时整个流程就断了而且没有重试机制。WorkBuddy 可以把采集、摘要、推送拆成独立步骤每一步都有执行记录失败可以单独重跑。另外WorkBuddy 的 Skill 机制让我可以把“抓取某个源”封装成一个可复用的模块后面加新信息源时只需要加一个 Skill不用改主流程。至于模型选择我试过几个不同的模型接口。摘要任务对模型的要求是稳定、便宜、支持长文本不需要太强的推理能力。DeepSeek 在这几个维度上表现比较均衡中文摘要质量也够用。如果你的日报涉及英文内容可以在 Skill 里加一个翻译步骤或者直接选一个中英兼顾的模型。2.3 整体架构三个模块串成一条线整套流程可以拆成三个模块采集模块负责从指定来源获取原始内容。来源可以是 RSS、网页、API甚至是本地文件。我目前主要用 RSS 和几个固定的技术社区页面。处理模块负责清洗、去重、摘要。清洗包括去掉 HTML 标签、广告内容去重是按标题或 URL 做简单哈希摘要用模型生成。推送模块负责把最终结果格式化后发到微信。我用的企业微信机器人支持 Markdown所以摘要可以直接用标题加列表的格式。这三个模块在 WorkBuddy 里对应三个 Skill通过一个主任务串起来。主任务设置定时触发每天十点半执行一次。执行顺序是采集 → 处理 → 推送。每个 Skill 的输出作为下一个 Skill 的输入。提示不要把三个模块写在一个 Skill 里。分开写的好处是调试方便比如采集失败时你可以单独重跑采集不用把整个流程走一遍。3. 核心细节采集、摘要、推送各自的关键点3.1 采集模块信息源怎么选、怎么抓信息源的选择直接决定日报的质量。我的原则是少而精一开始不要贪多。我目前只保留了五个源两个行业资讯站、一个技术社区热榜、一个内部项目更新页、一个竞品动态页。每个源每天新增内容大概三到五条五个源加起来十五到二十五条经过摘要后正好是一份五分钟能读完的简报。抓取方式上RSS 是最省事的直接用 WorkBuddy 的 RSS Skill 就能搞定。没有 RSS 的页面我用两种方式一种是页面结构稳定的直接按 CSS 选择器抓另一种是结构经常变的用 Playwright 做浏览器渲染后抓取。Playwright 的好处是能处理 JavaScript 渲染的页面缺点是速度慢一些所以只用在必要的地方。这里有一个细节抓取频率不要太高。我一开始设置成每小时抓一次结果发现很多源一天只更新一两次频繁抓取既浪费资源又容易触发反爬。后来改成每天十点抓一次正好在日报生成前半小时数据新鲜度够用。3.2 摘要模块Prompt 怎么写才稳定摘要质量取决于 Prompt。我试过几种写法最后稳定下来的结构是你是一个信息简报助手。请把以下内容压缩成不超过 200 字的摘要保留关键事实和数据去掉广告和重复内容。输出格式为一句话标题 三到五条要点。如果内容与 AI、自动化、效率工具无关请直接忽略。这个 Prompt 里有几个关键点字数限制不限制字数模型容易写太长。200 字是我实测下来既能说清楚又不啰嗦的长度。输出格式指定“标题 要点”的格式方便后面直接拼成 Markdown。过滤条件明确告诉模型忽略无关内容减少噪音。另外我建议在摘要前加一步去重。同一个事件可能被多个源报道如果不去重摘要里会出现重复信息。去重逻辑很简单按标题的前 20 个字符做哈希重复的只保留最早出现的那条。3.3 推送模块企业微信机器人的配置要点企业微信机器人的配置步骤不复杂但有几个坑要注意Webhook 地址在群聊里添加机器人后会得到一个 Webhook URL。这个 URL 里包含一个 key不要泄露。消息格式支持 text、markdown、image 等。我用的是 markdown因为可以加标题和列表。频率限制每个机器人每分钟最多发 20 条消息。日报一天只发一条完全够用。内容长度markdown 消息最长 4096 字节。如果摘要内容太长需要截断或分条发送。我实际用的推送格式是这样的## AI 日报 2025-01-15 **今日要点** - 要点一 - 要点二 - 要点三 **详细内容** [链接](url)这样在微信里点开就能看到清晰的标题和列表不需要再跳转。4. 实操过程从零搭建的完整步骤4.1 环境准备与 WorkBuddy 基础配置假设你已经有一个 WorkBuddy 账号并且能正常登录。第一步是创建一个新的工作区专门用来跑日报任务。工作区的好处是任务隔离不会和其他项目混在一起。然后安装必要的 Skill。我用到的是RSS 读取 SkillHTTP 请求 Skill用于抓取非 RSS 页面Playwright Skill用于动态页面模型调用 Skill用于摘要企业微信推送 Skill这些 Skill 在 WorkBuddy 的 Skill 市场里都能找到安装后需要配置各自的参数。比如 RSS Skill 需要填 RSS 地址模型 Skill 需要填 API Key 和模型名称。注意API Key 不要直接写在 Skill 配置里用 WorkBuddy 的环境变量功能存起来。这样即使 Skill 配置被导出Key 也不会泄露。4.2 采集 Skill 的编写与调试以 RSS 采集为例Skill 的逻辑是读取 RSS 地址列表。对每个地址发起请求解析 XML。提取标题、链接、发布时间、内容摘要。过滤掉 24 小时前的内容。输出去重后的条目列表。调试时建议先用一个源测试确认能正常拿到数据后再加其他源。我一开始一次性配了十个源结果其中一个源的 XML 格式有问题导致整个采集步骤失败。后来改成逐个添加每加一个就手动跑一次问题就好定位了。对于非 RSS 页面我用 HTTP 请求 Skill 加 CSS 选择器的方式。选择器的写法取决于页面结构可以用浏览器开发者工具查看。如果页面是 JavaScript 渲染的就换成 Playwright Skill等页面加载完成后再抓取。4.3 摘要 Skill 的参数调优摘要 Skill 的核心是 Prompt 和模型参数。我用的参数是参数值说明temperature0.3低温度让输出更稳定max_tokens500足够生成 200 字摘要top_p0.9默认值即可temperature 设成 0.3 是因为摘要任务不需要创造性稳定比多样更重要。我试过 0.7结果同一批内容每次生成的摘要措辞都不一样虽然意思差不多但看起来不够专业。另外我建议在摘要前加一个内容清洗步骤。很多网页抓下来的内容里混着导航栏、广告、评论区直接丢给模型会浪费 token 还影响摘要质量。清洗逻辑可以用正则去掉 HTML 标签再按段落长度过滤掉太短的段落。4.4 推送 Skill 与企业微信机器人对接企业微信机器人的创建步骤在企业微信里建一个群至少三个人可以拉两个同事或者用两个自己的账号。群设置里找到“群机器人”添加一个机器人。复制 Webhook 地址。在 WorkBuddy 的推送 Skill 里填入 Webhook 地址。推送 Skill 的逻辑是接收摘要模块的输出。按 Markdown 格式拼接消息。发送 POST 请求到 Webhook 地址。检查返回状态码非 200 则记录错误。这里有一个细节企业微信机器人对消息内容有长度限制如果摘要超过 4096 字节需要截断。我的做法是如果超过限制就只发标题和要点详细内容放到一个内部页面上消息里只放链接。4.5 定时触发与任务串联最后一步是把三个 Skill 串起来设置定时触发。WorkBuddy 的定时任务支持 Cron 表达式我设置的是30 10 * * *意思是每天十点三十分执行。执行顺序是采集 → 摘要 → 推送。每个步骤的输出会传给下一个步骤。提示定时任务的时间要留出足够的执行时间。如果采集步骤需要五分钟摘要需要两分钟推送需要十秒那么整个任务大概需要七到八分钟。十点半触发十点四十之前能收到日报。5. 常见问题与排查技巧实录5.1 采集失败页面结构变了怎么办这是最常见的问题。网页改版后原来的 CSS 选择器可能就失效了。我的排查步骤是手动打开目标页面确认页面能正常访问。用浏览器开发者工具检查目标元素的选择器是否还匹配。如果不匹配更新选择器。如果页面变成 JavaScript 渲染改用 Playwright Skill。为了减少这类问题我建议优先用 RSS。RSS 的格式相对稳定即使页面改版RSS 通常还会保留。如果某个源没有 RSS再考虑页面抓取。5.2 摘要质量差模型输出太泛或太长摘要质量差通常有两个原因Prompt 不够具体或者输入内容太杂。我的解决方法是在 Prompt 里明确字数限制和输出格式。在摘要前加清洗步骤去掉无关内容。如果某个源的内容质量一直很差直接把它从源列表里去掉。另外模型选择也有影响。我试过用一个小模型做摘要结果经常漏掉关键信息。换成 DeepSeek 后摘要质量明显提升。如果你的预算允许建议用中等规模以上的模型。5.3 推送失败Webhook 返回错误码企业微信机器人推送失败时返回的错误码能帮你定位问题。常见错误码错误码含义解决方法93000无效的 Webhook 地址检查 URL 是否完整45009接口调用超过限制降低推送频率40001无效的 access_token重新获取 token40058参数错误检查消息格式我遇到最多的是 45009原因是测试时频繁发送消息。正式使用时一天只发一条不会触发限制。5.4 定时任务没执行检查时区和日志定时任务没执行先检查两个地方时区和日志。WorkBuddy 的定时任务默认用 UTC 时间如果你设置的是北京时间十点半需要换算成 UTC 时间也就是凌晨两点半。我一开始没注意这个设置成十点半结果凌晨就跑了。日志里会记录每次任务的执行状态。如果任务显示“已触发但未完成”说明某个步骤卡住了。可以单独重跑那个步骤看具体报错信息。5.5 内容重复去重逻辑要放在摘要前内容重复的问题我在第三部分提过这里再强调一下去重一定要放在摘要前。如果先摘要再去重模型会对重复内容生成不同的摘要去重就失效了。去重逻辑按标题或 URL 做哈希简单有效。6. 我踩过的坑和最后分享的几个技巧第一个坑是信息源贪多。我一开始加了十几个源结果每天摘要出来几十条根本读不完。后来砍到五个源日报长度控制在五分钟能读完使用率反而高了。信息源的质量比数量重要得多。第二个坑是Prompt 写得太复杂。我试过在 Prompt 里加很多条件比如“如果内容涉及融资就重点写金额如果涉及产品发布就重点写功能”。结果模型经常搞混输出格式不稳定。后来简化成“标题 要点”的固定格式稳定性大幅提升。第三个坑是忽略时区。这个前面说过了设置定时任务时一定要确认时区。最后分享一个小技巧在推送消息里加一个“反馈”入口。我一开始只是单向推送后来在消息末尾加了一句“回复 1 表示有用回复 2 表示需要调整”。虽然企业微信机器人不支持直接回复但我可以手动在群里反馈。这样跑了一周后我根据反馈调整了信息源和摘要长度日报的实用性明显提升。另外如果你想让日报内容更丰富可以在摘要后加一个“延伸阅读”板块把原文链接附上。这样感兴趣的内容可以点进去看全文不感兴趣的跳过就行。这个板块不需要模型生成直接从采集结果里取链接就行。整套方案跑下来我每天花在信息收集上的时间从半小时降到了五分钟而且因为摘要是结构化的读起来比原来刷信息流轻松很多。如果你也在做类似的事情建议先从一两个源开始跑通流程后再逐步扩展。