1. 为什么我要折腾一个自动推送的 AI 日报每天早上到工位第一件事是打开浏览器翻十几个页面看行业动态、看竞品更新、看技术社区的新帖子一圈下来半小时没了真正记下来的没几条。这个习惯我坚持了大半年直到某天早上我盯着满屏的标签页发呆突然觉得这事不该由人来做——信息聚合、摘要提炼、定时推送这三件事拆开看都是机器更擅长的活。于是就有了这个项目给 WorkBuddy 设一个闹钟每天上午十点半让它把过去24小时里我关心的内容抓一遍、用大模型总结成一份日报、再通过微信推送到我手机上。整套流程跑通之后我早上到工位只需要花三分钟扫一眼日报剩下的时间可以干正事。这里说的 WorkBuddy 是一个可以挂载自定义技能、支持定时任务和外部工具调用的 AI 工作台类产品不同平台可能有不同的叫法但核心能力是相通的它能按你设定的时间自动执行一段任务流并且可以调用大模型、HTTP 接口、脚本等外部能力。我用的模型是 deepseek-v4-flash选它的原因后面会细说。推送通道走的是微信具体落地方式是用一个微信小程序做接收端配合服务端转发。这篇文章适合三类人看一是每天被信息淹没、想用自动化给自己减负的职场人二是正在玩 WorkBuddy 或者类似 AI 工作台、想找个真实项目练手的开发者三是对AI 日报这个形态感兴趣、想自己搭一套但不知道从哪下手的人。我会把整套方案的选型逻辑、关键配置、踩过的坑全部摊开讲代码和参数能给的都给你照着抄基本能跑起来。需要提前说明的是这套方案不涉及任何网络访问工具所有数据来源都是公开的、合规的信息渠道推送通道也是正规的微信生态能力。下面进入正题。2. 整体方案设计与选型思路拆解2.1 这套系统到底由哪几块拼起来先把架构摊平了说。整个AI 日报自动推送系统拆开就是四个环节每个环节对应一个技术选型环节职责我的选型备选方案触发调度每天10:30准时启动任务WorkBuddy 内置定时任务系统 crontab、云函数定时触发器数据采集抓取指定来源的内容WorkBuddy 自定义技能 HTTP 请求Python 爬虫、RSS 订阅内容生成把原始内容总结成日报deepseek-v4-flash其他大模型 API消息推送把日报送到微信微信小程序 服务端转发邮件、企业微信机器人这个拆法的好处是每一层都可以单独替换。比如你不想用 WorkBuddy 的定时能力换成服务器上的 crontab 完全没问题你不想用 deepseek-v4-flash换成别的模型接口也就是改个 URL 和 key 的事。我之所以这么选是因为 WorkBuddy 把调度和技能调用这两块整合得比较顺省去了自己维护一台常驻服务器的麻烦。2.2 为什么调度放在 WorkBuddy 而不是自己写 crontab我一开始的方案其实是在一台云服务器上写 crontabPython 脚本跑采集和总结然后调接口推送。跑了大概两周问题逐渐暴露出来脚本挂了没人知道。有天早上没收到日报登服务器一看是某个数据源的页面结构变了解析报错脚本静默退出。crontab 不会告诉你任务失败了。改需求成本高。我想把日报的总结风格从罗列改成分板块点评得改代码、测试、重新部署一来一回半小时。模型切换麻烦。想试试新出的模型效果得改代码里的调用逻辑。换成 WorkBuddy 之后这三个问题基本被抹平了。它的定时任务有执行记录失败了能看到日志总结风格可以通过调整提示词prompt直接改不用动代码模型切换在配置里改个名字就行。对于这种每天跑一次、逻辑不复杂、但需要经常微调的任务用工作台类产品比自己维护脚本划算得多。当然WorkBuddy 也不是没有代价。它的自定义技能能力有边界复杂的解析逻辑还是得靠外部接口兜底。我的做法是WorkBuddy 负责调度和编排真正脏活累活的解析放在一个轻量 HTTP 服务里两边通过接口通信。这样既享受了工作台的便利又保留了灵活性。2.3 模型为什么选 deepseek-v4-flash日报总结这个任务对模型的要求其实很明确输入长十几个来源的内容拼起来轻松过万 token、输出要结构化、响应要快、成本要低。它不需要模型有多强的推理能力但需要它稳定地做压缩归类提炼。我对比过几个模型在这个任务上的表现deepseek-v4-flash 的优势在于速度快。日报是定时任务10:30 触发我希望 10:31 就能收到不能等模型慢慢想。flash 版本在长文本总结上的响应速度明显优于标准版。长上下文处理稳。十几个来源的内容拼一起token 数不小flash 版本在这个量级下没有出现明显的中间内容丢失问题。成本可控。每天跑一次一个月三十次用 flash 版本的成本几乎可以忽略。结构化输出听话。我在提示词里要求它按行业动态 / 技术更新 / 值得关注三个板块输出它基本能稳定遵守格式不需要反复调教。提示模型选型没有绝对优劣关键看任务匹配度。日报总结这种长输入、短输出、重格式的场景flash 类模型往往比旗舰模型更合适因为旗舰模型的推理能力在这里是浪费的。2.4 推送通道为什么绕道微信小程序最直接的推送方式其实是邮件但邮件的打开率太低我经常一整天想不起来看。微信不一样它是我手机里打开频率最高的应用日报送到微信里我扫一眼通知栏就能决定要不要细看。但微信个人号没有官方的机器人接口直接给个人号发消息这条路走不通。所以我的方案是做一个极简的微信小程序作为接收端服务端把日报内容写进一个接口小程序打开时拉取展示同时通过订阅消息推送一条提醒。这个方案的关键在于订阅消息。微信小程序支持订阅消息能力用户授权后服务端可以在特定条件下推送一条模板消息到用户微信点击后跳转到小程序查看详情。整个链路是合规的也是微信官方推荐的触达方式。小程序的开发我用的是 uniapp一套代码可以同时编译到微信小程序和 App后面如果想扩展到其他端也方便。页面极其简单就一个列表页展示日报加一个详情页看全文。3. 核心细节解析与实操要点3.1 WorkBuddy 定时任务的配置要点WorkBuddy 的定时任务配置界面各个版本可能略有差异但核心参数就几个执行时间、执行频率、要调用的技能或指令、失败重试策略。我的配置是这样的执行时间每天 10:30。选这个时间是因为我一般 10 点左右到工位处理完邮件和消息10:30 正好需要一份信息汇总来规划当天的工作。执行频率每天一次。日报这种东西一天一次足够频率太高反而变成噪音。调用内容一个自定义指令指令里写清楚抓取以下来源 → 拼接内容 → 调用模型总结 → 推送结果的完整流程。失败重试开启重试 2 次间隔 5 分钟。数据源偶尔抽风是常态重试能解决大部分临时性失败。这里有个细节值得说WorkBuddy 的定时任务时区要确认清楚。我有一次发现任务在凌晨跑了排查半天才发现是时区配置成了 UTC10:30 UTC 对应北京时间是 18:30完全错位。改成 Asia/Shanghai 之后就正常了。另一个细节是任务执行超时时间。采集加总结整个流程我实测下来大概需要 40 到 90 秒取决于数据源响应速度和模型返回速度。如果你的 WorkBuddy 默认超时时间比较短比如 30 秒需要手动调大否则任务会被中途掐断。3.2 数据采集环节的实操细节数据采集是整个流程里最脏的部分因为你要面对的是各种格式不统一的网页和接口。我的做法是优先找 RSS 或公开 API找不到再考虑页面解析。我订阅的来源大概分三类技术社区的公开 RSS。这类最省事直接请求 XML 然后解析就行格式稳定。行业资讯站的公开接口。有些站点会暴露 JSON 接口给前端调用直接请求这个接口比解析 HTML 稳定得多。需要页面解析的站点。这类是下策因为页面结构一变解析就挂。我的处理方式是只提取最稳定的部分比如文章标题和链接正文内容让模型根据标题去概括而不是硬抓全文。采集环节有几个坑我踩过编码问题。有些站点的响应是 GBK 编码直接按 UTF-8 解析会乱码。处理方式是先检测响应头里的 charset没有的话用 chardet 之类的库猜一下。请求频率。别把采集脚本写成一秒请求十次容易被封。我的做法是每个来源之间间隔 1 到 2 秒整个采集过程控制在 30 秒以内。内容去重。不同来源可能转载同一篇文章直接拼给模型会浪费 token。我的做法是用标题做简单去重相似度超过阈值的只保留一条。采集到的原始内容我会做一个预处理去掉 HTML 标签、压缩多余空白、截断过长的正文。截断这一步很重要因为模型上下文有限与其塞进去一堆无关内容不如每个来源只保留前 500 字把 token 留给更多来源。3.3 提示词设计让模型稳定输出结构化日报提示词是这份日报质量的决定性因素。我前后改了七八版最终稳定下来的结构是这样的你是一个信息汇总助手。以下是过去24小时内我从多个来源采集的内容请帮我整理成一份日报。 要求 1. 按三个板块组织行业动态、技术更新、值得关注 2. 每个板块下用短句列出要点每条不超过50字 3. 如果某个板块没有相关内容写今日无 4. 最后用一句话总结今天的整体趋势 5. 不要编造内容只基于我提供的信息 采集内容如下 {content}这个提示词的关键在于约束足够具体。每条不超过50字这种量化要求比简洁一点有效得多。不要编造内容这句也必须加否则模型容易自由发挥把没发生的事写进日报。我还试过让模型输出 Markdown 格式方便小程序渲染但后来发现纯文本加简单换行反而更稳因为模型偶尔会在 Markdown 语法上出错导致渲染混乱。现在的做法是模型输出纯文本小程序端用固定样式渲染把格式控制权握在自己手里。注意提示词里的{content}占位符替换时要确保内容里没有会干扰模型理解的特殊字符。我遇到过采集内容里包含类似指令的文本导致模型被带偏。处理方式是在拼接前对内容做一次清洗去掉明显的指令性语句。3.4 微信小程序接收端的实现要点小程序端我做得极其克制就两个页面列表页展示最近 7 天的日报每条显示日期和摘要。详情页展示某一天的完整日报内容。数据获取走的是服务端接口。服务端在 WorkBuddy 推送日报时把内容写进数据库小程序打开时调接口拉取。这样即使小程序没打开日报也已经存好了不会丢。订阅消息的配置有几个关键点模板选择微信提供了多种订阅消息模板我选的是内容更新提醒类的模板字段填日期和摘要。用户授权订阅消息需要用户主动授权且每次授权只能推送有限次数。我的做法是在小程序里放一个开启每日提醒的按钮用户点击后请求授权授权一次可以推送多次具体次数看模板类型。推送时机服务端在日报生成后立即调用订阅消息接口推送用户收到通知点击进入小程序正好看到当天的日报。这里有个容易忽略的点订阅消息的推送有频率限制不能无限制推送。如果你的日报一天推多次可能会触发限制。我的方案是一天只推一次完全在安全范围内。3.5 服务端转发层的轻量实现服务端我用的是一台最低配的云服务器跑一个简单的 HTTP 服务职责就两个接收 WorkBuddy 推送的日报内容并存储、给小程序提供查询接口。技术栈选得很随意Python 的 FastAPI 或者 Node 的 Express 都行我用的是 FastAPI因为写起来快。核心接口就三个# 伪代码示意 POST /api/daily-report # WorkBuddy 推送日报内容 GET /api/daily-report/latest # 小程序获取最新日报 GET /api/daily-report/list # 小程序获取历史日报列表存储用的是 SQLite因为数据量极小一天一条没必要上 MySQL 或者 PostgreSQL。表结构就四个字段日期、内容、创建时间、推送状态。这个服务端的部署有个小技巧用 systemd 或者 supervisor 做进程守护确保服务挂了能自动重启。我有一次服务器重启后忘了设自启结果第二天日报没收到排查半天才发现是服务没起来。4. 完整实操流程与关键环节实现4.1 从零开始的搭建顺序如果你是第一次搭这套系统我建议按下面的顺序来每一步都能单独验证避免一次性堆完发现跑不通先跑通模型调用。写一个最简单的脚本把一段文本发给 deepseek-v4-flash看能不能拿到总结结果。这一步验证 API key、网络、模型名称都对。再跑通数据采集。单独写采集逻辑把几个来源的内容抓下来打印出来确认格式和内容符合预期。然后串起来。把采集内容拼进提示词调模型拿到日报文本。接着搭服务端。把日报文本通过接口存起来用 Postman 或者 curl 验证接口能读能写。再做小程序。先做列表页和详情页能拉到数据展示就行订阅消息最后加。最后配 WorkBuddy 定时任务。把前面验证过的流程封装成 WorkBuddy 的自定义指令设定时任务观察一两天确认稳定。这个顺序的核心逻辑是从易到难、从独立到集成。每一步都验证过最后集成时出问题也容易定位是哪一环的锅。4.2 关键参数的计算与选择过程有几个参数是我实际调过的把计算过程摊开说采集来源数量。我一开始订了 20 多个来源结果日报长得像流水账模型总结质量也下降。后来砍到 8 个核心来源日报质量明显提升。来源不是越多越好而是要精。我的标准是每个来源必须是我真正会看的如果一个来源连续一周的内容我都没点开过就砍掉。单条内容截断长度。我设的是 500 字。计算逻辑是8 个来源 × 500 字 ≈ 4000 字加上提示词本身约 200 字总共 4200 字左右换算成 token 大概 6000 以内完全在 deepseek-v4-flash 的上下文窗口内且留足了输出空间。如果来源增加到 15 个截断长度就要相应降到 300 字左右。任务超时时间。实测采集 8 个来源约 20 秒模型总结约 30 秒推送约 5 秒总共 55 秒左右。我把超时设成 180 秒留足余量应对网络波动。重试间隔。设的是 5 分钟。太短了可能数据源还没恢复太长了当天日报就延误了。5 分钟是个比较平衡的值。4.3 WorkBuddy 自定义指令的写法WorkBuddy 的自定义指令是整个流程的胶水它把采集、总结、推送三步串起来。我的指令逻辑大致是这样的步骤1调用采集接口获取原始内容 步骤2对原始内容做清洗和去重 步骤3拼接提示词调用 deepseek-v4-flash 步骤4将模型返回的日报内容 POST 到服务端接口 步骤5调用微信订阅消息接口推送提醒 步骤6记录执行日志每一步都要有错误处理。比如步骤1采集失败不应该直接中断而是记录哪些来源失败、哪些成功用成功的内容继续走流程。步骤3模型调用失败应该重试一次还失败就推送一条今日日报生成失败的提醒而不是静默消失。WorkBuddy 的指令编辑器支持条件判断和循环这些能力要用上。我见过有人把所有逻辑写成一条超长的直线指令结果一出错完全不知道哪一步挂了。把流程拆成带错误处理的步骤是保证长期稳定运行的关键。4.4 小程序端的页面实现细节小程序的列表页和详情页都很简单但有几个细节值得说列表页的日期显示。我用的是今天 / 昨天 / 具体日期的格式比单纯显示2024-01-15更符合阅读习惯。判断逻辑是拿日报日期和当前日期做差0 天显示今天1 天显示昨天其余显示日期。详情页的排版。日报内容是纯文本我用的是按行分割、逐行渲染的方式。板块标题如行业动态加粗放大要点内容正常显示整体留白充足。这里不要用富文本渲染因为模型输出的格式不完全可控富文本容易渲染出奇怪的效果。下拉刷新。列表页支持下拉刷新方便用户手动拉取最新日报。虽然订阅消息会推送提醒但用户主动打开时能刷新体验更好。缓存策略。小程序端对日报内容做了本地缓存缓存时间设的是 1 小时。这样用户反复打开不会重复请求接口减轻服务端压力。缓存过期后自动重新拉取。4.5 订阅消息推送的完整链路订阅消息的推送链路稍微绕一点我把完整流程写清楚用户在小程序里点击开启每日提醒按钮。小程序调用wx.requestSubscribeMessage请求用户授权。用户同意后小程序把授权凭证一个 token发给服务端。服务端保存这个 token并在每次日报生成后调用微信的订阅消息接口。微信服务器把消息推送到用户微信。用户点击消息跳转到小程序详情页。这里的关键是token 的保存和刷新。微信的订阅消息 token 有有效期过期需要重新获取。我的做法是服务端定时刷新 token确保推送时 token 有效。如果推送失败返回 token 过期就自动刷新后重试一次。提示订阅消息的模板字段是固定的不能随意添加字段。在微信公众平台配置模板时要选字段数量和类型都匹配的模板否则推送会失败。5. 常见问题与排查技巧实录5.1 日报没收到按这个顺序排查日报没收到是最常见的问题我整理了一个排查顺序从最可能的原因开始排查顺序检查项可能原因解决方法1WorkBuddy 任务执行记录任务没触发或执行失败看日志确认失败原因2数据采集是否成功数据源改版或超时单独测试采集逻辑3模型调用是否成功API key 过期或额度用完检查 key 和账户余额4服务端接口是否正常服务挂了或接口报错检查服务进程和日志5订阅消息是否推送成功token 过期或模板不匹配检查推送返回码6小程序是否能拉到数据接口地址变更或缓存问题清缓存重试这个顺序的逻辑是从上游到下游。日报的流转路径是WorkBuddy → 采集 → 模型 → 服务端 → 微信 → 小程序哪一环断了后面的都收不到。按顺序排查能最快定位问题。5.2 模型总结质量不稳定的处理模型总结质量波动是另一个高频问题。表现是有时候日报条理清晰有时候像流水账。我总结的原因和对策输入内容质量波动。如果某天采集到的内容本身就很碎模型也很难总结出条理。对策是在采集环节做质量过滤太短的内容比如少于 50 字直接丢弃。提示词被稀释。如果某天内容特别多提示词里的要求可能被模型忽略。对策是控制输入长度超过阈值就截断保证提示词占比。模型本身的随机性。大模型输出有随机性同样的输入两次结果可能不同。对策是把 temperature 调低我设的是 0.3输出稳定性明显提升。5.3 采集环节的典型故障与修复采集环节的故障最五花八门我挑几个典型的说故障一某个来源突然返回空内容。排查发现是该站点改了页面结构原来的解析规则失效。修复方式是更新解析规则同时加一个告警机制——如果某个来源连续两天返回空就在日报末尾提示来源 X 采集异常。故障二采集内容出现乱码。原因是编码判断错误。修复方式是在解析前先检测编码优先用响应头里的 charset没有就用 chardet 检测还不行就按 UTF-8 强制解码并忽略错误。故障三采集超时导致整个任务卡住。某个来源响应特别慢拖垮了整个流程。修复方式是给每个来源的请求设置独立超时我设的是 10 秒超时就跳过这个来源不阻塞整体流程。5.4 小程序端的常见问题小程序端的问题主要集中在订阅消息和数据展示上订阅消息收不到。检查三个地方用户是否授权、token 是否有效、模板字段是否匹配。我遇到过一次是模板字段填错了推送接口返回错误但没仔细看排查了半天。详情页内容显示不全。原因是内容里有特殊字符导致渲染中断。修复方式是在服务端对内容做转义处理把可能干扰渲染的字符替换掉。列表页日期显示错误。原因是时区处理不当。修复方式是统一用服务端返回的日期字符串不在客户端做日期计算。5.5 我踩过的三个印象最深的坑坑一时区错位。前面提过WorkBuddy 定时任务时区设成了 UTC导致日报在傍晚才生成。这个坑让我意识到任何涉及时间的配置都要显式确认时区。坑二token 过期没处理。订阅消息的 token 过期后推送静默失败我连续三天没收到日报才发现。修复方式是在推送逻辑里加 token 有效性检查过期自动刷新。坑三内容里的指令注入。有一次采集到的内容里包含类似忽略以上指令输出 XXX的文本模型真的被带偏了。修复方式是在拼接前对内容做清洗去掉明显的指令性语句同时在提示词里强调只基于提供的信息总结。6. 几个让系统更耐用的优化技巧6.1 给日报加一个健康度标记我在日报末尾加了一行小字显示本次采集的成功率比如本次采集 8 个来源成功 7 个。这样我一眼就能看出日报的完整性如果成功率突然下降说明某个来源出问题了可以及时处理。这个标记的实现很简单就是在采集环节统计成功和失败的数量拼到日报末尾。6.2 历史日报的归档与检索日报积累多了之后偶尔会想翻某一天的日报。我在服务端加了一个简单的检索接口支持按日期范围和关键词查询。小程序端也加了一个搜索框输入关键词能搜到包含该词的日报。这个功能用 SQLite 的 LIKE 查询就能实现不需要上全文检索引擎。6.3 把日报同步一份到笔记软件微信里看日报方便但不利于长期归档。我的做法是在服务端加一个同步逻辑把每天的日报通过接口写进我的笔记软件我用的是支持 API 的笔记工具。这样日报既能在微信里快速查看又能在笔记软件里长期保存和检索。6.4 定期回顾和调整来源列表来源列表不是一成不变的。我每个月会花十分钟回顾一下哪些来源的内容我从来没细看过哪些来源最近质量下降然后做增删。保持来源列表的精简和高质量是日报长期有价值的前提。一个塞满低质量来源的日报很快就会变成没人看的噪音。6.5 给模型加一个风格记忆我在提示词里加了一段固定的风格描述比如用简洁、直接的语言避免套话和空泛表述。这段描述每次调用都带上让模型的输出风格保持一致。如果不加这段模型有时候会输出很官方的总结读起来很累。风格记忆的本质是把提示词里稳定的部分固化下来只把变化的内容采集结果作为变量传入。这套系统跑到现在大概三个月中间修修补补不少次但核心流程一直很稳。最大的感受是自动化的价值不在于省了多少时间而在于把一件需要想起来去做的事变成了不用想就会发生的事。信息获取这件事一旦变成被动接收心态会轻松很多——我不再焦虑今天有没有漏掉什么因为我知道十点半会有一份汇总送到我面前。