1. 为什么我要给 WorkBuddy 装一个十点半闹钟每天早上到工位第一件事不是泡咖啡而是打开几个固定的信息源把昨天夜里到今早发生的行业动态、项目进展、待办提醒过一遍。这件事本身不复杂但极其消耗注意力和时间——你会在各种页面之间来回切换被无关信息打断等回过神来半小时已经没了。我试过用收藏夹、用待读清单、用各种聚合工具最后发现真正的问题不在于信息在哪而在于我什么时候被提醒去看。WorkBuddy 这类 AI 助手工具的价值恰恰在于它能把主动去查变成被动接收。你不需要记得去问它它到点自己把整理好的内容推给你。所以我给自己定了一个很朴素的目标每天上午十点半一份由 AI 生成的日报自动出现在我的微信里。十点半这个时间点是刻意选的——早会基本结束手头第一波紧急事项处理完正好需要一个今天该关注什么的锚点。这篇内容适合三类人看一是已经在用 WorkBuddy 或类似 AI 助手但还停留在手动问答阶段的人二是想把 AI 能力接进微信这种日常高频入口的开发者或重度用户三是对定时任务 AI 生成 消息推送这条链路感兴趣、想自己搭一套的人。我会把整条链路的选型逻辑、关键步骤、踩过的坑和实测细节都摊开讲不藏私。需要先说明一点下面涉及的具体接口、字段名、配置项部分是基于常见实践的合理还原因为不同版本的 WorkBuddy 和微信生态接口会有差异。你在复现时以自己环境的实际文档为准但思路和排查方法是可以直接迁移的。2. 拆解这条自动化链路四个环节缺一不可2.1 从触发到送达的完整路径任何一条定时把 AI 内容推到微信的链路本质上都可以拆成四段定时触发 → 数据采集与整理 → AI 生成日报 → 消息推送到微信。这四段里任何一段断了整条链路就是死的。很多人一上来就研究怎么调 AI 接口结果发现真正卡住自己的是定时任务在服务器上跑不起来或者微信这边收不到消息。我先把这四段各自的职责和常见实现方式列清楚后面再逐段展开。环节职责常见实现最容易出问题的地方定时触发到点唤醒整个流程系统定时任务、云函数定时触发器、常驻进程内的调度器时区不对、进程被回收、任务重叠执行数据采集拿到当天要总结的原始素材接口拉取、RSS、本地文件、数据库查询数据源鉴权失效、返回为空、格式突变AI 生成把素材整理成可读日报调用大模型接口带提示词模板超时、token 超限、输出格式不稳定消息推送把结果送到微信微信生态内的消息通道、机器人 webhook频率限制、消息长度截断、鉴权过期这张表建议你直接存下来后面任何一环出问题先对照它定位比盲目翻日志快得多。2.2 为什么选十点半而不是早上八点时间点的选择不是拍脑袋。早上八点推送你大概率还在通勤或刚坐下消息会被淹没在未读里太晚比如中午又失去了指导当天工作的意义。十点半是一个注意力窗口早上的紧急沟通告一段落人还没进入深度工作状态这时候一条结构清晰的日报能真正被读进去。另外一个现实考虑是数据新鲜度。很多信息源在早上八点前还没更新完你八点推的日报其实是昨天的残渣。十点半推夜里到上午的新内容基本都进来了日报的信息密度明显更高。这个细节看起来小但直接决定了你愿不愿意每天真的去看它。2.3 微信作为收件箱的合理性为什么是微信而不是邮件、不是钉钉、不是某个专门的应用因为微信是你打开频率最高、最不需要额外动作的入口。邮件要专门去开专门的应用要专门去点而微信你本来就在用。把日报塞进一个你已经在高频使用的通道里是降低阅读摩擦最有效的办法。但微信生态有个特点它对主动推送的限制比较严。你不能随便给用户发消息必须走它认可的通道。所以推送方案的选择直接决定了这条链路能不能长期稳定跑下去。这一点我在第 4 节会重点讲。3. 定时触发与数据采集链路的地基怎么打3.1 定时任务的三种落地方式与取舍定时触发看起来最简单其实坑最多。我按部署成本从低到高说三种方式。第一种本地机器的系统定时任务。比如在 Mac 上用launchd在 Linux 上用cron。优点是零成本、配置直观缺点是机器必须开着休眠或关机就断。我一开始就是这么干的结果周末电脑一关周一发现日报缺了两天。如果你只是自己用、机器常年不关这种方式完全够。第二种云函数定时触发器。各大云平台都提供定时触发能力你写一个函数配一个 cron 表达式到点自动执行。优点是稳定、不依赖你的机器缺点是有冷启动延迟且函数执行时长通常有限制如果 AI 生成比较慢可能超时。第三种常驻进程内的调度器。比如用 Python 的APScheduler或 Node 的node-cron跑在一个长期运行的服务里。优点是灵活、可控、能处理复杂逻辑缺点是你得有个地方让它一直跑着。我最终选的是第二种和第三种结合核心逻辑放在一个常驻服务里用云端的定时触发器每天唤醒一次。这样既稳定又保留了处理复杂逻辑的空间。cron 表达式这里要特别小心。以每天上午十点半为例标准五段式是30 10 * * *但如果你用的是某些云平台它可能要求六段式多一个秒位或者要求指定时区。我踩过的坑是服务器默认时区是 UTC我配了30 10 * * *结果推送时间是北京时间下午六点半。排查了半天才反应过来是时区问题。所以配完定时任务第一件事是确认服务器时区或者直接在表达式里显式指定。# 查看服务器当前时区 timedatectl # 如果不对设置为东八区 sudo timedatectl set-timezone Asia/Shanghai3.2 数据采集先想清楚日报里到底要有什么很多人卡在这一步是因为没想清楚日报的内容边界。你不可能把所有信息都塞进去那样日报会变成信息垃圾场。我的做法是先列一个最小可用清单今天必须知道的 3 到 5 件事。超出这个范围的一律不进日报。采集方式上我主要用两类接口拉取对于有开放接口的数据源直接调接口拿结构化数据。这种方式最稳但要注意鉴权 token 会过期得做自动刷新或失败重试。本地文件/数据库查询对于自己产生的数据比如待办、笔记、项目进度直接从本地读。这种方式没有网络依赖最可靠。采集环节有个经验永远对空结果做兜底。如果某天数据源挂了、返回为空你的日报不能因此变成一片空白或者报错。我的处理是如果采集到的素材少于阈值就在日报里明确写今日数据源异常以下为部分内容而不是硬凑或者直接失败。这样你至少知道链路哪一环出了问题。3.3 素材预处理别把原始数据直接丢给 AI采集到的原始数据通常是脏的有重复、有格式混乱、有无关字段。直接丢给 AI它会浪费大量 token 在理解噪音上输出质量也会下降。所以中间要加一层预处理。我的预处理做了三件事去重、截断、结构化。去重是把重复条目合并截断是给每条内容设一个长度上限避免单条超长内容挤占整个上下文结构化是把不同来源的数据统一成同一种格式比如都转成{标题, 摘要, 来源, 时间}这样的对象。# 预处理示例统一格式 去重 截断 def preprocess(raw_items, max_len200): seen set() cleaned [] for item in raw_items: key item.get(title, ).strip() if not key or key in seen: continue seen.add(key) cleaned.append({ title: key, summary: item.get(summary, )[:max_len], source: item.get(source, unknown), time: item.get(time, ) }) return cleaned这段代码不复杂但它决定了后面 AI 生成的质量上限。垃圾进垃圾出这句话在 AI 日报场景里体现得淋漓尽致。4. 让 AI 写出像人写的日报提示词与输出控制4.1 提示词模板的四个必备部分AI 生成日报成败几乎全在提示词。我试过很多版本最后稳定下来的模板包含四个部分角色设定、任务说明、输出格式、约束条件。角色设定是告诉模型你是谁比如你是一名资深的行业分析师擅长把零散信息整理成简洁的每日简报。任务说明是明确要做什么比如根据以下素材生成一份不超过 500 字的日报。输出格式是规定长什么样比如分几个板块、每个板块几条。约束条件是划红线比如不要编造素材中没有的信息不要使用夸张的营销词汇。这里有个反直觉的点约束条件比任务说明更重要。因为模型天生倾向于多说你不明确限制它就会把日报写成一篇冗长的分析文章。我最早版本的日报动辄上千字读起来累后来加了字数上限和每条不超过两句话的约束可读性立刻上来了。4.2 输出格式不稳定的三种应对即使提示词写得很清楚模型的输出格式仍然可能飘。今天用 markdown 列表明天变成纯段落后天多出一堆前言后语。这在自动化场景里是致命的因为你的推送环节可能依赖固定格式来解析。我的应对分三层第一层在提示词里给示例。直接给一个理想输出的样例模型模仿能力很强有样例比纯文字描述有效得多。第二层代码侧做容错解析。不要假设输出一定符合格式用正则或分段逻辑去提取关键内容提取不到就用原文兜底。第三层加一个格式校验步骤。生成后检查是否包含必需的板块标题缺了就重试一次或者降级为纯文本推送。# 简单的格式校验与降级 def validate_report(text): required_sections [今日要点, 值得关注] for sec in required_sections: if sec not in text: return None # 触发重试或降级 return text4.3 控制生成耗时超时是自动化最大的敌人AI 生成是整条链路里最慢的一环。如果模型响应慢加上网络波动很容易超过定时任务的执行时限。我遇到过好几次任务跑了但日报没推出来最后发现是生成超时被中断了。处理办法有三个设合理超时、做重试、准备降级内容。超时不要设太短给模型留足时间但也不能无限等。重试要限制次数避免雪崩。降级内容就是如果 AI 生成失败至少推一条今日日报生成失败请检查链路的提示让你知道出了问题而不是默默什么都没发生。提示生成环节建议单独打日志记录每次的耗时和 token 用量。跑一段时间后你会发现规律比如某些时段模型响应明显变慢据此调整触发时间能显著提升成功率。5. 把日报送进微信推送通道的选择与避坑5.1 微信生态里可用的推送方式对比这是整条链路里最需要谨慎的部分因为微信对主动推送管得很严。我调研和实践过的几种方式对比如下方式适用场景优点限制微信内机器人 webhook群聊/个人接收配置简单、即时有频率限制、消息格式受限服务号模板消息面向关注用户稳定、可长期需要认证、有推送额度小程序订阅消息用户主动订阅后合规、体验好需用户逐次授权文件传输助手类通道个人自用无需额外配置依赖客户端在线对于自己给自己推日报这种个人场景最省事的是走微信内的机器人 webhook 或文件传输助手类通道。但要注意这类通道通常有消息长度限制日报太长会被截断。我的做法是把日报控制在合理长度内如果确实超长就只推摘要完整内容存到本地或云端日报里附一个说明。5.2 消息格式让日报在微信里好看微信里的消息渲染能力和网页不一样markdown 支持有限。我试过直接推 markdown结果一堆符号原样显示很难看。后来改成纯文本 简单符号排版可读性反而更好。具体做法用空行分隔板块用短横线或数字做列表用方括号或书名号突出标题。不要用复杂的表格和嵌套列表微信里显示会乱。下面是一个实测效果不错的格式【今日日报】2024-XX-XX 一、今日要点 1. 第一条内容一句话说清 2. 第二条内容一句话说清 二、值得关注 - 某事项有新进展 - 某数据出现异常 三、明日提醒 - 记得处理某件事这种格式在手机和电脑微信上都能正常显示不会出现符号错乱。5.3 鉴权与频率两个最容易让链路猝死的点鉴权过期是隐形杀手。很多推送通道的凭证有有效期过期后推送会静默失败——你以为发出去了其实对方根本没收到。我的做法是每次推送后检查返回状态如果返回鉴权错误立刻告警而不是等你自己发现日报没来。频率限制也要注意。如果你不小心把定时任务配成了每分钟执行或者重试逻辑写得太激进很容易触发限流导致账号被临时限制。定时任务一定要做幂等和去重确保同一天不会重复推送。# 推送前检查今天是否已推送过避免重复 def should_push_today(record_file): today datetime.now().strftime(%Y-%m-%d) if os.path.exists(record_file): with open(record_file) as f: if today in f.read(): return False return True6. 实测中踩过的坑与排查链路6.1 日报没来的完整排查顺序链路跑起来之后最常遇到的问题就是今天日报没来。这时候不要慌按固定顺序排查比乱翻日志高效得多。我的排查顺序是先看定时任务有没有触发。查调度器日志或云函数的执行记录确认任务是否被唤醒。如果没触发问题在定时配置时区、表达式、服务是否在运行。再看数据采集有没有成功。如果任务触发了但没产出看采集环节的日志是不是数据源鉴权失败或返回为空。然后看 AI 生成有没有完成。检查生成耗时和返回内容是不是超时或被中断。最后看推送有没有成功。检查推送接口的返回状态是不是鉴权过期或触发限流。这个顺序是从链路前端往后端走能最快定位到断点。我踩过最冤的一次是任务触发了、数据采集了、AI 也生成了结果推送环节因为凭证过期静默失败白白排查了半天前面几环。6.2 时区、编码、换行符三个看不见的坑这三个问题都属于看起来没问题实际处处是问题的类型。时区前面说过了服务器 UTC 和本地时间不一致会导致推送时间完全错位。编码问题常见于中文内容如果采集或生成环节编码处理不当日报里会出现乱码。换行符在跨平台时尤其烦人Windows 的\r\n和 Linux 的\n混用可能导致消息在微信里显示成一大坨。# 统一换行符和编码 text text.replace(\r\n, \n).replace(\r, \n) text text.encode(utf-8, errorsignore).decode(utf-8)这几行代码看着不起眼但能省掉你大量为什么显示不对的困惑。6.3 内容质量的持续调优链路跑通只是第一步日报好不好看、有没有用才是长期价值所在。我调优的做法是每周回看一次历史日报标记哪些内容我真正读了、哪些直接跳过。然后据此调整提示词里的板块权重和素材来源。比如我一开始放了很多行业新闻后来发现自己几乎不看就把它降级成了可选项把项目待办和数据异常提到前面。日报是给自己看的它的价值不由生成得多漂亮决定而由你愿不愿意每天读决定。7. 关于这套方案的一些个人体会这套十点半闹钟我跑了挺长一段时间最大的感受是自动化的价值不在于省了多少操作而在于它帮你建立了一个稳定的节奏。以前我是想起来才看现在是每天固定时间被提醒信息摄入从随机变成了规律整个人的工作状态都不一样。如果你也想搭一套我的建议是先跑通最小链路再逐步加功能。不要一上来就追求完美的日报格式、丰富的素材来源、漂亮的排版。先用最简单的定时任务 一次 AI 调用 一条微信推送把链路跑通确认每天能收到东西然后再一点点优化。我见过太多人卡在设计完美方案阶段最后什么都没跑起来。另外**给链路加一个心跳**很重要。哪怕某天没有内容可推也推一条今日无重要更新的提示。这样你至少知道系统还活着而不是在没消息和系统挂了之间猜来猜去。这个习惯能帮你及早发现链路故障避免某天突然发现已经断了一周。最后分享一个小技巧把日报的生成结果同时存一份到本地文件。微信里的消息会被刷走但本地文件可以随时回看、搜索、做周度月度回顾。我现在每个月会翻一次这个月的日报存档很多当时没在意的信息回头看会发现规律。这个附加价值是当初搭这套系统时完全没想到的。