1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是泡茶而是打开各种信息源行业群、订阅号、技术社区、项目看板一圈刷下来半小时就没了真正有价值的内容可能就三五条。这种“人肉信息筛选”的活儿干久了谁都烦。我大概在三个月前开始用 WorkBuddy 做日常任务托管它本质上是一个可以挂载多种技能、按规则触发任务的自动化工作台。用得越深越觉得与其每天手动去问它“今天有什么新东西”不如让它主动在固定时间把整理好的内容推给我。于是就有了这个项目每天上午十点半WorkBuddy 自动生成一份 AI 日报通过微信送到我手上。核心链路其实就三段——定时触发、内容生成、消息推送。听起来简单但每一段都有坑定时怎么设才不会被任务队列吞掉日报内容怎么保证每天不重样又不跑偏微信侧怎么接才不触发风控这些细节才是真正决定这套东西能不能长期跑下去的关键。这篇文章我会把整个搭建过程拆开讲包括 WorkBuddy 的规则配置思路、DeepSeek 接口的调用方式、微信推送的几种可行路径以及我踩过的那些坑。适合两类人看一是已经在用 WorkBuddy 但还没玩透自动化规则的人二是想给自己搭一套“信息主动上门”流水线的开发者。不需要你是自动化测试工程师只要会改配置文件、能看懂简单的接口调用就能照着复现。2. 整体方案设计与核心思路拆解2.1 为什么选“定时触发 AI 生成 微信推送”这条链路市面上做日报的方案大致三种第一种是纯 RSS 聚合把订阅源抓下来拼成一份摘要优点是快缺点是没脑子信息密度低第二种是人工整理质量高但不可持续第三种就是我现在用的——让 AI 做筛选和摘要人只看结果。WorkBuddy 在这条链路里扮演的是“调度中枢”的角色它负责在指定时间唤醒任务、调用技能、把结果送出去。选微信作为推送终点理由很实际我一天里打开频率最高的 App 就是微信日报送到这里阅读概率最高。而且微信的文件传输助手、订阅号、企业微信机器人这几条路都能走灵活度够。至于 AI 生成部分我用的是 DeepSeek 的接口原因后面细说主要是性价比和中文摘要质量在我实测的几个方案里比较均衡。提示整条链路的设计原则是“各环节解耦”。定时归定时生成归生成推送归推送任何一环出问题都不会把整个流程拖死排查起来也快。2.2 WorkBuddy 规则机制的关键理解WorkBuddy 的规则系统是这套方案的地基。它的逻辑是你定义一条规则规则里包含触发条件、执行动作、以及作用范围。触发条件可以是时间、事件或者手动执行动作就是调用某个技能或接口作用范围决定了这条规则对哪些任务生效。我见过不少人把规则写得很复杂一个规则里塞七八个动作结果一出错根本不知道是哪一步挂了。我的做法是拆成三条独立规则第一条负责“到点触发”第二条负责“生成日报内容”第三条负责“推送”。三条规则通过任务 ID 串联任何一条单独测试都能跑通。这样做的好处是如果某天日报没收到我可以先看触发规则有没有执行再看生成规则有没有产出最后看推送规则有没有报错定位时间从原来的半小时缩短到五分钟以内。2.3 为什么用 DeepSeek 而不是其他模型DeepSeek 在这个场景里的优势有三个。第一是中文摘要的语感比较自然不会出现那种“翻译腔”的机械感第二是接口调用成本可控日报这种每天一次、每次几千 token 的任务一个月下来费用很低第三是它对结构化输出的支持比较稳我要求它按“标题 三句话摘要 原文链接”的格式返回基本不会跑偏。当然也有需要注意的地方。DeepSeek 的接口在高峰期响应会慢一些所以我在规则里把超时设成了 60 秒并且加了一次重试。另外提示词里必须明确“如果某条内容无法确认来源直接丢弃”否则它偶尔会编造一些看起来很像真的但实际不存在的信息。这个坑我在早期测试时踩过日报里出现了一条根本不存在的“某大厂发布新框架”的消息差点闹笑话。3. 核心细节解析与实操要点3.1 定时触发的参数怎么设才靠谱定时触发看起来最简单其实最容易出问题。WorkBuddy 的定时规则里时间格式、时区、错过补偿这三个参数必须搞清楚。时间格式我用的 cron 表达式30 10 * * *对应每天上午十点半。时区一定要显式指定否则服务器如果跑在 UTC 环境下你设的十点半实际执行时间是下午六点半这个坑我第一天就踩了。错过补偿misfire policy是另一个关键。如果十点半那一刻 WorkBuddy 正好在重启或者任务队列拥堵这条触发是直接丢弃还是补执行我的设置是“补执行一次但延迟不超过 15 分钟”。超过 15 分钟就跳过因为再晚推来的日报意义就不大了。这个参数在规则的高级设置里默认是“丢弃”一定要手动改。注意定时规则建好之后不要只看它“已启用”就完事。我习惯在创建后的第二天手动检查一次执行日志确认触发时间、执行耗时、返回状态都正常再放心让它长期跑。3.2 日报内容的生成逻辑与提示词设计日报内容的质量八成取决于提示词。我前后改了七版提示词最终稳定下来的结构是这样的先给 DeepSeek 一个角色设定“你是一个技术资讯编辑”再给输入源我订阅的五个信息源抓取结果然后给输出格式要求最后加约束条件。约束条件里最重要的一条是“每条内容必须附带原文链接无法提供链接的内容不要出现在日报里”。输出格式我要求它返回 JSON字段包括title、summary、source_url、category。用 JSON 的好处是后续推送时可以直接解析不用再做字符串处理。实测下来DeepSeek 对 JSON 格式的遵循度很高偶尔会在 JSON 外面包一层说明文字所以我在解析前加了一步“提取第一个左花括号到最后一个右花括号之间的内容”这样就能兼容各种意外情况。另外日报的“去重”逻辑不能只靠 AI。我的做法是在 WorkBuddy 里维护一个已推送链接的列表每次生成前先过滤掉最近七天出现过的 URL再把剩下的喂给 DeepSeek。这样既减轻了模型负担也避免了连续几天推同一条内容。3.3 微信推送的三条可行路径对比微信推送这块我实测了三种方式各有适用场景。推送方式实现难度稳定性适合场景企业微信机器人低高个人使用消息推送到群或自己订阅号模板消息中中有开发能力想推给多个用户文件传输助手手动低低临时测试不适合长期我最终选的是企业微信机器人。原因很简单创建一个群拉一个机器人进去拿到 Webhook 地址WorkBuddy 里用 HTTP 请求技能往这个地址 POST 一条 Markdown 消息就行。整个过程不需要任何微信开发者资质也不涉及复杂的鉴权。消息格式用 Markdown标题加粗、链接可点阅读体验接近原生。提示企业微信机器人的 Webhook 地址里包含一个 key这个 key 不要直接写在规则里明文保存。我的做法是把它放在 WorkBuddy 的环境变量里规则里引用变量名这样即使规则配置被导出key 也不会泄露。4. 实操过程与核心环节实现4.1 环境准备与 WorkBuddy 基础配置开始之前你需要有一个能正常运行的 WorkBuddy 实例。我用的是本地部署版本跑在一台常开的迷你主机上。安装过程不复杂官方文档里有详细的步骤这里不展开。装好之后第一件事是确认技能市场里已经安装了“HTTP 请求”和“定时任务”这两个基础技能日报方案依赖它们。然后配置环境变量。我建了三个变量DEEPSEEK_API_KEY、WECHAT_WEBHOOK、NEWS_SOURCES。前两个分别是 DeepSeek 的接口密钥和企业微信机器人的 Webhook 地址第三个是我订阅的信息源列表用逗号分隔。环境变量配好之后在规则里用${变量名}的方式引用这样换密钥或者换信息源的时候不用改规则本身。4.2 第一条规则定时触发器的创建在 WorkBuddy 的规则管理页面新建规则名称写“日报-定时触发”。触发类型选“定时”cron 表达式填30 10 * * *时区选Asia/Shanghai。高级设置里错过补偿选“补执行”最大延迟填 15 分钟。执行动作先留空因为这条规则只负责触发具体动作由下一条规则承接。这里有个细节WorkBuddy 的规则之间可以通过“触发事件”来串联。我在第一条规则的执行动作里加了一个“发布事件”的动作事件名就叫daily_report_trigger。第二条规则监听这个事件一旦收到就执行生成逻辑。这样做的好处是如果以后我想改触发时间只需要改第一条规则后面的逻辑完全不用动。4.3 第二条规则调用 DeepSeek 生成日报这条规则是核心。触发条件选“监听事件”事件名填daily_report_trigger。执行动作分三步。第一步是“获取信息源内容”。我用的是 HTTP 请求技能对每个订阅源发 GET 请求把返回的 JSON 或 XML 存到一个临时变量里。这一步要注意设置合理的超时我设的是 10 秒超时的源直接跳过不阻塞整体流程。第二步是“调用 DeepSeek 接口”。请求地址是https://api.deepseek.com/v1/chat/completions方法 POSTHeaders 里带Authorization: Bearer ${DEEPSEEK_API_KEY}和Content-Type: application/json。Body 是一个 JSONmodel填deepseek-chatmessages里放系统提示词和用户输入temperature我设的是 0.3让输出稳定一些。max_tokens设 2000够一份日报用了。第三步是“解析并存储结果”。DeepSeek 返回的内容在choices[0].message.content里我用 WorkBuddy 的 JSON 解析技能把它提取出来存到一个叫report_content的变量里供下一条规则使用。注意DeepSeek 接口偶尔会返回 429请求过多或者 503服务暂时不可用。我在这一步加了重试逻辑最多重试两次每次间隔 5 秒。重试仍然失败的话规则会发一条告警消息到企业微信告诉我“今天日报生成失败”而不是静默跳过。4.4 第三条规则推送到微信这条规则监听report_content变量更新事件。执行动作是发一个 HTTP POST 请求到企业微信机器人的 Webhook 地址。Body 格式如下{ msgtype: markdown, markdown: { content: ## AI 日报\n\n${report_content}\n\n 由 WorkBuddy 自动生成 } }这里有个小技巧企业微信机器人的 Markdown 对换行比较敏感\n要写成\n的转义形式否则消息会挤成一行。我一开始没注意推过来的日报所有内容连在一起完全没法看。后来在生成report_content的时候就把换行符处理好推送时直接拼接问题就解决了。推送成功后规则会把这次推送的链接列表追加到“已推送记录”里供下次去重使用。整个流程从十点半触发到微信收到消息实测平均耗时 12 秒左右最长的一次因为某个信息源响应慢用了 28 秒但仍在可接受范围内。5. 常见问题与排查技巧实录5.1 日报没收到怎么快速定位这是最常见的问题。我的排查顺序是先看 WorkBuddy 的规则执行日志确认第一条触发规则有没有在十点半执行。如果没有检查 cron 表达式和时区如果有看第二条规则的执行记录确认 DeepSeek 接口有没有返回正常。如果接口报错看错误码是 401密钥问题还是 429限流。如果第二条正常看第三条推送规则的返回状态企业微信机器人返回errcode: 0才算成功。我把这个排查流程做成了一张速查表贴在工位上现象可能原因处理方式完全没触发cron 写错或时区不对检查表达式确认时区为 Asia/Shanghai触发了但没内容DeepSeek 接口报错查看错误码检查密钥和余额有内容但没推送Webhook 地址失效重新生成机器人 Webhook更新环境变量推送了但内容为空JSON 解析失败检查 DeepSeek 返回格式调整解析逻辑连续几天内容重复去重列表未生效检查已推送记录的存储路径和读写权限5.2 DeepSeek 接口调用的三个坑第一个坑是提示词过长导致截断。我一开始把五个信息源的全部内容都塞进提示词结果超过了模型的上下文限制返回的内容被截断。后来改成每个源只取前 500 字总长度控制在 3000 字以内问题解决。第二个坑是模型偶尔不按 JSON 格式返回。虽然概率不高但一旦发生后续解析就会失败。我的应对方式是在提示词里加一句“只返回 JSON不要有任何其他文字”同时在解析前做一次“提取花括号”的预处理。第三个坑是接口响应时间波动大。晚上高峰期调用可能要 20 秒以上所以超时时间不能设太短。我设的是 60 秒并且把这条规则的执行优先级调低避免它阻塞其他任务。5.3 微信推送的风控边界企业微信机器人虽然好用但也有频率限制。单个机器人每分钟最多发 20 条消息每天最多发 200 条。对于一天一条的日报来说完全够用但如果你同时跑多个自动化任务就要注意别超限。我的做法是把所有推送任务分散到不同的机器人每个机器人负责一类消息这样即使某一类消息量突增也不会影响日报的推送。另外消息内容里不要包含短链接或者可疑的跳转地址否则可能被拦截。我推的日报里所有链接都是原文的完整 URL没有做短链处理至今没有出现过被拦截的情况。6. 几个让这套方案更耐用的经验补充6.1 日报模板的迭代节奏不要指望第一版提示词就能产出完美的日报。我的做法是每周回顾一次过去七天的日报看看哪些内容我实际点开了、哪些直接划过去了。然后根据这个反馈调整提示词里的筛选标准。比如我发现自己对“框架更新”类的新闻兴趣不大就在提示词里加了一句“优先选择工具类和实战经验类内容框架版本更新类内容最多保留一条”。这样迭代了三四轮之后日报的打开率明显提升。6.2 异常情况的兜底设计再稳定的系统也会有出问题的时候。我在 WorkBuddy 里加了一条“心跳规则”每天中午十二点检查一次当天有没有成功推送日报如果没有就发一条提醒到微信告诉我“今天日报未推送请检查”。这条规则本身很简单但能避免“日报没来我却不知道”的情况。另外DeepSeek 的密钥我设置了余额提醒低于 10 元就发邮件防止因为欠费导致日报断更。6.3 后续可以扩展的方向这套框架跑通之后扩展空间其实很大。比如把日报拆成“技术版”和“行业版”分别推给不同的群或者在日报里加一个“今日待办”区块从我的任务管理工具里拉取当天到期的事项。我最近在试的一个方向是让 DeepSeek 对每条内容做一个“重要性评分”只推送评分高于阈值的内容进一步降低信息噪音。等跑稳了再单独写一篇分享。最后分享一个我在配置过程中养成的习惯每改一次规则先手动触发一次看结果确认没问题再恢复定时。直接等第二天十点半看结果万一出错就浪费一整天。手动触发在 WorkBuddy 的规则详情页有个“立即执行”按钮点一下就行几秒钟的事但能省掉很多不必要的等待。
WorkBuddy+DeepSeek+微信：搭建每日AI日报自动化推送流水线
1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是泡茶而是打开各种信息源行业群、订阅号、技术社区、项目看板一圈刷下来半小时就没了真正有价值的内容可能就三五条。这种“人肉信息筛选”的活儿干久了谁都烦。我大概在三个月前开始用 WorkBuddy 做日常任务托管它本质上是一个可以挂载多种技能、按规则触发任务的自动化工作台。用得越深越觉得与其每天手动去问它“今天有什么新东西”不如让它主动在固定时间把整理好的内容推给我。于是就有了这个项目每天上午十点半WorkBuddy 自动生成一份 AI 日报通过微信送到我手上。核心链路其实就三段——定时触发、内容生成、消息推送。听起来简单但每一段都有坑定时怎么设才不会被任务队列吞掉日报内容怎么保证每天不重样又不跑偏微信侧怎么接才不触发风控这些细节才是真正决定这套东西能不能长期跑下去的关键。这篇文章我会把整个搭建过程拆开讲包括 WorkBuddy 的规则配置思路、DeepSeek 接口的调用方式、微信推送的几种可行路径以及我踩过的那些坑。适合两类人看一是已经在用 WorkBuddy 但还没玩透自动化规则的人二是想给自己搭一套“信息主动上门”流水线的开发者。不需要你是自动化测试工程师只要会改配置文件、能看懂简单的接口调用就能照着复现。2. 整体方案设计与核心思路拆解2.1 为什么选“定时触发 AI 生成 微信推送”这条链路市面上做日报的方案大致三种第一种是纯 RSS 聚合把订阅源抓下来拼成一份摘要优点是快缺点是没脑子信息密度低第二种是人工整理质量高但不可持续第三种就是我现在用的——让 AI 做筛选和摘要人只看结果。WorkBuddy 在这条链路里扮演的是“调度中枢”的角色它负责在指定时间唤醒任务、调用技能、把结果送出去。选微信作为推送终点理由很实际我一天里打开频率最高的 App 就是微信日报送到这里阅读概率最高。而且微信的文件传输助手、订阅号、企业微信机器人这几条路都能走灵活度够。至于 AI 生成部分我用的是 DeepSeek 的接口原因后面细说主要是性价比和中文摘要质量在我实测的几个方案里比较均衡。提示整条链路的设计原则是“各环节解耦”。定时归定时生成归生成推送归推送任何一环出问题都不会把整个流程拖死排查起来也快。2.2 WorkBuddy 规则机制的关键理解WorkBuddy 的规则系统是这套方案的地基。它的逻辑是你定义一条规则规则里包含触发条件、执行动作、以及作用范围。触发条件可以是时间、事件或者手动执行动作就是调用某个技能或接口作用范围决定了这条规则对哪些任务生效。我见过不少人把规则写得很复杂一个规则里塞七八个动作结果一出错根本不知道是哪一步挂了。我的做法是拆成三条独立规则第一条负责“到点触发”第二条负责“生成日报内容”第三条负责“推送”。三条规则通过任务 ID 串联任何一条单独测试都能跑通。这样做的好处是如果某天日报没收到我可以先看触发规则有没有执行再看生成规则有没有产出最后看推送规则有没有报错定位时间从原来的半小时缩短到五分钟以内。2.3 为什么用 DeepSeek 而不是其他模型DeepSeek 在这个场景里的优势有三个。第一是中文摘要的语感比较自然不会出现那种“翻译腔”的机械感第二是接口调用成本可控日报这种每天一次、每次几千 token 的任务一个月下来费用很低第三是它对结构化输出的支持比较稳我要求它按“标题 三句话摘要 原文链接”的格式返回基本不会跑偏。当然也有需要注意的地方。DeepSeek 的接口在高峰期响应会慢一些所以我在规则里把超时设成了 60 秒并且加了一次重试。另外提示词里必须明确“如果某条内容无法确认来源直接丢弃”否则它偶尔会编造一些看起来很像真的但实际不存在的信息。这个坑我在早期测试时踩过日报里出现了一条根本不存在的“某大厂发布新框架”的消息差点闹笑话。3. 核心细节解析与实操要点3.1 定时触发的参数怎么设才靠谱定时触发看起来最简单其实最容易出问题。WorkBuddy 的定时规则里时间格式、时区、错过补偿这三个参数必须搞清楚。时间格式我用的 cron 表达式30 10 * * *对应每天上午十点半。时区一定要显式指定否则服务器如果跑在 UTC 环境下你设的十点半实际执行时间是下午六点半这个坑我第一天就踩了。错过补偿misfire policy是另一个关键。如果十点半那一刻 WorkBuddy 正好在重启或者任务队列拥堵这条触发是直接丢弃还是补执行我的设置是“补执行一次但延迟不超过 15 分钟”。超过 15 分钟就跳过因为再晚推来的日报意义就不大了。这个参数在规则的高级设置里默认是“丢弃”一定要手动改。注意定时规则建好之后不要只看它“已启用”就完事。我习惯在创建后的第二天手动检查一次执行日志确认触发时间、执行耗时、返回状态都正常再放心让它长期跑。3.2 日报内容的生成逻辑与提示词设计日报内容的质量八成取决于提示词。我前后改了七版提示词最终稳定下来的结构是这样的先给 DeepSeek 一个角色设定“你是一个技术资讯编辑”再给输入源我订阅的五个信息源抓取结果然后给输出格式要求最后加约束条件。约束条件里最重要的一条是“每条内容必须附带原文链接无法提供链接的内容不要出现在日报里”。输出格式我要求它返回 JSON字段包括title、summary、source_url、category。用 JSON 的好处是后续推送时可以直接解析不用再做字符串处理。实测下来DeepSeek 对 JSON 格式的遵循度很高偶尔会在 JSON 外面包一层说明文字所以我在解析前加了一步“提取第一个左花括号到最后一个右花括号之间的内容”这样就能兼容各种意外情况。另外日报的“去重”逻辑不能只靠 AI。我的做法是在 WorkBuddy 里维护一个已推送链接的列表每次生成前先过滤掉最近七天出现过的 URL再把剩下的喂给 DeepSeek。这样既减轻了模型负担也避免了连续几天推同一条内容。3.3 微信推送的三条可行路径对比微信推送这块我实测了三种方式各有适用场景。推送方式实现难度稳定性适合场景企业微信机器人低高个人使用消息推送到群或自己订阅号模板消息中中有开发能力想推给多个用户文件传输助手手动低低临时测试不适合长期我最终选的是企业微信机器人。原因很简单创建一个群拉一个机器人进去拿到 Webhook 地址WorkBuddy 里用 HTTP 请求技能往这个地址 POST 一条 Markdown 消息就行。整个过程不需要任何微信开发者资质也不涉及复杂的鉴权。消息格式用 Markdown标题加粗、链接可点阅读体验接近原生。提示企业微信机器人的 Webhook 地址里包含一个 key这个 key 不要直接写在规则里明文保存。我的做法是把它放在 WorkBuddy 的环境变量里规则里引用变量名这样即使规则配置被导出key 也不会泄露。4. 实操过程与核心环节实现4.1 环境准备与 WorkBuddy 基础配置开始之前你需要有一个能正常运行的 WorkBuddy 实例。我用的是本地部署版本跑在一台常开的迷你主机上。安装过程不复杂官方文档里有详细的步骤这里不展开。装好之后第一件事是确认技能市场里已经安装了“HTTP 请求”和“定时任务”这两个基础技能日报方案依赖它们。然后配置环境变量。我建了三个变量DEEPSEEK_API_KEY、WECHAT_WEBHOOK、NEWS_SOURCES。前两个分别是 DeepSeek 的接口密钥和企业微信机器人的 Webhook 地址第三个是我订阅的信息源列表用逗号分隔。环境变量配好之后在规则里用${变量名}的方式引用这样换密钥或者换信息源的时候不用改规则本身。4.2 第一条规则定时触发器的创建在 WorkBuddy 的规则管理页面新建规则名称写“日报-定时触发”。触发类型选“定时”cron 表达式填30 10 * * *时区选Asia/Shanghai。高级设置里错过补偿选“补执行”最大延迟填 15 分钟。执行动作先留空因为这条规则只负责触发具体动作由下一条规则承接。这里有个细节WorkBuddy 的规则之间可以通过“触发事件”来串联。我在第一条规则的执行动作里加了一个“发布事件”的动作事件名就叫daily_report_trigger。第二条规则监听这个事件一旦收到就执行生成逻辑。这样做的好处是如果以后我想改触发时间只需要改第一条规则后面的逻辑完全不用动。4.3 第二条规则调用 DeepSeek 生成日报这条规则是核心。触发条件选“监听事件”事件名填daily_report_trigger。执行动作分三步。第一步是“获取信息源内容”。我用的是 HTTP 请求技能对每个订阅源发 GET 请求把返回的 JSON 或 XML 存到一个临时变量里。这一步要注意设置合理的超时我设的是 10 秒超时的源直接跳过不阻塞整体流程。第二步是“调用 DeepSeek 接口”。请求地址是https://api.deepseek.com/v1/chat/completions方法 POSTHeaders 里带Authorization: Bearer ${DEEPSEEK_API_KEY}和Content-Type: application/json。Body 是一个 JSONmodel填deepseek-chatmessages里放系统提示词和用户输入temperature我设的是 0.3让输出稳定一些。max_tokens设 2000够一份日报用了。第三步是“解析并存储结果”。DeepSeek 返回的内容在choices[0].message.content里我用 WorkBuddy 的 JSON 解析技能把它提取出来存到一个叫report_content的变量里供下一条规则使用。注意DeepSeek 接口偶尔会返回 429请求过多或者 503服务暂时不可用。我在这一步加了重试逻辑最多重试两次每次间隔 5 秒。重试仍然失败的话规则会发一条告警消息到企业微信告诉我“今天日报生成失败”而不是静默跳过。4.4 第三条规则推送到微信这条规则监听report_content变量更新事件。执行动作是发一个 HTTP POST 请求到企业微信机器人的 Webhook 地址。Body 格式如下{ msgtype: markdown, markdown: { content: ## AI 日报\n\n${report_content}\n\n 由 WorkBuddy 自动生成 } }这里有个小技巧企业微信机器人的 Markdown 对换行比较敏感\n要写成\n的转义形式否则消息会挤成一行。我一开始没注意推过来的日报所有内容连在一起完全没法看。后来在生成report_content的时候就把换行符处理好推送时直接拼接问题就解决了。推送成功后规则会把这次推送的链接列表追加到“已推送记录”里供下次去重使用。整个流程从十点半触发到微信收到消息实测平均耗时 12 秒左右最长的一次因为某个信息源响应慢用了 28 秒但仍在可接受范围内。5. 常见问题与排查技巧实录5.1 日报没收到怎么快速定位这是最常见的问题。我的排查顺序是先看 WorkBuddy 的规则执行日志确认第一条触发规则有没有在十点半执行。如果没有检查 cron 表达式和时区如果有看第二条规则的执行记录确认 DeepSeek 接口有没有返回正常。如果接口报错看错误码是 401密钥问题还是 429限流。如果第二条正常看第三条推送规则的返回状态企业微信机器人返回errcode: 0才算成功。我把这个排查流程做成了一张速查表贴在工位上现象可能原因处理方式完全没触发cron 写错或时区不对检查表达式确认时区为 Asia/Shanghai触发了但没内容DeepSeek 接口报错查看错误码检查密钥和余额有内容但没推送Webhook 地址失效重新生成机器人 Webhook更新环境变量推送了但内容为空JSON 解析失败检查 DeepSeek 返回格式调整解析逻辑连续几天内容重复去重列表未生效检查已推送记录的存储路径和读写权限5.2 DeepSeek 接口调用的三个坑第一个坑是提示词过长导致截断。我一开始把五个信息源的全部内容都塞进提示词结果超过了模型的上下文限制返回的内容被截断。后来改成每个源只取前 500 字总长度控制在 3000 字以内问题解决。第二个坑是模型偶尔不按 JSON 格式返回。虽然概率不高但一旦发生后续解析就会失败。我的应对方式是在提示词里加一句“只返回 JSON不要有任何其他文字”同时在解析前做一次“提取花括号”的预处理。第三个坑是接口响应时间波动大。晚上高峰期调用可能要 20 秒以上所以超时时间不能设太短。我设的是 60 秒并且把这条规则的执行优先级调低避免它阻塞其他任务。5.3 微信推送的风控边界企业微信机器人虽然好用但也有频率限制。单个机器人每分钟最多发 20 条消息每天最多发 200 条。对于一天一条的日报来说完全够用但如果你同时跑多个自动化任务就要注意别超限。我的做法是把所有推送任务分散到不同的机器人每个机器人负责一类消息这样即使某一类消息量突增也不会影响日报的推送。另外消息内容里不要包含短链接或者可疑的跳转地址否则可能被拦截。我推的日报里所有链接都是原文的完整 URL没有做短链处理至今没有出现过被拦截的情况。6. 几个让这套方案更耐用的经验补充6.1 日报模板的迭代节奏不要指望第一版提示词就能产出完美的日报。我的做法是每周回顾一次过去七天的日报看看哪些内容我实际点开了、哪些直接划过去了。然后根据这个反馈调整提示词里的筛选标准。比如我发现自己对“框架更新”类的新闻兴趣不大就在提示词里加了一句“优先选择工具类和实战经验类内容框架版本更新类内容最多保留一条”。这样迭代了三四轮之后日报的打开率明显提升。6.2 异常情况的兜底设计再稳定的系统也会有出问题的时候。我在 WorkBuddy 里加了一条“心跳规则”每天中午十二点检查一次当天有没有成功推送日报如果没有就发一条提醒到微信告诉我“今天日报未推送请检查”。这条规则本身很简单但能避免“日报没来我却不知道”的情况。另外DeepSeek 的密钥我设置了余额提醒低于 10 元就发邮件防止因为欠费导致日报断更。6.3 后续可以扩展的方向这套框架跑通之后扩展空间其实很大。比如把日报拆成“技术版”和“行业版”分别推给不同的群或者在日报里加一个“今日待办”区块从我的任务管理工具里拉取当天到期的事项。我最近在试的一个方向是让 DeepSeek 对每条内容做一个“重要性评分”只推送评分高于阈值的内容进一步降低信息噪音。等跑稳了再单独写一篇分享。最后分享一个我在配置过程中养成的习惯每改一次规则先手动触发一次看结果确认没问题再恢复定时。直接等第二天十点半看结果万一出错就浪费一整天。手动触发在 WorkBuddy 的规则详情页有个“立即执行”按钮点一下就行几秒钟的事但能省掉很多不必要的等待。
)
