1. 从一条消息推送说起为什么我要给 WorkBuddy 设个“闹钟”每天早上到工位第一件事是打开电脑、翻聊天记录、看邮件、刷几个技术社区把夜里发生的事过一遍。这个过程大概要花二十分钟而且经常漏掉关键信息——某个依赖库发了新版本、某个接口悄悄改了字段、某个自动化任务昨晚跑失败了。信息不是没有是散落在太多地方人肉聚合的效率太低。后来我换了个思路与其我追着信息跑不如让信息在固定时间来找我。具体做法是用 WorkBuddy 作为任务调度和执行的载体接上 DeepSeek 的模型能力做内容生成最后通过微信小程序的订阅消息通道把一份整理好的 AI 日报在每天上午十点半准时推到我微信里。整套流程跑通之后我早上到工位只需要花两分钟扫一眼日报剩下的时间可以干正事。这个项目的核心关键词是WorkBuddy、AI日报、微信小程序、自动化、DeepSeek。它解决的不是什么高深的技术难题而是一个很实际的效率问题把分散的信息聚合、摘要、定时送达。适合谁参考如果你手头有重复性的信息整理工作或者想找一个轻量的自动化项目练手把 WorkBuddy 的任务编排、DeepSeek 的 API 调用、微信小程序的订阅消息这三块串起来是一个性价比很高的切入点。下面我把整个搭建过程拆开讲包括选型理由、参数配置、踩过的坑以及一些文档里不会写的实操细节。2. 整体方案设计与选型思路拆解2.1 为什么是 WorkBuddy 而不是纯脚本一开始我确实想过写个 Python 脚本挂个 cron 定时跑就完事了。但实际用下来纯脚本有几个绕不开的问题。第一是任务状态不可见脚本跑没跑、跑到哪一步、失败了没有全靠看日志文件时间一长日志堆成山排查起来很烦。第二是多步骤编排麻烦抓取、清洗、调模型、推送每一步都要自己处理异常和重试代码量不小。第三是跨设备同步困难我在公司电脑上配好的任务回家想改一下还得远程连回去。WorkBuddy 这类工作台工具的价值就在于它把任务调度、步骤编排、执行记录这几件事做成了可视化的。我可以把整个日报流程拆成几个节点每个节点单独配置哪个节点失败了在面板上一眼就能看到重跑也只需要点一下。这不是说脚本不好而是当任务需要长期稳定运行、且我希望能随时调整的时候可视化编排的维护成本明显更低。提示选工具的时候不要只看功能列表要看“出问题的时候我能不能快速定位”。长期运行的任务可观测性比功能多寡更重要。2.2 DeepSeek 在流程里扮演什么角色日报的内容不是简单地把原始信息拼起来那样读起来跟没整理一样。我需要模型做三件事摘要压缩、分类归并、重点标注。比如夜里抓到的二十条技术动态模型要能判断哪些是同一类事件、哪些值得单独拎出来、哪些可以一句话带过。选 DeepSeek 的理由很直接它的 API 调用成本低中文理解能力够用而且支持较长的上下文。日报场景下我一次要喂进去的原始素材可能有几千字模型需要在一次调用里处理完上下文长度和推理质量都得跟得上。实测下来用 DeepSeek 做摘要和分类输出质量稳定延迟也在可接受范围内。这里有个细节值得说不要把模型当成万能的黑盒。我在 prompt 里明确规定了输出格式比如“每条动态不超过两句话”“按技术领域分三组”“每组用一句话总结”。格式约束越清晰模型输出越稳定后续解析也越省事。2.3 微信小程序作为推送通道的考量推送通道的选择其实不少邮件、钉钉、飞书、企业微信都能做。我最终选微信小程序原因有三个。第一是触达率高微信是我每天打开频率最高的应用订阅消息直接出现在聊天列表里不会像邮件那样被淹没。第二是开发成本可控微信小程序的订阅消息接口文档清晰用 uniapp 开发的话一套代码还能兼顾多端。第三是用户体验好日报以卡片形式呈现点开就能看不需要额外装应用。需要说明的是微信小程序的订阅消息是一次性订阅机制用户授权一次只能推一条。对于每天推一条日报的场景我采用的是“用户每次查看日报后引导其再次授权下一条”的方式形成一个授权循环。这个机制在微信小程序开发里是标准做法具体实现后面会讲。2.4 整体数据流梳理把上面三块串起来整个流程是这样的触发WorkBuddy 在每天上午十点触发任务。采集任务第一步从预设的信息源抓取原始内容存成结构化数据。处理调用 DeepSeek API把原始内容做摘要、分类、格式化。组装把模型输出组装成微信小程序订阅消息要求的 JSON 结构。推送调用微信小程序的订阅消息接口把日报推送到用户微信。记录WorkBuddy 记录本次执行结果失败则触发告警。这个流程里采集和处理是耗时大头推送是最后一步。所以我在 WorkBuddy 里把超时时间设得比较宽松避免因为模型响应慢导致任务被误判为失败。3. 核心细节解析与实操要点3.1 WorkBuddy 任务编排的关键配置在 WorkBuddy 里建任务核心是配好三样东西触发时间、执行步骤、失败处理。触发时间我设的是每天上午十点半。为什么不是更早因为太早的话有些信息源还没更新完抓到的内容不完整。十点半这个时间点大部分技术社区和更新源都已经完成了当天的首次更新同时离我上午的工作节奏也匹配看完日报正好开始处理当天任务。执行步骤我拆成了四个节点每个节点独立配置节点功能超时设置重试策略节点一信息采集120秒失败重试2次节点二数据清洗60秒失败重试1次节点三模型调用180秒失败重试2次节点四消息推送30秒失败重试3次超时和重试的设置逻辑是这样的采集和模型调用是外部依赖网络波动或服务响应慢的概率较高所以超时给得宽、重试次数多推送是最后一步失败成本高所以重试次数最多确保消息能发出去。注意重试不是越多越好。如果某个节点连续失败说明可能是配置错误或服务不可用这时候应该触发告警而不是无限重试。我在 WorkBuddy 里设了“连续失败3次则暂停任务并通知”的规则。3.2 DeepSeek API 调用的参数调优调用 DeepSeek API 做日报生成有几个参数直接影响输出质量。temperature我设的是 0.3。这个值越低输出越稳定、越保守越高越有创造性。日报场景不需要创造性需要的是准确和一致所以调低。实测 0.3 的时候模型基本能按照我要求的格式输出不会突然自由发挥。max_tokens根据日报长度来定。我一般控制在 1500 到 2000 之间。设太小会导致输出被截断设太大又浪费。我的做法是先跑几次看实际输出的 token 数然后留 20% 的余量。top_p保持默认的 1.0 就行配合低 temperature 使用不需要额外调整。prompt 的结构我固定成三段角色设定 任务说明 输出格式。举个例子你是一个技术日报编辑。请把下面的原始信息整理成一份日报。 要求 1. 按“开发工具”“AI动态”“社区热点”三个类别分组 2. 每条不超过两句话 3. 每组末尾用一句话总结 4. 输出用 JSON 格式字段为 category、items、summary 原始信息 {raw_content}这个 prompt 模板我用了很久输出格式基本没跑偏过。关键点是把格式要求写死在 prompt 里而不是靠后处理去猜。3.3 微信小程序订阅消息的接入细节微信小程序的订阅消息接入分三步申请模板、获取 access_token、发送消息。申请模板在微信公众平台的“订阅消息”里操作。我申请的是一个“日报通知”类模板字段包括标题、摘要、时间。模板申请通过后会拿到一个 template_id后面发送消息要用。获取 access_token 是调用微信接口的前置步骤。access_token 有效期是 7200 秒需要缓存起来不能每次发送都重新获取。我的做法是在 WorkBuddy 里用一个节点专门管理 token缓存到本地文件过期前自动刷新。发送消息的接口是subscribeMessage.send请求体里需要填 touser用户 openid、template_id、page点击跳转的小程序页面、data模板内容。data 的字段名要和模板里定义的字段一一对应否则会报错。提示微信小程序的订阅消息有严格的字段长度限制比如 thing 类型字段不超过 20 个字符。日报摘要如果太长需要先截断再填充否则接口会直接拒绝。3.4 数据采集环节的注意事项采集环节看起来简单实际上最容易出问题。我踩过的坑包括编码不一致导致乱码、请求频率过高被限流、页面结构变化导致解析失败。编码问题好解决统一用 UTF-8 处理遇到非 UTF-8 的源先转码再解析。限流问题需要在采集节点里加延时我设的是每个源之间间隔 2 秒一天抓十几个源总耗时控制在 30 秒以内。页面结构变化是最麻烦的因为源站改版不会通知你。我的应对策略是加一层校验如果某个源抓到的内容为空或格式异常就在日报里标注“该源今日无有效内容”而不是让整个任务失败。这个设计思路很重要单个源失败不应该拖垮整个日报。日报的价值在于整体信息覆盖缺一两个源可以接受但整个任务挂掉就什么都收不到了。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说环境。WorkBuddy 我装在公司电脑上系统是 Windows。DeepSeek 的 API 调用用 Python 写版本是 3.10。微信小程序的开发用 uniapp配合 HBuilderX。Python 这边需要装的库不多pip install requests pip install schedulerequests 用来调 DeepSeek API 和微信接口schedule 用来做本地测试时的定时模拟。实际跑在 WorkBuddy 里的时候定时由 WorkBuddy 负责schedule 只在本地调试用。微信小程序这边需要在微信公众平台注册一个小程序账号拿到 AppID 和 AppSecret。然后在小程序后台配置服务器域名把 WorkBuddy 所在服务器的 IP 或域名加进去否则接口调用会被拦截。注意微信小程序的服务器域名配置有数量限制而且必须是 HTTPS。如果 WorkBuddy 跑在本地需要做内网穿透或者部署到有公网 IP 的服务器上。这一步是很多新手卡住的地方。4.2 DeepSeek API 调用的完整代码实现先看调用 DeepSeek 的核心代码。我把它封装成了一个函数输入原始文本输出结构化日报。import requests import json def generate_daily_report(raw_content, api_key): url https://api.deepseek.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } prompt f你是一个技术日报编辑。请把下面的原始信息整理成一份日报。 要求 1. 按“开发工具”“AI动态”“社区热点”三个类别分组 2. 每条不超过两句话 3. 每组末尾用一句话总结 4. 输出用 JSON 格式字段为 category、items、summary 原始信息 {raw_content} payload { model: deepseek-chat, messages: [ {role: user, content: prompt} ], temperature: 0.3, max_tokens: 2000 } response requests.post(url, headersheaders, jsonpayload, timeout180) result response.json() content result[choices][0][message][content] # 清理可能的 markdown 代码块标记 content content.replace(json, ).replace(, ).strip() return json.loads(content)这段代码有几个细节值得说。第一timeout 设了 180 秒因为模型处理长文本可能需要时间设太短会频繁超时。第二输出做了 markdown 清理模型有时候会把 JSON 包在代码块里返回直接 json.loads 会报错。第三temperature 和 max_tokens 写死在代码里方便统一管理。4.3 微信订阅消息推送的实现推送这块先获取 access_token再发送消息。import requests import json import time import os def get_access_token(appid, secret): cache_file access_token_cache.json # 检查缓存 if os.path.exists(cache_file): with open(cache_file, r) as f: cache json.load(f) if cache[expires_at] time.time(): return cache[access_token] # 重新获取 url fhttps://api.weixin.qq.com/cgi-bin/token?grant_typeclient_credentialappid{appid}secret{secret} response requests.get(url, timeout30) result response.json() access_token result[access_token] expires_at time.time() result[expires_in] - 300 # 提前5分钟过期 with open(cache_file, w) as f: json.dump({access_token: access_token, expires_at: expires_at}, f) return access_token def send_subscribe_message(access_token, openid, template_id, report_data): url fhttps://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token{access_token} payload { touser: openid, template_id: template_id, page: pages/index/index, data: { thing1: {value: report_data[title][:20]}, thing2: {value: report_data[summary][:20]}, time3: {value: report_data[date]} } } response requests.post(url, jsonpayload, timeout30) return response.json()这里的关键点是access_token 的缓存机制。微信的 access_token 每天有获取次数限制如果每次发送都重新获取很快就会用完配额。我用文件缓存的方式把 token 和过期时间存下来过期前 5 分钟自动刷新。另一个细节是字段截断。微信订阅消息的 thing 类型字段限制 20 个字符所以我在填充 data 的时候做了[:20]的截断。如果不截断接口会返回错误码 47003。4.4 WorkBuddy 里的任务串联把上面两块代码串起来在 WorkBuddy 里配置成一个完整任务。我的做法是写一个主入口脚本WorkBuddy 调用这个脚本脚本内部按顺序执行采集、处理、推送。def main(): # 1. 采集 raw_content collect_sources() # 2. 生成日报 report generate_daily_report(raw_content, DEEPSEEK_API_KEY) # 3. 推送 access_token get_access_token(WECHAT_APPID, WECHAT_SECRET) result send_subscribe_message(access_token, USER_OPENID, TEMPLATE_ID, report) # 4. 记录结果 log_result(result) return result if __name__ __main__: main()WorkBuddy 这边我配置的是“执行外部脚本”类型的任务指定 Python 解释器路径和脚本路径触发时间设为每天上午十点半。执行记录里能看到每次运行的输出和耗时方便排查。4.5 本地调试与线上运行的差异处理本地调试的时候我直接用 schedule 库模拟定时每五分钟跑一次快速验证流程。但线上运行有几个差异需要注意。第一是网络环境。本地调试时网络稳定线上服务器可能遇到网络抖动所以超时和重试策略要按线上环境来配。第二是文件路径。本地用相对路径没问题线上要用绝对路径否则 WorkBuddy 调用脚本时可能找不到文件。第三是日志输出。本地调试看控制台就行线上要把日志写到文件里方便事后排查。我的做法是在脚本里加一个环境变量判断本地调试和线上运行走不同的配置分支。这样一套代码两边都能用不用维护两份。5. 常见问题与排查技巧实录5.1 模型输出格式不对怎么办这是最常见的问题。模型有时候会自由发挥不按 JSON 格式输出或者在 JSON 外面加一堆解释文字。我的排查思路是分三步走。第一步检查 prompt 是否足够明确。如果 prompt 里只写了“输出 JSON”模型可能理解成“在回答里包含 JSON”。要写成“只输出 JSON不要有任何其他文字”。第二步加后处理兜底。即使 prompt 写得很清楚模型偶尔还是会跑偏。我在代码里加了一层正则提取从输出里找第一个{到最后一个}之间的内容再尝试解析。这样即使模型多说了几句话也能把 JSON 抠出来。第三步设置失败降级。如果 JSON 解析实在失败就把模型的原始输出直接作为纯文本日报推送至少保证信息能送达而不是整个任务失败。5.2 微信推送报错 47003 怎么解决47003 是订阅消息的字段校验错误通常是因为字段内容不符合模板要求。排查的时候重点看三个地方。一是字段类型是否匹配。模板里定义的是 thing 类型你传了数字或者超长文本就会报错。二是字段长度是否超限。thing 类型限制 20 个字符超出就截断。三是字段名是否对应。模板里的字段名是 thing1、thing2你传的时候写成了 thing_1也会报错。我的经验是在代码里加一层校验发送前先检查每个字段的长度和类型不符合就先处理再发送。这样比等接口报错再回头改要高效得多。5.3 任务执行超时怎么排查WorkBuddy 里任务超时原因通常有三个采集源响应慢、模型调用耗时长、网络抖动。排查方法是看执行记录里每个节点的耗时。如果采集节点耗时超过 100 秒说明某个源响应慢需要单独检查。如果模型调用节点耗时超过 150 秒可能是输入文本太长需要做截断或分批处理。如果是网络抖动重试通常能解决。我设了一个规则如果某个节点连续三次超时就把它暂时禁用避免拖累整个任务。等排查清楚再重新启用。5.4 常见问题速查表问题现象可能原因排查方法解决方案模型输出非 JSONprompt 不明确检查 prompt 格式要求加“只输出 JSON”约束 正则兜底推送报错 47003字段超长或类型错检查 data 字段截断 类型转换access_token 失效缓存过期未刷新检查缓存文件提前 5 分钟刷新采集内容为空源站改版或限流单独测试该源加校验 标注无内容任务超时某节点耗时过长看执行记录耗时禁用问题节点 重试5.5 几个文档里不会写的实操心得第一个心得日报的“摘要”比“全文”更重要。我一开始把抓到的所有内容都塞进日报结果读起来跟没整理一样。后来改成每条只保留两句话摘要阅读效率明显提升。模型做摘要的时候要明确告诉它“提炼核心信息去掉细节”。第二个心得推送时间要留缓冲。我设的是十点半推送但实际执行时采集和模型处理可能花掉几分钟。所以我在 WorkBuddy 里把触发时间设成十点二十五留五分钟缓冲确保十点半之前能送达。第三个心得失败告警要分级。不是所有失败都需要立刻处理。采集失败可以容忍推送失败必须立刻知道。我在 WorkBuddy 里配了不同的告警级别推送失败直接发通知采集失败只记录日志。第四个心得定期回顾日报质量。我每周会翻一下过去七天的日报看看有没有重复信息、有没有漏掉重要动态。根据回顾结果调整采集源和 prompt让日报越来越贴合自己的需求。6. 后续可以怎么扩展这套流程跑通之后扩展空间其实挺大的。我目前想到几个方向也陆续在试。一个是多用户支持。现在日报只推给我自己如果团队里其他人也想看可以把 openid 存成一个列表推送的时候循环发送。微信订阅消息支持批量发送但每个用户需要单独授权。另一个是日报内容个性化。不同人关注的技术领域不一样可以在 prompt 里加一个“关注领域”参数让模型根据用户偏好调整内容权重。这个改动不大但效果挺明显。还有一个是历史日报归档。把每天的日报存到数据库里需要的时候可以回溯查询。这个对于跟踪某个技术趋势的变化很有用。最后再分享一个小技巧WorkBuddy 的任务执行记录可以导出我每周会把记录导出来用脚本统计一下各节点的平均耗时和失败率。这样能提前发现潜在问题而不是等任务挂了才去排查。这个习惯坚持了几个月任务的稳定性确实提升了不少。
