1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是泡茶而是打开各种窗口翻消息、看邮件、扫一遍项目群里的讨论把昨天遗留的问题和今天要跟进的事项在脑子里过一遍。这个过程大概要花掉二十分钟到半小时而且经常因为信息太散而漏掉关键内容。后来我把这套流程交给了 WorkBuddy让它每天上午十点半自动生成一份 AI 日报直接推送到微信上。现在我到工位坐下微信里已经躺着一份整理好的摘要扫一眼就能进入状态。这个项目的核心其实就三件事定时触发、AI 内容生成、微信推送。听起来简单但中间涉及调度策略、数据源整理、提示词设计、推送通道选择等一堆细节。我踩过的坑包括定时任务在服务器重启后失效、AI 输出格式不稳定导致推送内容乱码、微信侧消息长度超限被截断等等。这篇文章会把整套方案的思路、实现细节和避坑经验完整拆开讲适合有一定脚本基础、想把日常信息整理工作自动化的朋友参考。即使你之前没接触过 WorkBuddy跟着思路走也能理解整个链路的搭建逻辑。提示本文提到的 WorkBuddy 是一个 AI 任务编排工具核心能力是把多个步骤串成一条自动化流水线。不同版本的界面和配置方式可能有差异但底层逻辑是相通的。2. 整体方案设计与核心思路拆解2.1 为什么选“定时触发 AI 生成 微信推送”这条链路先说我评估过的几种方案。第一种是纯本地脚本用系统的定时任务跑一个 Python 脚本脚本里调 AI 接口生成内容再通过某种方式发到手机。第二种是用现成的自动化平台拖拽几个节点连起来。第三种就是 WorkBuddy 这类工具把调度、AI 调用、消息推送都封装成可配置的模块。我最终选第三条路原因很实际。纯本地脚本的自由度最高但维护成本也最高——服务器换了要重新配环境依赖升级了要重新测推送通道挂了要自己排查。自动化平台看起来省事但很多平台对 AI 模型的选择有限制提示词也不能精细控制。WorkBuddy 的好处在于它既提供了可视化的任务编排又允许我在关键节点插入自定义逻辑比如自己写提示词模板、自己处理数据格式。这种“半开放”的形态对我来说刚刚好。另一个关键考量是推送通道的稳定性。微信是我每天必看的工具消息触达率比邮件高得多。但微信本身不提供个人号的消息推送接口所以需要借助一些中间服务。我试过几种方式最后选了一个折中方案通过一个轻量的消息中转服务把内容转发到微信的文件传输助手或者某个只有自己的群。这样既不需要复杂的认证流程又能保证消息能到。2.2 十点半这个时间点是怎么定下来的时间选择不是拍脑袋决定的。我观察了自己一周的工作节奏九点到九点半是处理紧急消息和站会的时间九点半到十点是在写代码或者处理具体任务十点左右会有一个自然的停顿——可能是倒水、可能是等编译。十点半这个点上午的工作已经推进了一部分但还没到午饭前的收尾阶段正好适合插入一个信息同步的动作。另外从数据源的角度看很多系统的日报数据是在早上八点到九点之间生成的十点半去拉取能确保数据已经更新完毕。如果设得太早比如九点可能会拿到不完整的数据设得太晚比如十一点半又接近午饭时间容易被其他事情打断。所以十点半是一个经过实测的“甜点时间”。注意如果你的数据源有固定的更新时间窗口比如某些平台是每天十点才刷新数据那定时任务至少要往后推半小时留出缓冲。2.3 日报内容应该包含什么一开始我想把所有信息都塞进去结果生成的内容又长又乱根本不想看。后来我做了减法只保留四类内容昨日关键进展、今日待办事项、需要关注的风险点、一条随机激励语。前三条是实用信息最后一条是给自己一点正向反馈。这个结构的好处是信息密度高但阅读负担低。每条内容控制在两三句话以内整份日报读下来不超过一分钟。如果你也想做类似的事情建议先想清楚“我每天早上最想知道什么”而不是“我能拿到什么数据”。前者是需求驱动后者是技术驱动效果差别很大。3. 核心细节解析与实操要点3.1 WorkBuddy 任务的创建与规则配置在 WorkBuddy 里创建一个定时任务第一步是选触发方式。它支持 cron 表达式也支持可视化选择。我直接用 cron 写的30 10 * * *意思是每天十点三十分触发。这里有个细节如果你的服务器时区不是东八区需要在任务配置里显式指定时区否则会在错误的时间跑起来。创建完触发规则后下一步是定义任务步骤。我的任务链是这样的数据采集节点从几个数据源拉取原始信息包括项目管理系统里的任务状态、代码仓库的提交记录、以及一个手动维护的待办清单。数据清洗节点把拉到的原始数据做去重、排序、截断统一成结构化格式。AI 生成节点把清洗后的数据填入提示词模板调用 AI 模型生成日报正文。格式处理节点对 AI 输出做后处理比如去掉多余的 Markdown 标记、控制总长度。推送节点把最终内容发送到微信。每个节点都可以单独测试。我建议先把前四个节点跑通确认输出内容符合预期后再接入推送节点。否则调试的时候会频繁收到测试消息很烦人。3.2 提示词模板的设计要点提示词是决定日报质量的关键。我试过好几种写法最后稳定下来的模板大概是这样的结构你是一个工作助理需要根据以下原始数据生成一份简洁的每日工作日报。 要求 1. 分为四个部分昨日进展、今日待办、风险提醒、一句话鼓励。 2. 每个部分不超过三条每条不超过两句话。 3. 语言简洁不要用“我们”“大家”这类词直接用动词开头。 4. 如果某个部分没有内容写“暂无”。 5. 不要编造数据中没有的信息。 原始数据 {data}这个模板里最重要的两条是“不要编造”和“控制长度”。AI 模型天然倾向于扩写和补充如果不加限制它会自己脑补出一些不存在的事项。另外长度控制也很关键因为微信消息有长度限制太长的内容会被截断或者折叠。实操心得提示词里的示例比描述更有效。如果你希望 AI 输出特定格式最好在提示词里给一个简短的示例而不是用文字描述格式要求。3.3 微信推送通道的选择与配置微信推送这块我折腾最久。个人微信没有官方推送接口所以需要找一个合法的替代方案。我最终用的是“消息中转 文件传输助手”的方式WorkBuddy 把内容发到一个自建的中转服务中转服务再通过微信的开放能力把消息转发到我的文件传输助手。具体配置时需要注意几点。第一消息内容要做 URL 编码否则特殊字符会导致发送失败。第二如果内容超过一定长度要主动截断并加上“全文见附件”之类的提示。第三推送失败要有重试机制我设的是失败后隔三十秒重试一次最多重试三次。另外如果你不想折腾中转服务也可以考虑用邮件作为备选通道。虽然触达率不如微信但配置简单很多适合刚开始尝试的阶段。3.4 数据源的整理与清洗数据清洗这一步看起来不起眼但直接决定了 AI 生成内容的质量。我的原始数据来自三个地方格式各不相同项目管理系统返回的是 JSON代码仓库的提交记录是纯文本待办清单是我手动维护的 Markdown 文件。清洗的逻辑是先把所有数据转成统一的 JSON 结构每个条目包含type、title、status、timestamp四个字段。然后按时间倒序排列只保留最近二十四小时的条目。最后对title做截断超过五十个字符的只保留前五十个。这一步的代码不复杂但一定要做。我一开始跳过清洗直接喂给 AI结果生成的内容里混进了大量无关信息比如三个月前的旧任务、已经关闭的工单等等。清洗之后日报的相关性明显提升。4. 实操过程与核心环节实现4.1 环境准备与依赖安装我是在一台常驻的 Linux 机器上跑这套流程的。系统是 Ubuntu 22.04Python 版本 3.10。需要安装的依赖不多主要是requests用来调接口pyyaml用来读配置文件以及schedule作为本地调试时的备用调度器。sudo apt update sudo apt install -y python3-pip pip3 install requests pyyaml scheduleWorkBuddy 本身如果是客户端形式直接在界面里配置即可如果是服务形式需要确认它的 API 地址和认证方式。我用的版本需要在配置文件里填一个 token这个 token 在 WorkBuddy 的设置页面可以找到。注意token 不要硬编码在脚本里建议放在环境变量或者单独的配置文件里并且给配置文件设置好权限避免泄露。4.2 数据采集脚本的编写数据采集我写了一个 Python 脚本核心逻辑是三个函数分别拉取三个数据源然后合并。这里以拉取项目管理系统数据为例import requests import json from datetime import datetime, timedelta def fetch_project_tasks(api_url, token): headers {Authorization: fBearer {token}} params { updated_after: (datetime.now() - timedelta(hours24)).isoformat(), status: open,in_progress } resp requests.get(api_url, headersheaders, paramsparams, timeout10) resp.raise_for_status() tasks resp.json().get(items, []) result [] for t in tasks: result.append({ type: task, title: t.get(title, )[:50], status: t.get(status, ), timestamp: t.get(updated_at, ) }) return result这段代码的关键点是updated_after参数只拉取最近二十四小时有更新的任务。另外timeout一定要设否则网络卡住的时候整个任务会挂起。raise_for_status用来在接口返回错误时及时抛出异常方便排查。4.3 AI 生成节点的配置与调试在 WorkBuddy 里配置 AI 节点时需要填几个东西模型选择、提示词模板、输入变量映射、输出格式。模型我选的是 deepseek 系列因为它在中文理解和指令遵循上表现比较稳定而且响应速度可以接受。输入变量映射是把上一步清洗后的数据填入提示词的{data}占位符。这里要注意数据量不能太大如果原始数据超过几千字AI 的处理时间会明显变长而且容易丢失细节。我的做法是先在清洗阶段做一次摘要把每个条目的描述压缩到一句话再喂给 AI。调试的时候我建议先用固定的测试数据跑几遍观察输出是否稳定。如果发现 AI 有时候输出 Markdown 有时候输出纯文本可以在提示词里明确要求“输出纯文本不要使用任何标记符号”。如果发现内容长度波动很大可以在提示词里加上字数范围比如“总字数控制在三百字以内”。4.4 推送环节的实现与测试推送环节我写了一个简单的转发函数把 AI 生成的文本发到中转服务def push_to_wechat(content, endpoint, secret): payload { secret: secret, content: content[:1800], type: text } resp requests.post(endpoint, jsonpayload, timeout10) if resp.status_code ! 200: raise RuntimeError(fpush failed: {resp.status_code}) return resp.json()这里content[:1800]是做一个硬截断防止内容过长导致推送失败。实际测试下来一千八百个字符以内的消息基本都能正常送达。如果内容确实需要更长可以考虑拆成多条发送或者生成一个摘要版本加一个完整版本的链接。测试推送的时候我建议先用一条固定的测试消息确认通道通了之后再接入真实的 AI 输出。否则一旦格式有问题你很难判断是 AI 的问题还是推送的问题。4.5 定时调度的配置与验证WorkBuddy 的定时任务配置好之后一定要做一次手动触发测试。我一般会先把触发时间设成几分钟后观察任务是否按时执行、每个节点是否正常完成、最终消息是否送达。确认无误后再改成正式的十点半。另外要检查任务的超时设置。如果某个节点卡住整个任务会一直挂着。我给每个节点设了三十秒的超时整个任务设了五分钟的总超时。超过时间就标记为失败并发送一条告警消息到微信这样我能及时知道出了问题。实操心得定时任务最好加一个“执行日志”节点把每次运行的耗时、各节点状态、输出摘要记录到一个文件里。出问题的时候翻日志比重新跑一遍快得多。5. 常见问题与排查技巧实录5.1 任务没有按时触发这是最常见的问题。排查顺序是这样的先确认 WorkBuddy 服务本身是否在运行再看任务的 cron 表达式是否正确然后检查时区设置。我遇到过一次是因为服务器重启后 WorkBuddy 的服务没有自动拉起导致任务根本没跑。后来我加了一个系统级的守护配置确保服务异常退出后能自动重启。还有一种情况是任务触发了但卡在某个节点。这时候要看节点的超时设置和日志。如果日志显示某个接口调用一直没返回那大概率是网络问题或者对方服务挂了。我的做法是在关键节点加上重试逻辑比如接口调用失败后隔几秒重试两次。5.2 AI 输出内容不符合预期AI 输出的问题一般分三类格式不对、内容跑偏、长度失控。格式问题通常是因为提示词不够明确解决办法是在提示词里给出具体的输出示例。内容跑偏往往是因为原始数据太杂AI 抓不住重点这时候要加强数据清洗只保留最相关的信息。长度失控则需要在提示词里明确字数限制并且在输出后做一次截断。我自己的经验是提示词要反复迭代。第一版写完之后连续跑三天每天看输出把不满意的地方记下来然后针对性地改提示词。一般迭代三到五轮之后输出质量就能稳定下来。5.3 微信推送失败或消息被截断推送失败的原因比较多。如果是网络问题重试通常能解决。如果是认证问题需要检查 token 或 secret 是否过期。如果是内容问题比如包含了特殊字符那就需要在推送前做一次转义处理。消息被截断通常是因为长度超限。不同通道的长度限制不一样我用的中转服务限制是两千个字符左右。解决办法是在推送前先计算内容长度超过阈值就自动截断并加上省略号。更好的做法是让 AI 生成时就控制长度而不是事后截断。5.4 数据源接口变更导致采集失败这个问题的隐蔽性比较强因为接口变更往往不会提前通知。我的应对策略是在采集脚本里加一个“数据量校验”如果拉到的条目数为零或者比昨天少了超过一半就触发告警。这样即使接口变了我也能第一时间知道而不是等到日报内容变得很奇怪才发现。另外建议把采集脚本的返回结果保存一份原始副本方便对比。我一般会保留最近七天的原始数据超过七天的自动清理。这样既不占太多空间又能在出问题时回溯。5.5 常见问题速查表问题现象可能原因排查方法解决措施任务未触发服务未运行、cron 错误、时区不对检查服务状态和任务配置加守护进程、修正 cron 和时区任务卡住接口超时、节点死锁查看节点日志和超时设置加重试逻辑、设置合理超时AI 输出格式乱提示词不明确对比提示词和实际输出增加输出示例和格式约束推送失败网络问题、认证过期、内容超限检查推送日志和返回码重试、更新凭证、截断内容数据为空接口变更、权限失效检查采集脚本返回加数据量校验和告警6. 几个让日报更好用的小技巧6.1 给日报加一个“昨日回顾”的锚点我在日报的最后加了一行“昨天这个时候你在做什么”内容是前一天日报里“今日待办”的第一条。这样做的目的是形成一个闭环昨天说要做的今天看看有没有推进。如果连续几天都看到同一条待办没有变化那就说明这件事需要重新评估优先级了。这个功能实现起来很简单就是在生成日报的时候把前一天日报的内容读出来取第一条待办拼接到新日报的末尾。但效果很好有一种“自己监督自己”的感觉。6.2 用不同的语气切换来保持新鲜感同样的格式看久了会麻木。我在提示词里加了一个随机变量让 AI 在“正式”“轻松”“极简”三种风格之间随机切换。正式风格适合周一轻松风格适合周五极简风格适合特别忙的时候。这个改动很小但让日报的阅读体验好了很多。具体做法是在提示词模板里加一个{style}占位符然后在生成前随机选一个值填进去。风格描述可以写得很简单比如“正式用词严谨条理清晰”“轻松语气随意可以用口语”“极简只保留最关键的信息每条不超过十个字”。6.3 把日报同步一份到笔记软件微信里的消息容易被刷掉所以我还会把每天的日报同步一份到笔记软件里。这样过一段时间可以回看看看自己这段时间都在忙什么。同步的方式很简单就是在推送节点后面再加一个节点把同样的内容写到笔记软件的接口里。笔记软件的选择看个人习惯我用的是一个支持 Markdown 的轻量工具。关键是它的接口要简单最好支持直接 POST 一段文本就能创建一条笔记。如果接口太复杂维护成本就上去了。6.4 定期回顾和调整日报结构我大概每个月会花十分钟看一下这个月的日报问自己三个问题哪些内容我从来不看哪些内容我每次都看有没有什么信息是我希望看到但日报里没有的根据这三个问题的答案来调整日报的结构。上个月我发现“风险提醒”这一块经常是“暂无”说明我的数据源里缺少风险相关的信息。于是我在采集节点里加了一个来源专门拉取项目群里被标记为“阻塞”的消息。这个改动之后风险提醒的命中率明显提高了。提示日报的结构不是一成不变的随着工作内容的变化需要定期调整。建议每个月做一次小回顾每季度做一次大调整。6.5 异常情况的兜底方案再稳定的系统也会出问题。我的兜底方案是如果十点半没有收到日报十点四十五分的时候会有一个备用任务再跑一次。如果备用任务也失败了我会收到一条简短的告警消息内容只有“日报生成失败请检查”。这样即使主流程挂了我也能知道而不是傻等。备用任务的配置和主任务基本一样只是触发时间不同而且它会在执行前先检查一下今天的日报是否已经发送成功。如果已经发送过了就直接跳过避免重复推送。7. 关于 WorkBuddy 规则配置的一点补充标题里提到“给 WorkBuddy 定几条规则后续对所有任务都生效”这个能力在实际使用中确实很实用。我目前设了三条全局规则第一条是“所有涉及外部接口调用的节点超时时间不超过三十秒”第二条是“所有 AI 生成的内容输出前必须做一次长度检查”第三条是“所有推送类节点失败后必须重试至少两次”。这三条规则帮我省了很多重复配置的工作。比如我后来新增了一个“周报生成”的任务就不需要再单独设置超时和重试直接继承全局规则就行。WorkBuddy 的规则配置界面支持条件判断比如“如果节点类型是 AI 生成则应用规则 A”这样灵活性更高。如果你刚开始用 WorkBuddy建议先不要设太多规则等跑通两三个任务之后再根据实际遇到的问题来提炼规则。规则太多反而会互相冲突排查起来更麻烦。8. 最后分享几个踩坑之后的体会这套东西我从开始折腾到稳定运行大概花了两个周末。最大的体会是不要追求一步到位。我一开始想做一个大而全的日报系统结果每个环节都出问题调试起来非常痛苦。后来拆成小步走先让数据采集跑通再加 AI 生成最后接推送每一步都确认稳定了再往下走效率反而高很多。另一个体会是日志比什么都重要。我现在的每个节点都会输出结构化的日志包括开始时间、结束时间、输入摘要、输出摘要、状态码。出问题的时候看一眼日志基本就能定位到是哪个环节出了错。没有日志的话只能靠猜非常浪费时间。还有一点是不要过度依赖 AI。AI 适合做摘要和格式化但不适合做判断和决策。我的日报里所有涉及优先级判断的内容都是我在采集阶段就打好标签的AI 只负责把标签翻译成通顺的文字。如果把判断也交给 AI输出会变得很不稳定。最后这套方案的价值不在于技术有多复杂而在于它确实帮我省下了每天早上的二十分钟。这二十分钟我可以用来做更重要的事或者干脆多喝一杯咖啡。自动化工具的意义就在于此把重复的、低价值的事情交给机器把时间和精力留给真正需要人来做的事情。 WorkBuddy定时任务实战：AI日报自动生成与微信推送全流程
1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是泡茶而是打开各种窗口翻消息、看邮件、扫一遍项目群里的讨论把昨天遗留的问题和今天要跟进的事项在脑子里过一遍。这个过程大概要花掉二十分钟到半小时而且经常因为信息太散而漏掉关键内容。后来我把这套流程交给了 WorkBuddy让它每天上午十点半自动生成一份 AI 日报直接推送到微信上。现在我到工位坐下微信里已经躺着一份整理好的摘要扫一眼就能进入状态。这个项目的核心其实就三件事定时触发、AI 内容生成、微信推送。听起来简单但中间涉及调度策略、数据源整理、提示词设计、推送通道选择等一堆细节。我踩过的坑包括定时任务在服务器重启后失效、AI 输出格式不稳定导致推送内容乱码、微信侧消息长度超限被截断等等。这篇文章会把整套方案的思路、实现细节和避坑经验完整拆开讲适合有一定脚本基础、想把日常信息整理工作自动化的朋友参考。即使你之前没接触过 WorkBuddy跟着思路走也能理解整个链路的搭建逻辑。提示本文提到的 WorkBuddy 是一个 AI 任务编排工具核心能力是把多个步骤串成一条自动化流水线。不同版本的界面和配置方式可能有差异但底层逻辑是相通的。2. 整体方案设计与核心思路拆解2.1 为什么选“定时触发 AI 生成 微信推送”这条链路先说我评估过的几种方案。第一种是纯本地脚本用系统的定时任务跑一个 Python 脚本脚本里调 AI 接口生成内容再通过某种方式发到手机。第二种是用现成的自动化平台拖拽几个节点连起来。第三种就是 WorkBuddy 这类工具把调度、AI 调用、消息推送都封装成可配置的模块。我最终选第三条路原因很实际。纯本地脚本的自由度最高但维护成本也最高——服务器换了要重新配环境依赖升级了要重新测推送通道挂了要自己排查。自动化平台看起来省事但很多平台对 AI 模型的选择有限制提示词也不能精细控制。WorkBuddy 的好处在于它既提供了可视化的任务编排又允许我在关键节点插入自定义逻辑比如自己写提示词模板、自己处理数据格式。这种“半开放”的形态对我来说刚刚好。另一个关键考量是推送通道的稳定性。微信是我每天必看的工具消息触达率比邮件高得多。但微信本身不提供个人号的消息推送接口所以需要借助一些中间服务。我试过几种方式最后选了一个折中方案通过一个轻量的消息中转服务把内容转发到微信的文件传输助手或者某个只有自己的群。这样既不需要复杂的认证流程又能保证消息能到。2.2 十点半这个时间点是怎么定下来的时间选择不是拍脑袋决定的。我观察了自己一周的工作节奏九点到九点半是处理紧急消息和站会的时间九点半到十点是在写代码或者处理具体任务十点左右会有一个自然的停顿——可能是倒水、可能是等编译。十点半这个点上午的工作已经推进了一部分但还没到午饭前的收尾阶段正好适合插入一个信息同步的动作。另外从数据源的角度看很多系统的日报数据是在早上八点到九点之间生成的十点半去拉取能确保数据已经更新完毕。如果设得太早比如九点可能会拿到不完整的数据设得太晚比如十一点半又接近午饭时间容易被其他事情打断。所以十点半是一个经过实测的“甜点时间”。注意如果你的数据源有固定的更新时间窗口比如某些平台是每天十点才刷新数据那定时任务至少要往后推半小时留出缓冲。2.3 日报内容应该包含什么一开始我想把所有信息都塞进去结果生成的内容又长又乱根本不想看。后来我做了减法只保留四类内容昨日关键进展、今日待办事项、需要关注的风险点、一条随机激励语。前三条是实用信息最后一条是给自己一点正向反馈。这个结构的好处是信息密度高但阅读负担低。每条内容控制在两三句话以内整份日报读下来不超过一分钟。如果你也想做类似的事情建议先想清楚“我每天早上最想知道什么”而不是“我能拿到什么数据”。前者是需求驱动后者是技术驱动效果差别很大。3. 核心细节解析与实操要点3.1 WorkBuddy 任务的创建与规则配置在 WorkBuddy 里创建一个定时任务第一步是选触发方式。它支持 cron 表达式也支持可视化选择。我直接用 cron 写的30 10 * * *意思是每天十点三十分触发。这里有个细节如果你的服务器时区不是东八区需要在任务配置里显式指定时区否则会在错误的时间跑起来。创建完触发规则后下一步是定义任务步骤。我的任务链是这样的数据采集节点从几个数据源拉取原始信息包括项目管理系统里的任务状态、代码仓库的提交记录、以及一个手动维护的待办清单。数据清洗节点把拉到的原始数据做去重、排序、截断统一成结构化格式。AI 生成节点把清洗后的数据填入提示词模板调用 AI 模型生成日报正文。格式处理节点对 AI 输出做后处理比如去掉多余的 Markdown 标记、控制总长度。推送节点把最终内容发送到微信。每个节点都可以单独测试。我建议先把前四个节点跑通确认输出内容符合预期后再接入推送节点。否则调试的时候会频繁收到测试消息很烦人。3.2 提示词模板的设计要点提示词是决定日报质量的关键。我试过好几种写法最后稳定下来的模板大概是这样的结构你是一个工作助理需要根据以下原始数据生成一份简洁的每日工作日报。 要求 1. 分为四个部分昨日进展、今日待办、风险提醒、一句话鼓励。 2. 每个部分不超过三条每条不超过两句话。 3. 语言简洁不要用“我们”“大家”这类词直接用动词开头。 4. 如果某个部分没有内容写“暂无”。 5. 不要编造数据中没有的信息。 原始数据 {data}这个模板里最重要的两条是“不要编造”和“控制长度”。AI 模型天然倾向于扩写和补充如果不加限制它会自己脑补出一些不存在的事项。另外长度控制也很关键因为微信消息有长度限制太长的内容会被截断或者折叠。实操心得提示词里的示例比描述更有效。如果你希望 AI 输出特定格式最好在提示词里给一个简短的示例而不是用文字描述格式要求。3.3 微信推送通道的选择与配置微信推送这块我折腾最久。个人微信没有官方推送接口所以需要找一个合法的替代方案。我最终用的是“消息中转 文件传输助手”的方式WorkBuddy 把内容发到一个自建的中转服务中转服务再通过微信的开放能力把消息转发到我的文件传输助手。具体配置时需要注意几点。第一消息内容要做 URL 编码否则特殊字符会导致发送失败。第二如果内容超过一定长度要主动截断并加上“全文见附件”之类的提示。第三推送失败要有重试机制我设的是失败后隔三十秒重试一次最多重试三次。另外如果你不想折腾中转服务也可以考虑用邮件作为备选通道。虽然触达率不如微信但配置简单很多适合刚开始尝试的阶段。3.4 数据源的整理与清洗数据清洗这一步看起来不起眼但直接决定了 AI 生成内容的质量。我的原始数据来自三个地方格式各不相同项目管理系统返回的是 JSON代码仓库的提交记录是纯文本待办清单是我手动维护的 Markdown 文件。清洗的逻辑是先把所有数据转成统一的 JSON 结构每个条目包含type、title、status、timestamp四个字段。然后按时间倒序排列只保留最近二十四小时的条目。最后对title做截断超过五十个字符的只保留前五十个。这一步的代码不复杂但一定要做。我一开始跳过清洗直接喂给 AI结果生成的内容里混进了大量无关信息比如三个月前的旧任务、已经关闭的工单等等。清洗之后日报的相关性明显提升。4. 实操过程与核心环节实现4.1 环境准备与依赖安装我是在一台常驻的 Linux 机器上跑这套流程的。系统是 Ubuntu 22.04Python 版本 3.10。需要安装的依赖不多主要是requests用来调接口pyyaml用来读配置文件以及schedule作为本地调试时的备用调度器。sudo apt update sudo apt install -y python3-pip pip3 install requests pyyaml scheduleWorkBuddy 本身如果是客户端形式直接在界面里配置即可如果是服务形式需要确认它的 API 地址和认证方式。我用的版本需要在配置文件里填一个 token这个 token 在 WorkBuddy 的设置页面可以找到。注意token 不要硬编码在脚本里建议放在环境变量或者单独的配置文件里并且给配置文件设置好权限避免泄露。4.2 数据采集脚本的编写数据采集我写了一个 Python 脚本核心逻辑是三个函数分别拉取三个数据源然后合并。这里以拉取项目管理系统数据为例import requests import json from datetime import datetime, timedelta def fetch_project_tasks(api_url, token): headers {Authorization: fBearer {token}} params { updated_after: (datetime.now() - timedelta(hours24)).isoformat(), status: open,in_progress } resp requests.get(api_url, headersheaders, paramsparams, timeout10) resp.raise_for_status() tasks resp.json().get(items, []) result [] for t in tasks: result.append({ type: task, title: t.get(title, )[:50], status: t.get(status, ), timestamp: t.get(updated_at, ) }) return result这段代码的关键点是updated_after参数只拉取最近二十四小时有更新的任务。另外timeout一定要设否则网络卡住的时候整个任务会挂起。raise_for_status用来在接口返回错误时及时抛出异常方便排查。4.3 AI 生成节点的配置与调试在 WorkBuddy 里配置 AI 节点时需要填几个东西模型选择、提示词模板、输入变量映射、输出格式。模型我选的是 deepseek 系列因为它在中文理解和指令遵循上表现比较稳定而且响应速度可以接受。输入变量映射是把上一步清洗后的数据填入提示词的{data}占位符。这里要注意数据量不能太大如果原始数据超过几千字AI 的处理时间会明显变长而且容易丢失细节。我的做法是先在清洗阶段做一次摘要把每个条目的描述压缩到一句话再喂给 AI。调试的时候我建议先用固定的测试数据跑几遍观察输出是否稳定。如果发现 AI 有时候输出 Markdown 有时候输出纯文本可以在提示词里明确要求“输出纯文本不要使用任何标记符号”。如果发现内容长度波动很大可以在提示词里加上字数范围比如“总字数控制在三百字以内”。4.4 推送环节的实现与测试推送环节我写了一个简单的转发函数把 AI 生成的文本发到中转服务def push_to_wechat(content, endpoint, secret): payload { secret: secret, content: content[:1800], type: text } resp requests.post(endpoint, jsonpayload, timeout10) if resp.status_code ! 200: raise RuntimeError(fpush failed: {resp.status_code}) return resp.json()这里content[:1800]是做一个硬截断防止内容过长导致推送失败。实际测试下来一千八百个字符以内的消息基本都能正常送达。如果内容确实需要更长可以考虑拆成多条发送或者生成一个摘要版本加一个完整版本的链接。测试推送的时候我建议先用一条固定的测试消息确认通道通了之后再接入真实的 AI 输出。否则一旦格式有问题你很难判断是 AI 的问题还是推送的问题。4.5 定时调度的配置与验证WorkBuddy 的定时任务配置好之后一定要做一次手动触发测试。我一般会先把触发时间设成几分钟后观察任务是否按时执行、每个节点是否正常完成、最终消息是否送达。确认无误后再改成正式的十点半。另外要检查任务的超时设置。如果某个节点卡住整个任务会一直挂着。我给每个节点设了三十秒的超时整个任务设了五分钟的总超时。超过时间就标记为失败并发送一条告警消息到微信这样我能及时知道出了问题。实操心得定时任务最好加一个“执行日志”节点把每次运行的耗时、各节点状态、输出摘要记录到一个文件里。出问题的时候翻日志比重新跑一遍快得多。5. 常见问题与排查技巧实录5.1 任务没有按时触发这是最常见的问题。排查顺序是这样的先确认 WorkBuddy 服务本身是否在运行再看任务的 cron 表达式是否正确然后检查时区设置。我遇到过一次是因为服务器重启后 WorkBuddy 的服务没有自动拉起导致任务根本没跑。后来我加了一个系统级的守护配置确保服务异常退出后能自动重启。还有一种情况是任务触发了但卡在某个节点。这时候要看节点的超时设置和日志。如果日志显示某个接口调用一直没返回那大概率是网络问题或者对方服务挂了。我的做法是在关键节点加上重试逻辑比如接口调用失败后隔几秒重试两次。5.2 AI 输出内容不符合预期AI 输出的问题一般分三类格式不对、内容跑偏、长度失控。格式问题通常是因为提示词不够明确解决办法是在提示词里给出具体的输出示例。内容跑偏往往是因为原始数据太杂AI 抓不住重点这时候要加强数据清洗只保留最相关的信息。长度失控则需要在提示词里明确字数限制并且在输出后做一次截断。我自己的经验是提示词要反复迭代。第一版写完之后连续跑三天每天看输出把不满意的地方记下来然后针对性地改提示词。一般迭代三到五轮之后输出质量就能稳定下来。5.3 微信推送失败或消息被截断推送失败的原因比较多。如果是网络问题重试通常能解决。如果是认证问题需要检查 token 或 secret 是否过期。如果是内容问题比如包含了特殊字符那就需要在推送前做一次转义处理。消息被截断通常是因为长度超限。不同通道的长度限制不一样我用的中转服务限制是两千个字符左右。解决办法是在推送前先计算内容长度超过阈值就自动截断并加上省略号。更好的做法是让 AI 生成时就控制长度而不是事后截断。5.4 数据源接口变更导致采集失败这个问题的隐蔽性比较强因为接口变更往往不会提前通知。我的应对策略是在采集脚本里加一个“数据量校验”如果拉到的条目数为零或者比昨天少了超过一半就触发告警。这样即使接口变了我也能第一时间知道而不是等到日报内容变得很奇怪才发现。另外建议把采集脚本的返回结果保存一份原始副本方便对比。我一般会保留最近七天的原始数据超过七天的自动清理。这样既不占太多空间又能在出问题时回溯。5.5 常见问题速查表问题现象可能原因排查方法解决措施任务未触发服务未运行、cron 错误、时区不对检查服务状态和任务配置加守护进程、修正 cron 和时区任务卡住接口超时、节点死锁查看节点日志和超时设置加重试逻辑、设置合理超时AI 输出格式乱提示词不明确对比提示词和实际输出增加输出示例和格式约束推送失败网络问题、认证过期、内容超限检查推送日志和返回码重试、更新凭证、截断内容数据为空接口变更、权限失效检查采集脚本返回加数据量校验和告警6. 几个让日报更好用的小技巧6.1 给日报加一个“昨日回顾”的锚点我在日报的最后加了一行“昨天这个时候你在做什么”内容是前一天日报里“今日待办”的第一条。这样做的目的是形成一个闭环昨天说要做的今天看看有没有推进。如果连续几天都看到同一条待办没有变化那就说明这件事需要重新评估优先级了。这个功能实现起来很简单就是在生成日报的时候把前一天日报的内容读出来取第一条待办拼接到新日报的末尾。但效果很好有一种“自己监督自己”的感觉。6.2 用不同的语气切换来保持新鲜感同样的格式看久了会麻木。我在提示词里加了一个随机变量让 AI 在“正式”“轻松”“极简”三种风格之间随机切换。正式风格适合周一轻松风格适合周五极简风格适合特别忙的时候。这个改动很小但让日报的阅读体验好了很多。具体做法是在提示词模板里加一个{style}占位符然后在生成前随机选一个值填进去。风格描述可以写得很简单比如“正式用词严谨条理清晰”“轻松语气随意可以用口语”“极简只保留最关键的信息每条不超过十个字”。6.3 把日报同步一份到笔记软件微信里的消息容易被刷掉所以我还会把每天的日报同步一份到笔记软件里。这样过一段时间可以回看看看自己这段时间都在忙什么。同步的方式很简单就是在推送节点后面再加一个节点把同样的内容写到笔记软件的接口里。笔记软件的选择看个人习惯我用的是一个支持 Markdown 的轻量工具。关键是它的接口要简单最好支持直接 POST 一段文本就能创建一条笔记。如果接口太复杂维护成本就上去了。6.4 定期回顾和调整日报结构我大概每个月会花十分钟看一下这个月的日报问自己三个问题哪些内容我从来不看哪些内容我每次都看有没有什么信息是我希望看到但日报里没有的根据这三个问题的答案来调整日报的结构。上个月我发现“风险提醒”这一块经常是“暂无”说明我的数据源里缺少风险相关的信息。于是我在采集节点里加了一个来源专门拉取项目群里被标记为“阻塞”的消息。这个改动之后风险提醒的命中率明显提高了。提示日报的结构不是一成不变的随着工作内容的变化需要定期调整。建议每个月做一次小回顾每季度做一次大调整。6.5 异常情况的兜底方案再稳定的系统也会出问题。我的兜底方案是如果十点半没有收到日报十点四十五分的时候会有一个备用任务再跑一次。如果备用任务也失败了我会收到一条简短的告警消息内容只有“日报生成失败请检查”。这样即使主流程挂了我也能知道而不是傻等。备用任务的配置和主任务基本一样只是触发时间不同而且它会在执行前先检查一下今天的日报是否已经发送成功。如果已经发送过了就直接跳过避免重复推送。7. 关于 WorkBuddy 规则配置的一点补充标题里提到“给 WorkBuddy 定几条规则后续对所有任务都生效”这个能力在实际使用中确实很实用。我目前设了三条全局规则第一条是“所有涉及外部接口调用的节点超时时间不超过三十秒”第二条是“所有 AI 生成的内容输出前必须做一次长度检查”第三条是“所有推送类节点失败后必须重试至少两次”。这三条规则帮我省了很多重复配置的工作。比如我后来新增了一个“周报生成”的任务就不需要再单独设置超时和重试直接继承全局规则就行。WorkBuddy 的规则配置界面支持条件判断比如“如果节点类型是 AI 生成则应用规则 A”这样灵活性更高。如果你刚开始用 WorkBuddy建议先不要设太多规则等跑通两三个任务之后再根据实际遇到的问题来提炼规则。规则太多反而会互相冲突排查起来更麻烦。8. 最后分享几个踩坑之后的体会这套东西我从开始折腾到稳定运行大概花了两个周末。最大的体会是不要追求一步到位。我一开始想做一个大而全的日报系统结果每个环节都出问题调试起来非常痛苦。后来拆成小步走先让数据采集跑通再加 AI 生成最后接推送每一步都确认稳定了再往下走效率反而高很多。另一个体会是日志比什么都重要。我现在的每个节点都会输出结构化的日志包括开始时间、结束时间、输入摘要、输出摘要、状态码。出问题的时候看一眼日志基本就能定位到是哪个环节出了错。没有日志的话只能靠猜非常浪费时间。还有一点是不要过度依赖 AI。AI 适合做摘要和格式化但不适合做判断和决策。我的日报里所有涉及优先级判断的内容都是我在采集阶段就打好标签的AI 只负责把标签翻译成通顺的文字。如果把判断也交给 AI输出会变得很不稳定。最后这套方案的价值不在于技术有多复杂而在于它确实帮我省下了每天早上的二十分钟。这二十分钟我可以用来做更重要的事或者干脆多喝一杯咖啡。自动化工具的意义就在于此把重复的、低价值的事情交给机器把时间和精力留给真正需要人来做的事情。