1. 为什么我要折腾一个自动推送的 AI 日报每天早上到工位第一件事是打开各种信息源扫一遍行业动态、技术更新、竞品动作、社区热帖。扫完一圈半小时没了真正记下来的没几条。更麻烦的是团队里其他人也在做同样的事信息重复采集结论还经常对不齐。这个痛点我忍了很久直到某天早上盯着屏幕发呆的时候突然想明白一件事我需要的不是更多信息而是一份已经筛过、整理过、能直接看的简报。于是就有了这个项目——给 WorkBuddy 设一个定时任务每天上午十点半自动生成一份 AI 日报推送到微信。整个链路跑通之后我早上到工位只需要打开微信花三分钟看完剩下的时间可以干正事。这篇文章就把我从零搭这套东西的完整过程拆开讲包括为什么这么设计、每一步怎么落地、踩了哪些坑、哪些参数必须调。如果你也在做类似的自动化信息流或者单纯想给自己的日常工作减负这篇应该能直接抄作业。先说清楚这套东西的定位。它不是那种抓一堆 RSS 然后拼起来的粗糙聚合而是一条完整的采集 → 清洗 → 生成 → 推送流水线。核心角色有三个WorkBuddy 负责调度和编排大模型负责把原始信息压缩成可读的日报微信负责把结果送到我手上。三个环节各司其职任何一个环节出问题都能单独排查不会牵一发动全身。适合谁看三类人。第一类是想做个人自动化但不知道从哪下手的开发者这套流程的骨架可以平移到任何定时采集生成推送的场景。第二类是在团队里负责信息同步的人把日报推送到群里比每天手动整理省太多事。第三类是单纯对 WorkBuddy 这类工具好奇、想看看它到底能干什么的人我会把配置细节讲透不藏私。2. 整体架构设计与选型思路拆解2.1 为什么是定时任务 大模型 微信推送这个组合先讲清楚一个原则能用现成能力拼出来的绝不自己造轮子。我见过太多人一上来就写爬虫框架、搭消息队列、自己搞调度器结果维护成本比收益还高。这套方案的设计哲学是薄胶水——每个环节都用成熟工具我只负责把它们串起来。调度层用 WorkBuddy 的定时能力。为什么不用系统的 crontab因为 crontab 只管什么时候跑不管跑什么、跑完怎么处理。WorkBuddy 这类工具的价值在于它把任务编排、上下文管理、结果处理都封装好了我只需要描述每天十点半做这件事剩下的它来兜底。而且它天然支持把大模型调用作为任务的一个步骤省掉了我自己封装 API 的功夫。生成层用大模型。这一步是整个链路的核心价值所在。原始信息是散的、重复的、带噪音的直接推给人看等于没推。大模型的作用是压缩和结构化把二十条零散动态归纳成五个要点把技术更新翻译成人话把不相关的内容过滤掉。这里我选的是 deepseek-v4-flash 这个档位的模型原因后面细说。推送层用微信。为什么是微信而不是邮件、钉钉、飞书因为触达率。邮件我会忘看钉钉我会静音但微信是我每天必开的东西。日报这种东西送到用户一定会看的地方才有意义。微信这边有两条路一是走服务号模板消息二是走小程序。我最终选了小程序方案因为模板消息有格式限制、有频率限制而小程序可以做一个完整的阅读界面日报长了也不怕。2.2 三个环节的职责边界怎么划很多人做自动化容易犯一个错把逻辑全塞在一个地方。比如让大模型既负责抓取又负责生成还负责推送结果一出问题根本不知道是哪一步挂了。我的做法是严格分层每层只干一件事。采集层只负责拿到原始文本不做任何判断。它把各个来源的内容抓下来统一成一种格式我用的就是简单的 JSON每条包含标题、正文、来源、时间戳然后交给下一层。这一层的关键是幂等——同一条内容抓两次不能产生两条记录否则日报里会出现重复。生成层只负责把原始文本变成日报。它接收采集层的输出按预设的 prompt 模板调用大模型拿到结果后做一次格式校验比如检查有没有超出长度、有没有明显的格式错误然后交给推送层。这一层的关键是可复现——同样的输入应该得到结构一致的输出不能今天一个格式明天一个格式。推送层只负责把日报送到微信。它接收生成层的输出调用微信的接口把内容推出去。这一层的关键是可靠——推送失败要有重试要有失败告警不能默默吞掉。三层之间通过明确的数据结构通信任何一层都可以单独替换。比如哪天我想把微信换成别的渠道只需要改推送层采集和生成完全不用动。这种解耦在后期维护时价值巨大。2.3 为什么选 deepseek-v4-flash 而不是更大的模型模型选型这块我纠结了一阵。直觉上会觉得日报这种要质量的东西应该用最强的模型但实际跑下来发现不是这么回事。日报这个场景有三个特点输入量大、输出要求结构化、对延迟敏感。输入量大意味着 token 成本高用顶级模型每天跑一次一个月下来账单不好看。输出结构化意味着不需要模型有太强的创造力它主要是做归纳和改写不是写小说。对延迟敏感意味着早上十点半要准时推不能等模型慢慢想。deepseek-v4-flash 这个档位的模型刚好卡在甜点区归纳能力够用结构化输出稳定速度快成本可控。我实测下来一份包含二十条原始信息的日报生成时间在几秒到十几秒之间完全满足定时推送的需求。如果你对质量有更高要求可以换成更强的模型但要做好成本和延迟的权衡。我的建议是先用 flash 档跑通觉得不够再升级不要一上来就上最贵的。提示模型选型不要只看榜单分数。日报这种任务一个中等模型配上好的 prompt效果往往比顶级模型配烂 prompt 好得多。prompt 工程在这个场景里的权重比模型档位更高。3. 核心细节解析与实操要点3.1 采集层怎么把散落的信息收拢成统一格式采集是整个链路的地基地基不稳后面全白搭。我的采集策略是多源汇总 统一归一化。来源大概分三类一是固定的信息源比如几个我常看的技术社区二是关键词订阅比如搜AI 日报相关的动态三是手动投喂偶尔看到好内容随手丢进去。每一类来源抓下来的原始格式都不一样有的是 HTML有的是 JSON有的是纯文本。归一化这一步就是把这些五花八门的东西统一成同一种结构。我定义的结构很简单{ title: 条目标题, content: 条目正文或摘要, source: 来源标识, timestamp: 2024-01-01T10:00:00Z, url: 原始链接 }这个结构看起来朴素但每个字段都有用。title 和 content 是给大模型看的source 用于去重和溯源timestamp 用于排序和过滤比如只保留最近 24 小时的url 用于在日报里附上原文链接方便深读。归一化之后要做去重。去重不能只比 title因为同一个事件不同来源的标题可能完全不同。我的做法是算一个简单的相似度把 title 和 content 拼起来做一次分词算 Jaccard 相似度超过阈值就认为是同一条。阈值我设的是 0.7实测下来误杀和漏杀都在可接受范围。如果你嫌麻烦也可以只按 url 去重但效果会差一些。还有一个容易被忽略的点时间窗口。日报是日报不是全量报所以采集时要限定时间范围。我设的是最近 24 小时但考虑到有些来源更新慢实际会放宽到 36 小时。这个参数要根据你的信息源更新频率来调更新快的可以收紧更新慢的要放宽。3.2 生成层prompt 怎么写才能让日报能看生成层是整套方案里最需要打磨的地方。同样一堆原始信息prompt 写得好就是一份清爽的日报写得差就是一堆废话的堆砌。我前后改了七八版 prompt总结出几条经验。第一条明确角色和任务。不要上来就说帮我总结一下要说清楚你是一个科技行业分析师负责把以下原始信息整理成一份给开发者看的日报。角色设定会显著影响输出的语气和详略。第二条规定输出结构。日报要有固定的骨架比如今日要闻、技术动态、值得关注三个板块。每个板块下用要点列出每个要点不超过两句话。结构固定了读者形成阅读习惯扫一眼就知道重点在哪。第三条给出正反例。这是最有效的一招。在 prompt 里放一两个好的输出和差的输出的对比模型会迅速理解你要的是什么。比如差的输出是某公司发布了新产品好的输出是某公司发布 XX 产品主打 YY 能力对标 ZZ值得关注的是它的 AA 设计。对比一放输出质量立竿见影。第四条限制长度。不限制的话模型容易啰嗦。我规定每个要点不超过 80 字整份日报不超过 800 字。这个长度刚好够说清楚又不会让人失去耐心。第五条要求附来源。每个要点后面标注来源方便读者溯源。这既是可信度的保证也是防止模型胡编的约束——它知道要标来源就不敢乱写。注意prompt 里的指令要具体到可执行。简洁一点是模糊指令每个要点不超过 80 字才是可执行指令。模型对具体数字的服从度远高于对形容词的理解。3.3 推送层微信小程序方案的关键配置推送层我选的是微信小程序这里展开讲几个关键点。第一个是消息触达机制。小程序本身不能主动给用户发消息需要配合订阅消息。订阅消息的特点是用户要先授权授权后你可以在特定场景下发一条。对于日报这种每天一条的场景订阅消息是合适的。要注意的是订阅消息有模板限制你得先在后台申请一个合适的模板字段要和你的日报内容对得上。第二个是小程序的阅读界面。日报内容可能比较长小程序里要做一个能滚动的阅读页。这里有个细节微信小程序的顶部导航栏高度在不同机型上不一样如果你要做自定义导航栏得用wx.getSystemInfoSync()拿到状态栏高度再算。我一开始没注意这个在部分机型上标题被状态栏挡住了后来加了动态计算才解决。第三个是缓存策略。日报每天更新但用户可能一天内多次打开。我的做法是本地缓存当天的日报缓存有效期设到当天 23:59第二天自动失效重新拉取。这样既省流量又保证新鲜度。缓存 key 用日期简单可靠。第四个是请求封装。小程序的网络请求要统一封装加上超时、重试、错误提示。我见过太多小程序因为一个请求失败就白屏的体验很差。封装一层之后任何请求失败都有兜底用户看到的是加载失败点击重试而不是一片空白。如果你不想做小程序也可以用服务号模板消息配置更简单但阅读体验差一些长内容会被截断。我的建议是内容短用模板消息内容长用小程序。日报这种内容量小程序更合适。3.4 定时调度十点半这个时间点是怎么定的十点半不是随便定的。我观察了自己一周的作息发现这个时间点有几个好处早上的紧急事务已经处理完脑子清醒适合读信息距离午饭还有一段时间读完日报正好可以安排下午的工作而且大部分信息源在上午十点前已经更新完毕这时候采集能拿到当天最全的内容。WorkBuddy 的定时配置很直接指定每天 10:30 触发即可。但有几个细节要注意。一是时区确保调度器用的是你所在时区不然会出现明明设的十点半结果下午才推的情况。二是失败重试如果十点半那次因为网络问题失败了要配置重试比如五分钟后重试一次。三是执行时长整个链路跑完大概需要一到两分钟要确保调度器的超时设置大于这个时间不然任务会被中途掐断。还有一个经验不要在调度任务里做太多事。我一开始把采集、生成、推送全塞在一个任务里结果任何一步慢都会拖累整体。后来拆成三个子任务串行执行每步单独设超时问题定位起来清楚多了。4. 完整实操流程与关键环节实现4.1 环境准备与 WorkBuddy 基础配置动手之前先把环境理清楚。你需要的东西不多一个 WorkBuddy 账号用来做调度和编排、一个大模型的 API key用来生成日报、一个微信小程序的 AppID用来做推送。三样东西备齐就可以开始了。WorkBuddy 这边的配置分两步。第一步是创建任务在任务列表里新建一个定时任务触发规则设成每天 10:30。第二步是配置任务步骤把采集、生成、推送三个动作按顺序加进去。每个步骤可以单独配置参数比如采集步骤配置信息源列表生成步骤配置 prompt 模板和模型参数推送步骤配置微信的接口地址和凭证。这里有个容易踩的坑凭证管理。API key、小程序 secret 这些敏感信息不要硬编码在任务配置里要用环境变量或者密钥管理功能。我一开始图省事直接写在配置里后来分享配置截图的时候差点泄露赶紧改成了环境变量引用。这个习惯一定要养成。模型参数这块我用的配置是temperature 设 0.3日报要稳定不要太多随机性max_tokens 设 2000够生成一份日报又不至于失控top_p 设 0.9。这几个参数不用太纠结跑几次看输出效果微调就行。4.2 采集脚本的编写与调试采集脚本是整个链路里最脏的部分因为要和各种来源打交道。我用的思路是每个来源一个适配器适配器负责把该来源的原始数据转成统一格式主流程只负责调度适配器和汇总结果。写适配器的时候有几个通用技巧。一是加超时任何网络请求都要设超时不然一个卡住的来源会拖垮整个采集。我设的是 10 秒。二是加重试网络抖动是常态失败重试两次能解决大部分偶发问题。三是加日志每个来源抓了多少条、耗时多少、有没有报错都要记下来出问题的时候一眼就能看出是哪个来源挂了。调试采集脚本的时候我建议先单源调试再全量跑。先把一个来源调通确认格式正确、去重有效再把其他来源加进来。一上来就全量跑出了问题根本不知道是哪里的问题。去重这块再补充一个细节去重要在归一化之后做。因为不同来源的原始格式不同直接比对没意义。归一化之后大家都是统一结构比对才有意义。另外去重的时候要保留信息量最大的那条比如同样一个事件有详细正文的比只有标题的更有价值去重时应该保留详细的那条。4.3 日报生成的核心代码与 prompt 模板生成这一步的核心就是 prompt 模板。我把我的模板结构拆开讲你可以直接拿去改。模板分四段。第一段是角色设定你是一名科技行业分析师负责把原始信息整理成给开发者看的日报。第二段是任务说明以下是最近 24 小时的原始信息请整理成一份日报包含今日要闻、技术动态、值得关注三个板块。第三段是格式要求每个板块用要点列出每个要点不超过 80 字每个要点后标注来源整份日报不超过 800 字。第四段是正反例放一两个对比示例。调用模型的时候把采集层输出的 JSON 序列化成文本拼在模板后面。注意输入长度控制如果原始信息太多要截断或者分批处理不然会超出模型的上下文限制。我的做法是按时间倒序取前 30 条实测下来这个数量既能覆盖当天重点又不会超长。拿到模型输出后要做格式校验。检查有没有三个板块、每个要点有没有超长、有没有明显的格式错误。校验不通过就重试一次再不过就降级——把原始信息直接推过去至少保证有内容。这种降级策略在实际运行中救过我好几次。def generate_daily_report(raw_items): prompt build_prompt(raw_items) for attempt in range(2): result call_model(prompt, temperature0.3, max_tokens2000) if validate_format(result): return result return fallback_format(raw_items)4.4 微信推送的接口对接与消息模板推送这一步如果你走小程序方案核心是订阅消息的发送。流程是用户在小程序里授权订阅你拿到授权后在服务端调用微信的接口发送消息。接口需要几个参数用户的 openid、模板 ID、以及模板里各个字段的值。模板字段的设计要和日报内容对应。比如模板里可以有日报标题、要闻摘要、详情入口三个字段。要闻摘要放日报的前两条要点详情入口放小程序的页面路径用户点进去看完整日报。发送消息的时候要注意频率限制。微信对订阅消息有频率限制一天一条是安全的。如果你要发多条得确认没超限。另外错误处理要做好发送失败要记录日志连续失败要告警。我遇到过因为 access_token 过期导致推送失败的情况后来加了 token 自动刷新才解决。小程序的阅读页这边核心是渲染日报内容。日报是结构化的三个板块每个板块若干要点渲染的时候按板块分组展示每个要点一行来源用小字标注。页面要支持下拉刷新方便用户手动更新。整体风格简洁为主不要花哨日报这种东西可读性第一。5. 常见问题与排查技巧实录5.1 推送失败的五种典型情况和排查路径推送失败是最让人头疼的问题因为它在链路末端前面都跑通了就卡在最后一步。我把遇到过的失败情况整理成一张表方便对照排查。现象可能原因排查方法解决方式完全没收到消息订阅授权过期检查用户授权状态引导用户重新授权收到但内容为空生成层输出异常查看生成层日志检查 prompt 和模型返回收到但格式错乱模板字段不匹配核对模板 ID 和字段重新申请模板或调整字段时有时无access_token 过期检查 token 刷新逻辑加自动刷新机制延迟很久才收到调度任务排队查看任务执行时间调整调度时间或拆分任务排查的时候有个通用原则从后往前查。先确认推送接口有没有被调用再确认调用有没有成功再确认生成层有没有正常输出最后确认采集层有没有拿到数据。这样一层层往前推很快就能定位到问题所在。5.2 日报质量不稳定的调优经验日报质量不稳定是另一个高频问题。表现是有时候日报很精炼有时候一堆废话有时候重点突出有时候抓不住重点。这个问题八成出在 prompt 或者输入上。先说输入。如果某天采集到的原始信息特别杂比如混进了很多不相关的内容日报质量必然下降。解决办法是在采集层加相关性过滤用关键词或者简单的分类模型把不相关的内容先筛掉。我加了一层关键词过滤把明显不相关的内容挡在外面日报质量稳定了不少。再说 prompt。如果 prompt 太笼统模型就会自由发挥质量自然不稳定。解决办法是把要求写死。比如每个要点不超过 80 字比简洁一点有效得多必须包含三个板块比结构清晰有效得多。prompt 里的每一条要求都要具体到可验证这样输出才稳定。还有一个技巧固定 few-shot 示例。在 prompt 里放一组固定的输入输出示例模型会模仿示例的风格。示例要选质量高的、有代表性的不要随便放。我用的示例是一份我自己手写的理想日报模型模仿得挺像。5.3 成本控制的几个实用手段自动化跑起来之后成本是个绕不开的话题。每天一次调用一个月三十次如果模型选得贵、输入又长账单会很难看。我总结了几个控成本的手段。第一控制输入长度。原始信息不是越多越好取最相关的 20 到 30 条就够了。我实测过输入从 50 条减到 30 条日报质量几乎没变化但 token 消耗降了四成。第二选对模型档位。前面说过flash 档够用就别上顶级档。日报这种任务模型能力的边际收益递减很快多花的钱换不来等比例的质量提升。第三加缓存。如果某天的原始信息和前一天高度重合比如周末信息少可以复用前一天的日报只做增量更新。这个优化我还没做但思路是可行的。第四监控用量。定期看 token 消耗趋势发现异常增长及时排查。我有一次因为采集层出了 bug重复抓了大量内容token 消耗翻了好几倍及时发现才没造成大损失。提示成本控制的核心不是少花钱而是把钱花在刀刃上。该用模型的地方用模型不该用的地方用规则混合策略往往比纯模型方案更经济。6. 后续可以怎么扩展这套方案跑通基础版之后我陆续加了一些扩展这里分享几个我觉得价值比较高的方向。第一个是多频道日报。现在只有一份综合日报后来我按主题拆成了技术动态、行业新闻、竞品监控三个频道用户可以在小程序里订阅自己关心的频道。实现上就是采集层按主题分组生成层跑三次推送层根据订阅关系分发。工作量不大但实用性提升明显。第二个是历史归档与检索。日报每天生成积累下来就是一个小型知识库。我在小程序里加了一个历史页面可以按日期翻看也可以按关键词搜索。这个功能对我记得上周看到过一条关于 XX 的动态这种场景特别有用。第三个是反馈闭环。在小程序里给每条要点加一个有用/没用的按钮用户点了之后记录下来定期分析哪些来源、哪些类型的要点更受欢迎反过来优化采集和生成策略。这个功能还在做但思路是清晰的让日报越用越懂用户。第四个是多端同步。现在只在微信里看后来我把日报同步到了其他常用的工具里比如笔记软件、待办清单。实现上就是推送层多接几个出口内容复用。这样无论我在哪个工具里工作都能看到当天的日报。这套东西从想法到跑通前后花了大概两周的业余时间。最大的感受是自动化的价值不在于省了多少时间而在于把需要记得做的事变成自动发生的事。以前我总担心漏看重要信息现在这个焦虑没了因为我知道每天十点半会有一份整理好的日报送到我手上。这种确定性带来的心理收益比省下的那半小时时间更值钱。如果你也想搭一套我的建议是先跑通最小闭环再逐步优化。不要一上来就追求完美先把采集→生成→推送这条线打通哪怕日报质量一般先让它跑起来。跑起来之后你才有真实的反馈才知道该往哪个方向优化。我第一版的日报质量其实挺差的但正是因为它每天在跑我才能持续迭代慢慢调到现在的水平。