1. 从一条定时消息说起：这个项目到底在解决什么问题

每天早上到工位，第一件事是打开各种信息源，刷一遍行业动态、看看昨天夜里有没有什么新工具发布、有没有值得关注的模型更新。这件事听起来不费劲，但真正做过的人都知道，它是个隐形的注意力黑洞——你本来只想扫五分钟，结果半小时过去了，正事还没开始干。更麻烦的是，信息源太散：有的在公众号，有的在技术社区，有的在群聊里，有的干脆藏在某个更新日志的角落。你不可能每天手动把这些东西全捞一遍。

我给自己定的方案很直接：让一个自动化流程在每天上午十点半，把过去24小时里我关心的AI领域动态整理成一份日报，直接推送到微信里。这样我打开微信就能看到，不需要额外装App，不需要记着去某个网站看，也不需要自己动手整理。整个链路的核心角色是WorkBuddy——一个可以承载定时任务、调用模型能力、执行自动化流程的工作台。配合deepseek-v4-flash这类响应快、成本低的模型做内容摘要和结构化处理，最终通过微信小程序或者微信消息通道把日报送达到我手上。

这个项目适合什么人参考？三类人最有用。第一类是每天需要跟踪特定领域信息但不想被信息流绑架的从业者，比如产品经理、技术负责人、投资分析岗。第二类是对自动化流程感兴趣、想拿一个完整案例练手的开发者，这个项目涉及定时调度、API调用、消息推送、内容处理，是一个麻雀虽小五脏俱全的自动化样本。第三类是用 WorkBuddy 但还没想清楚拿它做什么的人，这个日报场景可以直接抄作业，改一改信息源和推送时间就能变成自己的版本。

需要提前说明的是，下面讲到的具体配置参数、调度表达式、消息通道选择，有一部分是基于我实际跑通的方案，有一部分是基于同类自动化项目的常见实践做的合理推演。我会在涉及推演的地方明确标注，避免你照着做的时候踩坑。

2. 整体方案设计与关键选型考量

2.1 为什么是“定时+摘要+推送”这三段式结构

这个项目的本质是一条信息加工流水线，拆开来看只有三个环节：采集、加工、送达。采集负责把散落的信息源聚拢，加工负责把原始内容压缩成可读的日报，送达负责把成品放到你每天一定会看的地方。三段式结构的好处是每一段都可以独立替换——今天用A信息源，明天想加B信息源，不影响加工和送达；今天推微信，明天想推邮件，也不影响前面两段。

很多人做自动化日报容易犯一个错误：把采集和加工揉在一起，边抓边总结。这样做的问题是，一旦某个信息源抓取失败，整个流程就断了，而且你很难判断到底是网络问题还是模型问题。分段之后，每一段的输入输出都是明确的，排查起来快得多。

2.2 WorkBuddy 在这个链路里扮演什么角色

WorkBuddy 的核心价值在于它把定时触发和任务编排这两件事做在了一起。你不需要自己搭一台服务器跑 cron，也不需要写一个常驻进程去监听时间。在 WorkBuddy 里定义一个任务，设定触发时间，把要执行的步骤串起来，它到点就会跑。对于个人项目来说，这省掉了运维成本——你不用关心机器有没有重启、进程有没有挂掉、日志存在哪里。

具体到日报场景，WorkBuddy 承担的是调度中枢的角色：上午十点半触发，依次调用信息采集接口、调用模型做摘要、调用微信推送接口。每一步的返回结果传给下一步，形成一条完整的执行链。如果中间某一步失败，WorkBuddy 的任务日志里能看到是哪一步出的问题，方便定位。

2.3 模型选型：为什么倾向 deepseek-v4-flash 这类轻量模型

日报场景对模型的要求很明确：快、便宜、够用。你不需要它写一篇深度分析，只需要它把一段原始文本压缩成两三句话，把标题改得更通顺，把多条信息按主题归类。这种任务用大模型是浪费，用轻量模型刚刚好。

deepseek-v4-flash 这类模型的优势在于响应速度快、单位成本低。日报每天跑一次，每次处理几十条信息，如果每条都调用一次模型，一天下来调用次数不少。用轻量模型可以把成本压到几乎可以忽略，同时响应时间控制在秒级，不会让整个流程卡住。当然，如果你对摘要质量要求更高，也可以在关键条目上切换到更强的模型，做成“轻量模型初筛+强模型精修”的两级处理。

2.4 送达通道：为什么选微信而不是邮件或App

送达通道的选择只有一个标准：你每天一定会打开它。对绝大多数人来说，微信满足这个条件。邮件可能一天才看一次，独立App你可能根本不会装，但微信你一定会看。把日报推到微信里，意味着你不需要额外养成一个查看习惯，它直接嵌入你已有的行为路径。

