1. 从手动刷信息到定点投喂这个闹钟到底解决了什么每天早上打开电脑第一件事是什么我猜很多人的答案跟我差不多打开浏览器翻几个技术社区扫一眼行业新闻再切到几个群看看有没有人聊新东西。这套动作看起来不费劲但实际算下来每天至少吃掉二十分钟而且信息是碎的——看完就忘真正有用的那几条往往在需要的时候又想不起来。我给 WorkBuddy 设了个闹钟这件事本质上就是把上面这套手动刷信息的动作改成定点投喂。每天上午十点半一份整理好的 AI 日报会自动出现在微信里我不用主动去翻它自己送上门。这个时间点不是随便定的后面会讲为什么。先把概念说清楚免得有朋友看到标题一头雾水。WorkBuddy在这里扮演的是干活的那个——它负责按我预设的指令去抓取、整理、生成内容微信是收货地址——生成好的日报通过微信推送到我手上中间串起来的那个闹钟就是自动化调度。三个东西各司其职缺一不可。这套东西适合谁我梳理了一下大概三类人用得上信息焦虑型选手每天要跟进 AI 领域动态但没时间也没耐心一条条筛希望有人把饭做好端上来。内容创作者需要持续的输出素材日报本身就是选题库看到有意思的点可以直接展开写。想入门自动化但不知道从哪下手的人这个项目麻雀虽小五脏俱全——定时、抓取、生成、推送四个环节全占了是练手自动化的绝佳样本。不适合谁如果你对信息时效性要求是秒级那日报这种每天一次的节奏肯定满足不了你如果你压根不关心 AI 领域那这套东西对你也没意义。工具是给需求服务的别为了自动化而自动化。我踩过的第一个坑就是一开始想做得太复杂。最初我的设想是实时监控几十个源一有更新立刻推送。结果折腾了两天发现推送太频繁反而成了骚扰而且很多更新其实是噪音。后来我把思路收回来改成每天固定时间汇总一次世界立刻清净了。频次这件事宁少勿多这是我从这个项目里学到的第一条经验。2. 拆解这条流水线四个环节各自在干什么要把每天十点半收到日报这件事落地得先把它拆成可执行的环节。我把它拆成了四段触发、采集、生成、投递。每一段都有它的脾气下面逐个说。2.1 触发环节为什么是十点半而不是八点定时触发听起来最简单定个 cron 就完事了但时间点的选择其实有讲究。我试过几个时间触发时间实际体验问题早上 7:00起床就能看到太早很多源还没更新日报内容偏旧早上 8:30通勤路上看推送时我在地铁上看完就忘没有沉淀上午 10:30工作间隙查看各源基本更新完毕且我有整块时间细读下午 14:00午休后看上午的信息已经过时失去了日报的意义最后定在十点半核心逻辑是给信息源留足更新时间同时卡在我有整块注意力的时段。大部分技术社区和资讯站的更新高峰在早上八点到十点之间十点半去抓能捞到当天最全的一批。再晚就变成昨天的新闻今天看了。技术上触发用系统级的定时任务就行。Linux 下是 cronWindows 下是任务计划程序macOS 用 launchd。如果你跟我一样把 WorkBuddy 跑在一台常开的机器上cron 是最省事的选择# 每天上午 10:30 执行日报生成脚本 30 10 * * * /usr/bin/python3 /home/user/workbuddy/daily_report.py /home/user/workbuddy/logs/cron.log 21这里有个细节值得说日志一定要重定向。我一开始没加 ... 21结果脚本报错了完全不知道白白空跑了好几天。加上日志之后出问题第一时间就能定位。提示cron 的环境变量跟你手动执行时不一样脚本里用到的路径、密钥最好都写绝对路径或者显式 source 一下环境配置否则很容易出现手动跑没问题cron 跑就报错的经典问题。2.2 采集环节抓什么、怎么抓、抓多少采集是整条流水线里最费心思的一段。抓什么源、抓多少条、怎么去重直接决定了日报的质量。我的源清单大概分三类技术社区类各类开发者社区的热榜、最新帖。资讯聚合类AI 领域的新闻站点、行业媒体的更新。个人关注类几个我长期跟踪的博主、项目的更新动态。抓取方式上能用官方接口就用接口没有接口再考虑页面解析。接口的好处是稳定、结构化坏处是很多站点不开放。页面解析的坏处是页面一改版就失效需要定期维护。这里必须提一个我踩过的坑别贪多。我一开始列了三十多个源结果日报长得像裹脚布自己都不想看。后来砍到八个核心源每条只保留标题加一句话摘要阅读体验立刻上来了。日报的价值在于精不在于全这是血的教训。去重也是个大问题。同一个新闻好几个源都在转如果不去重日报里会出现三条一模一样的内容。我的做法是用标题的相似度做粗筛再结合发布时间判断重复的直接丢掉。# 简化的去重逻辑示意 def dedupe(items): seen set() result [] for item in items: # 用标题前 20 个字符做粗粒度指纹 fingerprint item[title][:20] if fingerprint not in seen: seen.add(fingerprint) result.append(item) return result这个指纹法很粗糙但对日报这种场景够用了。追求极致准确的话可以上文本相似度算法但那是另一个量级的工程量没必要。2.3 生成环节让 WorkBuddy 把原料炒成菜采集回来的是原料——一堆标题、链接、摘要。生成环节要做的是让 WorkBuddy 把这些原料整理成一份能读的日报。我的指令大概长这样这是核心值得反复打磨你是一个 AI 领域的信息编辑。下面是我今天采集到的原始信息列表。 请帮我整理成一份日报要求 1. 按主题分类比如模型发布工具更新行业动态 2. 每条用一句话概括核心信息不要照抄原标题 3. 挑出 3 条你认为最值得关注的放在开头做今日重点 4. 语言简洁不要客套话不要综上所述这类总结 5. 如果某条信息价值不大直接删掉不要硬凑这份指令我改了不下十版。最初的版本太笼统生成出来的东西像流水账后来加了分类重点删减这几个约束质量明显提升。指令的颗粒度决定了输出的质量这是用 WorkBuddy 这类工具的核心心法。还有一个细节给 WorkBuddy 明确的人设和边界。我在指令开头写了你是一个 AI 领域的信息编辑它生成的内容就会往编辑的视角靠而不是干巴巴地罗列。同时明确告诉它不要客套话能有效避免那种以下是今天的日报希望对您有帮助的废话。2.4 投递环节怎么把日报送进微信投递是最后一公里也是最容易卡住的地方。把内容送进微信常见的有几条路企业微信机器人如果你有企业微信建个群加个机器人通过 webhook 推送这是最稳的方式。微信文件传输助手通过一些自动化手段把内容发到文件传输助手自己就能看到。公众号/服务号模板消息适合有开发能力的团队个人用略重。我选的是企业微信机器人这条路原因是它足够简单、稳定而且不涉及任何账号风险。核心就是往一个 webhook 地址 POST 一段 JSONcurl https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的KEY \ -H Content-Type: application/json \ -d { msgtype: markdown, markdown: { content: ## AI 日报\n 今日重点\n- 第一条\n- 第二条 } }企业微信机器人支持 markdown 格式日报的排版能做得比较清爽。注意内容长度有限制太长会被截断所以日报要控制篇幅——这又回到了前面说的别贪多。注意webhook 的 key 相当于密码别硬编码在脚本里更别提交到代码仓库。用环境变量或者独立的配置文件管理这是基本的安全习惯。3. 把 WorkBuddy 用顺手指令设计和调试的几个关键点前面讲了流水线的四个环节这一节专门聊聊 WorkBuddy 本身怎么用。很多人装完 WorkBuddy 就卡在不知道让它干什么或者让它干的结果不满意问题基本都出在指令上。3.1 指令要像给实习生派活而不是像许愿我见过太多人给 AI 下指令的方式就一句话帮我整理一下今天的 AI 新闻。然后抱怨结果不好。这就像你跟实习生说帮我搞个方案然后期待他交出完美答卷——不现实。好的指令应该包含这几个要素角色你是谁用什么视角干活。任务具体要做什么越具体越好。约束格式、长度、风格、禁忌。示例给一两个样例效果立竿见影。我现在的日报指令里会附上一段理想输出样例让 WorkBuddy 照着这个格式来。加了样例之后输出的稳定性提升非常明显。3.2 调试指令的正确姿势小步快跑调指令不要一次改一大堆那样你根本不知道是哪句话起了作用。我的做法是每次只改一个变量跑一遍看效果有效就保留无效就回退。比如我想让日报更简洁就先只加一条每条不超过 30 字跑一遍看。如果还是太长再加删掉所有形容词再跑。这样一步步逼近理想效果比一次性写一大段指令然后反复推倒重来高效得多。3.3 处理 WorkBuddy 的幻觉给它事实别让它编AI 生成内容最大的风险是一本正经地胡说八道。日报场景下这个风险尤其要防——如果它把某条新闻的时间、主体搞错了你信以为真那就麻烦了。我的应对策略是把事实喂给它让它只做整理不做创造。采集环节拿到的标题、摘要、链接原封不动地传给 WorkBuddy指令里明确写只基于我提供的信息整理不要添加任何我没有提供的内容。这样能最大程度避免它自由发挥。如果某条信息它整理得不对我会在指令里加一句如果信息不完整标注信息待确认不要猜测。这个约束很管用能有效抑制幻觉。4. 那些没人告诉你但一定会遇到的坑这一节是整篇的重点。前面讲的是应该怎么做这里讲的是实际做的时候会怎么翻车。这些都是我真金白银踩出来的希望能帮你省点时间。4.1 定时任务看起来在跑其实没跑这是最隐蔽的坑。cron 配置好了日志也重定向了但日报就是没来。去查日志发现是空的——说明脚本压根没被执行。原因通常有两个一是 cron 服务本身没启动二是路径写错了。排查方法很简单先确认 cron 服务状态再手动执行一遍脚本看能不能跑通。如果手动能跑、cron 不能跑那基本就是环境变量或者路径的问题。我的经验是在脚本第一行加一句日志输出比如echo 任务开始 $(date)这样只要 cron 触发了日志里一定有记录。有记录但没后续说明是脚本内部报错没记录说明是 cron 本身的问题。这一招能快速定位问题在哪一层。4.2 采集源突然失效日报变成空壳页面解析的采集方式最怕源站改版。我遇到过好几次早上十点半日报准时来了打开一看某个板块是空的。去查才发现那个站点的页面结构变了原来的选择器抓不到东西了。应对办法有两个一是加异常告警某个源抓取失败时日报里明确标注XX 源今日抓取失败而不是静默地留空二是定期巡检每周花几分钟看看各源的抓取量是否正常异常波动及时排查。# 抓取失败时的处理示意 try: items fetch_source(url) if not items: raise ValueError(抓取结果为空) except Exception as e: # 记录失败并在日报中标注 failed_sources.append(source_name) log_error(f{source_name} 抓取失败: {e})静默失败是最危险的因为它不会报错你只会觉得今天没什么新闻而实际上是抓取挂了。4.3 推送内容被截断重点信息丢失企业微信机器人对消息长度有限制日报太长会被截断。我第一次遇到时日报的后半部分直接没了还以为是生成环节出了问题。解决办法是控制日报长度或者分段推送。我现在把日报控制在 800 字以内重点突出反而比长篇大论更好读。如果内容实在多就拆成两条推送第一条是重点第二条是补充。4.4 密钥泄露的风险webhook 的 key、各种接口的 token这些都属于敏感信息。我见过有人图省事直接写在脚本里然后脚本传到 GitHub 上key 就泄露了。正确做法是用环境变量或者独立的配置文件并且把配置文件加入.gitignore。这是基本的安全意识别嫌麻烦。# 用环境变量管理密钥 export WECHAT_WEBHOOK_KEY你的key脚本里通过os.environ.get(WECHAT_WEBHOOK_KEY)读取这样即使脚本被看到key 也不会暴露。5. 让这套东西更耐用的几个进阶思路基础版跑通之后可以往上加东西。但记住一个原则每次只加一个功能加完稳定运行一周再加下一个。贪多嚼不烂。5.1 给日报加记忆避免重复推送如果某个新闻昨天推过了今天又推体验会很差。可以维护一个已推送的记录生成日报前先过滤掉已经出现过的内容。实现方式很简单用一个文件记录最近几天推送过的标题指纹生成时比对一下就行。这个功能加上之后日报的新鲜度会明显提升。5.2 按主题分频道推送如果你关注的面比较广可以把日报拆成几个频道比如模型动态工具更新行业新闻分别推送到不同的群或者用不同的标题区分。这样阅读时能快速定位到自己关心的部分。5.3 加一个周末特别版工作日和周末的信息节奏不一样周末可以做个特别版比如本周回顾把一周的重点串起来。这个思路我是从一个做 newsletter 的朋友那学来的效果不错。5.4 把日报沉淀成可检索的档案每天推送完把日报存一份到本地或者笔记软件里时间长了就是一个可检索的知识库。哪天想找上个月那个新模型叫啥来着搜一下就有了。这个习惯我坚持了几个月回头查资料的时候特别省事。6. 关于这套方案我最后想说的几句实在话这套闹钟 WorkBuddy 微信的组合技术上没什么高深的核心就是把重复的信息整理工作交给机器把自己解放出来。它不完美采集源会失效指令要反复调推送偶尔出问题但整体上它每天帮我省下的那二十分钟以及那份信息不会漏的安心感是实实在在的。如果你也想搭一套我的建议是先跑通最小闭环再谈优化。别一上来就想着做得多完美先用最简单的源、最朴素的指令、最直接的推送方式让它先跑起来。跑起来之后你自然知道哪里该改。还有一点别把它当成一个项目来做把它当成一个习惯来养。项目有完成的一天习惯是每天都要维护的。源失效了就修指令不好用就调推送出问题就查。这套东西的价值恰恰在于它日复一日的稳定运行而不是某一天搭得多么惊艳。我现在的状态是每天早上十点半手机震一下日报到了。我花五分钟扫一遍把值得深挖的几条标记出来剩下的划过去。整个过程行云流水几乎不占用我的注意力。这大概就是自动化最好的样子——你感觉不到它的存在但它一直在为你工作。
