WorkBuddy+DeepSeek+微信：搭建十点半自动AI日报

1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”

每天早上到工位，第一件事不是泡茶，而是打开几个信息源，把昨天夜里到今早的行业动态、项目进展、待办提醒翻一遍。这件事本身不复杂，但极其消耗注意力——你刚坐下，脑子还没热起来，就被一堆碎片信息冲得七零八落。我试过用手机日历提醒、用待办清单、用各种聚合工具，最后发现真正的问题不在于“有没有提醒”，而在于“提醒的内容是不是已经整理好的”。

WorkBuddy 这类 AI 助手工具的出现，让我看到了另一种可能：它不只是被动等你提问，而是可以主动把信息加工好，在固定时间推给你。于是我就想，能不能给它设一个“闹钟”——每天上午十点半，自动生成一份 AI 日报，然后送进微信。这样我打开微信就能看到，不需要额外装 App，也不需要手动触发。

这个想法的核心关键词是WorkBuddy、AI、微信、自动化、deepseek。拆开来看，WorkBuddy 是执行主体，AI 是加工能力，微信是投递渠道，自动化是手段，deepseek 则是背后可能调用的模型能力之一。整件事的目标很明确：把“人找信息”变成“信息找人”，而且找得足够准、足够轻。

适合谁来参考这篇内容？如果你每天需要处理大量信息、又不想被信息淹没，或者你正在用 WorkBuddy 做个人效率工具，再或者你对“AI Agent 定时任务”这个方向感兴趣，那这篇实操记录应该能给你一些可直接复用的思路。我踩过的坑、试过的方案、最后跑通的链路，都会尽量写清楚。

提示：本文提到的所有工具和平台，均以合规使用为前提。自动化操作应遵守各平台的服务条款，仅用于个人效率提升场景。

2. 拆解“十点半自动日报”这条链路到底需要什么

2.1 从触发到投递的四个关键环节

一条完整的自动化日报链路，拆开来看其实只有四段：触发、采集、加工、投递。触发就是“十点半”这个时间点怎么被感知；采集是日报的原始素材从哪里来；加工是 AI 怎么把素材变成可读的日报；投递是怎么把结果送进微信。

很多人一上来就想着“我要接哪个模型”，但其实最容易出问题的是触发和投递这两头。触发不稳，日报可能晚点或者重复；投递不稳，内容生成得再好也送不到你眼前。加工环节反而是现在最成熟的，deepseek 这类模型的能力已经足够把一堆碎片信息整理成结构清晰的摘要。

我最初的想法很简单：WorkBuddy 里不是有定时任务或者工作流吗？直接设一个每天十点半执行的任务，任务里调用 AI 生成内容，然后通过微信的某种方式发给自己。但实际动手才发现，WorkBuddy 的定时能力、微信的接收方式、以及两者之间的衔接，都需要做一些取舍。

2.2 WorkBuddy 在这个场景里扮演什么角色

WorkBuddy 本质上是一个 AI 工作助手，它可以理解指令、调用工具、执行多步任务。在这个场景里，它承担的是“调度中心”的角色：到点了，它负责启动流程；流程中，它负责调用模型生成日报；生成后，它负责把结果交给投递模块。

这里有一个关键认知：WorkBuddy 不是单纯的聊天窗口，而是一个可以编排任务的 Agent。如果你只把它当聊天工具用，那就只能手动问一句答一句。但如果你把它当成一个可以设定触发条件、可以串联多个步骤的执行器，它的价值就完全不一样了。

我试过两种思路。第一种是让 WorkBuddy 完全自己搞定，包括定时和发送；第二种是 WorkBuddy 只负责生成内容，定时和发送交给外部工具。实测下来，第二种更稳，因为 WorkBuddy 的强项在内容加工，而定时触发和消息投递有更成熟的专用方案。

2.3 微信作为投递终端的利与弊

微信作为投递终端，最大的好处是触达率高。你本来就会频繁打开微信，日报送到这里，不需要额外养成一个新习惯。而且微信支持文件传输助手、群机器人、服务号模板消息等多种接收方式，选择空间比较大。

