1. 为什么我要折腾一个“AI 日报闹钟”每天早上到工位第一件事是打开各种信息源技术社区的热榜、几个行业资讯站、团队内部的知识库更新、还有几个我长期跟踪的博主。一圈刷下来二十分钟没了真正有价值的信息可能就三五条。更麻烦的是这事儿一旦忙起来就断档断个两三天再捡起来又得重新建立信息脉络。我想要的其实特别简单每天上午十点半一份已经筛过、归过类、带摘要的 AI 日报自动出现在微信里。不用我打开任何 App不用我点任何按钮就像设了个闹钟一样到点东西自己就来了。这个需求拆开看核心就三件事定时触发、内容抓取与 AI 加工、推送到微信。听起来像是个典型的自动化流水线但真动手做的时候坑比想象中多——尤其是“送进微信”这一步微信生态对外部程序主动推送消息的限制是出了名的严格。我前后试了三套方案踩了七八个坑最后跑通的这套组合是WorkBuddy 做定时调度和流程编排DeepSeek 做内容摘要和分类微信侧用“文件传输助手 服务号模板消息”双通道兜底。整套东西跑了一个多月除了有两天因为源站改版导致抓取失败其余时间都是十点半准时到误差不超过两分钟。这篇文章我会把整套方案的选型逻辑、每个环节的具体配置、参数怎么算、坑怎么填全部摊开讲。适合两类人看一类是想给自己搭一套个人信息自动化流水线的另一类是想把 WorkBuddy 和 DeepSeek 串起来做实际项目的。哪怕你之前没碰过自动化工具跟着走也能跑通。2. 整体方案设计与选型思路2.1 为什么是 WorkBuddy 而不是自己写脚本最开始我是想直接用 Python 写个脚本挂个 crontab 就完事了。但实际写下来发现一个“日报机器人”远不止定时执行那么简单。它需要定时触发、多源抓取、失败重试、内容去重、AI 调用、结果格式化、推送分发、运行日志。这些东西如果全用脚本手写光是异常处理和重试逻辑就够写两百行而且换个信息源就得改代码。WorkBuddy 吸引我的点在于它把“任务编排”这件事做成了可视化配置。你可以把整个流程拆成若干个节点触发节点、HTTP 请求节点、数据处理节点、AI 调用节点、推送节点。每个节点独立配置节点之间用数据流串联。这意味着我改一个信息源的 URL不需要动其他任何逻辑我想加一个新的推送渠道只需要在末尾挂一个节点。提示WorkBuddy 的节点式编排和传统脚本的最大区别在于“关注点分离”。脚本里所有逻辑揉在一起改一处可能影响全局节点式编排里每个节点只负责一件事改动的爆炸半径可控。另一个关键考量是定时触发的可靠性。crontab 在服务器重启后会丢失任务状态而且如果上一次任务还没跑完下一次又触发了容易出现并发冲突。WorkBuddy 内置了任务锁机制同一个任务在上一次执行未结束时下一次触发会自动跳过或排队这个细节在实际运行中非常关键。2.2 DeepSeek 在流水线里扮演什么角色抓取下来的原始内容是一堆标题和链接直接推给我意义不大——我没时间一条条点开看。所以中间必须有一个“加工”环节把原始信息变成可读的摘要。我对比过几个方案本地跑一个小模型做摘要优点是数据不出本地缺点是效果差、速度慢用通用大模型 API效果好但成本高。DeepSeek 在这个场景下的优势比较明显中文摘要质量稳定、API 调用成本低、响应速度快。我实测下来一篇 800 字的技术文章DeepSeek 生成 100 字左右的摘要耗时大约 1.5 到 2 秒成本几乎可以忽略不计。具体用法上我不是让 DeepSeek 简单地“总结一下”而是给它一个结构化的提示词要求它输出固定格式的 JSON包含标题、一句话摘要、关键要点最多三条、所属分类、重要程度评分1 到 5。这样后续的格式化节点可以直接解析 JSON不需要再做额外的文本处理。2.3 微信推送的三种路径与最终选择“送进微信”是整个方案里最折腾的部分。微信对外部程序主动推送消息的限制非常严格我前后试了三种路径推送路径实现方式优点缺点适用场景文件传输助手通过微信网页版协议模拟发送直接出现在聊天列表协议不稳定有封号风险不推荐服务号模板消息注册服务号调用模板消息接口稳定、官方支持需要认证服务号有资质门槛有服务号资源的企业微信机器人创建群机器人通过 Webhook 推送配置简单、稳定需要企业微信推荐方案我最终选的是企业微信机器人 Webhook。原因很简单配置成本极低创建一个群添加一个机器人拿到 Webhook 地址往这个地址 POST 一条消息就完事了。而且企业微信的消息可以同步到个人微信如果绑定了的话在手机通知栏就能看到。注意企业微信机器人的 Webhook 地址里包含一个 key这个 key 等同于密码不要泄露到公开仓库里。我在 WorkBuddy 里是把它存在环境变量里的节点配置里只引用变量名。如果你没有企业微信退而求其次的方案是用服务号的模板消息但需要有一个认证过的服务号个人开发者申请比较麻烦。还有一个更轻量的方案是邮件推送虽然不在微信里但手机邮件 App 的通知也能达到类似效果。3. 核心环节拆解与实操配置3.1 信息源的选择与抓取策略信息源的质量直接决定了日报的质量。我一开始贪多塞了十几个源进去结果每天抓回来一百多条AI 处理要跑好几分钟最后推给我的日报长得像一篇论文根本看不完。后来我做了减法最终保留五个源覆盖三个维度技术动态类两个技术社区的热榜主要看大家在讨论什么行业资讯类一个 AI 领域的资讯站看有没有重要的产品发布或论文深度内容类两个我长期跟踪的博主更新质量稳定团队内部一个内部知识库的更新列表抓取方式上大部分源用的是 RSS少部分没有 RSS 的用 HTML 解析。WorkBuddy 的 HTTP 请求节点支持自定义请求头和超时时间我一般把超时设成 15 秒超过就跳过这个源不让它拖慢整个流程。{ source_name: tech_community_hot, url: https://example.com/api/hot, method: GET, timeout: 15000, headers: { User-Agent: Mozilla/5.0 (compatible; DailyBot/1.0) }, retry: { max_attempts: 2, interval: 3000 } }重试策略我设的是最多两次间隔三秒。实测下来大部分临时故障比如网络抖动重试一次就能成功两次还失败的基本就是源站挂了再重试也没用。3.2 DeepSeek 提示词的设计与调优提示词的设计直接决定了摘要质量。我前后改了六版最终稳定下来的版本是这样的你是一个技术资讯编辑。请对以下内容进行处理输出严格的 JSON 格式不要输出任何其他文字。 输入内容 标题{{title}} 正文{{content}} 输出要求 { title: 保留原标题如果标题超过30字则精简, summary: 用一句话概括核心内容不超过80字, key_points: [要点1, 要点2, 要点3], category: 从以下分类中选择一个模型发布、产品更新、技术教程、行业观点、工具推荐, importance: 1到5的整数5表示非常重要 } 注意 - summary 要客观陈述不要加入主观评价 - key_points 最多三条每条不超过40字 - 如果内容质量太低或无法理解importance 设为1这个提示词有几个关键设计点。第一强制 JSON 输出这样后续节点可以直接解析不需要用正则去提取。第二分类枚举限定在五个类别里避免模型自由发挥导致分类混乱。第三重要程度评分这样我可以在推送前做过滤只推 importance 大于等于 3 的内容。实测下来DeepSeek 对这个提示词的遵循度很高JSON 解析成功率在 98% 以上。偶尔会出现模型在 JSON 外面包了一层 json 代码块的情况这个在解析节点里做一下兼容处理就行。3.3 内容去重与排序逻辑去重这件事比想象中重要。同一个新闻可能三个源都在发如果不去重日报里会出现三条几乎一样的内容。我的去重策略是标题相似度 URL 域名双重判断。具体来说先把所有条目的标题做归一化处理去掉标点、转小写、去掉空格然后计算两两之间的编辑距离。如果编辑距离小于标题长度的 30%就认为是重复内容只保留 importance 最高的那条。排序逻辑上我用的公式是最终得分 importance × 0.6 时效性得分 × 0.3 来源权重 × 0.1时效性得分是根据发布时间计算的24 小时内的得 1.024 到 48 小时的得 0.7超过 48 小时的得 0.3。来源权重是我手动给每个源设的深度内容类的源权重高一些热榜类的低一些。这个公式不是拍脑袋想的是我跑了两周之后根据实际阅读体验调的。一开始 importance 的权重设的是 0.8结果推过来的全是“重磅”“震惊”类的内容深度分析反而被挤掉了。调到 0.6 之后平衡感好很多。3.4 微信推送的格式化与发送企业微信机器人的消息支持 Markdown 格式这比纯文本可读性高很多。我的日报格式是这样的## AI 日报 · 2025-01-15 今日共筛选 8 条以下按重要程度排序 ### 1. [模型发布] 某团队发布新一代开源模型 **摘要**该模型在多项基准测试中表现优异推理成本降低约 40%。 **要点** - 参数规模 70B支持 128K 上下文 - 开源协议为 Apache 2.0 - 已在多个平台上线 [阅读原文](https://example.com/article/123) --- ### 2. [技术教程] 如何用 WorkBuddy 搭建自动化流水线 ...每条内容之间用---分隔标题里带上分类标签方便快速扫读。链接放在最后想深入看的直接点。推送节点里有一个细节需要注意企业微信机器人对消息长度有限制单条消息不能超过 4096 字节。如果日报内容太长需要做分片发送。我的处理方式是如果格式化后的内容超过 3500 字节就按条目拆分分多条发送每条前面加一个“1/3”这样的序号。4. 完整实操流程与关键参数4.1 环境准备与 WorkBuddy 任务创建WorkBuddy 的安装过程这里不展开官方文档写得很清楚。重点说一下任务创建时的几个关键配置。创建任务时触发方式选“定时触发”Cron 表达式填30 10 * * *这就是每天上午十点半触发。时区一定要选对我一开始没注意默认是 UTC结果推送时间是下午六点半白白等了一天。任务创建后先别急着配节点先把环境变量配好。我用到的环境变量有变量名用途示例值DEEPSEEK_API_KEYDeepSeek 接口密钥sk-xxxxxxxxWECOM_WEBHOOK企业微信机器人地址https://qyapi.weixin.qq.com/...SOURCE_CONFIG信息源配置 JSON见下方环境变量配好之后节点里引用变量用{{env.VARIABLE_NAME}}的语法这样配置和密钥分离分享配置的时候不会泄露敏感信息。4.2 节点编排的完整流程整个任务的节点编排是这样的定时触发节点每天 10:30 触发并行抓取节点组五个源并行抓取每个源一个 HTTP 请求节点数据合并节点把五个源的结果合并成一个数组去重节点按标题相似度去重AI 处理节点循环调用 DeepSeek逐条生成摘要过滤排序节点按 importance 过滤按得分排序格式化节点生成 Markdown 格式的日报推送节点发送到企业微信机器人日志节点记录本次执行的结果写入日志文件并行抓取这个设计很关键。如果串行抓取五个源每个平均 3 秒光抓取就要 15 秒。并行之后总耗时取决于最慢的那个源一般 5 秒以内搞定。AI 处理节点我设的是并发数为 3也就是同时处理三条内容。这个数字是权衡的结果并发太高DeepSeek 接口可能限流并发太低处理速度慢。实测并发 3 的情况下20 条内容大约 15 秒处理完。4.3 参数计算与性能调优整个流程的耗时分布大致是这样的环节耗时占比并行抓取3-5 秒15%去重1 秒3%AI 处理20条并发312-18 秒55%过滤排序1 秒3%格式化与推送2-3 秒10%其他开销2-3 秒14%总计20-30 秒100%从十点半触发到推送到达整个过程大约 25 秒。这个速度我觉得可以接受毕竟不是实时性要求很高的场景。如果要进一步优化最大的空间在 AI 处理环节。两个方向一是提高并发数但要注意接口的限流阈值二是减少处理条数在 AI 处理之前先做一轮粗筛把明显不重要的内容过滤掉。我目前是在抓取阶段就做了限制每个源最多取 10 条总共不超过 50 条去重后一般剩 20 到 30 条。4.4 日志与监控配置日志这块我踩过一个坑。一开始没配日志结果有一天日报没来我完全不知道是哪个环节出了问题只能从头排查。后来加了日志节点每次执行都记录抓取到多少条、去重后剩多少条、AI 处理成功多少条、推送是否成功、总耗时多少。日志格式我用的是 JSON Lines每行一条记录方便后续用脚本分析。日志文件按天切割保留最近 30 天。{date:2025-01-15,trigger_time:10:30:00,fetch_count:47,dedup_count:23,ai_success:23,ai_fail:0,push_status:success,total_duration:24.3}有了日志之后排查问题就快多了。有一次推送失败我看日志发现 push_status 是 failed错误信息是“webhook key invalid”一查发现是企业微信机器人的 key 过期了重新生成一个换上就好了。5. 常见问题与排查技巧实录5.1 抓取失败源站改版与反爬问题表现某个源连续几天抓取结果为 0 条日志里显示 HTTP 状态码 200 但内容为空。排查思路先手动访问那个源的 URL看看返回的内容结构是不是变了。我遇到过一次源站把文章列表从 HTML 里的ul改成了 JavaScript 动态加载原来的解析规则完全失效。解决方法如果是 RSS 源检查 RSS 地址是否还有效如果是 HTML 解析需要更新解析规则。我的建议是尽量用 RSS因为 RSS 的格式相对稳定源站改版一般不会影响 RSS 输出。如果必须用 HTML 解析把解析规则写成可配置的改的时候只改配置不改代码。实操心得我给自己定了个规矩每个月第一个周一手动检查一遍所有源看看有没有异常。这个习惯帮我提前发现了两次源站改版避免了日报断档。5.2 AI 处理超时或返回格式错误问题表现AI 处理节点报错错误信息是“JSON parse failed”或者“request timeout”。排查思路JSON 解析失败通常是模型没有严格按格式输出可能是在 JSON 外面包了代码块或者输出了额外的解释文字。超时一般是网络问题或者接口限流。解决方法对于 JSON 解析失败在解析之前先做一轮清洗去掉json 和标记去掉首尾空白。如果还是失败就把这条内容标记为“处理失败”跳过它继续处理下一条不要让一条失败卡住整个流程。对于超时把超时时间从默认的 10 秒调到 20 秒同时把并发数从 3 降到 2。import json import re def parse_ai_response(raw_text): # 去掉可能的代码块标记 cleaned re.sub(r^json\s*, , raw_text.strip()) cleaned re.sub(r\s*$, , cleaned) try: return json.loads(cleaned) except json.JSONDecodeError: # 尝试提取第一个完整的 JSON 对象 match re.search(r\{.*\}, cleaned, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: return None return None5.3 微信推送失败消息太长或格式错误问题表现推送节点返回错误码 40058 或 40008提示消息格式不正确或消息太长。排查思路企业微信机器人对 Markdown 消息的支持有一些限制比如不支持表格、不支持嵌套列表超过两层。消息长度超过 4096 字节也会报错。解决方法把表格改成列表把嵌套列表拍平。长度问题用分片解决我写了一个简单的分片函数按条目拆分保证每片不超过 3500 字节。错误码含义解决方法40058消息格式错误检查 Markdown 语法去掉不支持的格式40008消息太长分片发送每片不超过 3500 字节93000webhook key 无效重新生成机器人 key45009接口调用超过限制降低推送频率每天不超过 20 条5.4 日报内容质量下降信息源污染与模型漂移问题表现连续几天推过来的内容都是低质量的营销文或者标题党。排查思路先看是哪个源的问题在日志里加上源名称字段统计每个源的 importance 平均值。如果某个源的平均 importance 持续低于 2说明这个源的质量在下降。解决方法短期方案是调低这个源的权重或者直接暂时移除。长期方案是定期审视信息源列表把质量下降的源替换掉。我一般每季度做一次信息源审查看看哪些源还在贡献有价值的内容哪些已经变成水文聚集地了。注意不要因为一两天的质量波动就急着换源有些源的质量是周期性的比如周末质量低、工作日质量高。至少观察一周再下结论。5.5 定时任务未触发或重复触发问题表现日报没来或者同一天收到了两份。排查思路先看 WorkBuddy 的任务执行记录确认是没触发还是触发了但执行失败。如果没触发检查 Cron 表达式和时区设置。如果重复触发检查是否有多个任务实例在运行。解决方法Cron 表达式我建议用在线工具验证一下确保理解正确。时区一定要显式设置不要依赖默认值。重复触发的问题WorkBuddy 有任务锁机制在任务配置里开启“防止并发执行”选项即可。6. 后续可以继续折腾的方向这套东西跑了一个多月基本达到了我最初的目标每天十点半一份筛选过的 AI 日报自动到微信。但用着用着又冒出了一些新的想法。第一个方向是个性化推荐。现在的排序逻辑是全局统一的但不同的人关注点不一样。我在想能不能根据我过去一周的点击行为动态调整分类权重。比如我最近在关注模型发布类的新闻那这类内容的权重就自动调高。这个需要记录点击行为目前还没做但思路是可行的。第二个方向是多端同步。现在只推送到企业微信有时候在电脑前工作更希望日报直接出现在浏览器的一个标签页里。我在考虑加一个 Web 页面把每天的日报存成静态 HTML通过一个简单的静态服务器提供访问。这样微信和网页两个渠道都能看。第三个方向是交互式追问。现在的日报是单向推送我看完之后如果有疑问没法直接追问。如果能把 DeepSeek 的对话能力接进来让我可以在微信里直接回复某条内容进行追问那就更实用了。不过这个涉及到消息接收的处理比单向推送复杂不少需要再研究一下企业微信的接收消息接口。最后分享一个我在配置过程中总结的小技巧先把流程跑通再优化细节。我一开始花了很多时间在调提示词上想把摘要质量调到完美结果整个流程还没跑通调了也没法验证效果。后来我改变策略先用最简单的提示词把全流程跑通看到日报真的推过来了再逐步优化每个环节。这个顺序很重要先有反馈再谈优化。