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 定时任务没触发的排查思路

某天早上没收到日报，先别慌，按这个顺序排查：

1. 查调度日志，确认任务有没有被触发
2. 如果触发了但没推送，查推送日志，看是哪一步断了
3. 如果没触发，查调度服务本身是否正常运行
4. 如果调度服务正常但没触发，查时间配置和时区

这个顺序是从“结果”往“原因”倒推，能最快定位问题。我遇到过一次任务没触发，查到最后发现是运行环境重启了，调度服务没设成开机自启。这个坑提醒我：任何依赖常驻服务的方案，都要考虑服务重启后的恢复问题。

提示：给调度服务设一个“心跳检查”，每隔一段时间确认它还活着。发现挂了就自动拉起，或者至少发个告警。别等到没收到日报才发现服务挂了。

5.4 让日报更“懂你”的进阶技巧

基础版跑通之后，可以做一些进阶优化，让日报更贴合你的个人习惯。

第一个技巧是加入反馈闭环。我在日报末尾加了一行“回复 1 表示今日日报有用，回复 2 表示需要调整”。虽然我很少真的回复，但这个设计逼着我去思考日报的质量。你也可以做得更轻量，就是每天收到后自己心里打个分，连续几天低分就说明该调规则了。

第二个技巧是按星期做差异化。周一适合多放点“本周计划”，周五适合多放点“本周总结”。这个通过在提示词里加一个“今天是星期几”的变量就能实现，成本很低，效果不错。

第三个技巧是历史对比。让 AI 在生成今日待办时，参考昨天的待办完成情况，这样日报就有了连续性，不是每天孤立的一份。这个需要把昨天的日报存下来，作为今天的输入之一。

6. 关于这套方案的一些个人体会

这套东西我从搭起来到现在跑了几个月，中间调过好几次规则，也修过几次故障。最大的体会是：自动化方案的价值不在于“全自动”，而在于“把人的注意力解放出来”。我每天花在整理信息上的时间，从原来的半小时降到了几乎为零，这半小时拿去做真正需要思考的事，回报远超过搭建成本。

另一个体会是，规则要跟着需求走，不要一次定死。我最初的规则和现在的规则已经差了很多，因为用着用着就发现哪些约束是必要的、哪些是多余的。所以别怕改，规则就是用来迭代的。

最后分享一个小技巧：如果你觉得每天一份日报太频繁，可以改成工作日推送、周末停推。实现方式就是在定时触发器里加一个“仅工作日触发”的条件。这个改动很小，但能让方案更贴合真实的工作节奏，不至于周末还被工作信息打扰。