但微信也有它的限制。个人微信的自动化操作需要格外小心，不能违反平台规则。比较稳妥的做法是使用微信提供的官方能力，比如企业微信的群机器人、或者微信服务号的模板消息。如果你只是发给自己看，文件传输助手配合一些合规的同步工具也能实现，但要注意不要高频、不要群发、不要涉及营销内容。

我最终选择的方案是：WorkBuddy 生成日报后，通过一个轻量的中转服务，把内容推送到微信的接收端。这个中转服务可以是一个简单的 Webhook，也可以是一个定时轮询的脚本。关键是它要足够轻，不要引入太多依赖。

2.4 deepseek 在日报生成中的实际作用

deepseek 在这个链路里负责的是“加工”环节。原始素材可能是一堆链接、几段笔记、或者几个数据源的更新，deepseek 要把它们读一遍，然后输出一份结构化的日报：今天有哪些重点、哪些需要跟进、哪些可以忽略。

我对比过几种用法。直接让模型总结，容易漏掉关键信息；给模型一个固定的模板，让它按模板填充，效果会好很多。比如我会告诉它：“请按‘今日重点’‘待办提醒’‘行业动态’三个板块输出，每个板块不超过三条，每条一句话概括。”这样生成的日报既简洁又不会跑偏。

deepseek 的 API 调用成本相对可控，对于每天一次、每次几千 token 的日报生成来说，完全在可接受范围内。如果你用量更大，可以考虑本地部署或者选择更轻量的模型，但对于个人日报这个场景，API 方式最省心。

3. 动手搭建：从零跑通一条可用的自动化链路

3.1 环境准备与前置条件确认

在开始之前，你需要确认几件事。第一，WorkBuddy 账号可用，并且你了解它的基本操作，比如怎么创建任务、怎么调用外部接口。第二，你有一个可以接收微信消息的通道，比如企业微信机器人或者一个自建的服务号。第三，你有一个 deepseek 的 API Key，或者 WorkBuddy 内置了可用的模型能力。

我建议先在本地把链路跑通，再考虑部署到服务器。本地跑通的好处是调试方便，出错了能立刻看到日志。等你确认每个环节都稳定了，再迁移到云函数或者一台常开的机器上。

环境清单大致如下：

3.2 在 WorkBuddy 里定义一个“日报生成”任务

打开 WorkBuddy，新建一个任务。任务的目标描述可以这样写：“每天上午十点半，收集指定信息源的最新内容，调用模型生成一份结构化日报，输出为 Markdown 格式。”然后在任务步骤里，把采集、加工、输出拆成三个子步骤。

采集部分，你可以让 WorkBuddy 读取你指定的几个信息源。如果 WorkBuddy 支持读取 RSS 或者网页内容，直接配置即可；如果不支持，可以先用一个外部脚本把素材抓下来，存到一个固定位置，再让 WorkBuddy 去读。

加工部分，给模型一个明确的提示词。我用的提示词大致是这样的：

你是一个日报助手。请根据以下素材，生成一份简洁的日报。 要求： 1. 分为“今日重点”“待办提醒”“行业动态”三个板块。 2. 每个板块最多三条，每条不超过 50 字。 3. 如果某个板块没有内容，写“暂无”。 4. 输出格式为 Markdown。 素材如下： {{素材内容}}

输出部分，让 WorkBuddy 把生成的 Markdown 保存到一个变量或者直接发送到指定的 Webhook 地址。这一步是整个链路的关键衔接点，一定要确认 WorkBuddy 支持“输出到外部地址”这个动作。

3.3 用中转服务把结果送进微信

WorkBuddy 生成日报后，需要一个中转服务把内容推送到微信。我用的方案是一个简单的 Python 脚本，监听一个 HTTP 端口，收到 WorkBuddy 的 POST 请求后，再把内容转发到企业微信机器人的 Webhook。

代码不复杂，核心逻辑就几行：

