1. 这套自动日报系统到底在解决什么问题每天早上到工位第一件事是打开各种信息源翻一遍昨天夜里到今早发生了什么然后手动整理成一段能看的摘要——这件事我干了快两年直到某天早上我盯着屏幕上第七个标签页发呆突然意识到这个动作本身没有任何创造性它完全可以被自动化掉。于是就有了这个项目给 WorkBuddy 设一个定时任务每天上午十点半让它自动生成一份 AI 日报然后推送到微信里。十点半这个时间点是刻意选的不是随便定的——太早很多海外信息源还没更新完太晚上午的工作节奏已经被打断了。十点半刚好是上午第一波专注期结束、准备进入下一段工作之前的空档这时候一份整理好的日报进来既不打扰深度工作又能让你在切换任务的间隙快速补齐信息差。这套东西适合谁三类人。第一类是每天需要跟踪特定领域动态的从业者比如做 AI 产品的、做技术选型的、做行业研究的第二类是已经在用 WorkBuddy 但只把它当聊天工具、没想过它能干定时活的人第三类是想学自动化工作流搭建、但一直没找到合适练手项目的人。不管你属于哪一类这套方案的搭建成本都不高核心逻辑也不复杂但里面有几个坑我踩过后面会一个一个说清楚。整个系统的骨架其实就三块定时触发、内容生成、消息推送。听起来简单但每一块都有值得展开的细节。定时触发决定了你什么时候收到日报内容生成决定了日报的质量消息推送决定了你能不能第一时间看到。这三块串起来才是一个完整的闭环。2. 整体架构设计与关键选型思路2.1 为什么是 WorkBuddy 而不是自己写脚本很多人第一反应是我直接写个 Python 脚本调个 API生成摘要再推到微信不就行了技术上完全可行但实际维护起来有几个麻烦。第一信息源的抓取和清洗是脏活。不同来源的格式不一样有的返回 JSON有的返回 HTML有的还要处理编码问题。你自己写脚本这部分代码会越堆越厚最后变成一个没人敢动的屎山。WorkBuddy 这类工具的价值在于它把获取信息和生成内容这两步做了封装你只需要告诉它要什么它去处理中间的脏活。第二模型调用和 prompt 管理。你要自己管 API key、处理限流、调 prompt 模板这些在 WorkBuddy 里是内置能力。特别是 prompt 这块WorkBuddy 支持你定义规则而且可以让规则对后续所有任务生效——这个特性后面会详细讲它是让日报质量稳定的关键。第三定时调度。自己写脚本要配 cron要考虑服务器时区要处理任务失败重试。WorkBuddy 的定时能力虽然不算特别强但应付每天固定时间跑一次这种需求绰绰有余。所以选型的核心逻辑是把精力花在日报内容怎么组织上而不是花在怎么把数据从 A 搬到 B上。工具的价值就是让你专注在真正需要判断力的地方。2.2 微信推送为什么选小程序而不是公众号或企业微信推送渠道这块我试过几种方案最后落在微信小程序上理由如下。公众号模板消息的问题在于它需要用户主动关注而且模板消息的格式限制很死你想发一份结构化的日报排版会很难看。企业微信机器人倒是方便但它的使用场景偏工作协作如果你只是想要一个个人日报用企业微信有点杀鸡用牛刀而且不是所有人都在企业微信环境里。微信小程序的好处是它天然在微信生态内你不需要额外装 App打开微信就能看。而且小程序可以做成一个日报阅读器的形态日报不是一条消息而是一个可以翻阅、可以回看历史记录的页面。这个体验比收到一条长消息要好得多。具体实现上我用的是小程序 云开发的组合。WorkBuddy 生成日报后通过云函数写入数据库小程序端读取数据库渲染页面。这样日报是持久化的你随时可以翻昨天的、上周的而不是像消息一样刷过去就没了。2.3 deepseek-v4-flash 在其中的角色模型选型上我用了 deepseek-v4-flash。选它的原因很直接日报生成这个任务对模型的深度推理要求不高但对速度和成本要求很高。你不需要模型去解数学题你需要它快速把一堆信息压缩成一段通顺的话。flash 版本在这个场景下性价比最高。实测下来一份包含 8 到 10 条信息的日报生成时间在 3 到 5 秒之间完全在可接受范围内。如果你用更大的模型生成时间可能翻倍但日报质量提升并不明显——因为这个任务的瓶颈不在模型能力而在你给它的信息质量和 prompt 质量。这里有个经验不要指望模型帮你判断什么重要。你要在 prompt 里明确告诉它筛选标准比如优先保留有具体数据的信息忽略纯观点输出每条不超过 50 字。模型很擅长执行明确指令但不擅长替你做价值判断。3. 核心环节拆解与实操要点3.1 定时触发十点半这个时间是怎么定下来的定时任务看起来是最简单的一环但时间点的选择其实有讲究。我最初设的是早上八点想着一早就能看到。结果发现两个问题一是很多海外信息源在北京时间八点还没更新完日报内容偏少二是八点正是处理夜间积压消息的时候日报进来反而被淹没了。后来改到十点半信息源更新完整了而且这个时间点你有空看。WorkBuddy 的定时配置里时区一定要确认清楚。如果你用的是国际版默认时区可能不是北京时间需要手动调整。这个坑我踩过——设了十点半结果下午六点半才收到排查了半天才发现是时区问题。提示定时任务设好后第一天一定要手动确认触发时间是否正确。不要等到第二天才发现时区错了。另外定时任务的失败处理也要考虑。如果某天 WorkBuddy 那边服务波动任务没跑成功你是希望它重试还是跳过等明天我的选择是跳过。日报这种东西晚几个小时补上意义不大反而会造成信息混乱。所以我在配置里关掉了自动重试失败了就失败了第二天正常跑。3.2 内容生成prompt 规则怎么定才能让日报稳定这是整个项目里最值得花时间的地方。日报质量好不好90% 取决于你的 prompt 规则。WorkBuddy 有一个很好用的特性你可以定义一组规则让它们对后续所有任务生效。这意味着你不需要每次生成日报都重新写一遍 prompt而是把规则设一次之后所有日报任务都自动套用。我的规则大概是这样几条信息筛选规则优先保留包含具体数字、时间、产品名的信息忽略纯情绪表达和没有信息增量的观点。格式规则每条信息控制在 50 字以内用一句话说清楚谁做了什么或发生了什么。分类规则把信息分成产品动态技术进展行业事件三类每类不超过 4 条。语气规则用陈述句不用感叹句不加主观评价。这几条规则定下来之后日报的稳定性明显提升。之前没有规则的时候模型有时候会把一条信息展开成一大段有时候又会漏掉重要内容。有了明确规则输出就收敛了。这里有个细节规则要写得具体不要写简洁一点重要一点这种模糊表述。模型对模糊指令的理解每次都不一样但对具体指令的执行很稳定。比如每条不超过 50 字就比简洁一点好得多。3.3 消息推送小程序端怎么接推送这块我用的是微信小程序的云开发能力。整体流程是WorkBuddy 生成日报后调用云函数云函数把日报内容写入云数据库小程序端监听数据库变化并渲染。为什么不用订阅消息因为订阅消息需要用户每次授权而且消息格式受限。用云开发的话日报是存在数据库里的小程序打开就能看到不依赖消息推送。你甚至可以在小程序里加一个未读标记提醒自己有新日报。小程序端的页面结构很简单一个列表页按日期倒序排列日报点进去是详情页展示当天的完整日报。顶部导航栏高度这个细节要注意微信小程序的默认导航栏在不同机型上高度不一样如果你要做自定义导航栏需要用wx.getSystemInfoSync()获取状态栏高度然后加上导航栏高度。这个坑我在做另一个小程序时踩过日报这个小程序里我直接用了默认导航栏省事。数据缓存方面小程序的wx.setStorageSync有大小限制单条数据不能超过 1MB。日报内容一般不会超但如果你要存历史记录建议只缓存最近 7 天更早的从数据库拉。4. 完整实操流程与关键配置4.1 第一步在 WorkBuddy 里把规则设好打开 WorkBuddy找到规则设置的地方。不同版本的入口可能不一样国际版和国内版的界面也有差异但核心逻辑是一样的找到规则或自定义指令相关的设置项。规则内容我建议直接复制下面这段然后根据自己的需求微调你是一个 AI 日报生成助手。请按照以下规则生成日报 1. 信息筛选优先保留包含具体数字、时间、产品名、公司名的信息。忽略纯观点、纯情绪、没有信息增量的内容。 2. 格式要求每条信息用一句话表达不超过 50 字。用陈述句不用感叹句。 3. 分类要求将信息分为产品动态技术进展行业事件三类每类最多 4 条。 4. 输出格式先写日期然后按分类列出信息每条前面加序号。 5. 语气要求客观陈述不加主观评价不用令人震惊重磅等夸张词汇。设好之后先手动跑一次测试看看输出是否符合预期。如果不符合调整规则再跑。这个迭代过程可能要重复三四次但一旦调好后面就省心了。4.2 第二步配置定时任务在 WorkBuddy 里新建一个任务任务类型选定时任务或计划任务。触发时间设为每天 10:30时区确认为北京时间UTC8。任务内容就是调用你设好的日报生成规则。有些版本的 WorkBuddy 支持直接在任务里引用规则有些需要你把规则内容再贴一遍。如果是后者建议把规则存成一个模板文件每次直接引用避免规则不一致。任务输出格式选 Markdown 或纯文本都可以看你小程序端怎么解析。我用的是 Markdown因为结构清晰小程序端解析起来也方便。注意定时任务设好后检查一下任务失败后的行为。如果选项里有重试建议关掉。日报不需要重试失败了等明天就好。4.3 第三步打通 WorkBuddy 到小程序的链路这一步是整个项目里技术含量最高的部分。WorkBuddy 生成日报后需要把内容传到小程序能读到的地方。我的做法是WorkBuddy 任务完成后通过 webhook 调用微信云函数的 HTTP 触发器。云函数收到内容后写入云数据库。云函数的核心代码大概是这样const cloud require(wx-server-sdk) cloud.init() const db cloud.database() exports.main async (event, context) { const { content, date } event try { const result await db.collection(daily_reports).add({ data: { content: content, date: date, createdAt: new Date() } }) return { success: true, id: result._id } } catch (err) { return { success: false, error: err.message } } }WorkBuddy 那边配置 webhook 的时候URL 填云函数的 HTTP 触发器地址请求方法用 POSTbody 里带上content和date两个字段。这里有个坑云函数的 HTTP 触发器需要在小程序后台配置合法域名否则请求会被拦截。配置路径在开发管理→开发设置→服务器域名里把云函数的域名加进去。4.4 第四步小程序端渲染日报小程序端我用了最简结构一个列表页 一个详情页。列表页读取daily_reports集合按date倒序排列展示日期和日报摘要。详情页根据 ID 读取单条记录渲染完整内容。关键代码// 列表页 Page({ data: { reports: [] }, onLoad() { const db wx.cloud.database() db.collection(daily_reports) .orderBy(date, desc) .limit(30) .get() .then(res { this.setData({ reports: res.data }) }) } })详情页的渲染要注意 Markdown 解析。小程序原生不支持 Markdown需要用towxml这类库来转换。如果嫌麻烦也可以让 WorkBuddy 直接输出纯文本小程序端用rich-text组件渲染。5. 常见问题与排查技巧实录5.1 日报内容质量不稳定怎么办这是最常见的问题。表现是有时候日报很精炼有时候又很啰嗦有时候分类清晰有时候又混在一起。排查思路先看规则是不是够具体。如果规则里写了简洁一点模型每次理解都不一样。改成每条不超过 50 字这种可量化的标准稳定性会大幅提升。如果规则已经够具体但还是不稳定检查信息源的质量。如果输入的信息本身就是碎片化的、没有明确主题的模型也很难整理出结构化的日报。这种情况下要么换信息源要么在规则里加一条如果信息不足以分类就统一放在其他分类下。还有一个可能模型版本变了。WorkBuddy 后台可能会更新模型版本新版本对同一套规则的理解可能不一样。如果发现日报风格突然变了先确认模型版本有没有变。5.2 定时任务没触发怎么排查按这个顺序查时区确认任务时区是不是北京时间。国际版默认可能是 UTC差 8 小时。任务状态在 WorkBuddy 的任务列表里看任务是不是启用状态。有时候创建完忘了启用。执行日志看任务有没有执行记录。如果有记录但没输出说明是生成环节出了问题如果连记录都没有说明是触发环节出了问题。服务状态确认 WorkBuddy 服务本身是否正常。偶尔会有服务波动等一会儿再试。5.3 小程序收不到数据怎么排查先确认云函数有没有被调用。在云开发控制台的云函数→日志里看有没有调用记录。如果有调用记录但数据库没数据检查云函数的数据库权限。云函数默认有管理员权限但如果你改过权限设置可能会导致写入失败。如果数据库有数据但小程序不显示检查小程序的数据库查询权限。小程序端默认只能读自己创建的数据如果日报是云函数创建的需要把集合权限设为所有用户可读。5.4 常见问题速查表问题现象可能原因排查方法解决方案日报内容啰嗦规则不够具体检查规则里的格式要求改成可量化的标准如每条不超过50字定时任务没触发时区错误检查任务时区设置改为北京时间 UTC8小程序无数据数据库权限问题检查集合权限设置设为所有用户可读云函数调用失败合法域名未配置检查小程序后台域名配置添加云函数域名到合法域名列表日报分类混乱信息源质量差检查输入信息的结构换信息源或在规则里加兜底分类生成速度慢模型选型过大确认使用的模型版本换用 flash 版本5.5 几个我踩过的坑第一个坑规则设了但没生效。WorkBuddy 的规则有作用范围有些规则只对当前会话生效有些对后续所有任务生效。我一开始设成了前者结果每次新任务都要重新设。后来找到对后续所有任务生效的选项才一劳永逸。第二个坑webhook 地址填错。云函数的 HTTP 触发器地址有一串随机字符复制的时候容易漏掉末尾的斜杠或者多复制了空格。建议复制后先在浏览器里访问一下确认地址有效。第三个坑小程序缓存导致看不到新日报。小程序的wx.setStorageSync缓存不会自动过期如果你在onLoad里先读缓存再请求网络可能会一直看到旧数据。解决方案是在onShow里强制刷新或者给缓存加时间戳。第四个坑日报日期格式不统一。WorkBuddy 输出的日期格式可能是2024-01-15也可能是Jan 15, 2024小程序端排序会乱。解决方案是在云函数里统一转成时间戳再存。6. 后续可以怎么扩展这套系统跑顺之后我陆续加了一些扩展这里分享几个我觉得比较实用的。加一个关键词高亮功能。在小程序端渲染日报时把你关心的关键词比如你所在公司的名字、你跟踪的产品名高亮显示。这样你扫一眼就能看到跟自己相关的信息不用逐条读。加一个收藏功能。看到有价值的日报条目可以收藏起来后面做周报或者月报的时候直接引用。这个功能实现起来很简单在数据库里加一个starred字段就行。加一个周报自动生成。每周日晚上让 WorkBuddy 把过去 7 天的日报汇总成一份周报。这个只需要在 WorkBuddy 里再建一个定时任务规则改成汇总过去 7 天的日报提取重复出现的关键词和趋势。换信息源。如果你觉得当前信息源不够好可以在 WorkBuddy 里配置多个信息源让日报覆盖更全面。但要注意信息源不是越多越好太多会导致日报过长反而没人看。我的经验是控制在 3 到 5 个信息源比较合适。加一个未读提醒。在小程序里加一个红点标记提示有新的日报。这个用wx.setTabBarBadge就能实现很简单但很实用。这套东西我从搭建到跑顺大概花了一个周末后面就是微调规则和加功能。现在每天早上十点半日报准时进来我花三分钟扫一遍该知道的都知道了。省下来的时间够我多写两段代码或者多喝一杯咖啡。