1. 这个闹钟不是叫醒我是叫醒 WorkBuddy每天上午十点半手机在桌上震一下。我不用看也知道微信里躺着的不是哪个群的消息而是一条整理好的 AI 日报昨晚 GitHub 上有哪些热门的 Agent 项目、各家模型发布了什么新版本、值得跟进的技术讨论是哪几个。往下翻两屏还有一段按我格式生成的摘要直接就能转发进团队群。这不是什么第三方资讯服务是我给 WorkBuddy 设的一个闹钟。WorkBuddy 这个工具大多数人对它的印象还停留在AI 编程助手——能在 IDE 里补全代码、能问你项目结构、能帮你想思路。但我实际用下来它真正值钱的地方不是写代码而是它背后那套 agent 式的执行能力可以加载自定义指令skill、可以跑一些自动化流程、能把一套重复劳动固化成可靠的工作流。换句话说它不只是敲代码时的副驾驶它是能替你把一件事从头到尾跑完的数字员工。我需要一名数字员工每天早上帮我盯 AI 圈的动态然后在十点半前把精华总结好、推到我微信里。这个需求听起来简单真正做起来要拆成四件事内容从哪来、总结怎么做、时间怎么触发、微信怎么送达。这四件事全部搞定才算是把一个手动刷信息的动作彻底变成了自动送到眼前。这篇文章就是把我的完整方案拆开来讲。里面没有特别玄的技术WorkBuddy 本身提供的是基础能力剩下的大部分是组合和调优。我会讲清楚我是怎么设计指令的、定时任务为什么选了这个方案、微信推送遇到过哪些坑、跑了七天之后我又改了哪些设置。适合谁看和我一样平时依赖 AI 工具、又不想天天泡在信息流里的人以及那些已经在用 WorkBuddy、但只拿它写代码的开发者——你会发现它还能干很多非代码的活。2. 日报内容从哪来订阅源、热榜 API 与模型自产的取舍2.1 我踩过的第一个坑让模型凭空总结一份日报最早我天真地以为只要给 WorkBuddy 一个提示词它就能总结出当天的 AI 圈动态。结果第一版日报出来看得我皱眉头内容确实通顺今天 AI 领域迎来多项重要进展这种话连篇具体是哪家发布了什么、代码仓库叫什么、讨论热度多高一个都没有。原因很简单——模型的知识是有截止时间的你不给它输入材料它就只能对着训练集里的旧闻编。这和我让新同事写日报、又不给他看工作群记录是一个道理写出来的东西格式再对内容也是悬空的。所以搞清这件事以后我做日报的思路彻底变了WorkBuddy 只负责加工不负责无中生有。我给它规定好数据源它按固定模板把材料揉成日报。数据质量决定日报上限提示词只是守住下限。2.2 三条稳定的内容来源我实际用的是三条线按优先级排列第一条是 GitHub Trending 和 GitHub Topic 的聚合信息。AI 圈的活跃开源项目基本都在这上面哪些仓库昨晚涨了多少 star、哪些新项目冒出来了都是硬信号。我是用 GitHub 的公开接口去拉 trending 数据解析出仓库名、描述、语言、今日 star 增量存成结构化数据。第二条是几个固定的信息源站点。Hacker News 的 AI 板块、HN 的排名变化这种偏讨论热度的信息用来补充社区在关注什么。我拉了 RSS 解析简单过滤关键词后合并进来。第三条是模型自身知识兜底。有一些背景解读类的内容比如这个新项目解决了什么问题为什么大家突然在刷某个词我会让 WorkBuddy 基于前两条数据去解释相当于是让它做二次分析而不是凭空输出。# 拉取 GitHub Trending 的核心思路简化版 import requests import json # 这不是完整代码是演示我处理数据的路径 url https://api.github.com/search/repositories params { q: topic:ai created:2025-01-01, sort: stars, order: desc, per_page: 20 } resp requests.get(url, paramsparams) data resp.json() for item in data[items]: print(item[full_name], item[stargazers_count])这一步做好以后就解决了我核心的痛点WorkBuddy 拿到的不是空手而是一堆带日期的、可验证的原始材料。它要做的只是阅读筛选排版。2.3 数据落在哪本地文件是所有自动化的地基这里有个细节值得单独说数据源抓下来之后我统一存成 JSON 文件存放在一个固定的工作目录里比如~/workbuddy-daily/raw/2025-06-10.json。WorkBuddy 去读这个文件而不是直接去调用线上的接口。这样做的好处有两点。第一任务可以被反复调试。一次跑失败、推送报错我不需要重新拉取数据只要拿同一份原始文件去测。第二WorkBuddy 的能力边界更清晰它只负责读取 JSON 和输出 Markdown抓取逻辑我可以用更熟悉的 Python 精确控制。万一哪天数据源改版了我只需要修抓取脚本不需要重新教模型怎么理解一个新接口。如果只是让 WorkBuddy 自己随缘发挥那每次生成的日报可能都是另一个风格而有了固定的本地文件日报的原料就稳定住了。AI 写日报这件事就不再是掷骰子而是一条有输入、有输出、可回放的流水线。3. 定时触发三选一本地计划任务、内置调度、还是云端函数日报的内容生产链路打通之后接下来就是闹钟两个字的核心了——怎么让 WorkBuddy 每天上午十点半自动醒过来干活。3.1 方案一WorkBuddy 的 skill 里能不能直接配定时WorkBuddy 支持自定义 skill自定义指令集这也是很多人工作中最常用的扩展方式。它的模型是你写一个 Markdown 文件里面包含触发条件、执行步骤、输出要求然后在对话里唤醒它。一开始我确实试过直接在 skill 里写每天十点半执行但很快发现问题skill 本身是被调用的机制它是一个能力封装不是一个常驻的定时器。它能做的是当用户说‘生成日报’时就按规则干活它不能自己决定我十点半该上班了。这就好比一个厨师手艺再好你不在早上把他叫醒他也不会主动进厨房。这不是 WorkBuddy 的缺陷而是我对它的定位出了问题。真正负责定时唤醒的应该是外面那一层调度器WorkBuddy 只负责被叫醒之后高效干活。3.2 方案二系统计划任务 WorkBuddy 命令行于是我转向了本地操作系统的定时能力。Windows 上有任务计划程序macOS 上是 launchdLinux 上是 cron。原理都一样让系统到点跑一个命令或脚本脚本里再调用 WorkBuddy 干活。WorkBuddy 本身是提供命令行入口的CLI 模式可以在非 IDE 环境里通过指令调用。比如workbuddy run --skill daily-report --input ~/workbuddy-daily/raw/2025-06-10.json --output ~/workbuddy-daily/report.md我实际测试下来这个方案完全走得通。我在 macOS 上配了一个 launchd 的 plist 文件每天上午 10:15 触发一个 shell 脚本#!/bin/bash # 拉取数据 python3 ~/workbuddy-daily/fetch_sources.py # 调用 workbuddy 生成日报 workbuddy run --skill daily-report \ --input ~/workbuddy-daily/raw/$(date \%Y-\%m-\%d).json \ --output ~/workbuddy-daily/report.md # 推送微信 python3 ~/workbuddy-daily/push_wechat.py ~/workbuddy-daily/report.md本地计划任务的好处是零成本、无平台依赖、所有文件都在自己机器里坏处是电脑必须开机、网络必须正常、计划任务本身的日志你得自己盯着。我实际跑的时候遇到过一个典型问题笔记本电脑晚上合盖休眠了第二天早上十点半它还在睡任务自然没跑成。这个后面我会详细说。3.3 方案三云端函数兜底把闹钟挪到永不关机的手机本地定时任务依赖设备的清醒状态这个天然约束让我考虑云端方案。现在各家云服务商都有定时触发的函数计算比如定时触发器我只要写一个 Python 脚本丢上去填好 cron 表达式它就能每天十点半自动执行根本不管我的电脑是开还是关。这个方案的可靠度最高代价是引入了外层依赖抓取脚本、调用 WorkBuddy CLI、推送微信的脚本全部要容器化或函数化。WorkBuddy 作为腾讯云代码助手和自家云函数的兼容性不错我在云端直接装一个 CLI 环境调用方式和本地几乎一致。但我不建议一上来就上云端。先把一条链路在本地跑通再考虑迁移到云端。本地调试时看日志方便、改代码快等确认所有环节都稳定了再花半小时部署到云函数把闹钟变成永不关机的闹钟。3.4 我的最终选型本地为主云端兜底完全说实话这次我的最终方案是本地为主、云端兜底的双轨制。本地仍然保留 launchd 任务作为主力运行同时把这套逻辑封装进一个云端定时函数每天早上跑一次。两边跑的是同一套脚本只是入口不同。如果一方的任务失败另一方还能把日报补推送过来。我知道肯定有人觉得这是小题大做——一个日报而已至于搞两套吗但我的判断标准其实很简单自动化系统的价值不在于平时跑得多顺而在于失灵的时候你多久能发现。双轨制下即使本地任务休眠了云端也会准点把日报推过来我不会因为电脑合盖就断粮。自动化一旦建立人对它的依赖就会迅速提高可靠性的优先级自然要升到第一位。4. 微信这条链路上的三种推送姿势日报生成之后最后一公里就是怎么送进微信。这一步我试过三种方式各有各的使用场景也各有各的坑。4.1 姿势一企业微信群机器人最简单但限制很明显企业微信群机器人是投入产出比最高的一种方式。你只需要在群里添加一个机器人拿到一个 webhook 地址然后往这个地址 POST 一段 JSON消息就发出去了。import requests webhook https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的key payload { msgtype: markdown, markdown: { content: # AI 日报 2025-06-10\n\n## 今日头条\n\n..., } } requests.post(webhook, jsonpayload)优点非常明显不需要服务器、不需要公众号、不需要复杂的审核有手就能配。缺点也很直接消息是发在群里的不是发给个人微信的。如果你只是给自己看在群里刷一条日报倒也能接受但多少有点占地方。而且群机器人的 Markdown 渲染是有限制的不支持图片外链预览链接跳转也相对笨拙。我的实际建议是先在团队群或自己小群里跑通企业微信机器人用最少的时间验证内容的质量和频率是不是符合预期这比一上来就折腾个人微信推送要理智得多。4.2 姿势二Server 酱把日报推到服务号里如果不想在群里刷屏想让日报像一条普通消息一样躺在你的微信聊天列表里Server 酱方糖是最成熟的路径。它本质上是帮你搭了一座桥你往 URL 里 GET/POST 一段消息它通过微信公众号的模板消息能力把内容推送到你自己的微信上。平时我推荐别人做这类推送第一句话就是个人开发者优先用 Server 酱。它不用服务器不用自己搭建微信对接注册即用而且它也支持 Markdown 格式。我实际体验下来它的发送延迟基本在秒级稳定性也算可靠。但它的限制也很现实消息有长度上限不适合塞长篇大论文章太长会被截断成摘要详情链接而这个链接是服务号的文章链接不是原链接。如果日报很长建议只推送摘要把完整版本存在本地或自己的博客里。# 推送日报摘要到微信 curl https://sctapi.ftqq.com/你的sendkey.send?titleAI日报_2025-06-10desp$(cat ~/workbuddy-daily/report.md)用这个姿势推送每天十点半微信里出现的就是一条标题清楚的日报摘要点开详情可以看全文。这也是我最后用得最顺的一种方式。4.3 姿势三微信测试号和小程序模板消息强大但重再往上一层就是微信测试号公众平台测试号的模板消息或者自建一个小程序来接收。这套方案优点是高度可控消息格式完全自定义甚至可以做成交互式的点一下查看更多缺点也很明显需要准备 appid、secret、模板 ID需要消息模板审核整体维护成本陡增。这条路线适合那些想把日报做成一个产品的人比如你想在团队里推广这个习惯给每个人都推送定制日报那确实值得做。如果只是自己一个人用我建议别在这里耗时——用最低的成本先把信息流跑起来让日报先飞一会儿。4.4 推送环节我真实踩到的三个坑聊完姿势说几个我在推送环节真实踩到的问题都是常规文档里不会跟你讲的。第一个坑是换行符在 Markdown 渲染中丢失。我在本地用\n换行推给企业微信机器人后发现段落全部挤在一起。解决方法是统一转成微信兼容的换行比如 Markdown 中的空行需要br或两个换行符并在测试阶段就检查字符串的实际内容不要在发送后才发现排版乱了。第二个坑是链接无法点击。企业微信机器人的 Markdown 里裸链接点击性很差必须显式写成[文字](url)格式有时候还需要在文字里加上完整 URL 才能正确识别。这一点在调试时要特别留意。第三个坑是消息重复推送定时任务没配好十分钟内推了三条一样的日报。原因是脚本重试机制写得太激进失败一次就立即重发导致成功之后又重发了。后来我加了一个sent_history.json文件推送前先检查当天的日报是否已经发送过重复推送的问题才根治。这三个坑都不难解决但每一个都会在你真正上线推送时跳出来提前知道就能少走弯路。5. 从配置到跑通一份可以直接抄的完整清单前面讲的是原理和选型这一章把整套流程收拢成一个可以照着操作的清单。按这份清单走你也能在自己的电脑上搭出一套WorkBuddy 定时 AI 日报 微信推送的流水线。5.1 环境准备和目录结构先把目录和文件约定好。我的做法是~/workbuddy-daily/ ├── fetch_sources.py # 抓取 GitHub/HN 数据源 ├── workbuddy_daily_skill.md # WorkBuddy skill 定义 ├── push_wechat.py # 微信推送脚本 ├── daily_report.md # 生成的日报中间产物 ├── raw/ # 原始数据缓存 │ └── 2025-06-10.json └── sent_history.json # 去重标记这个目录是整套自动化系统的记忆体WorkBuddy 读这里的输入、写这里的输出、推送脚本也只认这里的文件。结构一旦定下来就尽量别改不然各种绝对路径和 skill 里的引用全得跟着乱。5.2 WorkBuddy skill 定义把日报格式刻进模型里workbuddy_daily_skill.md 就是让 WorkBuddy 变成日报编辑的那张身份证。我写的要点是--- name: daily-report description: 生成每日 AI 领域动态日报 --- 你是一名资深 AI 领域日报编辑。请读取 raw/ 目录下当天的 JSON 数据文件完成以下任务 1. 提取最有价值的 5 个开源项目解释它们为什么值得关注 2. 挑选 2-3 条社区讨论热度最高的主题做简要背景解读 3. 输出格式为 Markdown包含日期、分类、标题、内容、项目链接、star 增量等字段 4. 语言风格要求简洁、直接、有判断力不用空话套话 5. 最后附上今日一句话总结。 输出文件写入 daily_report.md。这里最重要的不是格式本身而是给模型明确的权限边界它只处理 raw 目录下的文件不要自由发挥它必须给出项目链接数字和事实要可追溯。把这几条写进 skill日报的稳定性和可信度都会明显提升。如果你是在自己的项目里复用我强烈建议你把读取哪天的数据、输出到哪个文件、格式字段有哪些都写清楚。模型对模糊指令的理解再好也不如你把边界画清楚。5.3 调度脚本和推送脚本的对接调度脚本处理的是几点拉取数据、几点调用 WorkBuddy、几点推送微信。我的建议是给每个环节之间留一点缓冲比如十点半的推送十点十五分开始拉数据十点二十分调用 WorkBuddy 生成日报十点二十五分推送。时间留宽一点就少一点某个环节慢了导致推送延迟的焦虑。推送脚本的伪代码大概是import json, hashlib, datetime, os async def push_report(): today datetime.date.today().isoformat() # 查重 if today in load_history(): return # 读取日报 with open(daily_report.md, r, encodingutf-8) as f: content f.read() # 推送到 Server 酱 resp requests.post(SERVER_URL, data{title: fAI日报_{today}, desp: content}) if resp.ok: save_history(today)这里唯一的小心机是那个查重逻辑系统跑起来之后你一定会遇到重复执行的情况可能来自手动调试、也可能来自云端和本地双跑。查重文件就像闹钟的贪睡键确保同样的日报只发一次。5.4 首次链路的完整调试节奏我第一次跑通这条链路花了一个多小时大部分时间花在调 push 脚本的格式上。你第一次做时可以按这个节奏来先手动跑一次fetch_sources.py确认 raw 文件生成手动调用 WorkBuddy 的 skill确认daily_report.md的内容质量临时运行push_wechat.py确认微信里能看到正确排版最后才是把三个脚本串起来挂到定时任务里。很多人一上来就直接挂定时任务结果哪一环出了问题都不知道排查起来非常痛苦。自动化系统的调试永远是一层一层来的手动跑通每一环再叠加调度这是最高效的路径。6. 跑了七天后我改掉的四个设置系统上线第一天十点半微信准时收到日报的时候说实话是很有成就感的。但连续跑了七天我改掉了四个设置每个都是真实发生的幺蛾子。6.1 电脑休眠导致本地任务失效加了唤醒或切换云端这个我前面提到过。第一天晚上我把笔记本合盖带回家了第二天上午十点半任务根本没执行。原因就是 macOS 在合盖休眠后launchd 不会唤醒机器执行任务。我查了一圈最稳妥的解法是让本机关盖不睡眠比如接电源时用caffeinate保持唤醒或者直接依赖云端兜底。最后我选了后者云端函数每天定时运行本地任务即使没跑日报照样送达。所以如果你也打算完全靠本地计划任务跑请一定想清楚这台电脑会不会在你设定的时间处于唤醒状态如果会那么请务必上云端兜底。6.2 日报推送时间不稳定十点半变成十点四十五上了双轨制后我又遇到一个问题云端的函数执行时间不稳定有时十点半准时到有时拖到十点四十五。原因是定时触发后函数内部拉取外部数据源的响应时间波动比较大GitHub API 偶尔慢到几十秒。我把拉取环节加了超时设置和数据源重试机制超时后跳过非关键源优先保证日报能按时推送。另外我把生成日报和推送日报拆成了两个步骤生成可以稍微晚一点但推送绝不拖延——日报晚到五分钟可以接受推送脚本卡住半小时就会让人产生这系统废了的错觉。6.3 star 数据和项目描述越来越冗余调整了筛选阈值跑了两三天以后我发现日报里 GitHub 项目越来越多但真正有洞察的内容变少了。原因是拉热榜数据时阈值设得太低一些只有零星 star 的小仓库也进来了稀释了日报浓度。我把per_page从 20 调到了 30但加了额外的排序逻辑只保留 star 增量超过某个阈值、且描述里包含 AI 相关关键词的仓库。这样一来日报从我告诉 WorkBuddy 什么都可以写变成只写值得写的信息密度明显上来了。6.4 内容合规与来源标注这是我给自己加的硬规矩AI 日报不是天马行空的创作它是带着信息来源的摘要。我在 skill 里特别增加了一条硬性要求每条内容必须标注来源链接和原始数据日期无法溯源的内容不要写进日报。这样做一方面是为了避免模型在补全时把不存在的项目写得像真的一样——这种事我真的遇过它一本正经地给我推荐了一个看起来非常合理、但 GitHub 上根本不存在的仓库另一方面也是对我自己的保护推送到微信里的内容要有据可查不能图省事就放任模型自由发挥。这一条看起来不起眼却是整套系统从玩具走向可信工具的分水岭。最后分享一个实际的体会七天跑下来我的感受是给 WorkBuddy 设闹钟这件事真正的难点不是某个单一技术而是把内容获取、AI 加工、定时触发、消息推送这几件事拧成一条不间断的链。每一个环节单拎出来都不算难但把它们组合在一起并且让系统连续一周不出错才是自动化真正考验人的地方。如果你也打算做类似的事我的建议是先别追求完美方案从企业微信机器人加本地计划任务开始跑通一遍流程然后把你踩到的每个坑记下来逐个修正等你觉得链路稳定再考虑上云端兜底这样你的每天十点半就会多一条可靠的、属于你自己的 AI 日报。