1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位泡好咖啡打开电脑第一件事不是看邮件而是刷一遍昨天夜里到今早的行业动态、竞品更新、社区热帖。这件事听起来简单但真正做起来非常碎公众号、技术社区、社交平台、内部群聊、邮件列表信息源散落在七八个地方手动翻一遍至少二十分钟而且很容易漏掉关键内容。更麻烦的是有些信息有时效性上午十点半之前如果没看到可能就错过了一个值得跟进的线索。我用的工具是 WorkBuddy一个可以挂载技能、执行自动化任务的工作台。它本身支持定时触发、脚本执行和消息推送于是我就想能不能让它每天上午十点半自动把过去二十四小时的关键信息汇总成一份 AI 日报直接推送到微信里这样我只需要在十点半看一眼微信就能掌握当天需要关注的重点剩下的时间全部留给深度工作。这个项目的核心目标很明确用 WorkBuddy 作为调度中枢用 deepseek-v4-flash 作为内容生成引擎用微信小程序或微信消息通道作为接收端实现一份每日自动生成、自动推送的 AI 日报。它解决的不是“信息太少”的问题而是“信息太散、筛选太慢、容易遗漏”的问题。适合所有需要跟踪行业动态的从业者、独立开发者、产品经理、运营人员以及任何想用自动化手段给自己减负的人。我前后调了三个版本才跑通。第一版死在定时任务不触发第二版死在微信侧收不到消息第三版才把链路彻底跑顺。下面我把整个设计思路、关键细节、实操步骤和踩过的坑全部拆开讲你照着做就能复现。2. 整体方案设计与核心思路拆解2.1 为什么选 WorkBuddy 做调度而不是自己写 Cron很多人第一反应是不就是定时任务吗服务器上写个 crontab 不就行了我一开始也这么想但实际跑下来发现纯 Cron 方案有三个硬伤。第一环境依赖太重。你要自己维护一台常驻服务器装 Python 环境、配依赖、处理日志轮转还要保证网络稳定。对于只是想要一份日报的人来说这是杀鸡用牛刀。第二技能扩展不灵活。日报的内容源会变今天抓社区明天可能加邮件后天可能加内部知识库。纯脚本方案每加一个源就要改代码、重新部署维护成本很高。第三消息推送要自己对接。微信侧的消息通道有各种限制自己对接不仅麻烦还容易因为频率问题被限制。WorkBuddy 的优势在于它把定时调度、技能挂载、脚本执行、消息推送这几件事打包成了一个工作台。你只需要定义“什么时候触发、触发后执行什么、执行完推送到哪里”中间的运行环境、依赖管理、日志记录它帮你处理了。这就像你本来要自己盖一间厨房才能做饭现在直接给你一个带灶台的操作间你只管炒菜就行。提示WorkBuddy 的定时任务支持 Cron 表达式也支持自然语言描述时间。我实测下来用 Cron 表达式更稳因为自然语言解析偶尔会有时区歧义。2.2 deepseek-v4-flash 在链路里扮演什么角色日报的生成分两步信息采集和内容生成。采集靠脚本生成靠模型。我选 deepseek-v4-flash 的原因很直接快、便宜、够用。日报这种场景不需要模型做复杂推理它只需要把采集到的原始信息做三件事去重、摘要、分类。deepseek-v4-flash 的响应速度在同类模型里属于第一梯队生成一份八百字左右的日报通常三到五秒就能返回。而且它的上下文窗口足够放下我采集的几十条原始信息不需要做复杂的分片处理。这里有个关键设计我不让模型直接生成最终文案而是让它输出结构化 JSON。比如{ date: 2025-06-01, sections: [ { title: 行业动态, items: [ {summary: 某平台发布新版本, source: 社区, importance: high} ] } ] }拿到 JSON 之后我再在脚本里做格式化拼成适合微信阅读的 Markdown 或纯文本。这样做的好处是模型只负责它擅长的“理解和归纳”排版和推送逻辑由代码控制稳定性高很多。如果让模型直接写最终文案它偶尔会加一些奇怪的修饰词或者把来源搞混反而增加排查成本。2.3 微信侧接收方案的选择逻辑微信侧接收有三条路可走微信小程序订阅消息、企业微信机器人、个人微信文件传输助手。我三条都试过最后选了小程序订阅消息作为主通道企业微信机器人作为备用通道。小程序订阅消息的优势是正式、稳定、可追溯。用户主动订阅之后每天十点半收到一条服务通知点进去就能看日报详情。缺点是需要开发一个小程序页面来承载内容前期投入稍大。企业微信机器人的优势是零开发、五分钟接入。你只需要在群里添加一个机器人拿到 Webhook 地址脚本直接 POST 过去就行。缺点是消息长度有限制超过一定字数会被截断而且样式比较单一。个人微信文件传输助手理论上最简单但实际用下来最不稳定因为微信对自动化操作有风控频繁发送容易触发限制。我不推荐这条路。我的最终方案是WorkBuddy 定时触发脚本脚本采集信息后调用 deepseek-v4-flash 生成结构化日报然后通过小程序订阅消息推送给订阅用户同时把完整版日报 POST 到企业微信机器人作为备份。这样即使小程序侧出问题企业微信里也能看到内容。3. 核心细节解析与实操要点3.1 WorkBuddy 定时任务的配置细节WorkBuddy 的定时任务配置界面里有几个参数需要特别注意。Cron 表达式我设的是30 10 * * *意思是每天上午十点三十分触发。这里有个坑WorkBuddy 默认使用 UTC 时间如果你在中国大陆需要手动把时区调成 UTC8否则任务会在下午六点半才跑。我第一版就是栽在这里等了三天才发现时间不对。任务超时时间默认是六十秒但采集加生成加推送的完整链路实测下来平均需要四十到五十秒遇到网络波动可能超过六十秒。我建议把超时调到一百二十秒留足余量。失败重试策略WorkBuddy 支持配置重试次数和重试间隔。我设的是重试两次间隔三十秒。这样即使某次采集源临时不可用也有机会在第二次或第三次成功。日志保留默认保留最近七天的执行日志。如果你需要回溯更久可以在设置里调到三十天。日志里会记录每次执行的开始时间、结束时间、输出内容和错误信息排查问题时非常有用。注意WorkBuddy 的定时任务在触发时如果上一次任务还没执行完默认会跳过本次触发。这个行为在日报场景下是合理的避免重复推送。但如果你希望排队执行需要在高级设置里手动开启。3.2 信息采集脚本的编写要点采集脚本是整个链路里最脏最累的部分因为每个信息源的抓取方式都不一样。我把它拆成了三个模块源配置、抓取器、清洗器。源配置用一个 JSON 文件管理每个源包含名称、类型、地址、抓取频率、权重。比如{ sources: [ { name: 技术社区热帖, type: rss, url: https://example.com/feed, weight: 1.0 }, { name: 内部知识库更新, type: api, url: https://internal.example.com/api/updates, weight: 1.5 } ] }抓取器根据类型分发。RSS 源用 feedparser 解析API 源用 requests 请求网页源用 playwright 做无头浏览器渲染。这里重点说 playwright因为很多社区页面是动态加载的直接 requests 拿不到内容。playwright 的好处是它能等页面完全渲染后再提取文本稳定性比 selenium 好很多。from playwright.sync_api import sync_playwright def fetch_dynamic_page(url): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(url, wait_untilnetworkidle) content page.inner_text(body) browser.close() return content清洗器负责去重、去广告、提取正文。去重我用的是 SimHash 算法把每条内容的文本转成一个六十四位指纹相似度超过阈值的视为重复。去广告用正则匹配常见广告关键词比如“点击领取”“限时优惠”这类。提取正文用 readability-lxml它能自动识别页面里的主体内容区域把导航栏、侧边栏、评论区过滤掉。3.3 deepseek-v4-flash 的调用与提示词设计调用 deepseek-v4-flash 的接口本身不复杂关键是提示词的设计。我前后改了五版提示词最终稳定下来的版本包含四个部分角色定义、任务说明、输出格式、约束条件。角色定义让模型知道自己是一个“信息筛选助手”任务说明告诉它要把原始信息归纳成几个固定板块输出格式强制它返回 JSON约束条件要求它不编造信息、不添加主观评价、每条摘要不超过八十字。prompt 你是一个信息筛选助手。请把下面的原始信息归纳成日报分为三个板块 1. 行业动态与行业趋势、产品更新相关的内容 2. 技术干货与技术实践、工具使用相关的内容 3. 值得关注其他有价值但不易归类的内容 输出格式为 JSON结构如下 { sections: [ {title: 板块名, items: [{summary: 摘要, source: 来源}]} ] } 约束 - 每条摘要不超过 80 字 - 不编造原始信息中没有的内容 - 不添加主观评价 - 如果某个板块没有内容items 为空数组 原始信息 {raw_content} 这里有个经验温度参数设成 0.3。温度太高模型会自由发挥摘要里出现原文没有的表述温度太低模型会过于保守把不同来源的相似内容重复输出。0.3 是我实测下来平衡点最好的值。3.4 微信小程序订阅消息的接入流程小程序订阅消息的接入分四步注册小程序、配置模板、获取订阅授权、发送消息。注册小程序需要主体资质个人开发者可以注册但部分类目有限制。日报推送属于“服务通知”类目个人主体可以申请。配置模板在小程序后台的“订阅消息”页面操作。你需要选一个合适的模板或者自定义模板。模板里可以定义多个字段比如“日报日期”“内容摘要”“详情链接”。字段类型支持文本、数字、日期等。获取订阅授权需要在小程序前端调用wx.requestSubscribeMessage让用户主动点击授权。这里有个关键限制一次授权只能发送一条消息。也就是说如果用户只授权了一次你只能给他发一条日报第二天就发不出去了。解决办法是引导用户勾选“总是保持以上选择”这样后续可以持续发送。发送消息在服务端调用微信的接口需要用到 access_token。access_token 有有效期需要缓存并定时刷新。我用的方案是存在 Redis 里设置七千秒过期每次发送前检查是否过期过期就重新获取。def send_subscribe_message(openid, template_id, data): access_token get_access_token() url fhttps://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token{access_token} payload { touser: openid, template_id: template_id, data: data } response requests.post(url, jsonpayload) return response.json()提示小程序订阅消息的发送频率有限制单个用户每天最多接收一定数量的服务通知。日报场景下每天一条完全在限制范围内。4. 实操过程与核心环节实现4.1 从零搭建 WorkBuddy 任务的完整步骤第一步登录 WorkBuddy 工作台进入“技能”页面创建一个新的技能。技能类型选“脚本执行”运行环境选 Python 3.10。为什么选 3.10因为 playwright 和 feedparser 在这个版本下兼容性最好3.11 和 3.12 偶尔会有依赖冲突。第二步在技能里上传或在线编辑脚本。脚本的入口函数需要按照 WorkBuddy 的规范来写通常是定义一个main函数接收一个 context 参数返回执行结果。context 里包含触发时间、任务 ID、环境变量等信息。def main(context): raw_content collect_all_sources() daily_report generate_report(raw_content) push_to_wechat(daily_report) return {status: success, report_length: len(daily_report)}第三步配置定时触发器。在技能详情页找到“触发器”选项卡添加一个 Cron 触发器表达式填30 10 * * *时区选 UTC8。同时把超时时间改成一百二十秒重试次数设为两次。第四步配置环境变量。把 deepseek 的 API Key、微信小程序的 AppID 和 AppSecret、企业微信机器人的 Webhook 地址都存到环境变量里不要硬编码在脚本中。WorkBuddy 的环境变量是加密存储的安全性有保障。第五步手动触发一次测试。在技能页面点击“立即执行”观察日志输出。如果一切正常你会看到采集条数、生成耗时、推送结果等信息。我第一次测试时采集到了四十三条原始信息生成日报用了四点二秒推送成功。4.2 日报内容的格式化与推送实现模型返回的 JSON 需要经过格式化才能推送。我写了一个format_report函数把 JSON 转成适合微信阅读的纯文本。def format_report(report_json): lines [] lines.append(fAI 日报 | {report_json[date]}) lines.append() for section in report_json[sections]: lines.append(f【{section[title]}】) for item in section[items]: lines.append(f- {item[summary]}来源{item[source]}) lines.append() return \n.join(lines)格式化之后先推送到企业微信机器人。企业微信机器人的消息体支持 Markdown 格式但长度限制是四千零九十六字节。如果日报超过这个长度需要截断或者分多条发送。我的做法是如果超过三千五百字节就只推送摘要版完整版存到数据库通过小程序详情页查看。def push_to_wecom(content): webhook os.environ[WECOM_WEBHOOK] if len(content.encode(utf-8)) 3500: content content[:3000] \n\n... 完整内容请在小程序查看 payload { msgtype: markdown, markdown: {content: content} } requests.post(webhook, jsonpayload)小程序侧的推送需要先查询订阅用户列表然后逐个发送。订阅用户列表存在数据库里每次用户授权时插入一条记录。发送时遍历列表调用send_subscribe_message。如果某个用户发送失败记录失败原因下次重试。4.3 参数计算与性能优化记录整个链路的耗时分布大致是采集三十秒、生成五秒、推送三秒、其他开销五秒总计约四十三秒。采集是大头因为要等 playwright 渲染页面。我做了两个优化。优化一并发采集。把独立的源放到线程池里并行抓取采集时间从三十秒降到了十二秒。注意playwright 的浏览器实例不要并发太多我实测下来同时开三个页面比较稳开五个以上容易内存溢出。from concurrent.futures import ThreadPoolExecutor def collect_all_sources(): sources load_sources() with ThreadPoolExecutor(max_workers3) as executor: results list(executor.map(fetch_source, sources)) return merge_results(results)优化二缓存静态内容。有些源的内容变化不频繁比如内部知识库的文档列表没必要每次都全量抓取。我加了一个简单的缓存层用文件的修改时间做判断如果距离上次抓取不到一小时直接读缓存。优化三模型调用批处理。如果原始信息超过模型单次处理的上下文限制需要分批调用。我的做法是按来源分组每组单独生成摘要最后合并。这样虽然多调用几次模型但每次的输入更聚焦生成质量反而更好。4.4 完整链路的联调与验证联调阶段我重点验证了四个场景正常执行、源不可用、模型超时、推送失败。正常执行场景下日志显示采集四十三条、生成四点二秒、推送成功微信侧十点半准时收到消息。源不可用场景下我把其中一个源的地址改成无效地址脚本没有崩溃而是跳过了该源并在日志里记录了警告。最终日报里少了那个源的内容但整体流程正常。模型超时场景下我把 deepseek 的接口地址改成一个不存在的地址脚本在等待十秒后抛出超时异常。WorkBuddy 的重试机制在三十秒后重新触发第二次因为缓存了采集结果直接跳过采集进入生成但模型依然不可用最终任务标记为失败并发送了告警通知到企业微信。推送失败场景下我故意把企业微信的 Webhook 地址改错脚本捕获了异常并记录日志但没有影响小程序侧的推送。这说明两个推送通道是解耦的一个失败不影响另一个。注意联调阶段一定要用测试数据不要直接跑真实数据。我一开始图省事直接跑真实源结果测试过程中给订阅用户发了好几条重复日报非常尴尬。5. 常见问题与排查技巧实录5.1 定时任务不触发或触发时间不对这是最常见的问题我遇到过三次。第一次是时区没设对WorkBuddy 默认 UTC我以为是本地时间结果任务在下午六点半才跑。第二次是 Cron 表达式写错了把30 10 * * *写成了30 10 * * 1变成了每周一才触发。第三次是任务被禁用了我在调试时手动关掉了触发器后来忘了重新开启。排查顺序建议是先看触发器状态是否启用再看 Cron 表达式是否正确最后检查时区设置。WorkBuddy 的触发器页面会显示“下次触发时间”你可以对照这个时间来判断是否配置正确。5.2 微信侧收不到推送消息这个问题分两种情况小程序订阅消息收不到和企业微信机器人收不到。小程序订阅消息收不到首先检查用户是否真的完成了订阅授权。很多人以为点了“允许”就是订阅了但实际上微信的订阅消息需要用户主动勾选“总是保持以上选择”才能持续接收。如果用户只授权了一次你只能发一条。其次检查 access_token 是否有效过期的 token 会导致接口返回四千零一错误。最后检查模板 ID 是否正确模板 ID 填错会返回四千零三错误。企业微信机器人收不到首先检查 Webhook 地址是否完整有没有多余的空格。其次检查消息体格式企业微信对 Markdown 的语法支持有限某些特殊字符会导致解析失败。最后检查机器人是否被移出群聊或者群聊是否被解散。5.3 模型生成内容质量不稳定模型生成质量不稳定的表现有三种摘要太长、摘要太短、摘要偏离原文。摘要太长通常是提示词里没有限制字数或者温度设得太高。解决办法是在提示词里明确写“每条摘要不超过八十字”并把温度降到 0.3。摘要太短通常是原始信息本身就很短模型没有足够的内容可以归纳。这种情况可以在采集阶段做过滤把字数少于五十字的原始信息直接丢弃。摘要偏离原文通常是模型在“自由发挥”。解决办法是在提示词里加一条约束“摘要必须基于原始信息不得添加原文没有的内容”。如果还是不行可以在生成后加一个校验步骤用另一个模型调用判断摘要是否忠实于原文。5.4 常见问题速查表问题现象可能原因排查方法解决方案任务不触发触发器禁用查看触发器状态重新启用触发器触发时间不对时区设置错误检查时区配置改为 UTC8采集为空源地址失效手动请求源地址更新源配置模型超时接口不可用检查 API Key 和网络重试或更换接口小程序收不到未授权或 token 过期检查授权记录和 token引导重新授权刷新 token企业微信收不到Webhook 错误手动 POST 测试更新 Webhook 地址日报内容重复去重阈值太低检查 SimHash 阈值提高相似度阈值推送内容截断超过长度限制检查内容字节数截断或分条发送5.5 我踩过的三个坑和对应的避坑技巧坑一playwright 浏览器实例没有正确关闭。我在早期版本里每次抓取都新建一个浏览器实例但忘记关闭跑了两天之后服务器内存被占满任务开始随机失败。解决办法是用with语句管理浏览器生命周期确保每次抓取后自动关闭。坑二deepseek 接口的并发限制。我一开始为了提速把模型调用也放到了线程池里并发执行结果触发了接口的速率限制返回四百二十九错误。后来改成串行调用虽然慢了几秒但稳定性大幅提升。如果你的场景确实需要并发建议加一个令牌桶限流器控制每秒请求数。坑三微信 access_token 被其他服务刷新。如果你有多个服务共用一个小程序它们可能会同时刷新 access_token导致先刷新的那个 token 失效。解决办法是统一由一个服务负责刷新其他服务从缓存读取。我用的方案是把 token 存在 Redis 里所有服务都从 Redis 读只有一个定时任务负责刷新。提示WorkBuddy 的日志功能非常有用每次执行都会记录完整的标准输出和标准错误。排查问题时先看日志里的错误堆栈大部分问题都能直接定位。6. 后续可以继续扩展的方向这套链路跑通之后我发现它的扩展性比想象中好。最直接的扩展是增加信息源比如把邮件列表、内部 Wiki 更新、竞品博客都接进来。每加一个源只需要在源配置里加一条记录写对应的抓取器就行。第二个扩展方向是个性化日报。不同的人关注的内容不一样可以在订阅时让用户选择感兴趣的板块生成日报时根据用户偏好过滤内容。这个功能需要在小程序侧加一个偏好设置页面后端根据偏好生成不同的日报版本。第三个扩展方向是日报归档与检索。把每天的日报存到数据库里提供一个搜索页面支持按关键词、日期、来源检索。这样日报就不只是“当天看完就扔”的东西而是变成了一个可积累的知识库。我目前已经把前两个方向跑通了第三个方向还在做。如果你也在用 WorkBuddy 做类似的事情建议先从最简单的单源单通道跑通再逐步加源加通道。一上来就搞大而全很容易在联调阶段卡住。先把主链路跑顺后面加东西就是复制粘贴的事。