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 整体架构：三个模块串成一条线

整套流程可以拆成三个模块：

1. 采集模块：负责从指定来源获取原始内容。来源可以是 RSS、网页、API，甚至是本地文件。我目前主要用 RSS 和几个固定的技术社区页面。
2. 处理模块：负责清洗、去重、摘要。清洗包括去掉 HTML 标签、广告内容；去重是按标题或 URL 做简单哈希；摘要用模型生成。
3. 推送模块：负责把最终结果格式化后发到微信。我用的企业微信机器人支持 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 读取 Skill
• HTTP 请求 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 的逻辑是：

1. 读取 RSS 地址列表。
2. 对每个地址发起请求，解析 XML。
3. 提取标题、链接、发布时间、内容摘要。
4. 过滤掉 24 小时前的内容。
5. 输出去重后的条目列表。

调试时建议先用一个源测试，确认能正常拿到数据后再加其他源。我一开始一次性配了十个源，结果其中一个源的 XML 格式有问题，导致整个采集步骤失败。后来改成逐个添加，每加一个就手动跑一次，问题就好定位了。

对于非 RSS 页面，我用 HTTP 请求 Skill 加 CSS 选择器的方式。选择器的写法取决于页面结构，可以用浏览器开发者工具查看。如果页面是 JavaScript 渲染的，就换成 Playwright Skill，等页面加载完成后再抓取。

4.3 摘要 Skill 的参数调优

摘要 Skill 的核心是 Prompt 和模型参数。我用的参数是：

参数	值	说明
temperature	0.3	低温度让输出更稳定
max_tokens	500	足够生成 200 字摘要
top_p	0.9	默认值即可

temperature 设成 0.3 是因为摘要任务不需要创造性，稳定比多样更重要。我试过 0.7，结果同一批内容每次生成的摘要措辞都不一样，虽然意思差不多，但看起来不够专业。

另外，我建议在摘要前加一个内容清洗步骤。很多网页抓下来的内容里混着导航栏、广告、评论区，直接丢给模型会浪费 token 还影响摘要质量。清洗逻辑可以用正则去掉 HTML 标签，再按段落长度过滤掉太短的段落。

4.4 推送 Skill 与企业微信机器人对接

企业微信机器人的创建步骤：

1. 在企业微信里建一个群，至少三个人（可以拉两个同事，或者用两个自己的账号）。
2. 群设置里找到“群机器人”，添加一个机器人。
3. 复制 Webhook 地址。
4. 在 WorkBuddy 的推送 Skill 里填入 Webhook 地址。

推送 Skill 的逻辑是：

1. 接收摘要模块的输出。
2. 按 Markdown 格式拼接消息。
3. 发送 POST 请求到 Webhook 地址。
4. 检查返回状态码，非 200 则记录错误。

这里有一个细节：企业微信机器人对消息内容有长度限制，如果摘要超过 4096 字节，需要截断。我的做法是如果超过限制，就只发标题和要点，详细内容放到一个内部页面上，消息里只放链接。

4.5 定时触发与任务串联

最后一步是把三个 Skill 串起来，设置定时触发。WorkBuddy 的定时任务支持 Cron 表达式，我设置的是：

30 10 * * *

意思是每天十点三十分执行。执行顺序是采集 → 摘要 → 推送。每个步骤的输出会传给下一个步骤。

提示：定时任务的时间要留出足够的执行时间。如果采集步骤需要五分钟，摘要需要两分钟，推送需要十秒，那么整个任务大概需要七到八分钟。十点半触发，十点四十之前能收到日报。

5. 常见问题与排查技巧实录

5.1 采集失败：页面结构变了怎么办

这是最常见的问题。网页改版后，原来的 CSS 选择器可能就失效了。我的排查步骤是：

1. 手动打开目标页面，确认页面能正常访问。
2. 用浏览器开发者工具检查目标元素的选择器是否还匹配。
3. 如果不匹配，更新选择器。
4. 如果页面变成 JavaScript 渲染，改用 Playwright Skill。

为了减少这类问题，我建议优先用 RSS。RSS 的格式相对稳定，即使页面改版，RSS 通常还会保留。如果某个源没有 RSS，再考虑页面抓取。

5.2 摘要质量差：模型输出太泛或太长

摘要质量差通常有两个原因：Prompt 不够具体，或者输入内容太杂。我的解决方法是：

• 在 Prompt 里明确字数限制和输出格式。
• 在摘要前加清洗步骤，去掉无关内容。
• 如果某个源的内容质量一直很差，直接把它从源列表里去掉。

另外，模型选择也有影响。我试过用一个小模型做摘要，结果经常漏掉关键信息。换成 DeepSeek 后，摘要质量明显提升。如果你的预算允许，建议用中等规模以上的模型。

5.3 推送失败：Webhook 返回错误码

企业微信机器人推送失败时，返回的错误码能帮你定位问题。常见错误码：

错误码	含义	解决方法
93000	无效的 Webhook 地址	检查 URL 是否完整
45009	接口调用超过限制	降低推送频率
40001	无效的 access_token	重新获取 token
40058	参数错误	检查消息格式

我遇到最多的是 45009，原因是测试时频繁发送消息。正式使用时一天只发一条，不会触发限制。

5.4 定时任务没执行：检查时区和日志

定时任务没执行，先检查两个地方：时区和日志。WorkBuddy 的定时任务默认用 UTC 时间，如果你设置的是北京时间十点半，需要换算成 UTC 时间，也就是凌晨两点半。我一开始没注意这个，设置成十点半结果凌晨就跑了。

日志里会记录每次任务的执行状态。如果任务显示“已触发但未完成”，说明某个步骤卡住了。可以单独重跑那个步骤，看具体报错信息。

5.5 内容重复：去重逻辑要放在摘要前

内容重复的问题我在第三部分提过，这里再强调一下：去重一定要放在摘要前。如果先摘要再去重，模型会对重复内容生成不同的摘要，去重就失效了。去重逻辑按标题或 URL 做哈希，简单有效。

6. 我踩过的坑和最后分享的几个技巧

第一个坑是信息源贪多。我一开始加了十几个源，结果每天摘要出来几十条，根本读不完。后来砍到五个源，日报长度控制在五分钟能读完，使用率反而高了。信息源的质量比数量重要得多。

第二个坑是Prompt 写得太复杂。我试过在 Prompt 里加很多条件，比如“如果内容涉及融资就重点写金额，如果涉及产品发布就重点写功能”。结果模型经常搞混，输出格式不稳定。后来简化成“标题 + 要点”的固定格式，稳定性大幅提升。

第三个坑是忽略时区。这个前面说过了，设置定时任务时一定要确认时区。

最后分享一个小技巧：在推送消息里加一个“反馈”入口。我一开始只是单向推送，后来在消息末尾加了一句“回复 1 表示有用，回复 2 表示需要调整”。虽然企业微信机器人不支持直接回复，但我可以手动在群里反馈。这样跑了一周后，我根据反馈调整了信息源和摘要长度，日报的实用性明显提升。

另外，如果你想让日报内容更丰富，可以在摘要后加一个“延伸阅读”板块，把原文链接附上。这样感兴趣的内容可以点进去看全文，不感兴趣的跳过就行。这个板块不需要模型生成，直接从采集结果里取链接就行。

整套方案跑下来，我每天花在信息收集上的时间从半小时降到了五分钟，而且因为摘要是结构化的，读起来比原来刷信息流轻松很多。如果你也在做类似的事情，建议先从一两个源开始，跑通流程后再逐步扩展。