★ FEATURED ARTICLE 1. 从一条消息推送说起为什么我要给 WorkBuddy 设个“闹钟”每天早上到工位第一件事是打开电脑、点开几个信息源、翻一遍昨天夜里到今早的行业动态然后手动整理成一段能看的摘要。这件事听起来不复杂但真正做过的人都知道它消耗的不只是十分钟而是你一天里最清醒、最该用来干正事的那段注意力。我试过用各种方式简化它收藏夹、RSS、群里的转发、备忘录里的碎片记录最后都败给同一个问题——信息是散的整理是累的坚持是难的。所以当我开始用 WorkBuddy 做日常任务编排之后脑子里冒出来的第一个念头就是能不能让它每天上午十点半自动把一份整理好的 AI 日报送到我微信里不是那种需要我主动去某个后台点一下“生成”的半自动方案而是真正意义上的“闹钟式”推送——时间一到内容已经在微信里等着我了。这个项目的核心其实就三件事定时触发、内容生成、微信送达。听起来简单但每一环都有坑。定时触发要考虑时区和任务队列的稳定性内容生成要解决数据源筛选、摘要质量和格式统一的问题微信送达则涉及小程序消息推送、模板消息、订阅消息这几条不同的路径选错了要么发不出去要么被限制。我前后折腾了大概两周中间推翻过两版方案最后跑通的这套流程每天十点半准时推送稳定跑了三个月没出过大问题。这篇文章适合两类人看一类是已经在用 WorkBuddy 做自动化、想进一步把它接入微信生态的另一类是对 AI 日报、自动化推送感兴趣想自己搭一套类似流程但还没找到切入点的。我会把方案选型的理由、关键参数的计算、实操步骤、踩过的坑全部摊开讲尽量做到你照着做就能复现。涉及 WorkBuddy 的具体配置和 DeepSeek 的调用细节我会给出可直接参考的参数和代码片段但不会贴任何敏感信息。先说结论这套方案的核心不是“技术有多难”而是“链路设计得对不对”。很多人卡住不是因为不会写代码而是因为把定时、生成、推送这三件事耦合在一起导致任何一环出问题整个流程就崩。我的做法是把它们拆成三个独立模块用消息队列串起来每个模块可以单独调试、单独替换。下面我从整体设计开始拆。2. 整体方案设计与核心思路拆解2.1 为什么选择“三段式”架构而不是一把梭最开始我图省事写了一个大脚本定时器触发之后脚本内部依次完成抓取、调用 DeepSeek 生成摘要、调用微信接口推送。跑了两天就发现问题——只要 DeepSeek 的接口响应慢一点整个脚本就卡住定时器下一次触发时上一个任务还没结束日志里全是超时。更麻烦的是如果微信推送失败我根本不知道是生成环节出了问题还是推送环节出了问题排查起来像在黑暗中找开关。后来改成三段式调度层、生成层、推送层各自独立。调度层只负责在每天十点半准时发出一个“该生成日报了”的信号生成层收到信号后去抓数据、调模型、产出内容然后把结果写到一个中间存储里推送层再从这个存储里取内容组装成微信消息发出去。三层之间通过一个轻量的任务队列通信任何一层挂了其他层不受影响而且每一层都有独立的日志和重试机制。这个架构的好处在实际运行中非常明显。有一次 DeepSeek 的 API 响应特别慢生成层积压了三个任务但推送层完全不受影响照常把已经生成好的内容发出去。还有一次微信侧的接口临时调整推送失败但生成层的内容已经落库了我手动补推一次就行不用重新生成。这种“解耦”带来的容错能力是一把梭方案给不了的。2.2 定时触发为什么是十点半而不是别的時間十点半这个时间点不是随便定的。我观察了自己两周的作息九点到十点之间通常在处理邮件和晨会注意力被切得很碎十点半左右第一波紧急事务基本处理完正好需要一个“信息补给”来衔接上午的后半段。太早推送我还没进入工作状态消息容易被忽略太晚推送上午都快结束了日报的时效性就打折扣了。从技术角度看十点半这个时间点还有一个好处它避开了整点的高峰期。很多定时任务都设在整点触发服务器负载在整点前后会有一个小高峰。十点半这个“半点”时刻队列压力相对小任务执行的延迟更低。我在调度层用的是 WorkBuddy 内置的定时任务能力配置表达式是0 30 10 * * ?也就是每天上午十点三十分触发一次。这里要注意时区设置WorkBuddy 默认用的是服务器时区如果你的服务器在 UTC 时区需要显式指定为东八区否则会差八个小时。提示定时任务的时区配置是最容易被忽略的坑。我建议在调度层加一行日志每次触发时打印当前服务器时间和目标时区时间方便核对。2.3 内容生成DeepSeek 在链路里扮演什么角色生成层的核心任务是从若干个信息源里抓取原始内容然后交给 DeepSeek 做摘要和结构化。为什么选 DeepSeek 而不是别的模型主要是两个原因一是它的 API 调用成本在我可接受的范围内每天一次日报生成token 消耗量不大二是它对中文技术内容的摘要质量比较稳定尤其是对技术术语的处理不会出现那种“翻译腔”很重的表达。生成层的流程是这样的先并行抓取预设的几个信息源把原始文本汇总成一个大的上下文然后构造一个 prompt要求 DeepSeek 按照固定的格式输出——包括“今日重点”“技术动态”“值得关注的项目”三个板块每个板块下面用短句列出要点最后对输出做一次格式校验确保没有多余的空行、没有 markdown 语法错误、没有截断。这里的关键是 prompt 的设计我试过好几版最后稳定下来的版本对输出格式的约束非常严格基本不需要人工二次整理。2.4 微信送达订阅消息 vs 模板消息 vs 小程序推送微信侧的推送有三条路可以走模板消息、订阅消息、小程序自身的消息推送。模板消息早在几年前就被限制了现在基本不可用订阅消息需要用户主动订阅而且每次订阅只能发一条对于每天推送的日报来说让用户每天手动订阅一次显然不现实小程序自身的消息推送能力在用户授权之后可以做到长期推送但需要处理好授权过期和重新授权的问题。我最后选的是小程序订阅消息的“长期订阅”模式。这里有一个关键点长期订阅只对特定类目的小程序开放普通开发者账号只能使用一次性订阅。如果你的小程序类目不在长期订阅的范围内那就需要换一种思路——比如用服务号模板消息或者引导用户把日报推送到自己的文件传输助手。我在实操中用的是长期订阅因为我的小程序类目刚好符合要求。如果你不符合也不用灰心后面我会讲替代方案。2.5 数据流全景从触发到送达的完整链路把上面几层串起来完整的数据流是这样的每天上午十点半调度层触发一个任务往队列里写一条消息生成层监听到消息后并行抓取信息源调用 DeepSeek 生成日报内容把结果写入一个 JSON 文件并上传到对象存储推送层监听到生成完成的事件从对象存储拉取内容组装成订阅消息的数据格式调用微信接口推送给用户。整个链路里每一层都有重试机制失败的任务会进入死信队列我每天早上会看一眼死信队列如果有积压就手动处理。这个链路的设计原则是任何一层都不依赖上一层的实时状态。生成层不需要知道调度层是怎么触发的推送层也不需要知道生成层是怎么调模型的。每一层只关心自己的输入和输出这样替换任何一层都不会影响其他层。比如我后来把 DeepSeek 换成了另一个模型做对比测试只需要改生成层的配置推送层完全不用动。3. 核心细节解析与实操要点3.1 WorkBuddy 定时任务的配置细节WorkBuddy 的定时任务配置界面看起来简单但有几个参数需要特别注意。第一个是触发频率我选的是 Cron 表达式模式因为需要精确到每天十点半。第二个是任务超时时间默认是 30 秒但生成层调用 DeepSeek 可能需要更长时间所以我把超时设成了 120 秒。第三个是失败重试策略我设的是最多重试 3 次每次间隔 60 秒超过 3 次就写入死信队列。配置的时候有一个细节容易踩坑WorkBuddy 的任务超时时间是从任务开始执行算起的如果你的任务里包含了网络请求而网络请求的耗时超过了超时时间任务会被强制中断。我一开始把超时设成 30 秒结果生成层经常被中断日志里显示“任务超时”。后来改成 120 秒就稳定了。你可以根据自己调用的模型响应时间来调整这个值一般建议设成平均响应时间的 3 倍以上。注意超时时间不是越长越好。设得太长任务卡住时会占用队列资源影响后续任务的执行。我的经验是先测出平均响应时间然后乘以 3再根据实际运行情况微调。3.2 DeepSeek API 调用的参数选择与成本控制调用 DeepSeek 的 API 时有几个参数直接影响输出质量和成本。第一个是temperature我设的是 0.3因为日报需要的是稳定、可预期的输出不需要太多创造性。第二个是max_tokens我设的是 2000因为日报内容通常不会超过这个长度设太大浪费额度设太小可能截断。第三个是top_p我保持默认的 0.9没有特别调整。成本控制方面我做了两件事一是把信息源的原始文本做了一次预处理去掉重复内容和无关的广告文本减少输入 token二是把日报的格式固定下来让模型不需要在格式上“发挥”减少输出 token。实测下来每天一次日报生成的 token 消耗在 3000 到 5000 之间按 DeepSeek 的定价算一个月的成本在可接受范围内。这里有一个实操心得不要把所有信息源一股脑塞给模型。我一开始把十几个信息源的内容全部拼在一起结果模型抓不住重点输出的日报又长又散。后来改成先做一轮筛选只保留最近 24 小时内更新的、与 AI 相关的条目再按重要性排序取前 20 条作为输入。这样模型的输出质量明显提升token 消耗也降下来了。3.3 微信订阅消息的模板设计与数据组装微信订阅消息的模板需要在微信公众平台后台先创建创建的时候要选好模板的字段。我的模板有三个字段thing1日报标题、thing2今日重点摘要、time3生成时间。字段的类型和长度都有限制比如thing类型最多 20 个字符所以摘要不能太长需要提前截断。数据组装的时候要把生成层产出的 JSON 内容映射到模板字段上。这里有一个坑微信对字段内容的格式有要求不能包含特殊字符不能有换行符。我一开始直接把模型输出的多行文本塞进去结果推送失败报错说“内容格式不合法”。后来加了一个清洗步骤把换行符替换成空格把特殊字符过滤掉才推送成功。提示建议在推送层加一个“预校验”步骤在调用微信接口之前先检查字段长度和字符合法性避免因为格式问题导致推送失败。3.4 中间存储的选择为什么用对象存储而不是数据库生成层和推送层之间的中间存储我选的是对象存储而不是数据库。原因有三个一是日报内容是非结构化文本用对象存储更自然二是对象存储的读写延迟低推送层拉取内容的速度快三是对象存储有天然的版本管理能力我可以回溯每一天的日报内容方便排查问题。具体用的是云厂商的对象存储服务每天生成一个 JSON 文件文件名用日期命名比如daily-report-2025-01-15.json。推送层根据日期去拉取对应的文件如果文件不存在就说明生成层还没完成推送层会等待并重试。这个设计让生成和推送之间的耦合度降到最低即使生成层延迟了推送层也不会丢数据。3.5 日志与监控怎么知道每天的任务有没有跑成功没有监控的自动化就是耍流氓。我在每一层都加了日志调度层记录触发时间和任务 ID生成层记录抓取的信息源数量、模型调用的耗时和 token 消耗推送层记录推送结果和微信返回的 message id。这些日志统一收集到一个日志服务里我每天早上花一分钟看一眼昨天的日志确认没有异常。除了日志我还加了一个简单的告警机制如果推送层连续两次推送失败就通过另一个渠道给我发一条提醒。这个提醒渠道我用的是邮件因为邮件不依赖微信生态即使微信侧出了问题也能收到。告警的阈值设的是“连续两次失败”因为偶尔一次失败可能是网络抖动连续两次失败就说明有问题了。3.6 安全与合规推送内容里不能出现什么日报的内容来自公开信息源但经过模型摘要之后可能会产生一些意想不到的表达。我在生成层的 prompt 里加了一条硬性约束不输出任何涉及个人隐私、未公开信息、敏感话题的内容。同时在推送层加了一个关键词过滤如果日报内容里出现了预设的敏感词就拦截这条推送改为发送一条“今日日报内容需要人工审核”的提醒。这个过滤机制我建议每个做自动化推送的人都加上。模型不是万能的它可能会把信息源里的某些表达原样带出来如果不加过滤推送出去的内容可能会带来不必要的麻烦。我的做法是维护一个敏感词列表每次推送前做一次扫描命中就拦截。这个列表不需要很长但覆盖要全。4. 实操过程与核心环节实现4.1 环境准备WorkBuddy 的安装与基础配置WorkBuddy 的安装过程不复杂官方文档写得比较清楚。我是在一台常开的云服务器上部署的系统是 Ubuntu 22.04。安装步骤大致是先安装依赖的运行环境然后下载 WorkBuddy 的安装包解压后运行初始化脚本最后配置管理员账号和访问端口。整个过程大概十分钟。配置的时候有几个地方需要留意。第一个是数据目录默认是在安装目录下的data文件夹我改成了一个独立的挂载盘避免系统盘满了影响任务执行。第二个是访问端口默认是 8080我改成了一个不常用的端口减少被扫描的风险。第三个是管理员密码一定要设一个强密码不要用默认的。安装完成后我建议先跑一个最简单的定时任务测试一下比如每分钟往日志里写一条记录确认调度层能正常工作。这个测试花不了几分钟但能帮你提前发现环境问题。4.2 调度层实现Cron 表达式与任务队列的对接调度层的核心是一个 Cron 表达式加上一个任务队列的写入操作。WorkBuddy 支持在任务里执行自定义脚本我写了一个简单的 Python 脚本内容就是往队列里写一条消息。脚本的逻辑很简单连接队列服务写入一条 JSON 消息消息体里包含任务类型和触发时间。import json import redis from datetime import datetime def trigger_daily_report(): r redis.Redis(hostlocalhost, port6379, db0) message { task_type: daily_report, trigger_time: datetime.now().isoformat(), date: datetime.now().strftime(%Y-%m-%d) } r.lpush(task_queue, json.dumps(message)) print(fTask triggered at {message[trigger_time]})这个脚本部署在 WorkBuddy 的定时任务里Cron 表达式设为0 30 10 * * ?。脚本执行时间通常在 100 毫秒以内不会触发超时。队列我用的是 Redis因为它的读写速度快而且支持持久化即使服务重启也不会丢消息。4.3 生成层实现信息抓取、Prompt 构造与模型调用生成层是一个常驻的消费者进程它监听队列收到消息后开始执行。第一步是抓取信息源我用的是requests库并行抓取每个源设置 10 秒超时失败的源跳过并记录日志。抓取到的原始文本先做一轮清洗去掉 HTML 标签、广告文本和重复内容。第二步是构造 prompt。我的 prompt 模板是这样的PROMPT_TEMPLATE 你是一个 AI 行业日报编辑。请根据以下原始信息生成一份结构化的日报。 要求 1. 分为三个板块今日重点、技术动态、值得关注的项目。 2. 每个板块用短句列出要点每条不超过 50 字。 3. 不要输出任何与 AI 无关的内容。 4. 不要输出任何敏感信息。 5. 输出格式为纯文本不要使用 markdown 语法。 原始信息 {raw_content} 第三步是调用 DeepSeek 的 API。我用的是requests直接发 POST 请求请求体里包含model、messages、temperature、max_tokens等参数。调用的时候加了重试机制如果返回 429限流或 500服务端错误就等待 5 秒后重试最多重试 3 次。import requests import time def call_deepseek(prompt, api_key): url https://api.deepseek.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.3, max_tokens: 2000 } for attempt in range(3): try: resp requests.post(url, headersheaders, jsonpayload, timeout60) if resp.status_code 200: return resp.json()[choices][0][message][content] elif resp.status_code in (429, 500): time.sleep(5) else: raise Exception(fAPI error: {resp.status_code}) except requests.exceptions.Timeout: time.sleep(5) raise Exception(DeepSeek API call failed after 3 retries)第四步是把生成的内容写入对象存储。我用的是云厂商的 SDK上传的时候设置文件名为daily-report-{date}.json内容是一个 JSON 对象包含日报正文、生成时间和 token 消耗。4.4 推送层实现订阅消息的组装与发送推送层也是一个常驻的消费者进程它监听的是“生成完成”的事件。收到事件后先从对象存储拉取当天的日报文件然后组装成微信订阅消息的数据格式。def build_subscribe_message(report_content, date): # 截断摘要确保不超过 20 个字符 summary report_content[:20].replace(\n, ) return { touser: USER_OPENID, template_id: TEMPLATE_ID, page: pages/index/index, data: { thing1: {value: fAI日报 {date}}, thing2: {value: summary}, time3: {value: datetime.now().strftime(%Y-%m-%d %H:%M)} } }组装好之后调用微信的订阅消息接口发送。发送的时候需要 access_token这个 token 需要提前获取并缓存避免每次发送都去请求。我用的是 Redis 缓存token 的有效期是 7200 秒我设的缓存过期时间是 7000 秒留 200 秒的缓冲。def send_subscribe_message(message, access_token): url fhttps://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token{access_token} resp requests.post(url, jsonmessage, timeout10) result resp.json() if result.get(errcode) ! 0: raise Exception(fSend failed: {result}) return result发送成功后记录 message id 到日志。如果发送失败根据错误码决定是否重试。比如errcode为 40001access_token 无效就刷新 token 后重试errcode为 43101用户拒绝接收就不重试直接记录并告警。4.5 联调与测试怎么模拟完整的推送流程联调的时候我没有等到第二天十点半而是手动往队列里写了一条消息模拟调度层的触发。生成层收到消息后正常执行推送层也正常发送。第一次联调就发现了问题推送层拉取对象存储的文件时因为文件还没上传完成拉取失败。后来加了一个等待重试的逻辑如果文件不存在就等待 5 秒后重试最多重试 6 次。第二次联调发现的问题是字段截断。日报摘要超过了 20 个字符微信接口返回格式错误。后来在组装消息的时候加了截断逻辑确保每个字段都不超过限制。第三次联调就比较顺利了整个链路跑通微信里收到了推送。提示联调的时候建议用测试用的 openid不要用真实用户的 openid避免打扰。测试通过后再切换到真实用户。4.6 上线后的第一次真实推送发生了什么上线后的第一天我特意早起等着十点半的推送。十点半一到微信里弹出了消息标题是“AI日报 2025-01-15”摘要显示“今日重点DeepSeek 发布新版本...”。点进去看内容结构清晰三个板块都有内容格式也整齐。那一刻的感觉还是挺爽的毕竟折腾了两周。不过也不是没有问题。第一天的日报里“值得关注的项目”板块只有一条内容明显偏少。我检查了信息源发现是因为筛选逻辑太严格把一些边缘相关的项目过滤掉了。后来调整了筛选阈值第二天的日报就正常了。这个调整过程让我意识到自动化流程的上线不是终点而是一个持续调优的起点。5. 常见问题与排查技巧实录5.1 定时任务没有触发从时区到队列的排查路径定时任务没触发是最常见的问题排查路径可以按这个顺序走先确认 WorkBuddy 的服务是否在运行再看调度层的日志有没有触发记录然后检查 Cron 表达式是否正确最后确认时区设置。我遇到过一次是因为服务器重启后 WorkBuddy 没有自动启动导致定时任务没执行。后来加了一个开机自启的配置这个问题就没再出现过。还有一个隐蔽的坑是 Cron 表达式的格式。不同的系统对 Cron 表达式的支持不一样有的支持 6 位包含秒有的只支持 5 位。WorkBuddy 用的是 6 位格式如果你从别的地方复制了一个 5 位的表达式可能会解析失败。我建议在配置完成后先手动触发一次确认表达式能被正确解析。5.2 DeepSeek 调用超时或限流重试策略与降级方案DeepSeek 的 API 在高峰期可能会出现响应慢或限流的情况。我的应对策略是设置合理的超时时间60 秒加上重试机制最多 3 次间隔 5 秒如果重试后仍然失败就降级到备用方案——使用上一次的日报内容并在推送时标注“今日日报生成延迟以下为昨日内容”。这个降级方案保证了推送不会中断用户至少能收到一些内容。限流的问题可以通过控制调用频率来缓解。我每天只调用一次基本不会触发限流。如果你需要更频繁地调用建议在代码里加一个令牌桶或漏桶算法控制每秒的请求数。5.3 微信推送失败错误码速查与处理微信订阅消息推送失败时返回的错误码是排查的关键。我整理了一个常见错误码的速查表错误码含义处理方式40001access_token 无效刷新 token 后重试40003openid 无效检查 openid 是否正确43101用户拒绝接收不重试记录并告警47003模板参数不合法检查字段长度和字符45009接口调用超过限额降低调用频率这个表我贴在代码注释里每次遇到新的错误码就补充进去。排查的时候先看错误码再对照处理方式基本能解决大部分问题。5.4 日报内容质量不稳定Prompt 调优的几次迭代日报内容质量不稳定的问题我主要通过调优 prompt 来解决。第一版 prompt 太简单模型输出的内容很散第二版加了格式约束但模型有时候会忽略第三版把格式约束放在 prompt 的开头并且用“必须”“不要”这样的强约束词输出就稳定多了。第四版加了一个 few-shot 示例给模型一个输出样例质量又提升了一截。我的经验是prompt 的约束要具体、要前置、要有示例。不要指望模型能“理解”你的意图要把意图翻译成明确的规则。比如“输出简洁”这种表述太模糊改成“每条要点不超过 50 字”就明确多了。5.5 对象存储文件拉取失败重试与兜底逻辑推送层拉取对象存储文件失败的情况我遇到过几次。原因主要有两个一是生成层还没上传完成推送层就急着拉取二是对象存储的临时网络抖动。针对第一个原因我加了等待重试逻辑如果文件不存在就等待 5 秒后重试最多重试 6 次。针对第二个原因我加了兜底逻辑如果重试后仍然失败就从本地缓存里读取上一次的日报内容确保推送不中断。这个兜底逻辑在实际运行中救过我好几次。有一次对象存储服务临时不可用推送层从本地缓存读取了前一天的日报虽然内容不是最新的但至少没有让用户空等。5.6 订阅消息授权过期如何引导用户重新授权订阅消息的授权是有有效期的长期订阅虽然有效期较长但也不是永久的。如果用户长时间没有与小程序交互授权可能会失效。我的做法是在推送失败且错误码为 43101 时给用户发一条普通的服务通知引导用户重新授权。这个通知不依赖订阅消息用的是小程序的客服消息能力。引导重新授权的文案要简洁明了比如“您的日报订阅已过期点击重新订阅”。点击后跳转到小程序的订阅页面用户确认后授权就恢复了。这个流程我测试过几次用户的重新授权率还不错。5.7 日志排查实战一次推送延迟的完整分析有一次推送延迟了将近一个小时我通过日志排查了整个过程。调度层的日志显示十点半准时触发了任务生成层的日志显示抓取信息源花了 15 分钟因为其中一个源响应特别慢模型调用花了 3 分钟上传对象存储花了 1 分钟推送层在十点五十分收到事件但拉取文件时失败了两次重试后成功最终在十一点二十分完成推送。问题的根因是信息源抓取太慢。后来我给每个信息源设置了独立的超时时间10 秒并且把串行抓取改成了并行抓取整体耗时降到了 2 分钟以内。这个优化之后推送时间稳定在十点三十五分左右。5.8 成本与频率的平衡多久推一次最合适每天推一次是我目前的选择但我也试过每周推一次和每天推两次。每周推一次的问题是信息滞后太严重很多动态等到周末已经过时了每天推两次的问题是内容重复度高而且增加了 token 消耗和推送次数。最后回到每天一次时间定在十点半这个频率和时机对我来说是最合适的。如果你觉得每天一次太频繁可以改成工作日推送、周末不推。这个只需要在调度层加一个判断逻辑检查当天是星期几如果是周末就跳过。这个改动很小但能减少不必要的打扰。6. 后续可以继续折腾的几个方向这套流程跑通之后我又想了几个可以继续优化的方向。第一个是个性化现在的日报是固定格式后续可以根据我的阅读习惯调整板块的权重比如我最近关注某个技术方向就让它多推这方面的内容。第二个是多端同步除了微信还可以推送到邮箱、飞书或者钉钉这样即使微信侧出问题其他渠道也能收到。第三个是交互式日报在推送的消息里加一个“查看更多”的链接点进去可以看到更详细的原始信息而不只是摘要。还有一个方向是把生成层做成可插拔的现在用的是 DeepSeek后续可以接入其他模型做对比甚至可以根据内容类型自动选择模型。比如技术动态用 DeepSeek行业新闻用另一个模型这样能发挥不同模型的优势。这些方向我还没有全部实现但架构上已经留好了扩展点。三段式的设计让每一层都可以独立替换不需要动其他层。这也是我一开始坚持解耦的原因——自动化流程不是一次性的它需要能随着需求变化而演进。最后分享一个小技巧如果你也在做类似的自动化推送建议在推送内容里加一个“反馈”入口比如一个简单的“有用/没用”按钮。用户的反馈数据可以帮助你持续优化内容质量而且这个数据是自动收集的不需要额外的人工整理。我在日报里加了这个入口之后根据反馈调整了几次板块的权重现在的日报比第一版好用多了。
阅读完成 · 觉得有帮助？
