1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位泡好咖啡坐下来第一件事不是打开编辑器而是先花十几分钟翻各种信息源昨天项目里谁提交了什么、有没有新的 issue 被提上来、行业里又出了什么值得关注的东西。这件事本身不复杂但极其消耗注意力和时间而且一旦忙起来就很容易忘。我试过用日历提醒、用待办清单最后都因为“提醒了还得手动去查”而放弃。后来我把这套流程整个交给了 WorkBuddy让它每天上午十点半自动生成一份 AI 日报直接推送到微信。整个过程不需要我打开任何后台不需要手动触发到点就有一份整理好的内容躺在微信里。这篇文章就是把这套方案从头到尾拆开讲清楚为什么这么设计、每个环节怎么落地、参数怎么选、踩过哪些坑以及你如果想复现具体该怎么做。先明确一下这套东西适合谁。如果你每天需要处理大量碎片信息、有固定的信息收集习惯、又不想被“手动整理”这件事绑住那这套方案基本可以直接抄。如果你只是想偶尔看看 AI 新闻那可能没必要上自动化手动刷一刷就够了。核心判断标准是这件事你是否每天都要做且重复度极高。只要满足这两点自动化就是划算的。WorkBuddy 在这里扮演的角色是一个可以接受自定义指令、按计划执行任务的工作台。你可以把它理解成一个“听得懂人话的定时任务执行器”——你告诉它每天几点做什么它就按时去做做完把结果送到你指定的地方。AI 日报只是其中一个用法同样的思路可以套用到周报汇总、数据巡检、内容监控等场景。2. 整体方案设计与核心思路拆解2.1 为什么选“定时触发 微信推送”这条链路自动化方案有很多种形态最常见的是“事件触发”比如有新提交就通知和“定时触发”比如每天固定时间汇总。我选定时触发原因很直接日报这个东西的价值在于节奏稳定。事件触发会导致通知忽多忽少忙的时候一天几十条闲的时候一条没有反而增加认知负担。固定时间推送你能形成预期知道十点半会有一份东西看完就进入工作状态。推送渠道选微信也是同样的逻辑。我不可能为了看一份日报专门去打开某个后台或者邮箱但微信是我本来就一直开着的。把结果送到用户已经在用的工具里是自动化方案能不能长期坚持的关键。很多人做自动化失败不是因为技术不行而是因为“查看成本太高”最后就懒得看了。提示推送渠道的选择标准只有一个——你每天一定会打开它。微信、钉钉、飞书都可以选你用得最顺手的那个不要为了“看起来专业”去选一个你一周才开一次的渠道。2.2 WorkBuddy 在链路中的定位WorkBuddy 在这套方案里承担的是“调度 执行 汇总”三个职责。调度是指它知道什么时候该干活执行是指它去拉取信息、调用模型生成内容汇总是指它把结果整理成可读的格式再通过接口推送到微信。这里有个设计取舍值得说清楚我没有让 WorkBuddy 直接去抓取所有原始信息而是让它调用一个已经整理好的数据源。原因是原始信息抓取涉及太多不确定性——页面结构会变、接口会限流、反爬策略会调整。把这些不稳定因素集中在一个环节处理比分散在整个链路里要好排查得多。WorkBuddy 只负责“拿现成的数据生成日报推出去”链路越短出问题的概率越低。2.3 模型选型为什么用 deepseek-v4-flash生成日报这一步需要调用大模型。我选 deepseek-v4-flash主要看三点响应速度、成本、中文表达能力。日报这种场景对模型的“深度推理”要求不高但对“快速稳定输出”要求很高。flash 版本在速度上有明显优势而且中文语料训练充分生成的内容读起来不像机翻。如果你用的是其他模型逻辑是一样的选一个响应快、成本可控、中文表达自然的就行。不要在这个环节追求“最强模型”日报不是写论文够用就好。我实测下来用 flash 版本生成一份 800 字左右的日报从触发到推送完成整个链路大概在 15 到 25 秒之间这个延迟完全可以接受。2.4 整体链路一览把上面的设计串起来完整链路是这样的每天上午 10:30WorkBuddy 的定时任务被触发WorkBuddy 调用预设的数据源接口拉取当日需要汇总的信息把原始数据交给 deepseek-v4-flash按预设的 prompt 生成日报正文对生成内容做一次格式清洗去掉多余空行、统一标点通过微信推送接口把日报发送到指定会话记录本次执行日志方便后续排查这条链路里第 2 步和第 5 步是最容易出问题的环节后面会专门讲排查方法。3. 核心细节解析与实操要点3.1 定时任务的参数怎么设定时任务看起来简单但有几个参数如果设错会导致任务要么不触发要么触发时间漂移。第一个是时区。WorkBuddy 如果跑在服务器上默认时区可能是 UTC你设的 10:30 实际执行时间是北京时间 18:30。这个坑我踩过排查了半天才发现是时区问题。解决办法是在任务配置里显式指定时区或者把服务器时区改成你所在的时区。第二个是执行频率的边界。如果你设的是“每天 10:30”要确认它不会在 10:30:00 到 10:30:59 之间重复触发。有些调度器的最小粒度是分钟有些是秒配置时要看清楚。我一般会把触发时间设成 10:30:00然后在任务内部加一个“本次执行标记”防止重复推送。第三个是失败重试策略。网络请求可能失败模型调用可能超时如果一次失败就放弃那当天就没有日报了。我的做法是设置最多 3 次重试每次间隔 60 秒。如果 3 次都失败就推送一条“今日日报生成失败”的简短通知至少让你知道出了问题而不是默默什么都没发生。3.2 数据源接口的稳定性处理数据源是整个链路的上游它不稳定后面全白搭。我在这一层做了三件事加超时单次请求超过 10 秒就放弃避免整个任务卡死加缓存如果本次拉取失败尝试读取上一次成功拉取的数据并在日报里标注“数据可能不是最新”加校验拉回来的数据先检查字段是否完整缺字段就直接走失败流程不要把残缺数据喂给模型注意不要假设数据源永远可用。任何外部依赖都要有降级方案哪怕降级方案只是“推送一条说明”也比什么都不推要好。3.3 Prompt 的设计要点日报生成的质量八成取决于 prompt。我试过很多版本最后稳定下来的结构是这样的你是一个信息汇总助手。请根据以下原始数据生成一份简洁的每日简报。 要求 1. 分成三个板块重要动态、值得关注、一句话总结 2. 每个板块不超过 5 条每条不超过 50 字 3. 不要编造数据中没有的信息 4. 语言简洁不要用“据悉”“据了解”这类冗余表达 5. 如果某条信息不确定标注“待确认” 原始数据 {data}这个 prompt 的关键在于约束输出结构和禁止编造。大模型在没有约束的情况下很容易把简短的数据扩写成一大段废话或者自己脑补一些不存在的信息。加上“不要编造”和“待确认”标注后输出质量稳定了很多。3.4 微信推送的格式处理微信推送对格式有一定要求纯文本最稳Markdown 在部分场景下不渲染。我的做法是把日报生成成纯文本用换行和简单的符号比如-、【】来做视觉分隔。这样不管在哪个客户端打开显示效果都是一致的。推送内容长度也要控制。微信单条消息有长度限制超过会被截断。我的日报控制在 800 字以内如果内容确实多就分成两条推送第一条是摘要第二条是详情。实测下来800 字以内的日报阅读体验最好太长反而没人看。4. 实操过程与核心环节实现4.1 环境准备与基础配置先把基础环境搭好。WorkBuddy 支持多种部署方式我用的是 Linux 环境因为定时任务在 Linux 上更稳定。安装过程按官方文档走就行这里不展开重点说几个配置项时区配置在配置文件里设置TZAsia/Shanghai或者在启动命令前加TZAsia/Shanghai日志路径指定一个固定的日志目录方便后续排查我设在/var/log/workbuddy/并发限制如果同时跑多个任务设置最大并发数避免资源争抢配置完成后先跑一个最简单的测试任务确认 WorkBuddy 能正常触发和执行。不要一上来就配完整链路分步验证能省很多排查时间。4.2 编写日报生成脚本核心逻辑我写成了一个独立的脚本WorkBuddy 只负责调用它。这样做的好处是脚本可以单独测试不依赖 WorkBuddy 的调度。脚本的主要逻辑如下import requests import json from datetime import datetime def fetch_data(): 拉取原始数据带超时和重试 for attempt in range(3): try: resp requests.get(DATA_SOURCE_URL, timeout10) if resp.status_code 200: return resp.json() except Exception as e: print(f第 {attempt1} 次拉取失败: {e}) return None def generate_report(data): 调用模型生成日报 prompt build_prompt(data) resp requests.post( MODEL_API_URL, json{model: deepseek-v4-flash, prompt: prompt}, timeout30 ) return resp.json().get(content, ) def push_to_wechat(content): 推送到微信 resp requests.post( WECHAT_WEBHOOK_URL, json{msgtype: text, text: {content: content}}, timeout10 ) return resp.status_code 200 if __name__ __main__: data fetch_data() if not data: push_to_wechat(今日日报生成失败数据源不可用) exit(1) report generate_report(data) if not report: push_to_wechat(今日日报生成失败模型调用异常) exit(1) push_to_wechat(report) print(f日报推送完成: {datetime.now()})这个脚本的结构很清晰拉数据、生成、推送每一步都有失败处理。你可以直接拿去改把 URL 和参数换成你自己的就行。4.3 配置 WorkBuddy 定时任务脚本写好后在 WorkBuddy 里配置定时任务。核心配置项如下配置项值说明任务名称daily-ai-report自定义方便识别触发时间10:30:00每天上午十点半时区Asia/Shanghai显式指定避免漂移执行命令python /path/to/report.py调用脚本超时时间120 秒给足模型调用时间重试次数3失败后重试重试间隔60 秒避免频繁重试配置完成后先手动触发一次确认整个链路能跑通。手动触发没问题后再等第二天看定时触发是否正常。4.4 验证与日志检查任务跑起来后要养成看日志的习惯。我一般在任务执行后 5 分钟检查一次日志确认三件事数据拉取是否成功日志里会有“拉取成功”或“拉取失败”模型调用是否正常日志里会有 token 消耗和响应时间微信推送是否成功日志里会有推送接口的返回码如果某一步失败日志里会有具体的错误信息。根据错误信息定位问题比盲目猜测快得多。5. 常见问题与排查技巧实录5.1 任务没有按时触发这是最常见的问题排查顺序如下检查时区确认 WorkBuddy 的时区和你的预期一致检查任务状态确认任务没有被禁用或暂停检查调度器日志看调度器有没有记录触发事件检查系统时间服务器时间是否准确有没有跑偏我遇到过一次任务不触发最后发现是服务器时间比实际时间慢了 20 分钟导致 10:30 的任务实际在 10:50 才触发。同步一下系统时间就好了。5.2 日报内容为空或格式错乱如果推送出来的日报是空的或者格式乱七八糟通常是 prompt 或数据的问题。排查方法打印原始数据确认数据源返回的内容是否正常打印模型输出确认模型返回的内容是否完整检查 prompt确认 prompt 里的变量是否正确替换格式错乱一般是模型没有按预期输出可以在 prompt 里加一句“严格按照以下格式输出”并给出示例。示例对模型的约束效果比纯文字描述好很多。5.3 微信推送失败微信推送失败的原因比较多常见的有错误码原因解决办法40001凭证无效检查 webhook 地址是否正确45009接口调用超限降低推送频率或申请更高配额40008消息内容为空检查推送内容是否为空字符串超时网络问题增加超时时间或检查网络连通性提示微信推送接口有频率限制不要短时间内重复推送。如果任务重试要确保不会因为重试导致重复推送多条消息。5.4 模型调用超时或返回异常模型调用超时一般是网络问题或模型服务负载高。解决办法增加超时时间从 30 秒调到 60 秒在 prompt 里限制输出长度减少生成时间如果频繁超时考虑换一个响应更快的模型返回异常的情况比如返回内容包含乱码或无关信息一般是 prompt 不够明确。可以在 prompt 里加“只输出日报内容不要输出其他说明”能有效减少无关输出。5.5 独家避坑技巧几个我踩过坑之后总结的技巧不要在周五下午改配置改完如果出问题周末没人处理周一回来一堆烂摊子保留最近 7 天的日志出问题时可以对比正常和异常的执行记录推送内容加时间戳方便确认收到的是哪一天的日报避免混淆先跑通再优化不要一开始就追求完美格式先让链路跑起来再慢慢调6. 后续扩展与个人体会这套方案跑稳定之后可以扩展的方向不少。比如把日报改成周报每周一早上推送上周汇总或者增加一个“异常提醒”任务当数据源出现异常时立即推送而不是等到第二天。WorkBuddy 的自定义指令能力在这里很有用你可以给它定几条通用规则比如“所有推送内容必须包含时间戳”“所有失败必须推送通知”这些规则对后续所有任务都生效不用每个任务单独配置。我个人在实际操作中的体会是自动化的价值不在于“省了多少时间”而在于“消除了多少不确定性”。以前我每天要记得去查信息现在不用记了到点就有。这种确定性带来的心理负担减轻比省下来的十几分钟更值钱。另外一个小建议日报的内容不要贪多控制在 800 字以内三条核心信息加一句总结就够了。信息太多反而没人看自动化就失去了意义。