from flask import Flask, request import requests app = Flask(__name__) WECHAT_WEBHOOK = "你的企业微信机器人 Webhook 地址" @app.route("/daily-report", methods=["POST"]) def forward(): content = request.json.get("content", "") requests.post(WECHAT_WEBHOOK, json={ "msgtype": "markdown", "markdown": {"content": content} }) return {"status": "ok"} if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)

这个脚本跑起来后，WorkBuddy 只需要把日报内容 POST 到http://你的地址:5000/daily-report，微信那边就能收到。企业微信机器人的好处是稳定、合规、支持 Markdown 格式，展示效果也还不错。

注意：如果你用的是个人微信而不是企业微信，请务必确认你的使用方式符合平台规则。不要使用任何非官方的自动化手段操作个人微信账号。

3.4 定时触发：十点半这个时间点怎么保证

定时触发有两种做法。一种是依赖 WorkBuddy 自身的定时任务功能，在任务设置里指定每天十点半执行。另一种是在中转服务里加一个定时器，到点主动去拉取 WorkBuddy 的生成结果。

我两种都试过。WorkBuddy 自带定时任务最省事，但前提是它的定时功能足够可靠。如果你发现它偶尔会延迟或者漏执行，那就用第二种方案：用一个 cron 任务或者云函数的定时触发器，每天十点半调用一次 WorkBuddy 的任务执行接口，然后再把结果转发到微信。

Linux 下的 cron 配置示例：

30 10 * * * curl -X POST http://workbuddy-api/run-task -d '{"task_id": "daily-report"}' && sleep 30 && curl http://localhost:5000/fetch-and-forward

这个方案的好处是触发逻辑掌握在自己手里，不依赖 WorkBuddy 的定时精度。缺点是多了几个环节，需要确保每个环节都能正常响应。

4. 实测中遇到的坑与对应解法

4.1 日报内容重复或遗漏的排查过程

跑通第一天，我发现日报里出现了前一天的内容。排查后发现，是采集环节没有做时间过滤，把历史素材也一起抓进来了。解法很简单：在采集时加上时间范围限制，只取最近 24 小时的内容。

另一个问题是遗漏。有些信息源更新频率低，24 小时内可能没有新内容，但模型会强行编造一些“动态”。我在提示词里加了一句：“如果素材中没有新内容，请如实说明，不要编造。”这样日报的可信度就上来了。

还有一个隐蔽的坑：如果素材里包含大量无关内容，模型会被带偏。我的做法是在采集阶段就做一次粗筛，只保留标题或摘要里包含关键词的条目，再把筛选后的素材交给模型。

4.2 微信接收端的稳定性问题

企业微信机器人偶尔会出现消息发送失败的情况，尤其是在网络波动的时候。我的处理方式是加一个重试机制：如果第一次发送失败，等 5 秒再试一次，最多重试三次。如果三次都失败，就把内容写到一个本地文件里，第二天手动补看。

另外，企业微信机器人对消息长度有限制，如果日报太长会被截断。我的日报控制在 500 字以内，一般不会触发限制。如果你需要更长的日报，可以考虑分段发送，或者把完整版存成文件，微信里只发摘要和文件链接。

4.3 模型输出格式不稳定的处理技巧

即使提示词写得很清楚，模型偶尔还是会输出不符合格式的内容。比如该用 Markdown 的时候用了纯文本，该分三个板块的时候只分了两个。我的经验是：不要指望一次提示就能完美，要在输出后加一层校验。

校验逻辑可以很简单：检查输出里是否包含“今日重点”“待办提醒”“行业动态”这三个关键词，如果没有，就重新调用一次模型。重试两次之后如果还是不行，就接受当前结果，但记录日志，方便后续优化提示词。

还有一个技巧是给模型一个示例输出。在提示词里加一段“参考格式如下”，然后附上一个标准日报的样例。实测下来，加了示例之后，格式稳定性明显提升。

4.4 成本与频率的平衡

