1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事是打开各种信息源项目群消息、待办清单、行业动态、昨天没跑完的自动化任务日志。信息是散的人是懵的等我把这些捋清楚往往已经十一点了。这个状态持续了挺长一段时间直到我把 WorkBuddy 用起来才意识到一个问题工具本身不产生价值工具被“定时触发”才产生价值。WorkBuddy 这类 AI 助手很多人装完就放在那儿想起来才问一句本质上还是“手动挡”。我想要的是一台“自动挡”的车——每天上午十点半它自己把该汇总的汇总好、该提醒的提醒到位然后通过微信推给我。我不用主动去问信息自己找上门。这就是标题里说的“设了个闹钟”的真实含义不是给手机设闹钟而是给一个 AI 工作流设一个定时触发器。这件事解决的核心痛点有三个。第一是信息聚合的时机问题早上刚上班注意力最宝贵不该浪费在“找信息”上第二是执行的一致性人会有惰性今天忙就不整理了AI 不会第三是触达渠道的顺手程度微信是绝大多数人一天打开次数最多的应用把日报送进微信等于把信息放到了你必然会看到的地方。适合谁来参考这套方案我梳理了一下大概是这几类人每天需要处理多源信息的知识工作者、带小团队的负责人、做自动化测试或运维的工程师、以及任何想用 AI Agent 把重复性信息整理工作“外包”出去的人。不需要你会写复杂代码但需要你愿意花一两个小时把流程搭起来。搭完之后它每天替你干活这笔时间投资非常划算。下面我把整套东西拆开讲从设计思路到落地细节再到踩过的坑尽量让你看完就能照着复现。2. 整体方案设计与选型思路拆解2.1 为什么是“定时触发 AI 汇总 微信推送”这条链路先讲清楚这条链路的三个环节各自承担什么角色。定时触发是发动机负责在固定时间点把整个流程点着AI 汇总是大脑负责把原始、零散、格式不一的信息加工成一份人能直接读的日报微信推送是最后一公里负责把成品送到你眼前。我对比过几种替代方案。方案 A 是纯手动每天自己整理优点是灵活缺点是坚持不下来。方案 B 是纯脚本写个 Python 脚本定时抓数据、拼字符串、发邮件优点是稳定缺点是格式死板遇到非结构化信息就歇菜。方案 C 就是我现在用的脚本负责“取数和触发”AI 负责“理解和成文”推送负责“送达”。三者各干各擅长的事这是它比纯脚本强的地方——AI 能处理“昨天项目群里讨论的三个风险点”这种没法用正则提取的内容。选这条链路还有一个现实考量每一环都有成熟的、低门槛的实现方式。定时触发用系统自带的任务计划或者轻量调度就够AI 汇总走 API 调用微信推送用现成的消息通道。不需要自己造轮子把精力放在“日报该包含什么”这个真正有价值的问题上。2.2 WorkBuddy 在这套流程里扮演什么角色很多人会把 WorkBuddy 和普通的聊天式 AI 混为一谈其实差别很大。普通聊天 AI 是你问一句它答一句会话结束就断了。WorkBuddy 这类工具的核心能力在于它可以被配置规则、被赋予技能Skill、被外部触发。热词里出现的“workbuddy skill”“给 workbuddy 定几条规则后续对所有任务都生效”说的就是这个特性。在我的方案里WorkBuddy 承担的是“汇总大脑”这个角色。我给它预设了几条规则日报必须分板块、每个板块不超过五条、风险项要标红提示、语言要简洁不要客套话。这些规则一旦设定后续每天触发时都自动生效我不需要每天重新交代一遍。这就是“定规则”的价值——把一次性的偏好变成长期的行为约束。需要说明的是WorkBuddy 有不同版本和形态具体用哪个版本、怎么接入取决于你手头的环境。我下面讲的是通用思路你在落地时按自己实际可用的工具形态做替换即可。核心逻辑不变一个能被规则约束、能被外部调用的 AI 处理单元。2.3 十点半这个时间点是怎么定下来的时间点的选择不是拍脑袋。我观察了自己两周的工作节奏发现九点到十点这段时间通常在处理紧急消息和晨会十点之后才进入相对稳定的工作状态。如果把日报推到九点它会被淹没在晨会消息里推到十一点又太晚了上午的计划已经开始了。十点半是一个“信息已经产生、决策还没开始”的窗口。昨天的任务日志已经落库今天的待办还没排这时候一份日报进来正好用来做当天的优先级判断。当然你的节奏可能不一样这个时间点完全可以调关键是找到你自己那个“信息齐了但还没开始忙”的缝隙。提示定时任务的时间不要设在整点。整点是各种系统任务、备份、同步的高峰期容易撞车导致延迟。十点半这种“半点”时间反而更稳。3. 核心细节解析与实操要点3.1 日报内容板块的设计原则一份没人看的日报等于没发。我见过太多自动生成的日报把一堆原始数据堆上去看着很全实际没人读。所以板块设计的第一原则是每个板块回答一个具体问题。我最终定下来的板块是这样的板块回答的问题数据来源昨日进展昨天实际完成了什么任务系统、提交记录今日待办今天该优先做什么待办清单、日历风险提醒有什么可能出问题项目群、监控告警行业动态外部有什么值得关注订阅源、资讯接口四个板块每个都对应一个真实的决策需求。进展板块让你知道“进度到哪了”待办板块让你知道“接下来干嘛”风险板块让你“提前避坑”动态板块让你“不脱节”。多一个板块都是负担少一个就有信息盲区。这里有个细节板块顺序不能乱。必须按“回顾—计划—预警—外部”的顺序来。因为人的阅读是线性的先看昨天再看今天逻辑才顺。如果把风险提醒放最前面一打开就是坏消息体验很差。3.2 给 WorkBuddy 定规则的正确姿势规则写得好不好直接决定日报能不能用。我一开始写的规则很笼统比如“写得简洁一点”结果 AI 理解不了什么叫简洁生成的东西还是又臭又长。后来我改成可量化、可判断的规则效果立刻不一样。我现在的规则大致是这么几条每个板块的条目数量控制在 3 到 5 条超过 5 条必须合并同类项每条不超过 40 个字超过就拆成两条或者删掉修饰词风险项必须用“风险”开头方便我一眼扫到禁止使用“据悉”“值得一提的是”“综上所述”这类填充词如果某个板块当天没有内容直接写“无”不要硬凑这几条规则的关键在于可执行。“简洁”不可执行“每条不超过 40 字”可执行。“突出重点”不可执行“风险项用特定前缀”可执行。你给 AI 定规则的时候一定要问自己这条规则能不能用一个是非判断来检验能才是好规则。注意规则不要一次定太多。我建议先定 3 条最核心的跑几天看效果再逐步加。一次性堆十几条规则AI 容易顾此失彼而且你也不好判断是哪条规则起了作用。3.3 微信推送通道的选择与配置要点推送通道这块选择其实不少但核心诉求就一个稳定送达且我能第一时间看到。微信生态里能实现自动推送的方式有好几种我选的是最贴合个人使用习惯的那种配置过程不复杂但有几个坑要提前说。第一个坑是消息长度限制。微信消息通道对单条消息的长度是有上限的日报如果太长会被截断。我的处理办法是在 AI 汇总阶段就控制总长度把日报压到 800 字以内。如果确实内容多就拆成两条发第一条是摘要第二条是详情。第二个坑是推送频率。有些通道对推送频率有限制短时间内发太多条会被限流。所以我把整个流程设计成“一天只推一次”绝不滥用。日报就是日报不是实时告警没必要高频推送。第三个坑是格式兼容。微信里对 Markdown 的支持有限加粗、表格这些不一定能正常显示。我的做法是推送时用纯文本加简单符号比如用“【】”代替加粗用“-”代替列表符号。牺牲一点美观换取 100% 的可读性这笔账划算。3.4 数据源的接入方式与清洗日报的质量七分靠数据源三分靠 AI 加工。数据源接得不好AI 再强也是“垃圾进垃圾出”。我把数据源分成两类来处理。一类是结构化数据比如任务系统的完成记录、代码仓库的提交日志。这类数据格式规整直接用接口拉取简单清洗一下就能用。清洗的重点是去重和排序——同一条记录可能被拉取多次按时间倒序排一下取最近的几条。另一类是非结构化数据比如项目群里的讨论、邮件里的反馈。这类数据没法用规则提取正好交给 AI 处理。我的做法是把原始文本整段喂给 AI让它自己判断哪些是风险、哪些是进展。这里要注意控制输入长度太长的文本会稀释 AI 的注意力我一般会先做个粗筛只把最近 24 小时的内容送进去。两类数据在 AI 汇总阶段会合流AI 的任务是把它们揉成一份连贯的日报。这一步的提示词设计很关键我后面单独讲。4. 实操过程与核心环节实现4.1 环境准备与依赖梳理动手之前先把需要的东西列清楚。我按“必须有”和“可选有”分了一下必须有一个能跑定时任务的运行环境本地机器、服务器都行WorkBuddy 或同类 AI 处理单元的可用接口一个微信消息推送通道各数据源的访问凭证可选有一个日志记录工具方便排查问题一个简单的配置文件把规则和参数外置环境准备阶段最容易忽略的是时区问题。如果你的运行环境和你的实际所在地时区不一致定时任务会在错误的时间触发。我踩过这个坑任务设的是十点半结果因为服务器是 UTC 时间实际推送变成了下午六点半。解决办法很简单在配置里显式指定时区别依赖系统默认值。4.2 定时触发器的配置定时触发器的配置核心就三个参数触发时间、触发频率、失败重试策略。触发时间设成每天上午十点半这个前面讲过。触发频率是每天一次不要设成多次日报一天一份就够了。失败重试策略是我强烈建议加的如果第一次触发因为网络问题失败了隔五分钟重试一次最多重试三次。没有重试机制的话某天网络抖一下你那天就没日报了。配置示例以常见的任务调度配置为例具体语法按你的环境调整schedule: trigger_time: 10:30 timezone: Asia/Shanghai frequency: daily retry: max_attempts: 3 interval_seconds: 300这里timezone一定要显式写retry的间隔不要设太短五分钟是个比较稳妥的值。设太短容易在对方服务还没恢复时就重试白白浪费次数。4.3 AI 汇总环节的提示词设计这是整个流程里最需要打磨的一环。提示词写得好日报质量高一个档次。我的提示词结构是这样的你是一个日报生成助手。请根据以下原始数据生成一份工作日报。 规则 1. 分为四个板块昨日进展、今日待办、风险提醒、行业动态 2. 每个板块 3-5 条每条不超过 40 字 3. 风险项以风险开头 4. 禁止使用填充词 5. 无内容的板块写无 原始数据 {这里填入当天抓取的数据}这个提示词有几个设计要点。第一规则前置让 AI 先看到约束再处理数据比先给数据再给规则效果好。第二用编号列规则AI 对编号列表的遵循度比段落描述高。第三留一个数据占位符方便程序动态填充。我实测下来这套提示词生成的日报可用率在 90% 以上。剩下 10% 的问题主要是数据源本身有噪声比如抓到了无关的群消息这个靠优化数据源解决不是提示词的问题。4.4 微信推送的完整实现推送环节我拆成三步组装消息、调用推送接口、确认送达。组装消息时我会在日报前面加一个标题行格式是“【工作日报】X月X日”让消息在微信列表里一眼可辨。正文就是 AI 生成的四个板块。最后加一行“—— 由 WorkBuddy 自动生成”既是说明来源也方便我日后回溯。调用推送接口的代码逻辑很简单核心是错误处理。推送失败的原因可能是网络、可能是凭证过期、可能是内容超长。我针对每种情况都做了判断网络问题就重试凭证问题就告警内容超长就截断后重发。def push_to_wechat(content): if len(content) MAX_LENGTH: content content[:MAX_LENGTH] ...(内容过长已截断) try: response send_message(content) if response.status_code 200: log(推送成功) return True else: log(f推送失败状态码{response.status_code}) return False except Exception as e: log(f推送异常{e}) return False确认送达这一步很多人会省掉但我建议保留。做法很简单推送成功后写一条日志记录推送时间和内容摘要。这样如果哪天你没收到日报可以查日志确认是“没推送”还是“推送了但你没看到”排查方向完全不同。4.5 全流程串联与首次运行验证把四个环节串起来之后不要直接等第二天十点半先手动触发一次做验证。验证的时候重点看三件事数据抓全了没有、AI 汇总的格式对不对、微信收到没有。我第一次跑的时候数据抓取环节漏了一个源导致“行业动态”板块是空的。这个问题在手动验证时一眼就看出来了如果直接等自动触发可能要好几天才发现。所以首次运行一定要手动触发并且逐环节检查。验证通过后把定时任务正式启用。启用后的头三天每天收到日报后花一分钟检查一下质量有问题及时调规则。三天之后基本就稳定了可以放手让它自己跑。5. 常见问题与排查技巧实录5.1 日报内容质量问题排查日报最常见的质量问题是“内容空洞”和“格式跑偏”。内容空洞通常是数据源的问题抓到的都是些无关紧要的信息AI 巧妇难为无米之炊。排查方法是把喂给 AI 的原始数据打印出来看一眼如果原始数据本身就没什么价值那问题在数据源不在 AI。格式跑偏则是提示词的问题。比如 AI 没有按四个板块来分或者条目数量超了。这种情况我一般会做两件事一是把规则写得更具体二是给一个示例。AI 对示例的模仿能力很强给一个标准格式的样例比写十条规则都管用。问题现象可能原因排查方向内容空洞数据源质量差检查原始数据格式跑偏提示词不够具体补充规则或示例条目过多数量约束没生效强化数量规则出现填充词禁用词列表不全补充禁用词5.2 推送失败的典型场景推送失败我遇到过三种典型场景。第一种是凭证过期这个最隐蔽因为程序不会报错只是推送接口返回一个失败状态。解决办法是定期检查凭证有效期快到期时提前更新。第二种是内容超长前面提过微信通道有长度限制。我的处理是在推送前先判断长度超了就截断。截断的位置要选好别把一句话截一半我一般按段落截保证语义完整。第三种是频率限流短时间内推送太多次会被限制。这个靠“一天只推一次”的设计天然规避了。如果你确实需要多次推送那就要在推送逻辑里加个间隔判断两次推送之间至少隔几分钟。5.3 定时任务没触发的排查思路某天早上没收到日报先别慌按这个顺序排查查调度日志确认任务有没有被触发如果触发了但没推送查推送日志看是哪一步断了如果没触发查调度服务本身是否正常运行如果调度服务正常但没触发查时间配置和时区这个顺序是从“结果”往“原因”倒推能最快定位问题。我遇到过一次任务没触发查到最后发现是运行环境重启了调度服务没设成开机自启。这个坑提醒我任何依赖常驻服务的方案都要考虑服务重启后的恢复问题。提示给调度服务设一个“心跳检查”每隔一段时间确认它还活着。发现挂了就自动拉起或者至少发个告警。别等到没收到日报才发现服务挂了。5.4 让日报更“懂你”的进阶技巧基础版跑通之后可以做一些进阶优化让日报更贴合你的个人习惯。第一个技巧是加入反馈闭环。我在日报末尾加了一行“回复 1 表示今日日报有用回复 2 表示需要调整”。虽然我很少真的回复但这个设计逼着我去思考日报的质量。你也可以做得更轻量就是每天收到后自己心里打个分连续几天低分就说明该调规则了。第二个技巧是按星期做差异化。周一适合多放点“本周计划”周五适合多放点“本周总结”。这个通过在提示词里加一个“今天是星期几”的变量就能实现成本很低效果不错。第三个技巧是历史对比。让 AI 在生成今日待办时参考昨天的待办完成情况这样日报就有了连续性不是每天孤立的一份。这个需要把昨天的日报存下来作为今天的输入之一。6. 关于这套方案的一些个人体会这套东西我从搭起来到现在跑了几个月中间调过好几次规则也修过几次故障。最大的体会是自动化方案的价值不在于“全自动”而在于“把人的注意力解放出来”。我每天花在整理信息上的时间从原来的半小时降到了几乎为零这半小时拿去做真正需要思考的事回报远超过搭建成本。另一个体会是规则要跟着需求走不要一次定死。我最初的规则和现在的规则已经差了很多因为用着用着就发现哪些约束是必要的、哪些是多余的。所以别怕改规则就是用来迭代的。最后分享一个小技巧如果你觉得每天一份日报太频繁可以改成工作日推送、周末停推。实现方式就是在定时触发器里加一个“仅工作日触发”的条件。这个改动很小但能让方案更贴合真实的工作节奏不至于周末还被工作信息打扰。