WorkBuddy+微信+deepseek-v4-flash：打造每日AI日报自动推送系统

1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上十点半我的微信会准时收到一份 AI 日报。不是那种“今日天气晴适合摸鱼”的废话推送而是一份包含昨日任务回顾、今日待办优先级、行业动态摘要、以及我关注的几个技术方向最新进展的结构化简报。这件事我已经跑了小半年中间踩过坑、换过方案、也推翻重来过两次现在算是稳定下来了。核心工具就两个WorkBuddy和微信。WorkBuddy 负责干活——抓信息、调模型、生成内容微信负责送达——用最不打扰的方式把结果推到我面前。中间串联的自动化逻辑我用的是deepseek-v4-flash做内容生成和摘要压缩整个链路跑在本地一台 Ubuntu 小主机上通过定时任务触发。这套东西解决了一个很具体的问题我每天需要花 40 到 60 分钟手动浏览各种信息源、整理待办、写日报现在压缩到 0 分钟——日报自动生成、自动送达我只需要花 3 分钟扫一眼决定哪些事需要跟进。适合谁参考如果你每天有大量重复性的信息整理工作或者你想把某个 AI 能力“嵌入”到日常通讯工具里而不是每次都打开一个网页去对话那这套思路可以直接抄。我先把整体架构说清楚再拆细节。整个链路是这样的定时触发 → WorkBuddy 执行任务流 → 调用 deepseek-v4-flash 生成内容 → 格式化输出 → 通过微信接口推送 → 我收到消息。看起来简单但每个环节都有坑尤其是微信这一端限制比想象中多。2. 整体方案设计与核心思路拆解2.1 为什么选 WorkBuddy 而不是自己写脚本一开始我是自己写 Python 脚本的。用requests抓 RSS用schedule做定时用smtplib发邮件。跑了大概两周问题越来越多信息源格式一变就要改代码摘要质量不稳定而且我发现自己大部分时间花在“维护脚本”而不是“用结果”上。后来换成 WorkBuddy核心原因是它把“任务编排”这件事抽象出来了。我不需要关心某个信息源是 RSS 还是 API不需要处理编码问题不需要自己写重试逻辑。WorkBuddy 的 skill 机制让我可以把“抓取”“摘要”“格式化”“推送”拆成独立步骤每个步骤可以单独调试、单独替换。这比一坨 Python 脚本好维护太多。另一个关键点是deepseek-v4-flash的接入。WorkBuddy 本身支持多种模型我选 deepseek-v4-flash 是因为它在摘要任务上的表现很稳——速度快、成本低、对中文内容的压缩质量比我试过的几个模型都好。尤其是处理技术类内容时它不会把关键信息“摘要掉”而是能保留核心结论和参数。2.2 微信推送的三种方案对比微信这一端是最麻烦的。我前后试过三种方案最后选了第三种。方案实现方式优点缺点适用场景邮件转微信发邮件到微信绑定邮箱实现简单延迟高、格式乱不推荐企业微信机器人Webhook 推送稳定、支持 Markdown需要企业微信有企业微信的用户微信文件传输助手通过自动化工具模拟发送直接进微信需要保持客户端在线个人用户首选我最终用的是文件传输助手方案。具体做法是在 Ubuntu 主机上跑一个自动化工具模拟微信客户端的操作把生成好的日报内容发送到“文件传输助手”。这样我在手机微信上就能直接看到而且文件传输助手不会像群消息那样打扰别人。注意这个方案需要你的微信客户端保持在线而且自动化工具的操作频率不能太高否则容易触发风控。我设置的是每天只发一次目前跑了半年没有出过问题。2.3 为什么是上午十点半这个时间点是我反复调整后定下来的。太早信息源还没更新完太晚我已经开始处理当天任务了日报的参考价值下降。十点半刚好是大部分信息源完成当日更新、而我还没有完全进入深度工作状态的窗口期。另外十点半这个时间点还有一个好处如果日报生成失败我还有足够的时间在中午之前手动补上。我设置了一个简单的失败告警——如果十点半没有收到日报十点四十五会再试一次如果还失败会通过另一个通道给我发一个简短提醒。3. 核心细节解析与实操要点3.1 WorkBuddy 任务流的设计原则WorkBuddy 的任务流设计有一个核心原则每个步骤只做一件事步骤之间通过标准格式传递数据。我的日报任务流一共分四步信息采集从预设的信息源列表抓取内容输出为 JSON 格式内容摘要调用 deepseek-v4-flash 对每条内容生成 2-3 句摘要日报组装按照固定模板把摘要组装成 Markdown 格式推送执行调用微信推送脚本把 Markdown 转成纯文本发送这样设计的好处是如果某个信息源挂了只有第一步会报错后面的步骤可以用缓存数据继续跑。如果摘要质量不好我只需要调整第二步的 prompt不用动其他部分。3.2 deepseek-v4-flash 的调用参数怎么调摘要任务对模型的要求比较特殊既要压缩信息又不能丢失关键结论。我试过几组参数最后稳定在这套配置上temperature: 0.3太低会照抄原文太高会编造内容max_tokens: 800足够覆盖大部分摘要需求又不会让模型“话太多”top_p: 0.9保持一定的多样性避免摘要千篇一律Prompt 我是这样写的你是一个技术日报编辑。请对以下内容生成 2-3 句摘要要求 1. 保留核心结论和关键参数 2. 删除广告、重复内容和无关背景 3. 如果内容涉及具体数字或版本号必须保留 4. 用简洁的中文表达不要用“本文介绍了”这类开头 内容 {content}这套 prompt 我调了大概七八版才稳定下来。早期版本经常把“某模型发布了新版本”摘要成“有新的进展”关键版本号全丢了。后来加了“必须保留数字和版本号”这条约束质量明显提升。3.3 微信推送的格式处理微信文件传输助手对 Markdown 的支持很有限。我试过直接发 Markdown结果在手机上显示一堆#和*很难看。后来改成纯文本格式用简单的符号做层级【AI 日报】2025-XX-XX 一、昨日任务回顾 1. 完成 XXX 模块的接口联调 2. 修复 XXX 的兼容性问题 二、今日待办 1. 优先处理 XXX 的反馈 2. 跟进 XXX 的进度 三、行业动态 - XXX 发布了新版本主要更新包括... - XXX 有一篇关于...的分析核心观点是...这种格式在手机上阅读体验最好。我试过用表格但在微信里表格会错位所以放弃了。实操心得微信推送的内容长度最好控制在 2000 字以内。超过这个长度消息会被折叠阅读体验下降。如果内容确实多我会拆成两条发送中间间隔几秒。4. 实操过程与核心环节实现4.1 环境准备与 WorkBuddy 安装我的运行环境是一台 Ubuntu 22.04 的小主机配置不高4 核 8G跑这套东西绰绰有余。WorkBuddy 的安装过程不复杂但有几个细节需要注意。首先确认系统依赖sudo apt update sudo apt install -y python3-pip python3-venv git curl然后创建工作目录并安装 WorkBuddymkdir -p ~/workbuddy-daily cd ~/workbuddy-daily python3 -m venv venv source venv/bin/activate pip install workbuddy安装完成后需要初始化配置。WorkBuddy 的配置文件默认在~/.workbuddy/config.yaml我建议直接在这个文件里写配置而不是用命令行参数因为定时任务调用时命令行参数容易出错。配置文件的关键部分model: provider: deepseek name: deepseek-v4-flash api_key: your_api_key_here temperature: 0.3 max_tokens: 800 tasks: daily_report: steps: - collect - summarize - format - push注意API key 不要直接写在配置文件里然后提交到 git。我是用环境变量注入的配置文件里只写${DEEPSEEK_API_KEY}然后在定时任务的脚本里 export 这个变量。4.2 信息采集步骤的实现信息采集我分了三个来源RSS 订阅、特定网页的更新、以及我自己的待办清单。RSS 部分 WorkBuddy 有内置支持直接配置 feed 地址就行。网页更新部分需要写一个简单的抓取脚本。我的采集脚本核心逻辑是这样的import feedparser import requests from bs4 import BeautifulSoup def collect_rss(feed_urls): items [] for url in feed_urls: feed feedparser.parse(url) for entry in feed.entries[:5]: items.append({ title: entry.title, link: entry.link, summary: entry.get(summary, ), source: url }) return items def collect_webpage(url, selector): resp requests.get(url, timeout10) soup BeautifulSoup(resp.text, html.parser) elements soup.select(selector) return [{title: el.get_text(stripTrue), link: url} for el in elements[:5]]采集频率我设置的是每天一次在十点十五分执行。这样十点半推送时数据是新鲜的。4.3 摘要生成与日报组装摘要生成这一步我把采集到的每条内容单独发给 deepseek-v4-flash而不是一次性发所有内容。这样做的好处是每条摘要的质量更稳定而且如果某条内容特别长不会影响其他内容的摘要。组装日报时我用了简单的模板引擎。核心逻辑是把摘要按类别分组然后套用固定格式def build_report(summaries, todos): lines [] lines.append(f【AI 日报】{datetime.now().strftime(%Y-%m-%d)}) lines.append() lines.append(一、昨日任务回顾) for i, todo in enumerate(todos[done], 1): lines.append(f{i}. {todo}) lines.append() lines.append(二、今日待办) for i, todo in enumerate(todos[pending], 1): lines.append(f{i}. {todo}) lines.append() lines.append(三、行业动态) for s in summaries: lines.append(f- {s}) return \n.join(lines)4.4 微信推送的自动化实现这是整个链路里最“脆”的一环。我用的方案是在 Ubuntu 上跑一个微信客户端然后通过自动化工具模拟发送操作。具体工具这里不展开核心思路是保持客户端在线通过脚本触发发送动作发送内容从文件读取。推送脚本的关键逻辑#!/bin/bash REPORT_FILE/tmp/daily_report.txt if [ ! -f $REPORT_FILE ]; then echo Report file not found exit 1 fi # 调用自动化工具发送文件内容 # 具体命令根据你用的工具调整 send_to_wechat --target filehelper --content $(cat $REPORT_FILE)实操心得推送脚本一定要加超时和重试。我遇到过微信客户端卡死的情况脚本一直等在那里导致后面的定时任务全部堵住。后来加了timeout 30和最多两次重试稳定多了。4.5 定时任务的配置我用的是系统自带的 cron没有用更复杂的调度工具。cron 的配置很简单# 每天十点十五分采集 15 10 * * * /home/user/workbuddy-daily/venv/bin/python /home/user/workbuddy-daily/collect.py /var/log/workbuddy.log 21 # 每天十点二十五分生成日报 25 10 * * * /home/user/workbuddy-daily/venv/bin/python /home/user/workbuddy-daily/generate.py /var/log/workbuddy.log 21 # 每天十点半推送 30 10 * * * /home/user/workbuddy-daily/push.sh /var/log/workbuddy.log 21三个任务分开跑而不是串在一个脚本里是为了方便排查问题。如果日报没收到我可以先看采集日志再看生成日志最后看推送日志很快能定位到是哪一步出了问题。5. 常见问题与排查技巧实录5.1 日报没有准时收到怎么办这是最常见的问题。我的排查顺序是这样的先看日志tail -50 /var/log/workbuddy.log看有没有明显的报错检查采集步骤手动跑一次采集脚本看是否能正常获取数据检查模型调用确认 API key 是否过期额度是否用完检查微信客户端确认客户端是否在线是否被系统休眠影响检查 cron 服务systemctl status cron确认定时任务服务正常大部分情况下问题出在第三步或第四步。API key 过期我遇到过两次微信客户端掉线遇到过三四次。5.2 摘要质量不稳定的调整方法摘要质量波动是正常现象但如果波动太大可以从这几个方面调整检查输入内容如果原始内容本身就很短或很乱摘要质量肯定好不了调整 prompt在 prompt 里加更具体的约束比如“如果内容包含代码保留代码逻辑描述”调整 temperature如果摘要太死板适当调高如果摘要开始编造内容调低分批处理把长内容拆成多段分别摘要再合并我自己的经验是prompt 的约束越具体摘要质量越稳定。早期我用“请生成摘要”这种模糊指令结果每次格式都不一样。后来改成“生成 2-3 句保留数字和版本号删除广告”质量就稳定多了。5.3 微信推送失败的几种典型情况现象可能原因解决方法消息发送成功但内容为空文件读取失败检查文件路径和权限消息发送失败客户端未登录重新登录微信客户端消息延迟很久才到客户端卡顿重启客户端检查系统资源消息内容被截断内容过长拆分成多条发送频繁失败触发风控降低发送频率增加随机延迟注意微信自动化操作有频率限制不要设置太高的发送频率。我每天只发一次偶尔测试时最多发两三次目前没有遇到风控问题。5.4 如何扩展这套方案这套方案的核心思路是“定时触发 AI 处理 通讯工具送达”这个模式可以扩展到很多场景周报自动生成把每日日报积累起来每周五自动生成周报特定主题监控只关注某个关键词或某个信息源有更新时即时推送多通道送达除了微信还可以同时推送到邮件、笔记软件等交互式查询在微信里发送特定指令触发 WorkBuddy 执行特定任务并返回结果我目前正在尝试第四个方向让日报不只是“推送”而是可以“对话”。比如我回复“详细说说第三条”WorkBuddy 会把第三条的完整内容发给我。这个功能还在调试中主要难点是微信端的消息接收和解析。6. 一些踩坑之后的个人体会这套东西跑到现在最大的体会是自动化不是目的减少干扰才是。我早期版本每天推送的内容特别多结果我反而不看了因为信息过载。后来把日报压缩到 500 字以内只保留最核心的几条阅读率反而上去了。另一个体会是不要追求一步到位。我最开始的版本特别简陋就是抓几个 RSS 然后拼在一起发过来。后来慢慢加摘要、加待办、加格式优化迭代了十几版才到现在这个样子。如果你也想搭一套类似的系统建议先从最简单的版本开始跑起来然后再逐步优化。最后一个建议给自动化系统留一个“手动开关”。我设置了一个命令可以手动触发日报生成和推送。有时候我周末想看看本周的汇总或者某天日报生成失败了想补一份这个手动开关就很有用。自动化是为了省事但不能把自己完全“锁死”在自动化流程里。