具体到微信生态，有两种常见做法。一种是通过微信小程序做一个日报展示页，WorkBuddy 把日报内容写入后端，小程序负责渲染。另一种是通过服务号模板消息或企业微信机器人直接把内容推送到聊天窗口。前者适合需要交互的场景，比如你想在日报里点开某条看详情；后者适合纯阅读场景，打开即看，看完即走。我个人的选择偏向后者，因为日报的核心价值是“扫一眼就知道今天发生了什么”，不需要复杂交互。

3. 核心细节拆解与实操要点

3.1 信息源的选择与采集策略

信息源决定了日报的上限。你喂进去的是垃圾，出来的就是垃圾摘要。我的建议是少而精，不要一上来就接十几个源，先选三到五个你真正关心的，跑通之后再逐步加。

常见的信息源类型包括：技术社区的每日热榜、特定关键词的搜索结果、你关注的几个公众号的更新、开源项目的 release 动态。采集方式也分几种：有的源提供 RSS，直接解析就行；有的源需要调用 API，按文档传参；有的源没有现成接口，需要用页面抓取的方式提取内容。

这里有一个实操要点：采集环节一定要做去重和过滤。同一个事件可能被多个源报道，如果不去重，日报里会出现三条内容几乎一样的条目，读起来很烦。去重可以基于标题相似度做，也可以基于URL做。过滤则是把明显不相关的内容剔除，比如你关注AI工具，但某个源里混进了娱乐新闻，就需要用关键词白名单或黑名单过滤掉。

注意：采集频率不要设得太高。日报是每天一次，采集也每天一次就够了。高频采集不仅浪费资源，还容易触发信息源的反爬机制，导致你的请求被限制。

3.2 内容加工：从原始文本到可读日报

加工环节是整个流程里最需要调优的部分。原始信息通常是一堆标题加链接，直接推给你等于没加工。你需要做的是：提取关键信息、归类、生成摘要。

第一步是结构化。把每条信息整理成统一格式，至少包含标题、来源、时间、链接、正文摘要。这一步可以用规则做，也可以用模型做。规则做的好处是稳定、快、不花钱；模型做的好处是能处理格式不统一的源。我的做法是混合：能用规则提取的用规则，规则搞不定的丢给模型。

第二步是归类。把信息按主题分组，比如“模型更新”“工具发布”“行业动态”“论文速递”。归类可以用关键词匹配，也可以让模型判断。归类之后，日报的阅读体验会好很多，你不需要在一条条信息里自己找重点。

第三步是生成摘要。每条信息用一两句话概括核心内容，整份日报开头再写一段总览。摘要的 prompt 很关键，我试过几种写法，最后稳定下来的模板大概是这样的：

你是一个信息摘要助手。请将以下内容压缩成不超过两句话的中文摘要，保留关键事实（谁、做了什么、有什么影响），去掉修饰性描述。如果内容本身信息量不足，直接输出“信息量不足，建议查看原文”。

这个模板的好处是给了模型一个“退路”——当它判断内容不值得摘要时，可以直接说信息量不足，而不是硬编一段废话。

3.3 定时调度的配置细节

WorkBuddy 的定时任务配置通常涉及几个参数：触发时间、执行频率、超时时间、失败重试策略。

触发时间设成上午十点半，这个时间点的选择有讲究。太早，信息源可能还没更新完；太晚，你已经开始忙了，没时间看。十点半是一个折中点，大部分夜间和早间的更新都已经发布，你也有时间在午饭前扫一眼。

执行频率设成每天一次。如果你周末也想看，就设成每天；如果只想工作日看，就设成周一到周五。WorkBuddy 一般支持 cron 表达式，30 10 * * 1-5表示周一到周五的十点半触发。

超时时间要设得合理。整个流程涉及多次网络请求和模型调用，如果某个环节卡住，没有超时限制的话任务会一直挂着。我一般设 5 分钟超时，超过就判定失败，走重试或告警。

失败重试策略建议设最多重试两次，间隔一分钟。很多失败是偶发的网络抖动，重试一次就能成功。如果重试两次还失败，那就不是偶发问题，需要人工介入排查。

3.4 微信推送的几种实现路径

前面提到两种主要路径，这里展开说一下各自的实操要点。

路径一：企业微信机器人。这是最快能跑通的方式。在企业微信群里添加一个机器人，拿到 webhook 地址，WorkBuddy 在任务最后一步向这个地址发一个 POST 请求，内容就是日报的 markdown 文本。优点是配置简单，五分钟就能搞定；缺点是日报会发在群里，如果你想要私密一点，可以建一个只有自己的群。

