1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事是打开电脑第二件事是翻各种信息源项目群里的消息、昨天提交的代码有没有跑完、待办事项里哪些今天到期、行业里又出了什么新东西。这套动作熟练之后大概要花二十分钟但问题是它每天都在重复而且一旦忙起来就容易漏掉关键信息。我试过用待办清单、日历提醒、甚至手动写脚本抓 RSS但最后都因为维护成本太高而放弃。直到我把 WorkBuddy 用起来之后事情有了转机。WorkBuddy 本质上是一个可以挂载各种技能Skill的工作台它支持定时触发、支持调用外部 API、支持把结果推送到指定渠道。我当时的想法很简单既然它能在后台跑任务那我为什么不把“每天早上整理信息”这件事交给它于是就有了这个项目——每天上午十点半让 WorkBuddy 自动生成一份 AI 日报然后通过微信推送到我的手机上。这个项目的核心价值不在于技术有多复杂而在于它真正解决了一个高频、重复、容易遗漏的痛点。你不需要是自动化测试工程师也不需要懂 pytest 或者 appium 那一套只要你会配置 WorkBuddy 的定时任务、会调用 DeepSeek 的 API、会用一个简单的推送通道就能在半小时内把这套流程跑通。适合谁来参考我觉得三类人最合适一是每天需要处理大量信息的运营或产品岗二是想入门自动化但不知道从哪下手的技术新手三是已经在用 WorkBuddy 但还没把它“定时化”的老用户。下面我会把整个项目的设计思路、关键细节、实操步骤、踩过的坑全部拆开讲。文章里涉及到的参数和配置都是我实际跑通之后验证过的你可以直接抄作业。2. 整体方案设计与核心思路拆解2.1 为什么选 WorkBuddy 而不是自己写脚本我一开始确实想过自己写一个 Python 脚本用 crontab 定时跑然后调 DeepSeek 的 API 生成日报最后用某个推送服务发到微信。这个方案技术上完全可行但我实际评估之后放弃了原因有三个。第一维护成本。自己写脚本意味着你要处理依赖安装、环境变量管理、日志记录、异常重试、进程守护这一整套东西。crontab 虽然简单但一旦脚本报错你很难第一时间知道。WorkBuddy 本身就是一个常驻的工作台它的定时任务机制已经帮你处理了调度和基础容错你只需要关注业务逻辑。第二技能复用。WorkBuddy 的 Skill 机制允许你把一个任务拆成多个可复用的模块。比如“抓取信息”是一个 Skill“调用 DeepSeek 生成摘要”是另一个 Skill“推送到微信”又是一个 Skill。这三个 Skill 可以独立调试也可以组合成一个完整的工作流。自己写脚本的话这些逻辑全揉在一个文件里改一处容易影响全局。第三扩展性。我后面可能会想把日报同时推送到邮件、飞书或者钉钉如果用的是 WorkBuddy只需要加一个推送 Skill 就行。自己写脚本的话每加一个渠道就要改一次代码还要重新测试。当然WorkBuddy 也不是没有缺点。它的定时任务精度取决于工作台的运行状态如果工作台本身挂了任务就不会触发。所以我在方案里加了一个“心跳检查”的机制后面会详细讲。2.2 日报的内容结构是怎么定的一份 AI 日报到底应该包含什么我一开始想得很复杂恨不得把当天所有 AI 相关的新闻都抓进来。但实际跑了两天之后发现信息量太大反而没人看。于是我重新设计了日报的结构最终定下来四个板块今日要闻3 到 5 条最重要的 AI 行业动态每条不超过 50 字。技术速递1 到 2 个值得关注的技术更新或工具发布比如 DeepSeek 的新版本、某个自动化框架的重要更新。待办提醒从我的待办清单里抓取当天到期的任务最多 5 条。一句总结用一句话概括今天的整体状态比如“今天信息量适中建议优先处理待办中的第 2 项”。这个结构的好处是它既有外部信息也有内部提醒而且总量可控。我实测下来整份日报的阅读时间大概在 90 秒左右正好是早上喝咖啡的间隙。2.3 为什么选 DeepSeek 作为生成引擎生成日报的核心是把抓取到的原始信息压缩成可读的摘要。我对比过几个方案直接用规则模板拼接、用本地小模型、用 DeepSeek 的 API。最后选 DeepSeek 的原因很直接——它的中文摘要能力在同等成本下是最稳的。我试过用规则模板比如“今天有 X 条新闻其中 Y 条关于大模型”但这种方式太死板遇到不同格式的信息源就容易出错。本地小模型我也试过在 Jetson Orin 上部署了一个 7B 的模型生成质量勉强能用但推理速度太慢一份日报要等将近一分钟。DeepSeek 的 API 调用一次大概几秒钟成本也很低对于每天一次的任务来说完全可以接受。这里有一个细节需要注意DeepSeek 的 API 返回格式是 JSON你需要自己解析出choices[0].message.content这个字段。如果你用的是 WorkBuddy 的 HTTP 请求 Skill记得在配置里把响应体的解析路径写对否则拿到的是一整坨 JSON 字符串还得二次处理。2.4 推送通道为什么选微信推送通道的选择其实挺多的邮件、飞书、钉钉、Telegram、微信。我最后选微信理由很简单——我每天打开频率最高的 App 就是微信。邮件我会积压飞书和钉钉只有工作时间才看Telegram 在国内用起来不方便。微信是唯一一个我早上起床就会刷、上班路上也会看的渠道。具体实现上我没有用微信的官方公众号模板消息因为那个需要认证服务号流程太麻烦。我用的是一个轻量的推送服务它提供了一个 HTTP 接口你往这个接口发一个 POST 请求它就会把消息推送到你的微信上。这个服务的配置很简单注册之后拿到一个 token然后在 WorkBuddy 里配置一个 HTTP 请求 Skill 就行。注意推送服务的选择上建议优先考虑那些不需要复杂认证、支持 HTTPS、且有明确文档的。我踩过一个坑用了一个需要抓包才能配置的服务结果折腾了一下午也没跑通后来换了一个文档清晰的十分钟就搞定了。3. 核心细节解析与实操要点3.1 WorkBuddy 定时任务的配置细节WorkBuddy 的定时任务配置入口在工作台的“任务”面板里你可以新建一个任务然后设置触发条件。触发条件支持 cron 表达式也支持简单的“每天几点几分”这种可视化配置。我选的是可视化配置因为 cron 表达式虽然灵活但容易写错尤其是涉及到时区的时候。这里有一个关键点WorkBuddy 的定时任务默认使用工作台所在服务器的时区。如果你的工作台部署在云服务器上而服务器用的是 UTC 时间那你设置“十点半”的时候要记得换算。我一开始就踩了这个坑设了十点半结果实际推送时间是下午六点半差了八个小时。后来我在任务配置里显式指定了时区问题才解决。另一个细节是任务的超时时间。WorkBuddy 的默认超时是 30 秒但我的日报生成流程涉及到抓取多个信息源、调用 DeepSeek API、再推送到微信整个链路跑下来大概需要 15 到 20 秒。如果你抓取的信息源比较多或者 DeepSeek 的响应比较慢30 秒可能不够。我建议把超时时间设成 60 秒留出足够的余量。3.2 信息抓取 Skill 的配置要点信息抓取是整个流程的第一步也是最容易出问题的一步。我目前抓取的信息源主要有三类RSS 订阅、网页内容、以及我自己的待办清单 API。RSS 订阅是最简单的WorkBuddy 有一个内置的 RSS 解析 Skill你只需要把 RSS 地址填进去它就会返回一个结构化的列表。但要注意有些 RSS 源返回的字段不完整比如只有标题没有摘要这时候你需要在后续的 DeepSeek 调用里做补充。网页内容的抓取稍微复杂一点。我用的方式是 HTTP 请求 Skill 加上一个简单的 HTML 解析。WorkBuddy 支持在 HTTP 请求之后挂一个“提取内容”的步骤你可以用 CSS 选择器或者 XPath 来定位你需要的元素。我实测下来CSS 选择器更稳定因为很多网站的 HTML 结构会变但 class 名一般不会频繁改。待办清单的抓取需要调用我自己的 API。这个 API 是我之前用 Python 写的一个小服务部署在内网返回 JSON 格式的待办列表。WorkBuddy 的 HTTP 请求 Skill 可以直接调用它但要注意内网地址的可达性。如果你的 WorkBuddy 部署在公网而待办 API 在内网你需要确保两者之间的网络是通的或者把待办 API 也暴露到公网记得加认证。3.3 DeepSeek API 调用的参数调优DeepSeek 的 API 调用看起来简单但有几个参数直接影响生成质量。我实际调优之后固定下来一套参数你可以参考参数我的设置说明modeldeepseek-chat通用对话模型摘要任务够用temperature0.3降低随机性保证摘要稳定max_tokens800日报总长度控制在 800 token 以内top_p0.9配合 temperature 使用避免过于保守frequency_penalty0.2轻微惩罚重复用词temperature 这个参数我试过 0.1 到 0.7 的范围。0.1 的时候生成的内容太死板像机器翻译0.7 的时候又太发散有时候会编造不存在的信息。0.3 是我实测下来最平衡的值既保持了摘要的准确性又不会太生硬。还有一个细节是提示词的设计。我一开始的提示词写得很简单“请把以下信息总结成一份日报”。结果 DeepSeek 返回的内容格式五花八门有时候是段落有时候是列表有时候还带 markdown 标题。后来我把提示词改成了结构化输出你是一个 AI 日报生成助手。请根据以下原始信息生成一份日报。 要求 1. 分为四个板块今日要闻、技术速递、待办提醒、一句总结。 2. 今日要闻最多 5 条每条不超过 50 字。 3. 技术速递最多 2 条每条不超过 80 字。 4. 待办提醒最多 5 条直接列出任务名称。 5. 一句总结不超过 30 字。 6. 输出格式为纯文本不要使用 markdown 标题。改完之后生成的内容就稳定多了。3.4 微信推送的格式处理微信推送的内容不能太长否则会被截断。我实测下来单条消息的安全长度大概在 600 到 800 字之间。如果你的日报超过这个长度有两个方案一是压缩内容二是分多条推送。我选的是压缩内容因为分多条推送会打扰用户。压缩的方式是在 DeepSeek 的提示词里明确限制每个板块的字数同时在推送之前做一个简单的长度检查如果超过 800 字就自动截断并加上“...”提示。推送的格式我建议用纯文本不要用 markdown。虽然有些推送服务支持 markdown 渲染但微信的显示效果并不好尤其是表格和代码块经常显示错乱。纯文本虽然朴素但胜在稳定。4. 实操过程与核心环节实现4.1 第一步在 WorkBuddy 里创建定时任务打开 WorkBuddy 的工作台进入“任务”面板点击“新建任务”。任务名称我填的是“每日 AI 日报”触发方式选“每天”时间填“10:30”时区选“Asia/Shanghai”。超时时间设成 60 秒重试次数设成 1 次如果第一次失败隔 5 分钟再试一次。这里有一个隐藏选项任务失败时的通知方式。WorkBuddy 支持在任务失败时发送通知我建议开启这个功能通知渠道选微信。这样如果某天日报没有按时推送你能第一时间知道是任务挂了而不是傻等。4.2 第二步配置信息抓取 Skill在任务里添加第一个 Skill类型选“HTTP 请求”。我以抓取一个 RSS 源为例URL填你的 RSS 地址MethodGETHeaders根据需要添加一般不需要响应解析选“JSON”或“XML”取决于你的 RSS 源格式如果你要抓取多个信息源可以添加多个 HTTP 请求 Skill然后把它们的输出合并。WorkBuddy 支持在 Skill 之间传递数据你可以在后续的 Skill 里引用前面 Skill 的输出。提示抓取信息源的时候建议加一个简单的去重逻辑。我遇到过同一个新闻在多个源里出现的情况如果不处理日报里会出现重复内容。去重的方式可以在 DeepSeek 的提示词里加一句“如果有多条信息重复只保留一条”。4.3 第三步调用 DeepSeek API 生成日报添加第二个 Skill类型选“HTTP 请求”。配置如下URLhttps://api.deepseek.com/v1/chat/completionsMethodPOSTHeadersContent-Type: application/jsonAuthorization: Bearer YOUR_API_KEYBody{ model: deepseek-chat, messages: [ { role: system, content: 你是一个 AI 日报生成助手... }, { role: user, content: 以下是今天的原始信息{{previous_skill_output}} } ], temperature: 0.3, max_tokens: 800, top_p: 0.9, frequency_penalty: 0.2 }注意{{previous_skill_output}}这个占位符它会被 WorkBuddy 自动替换成前一个 Skill 的输出。如果你的信息源有多个可以用{{skill_1_output}}和{{skill_2_output}}分别引用。响应解析路径填choices[0].message.content这样你拿到的就是 DeepSeek 生成的日报文本。4.4 第四步推送到微信添加第三个 Skill类型选“HTTP 请求”。配置如下URL你的推送服务的接口地址MethodPOSTHeadersContent-Type: application/jsonBody{ token: YOUR_PUSH_TOKEN, title: 今日 AI 日报, content: {{deepseek_output}} }这里的{{deepseek_output}}是上一个 Skill 的输出。推送成功之后你的微信上就会收到一条消息。4.5 第五步测试与调试配置完成之后不要直接等第二天十点半。先手动触发一次任务看看整个流程能不能跑通。WorkBuddy 的任务面板里有一个“立即执行”按钮点一下就能手动触发。我第一次手动触发的时候遇到了三个问题一是 RSS 源返回的格式和预期不一致导致解析失败二是 DeepSeek 的 API 返回了 401原因是 API Key 填错了三是推送服务的 token 过期了。这三个问题都是配置层面的改一下就好。调试的时候建议打开日志。WorkBuddy 的任务日志会记录每个 Skill 的输入和输出你可以清楚地看到是哪一步出了问题。如果日志不够详细可以在 HTTP 请求 Skill 里开启“记录完整响应”这样你能看到原始的返回内容。5. 常见问题与排查技巧实录5.1 任务没有按时触发怎么办这是最常见的问题。排查思路如下检查工作台是否在运行。如果 WorkBuddy 的工作台进程挂了所有定时任务都不会触发。我建议给工作台加一个进程守护比如用 systemd 或者 supervisor。检查时区设置。前面提到过时区不对会导致触发时间偏移。在任务配置里显式指定时区不要依赖默认值。检查 cron 表达式。如果你用的是 cron 表达式注意 WorkBuddy 的 cron 格式可能和标准 cron 有细微差别。我建议先用可视化配置跑通之后再考虑用 cron。检查任务是否被禁用。有时候手动暂停了任务忘记重新启用也会导致不触发。5.2 DeepSeek API 调用失败怎么排查DeepSeek API 的失败原因主要有三类错误码可能原因解决方法401API Key 错误或过期重新生成 Key更新配置429请求频率超限降低调用频率或升级套餐500服务端错误等待几分钟后重试timeout网络问题或响应太慢增加超时时间检查网络我遇到最多的是 429原因是我的任务里同时调用了多个 DeepSeek API日报生成、摘要压缩、格式转换触发了频率限制。后来我把这些调用合并成一个问题就解决了。5.3 推送内容被截断或显示乱码微信推送的内容如果超过一定长度会被自动截断。解决方式是在推送之前做一个长度检查如果超过 800 字就截断并加上提示。乱码的问题一般是编码不对确保你的推送服务用的是 UTF-8 编码。还有一个坑是特殊字符。如果你的日报里包含 emoji 或者特殊符号有些推送服务会处理失败。我建议在生成日报的时候就让 DeepSeek 避免使用特殊字符或者在推送之前做一个过滤。5.4 如何让日报内容更精准日报内容不精准通常是因为原始信息太杂。我的经验是在抓取阶段就做好过滤。比如你只关心大模型相关的新闻那就在 RSS 源的选择上只订阅相关的频道而不是把所有科技新闻都抓进来。另外DeepSeek 的提示词里可以加一些约束条件比如“只保留与 AI 相关的信息”、“忽略广告和推广内容”。我实测下来加了这些约束之后日报的信噪比明显提升。5.5 常见问题速查表问题现象可能原因快速解决任务不触发工作台未运行 / 时区错误检查进程和时区配置API 返回 401Key 错误重新生成并更新 KeyAPI 返回 429频率超限合并调用或降低频率推送失败Token 过期 / 网络不通更新 Token检查网络内容截断超过长度限制压缩内容或分条推送内容重复信息源重复加去重逻辑生成质量差提示词不明确优化提示词加约束条件6. 我踩过的坑和最后分享几个小技巧这个项目从想法到跑通我大概花了三个晚上。第一个晚上在配环境第二个晚上在调 DeepSeek 的提示词第三个晚上在解决推送的问题。踩过的坑不少这里挑几个最有代表性的分享一下。第一个坑是时区。我前面提过但值得再强调一次。WorkBuddy 的默认时区取决于部署环境如果你用的是云服务器大概率是 UTC。我建议在任务配置里显式指定Asia/Shanghai不要偷懒。第二个坑是API Key 的存储。我一开始把 DeepSeek 的 API Key 直接写在 Skill 的配置里后来发现 WorkBuddy 的配置是可以被导出的这意味着 Key 会泄露。正确的做法是用环境变量或者 WorkBuddy 的密钥管理功能不要把敏感信息硬编码在配置里。第三个坑是推送频率。我一开始设的是每天推送三次早上、中午、晚上结果发现自己根本看不过来而且推送太频繁会导致微信消息被折叠。后来改成每天一次反而更珍惜每次推送的内容。最后分享几个小技巧。一是在日报里加一个“昨日回顾”板块把前一天没完成的任务自动带过来这样你不需要手动翻待办清单。二是给日报加一个简单的评分让 DeepSeek 根据信息量和紧急程度打一个 1 到 5 分这样你一眼就能判断今天需不需要花时间细看。三是定期回顾日报的生成质量我每个月会抽一天把过去一个月的日报翻出来看看如果发现某些板块长期没有有价值的内容就调整信息源或者提示词。这套流程跑了一个多月目前稳定运行。每天早上十点半微信准时弹出日报我花两分钟看完该处理的处理该忽略的忽略。省下来的时间够我多喝一杯咖啡。