1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”每天早上到工位第一件事不是打开编辑器而是先刷一遍昨天夜里各个渠道冒出来的消息项目群里有没有人 我、订阅的几个技术号有没有更新、手头跟进的几个关键词有没有新动态。这套动作熟练之后大概要花十五到二十分钟问题是它每天都在重复而且刷完就忘真正有价值的信息经常被淹没在噪音里。后来我把这件事拆成了两半采集和筛选交给 WorkBuddy投递交给微信。WorkBuddy 负责在固定时间跑一遍我预设的任务把结果整理成一份结构化的日报微信负责在上午十点半准时把这份日报推到我手机上。这样一来我早上到工位只需要花两分钟扫一眼日报剩下的时间全部留给真正要动手的活。这套东西听起来像是个“小玩具”但实际跑起来之后我发现它解决的是一个很实在的问题把“定时 采集 整理 推送”这四个动作串成一条无人值守的流水线。关键词里出现的 WorkBuddy、AI、微信、自动化、deepseek其实正好对应了这条流水线的四个环节——WorkBuddy 是调度和执行的主体AI 能力负责把原始信息加工成可读的日报微信是最终的投递终端而自动化是把它们粘合起来的胶水。这篇文章我会把这套“十点半日报”从设计思路到落地细节完整拆一遍。适合两类人看一类是已经装了 WorkBuddy 但只会手动点一下、还没让它真正“自己动起来”的用户另一类是手上有一堆重复性信息处理任务、想找个轻量方案把它们自动化掉的人。不需要你懂多少编程但需要你愿意花半小时把配置一次性做对。提示本文提到的所有时间、频率、推送渠道都是可以替换的。十点半只是我个人的习惯你完全可以改成八点、十二点或者下班前。核心是那套“定时触发 内容加工 定向投递”的思路。2. 把需求翻译成 WorkBuddy 能听懂的任务描述2.1 先想清楚“日报里到底要有什么”很多人一上来就去翻 WorkBuddy 的配置文档结果被一堆参数绕晕。我的建议是反过来先用大白话把日报的内容列出来再去找对应的能力。我自己的日报固定包含四块昨天我关注的关键词有没有新的公开讨论按热度排个序我订阅的几个信息源当天更新的标题列表附一句话摘要我手头正在推进的事项有没有到期的提醒一句当天的“重点提示”由 AI 根据上面三块内容自己总结。这四块里前三块是“采集 整理”第四块是“AI 加工”。把它们写清楚之后你会发现 WorkBuddy 要干的事其实很明确按顺序执行几个子任务把结果拼成一段文本然后发出去。2.2 用“自定义指令”把模糊需求变成可执行步骤WorkBuddy 的自定义指令skill是这套方案的核心。它的作用是把一段自然语言描述翻译成 WorkBuddy 能逐步执行的动作序列。我一开始写的指令特别笼统比如“帮我整理今天的行业动态”结果它每次给我的东西都不一样有时候是三条有时候是十条格式也飘。后来我改成结构化写法效果立刻稳定下来。核心技巧是把“做什么”和“输出成什么格式”分开写任务目标生成一份当日信息日报 执行步骤 1. 检索关键词列表[关键词A, 关键词B, 关键词C]时间范围限定为过去 24 小时 2. 对每条结果提取标题、来源、一句话摘要 3. 按“信息密度”从高到低排序最多保留 8 条 4. 读取我预设的待办清单筛出今天到期的条目 5. 用一段不超过 150 字的话总结以上内容语气简洁 输出格式 - 第一部分关键词动态列表 - 第二部分订阅更新列表 - 第三部分今日待办列表 - 第四部分AI 总结一段话这么写的好处是WorkBuddy 每一步都有明确的输入和输出不会自由发挥。关键词里提到的“workbuddy 自定义指令推荐”其实核心就是这个思路指令越像一份给新人的操作手册执行结果就越稳定。2.3 为什么把“排序”和“截断”写进指令里这里有个容易被忽略的细节如果不限制条数WorkBuddy 可能会把搜到的几十条结果全塞给你日报直接变成信息垃圾场。我在指令里强制加了“最多保留 8 条”和“按信息密度排序”实际跑下来日报的可读性提升非常明显。“信息密度”这个词有点虚我在实际配置里会把它拆成几个可判断的维度来源是否权威、标题是否包含具体数字或结论、发布时间是否在最近 12 小时内。WorkBuddy 在执行时会综合这几个维度打分虽然做不到百分百精准但比随机排序强太多。注意排序规则不要写得太复杂超过三个维度之后 AI 反而容易混乱。我的经验是两到三个维度最稳。3. 定时触发让 WorkBuddy 在十点半自己醒来3.1 定时任务的两种实现路径让 WorkBuddy 每天十点半自动跑有两条路可以走。第一条是用 WorkBuddy 自带的定时/计划任务能力在它的任务配置里直接设定触发时间第二条是用系统级的定时工具去调用 WorkBuddy比如 Linux 上的 cron、Windows 上的任务计划程序。我两条都试过。自带定时能力的优点是配置简单、和 WorkBuddy 内部状态耦合好缺点是如果 WorkBuddy 本身没在运行任务就不会触发。系统级定时工具的优点是更可靠只要机器开着就能触发缺点是需要多写一层调用脚本。最后我选了系统级定时 WorkBuddy 无头执行的组合。原因很实际我的 WorkBuddy 有时候会被我手动关掉去调试别的东西如果依赖它自带的定时那天的日报就没了。用系统级定时去“叫醒”它稳定性高一个档次。3.2 cron 表达式怎么写才不出错Linux 环境下用 cron 是最省事的。十点半对应的表达式是30 10 * * * /path/to/run_daily_report.sh /var/log/workbuddy_daily.log 21这里有几个我踩过的坑值得单独说一下路径必须写绝对路径。cron 执行时的环境变量和你在终端里完全不一样用相对路径基本必挂。把输出重定向到日志文件。不然任务失败了你根本不知道 log 21这半句一定要带上。脚本里显式声明环境变量。如果 WorkBuddy 依赖某些环境变量比如 API 相关的配置在脚本开头用export声明一遍别指望 cron 帮你继承。我第一版脚本就是因为没写绝对路径连续三天日报都没发出来查了半天才发现是 cron 在/root目录下找不到我的脚本。这种坑不踩一次是不会长记性的。3.3 脚本里到底该写什么run_daily_report.sh的内容其实很薄核心就一件事调用 WorkBuddy 执行我预设的那个日报任务。大致长这样#!/bin/bash export WORKBUDDY_HOME/home/user/.workbuddy export PATH$PATH:/usr/local/bin cd /home/user/workbuddy-tasks /usr/local/bin/workbuddy run --task daily_report --output /tmp/daily_report.txt if [ $? -eq 0 ]; then echo $(date) - 日报生成成功 else echo $(date) - 日报生成失败退出码 $? fi关键点是那个--output参数它把 WorkBuddy 生成的结果落到一个临时文件里后面推送环节直接读这个文件就行。这样采集和推送就解耦了推送失败也不影响日报本身的生成。提示脚本记得加执行权限chmod x run_daily_report.sh这个低级错误我见过太多人犯。4. 把日报送进微信投递环节的几种做法4.1 先明确一件事你要的是“通知”还是“对话”“送进微信”这个需求其实有两种完全不同的实现方向。一种是单向通知日报以消息形式推给你你只读不回另一种是双向对话你还能在微信里回复、追问、让它继续干活。前者实现简单、稳定性高后者体验好但复杂度上一个台阶。我一开始做的是单向通知跑了两周觉得够用了。日报本来就是“扫一眼”的东西不需要交互。如果你确实想要双向能力那就要考虑接入微信生态里的机器人或服务号能力这部分涉及的东西比较多本文先聚焦单向推送这条最实用的路径。4.2 用企业微信机器人做投递是最省心的在几种投递方式里企业微信群的 Webhook 机器人是我最推荐的。原因有三点配置简单一个 Webhook 地址就能发消息支持 Markdown 格式日报的排版能保留稳定性好不像个人号那样容易触发风控。配置流程大致是在企业微信里建一个只有自己的群添加一个群机器人拿到 Webhook 地址然后用一条 curl 命令就能把消息发出去curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的KEY \ -H Content-Type: application/json \ -d { msgtype: markdown, markdown: { content: 日报内容放这里 } }把这段逻辑加到前面的脚本末尾日报生成完就直接推走了。整个链路从触发到收到消息实测下来在十秒以内。4.3 内容太长怎么办分段和摘要企业微信机器人对单条消息有长度限制日报内容一多就会被截断。我的处理办法是在 WorkBuddy 那一层就把内容压到 2000 字以内具体做法是在指令里明确要求“AI 总结部分不超过 150 字列表每条不超过 50 字”。如果内容实在压不下来就拆成两条消息发。我写了个简单的判断逻辑内容超过 1800 字就按段落切成两条中间加个“续”标记。这个阈值是我试出来的1800 字以下基本不会触发截断。4.4 个人微信这条路要不要走很多人第一反应是“我要发到个人微信”。这条路技术上可行但坑比较多个人号没有官方开放的消息接口第三方方案要么不稳定要么有账号风险。我的建议是能用企业微信就用企业微信它本质上也是微信生态消息在微信里能收到提醒体验差别不大但稳定性和合规性好太多。关键词里出现的“企业微信多开会封号吗”这类问题其实反映的就是大家对账号稳定性的担心。我的态度很明确投递渠道优先选官方支持的方案别为了省事去碰灰色地带日报这种每天都要跑的东西稳定性比什么都重要。5. 让 AI 把原始信息加工成“人话日报”5.1 为什么原始采集结果不能直接推WorkBuddy 采集回来的原始数据本质上是一堆标题、链接和时间戳。直接推给你你还是要自己读、自己判断等于没省事。AI 加工这一步的价值就是把“信息”变成“结论”。举个具体的例子。原始采集结果可能是这样的[标题A] 某工具发布新版本 [标题B] 某技术方案性能提升 30% [标题C] 某行业报告发布经过 AI 加工之后日报里呈现的是今日重点某技术方案性能提升 30%值得关注 某工具新版本主要是修 bug可以缓一缓 行业报告偏宏观建议周末再看。差别就在于前者是“有什么”后者是“该关注什么”。这才是日报真正的价值。5.2 给 AI 的加工指令要带“判断标准”AI 加工的质量取决于你给它的判断标准有多具体。我一开始只说“帮我总结一下”结果它给我的总结全是“今天有多条更新”这种废话。后来我在指令里加了三条判断标准涉及具体数字或结论的优先级最高涉及我关注的关键词的优先级次之纯公告类、无实质内容的直接过滤掉。加上这三条之后日报的“含金量”肉眼可见地提升了。关键词里提到的“deepseek”这类模型能力在这里的作用就是理解你的判断标准并稳定执行模型选得对加工质量就稳。5.3 语气和长度也要在指令里定死日报是给自己看的语气不用太正式但也不能太随意。我在指令里明确写了“语气简洁、直接不用敬语不用‘您好’‘感谢’这类客套话”。长度上限定“总结部分不超过 150 字”这样每天读起来节奏一致不会今天三行明天三十行。这里有个小技巧把你满意的日报样例贴进指令里当参考。AI 看到具体样例之后输出风格会明显向样例靠拢。我贴了两份自己觉得写得好的历史日报进去之后的输出稳定多了。6. 实测中遇到的几个坑和对应的解法6.1 任务跑成功了但日报是空的这是我最开始遇到的一个诡异问题日志显示任务执行成功但推送出去的日报是空的。排查了半天发现是输出文件路径不一致——WorkBuddy 把结果写到了 A 路径推送脚本读的是 B 路径。解法很简单在脚本里用一个变量统一管理路径REPORT_FILE/tmp/daily_report.txt /usr/local/bin/workbuddy run --task daily_report --output $REPORT_FILE # 后面推送时统一用 $REPORT_FILE这种“路径不一致”的坑本质上是配置散落在多个地方导致的。能用一个变量管住的东西就别写两遍。6.2 周末的日报没人看但还在跑跑了几天之后我发现周末的日报基本没人看但任务还在照常跑白白消耗资源。解法是在 cron 里加一个判断或者直接在脚本开头判断星期几DAY_OF_WEEK$(date %u) if [ $DAY_OF_WEEK -ge 6 ]; then echo 周末不生成日报 exit 0 fidate %u返回 1 到 76 和 7 就是周六周日。这个判断加上之后周末就清净了。6.3 推送偶尔失败但没人知道企业微信的 Webhook 偶尔会因为网络抖动失败如果不做处理那天的日报就静默丢失了。我的做法是加一次重试for i in 1 2 3; do curl -s -X POST $WEBHOOK_URL -H Content-Type: application/json -d $PAYLOAD if [ $? -eq 0 ]; then break fi sleep 5 done失败后等 5 秒重试最多三次。实测下来加了重试之后日报的到达率基本是 100%。6.4 日报内容越来越水跑了一个月之后我发现日报开始出现“今天没有重要更新”这种敷衍内容。排查下来是关键词列表太久没更新采集回来的东西越来越同质化。解法是每个月花十分钟review一下关键词把不再关注的删掉把新关注的加上。这件事没有技术含量但很关键。自动化系统最怕的不是技术故障而是内容腐化——它还在跑但跑出来的东西已经没人看了。7. 这套方案还能怎么扩展7.1 把“日报”扩展成“多时段简报”十点半的日报跑顺之后我顺手加了两个时段中午十二点半的“午间速览”和下午六点的“收工总结”。三个时段共用同一套采集和加工逻辑只是推送时间和内容侧重不同。午间侧重“上午有什么新动态”收工侧重“今天还有什么没做完”。实现上就是把同一个脚本复制三份改一下 cron 时间和任务参数。成本很低但信息覆盖的密度上来了。7.2 把“单向推送”扩展成“可追问”如果你确实需要双向能力可以在企业微信里配置一个能接收消息的应用把用户回复转发给 WorkBuddy 处理再把结果推回去。这条路我试过技术上可行但配置复杂度比单向推送高不少适合有明确追问需求的人。7.3 把“信息日报”扩展成“任务日报”日报的内容不一定是信息也可以是任务状态。比如把待办清单、项目进度、代码提交记录这些数据接进来生成一份“工作日报”。思路完全一样只是数据源换了。关键词里提到的“自动化测试”“接口自动化”这些场景其实都可以套用这套“定时采集 AI 加工 微信推送”的框架。8. 我个人的几条实操心得第一先把链路跑通再优化细节。我一开始想一步到位结果卡在格式美化上半天。后来改成“先让日报能发出来哪怕丑一点”跑通之后再慢慢调格式效率高很多。第二日志一定要留。自动化系统出问题是必然的没有日志你连从哪查都不知道。我的脚本里每个关键步骤都会往日志里写一行出问题的时候直接tail -f看日志五分钟定位。第三别追求全自动留个人工兜底。我的日报推送失败时会给我发一条“日报生成失败”的告警这样我至少知道今天要手动看一眼。全自动系统最怕的就是“静默失败”你以为它在跑其实早就挂了。第四定期 review 内容质量。技术上的稳定不代表内容上的有用。我每个月会翻一遍历史日报看看哪些内容我从来没点开过然后据此调整采集范围和加工指令。这套动作花不了多少时间但能让日报一直保持“值得看”的状态。最后分享一个小技巧如果你不确定自己的指令写得对不对可以先用 WorkBuddy 手动跑一次把输出结果和你的预期对比一下差在哪就补哪。手动跑通之后再挂定时成功率会高很多。这套“十点半日报”我从最初的手忙脚乱到现在基本不用管前后大概调了两周现在它已经成了我每天开工的第一个动作。