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 微信推送的三种方案对比

微信这一端是最麻烦的。我前后试过三种方案，最后选了第三种。

我最终用的是文件传输助手方案。具体做法是：在 Ubuntu 主机上跑一个自动化工具，模拟微信客户端的操作，把生成好的日报内容发送到“文件传输助手”。这样我在手机微信上就能直接看到，而且文件传输助手不会像群消息那样打扰别人。

注意：这个方案需要你的微信客户端保持在线，而且自动化工具的操作频率不能太高，否则容易触发风控。我设置的是每天只发一次，目前跑了半年没有出过问题。

2.3 为什么是上午十点半

这个时间点是我反复调整后定下来的。太早，信息源还没更新完；太晚，我已经开始处理当天任务了，日报的参考价值下降。十点半刚好是大部分信息源完成当日更新、而我还没有完全进入深度工作状态的窗口期。

另外，十点半这个时间点还有一个好处：如果日报生成失败，我还有足够的时间在中午之前手动补上。我设置了一个简单的失败告警——如果十点半没有收到日报，十点四十五会再试一次，如果还失败，会通过另一个通道给我发一个简短提醒。

3. 核心细节解析与实操要点

3.1 WorkBuddy 任务流的设计原则

WorkBuddy 的任务流设计有一个核心原则：每个步骤只做一件事，步骤之间通过标准格式传递数据。我的日报任务流一共分四步：

1. 信息采集：从预设的信息源列表抓取内容，输出为 JSON 格式
2. 内容摘要：调用 deepseek-v4-flash 对每条内容生成 2-3 句摘要
3. 日报组装：按照固定模板把摘要组装成 Markdown 格式
4. 推送执行：调用微信推送脚本，把 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

然后创建工作目录并安装 WorkBuddy：

mkdir -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, timeout=10) soup = BeautifulSoup(resp.text, "html.parser") elements = soup.select(selector) return [{"title": el.get_text(strip=True), "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 2>&1 # 每天十点二十五分生成日报 25 10 * * * /home/user/workbuddy-daily/venv/bin/python /home/user/workbuddy-daily/generate.py >> /var/log/workbuddy.log 2>&1 # 每天十点半推送 30 10 * * * /home/user/workbuddy-daily/push.sh >> /var/log/workbuddy.log 2>&1

三个任务分开跑，而不是串在一个脚本里，是为了方便排查问题。如果日报没收到，我可以先看采集日志，再看生成日志，最后看推送日志，很快能定位到是哪一步出了问题。

5. 常见问题与排查技巧实录

5.1 日报没有准时收到怎么办

这是最常见的问题。我的排查顺序是这样的：

1. 先看日志：tail -50 /var/log/workbuddy.log，看有没有明显的报错
2. 检查采集步骤：手动跑一次采集脚本，看是否能正常获取数据
3. 检查模型调用：确认 API key 是否过期，额度是否用完
4. 检查微信客户端：确认客户端是否在线，是否被系统休眠影响
5. 检查 cron 服务：systemctl status cron，确认定时任务服务正常

大部分情况下，问题出在第三步或第四步。API key 过期我遇到过两次，微信客户端掉线遇到过三四次。

5.2 摘要质量不稳定的调整方法

摘要质量波动是正常现象，但如果波动太大，可以从这几个方面调整：

• 检查输入内容：如果原始内容本身就很短或很乱，摘要质量肯定好不了
• 调整 prompt：在 prompt 里加更具体的约束，比如“如果内容包含代码，保留代码逻辑描述”
• 调整 temperature：如果摘要太死板，适当调高；如果摘要开始编造内容，调低
• 分批处理：把长内容拆成多段分别摘要，再合并

我自己的经验是，prompt 的约束越具体，摘要质量越稳定。早期我用“请生成摘要”这种模糊指令，结果每次格式都不一样。后来改成“生成 2-3 句，保留数字和版本号，删除广告”，质量就稳定多了。

5.3 微信推送失败的几种典型情况

注意：微信自动化操作有频率限制，不要设置太高的发送频率。我每天只发一次，偶尔测试时最多发两三次，目前没有遇到风控问题。

5.4 如何扩展这套方案

这套方案的核心思路是“定时触发 + AI 处理 + 通讯工具送达”，这个模式可以扩展到很多场景：

• 周报自动生成：把每日日报积累起来，每周五自动生成周报
• 特定主题监控：只关注某个关键词或某个信息源，有更新时即时推送
• 多通道送达：除了微信，还可以同时推送到邮件、笔记软件等
• 交互式查询：在微信里发送特定指令，触发 WorkBuddy 执行特定任务并返回结果

我目前正在尝试第四个方向，让日报不只是“推送”，而是可以“对话”。比如我回复“详细说说第三条”，WorkBuddy 会把第三条的完整内容发给我。这个功能还在调试中，主要难点是微信端的消息接收和解析。

6. 一些踩坑之后的个人体会

这套东西跑到现在，最大的体会是：自动化不是目的，减少干扰才是。我早期版本每天推送的内容特别多，结果我反而不看了，因为信息过载。后来把日报压缩到 500 字以内，只保留最核心的几条，阅读率反而上去了。

另一个体会是，不要追求一步到位。我最开始的版本特别简陋，就是抓几个 RSS 然后拼在一起发过来。后来慢慢加摘要、加待办、加格式优化，迭代了十几版才到现在这个样子。如果你也想搭一套类似的系统，建议先从最简单的版本开始跑起来，然后再逐步优化。

最后一个建议：给自动化系统留一个“手动开关”。我设置了一个命令，可以手动触发日报生成和推送。有时候我周末想看看本周的汇总，或者某天日报生成失败了想补一份，这个手动开关就很有用。自动化是为了省事，但不能把自己完全“锁死”在自动化流程里。