路径二：微信小程序。这种方式适合想要更好展示效果的场景。你需要做一个小程序页面，后端提供一个接口返回日报数据，WorkBuddy 把日报写入数据库或缓存，小程序打开时拉取。小程序的开发涉及 uniapp 或原生开发，如果你不熟悉前端，这一步会花一些时间。但好处是展示形式更灵活，可以加折叠、搜索、收藏等功能。

路径三：服务号模板消息。如果你有服务号，可以通过模板消息推送到用户微信。这种方式需要服务号认证，配置相对复杂，适合已经有服务号资源的团队。

对于个人项目，我建议从企业微信机器人开始，跑通之后再考虑要不要升级到小程序。

4. 完整实操流程与关键环节实现

4.1 环境准备与 WorkBuddy 任务创建

先把 WorkBuddy 的环境准备好。如果你还没装，按照官方文档走一遍安装流程，确保能正常登录、能创建任务。安装过程中如果遇到依赖问题，优先检查运行环境的版本是否符合要求，很多安装失败都是版本不匹配导致的。

创建任务的步骤大致是：新建一个任务，命名成“AI日报-每日十点半”，选择触发方式为定时触发，填入 cron 表达式，然后开始编排步骤。WorkBuddy 的任务编排通常是步骤式的，每一步是一个动作，动作之间可以传递数据。

第一步动作：调用信息采集脚本或接口。如果你用脚本，确保脚本在 WorkBuddy 的运行环境里能执行，依赖都装好。如果你用接口，把请求参数配好，测试一下能不能拿到数据。

第二步动作：调用模型接口做摘要。把上一步的输出作为输入，传给 deepseek-v4-flash 或你选的模型。注意控制输入长度，太长的内容先截断或分段，避免超出模型的上下文限制。

第三步动作：组装日报文本。把摘要结果按归类拼成一份 markdown 格式的日报，加上日期、总览、各分类的条目。

第四步动作：推送到微信。调用企业微信机器人的 webhook，把日报文本发出去。

4.2 信息采集脚本的编写要点

采集脚本的核心逻辑是：请求信息源、解析返回内容、提取字段、去重、输出结构化数据。

以抓取一个技术社区的热榜为例，脚本大概长这样：

import requests from bs4 import BeautifulSoup import json from datetime import datetime def fetch_hot_list(): url = "https://example.com/hot" headers = { "User-Agent": "Mozilla/5.0 (compatible; DailyReportBot/1.0)" } resp = requests.get(url, headers=headers, timeout=10) resp.raise_for_status() soup = BeautifulSoup(resp.text, "html.parser") items = [] for node in soup.select(".hot-item"): title = node.select_one(".title").get_text(strip=True) link = node.select_one("a")["href"] items.append({ "title": title, "link": link, "source": "example", "fetched_at": datetime.now().isoformat() }) return items if __name__ == "__main__": data = fetch_hot_list() print(json.dumps(data, ensure_ascii=False, indent=2))

几个要点：设置 User-Agent，不要用默认的 python-requests，容易被识别为爬虫；设置超时，避免请求卡死；异常处理，网络请求可能失败，要有 try-except 包裹；输出 JSON，方便下一步解析。

去重逻辑可以单独写一个函数，基于标题的相似度或链接的域名+路径做判断。简单做法是用一个集合记录已经出现过的链接，重复的直接跳过。

4.3 模型调用的参数配置与 prompt 设计

调用模型时，几个参数需要关注：temperature、max_tokens、top_p。

日报摘要场景，temperature 设低一点，0.3 左右就够了，太高会让摘要变得不稳定，同样的输入每次输出不一样。max_tokens 根据你的摘要长度要求设，一般 200 到 500 够了。top_p 保持默认或设 0.9。

prompt 的设计前面给了一个模板，这里补充几个调优技巧。给例子比给指令更有效，你可以在 prompt 里放一两个输入输出的示例，模型会模仿这个格式。明确输出格式，比如要求输出 JSON，包含 summary 和 category 两个字段，这样后续处理更方便。限制输出长度，明确说“不超过两句话”或“不超过50字”，避免模型写太长。

如果一次要处理多条信息，可以批量传给模型，让它逐条输出摘要。但要注意上下文长度限制，条数太多就分批。

4.4 日报文本的组装与格式化

日报的格式直接影响阅读体验。我用的格式大概是这样的：

# AI日报 2025-XX-XX 今日共收录 12 条动态，其中模型更新 3 条，工具发布 4 条，行业动态 5 条。 ## 模型更新 1. **标题**（来源） 摘要内容，不超过两句话。 [原文链接](url) ## 工具发布 ... ## 行业动态 ...

要点：开头给总览，让读者一眼知道今天有多少条、都是什么类型；分类清晰，每类下面按重要性排序；每条包含标题、来源、摘要、链接，信息完整但不冗余；链接用 markdown 格式，在微信里可以直接点。