每天一次日报，每次调用模型消耗的 token 量并不大。但如果你的素材很多，或者你一天要生成多次，成本就会上升。我的建议是：先跑一周，看看实际消耗，再决定要不要优化。

优化方向有几个：一是压缩素材，只保留最关键的信息；二是换用更轻量的模型做初筛，再用大模型做精加工；三是把日报频率从每天一次改成工作日每天一次，周末不生成。这些调整都能有效控制成本。

5. 让日报真正有用的几个进阶思路

5.1 把“待办提醒”做成可勾选的清单

最初的日报只是纯文本，看完就过去了。后来我想，能不能让待办事项变成可勾选的清单？这样我可以在微信里直接标记完成，第二天日报就不会再重复提醒。

实现方式是在生成日报时，让模型把待办事项单独输出为一个列表，然后在中转服务里把它转换成企业微信支持的交互格式。企业微信机器人目前对交互组件的支持有限，但你可以把待办事项做成一个带编号的列表，手动回复编号来标记完成。虽然不够优雅，但比纯文本前进了一步。

5.2 根据反馈动态调整日报内容

日报跑了一段时间后，我发现有些板块我从来不看，有些板块却总是觉得信息不够。于是我在中转服务里加了一个简单的反馈机制：每天日报发出后，附带一句“回复‘调整’可以修改日报板块”。当我回复“调整”时，服务会记录我的偏好，下次生成时自动调整板块权重。

这个机制不需要太复杂，甚至可以用一个配置文件来管理。关键是让日报有“可进化”的能力，而不是一成不变。

5.3 多源信息的融合与去重

如果你的信息源比较多，去重就是一个必须解决的问题。同一条新闻可能出现在三个不同的源里，如果不去重，日报里就会出现三条重复内容。我的做法是在采集阶段就用标题做一次相似度比对，相似度超过阈值的只保留一条。

去重之后，还可以做一层融合：把不同源对同一事件的描述合并成一条更完整的摘要。这一步可以交给模型来做，但要在提示词里明确要求“合并重复内容，保留最完整的信息”。

5.4 把日报沉淀为可检索的知识库

日报每天生成，日积月累就是一笔不小的知识资产。我现在的做法是每天把日报存成一个 Markdown 文件，按日期命名，放在一个固定目录里。时间长了，这个目录就变成了一个可检索的个人知识库。

更进一步，你可以用 WorkBuddy 或者别的工具对这个目录做索引，支持关键词搜索。这样当你需要回顾某个话题时，不需要翻聊天记录，直接搜日报库就行。这个习惯我坚持了几个月，效果非常好，强烈推荐你试试。

6. 关于这套方案的一些个人体会

这套“十点半自动日报”的方案，我从起意到跑通大概花了一个周末的时间。中间踩的坑不算少，但整体来说，难度并不高，关键在于把每个环节拆清楚，然后逐个验证。

我最大的体会是：自动化工具的价值不在于“炫技”，而在于“省心”。如果一套自动化流程需要你天天盯着它有没有出错，那它反而增加了负担。所以我在设计时尽量做减法，能简化的环节就简化，能加校验的地方就加校验，确保它跑起来之后我基本不用管。

另一个体会是，微信作为投递终端确实方便，但也要注意边界。企业微信机器人是目前最稳妥的选择，个人微信的自动化操作风险较高，不建议尝试。如果你只是自己看，文件传输助手配合手动同步也能用，但那就失去自动化的意义了。

最后分享一个小技巧：日报的提示词不要一次写死，留一个“可调整”的入口。比如把板块名称、每条字数限制、输出格式这些参数放在一个配置文件里，想改的时候改配置就行，不用动代码。这个习惯让我在后续调整日报风格时省了很多事。

这套方案目前已经稳定运行了一段时间，每天早上十点半，微信里准时出现一份整理好的日报。我打开看一眼，该跟进的跟进，该忽略的忽略，整个过程不到两分钟。相比之前手动翻信息源，效率提升非常明显。如果你也在用 WorkBuddy，不妨试试给它设一个这样的“闹钟”。