WorkBuddy+DeepSeek：定时自动推送AI日报到微信

1. 为什么我要折腾一个“AI 日报自动进微信”每天早上到工位第一件事不是泡茶而是打开四五个网页、翻两三个群聊、扫一遍行业动态等把信息捋顺了半小时已经没了。这种重复劳动我忍了很久直到某天突然想明白一件事我需要的不是“更多信息”而是一份已经筛过、排过序、能直接看的日报。于是就有了这个项目——给 WorkBuddy 设一个闹钟每天上午十点半让它把整理好的 AI 日报自动推送到微信。先说清楚这个东西是什么。它本质上是一条自动化流水线定时触发 → 抓取/汇总信息源 → 交给大模型做摘要和归类 → 格式化成日报 → 通过微信通道送达。整条链路里WorkBuddy 扮演的是“调度中枢 执行器”的角色DeepSeek 这类大模型负责“理解与生成”微信则是最终的“投递终点”。你不需要盯着它它自己会在十点半准时把东西送到你面前。它能解决的问题很具体信息过载下的定时汇总。适合谁参考三类人最合适。第一类是每天需要跟踪特定领域动态的从业者比如做 AI 产品、做投资、做技术选型的第二类是想入门自动化但不知道从哪下手的新手这个项目链路完整、门槛不高是个很好的练手样本第三类是靠信息差吃饭的人比如做内容、做咨询的日报本身就是生产资料。哪怕你完全不懂代码只要跟着思路走也能理解每一步在干什么甚至用现成工具拼出来。我踩过的坑先给你交个底最容易翻车的不是抓取也不是模型而是微信这一端的送达稳定性和定时任务的时区/触发逻辑。后面会专门讲这两块。现在先进入整体设计。2. 整体设计与思路拆解2.1 为什么是“定时 推送”而不是“实时流”很多人第一反应是做实时推送一有新闻就发。我试过结果是灾难。信息是碎的一条一条弹出来你根本来不及消化最后要么屏蔽要么焦虑。日报的价值恰恰在于批处理带来的节奏感——每天固定一个时间点把过去 24 小时的东西压缩成一份可读的东西。从工程角度看定时任务比实时流简单太多。实时流要考虑去重、限流、消息顺序、断线重连而定时任务每天只跑一次失败了重试一次就行状态管理几乎为零。上午十点半这个时间点也不是随便定的太早很多源还没更新太晚上午的工作节奏已经被打乱。十点半刚好是“晨会结束、进入正题”的窗口拿到日报可以直接指导当天安排。提示定时任务的时间点要结合你的信息源更新规律来定。如果你的源大多是海外站点注意时区换算别设了个“上午十点半”结果抓到的全是昨天的旧闻。2.2 技术选型的三个关键取舍第一个取舍用 WorkBuddy 还是自己写脚本。自己写当然自由但要处理调度、日志、失败重试、通知通道一套下来没两天搞不定。WorkBuddy 这类工具的价值在于把这些“脏活”封装好了你只需要关注业务逻辑——抓什么、怎么总结、发给谁。对于日报这种“每天一次、逻辑固定”的场景用现成调度器是性价比最高的选择。第二个取舍模型用哪个。热词里出现了 DeepSeek我也确实用它做过对比。日报场景对模型的要求是长文本摘要能力稳、中文表达自然、成本可控。DeepSeek 在这三点上表现均衡尤其是中文语境下的归纳比一些英文优先的模型更贴合。当然你也可以换接口是标准化的换模型基本只改一个配置项。第三个取舍微信通道怎么走。这是整个项目最需要谨慎的部分。微信生态对自动化推送有明确限制个人号做自动发送存在账号风险企业微信相对规范但也要遵守平台规则。我的建议是优先使用官方支持的通道比如企业微信的机器人、微信小程序的订阅消息、或者服务号的模板消息。这些通道有明确的接口文档和使用边界稳定性和合规性都有保障。不要为了图省事去碰那些灰色方案账号被封得不偿失。2.3 整条链路的模块划分把项目拆开其实是四个模块模块职责关键考量触发层定时唤醒任务时区、失败重试、幂等采集层拉取信息源源的质量、去重、限速生成层模型摘要与排版提示词设计、输出格式约束投递层送达微信通道合规、送达确认这四个模块之间是松耦合的任何一层出问题都不会拖垮全局。比如采集层某个源挂了生成层照样能用剩下的源出日报投递层失败日报内容还在日志里手动补发即可。这种设计的好处是可维护——出问题时你能快速定位是哪一层而不是面对一坨黑盒。3. 核心细节解析与实操要点3.1 信息源的选择与清洗日报的质量七分靠源三分靠模型。源选得烂模型再强也只能把垃圾总结得更通顺。我的经验是源要少而精控制在 5 到 8 个覆盖“官方公告 行业媒体 社区讨论”三个层次。官方公告保证权威性行业媒体保证覆盖面社区讨论保证时效性和“人味儿”。采集时最容易忽略的是去重。同一个事件会被多个源报道如果不去重日报里会出现三条内容讲同一件事读起来很烦。去重的思路有两种一是基于 URL 或标题的精确去重简单但漏网多二是基于语义相似度的模糊去重效果好但要多花点算力。我一般先用标题关键词做粗筛再用模型做一次语义合并成本可控。注意采集频率要克制。有些源对高频访问不友好一天抓一次足够了。别把定时任务设成每小时跑一次既没必要也容易触发对方的限流。3.2 提示词设计让模型输出“能直接看”的日报这是整个项目里最见功力的地方。很多人写提示词就是一句“帮我总结一下”结果模型输出一堆废话。日报的提示词要解决三个问题结构固定、长度可控、语气统一。我的提示词骨架是这样的先给角色设定“你是一个 AI 行业日报编辑”再给输出格式约束“按‘今日要闻 / 技术动态 / 值得关注’三个板块组织每个板块不超过 5 条每条不超过 80 字”最后给风格要求“客观陈述不加主观评价不堆砌形容词”。格式约束越具体输出越稳定。这里有个小技巧在提示词里给一个示例输出。模型看到示例后格式遵循度会明显提升。示例不用长三五行的样子就够但能省掉你大量后期调整的时间。3.3 微信投递的合规通道选择前面强调过这一块必须走官方通道。具体来说企业微信的群机器人是最省事的选择创建一个群添加机器人拿到 Webhook 地址往这个地址 POST 一条消息就完事了。它支持 Markdown 格式日报的排版能保留得不错。如果你用的是服务号可以用模板消息但模板消息有格式限制适合短消息长日报要拆成多条。小程序订阅消息则需要用户主动订阅适合做“个性化日报”的场景。选哪个取决于你的使用场景自己看群机器人最方便发给一批用户服务号或小程序更合适。通道适用场景格式支持合规性企业微信群机器人自己/小团队Markdown官方支持服务号模板消息面向订阅用户受限官方支持小程序订阅消息个性化推送受限官方支持3.4 定时触发的时区与幂等处理定时任务有两个经典坑时区和重复执行。时区问题在于服务器可能跑在 UTC而你设的“十点半”是本地时间不换算就会差 8 小时。解决办法很简单在配置里明确写清时区别依赖默认值。幂等处理是为了防止“同一天发了两次日报”。触发器和执行器之间如果网络抖动可能触发重试导致重复投递。我的做法是在投递前检查一个“今日已发送”的标记发过了就跳过。这个标记可以存在本地文件也可以存在数据库看你的环境。4. 实操过程与核心环节实现4.1 环境准备与 WorkBuddy 配置先把基础环境搭起来。WorkBuddy 的安装按官方文档走就行装完后重点是配置任务。一个典型的任务配置包含四部分触发时间、执行脚本、环境变量、失败策略。触发时间用标准的 cron 表达式比如30 10 * * *表示每天十点半。这里要特别注意如果你的 WorkBuddy 跑在容器里确认容器的时区设置否则 cron 会按 UTC 执行。环境变量里要放的是敏感信息比如模型 API Key、微信 Webhook 地址。千万别把这些硬编码在脚本里一旦脚本被分享出去密钥就泄露了。用环境变量或者配置文件配置文件记得加进.gitignore。失败策略建议设成“重试 2 次间隔 5 分钟”。日报这种任务偶尔失败一次很正常重试基本能解决。如果重试还失败就发一条告警消息给你别让它默默挂掉。4.2 采集脚本的编写要点采集脚本的核心逻辑是遍历源列表 → 请求 → 解析 → 归一化成统一结构。用 Python 写的话requests加BeautifulSoup基本够用。如果源提供 RSS直接用feedparser更省事。归一化的数据结构建议长这样{ title: 标题, url: 链接, source: 来源名, published: 发布时间, summary: 原始摘要 }统一结构的好处是后面的去重和模型处理都不用关心源之间的差异。请求时记得加User-Agent很多站点对没有 UA 的请求会直接拒绝。请求间隔加个time.sleep(1)既是礼貌也是避免被封。4.3 模型调用与输出格式化调用模型这一步关键是把采集到的数据整理成模型能吃的格式。我一般把每条信息压成一行“标题 摘要”拼成一个大字符串前面加上提示词。注意控制输入长度太长了模型会截断反而丢信息。如果源很多可以先做一轮规则筛选把明显不相关的去掉再喂给模型。模型返回的是文本需要做一次格式化才能投递。如果走企业微信机器人把文本转成 Markdown 就行。转换时注意转义特殊字符比如标题里的#要处理掉否则会打乱排版。def format_daily(text): header ## AI 日报\n\n return header text4.4 投递与送达确认投递就是往 Webhook 地址发一个 POST 请求。企业微信机器人的接口很简单curl -X POST 你的Webhook地址 \ -H Content-Type: application/json \ -d {msgtype:markdown,markdown:{content:日报内容}}发完之后要检查返回码。企业微信返回errcode: 0才算成功其他值都要记录到日志里。我见过有人发完就不管了结果机器人被移出群聊都不知道日报发了个寂寞。送达确认这一步不能省。提示日报内容如果超过机器人单条消息的长度限制要自动拆分。拆的时候按板块拆别把一条内容从中间截断读起来很难受。5. 常见问题与排查技巧实录5.1 日报没收到怎么一步步排查这是最高频的问题。排查顺序应该是从后往前先看投递层再看生成层最后看采集层。第一步查投递日志。有没有发出请求返回码是多少如果返回码非 0看错误信息常见的是 Webhook 失效或内容格式不对。第二步如果投递成功但你没看到检查是不是被群消息淹没了或者机器人被限制了。第三步如果投递层没问题看生成层有没有产出内容模型调用是否超时。第四步如果生成层也没内容那就是采集层没抓到东西检查源是否改版、网络是否通。现象可能原因排查动作完全没消息触发器没跑查调度日志、时区设置有请求但失败Webhook 失效重新生成 Webhook内容为空采集失败检查源可用性内容重复幂等失效检查去重标记5.2 模型输出格式跑偏怎么办模型偶尔会不按格式来比如该分三个板块结果只分了一个或者字数超了一大截。解决办法有三层提示词加约束、输出后校验、校验不过就重试。提示词里把格式要求写得越死越好最好给示例。输出后用正则或简单的规则校验一下比如检查板块标题是否存在、每条长度是否超标。校验不过就带着“请严格按格式重新输出”再调一次一般第二次就正常了。如果反复跑偏说明提示词还是太模糊回去改提示词。5.3 采集源失效的应对信息源改版是常态今天能抓的页面明天可能就变了。应对策略是多源冗余 失效告警。同一个领域至少准备两个源一个挂了另一个顶上。同时给采集脚本加个检查如果某个源连续三天抓不到内容就发告警提醒你去看看。我自己的做法是维护一个源健康度表记录每个源最近的成功率。成功率低于阈值的源要么修要么换。这个表不用很复杂一个 JSON 文件就够。5.4 几个我踩过的坑第一个坑是时间点设得太早。一开始我设的早上七点结果很多源还没更新日报内容很干。改成十点半之后信息量明显上来了。第二个坑是没做去重。有段时间日报里同一件事出现三次读起来像复读机。加了语义去重之后清爽多了。第三个坑是密钥写死在脚本里。有次我把脚本发到群里求助忘了删密钥幸好发现得早。从那以后所有敏感信息一律走环境变量。第四个坑是没设失败告警。有次机器人被移出群日报连发三天没人收我第四天才发现。现在只要投递失败就立刻告警问题不过夜。6. 这套东西还能怎么扩展日报跑顺之后你会发现这套链路的复用性很强。把“AI 日报”换成“竞品动态”“专利更新提醒”“行业价格监控”逻辑几乎不用改只换采集源和提示词就行。我自己就基于同一套框架做了三个不同主题的日报维护成本很低。再往深了做可以加个性化。比如根据你前一天的阅读行为调整日报的板块权重或者做多端同步微信收一份邮件收一份Notion 里存一份。这些扩展都不难核心链路已经跑通了剩下的都是锦上添花。我个人在实际操作中的体会是自动化工具的价值不在于省了多少时间而在于把“需要记得做的事”变成“不需要记得也会发生的事”。日报这件事以前是我追着信息跑现在是信息按时来找我。这个转变带来的心理松弛感比省下的那半小时值钱多了。