1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是打开编辑器而是先刷一遍几个技术社区、翻两页行业动态、再看看昨天夜里群里有没有人甩出什么新工具。这套动作看着不起眼实际每天要吃掉我将近四十分钟而且刷完经常是“看了很多记住很少”。我真正想要的其实很简单每天上午十点半一份已经整理好的 AI 日报自动出现在微信里我端着咖啡扫一眼就能知道今天该关注什么。这个需求听起来像“做个定时推送”但真动手就会发现里面全是细节。定时任务本身不难难的是三件事第一内容从哪来、怎么保证质量第二怎么把结果稳定地送进微信而不是发到一半断了第三怎么让这套东西长期无人值守地跑下去而不是跑三天就挂。我前后折腾了大概两周中间踩了不少坑最后用WorkBuddy作为任务编排的核心配合deepseek-v4-flash这类响应快、成本低的模型做内容加工把整条链路跑通了。这篇文章适合两类人看一类是像我一样每天被信息流淹没、想用自动化把自己捞出来的普通开发者另一类是想入门AI Agent和自动化工作流、但不知道从哪个真实场景下手的同学。我会把整个设计思路、关键参数、实操步骤、以及那些文档里不会写的坑全部摊开讲清楚。你不需要很深的背景跟着做基本能复现一套属于自己的“AI 日报机器人”。先说结论性的东西免得你看到一半才发现方向不对。整套系统的骨架是定时触发 → 多源抓取 → 模型清洗与摘要 → 结构化排版 → 微信推送 → 失败告警。WorkBuddy 负责把这几步串成一条可复用、可观测的任务流模型负责把“一堆原始信息”压成“人能读的日报”微信负责最后一公里的触达。下面我按这个顺序一层一层拆。2. 整体设计思路把“日报”当成一条流水线来搭2.1 为什么选 WorkBuddy 做编排而不是自己写脚本一开始我是想直接写个 Python 脚本挂个 cron 就完事。真写起来才发现脚本能跑但不好维护。抓取源一多异常处理、重试、日志、状态记录全得自己写改一个源就要动一遍主流程。后来我把编排层换成了 WorkBuddy核心原因是它把“任务”和“步骤”做了抽象每个步骤是一个独立单元可以单独重试、单独看日志前一步的输出能直接喂给后一步。这里有个选型上的关键判断编排工具的价值不在于“能定时”而在于“出错时你知道错在哪、能只重跑坏掉的那一段”。我实测下来日报这种每天都要跑的任务最怕的不是跑不起来而是“跑了一半你不知道它到底发没发”。WorkBuddy 的任务状态和步骤级日志正好解决这个痛点。另外它支持把常用逻辑封装成可复用的 skill比如“抓取某个源”“调用模型做摘要”下次做别的自动化任务可以直接拿来用这点对我这种喜欢攒工具的人很友好。需要说明的是WorkBuddy 和 CodeBuddy 这类工具定位不太一样前者更偏任务编排和工作流后者更偏编码辅助。我选它就是因为我要的是“调度 串联”不是“帮我写代码”。如果你只是想本地跑个一次性脚本那确实没必要上编排工具但只要你的任务需要每天稳定运行、还要能观测编排层的投入是值得的。2.2 内容加工为什么用 deepseek-v4-flash 这类模型日报的核心是“把原始信息变成人能快速消化的内容”。原始信息可能是几十条标题、几段摘要、一堆链接直接推给你等于没整理。所以我需要一个模型来做三件事去重、归类、压缩成短句。这里我选的是 deepseek-v4-flash 这一类偏“快而轻”的模型原因很实际日报是每天跑的token 消耗是长期成本用大模型做这种“摘要 归类”的活属于杀鸡用牛刀响应还慢。我做过一个粗略的对比测试同样处理 40 条原始信息轻量模型大概 3 到 5 秒出结果重模型要 15 秒以上而且日报这种场景对“文采”要求不高对“准确、不丢关键信息、格式稳定”要求高。轻量模型在这几点上完全够用。这里的关键经验是不要用模型能力去解决工程问题。比如“去重”这件事能用规则和哈希做的就别丢给模型模型只负责它真正擅长的语义压缩和归类。2.3 微信作为触达端为什么比邮件、钉钉更合适我试过邮件和几个办公 IM最后回到微信理由很朴素我一天里打开频率最高的就是微信。日报这种东西触达率比形式重要。发到邮件里我可能下午才想起来看发到微信里十点半弹出来我顺手就点开了。而且微信的“文件传输助手”或者自建的小号可以当成一个天然的“收件箱”历史日报还能往回翻。但微信推送有个绕不开的现实官方对主动推送有严格限制个人号自动化也有风险。所以我的做法是把日报推送到一个我自己可控的接收端比如通过微信生态里合规的机器人能力或者推送到一个只有我自己的会话里。这里必须强调任何涉及账号自动化的操作都要以不违反平台规则为前提我全程用的是合规的接口和自建接收方式没有去碰那些灰色手段。这一点后面讲实操时会再展开。3. 核心细节拆解日报流水线的每个环节怎么设计3.1 信息源的选择与分级日报质量的上限取决于信息源的质量。我一开始贪多塞了十几个源结果日报又长又杂自己都不想看。后来我做了分级一级源必抓3 到 5 个我真正关心的技术社区和官方博客保证核心信息不漏。二级源选抓一些聚合类站点用来补充“今天大家都在聊什么”。三级源备用偶尔看看的源只在有重大更新时才纳入。分级的好处是日报的“主干”稳定不会被噪音淹没。我建议你一开始就控制在 5 个源以内跑顺了再慢慢加。这里有个实操心得每个源都要单独记录“最近一次成功抓取时间”一旦某个源连续失败日报里要能体现出来而不是悄悄少了一块内容你还不知道。3.2 抓取环节的稳定性设计抓取是最容易出问题的一环。网络抖动、页面改版、反爬策略变化都会让抓取失败。我的处理原则是抓取失败不阻塞整条流水线。具体做法是每个源独立抓取失败就记录失败原因继续抓下一个。最后汇总时如果某个源失败了日报里会标注“该源今日抓取失败”而不是直接报错终止。另外抓取要设置合理的超时和重试。我一般设单次超时 10 秒失败重试 2 次重试间隔 3 秒。这个参数不是拍脑袋定的10 秒足够大多数正常页面返回超过基本就是对方有问题重试 2 次能覆盖大部分瞬时抖动再多就是浪费时间。这些参数在 WorkBuddy 的步骤配置里都能直接设不用自己写循环。3.3 模型加工的提示词设计模型加工这一步提示词prompt的设计直接决定日报的可读性。我踩过的最大坑是一开始提示词写得太“开放”让模型“自由发挥总结”结果每天格式都不一样有时候还自己加戏。后来我把提示词改成了强约束的结构化输出核心要求有三条输出必须是固定字段的 JSON比如{ title: ..., summary: ..., category: ... }。每条摘要不超过 60 字必须包含“发生了什么”和“为什么值得关注”。分类只能从预设的几个标签里选不允许自创。强约束之后日报格式稳定了后续排版也省事。这里的关键经验是把模型当成一个“格式化的翻译器”而不是“有想法的作者”。你给它越明确的边界它输出越可靠。3.4 微信推送的合规实现路径前面提过微信推送要合规。我的实现路径是把日报内容先渲染成一段结构清晰的文本或一张图片然后通过合规的接收端送达。具体来说我用的是一种“自建接收 主动拉取”的思路日报生成后先落库接收端定时拉取最新日报并展示。这样既实现了“十点半能看到”又完全在规则范围内。如果你希望更“即时”可以考虑微信生态里官方支持的机器人能力但一定要看清楚它的使用条款。我个人的原则是凡是需要绕过平台规则才能实现的功能一律不做。日报晚几分钟到没关系账号安全才是底线。这一点我在后面“常见问题”里还会再强调。4. 实操过程从零把这条流水线跑起来4.1 环境准备与 WorkBuddy 基础配置先把基础环境搭好。我用的是 Linux 服务器Ubuntu 22.04Python 3.11。WorkBuddy 的安装按官方文档走就行装完之后先跑一个最简单的“Hello World”任务确认调度能正常触发。这一步别跳过很多人后面出问题其实是基础环境就没通。配置上我做了两件事一是把时区设成我所在的时区避免“十点半”变成“凌晨两点半”二是把日志级别调到 INFO方便排查。WorkBuddy 的任务配置里触发时间用 cron 表达式30 10 * * *就是每天上午十点半。这里有个小坑cron 的分钟在前、小时在后我第一次写反了结果任务在“十点三十分”之外的奇怪时间跑排查了半天。4.2 抓取步骤的实现与参数抓取我用 Python 写了一个通用函数输入是源地址和解析规则输出是结构化列表。核心参数如下参数取值说明timeout10s单次请求超时retry2失败重试次数retry_interval3s重试间隔user_agent常规浏览器 UA避免被简单拦截max_items20单源最多取 20 条防止刷屏max_items这个参数很重要。我一开始不限制某个源一次返回 200 条日报直接爆炸。限制到 20 条之后日报长度可控模型处理也快。这个值可以根据你的源质量调整源越精可以适当放宽。4.3 模型调用与结果解析模型调用这一步我把提示词和调用逻辑封装成了一个独立步骤。调用时传入抓取结果拿回 JSON。这里有个必须处理的细节模型偶尔会返回带 markdown 代码块的 JSON比如用 json 包起来。直接json.loads会报错。我的处理是先做一次清洗把代码块标记去掉再解析。这个坑我踩过日报某天突然空白查了半天才发现是模型“贴心地”加了代码块。解析成功后我会做一次校验字段是否齐全、分类是否在预设范围内、摘要长度是否超标。任何一条不满足就打回让模型重试一次还不行就降级成“原始标题 链接”。永远要有降级方案这是保证日报“每天都有”的关键。4.4 排版与推送的落地排版我追求的是“扫一眼就懂”。结构是日期 一句话总览 按分类分组的条目。每条包含标题、60 字摘要、来源。总览那句话也是模型生成的控制在 40 字以内。排版用纯文本加简单符号不搞花哨的富文本因为接收端渲染能力参差不齐纯文本最稳。推送环节我把渲染好的内容写入一个“日报表”接收端每 5 分钟拉一次。十点半生成最晚十点三十五就能看到。如果你要更即时可以把拉取间隔调到 1 分钟代价是接收端请求变多自己权衡。5. 常见问题与排查技巧实录5.1 任务没触发或触发时间不对最常见的原因是时区或 cron 表达式写错。排查顺序先看服务器时间date再看 WorkBuddy 的时区配置最后核对 cron。我遇到过一次是容器时区默认 UTC导致“十点半”实际是本地时间下午六点半。解决办法是在容器启动时挂载本地时区文件或者直接在配置里指定时区。5.2 抓取大量失败先看是不是网络问题curl手动试一下再看是不是 UA 被拦最后看页面结构是不是变了。我建议给每个源单独写解析规则别用一个通用规则硬套页面结构差异太大。另外失败要记录到日志别静默吞掉。5.3 模型输出格式不稳定回到提示词。确保你明确要求了 JSON 格式、字段名、长度限制、分类枚举。如果还是不稳可以在调用后加一层“格式修复”比如用正则提取 JSON 部分。实测下来强约束 一次重试稳定性可以到 99% 以上。5.4 日报内容重复或遗漏重复通常是去重没做好。我的做法是在抓取后、模型处理前先用标题的哈希做一次粗去重模型再做一次语义去重。遗漏则要检查max_items是不是设太小或者某个源失败了没被发现。日报里标注“源失败”就是为这个准备的。5.5 微信端收不到先确认接收端本身是否正常手动写一条测试数据看能不能拉到再确认日报是否真的生成了查日报表。如果都正常那就是拉取间隔或权限问题。这里再次提醒不要为了“即时”去用不合规的推送方式稳定和安全永远优先。问题现象最可能原因快速排查任务不触发时区/cron 错误查服务器时间与 cron抓取全失败网络或 UA 被拦手动 curl 测试日报空白模型返回格式异常看原始返回内容内容重复去重缺失加标题哈希去重微信收不到接收端或权限问题手动写入测试数据6. 我踩过的坑和几条压箱底的经验第一条经验先跑通最短链路再加功能。我一开始就想把抓取、模型、排版、推送全做完结果每个环节都在调根本不知道问题出在哪。后来我改成先让“一条固定文本”能从触发走到微信确认链路通了再逐个环节替换成真实逻辑。这个顺序能帮你省掉大量排查时间。第二条经验给每个步骤留“可观测的痕迹”。抓取了多少条、模型用了多久、推送成功没有这些都要有记录。日报这种每天跑的任务出问题是必然的关键是出问题时你能五分钟定位而不是翻半天日志。第三条经验成本要算长期账。模型调用、服务器、接收端请求单次都不贵但乘以 365 天就不是小数目。轻量模型 合理限流 缓存是我实测下来性价比最高的组合。比如同一个源的内容一小时内不重复抓取就能省下不少调用。第四条经验也是最重要的合规是底线不是选项。任何涉及账号、平台规则的操作先问自己“这是不是平台允许的”。日报晚到几分钟、形式朴素一点都无所谓账号出问题整套系统就白搭了。我全程用的是合规接口和自建接收虽然没那么“炫”但跑了大半年一直很稳。最后分享一个小技巧我会在日报末尾附一句“今日无重要更新”的兜底文案。当所有源都没抓到有价值内容时日报不会空白而是明确告诉你“今天没什么大事”。这比收到一条空消息体验好太多也避免了“是不是系统挂了”的误判。这套东西跑顺之后我每天早上省下的那四十分钟足够我多写半篇文档或者多喝一杯咖啡了。