组装的时候注意转义特殊字符，避免 markdown 渲染出错。如果日报要发到企业微信，确认它支持的 markdown 语法范围，有些语法在微信里不生效。

4.5 推送环节的配置与测试

企业微信机器人的配置步骤：在企业微信里建一个群，群设置里添加机器人，拿到 webhook 地址。这个地址长这样：

https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx

推送时发一个 POST 请求，body 是 JSON：

{ "msgtype": "markdown", "markdown": { "content": "日报内容..." } }

测试的时候先用一条简单消息验证通道通不通，再发完整日报。注意企业微信机器人对消息长度有限制，太长要分段发。如果日报超过限制，可以拆成两条，或者只发摘要和链接，详情让用户点进去看。

提示：webhook 地址不要泄露，拿到地址的人都能往你的群里发消息。如果怀疑泄露了，在机器人设置里重置 key。

5. 常见问题与排查技巧实录

5.1 任务到点没触发怎么办

先检查 WorkBuddy 的任务状态，看是“未触发”还是“触发失败”。未触发通常是 cron 表达式写错了，或者任务被禁用了。触发失败则要看日志，可能是运行环境的问题。

cron 表达式最容易出错的是时区。WorkBuddy 的服务器可能跑在 UTC 时区，你写的十点半如果是本地时间，实际触发可能是下午六点半。确认一下时区设置，或者在表达式里做偏移。

另一个常见原因是任务被前一次执行阻塞。如果上一次任务还没跑完，下一次触发可能会被跳过。检查一下超时设置，确保单次执行不会超过触发间隔。

5.2 采集环节拿不到数据怎么排查

按这个顺序查：网络通不通、目标地址变没变、返回内容格式变没变、解析规则还对不对。

网络问题用 curl 或 requests 直接请求一下目标地址，看能不能拿到响应。如果返回 403 或 429，说明被限制了，需要调整请求头或降低频率。如果返回 200 但内容为空，可能是目标页面改版了，解析规则失效。

解析规则失效是最常见的问题。网页结构一变，原来的 CSS 选择器就选不到元素了。解决办法是定期检查采集结果，发现某天数据突然变少或为空，就去看看目标页面是不是改版了。

5.3 模型摘要质量不稳定的处理

摘要质量波动通常有三个原因：输入内容质量差、prompt 不够明确、模型本身的不确定性。

输入质量差是根本问题。如果原始内容就是一句话标题，模型也变不出花来。这种情况下，摘要环节可以跳过，直接展示原标题。

prompt 不够明确的话，加例子、加格式要求、加长度限制。我试过在 prompt 里写“如果内容少于20字，直接输出原标题”，效果比让模型硬摘要好。

模型不确定性可以通过降低 temperature 来缓解。如果还是不稳定，考虑换一个更稳定的模型，或者在输出后加一层规则校验，比如摘要长度超过阈值就截断。

5.4 推送失败或消息显示异常的排查

推送失败先看 HTTP 状态码。400 通常是请求体格式不对，401 是 key 无效，450 是消息类型不支持，45047 是消息长度超限。根据状态码对症处理。

消息显示异常一般是 markdown 语法问题。企业微信支持的 markdown 语法有限，比如不支持表格、不支持嵌套列表。把日报里的复杂语法简化，用纯文本加换行的方式展示。

如果消息发出去但没人收到，检查一下机器人是不是被移出群了，或者群设置里是不是禁用了机器人消息。

5.5 常见问题速查表

6. 几个我踩过的坑和实际调优经验

第一个坑是信息源太多导致日报太长。一开始我接了八个源，每天日报有四十多条，自己都不想看。后来砍到三个源，每天精选十条左右，阅读体验好很多。日报的价值在于筛选，不在于全量。

第二个坑是摘要 prompt 写得太复杂。我试过让模型同时做摘要、归类、打分，结果输出格式经常乱。后来拆成两步：先归类，再对每类做摘要。虽然多了一次调用，但稳定性高很多。

第三个坑是没有做失败告警。有段时间任务连续几天失败，我因为忙没注意，等发现的时候已经漏了一周的日报。后来加了一个简单的告警：任务失败时往另一个通道发一条消息，提醒我去看日志。

第四个坑是推送时间设得太早。一开始设的早上八点，结果发现很多源还没更新完，日报内容很少。改到十点半之后，信息量明显上来了。

调优方面，我目前的做法是每周回顾一次日报质量，看看有没有漏掉重要信息、有没有重复条目、摘要是不是准确。根据回顾结果调整信息源和 prompt。这个习惯让日报的质量一直保持在可用水平。

最后分享一个小技巧：在日报末尾加一个“今日无大事”的判断。如果当天所有条目的重要性都低于阈值，日报开头直接写“今日无重大动态”，让你一眼就知道不用细看。这个判断可以让模型做，也可以基于规则做，比如条目数少于三条就触发。