1. 从一条定时任务说起为什么我要给 WorkBuddy 设个闹钟每天早上到工位第一件事不是泡咖啡而是打开各种信息源翻一遍行业动态、竞品更新、技术社区热帖、内部群里的零散讨论。翻完一圈半小时没了真正有价值的信息可能就三五条。这种低效的重复劳动我忍了很久。后来我开始用 WorkBuddy 做日常任务管理某天突然想到既然它能调 DeepSeek 的接口做内容生成那为什么不干脆让它每天早上自动跑一遍信息汇总生成一份 AI 日报直接推到我微信上这样我人到工位日报已经在手机里躺着了。说干就干。整个方案的核心链路其实不复杂定时触发 → 拉取信息源 → 调 DeepSeek 生成摘要 → 推送到微信。但真正落地的时候每个环节都有坑。比如定时任务用什么跑、DeepSeek 的 API 怎么调才稳定、微信推送走什么通道最省事、日报的 prompt 怎么设计才能让输出不像废话。这些问题我在实操中一个个踩过来了这篇文章就把完整方案和踩坑经验分享出来。这套东西适合谁如果你每天需要花大量时间做信息筛选和汇总或者你想找一个 AI 自动化的入门项目练手再或者你已经在用 WorkBuddy 但只停留在手动对话阶段那这篇内容应该能给你一些直接能抄的作业。不需要你是专业开发基础的 Python 能看懂就行。2. 整体方案设计与技术选型思路2.1 为什么选 WorkBuddy 作为调度中枢市面上做定时任务的工具很多Linux 的 crontab、Windows 的任务计划程序、各种 CI/CD 平台的定时触发甚至用 Python 的 schedule 库自己写一个都行。我最终选 WorkBuddy 作为调度中枢主要考虑三点。第一是统一管理。我日常的任务管理、笔记、部分自动化脚本都挂在 WorkBuddy 上日报任务放在同一个地方不用再单独维护一套调度系统。第二是规则复用。WorkBuddy 支持给任务设定规则比如后续所有任务都生效的全局规则我可以定义好输出格式规范、错误处理策略日报任务直接继承。第三是调试方便。WorkBuddy 的工作台可以直接看到每次任务的执行日志和输出出了问题不用去翻服务器日志。当然如果你还没用 WorkBuddy用 crontab 加一个 Python 脚本也能实现同样的效果后面的核心逻辑是通用的。工具只是壳思路才是关键。2.2 信息源的选择与取舍日报的内容质量八成取决于你喂给 AI 的原始信息。我一开始贪多把能想到的信息源全塞进去了技术社区热榜、行业新闻 RSS、几个竞品的更新日志、内部知识库的新增文档。结果生成的日报又长又杂重点全被淹没了。后来我做了减法只保留三类信息源必看类直接影响我当天工作的信息比如内部项目的更新通知、关键竞品的功能变更参考类行业趋势、技术动态每周看两三次就够的灵感类社区里的讨论帖、别人的经验分享偶尔能触发一些新想法每类信息源控制在 3 到 5 个总量不超过 15 个。这个量级下DeepSeek 生成的摘要既能覆盖重点又不会因为信息过载而输出一堆正确的废话。提示信息源不是越多越好。我实测下来超过 20 个信息源之后日报的有效信息密度反而下降因为 AI 会把大量篇幅花在平衡各个来源上而不是提炼真正重要的内容。2.3 DeepSeek 在链路中的角色定位DeepSeek 在这套方案里承担的是信息压缩和结构化的工作不是做深度分析。具体来说它需要完成三件事把不同格式的原始信息统一成可读的文本、按重要性排序并提炼要点、用我习惯的表达方式输出。这里有个关键认知不要指望 AI 帮你判断什么重要。重要性排序的规则应该由你来定AI 只负责执行。比如我会在 prompt 里明确告诉它内部项目更新优先级最高竞品动态次之行业新闻最低。如果某条信息涉及我负责的模块单独标出来。这样输出的日报才有针对性。选 DeepSeek 而不是其他模型主要是考虑成本和中文理解能力。日报这种每天都要跑的任务token 消耗累积起来不小DeepSeek 的性价比在这个场景下很合适。而且它对中文技术内容的摘要质量我实测比几个同类模型要稳。2.4 微信推送通道的对比与选择推送通道我试过三种方案各有优劣方案实现难度稳定性消息形态适用场景企业微信机器人低高文本/Markdown个人使用有企业微信微信服务号模板消息中中结构化卡片需要推送给多人文件传输助手自动化高低纯文本不想折腾服务号我最终选了企业微信机器人。原因很简单创建一个群加一个机器人拿到 Webhook 地址往那个地址 POST 数据就行。不需要认证服务号不需要处理 access_token 刷新也不依赖任何非官方的自动化工具。整个推送环节的代码不超过 20 行。如果你没有企业微信服务号模板消息是次优选择但需要处理 token 管理和消息模板审核。文件传输助手的方案我不推荐依赖 UI 自动化稳定性差微信版本一更新就可能失效。3. 核心环节拆解与实操要点3.1 定时触发的实现细节WorkBuddy 的定时任务配置界面比较直观设置每天上午 10:30 触发即可。但有几个细节需要注意。时区问题。如果你的服务器或者 WorkBuddy 工作区的时区设置不是东八区10:30 可能变成凌晨或者下午。我第一次配置的时候就踩了这个坑日报在凌晨三点推过来手机震醒了我。检查时区的地方通常在设置里的区域或时间选项确认是 UTC8 再保存。触发时间的容错。10:30 是个比较尴尬的时间点如果那个时刻正好有别的任务在跑可能会排队等待。我的做法是设两个触发点10:30 为主10:45 为备用。主任务成功执行后写一个标记备用任务检查到标记就跳过。这样即使主任务因为资源占用延迟了也不会漏掉当天的日报。失败重试策略。网络抖动、API 限流、信息源暂时不可用这些都会导致任务失败。我在 WorkBuddy 的规则里设置了最多重试 3 次间隔分别是 1 分钟、5 分钟、15 分钟。超过 3 次就发一条告警消息到微信告诉我今天日报生成失败了而不是默默吞掉。3.2 信息拉取与预处理信息拉取这部分不同来源的处理方式不一样。RSS 源用 feedparser 解析API 接口用 requests 拉 JSON网页内容用 BeautifulSoup 提取正文。核心原则是在送给 DeepSeek 之前尽量把噪音去掉。我写了一个预处理函数做三件事去掉 HTML 标签和多余空白、截断过长的内容单条不超过 500 字、给每条信息打上来源标签。这样 DeepSeek 拿到的就是干净的文本不用浪费 token 去理解格式。import feedparser import requests from bs4 import BeautifulSoup def fetch_rss(url, max_items5): feed feedparser.parse(url) items [] for entry in feed.entries[:max_items]: content entry.get(summary, ) soup BeautifulSoup(content, html.parser) text soup.get_text(stripTrue)[:500] items.append({ source: feed.feed.get(title, RSS), title: entry.title, content: text }) return items def fetch_api(url, headersNone, max_items5): resp requests.get(url, headersheaders, timeout10) data resp.json() items [] for item in data.get(items, [])[:max_items]: items.append({ source: API, title: item.get(title, ), content: item.get(description, )[:500] }) return items注意拉取信息的时候一定要设超时。我有一次没设 timeout某个信息源响应极慢整个任务卡了十几分钟后面的推送全乱了。现在所有网络请求统一 10 秒超时超时就跳过该来源在日报末尾标注某来源今日不可用。3.3 DeepSeek API 调用的参数调优调用 DeepSeek 的 API 生成日报prompt 的设计比参数调优更重要。但参数也不能忽视我经过多次测试固定了一套配置temperature 设为 0.3。日报需要的是稳定、可预期的输出不需要创意发挥。0.3 这个值能让输出保持一定的语言流畅度同时不会偏离事实太远。max_tokens 设为 2000。一份日报控制在 1500 字左右比较合适留 500 token 的余量防止截断。top_p 设为 0.9。配合低 temperature 使用进一步收窄输出的随机性。prompt 的结构我分成四段角色设定、任务说明、输出格式、示例。角色设定告诉它你是一个技术日报编辑任务说明写清楚从以下信息中提炼 5 到 8 条要点输出格式用 Markdown 定义好标题层级和列表样式示例给一条理想输出的样子。def generate_daily_report(items): prompt f你是一个技术日报编辑。请从以下信息中提炼 5-8 条要点按重要性排序。 要求 1. 内部项目更新优先级最高单独列出 2. 每条要点不超过 80 字 3. 用 Markdown 格式输出标题用 ##要点用 - 4. 如果某条信息涉及我负责的模块在末尾标注 [相关] 信息源 {format_items(items)} 输出格式示例 ## 今日要点 - 要点内容 [相关] - 要点内容 resp requests.post( https://api.deepseek.com/v1/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.3, max_tokens: 2000, top_p: 0.9 }, timeout30 ) return resp.json()[choices][0][message][content]3.4 微信推送的落地实现企业微信机器人的推送非常简单拿到 Webhook 地址后构造一个 JSON 发过去就行。支持文本和 Markdown 两种消息类型日报用 Markdown 格式展示效果更好。def push_to_wechat(content): webhook https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_KEY payload { msgtype: markdown, markdown: {content: content} } resp requests.post(webhook, jsonpayload, timeout10) return resp.json()这里有个细节企业微信机器人的 Markdown 不支持所有语法标题只能用#到######列表用-加粗用**。表格和代码块不支持。所以我在生成日报的时候会让 DeepSeek 避免使用这些格式或者推送前做一次格式转换。提示Webhook 的 key 不要硬编码在代码里放到环境变量或者 WorkBuddy 的密钥管理里。我见过有人把 key 提交到公开仓库结果被滥用发了一堆垃圾消息。4. 完整实操流程与关键配置4.1 环境准备与依赖安装整套方案跑起来需要的依赖不多Python 3.8 以上就行。核心库就四个requests 做网络请求、feedparser 解析 RSS、beautifulsoup4 提取网页正文、schedule 做本地定时如果你不用 WorkBuddy 的定时功能。pip install requests feedparser beautifulsoup4 schedule如果你用 WorkBuddy 的定时功能schedule 库可以省掉。但建议还是装上本地调试的时候方便不用每次都去 WorkBuddy 上手动触发。环境变量需要配置三个DEEPSEEK_API_KEY、WECHAT_WEBHOOK、TIMEZONE。前两个是密钥第三个设成Asia/Shanghai确保时间正确。4.2 信息源配置文件的编写我把信息源配置抽成一个独立的 JSON 文件方便增删改不用动代码。{ sources: [ { name: 内部项目更新, type: api, url: https://internal.example.com/api/updates, priority: 1, max_items: 5 }, { name: 技术社区热榜, type: rss, url: https://example.com/feed.xml, priority: 3, max_items: 5 } ] }priority 字段控制信息在 prompt 里的排序数字越小优先级越高。DeepSeek 拿到的信息是按优先级排列的这样它在提炼要点的时候会自然地把高优先级内容放在前面。4.3 主流程代码的串联把前面几个模块串起来主流程大概长这样import os import json from datetime import datetime def main(): # 1. 读取配置 with open(sources.json, r) as f: config json.load(f) # 2. 拉取所有信息源 all_items [] for source in config[sources]: try: if source[type] rss: items fetch_rss(source[url], source[max_items]) elif source[type] api: items fetch_api(source[url], max_itemssource[max_items]) for item in items: item[priority] source[priority] all_items.extend(items) except Exception as e: print(f拉取 {source[name]} 失败: {e}) # 3. 按优先级排序 all_items.sort(keylambda x: x[priority]) # 4. 生成日报 report generate_daily_report(all_items) # 5. 加上日期头 today datetime.now().strftime(%Y年%m月%d日) full_report f# AI 日报 - {today}\n\n{report} # 6. 推送到微信 result push_to_wechat(full_report) print(f推送结果: {result}) if __name__ __main__: main()这段代码在本地跑通之后直接搬到 WorkBuddy 的任务里设置好定时触发就行。WorkBuddy 的工作台可以看每次执行的输出方便排查问题。4.4 日报模板的迭代优化第一版日报生成出来的时候我看了直摇头。DeepSeek 把每条信息都压缩成一句话读起来像新闻标题列表完全没有重点。后来我调整了 prompt加了几个约束要求它把相关的信息合并成一条而不是逐条罗列要求它对每条要点加一句为什么重要的说明要求它在末尾加一个今日建议关注的板块挑一条最值得深入看的调整之后日报的可读性明显提升。现在每天早上收到的那条消息我基本扫一眼就能抓住当天需要关注的重点。提示日报模板不要一次定死。我前两周每天收到日报后都会花一分钟想想哪里可以改进然后调整 prompt。迭代了大概五六版之后输出质量才稳定下来。这个过程是值得的因为日报是每天都要看的东西多花点时间打磨很划算。5. 常见问题与排查技巧实录5.1 推送失败的那些原因推送失败是最常见的问题我遇到过几种情况Webhook 地址失效。企业微信机器人的 Webhook 如果长时间不用或者群被解散了地址就会失效。表现是 POST 请求返回错误码。解决办法是重新创建机器人更新环境变量。消息内容超长。企业微信 Markdown 消息有长度限制超过 4096 字节会被截断。日报如果信息源太多很容易超。我的做法是在推送前检查长度超过 3500 字节就自动截断并在末尾加一句内容过长已截断。频率限制。企业微信机器人每个分钟最多发 20 条消息。日报一天一条正常不会触发。但如果你在调试的时候反复触发可能会被限流。等一分钟再试就行。5.2 DeepSeek 输出不稳定的处理DeepSeek 的输出偶尔会跑偏比如把不重要的信息放在前面或者输出格式不对。我总结了几个应对策略问题表现可能原因解决方法输出格式混乱prompt 里的格式说明不够明确加一个完整的输出示例重点排序错误优先级信息没有传给模型在 prompt 里显式标注优先级内容过于简略max_tokens 设太小调到 2000 以上出现重复内容信息源本身有重复预处理时做去重去重这个事我单独说一下。不同信息源之间经常有重叠内容比如同一个新闻被多个源报道。如果不做去重DeepSeek 会把它当成多条独立信息浪费篇幅。我的做法是用标题的相似度做简单去重相似度超过 80% 的只保留优先级最高的那条。5.3 定时任务不执行的排查WorkBuddy 的定时任务偶尔会不触发排查思路按这个顺序来检查任务状态是否被暂停检查时区设置是否正确查看上次执行日志看是否有报错确认 WorkBuddy 服务本身是否正常我遇到过一次任务不执行查了半天发现是时区设置被改成了 UTC10:30 变成了北京时间 18:30。所以时区这个问题值得反复确认。5.4 几个提升稳定性的小技巧加一个心跳检测。每天日报推送成功后往一个单独的日志文件写一条记录。如果连续两天没有记录说明任务出问题了需要检查。信息源做降级处理。某个源拉取失败时不要让它影响整个任务。我的做法是每个源独立 try-catch失败的源在日报末尾统一标注而不是让整个任务挂掉。API key 做轮换准备。如果你有多个 DeepSeek API key可以在代码里做一个简单的轮询。某个 key 触发限流时自动切换到下一个。这个不是必须的但如果你对稳定性要求高值得加上。日报内容做本地备份。每天生成的日报除了推送还存一份到本地文件。这样即使推送失败你也能在本地找到当天的日报。我按月份建文件夹文件名用日期找起来很方便。6. 后续可以扩展的方向这套方案跑顺之后我陆续加了一些扩展。比如在日报末尾加一个昨日回顾板块把前一天标记为相关的要点重新列出来看看有没有后续进展。再比如加一个简单的反馈机制我在微信里回复1表示日报有用2表示需要调整WorkBuddy 收到反馈后记录到日志里方便我后续优化 prompt。还有一个想法是把这个方案扩展到周报和月报。日报是信息汇总周报可以做趋势分析月报可以做总结回顾。底层逻辑是一样的只是 prompt 和信息源的时间范围不同。等我把日报再跑一段时间积累足够的数据就准备动手做周报版本。如果你也在用 WorkBuddy 或者类似的工具我建议从最简单的版本开始一个信息源、一个推送通道、一个定时任务。跑通之后再逐步加东西。我见过太多人一上来就想做全套结果卡在某个环节就放弃了。先让日报跑起来哪怕内容粗糙一点有了正反馈之后再迭代这条路会好走很多。