每天早上十点半手机屏幕亮起微信弹出一条消息——一份排版整齐的 AI 日报已经躺在对话框里了。这不是某个付费订阅服务而是我自己搭的一套自动化流程让 WorkBuddy 在固定时间自动跑一遍信息采集、摘要生成、格式化排版最后通过微信推送到我手上。整套东西从想法到跑通前后折腾了大概两个周末中间踩的坑不算少但跑稳之后确实省心。这篇内容适合两类人看一类是手上有 WorkBuddy 或者类似 AI 工作台工具、想把它用得更自动化一点的人另一类是对定时任务 AI 摘要 微信推送这条链路感兴趣、想自己搭一套类似流程的人。我会把整个链路的每个环节拆开讲包括为什么这么选、参数怎么定、哪些地方容易翻车以及我实际跑下来觉得最值得注意的几个细节。核心关键词就三个WorkBuddy、AI 日报、微信推送围绕它们把自动化这件事讲透。1. 为什么是闹钟 AI 日报这个组合1.1 手动整理信息的真实成本先说清楚我为什么要做这个东西。我每天需要关注的信息源比较杂行业动态、几个技术社区的热帖、自己项目相关的更新日志、还有一些零散的订阅内容。手动刷一遍快的话二十分钟慢的话一个小时就没了而且刷完之后脑子里留下的东西其实很有限——大部分信息是看过就忘。真正的问题不在于看而在于整理。人脑在被动浏览时很难做结构化归纳你刷了三十条内容最后能记住的可能就两三条。而 AI 摘要的价值恰恰在这里它不负责帮你发现信息它负责帮你把已经采集到的信息压缩成可快速扫读的结构。这两件事分开之后整个流程就清晰了——采集归采集摘要归摘要推送归推送。1.2 WorkBuddy 在这条链路里扮演什么角色WorkBuddy 本质上是一个 AI 工作台你可以把它理解成一个能调用模型、能跑脚本、能编排任务的中枢。它跟单纯的聊天式 AI 工具最大的区别在于它支持把多个步骤串成一个可重复执行的任务流。这一点对日报场景是决定性的——日报的核心诉求就是每天重复、结果稳定、格式一致而不是每次都要我重新描述一遍需求。我在 WorkBuddy 里做的事情说白了就是定义了一个任务输入是若干信息源的原始内容处理是调用模型做摘要和分类输出是一段结构化文本。然后给这个任务挂一个定时触发器每天上午十点半执行一次。执行完之后结果通过一个推送环节送到微信。这里有个很多人会忽略的点WorkBuddy 负责的是生成微信负责的是送达这两件事必须解耦。如果你把推送逻辑写死在生成任务里一旦推送通道出问题整个任务就失败了你连日报内容都拿不到。我的做法是让 WorkBuddy 先把日报落成一份文件或者一段可读取的结果推送环节单独去读这个结果。这样即使推送挂了我还能手动去取内容。1.3 十点半这个时间点是怎么定的时间点的选择看着随意其实有讲究。太早信息源还没更新完摘要出来的内容是昨天的残羹太晚等你看到的时候上午已经过了一半失去了晨间速览的意义。我试过几个时间点触发时间实测问题7:00多数信息源未更新内容重复率高8:30部分源刚更新摘要质量不稳定10:30主流源基本更新完毕摘要完整度高12:00内容全但偏晚失去晨间速览价值14:00上午信息已过时实用性下降十点半这个点是我实测下来信息完整度和时效性平衡得最好的。当然这个跟你的信息源更新节奏强相关如果你的源是凌晨更新的那完全可以提前。建议你先花三天记录一下自己主要信息源的更新时间分布再定触发点别照抄别人的时间。2. 把 WorkBuddy 的任务拆成可复用的三段2.1 采集段别让模型去干爬取的活很多人第一反应是让 AI 自己去网上找信息这个思路在日报场景里是错的。原因很简单模型的联网检索能力不稳定每次返回的内容范围、质量、去重情况都不一样你没法保证日报的稳定性。日报要的是每天结构一致而不是每天都有惊喜。我的做法是把采集和摘要彻底分开。采集段用固定的脚本或者固定的数据源接口把原始内容抓下来存成一个中间文件。这个中间文件可以是 JSON也可以是纯文本关键是格式固定。WorkBuddy 的任务从读取这个中间文件开始而不是从去网上找开始。这样做的好处有三个第一采集失败和摘要失败可以分开排查第二同一批原始内容可以反复跑摘要做对比调优第三采集源可以随时增删不影响摘要逻辑。中间文件的格式我建议至少包含这几个字段{ source: 来源标识, title: 条目标题, content: 正文或摘要原文, timestamp: 采集时间, url: 原始链接 }字段不用多但这五个基本够用。source用于后续分类timestamp用于去重和排序url用于你看到感兴趣的内容时能点回去。2.2 摘要段提示词的结构比文采重要摘要段是 WorkBuddy 真正发挥价值的地方。这里我踩过的最大坑是一开始我把提示词写得很文学希望日报读起来流畅自然结果模型开始自由发挥该保留的数字被改写了该分类的内容被合并了。后来我把提示词改成结构化指令效果立刻稳定下来。我现在用的提示词骨架大致是这样的逻辑先给角色和任务边界再给输出格式的硬性约束最后给几条负面清单。具体来说我会明确告诉它不要改写原文中的数字和专有名词每条摘要不超过两句话按来源分组输出如果某条内容无法判断价值就标注为待定而不是丢弃。这里有个经验负面清单比正面要求更管用。你告诉模型要简洁它可能理解成各种样子但你告诉它不要超过两句话、不要用形容词堆砌、不要加自己的评论它的输出就会收敛很多。我大概迭代了五六版提示词才稳定下来前几版的问题基本都是模型太想表现。另外摘要段一定要做去重。不同信息源经常报道同一件事如果不做去重日报里会出现三条内容讲同一件事的情况非常影响阅读体验。去重可以在采集段做按标题相似度也可以在摘要段做让模型识别重复并合并。我倾向于在采集段做粗去重摘要段做精合并两层配合效果最好。2.3 排版段日报的可读性决定你会不会坚持看排版这件事做之前觉得不重要做之后发现它是决定你会不会真的每天看的关键。一份密密麻麻、没有分层的日报你看两天就烦了。我的排版原则是分层清晰、重点前置、长度可控。具体做法是日报开头放一个今日三条的精选区把当天最重要的三条内容拎出来然后是分来源的详细区最后是待定区放那些模型判断不了价值的内容。这样你扫一眼开头就知道今天有没有值得深读的东西没有的话直接跳过有时间再往下看。长度控制也很重要。我一开始没限制结果日报越跑越长后来加了硬约束整份日报控制在 800 字以内单条摘要不超过 60 字。超过的部分要么合并要么砍掉。日报不是越全越好是越能快速扫完越好。这个认知转变花了我不少时间。3. 微信推送这条链路坑比想象中多3.1 为什么不用直接发到文件传输助手最朴素的想法是让脚本模拟微信操作把内容发到文件传输助手。这条路我试过结论是不稳定不建议。模拟操作依赖界面元素微信一更新界面就可能失效而且频繁操作有账号风险。更重要的是这种方式没法做格式化——你发过去的就是一坨纯文本跟在记事本里看没区别。我最后选的是微信小程序 服务端推送的方案。思路是WorkBuddy 生成日报后把内容写到一个服务端的存储里可以是数据库也可以是一个简单的文件服务然后通过微信的订阅消息或者小程序内的消息通道推送给用户。用户点开小程序就能看到排版好的日报。这个方案的好处是推送通道是官方支持的稳定展示层是小程序排版可控内容存在服务端历史日报可以回溯。代价是需要一点开发工作但如果你本来就会写小程序这部分不算难。3.2 小程序端的几个实操细节小程序端我踩过的坑主要集中在两个地方顶部导航栏高度和缓存策略。顶部导航栏高度这个事看起来是个小问题实际上不同机型、不同微信版本下导航栏高度是有差异的。如果你用固定像素值去布局在某些机型上内容会被导航栏遮住。正确做法是用微信提供的系统信息接口动态获取状态栏高度和导航栏高度然后做适配。我一开始图省事写死了 44px结果在几台安卓机上全翻车了。缓存策略是另一个坑。日报内容我一开始是每次打开小程序都重新请求结果网络不好的时候白屏体验很差。后来改成本地缓存 后台更新打开时先展示上次缓存的内容同时后台请求最新数据拿到后更新界面并刷新缓存。这样即使网络慢用户也能立刻看到内容。缓存时间我设的是 6 小时因为日报一天就更新一次没必要频繁请求。还有一个细节是请求封装。小程序的网络请求如果散落在各个页面里后期维护会很痛苦。我建议一开始就做一个统一的请求封装把 baseURL、超时、错误处理、loading 状态都收进去。这个封装大概五十行代码但能省掉后面大量的重复劳动。3.3 推送失败的兜底方案任何推送通道都有失败的可能所以兜底方案是必须的。我的兜底逻辑是这样的WorkBuddy 生成日报后先落一份到本地文件再尝试推送。如果推送环节报错任务不会整体失败而是记录一条错误日志同时把日报文件保留下来。第二天我如果发现没收到推送就去本地文件里找。更进一步我加了一个补推机制如果当天推送失败第二天任务执行时会先检查前一天是否有未推送成功的日报有的话先补推再执行当天任务。这个机制救过我好几次尤其是服务端偶尔抽风的时候。提示兜底方案的核心思想是生成和送达分离。只要生成成功了内容就不会丢送达只是时间问题。千万不要把两者耦合在一起。4. 定时触发与任务编排的稳定性设计4.1 定时器选在哪里定时触发这件事可以放在 WorkBuddy 内部也可以放在外部比如系统的定时任务。我的建议是如果 WorkBuddy 自带定时能力优先用它如果没有用外部定时器去调用 WorkBuddy 的任务接口。放在 WorkBuddy 内部的好处是链路短、依赖少放在外部的好处是灵活、可控。我实际用的是外部定时器因为我想在触发前加一些前置检查比如检查信息源是否可用、检查昨天的任务是否完成这些逻辑放在外部更自然。外部定时器我用的就是最朴素的系统级定时任务配置简单、稳定、不依赖任何第三方服务。配置的时候注意两点一是要设置好工作目录否则脚本里的相对路径会出错二是要把输出重定向到日志文件方便排查问题。# 每天上午 10:30 执行 30 10 * * * cd /path/to/task /usr/bin/python3 run_daily.py /var/log/daily.log 21这行配置里cd是为了固定工作目录是追加日志21是把错误输出也重定向到同一个日志文件。别小看这几个符号我见过太多人因为没写cd导致脚本找不到文件或者因为没重定向导致出错时完全不知道发生了什么。4.2 任务幂等性重复执行不能出乱子定时任务有个经典问题如果某次执行卡住了下一次触发时上一次还没结束就可能出现两个任务同时跑的情况。日报场景下这会导致重复推送或者内容错乱。解决办法是加幂等控制。最简单的做法是用一个锁文件任务开始时检查锁文件是否存在存在就退出不存在就创建锁文件并开始执行执行完删除锁文件。这样即使定时器重复触发也只有一个任务会真正执行。import os import sys LOCK_FILE /tmp/daily_task.lock if os.path.exists(LOCK_FILE): print(任务已在执行中退出) sys.exit(0) try: with open(LOCK_FILE, w) as f: f.write(str(os.getpid())) # 执行主逻辑 run_task() finally: if os.path.exists(LOCK_FILE): os.remove(LOCK_FILE)这个锁文件方案简单有效但要注意如果任务异常崩溃锁文件可能残留导致后续任务永远无法执行。所以要么在锁文件里写进程 ID 并在启动时检查进程是否还活着要么加一个超时机制比如锁文件超过两小时就强制删除。我用的是后者简单粗暴但够用。4.3 日志要记到什么粒度日志这件事平时觉得烦出问题时觉得救命。我的日志策略是关键节点必记异常必记正常流程记摘要。具体来说任务开始、采集完成、摘要完成、推送完成这几个节点各记一条任何异常记完整堆栈正常流程只记条数和耗时不记具体内容。这样日志文件不会爆炸出问题时又能快速定位到是哪一段出的问题。我还会在日志里记录每次任务的耗时。这个数据看起来没用但当你发现某天任务突然变慢时它能帮你快速判断是采集慢了还是摘要慢了。我有一次发现摘要段耗时从 30 秒涨到了 5 分钟查下来是某个信息源返回的内容量突然变大导致模型处理时间暴涨。没有耗时日志的话这个问题很难发现。5. 提示词调优让日报像人写的而不是像机器生成的5.1 摘要质量的三个层次我把摘要质量分成三个层次能看、好读、有用。能看是指内容完整、没有明显错误好读是指结构清晰、语言通顺有用是指读完能快速抓住重点、知道哪些值得深挖。大部分人做到能看就停了但日报的价值恰恰在有用这一层。从能看到好读靠的是格式约束从好读到有用靠的是价值判断。也就是说模型不仅要会摘要还要会判断哪条内容更重要。这个判断能力需要通过提示词来引导。我的做法是在提示词里给模型一个简单的价值判断框架时效性是不是新发生的、相关性跟我关注的方向是否匹配、信息量有没有具体的数据或结论。让模型按这三个维度给每条内容打个标签然后按标签排序。这样出来的日报重要的内容自然排在前面。5.2 避免正确的废话AI 摘要最容易犯的毛病是正确的废话——每句话都对但每句话都没信息量。比如某公司发布了新产品该产品具有多项新功能这种说了等于没说。要避免这个问题提示词里必须明确要求保留具体信息数字、名称、结论、影响范围。我甚至会在提示词里举例说明什么是废话、什么是有效信息让模型有个参照。这个举例很重要模型对抽象要求的理解远不如对具体例子的理解。另外我会要求模型在摘要里标注信息密度——如果某条内容实在没什么可提炼的就标注为低信息量而不是硬凑一句话。这样我扫的时候可以直接跳过这些条目节省时间。5.3 提示词版本管理提示词是要迭代的所以版本管理很重要。我的做法是把提示词存在一个单独的文件里每次修改都保留历史版本并在日志里记录本次任务用的是哪个版本。这样当摘要质量出现波动时我能快速定位是不是提示词改动导致的。prompts/ daily_summary_v1.txt daily_summary_v2.txt daily_summary_v3.txt current - daily_summary_v3.txt用软链接指向当前版本切换版本时只改软链接不用改代码。这个做法是从代码版本管理里借鉴过来的用在提示词上同样有效。我大概迭代了七八版提示词每一版都有明确的改进目标没有一次是随便改改。6. 跑稳之后我总结的几条经验6.1 先跑通最小链路再优化细节我一开始想一步到位把采集、摘要、排版、推送全做好结果卡了两周没跑通。后来改变策略先做一个最小版本手动准备一份原始内容让 WorkBuddy 生成摘要手动复制到微信。这个版本半小时就跑通了。然后逐步把采集自动化、把推送自动化、把排版精细化。这个顺序很重要。最小链路跑通之后你才有反馈才知道哪里是真正的瓶颈。在没跑通之前做的所有优化很可能都是优化了不重要的地方。6.2 日报的价值在于稳定不在于惊艳我见过很多人做日报追求每天都有新花样结果做了两周就放弃了。日报这种东西价值在于每天都有一份、格式一致、能快速扫完。惊艳是锦上添花稳定才是根本。所以我在设计的时候宁可内容保守一点也要保证每天都能准时出来。具体来说我会给每个环节设置超时和降级策略。采集超时就跳过该源摘要超时就输出原始内容推送失败就落本地文件。任何一个环节出问题都不会导致整个日报缺失。这种降级思维是保证稳定性的关键。6.3 定期回顾砍掉不看的板块日报跑了一段时间之后你会发现有些板块你从来不看。这些板块要么砍掉要么合并。我每个月会回顾一次日报的使用情况把连续两周没看过的板块删掉。日报不是越全越好是越贴合你实际需求越好。这个回顾习惯还帮我发现了一个问题我原本以为自己对某个方向很关注所以放了很多相关源结果回顾时发现那些内容我基本都跳过。后来我把这些源砍掉日报长度减了三分之一阅读体验反而更好了。6.4 关于 WorkBuddy 的一些使用心得WorkBuddy 这类工具用得好不好的关键不在于工具本身而在于你有没有把任务拆清楚。我的经验是一个任务只做一件事。采集是一个任务摘要是一个任务推送是一个任务。任务拆得越细越容易调试越容易复用。另外WorkBuddy 的任务配置建议用版本管理跟代码一样。每次修改都记录改了什么、为什么改。这样当任务行为出现变化时你能快速定位到是哪次修改导致的。我吃过这个亏——有一次任务突然开始输出乱码查了半天才发现是某次修改配置时手滑改错了一个参数因为没有版本记录排查花了很久。还有一点是不要过度依赖模型的智能。模型很擅长处理模糊的、需要理解的任务但不擅长处理精确的、需要一致性的任务。所以像时间格式、字段名、分类标签这些东西能用固定规则就用固定规则别交给模型去判断。模型负责理解内容规则负责保证一致两者分工明确整个系统才稳。6.5 一个容易被忽略的细节时区定时任务和日志时间戳一定要统一时区。我有一次发现日报的时间戳总是差几个小时查下来是服务器时区和本地时区不一致。这个问题不影响功能但影响排查问题时的判断。建议在任务开始时就把时区固定下来所有时间相关的地方都用同一个时区。import os os.environ[TZ] Asia/Shanghai这行代码放在任务脚本的最开头能避免很多时间相关的困惑。别觉得这是小事排查时间相关问题时时区不一致能让你怀疑人生。整套流程跑到现在大概三个月了中间大改过两次小修过无数次。现在每天早上十点半微信准时弹出日报我扫一眼三分钟看完该深挖的记下来该跳过的跳过。省下来的时间够我多写两段代码或者多喝一杯咖啡。如果你也在做类似的事情我的建议是先把最小链路跑通然后慢慢磨别急着一口吃成胖子。