每天上午十点半微信准时收到一份整理好的 AI 日报，这个习惯我已经保持了快两个月。最早是手动操作：刷 RSS、翻公众号、逛 GitHub，再复制粘贴到团队群，一套流程下来至少四十分钟。后来我直接给 WorkBuddy 配了个"闹钟"——定时任务每天十点半自动聚合当天 AI 圈的动态，调用模型生成结构化日报，再通过 Webhook 推送到微信。整个过程不用我碰一下客户端，关键在于把"定时触发、内容生成、消息推送"这三件事彻底解耦，这也是我觉得 WorkBuddy 这类 AI Agent 工作台最值得玩的地方。
如果你也在做 AI 产品、运营或者技术研究，每天需要盯大量信息源，这篇文章就是给你写的。我会把整个方案从需求拆解到实操配置一步步讲清楚，包含提醒词设计、定时触发器设置、微信推送通道选型，以及我踩过的坑。全程不涉及自己写服务器脚本，只要能打开浏览器、会复制粘贴就能复现。
1. 先把需求拆清楚：这个"闹钟"到底在做什么
1.1 这个"闹钟"由三个模块组成
很多人一想到"定时推送 AI 日报"，第一反应是写个 Python 脚本跑在服务器上，再挂 cron。这个思路本身没错，但对个人用户来说太重了：你要维护环境、处理依赖、还要管服务器不宕机。我在动手之前先做了需求拆解，发现整件事本质上是三个独立模块的串联：
- 定时触发：每天上午 10:30 产生一个"该干活了"的信号；
- 内容生成：基于信息源聚合当天 AI 动态，让大模型整理成结构化日报；
- 消息送达：把最终文本推送到微信，让手机弹出通知。
这三个模块单独看都不难，难的是把它们稳定、低门槛地串起来。WorkBuddy 的价值恰恰在这里：它自带调度能力和工具调用能力，把触发、生成、推送全部放进一个可视化的流程里，我只需要告诉它"做什么"和"按什么格式输出"，剩下的执行环节全部由平台接管。
1.2 为什么我选 WorkBuddy 而不是自己硬编码
先说结论：如果你的需求是"每天固定时间把一份内容推到聊天软件"，用 WorkBuddy 搭建自动化流程比自建服务省太多事。我对比过三条路线，列出来你就明白差距在哪。
- 自建 Python + Cron：灵活度最高，但你要处理 Python 环境、依赖库、日志轮转、服务器重启后任务恢复。为了一条日报付出运维成本，不划算。
- 云函数 + 定时触发器：免运维，但调试体验割裂，每次改完代码要重新部署，而且联动微信 Webhook 时你得自己写请求逻辑。
- WorkBuddy 自动化流程：把触发条件、模型调用、HTTP 请求封装成一个可视化流程，修改提醒词和推送地址都是改配置，不需要碰代码。
我自己属于"能少写一行代码就少写一行"的人。WorkBuddy 这类工具相当于把高频、重复的 AI 任务固化成了模板，我的精力可以放在日报的内容质量上，而不是底层的调度稳定性。
1.3 数据在后台是怎么流动的
为了后面调试方便，理解数据流比记步骤更重要。整个流程在后台是这样跑的：
- 到达 10:30，WorkBuddy 的定时触发器被唤醒；
- 触发器携带当天的日期作为上下文参数，交给日报 Skill；
- 日报 Skill 依次做三件事：抓取订阅源最新资讯、调用大模型生成结构化日报、把结果传给下一步；
- 数据被格式化为企业微信机器人可识别的 Markdown 文本；
- WorkBuddy 通过 Webhook 向微信推送，完成一次闭环。
注意一个细节：定时任务的上下文里包含当前日期。如果你的提醒词里没有把"今天"这个信息透传给大模型，模型可能把日期写错，日报里全是"昨日""今天"混用。这一步是很多人漏掉的。
2. 开工前的环境准备
2.1 安装、登录与账号初始化
第一步是下载 WorkBuddy 客户端并完成登录。官网下载对应系统的安装包之后，安装过程没有需要特别说明的地方，一路下一步就行。登录账号后，建议先做两件事：
第一，把客户端更新到最新版。定时任务和 Webhook 功能在旧版本上稳定性差异明显，我遇到过旧版触发时间偶发不准的问题，升级后消失。
第二，检查工作目录的权限。如果你打算让定时任务访问本地文件（比如读取某个固定的信息源清单），确保 WorkBuddy 有这些文件的读取权限。在 macOS 上需要到系统设置里给客户端授予"完全磁盘访问权限"，Windows 上则要确认目录不被安全软件拦截。这些权限问题通常不会在首次运行时暴露，而是等定时任务真正跑起来才报错，提前做好能少踩一个坑。
2.2 配置模型接口与参数选择
WorkBuddy 本身不自带大模型，需要绑定模型服务的 API Key 才能让 Agent 具备生成能力。进入模型配置页面后，把服务商提供的 API Key 填入即可。这一步唯一需要花心思的是模型选择。
我建议同时配两种模型：一个通用对话模型用于日报生成，一个轻量模型用于格式清洗。理由很实际：日报生成需要较强的信息归纳能力，通用模型能保证内容质量；而格式清洗这个任务简单、机械，用轻量模型能降低成本、加快响应。WorkBuddy 支持的模型服务商比较多，你可以按自己已有的 API 来填。如果手里没有现成 Key，去对应平台注册开通即可，过程就是复制粘贴的事情。
配置完成后，立刻做一个连通性测试，比如直接在工作台发起一个对话让模型自我介绍。很多定时任务的失败都发生在调用模型这一步，提前验证至少能排除"Key 失效、余额不足、接口地址填错"这三类低级问题。
2.3 写一个日报专用 Skill
Skill 是 WorkBuddy 里最核心的概念，你可以把它理解成一个"带人设、带流程、带输出格式的提示词模板"。日报 Skill 的理想结构我帮你拆好了：
你现在是一名 AI 领域资讯编辑。你的任务是基于提供的最新资讯，生成一份简洁的当日 AI 日报。 要求： 1. 只收录 24 小时内发布的内容。 2. 分三个栏目：模型与产品动态、开源与开发工具、重要观点与研究。 3. 每个栏目最多 3 条，每条包含：一句话摘要 + 来源链接。 4. 某个栏目无新内容时，写"今日无更新"。 5. 全文控制在 500 字以内，开篇直接输出内容，不要寒暄。 6. 日期以参数中的当前日期为准。这段提示词有几个精心设计的地方。第一栏目的划分不是我拍脑袋想的，而是 AI 圈读者最常关注的三个方向，分类明确后模型输出不会东一榔头西一棒子。第二字数限制直接对标企业微信消息体的上限，避免生成几千字超长内容导致推送被截断。第三"日期以参数中的当前日期为准"是关键，它告诉模型不要去猜日期，而是使用定时任务注入的上下文参数。你可以把这段提示词完整保存到 WorkBuddy 的 Skill 管理页面，后面建流程时直接调用。
3. 核心实现：定时触发与微信推送
3.1 配置"每天上午 10:30"的定时触发器
在 WorkBuddy 里新建自动化流程时，触发器类型选"定时"即可。这里出现了全流程中唯一一个像代码的东西——Cron 表达式，不过它没那么可怕：
0 30 10 * * *从左到右依次是秒、分、时、日、月、周，对应关系就是每天 10:30:00。
填完表达式后，我强烈建议你再确认两个参数。一是时区：WorkBuddy 里一般默认 Asia/Shanghai，但如果你之前折腾过国际版或者系统时区不是中国标准时间，务必在触发器设置里人工确认，否则可能出现"服务器按时跑了但你手机准点收不到"的问题。二是首次生效时间：有些平台对定时任务的首次执行需要明确的起始日期，默认可能从明天才开始，你要在配置里确认这一点。
另外，真实业务里"上午十点半"可能不是所有人的理想时间。作为参考，我们团队后来把这个时间调到了 9 点 20 分，赶在晨会之前发送。你完全可以根据自己的作息修改 Cron 表达式，规则是一样的。
3.2 微信推送通道选型与接入
定时触发解决了，接下来是"怎么把日报送到微信"。这里有三条主流路线，我把它们的差异整理成了一张表：
| 方案 | 配置难度 | 稳定性 | 限制 | 适合场景 |
|---|---|---|---|---|
| 企业微信群机器人 Webhook | 低 | 高 | 每条消息限 4096 字节，每分钟限 20 条 | 个人使用/团队共享，最推荐 |
| Server酱 | 低 | 中 | 免费版每天有推送配额 | 个人日常提醒 |
| PushPlus | 低 | 中 | 免费版有频率限制 | 个人日常提醒 |
| 自建微信公众号 | 高 | 高 | 需要认证和服务器 | 面向公众的内容分发 |
我最终选的是企业微信群机器人。理由很简单：免费、无需公网服务器、微信原生提醒，而且它支持 Markdown 消息类型，日报里的二级标题和列表能直接渲染，观感比纯文本好得多。接入方式也最直接——建一个只有你自己的群（或者拉一个"日报接收"群），在群设置里添加群机器人，拿到 Webhook 地址，把这个地址填到 WorkBuddy 的 HTTP 请求节点里就算完成。
Webhook 地址是一串包含机器人的key参数的 URL，它是唯一的身份标识。注意：任何人拿到这个地址都能往你的群里发消息，所以务必像保护密码一样保护它，绝不能写进公开仓库或截到群里。
3.3 日报模板与内容格式设计
推送通道支持 Markdown 格式，这意味着你可以把日报做得层次分明。我用的模板长这样：
## AI 日报 - 2025-xx-xx **模型与产品动态** - [一句话摘要](来源链接) - [一句话摘要](来源链接) **开源与开发工具** - ... **今日无更新栏目照常显示**这个模板有一个容易被忽视的优势：它天然适配 AI 生成。大模型在生成 Markdown 格式时，遵循的是结构明确的任务描述，不容易出现格式失控。如果你让它"自由发挥"，它可能写出毫无逻辑的长段落。另外，标题里的日期是动态注入的，不是模型猜的，整个模板我直接在 Skill 的输出格式部分做了约束，生成端和展示端共用一套结构，省去了后处理的麻烦。
日报生成后，WorkBuddy 的 HTTP 请求节点会把它作为报文内容发送到企业微信机器人。这一步要特别注意请求体格式：
{ "msgtype": "markdown", "markdown": { "content": "日报内容" } }如果你把markdown写成了text，消息也能发出去，但 Markdown 语法会以纯文本展示，整个日报的可读性大打折扣。这个字段拼写问题是我见过最常见的低级错误，后面再看一条判断技巧。
4. 实操过程实录：从创建到第一次推送成功
4.1 完整配置流程 Step by Step
现在我把整个配置流程串一遍，你可以照着操作。为了描述方便，我按我自己的环境来写，界面名称在不同版本里可能有细微差异，但流程骨架是一致的。
第一步，创建 Skill。进入 WorkBuddy 的 Skill 管理页，新建一个名为"AI 日报生成器"的 Skill，把上面 2.3 里的提示词完整粘贴进去，保存。
第二步，创建自动化流程。在自动化页面新建流程，命名"每日 AI 日报推送"，触发器选择"定时"，填入 Cron 表达式0 30 10 * * *，时区设为 Asia/Shanghai。
第三步，添加模型调用节点。这里引用刚才创建的日报 Skill，输入参数绑定触发器注入的日期变量{{TODAY}}。如果你不确定变量名怎么写，看看触发器的输出参数说明，每个平台都会暴露这些变量，照着填就行。
第四步，添加 HTTP 请求节点。方法选 POST，URL 填入企业微信机器人的 Webhook 地址，请求体选择 JSON，模板按 3.3 节的格式填写，其中content的值绑定上一步模型输出的文本变量。
第五步，手动调试。先不要等定时器跑，直接在流程页点"运行一次"，在调试面板里看每一步的输入输出。这一步能验证整个链路是否通畅，绝大多数问题在这时候就能发现。
第六步，验证推送结果。手动运行成功后，微信里应该已经收到一条完整的 AI 日报。检查内容结构、日期、链接格式，确认无误后，把流程设为启用状态，等第二天上午 10:30 自动触发。
4.2 首次运行验证与日志检查
如果你照着上面步骤做完，大概率第一次手动运行就会成功。但真正的考验是第二天早上那次自动触发。我的习惯是去看执行日志，而不是只在微信里等消息。
WorkBuddy 的每个自动化流程都有执行记录页面，里面能看到每一次触发的状态、耗时和各节点的输入输出。重点看三处：
- 触发器状态是否为"已执行"，确认定时任务真的被唤醒了；
- 模型节点的输出是否符合模板结构，有没有出现大段空白或者 JSON 解析错误；
- HTTP 节点的返回码是否为 200，企业微信机器人返回 200 才代表消息送达成功。
如果返回码是 200 但微信没收到，问题几乎都出在请求体格式上。我遇到过一种情况：模型输出里带了多余的转义字符，导致整个 JSON 解析失败。排查方法是把 HTTP 节点收到的实际请求体复制出来，放到任意 JSON 校验工具里看一眼，格式一断就明白问题在哪。
4.3 首次运行后的三处调优
流程跑通后不要急着收工，把日报连续看几天，你会很快发现可以优化的地方。我做了三处调整，仅作为参考方向：
第一，日报长度。第一次生成的日报快两千字，推送后被裁掉一大截。后来我把 Skill 里的字数约束从 500 字压到 400 字，并且明确"每栏每条不超过 40 字摘要"，推送效果立刻稳定。
第二，信息源去重。大模型偶尔会把同一条新闻换一种说法重复输出，这其实是上下文窗口内信息冗余导致的。我在 Skill 里加了一句"如果多条新闻内容相似，只保留信息量最大的一条"，重复问题基本消失。
第三，发送失败的重试策略。企业微信机器人偶尔会有超时，我观察到 WorkBuddy 的 HTTP 节点可以配置失败重试次数，我设成了最多重试 2 次，间隔 1 分钟。注意别把重试间隔设太短，否则触发频率限制反而更麻烦。
5. 常见问题与排查技巧实录
5.1 定时任务没触发、消息收不到
这是所有自动化推送方案里最让人抓狂的问题。消息没收到，先别怀疑推送通道，按这个顺序排查：看流程是否处于启用状态、看执行记录里的触发时间、看触发器时区。我统计过自己遇到的案例，超过一半的"没推送"问题出在流程忘了启用，剩下的是时区配置错误。
真正链路没问题但仍收不到，那就要怀疑企业微信机器人本身。最常见的情况是机器人被群主移除了，或者群解散了，Webhook 立即失效。此时机器人接口会返回错误码，WorkBuddy 的执行日志里能看到具体信息。处理方式是到群里重建机器人，把新的 Webhook 地址重新填回流程。
5.2 内容错乱与格式异常
日报生成后出现格式错乱，十有八九是模型输出没严格遵循提示词。比如要求输出 Markdown 列表，结果它输出了一段 JSON。我有两个处理习惯：第一，在 Skill 的输出格式里增加"只输出日报正文，严禁输出任何解释性文字"，这个约束非常有效；第二，如果模型做不到严格结构化，就在 WorkBuddy 流程里加一个文本后处理节点，用正则把多余的代码块标记剔除。大多数情况下先做第一条就够。
另外对微软家的 Markdown 渲染要有点心理准备，它和企业微信的 Markdown 语法不是完全一样的。最好的策略是让 Skill 输出最基础的 Markdown——只用二级标题、加粗、列表、链接，这些语法在哪里都能正常渲染。复杂表格、引用块之类的花活容易翻车，日报场景里完全没必要用。
5.3 重复推送与并发问题
关于重复推送，我总结成一个经验：定时任务必须设计成幂等。WorkBuddy 的定时触发器在极端情况下可能触发多次，如果不做去重，你的微信会在一分钟内收到两条一模一样的日报。
最简单的去重方案是利用执行记录本身——在流程开始处加一个判断节点：如果今天的记录已存在且状态为成功，就不再执行。这相当于一个流程级的锁机制。如果你用的是自建脚本方案，就得自己保存一个last_run_date的状态文件，成本高且容易出错，这也是 WorkBuddy 这类平台的价值体现。
5.4 常见问题速查表
| 现象 | 可能原因 | 处理思路 |
|---|---|---|
| 到点没收到日报 | 流程未启用/时区配置错误 | 检查流程状态和 Cron 时区 |
| HTTP 返回非 200 | Webhook 失效或请求体格式错误 | 到企业微信重新生成机器人，校验 JSON 格式 |
| 内容被截断 | 模型输出超过企业微信消息体上限 | 在 Skill 里压缩字数和条数 |
| 收到重复日报 | 定时器重复触发 | 增加流程级幂等判断节点 |
| Markdown 渲染异常 | 模型输出带复杂语法 | 限定基础 Markdown 语法 |
| 日期显示错误 | 未注入当前日期参数 | 在流程中绑定日期变量给模型节点 |
用 WorkBuddy 搭完这套日报推送，我最大的体会是：自动化方案的价值不在于把脚本跑通，而在于让整个流程"隐形"。理想状态是，你看微信推送时只关心内容本身，完全忘记后台还有一套定时任务在跑。如果你也有类似的需求，建议先从最简版本开始：固定时间、单一信息源、纯文本推送，跑稳定一周后再逐渐加入多信息源和更复杂的模板。另外一个小技巧是，把日报推送给自己的同时，顺手把 Webhook 地址同步给同样关注 AI 动态的同事，他们也能收到这份日报，一个人搭的流程，整个小团队都受益。
