1. 一份“每日晨报”到底在解决什么问题每天早上七点半我手机里会准时弹出一条自己给自己发的消息标题格式固定是“每日晨报 · 某年某月某日周几”。这个习惯我坚持了快两年中间断过几次最长的一次停了将近一个月后来还是捡回来了。原因很简单没有这份晨报的日子我打开手机的第一件事就是被各种推送牵着走刷完一圈下来脑子是满的但真正需要处理的事情一件没动。这份晨报本质上是一个个人信息聚合与预处理系统。它把分散在不同来源的信息——日程安排、待办事项、天气、行业动态、关注的几个数据指标——在每天固定时间抓取、清洗、排序然后以一条结构化消息的形式推送到我面前。它解决的核心问题不是“信息获取”信息早就不缺了缺的是在正确的时间以正确的顺序看到正确的那几条。适合谁来参考这套做法三类人最合适。第一类是每天需要处理多线程事务的人比如同时跟进几个项目的开发者、需要协调多方进度的产品经理、自己管自己节奏的自由职业者。第二类是对信息摄入有洁癖、不想被算法推荐喂养的人希望自己定义“什么值得看”。第三类是把自动化当乐趣、愿意花一个周末搭一套一劳永逸工具的人。如果你属于“每天早上醒来先刷半小时手机然后懊恼”的类型这套东西值得你花时间搭一次。我搭这套系统的原则只有一条晨报是给人看的不是给机器看的。所以它必须短、必须准、必须在我还没完全清醒的时候也能一眼扫完。下面我把整个设计思路、技术选型、实操步骤和踩过的坑完整拆一遍。2. 整体架构设计与技术选型思路2.1 为什么选择“定时任务 多源聚合 单条推送”的架构市面上做信息聚合的方案大致三种。第一种是RSS阅读器优点是成熟稳定缺点是它只解决“订阅源”这一种信息类型日程、待办、自定义指标它管不了而且你得主动打开App去看不符合“推送到面前”的需求。第二种是低代码自动化平台拖拖拽拽就能连各种服务上手快但免费额度有限、复杂逻辑表达吃力、数据经过第三方。第三种就是自己写脚本加定时任务灵活度最高但需要一点动手能力。我选的是第三种理由有三个。第一数据主权。晨报里会有我的日程和待办这些内容我不希望经过任何第三方平台的服务器。第二逻辑可控。比如“如果今天有超过三个会议就把行业动态压缩到两条”这种条件逻辑在低代码平台上要绕很大一圈在代码里就是几行判断。第三成本。一台最基础的云主机或者家里一台常开的迷你主机就够跑边际成本几乎为零。整个架构分四层数据源层、抓取清洗层、组装渲染层、推送层。数据源层是各种API和本地文件抓取清洗层负责把不同格式的数据统一成内部结构组装渲染层按优先级和模板拼成最终文本推送层负责在固定时间把消息发出去。四层之间用简单的函数调用串联不引入消息队列之类的重组件因为每天只跑一次没必要。2.2 推送渠道的选择为什么最终落在“自己给自己发消息”推送渠道我试过好几种。邮件的问题是打开率低早上根本不想点开邮箱。系统通知的问题是容易被淹没而且手机端和电脑端不同步。短信成本高且格式受限。最后我选的是一个支持机器人消息的即时通讯工具自己建一个只有自己的群机器人每天定时往里发。这个选择的关键考量是触达确定性。即时通讯工具的消息推送在手机上的到达率是最高的而且已读未读状态清晰。自己建群的好处是消息不会混在别人的对话里翻历史记录也方便。机器人消息支持Markdown格式加粗、列表、链接都能正常渲染排版可控。如果你不想用即时通讯工具退而求其次可以用系统自带的提醒事项或者日历事件把晨报内容塞进事件描述里但排版能力会差很多。提示推送渠道的选择标准只有一个——你每天早上第一眼会看哪个App。晨报发到你不会看的地方等于没发。2.3 时间调度的细节为什么是七点半而不是七点定时任务的触发时间我调过好几次。最早设的是早上六点半结果发现那个点我还没醒消息推来之后在通知栏躺着等我真正起床时已经被其他推送压下去了。后来改到八点又太晚出门路上才看到来不及根据晨报调整当天的安排。最终定在七点半是我平均起床时间前十五分钟。这个提前量的作用是消息到达时我可能刚醒扫一眼手机就能对今天有个全局认知然后起床洗漱时脑子里已经在排优先级了。定时任务的实现方式取决于你跑脚本的环境Linux上用cronWindows上用任务计划程序如果跑在容器里可以用宿主机的调度或者容器编排自带的定时能力。关键是时区要设对我有一次换了服务器忘记改时区晨报在凌晨三点推过来直接被静音了。2.4 数据源清单与优先级排序晨报的内容不是越多越好我最终保留的数据源经过了好几轮删减。目前稳定在六个来源按在晨报中出现的优先级排列优先级数据源内容类型更新频率1日历服务API当日日程实时2待办清单本地文件未完成任务手动维护3天气服务API天气与温度每小时4行业资讯RSS精选动态每日5自定义指标接口关键数据每日6本地备忘文件临时提醒手动维护优先级决定了渲染顺序也决定了内容超长时的截断策略。日历和待办永远完整展示天气一行带过行业资讯最多三条自定义指标最多五条备忘只在有内容时出现。这个排序逻辑背后是注意力预算的概念早上刚醒时能处理的信息量有限必须把最重要的放在最前面次要的放在后面甚至砍掉。3. 核心模块拆解与实操要点3.1 日历数据的抓取与格式化日历是晨报的骨架。我用的日历服务提供了标准的API接口通过授权令牌可以读取指定日历在指定时间范围内的所有事件。这里有几个实操细节值得展开。第一个是时间窗口的确定。晨报展示的是“今天”的日程但“今天”的边界不是自然日的零点到二十四点。我的处理方式是取当天零点到次日凌晨两点这样晚上十一点开始的跨夜事件也能被包含进来。如果严格按自然日切跨夜事件会被漏掉。第二个是全天事件的特殊处理。日历里的全天事件比如某人的生日、某个截止日期没有具体时间在排序时应该放在最前面因为它们代表的是当天的背景信息而非具体安排。我在代码里给全天事件设了一个特殊的排序权重确保它们出现在时间轴事件之前。第三个是冲突检测。如果两个事件时间重叠晨报里应该给出提示。实现方式是把所有事件按开始时间排序然后两两比较结束时间和开始时间。这个逻辑不复杂但很实用我有好几次就是因为晨报提示“十点和十点半两个会议重叠”才提前做了调整。# 日历事件抓取与格式化的核心逻辑示意 def fetch_calendar_events(date): start date.strftime(%Y-%m-%dT00:00:00) end (date timedelta(days1)).strftime(%Y-%m-%dT02:00:00) events calendar_api.list_events(calendar_id, start, end) formatted [] for ev in events: if ev.is_all_day: formatted.append({type: allday, title: ev.summary, weight: 0}) else: formatted.append({ type: timed, title: ev.summary, start: ev.start, end: ev.end, weight: 1 }) return sorted(formatted, keylambda x: (x[weight], x.get(start, )))注意日历API的授权令牌通常有有效期需要实现自动刷新逻辑。我踩过的坑是令牌过期后脚本静默失败晨报里日历部分空白了好几天才发现。建议在脚本里加一个“数据源健康检查”某个源返回空值时在晨报末尾标注异常。3.2 待办清单的本地化管理待办清单我没有用任何在线服务就是一个本地Markdown文件。格式很简单每行一个任务用方括号标记状态比如- [ ] 写周报表示未完成- [x] 回复邮件表示已完成。脚本读取这个文件把所有未完成的任务提取出来放进晨报。为什么用本地文件而不是待办App因为编辑成本最低。我在电脑前想到什么直接打开文件敲一行就行不需要打开App、点新建、选清单、设日期。而且Markdown文件可以用Git做版本管理哪天误删了还能找回来。缺点是手机端编辑不方便但我的待办主要是在电脑前产生的这个缺点可以接受。待办在晨报里的展示有个技巧按添加时间倒序排列。最新的任务放在最前面因为刚添加的任务通常最紧急或者最容易忘记。老任务排在后面如果连续多天出现说明它在被拖延晨报里看到它反复出现本身就是一种提醒。3.3 天气信息的精简呈现天气数据来自一个公开的天气API免费额度足够个人使用。晨报里天气只占一行格式是“天气状况 温度范围 降水概率”。比如“多云 18-26度 降水概率20%”。如果降水概率超过50%会在行尾加一个“带伞”的提示。这里的关键是不要展示太多天气细节。湿度、风速、紫外线指数这些信息在晨报场景下是噪音。早上需要知道的只有三件事要不要带伞、穿多厚、适不适合户外活动。温度范围告诉你穿什么降水概率告诉你带不带伞天气状况告诉你适不适合跑步。其他都是多余的。天气API的调用要注意缓存策略。我设的是每天早上六点抓一次如果抓取失败就用前一天的数据并在晨报里标注“天气数据可能过期”。不要每次渲染晨报时都去调API那样既慢又浪费额度。3.4 行业资讯的筛选与截断行业资讯来自几个RSS源脚本抓取最近24小时内的新文章按发布时间排序取前三条。筛选逻辑有两个一是关键词过滤只保留标题或摘要里包含我关注领域关键词的文章二是来源权重某些高质量源的文章优先展示。三条的限制是硬性的。我试过展示五条结果晨报太长扫读时间从三十秒变成两分钟反而降低了打开意愿。三条是一个刚好能扫完又不至于遗漏太多的数量。如果当天确实有很多重要动态我会在周末单独做一次深度阅读而不是塞进晨报。RSS抓取有个常见问题是编码混乱。不同源的XML文件编码格式不一样有的用UTF-8有的用GBK直接解析会出乱码。我的处理方式是先用二进制读取检测编码后再解码统一转成UTF-8再解析。这个坑我踩过好几次晨报里出现乱码非常影响阅读体验。3.5 自定义指标的接入方式自定义指标是我晨报里最个性化的部分。目前接入了三个一个是我的个人项目仓库的未关闭议题数量一个是某个我关注的数据接口的最新数值一个是我的阅读清单里未读书籍的数量。这些数据通过各自的API获取格式化成一行文字。接入自定义指标的关键是定义好“异常阈值”。比如未关闭议题数量超过二十个时晨报里会用加粗标注提醒我该清理了。未读书籍超过十本时也会标注。这种阈值提醒比单纯展示数字有用得多它把数据变成了行动信号。提示自定义指标不要超过五个。每增加一个指标晨报的认知负担就增加一分。只保留那些你看到数字变化后会真正采取行动的项目。3.6 备忘文件的触发式展示备忘文件是一个本地文本文件里面放的是临时性的提醒比如“今天下午记得取快递”“明天要交电费”。脚本读取这个文件如果内容不为空就展示在晨报末尾为空则整段省略。这个模块的设计意图是给晨报留一个手动干预的入口。自动化系统再完善也有它覆盖不到的临时事项。备忘文件让我可以在任何时候往里面加一行第二天早上就会出现在晨报里。用完即删不会积累成新的信息负担。备忘文件的读取要注意空行和注释的处理。我约定以#开头的行是注释不展示空行跳过。这样我可以在文件里留一些长期备注而不影响晨报内容。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装整套系统跑在一台常开的迷你主机上系统是Linux。需要的运行环境包括Python 3.9以上、几个HTTP请求库、一个XML解析库、一个模板引擎。依赖不多用pip一次性装好。# 创建虚拟环境并安装依赖 python3 -m venv morning-report-env source morning-report-env/bin/activate pip install requests feedparser jinja2 python-dateutil虚拟环境的作用是隔离依赖避免和系统里其他Python项目冲突。我一开始图省事直接装在系统环境里后来升级某个库导致另一个脚本挂掉才老老实实用了虚拟环境。目录结构我组织成这样morning-report/ ├── config/ │ ├── sources.yaml # 数据源配置 │ └── template.j2 # 晨报模板 ├── data/ │ ├── todo.md # 待办清单 │ └── memo.txt # 备忘文件 ├── scripts/ │ ├── fetch_calendar.py │ ├── fetch_weather.py │ ├── fetch_feeds.py │ ├── fetch_metrics.py │ └── render.py ├── output/ │ └── latest.md # 最新晨报 └── run.sh # 入口脚本配置和数据分离的好处是改数据源不用动代码改代码不会误伤数据。sources.yaml里存的是各个API的地址、密钥、参数template.j2里存的是晨报的排版模板。4.2 数据抓取脚本的编写要点每个数据源一个独立的抓取脚本输出统一格式的字典。这样做的好处是某个源出问题时不影响其他源而且方便单独测试。以天气抓取为例# fetch_weather.py 核心逻辑 import requests from datetime import date def fetch_weather(city_code, api_key): url fhttps://api.example.com/weather params { city: city_code, key: api_key, date: date.today().isoformat() } try: resp requests.get(url, paramsparams, timeout10) resp.raise_for_status() data resp.json() return { status: ok, condition: data[condition], temp_low: data[temp_min], temp_high: data[temp_max], rain_prob: data[precip_prob] } except Exception as e: return {status: error, message: str(e)}每个抓取函数都返回一个带status字段的字典ok表示成功error表示失败并附带错误信息。渲染层根据status决定是展示数据还是展示错误提示。这种设计让局部失败不会导致整体崩溃晨报里某个板块显示“数据获取失败”总比整条晨报发不出来要好。超时设置是必须的。我有一次某个API响应极慢脚本卡在那里等了将近一分钟导致晨报推送延迟。后来所有请求都加了timeout10超过十秒直接放弃用缓存数据或错误提示代替。4.3 模板渲染与排版控制晨报的最终文本用Jinja2模板渲染。模板里定义了各个板块的顺序和格式数据以变量的形式注入。这样做的好处是调整排版不用改Python代码改模板文件就行。# template.j2 简化示意 **{{ date_str }} 晨报** {% if calendar.events %} **今日日程** {% for ev in calendar.events %} - {{ ev.time }} {{ ev.title }} {% endfor %} {% endif %} {% if weather.status ok %} **天气** {{ weather.condition }} {{ weather.temp_low }}-{{ weather.temp_high }}度 降水概率{{ weather.rain_prob }}% {% endif %} {% if todos %} **待办** {% for t in todos %} - [ ] {{ t }} {% endfor %} {% endif %}排版上有几个细节我调了很久。第一板块之间用空行分隔但不要用分割线分割线在手机通知栏里显示效果很差。第二加粗只用在板块标题上正文不加粗否则满屏都是重点等于没有重点。第三列表项不要超过一行超过一行的内容要么截断要么换行缩进保持视觉整齐。4.4 推送环节的实现与容错推送用的是即时通讯工具的机器人接口本质上就是一个HTTP POST请求把渲染好的文本发到指定的群组。实现很简单但容错要做好。# push.py 核心逻辑 def push_message(webhook_url, content): payload {msgtype: markdown, markdown: {content: content}} for attempt in range(3): try: resp requests.post(webhook_url, jsonpayload, timeout10) if resp.status_code 200: return True except Exception: time.sleep(5) return False重试三次每次间隔五秒。如果三次都失败脚本会把晨报内容写入本地文件并在日志里记录不会静默丢失。我有一次网络波动导致推送失败因为没做重试那天早上就没收到晨报后来加了重试逻辑再没出现过。推送时间由cron控制crontab配置如下# 每天早上7:30执行 30 7 * * * /home/user/morning-report/run.sh /home/user/morning-report/logs/cron.log 21日志重定向很重要脚本运行时的输出都写到日志文件里出问题时可以回溯。日志文件我设了自动轮转每周清理一次避免占满磁盘。4.5 入口脚本的串联逻辑run.sh是整个系统的入口负责按顺序调用各个模块#!/bin/bash cd /home/user/morning-report source morning-report-env/bin/activate python scripts/fetch_calendar.py python scripts/fetch_weather.py python scripts/fetch_feeds.py python scripts/fetch_metrics.py python scripts/render.py python scripts/push.py每个脚本把结果写入output/目录下的中间文件下一个脚本读取。这种文件传递的方式比内存传递慢一点但好处是每一步的中间结果都可以检查。如果晨报内容不对我可以逐个文件看是哪个环节出了问题。注意脚本执行顺序有依赖关系render.py必须在所有fetch脚本之后执行push.py必须在render.py之后执行。如果某个fetch脚本失败render脚本要能处理缺失的数据而不是直接报错退出。5. 常见问题与排查技巧实录5.1 晨报内容为空或部分缺失这是最常见的问题表现是晨报正常推送但某个板块没有内容。排查思路是从后往前查。先看output/目录下的中间文件确认是抓取阶段就没拿到数据还是渲染阶段没渲染出来。如果是抓取阶段的问题常见原因有三个API密钥过期、网络请求超时、返回数据格式变化。API密钥过期最隐蔽因为脚本不会报错只是返回空数据。我的做法是在每个抓取脚本里加一个“空数据告警”如果连续两天某个源返回空值就在晨报末尾标注提醒。如果是渲染阶段的问题通常是模板变量名和数据结构不匹配。比如抓取脚本返回的是temp_high模板里写的是temp_max渲染出来就是空白。这种问题在修改代码后容易出现解决办法是每次改完代码手动跑一次渲染检查输出。5.2 推送成功但手机没收到通知这个问题我遇到过两次排查下来原因不同。第一次是即时通讯工具的机器人被移出了群组推送接口返回成功但消息实际没发出去。第二次是手机的通知权限被系统更新重置了消息到了但没弹通知。排查方法是先确认消息是否到达。打开即时通讯工具看群里有没有消息有消息说明推送成功问题在手机通知设置没消息说明推送环节有问题检查机器人是否还在群里、webhook地址是否有效。提示建议在晨报推送成功后脚本再发一条极简的确认消息比如一个句号如果连确认消息都没收到说明推送链路断了。5.3 定时任务没有按时执行cron任务不执行的原因通常有三个脚本没有执行权限、环境变量缺失、cron服务本身没运行。第一个最好排查chmod x run.sh就行。第二个比较隐蔽cron执行时的环境变量和登录shell不一样脚本里用到的命令可能找不到。解决办法是在脚本开头显式设置PATH或者用绝对路径调用命令。第三个原因我遇到过一次服务器重启后cron服务没有自动启动。后来加了一个开机自启的配置并且每周检查一次cron日志确认任务正常执行。5.4 晨报内容过长导致阅读体验下降内容过长通常是因为某个数据源返回了大量条目。比如RSS源某天更新了五十篇文章如果不过滤直接展示晨报会变成一篇长文。解决办法是在抓取阶段就做数量截断每个源最多取N条N的值根据板块重要性设定。另一个原因是待办清单积累太多未完成任务。如果待办超过十五条晨报会变得很长。我的处理方式是待办超过十条时只展示最新的十条并在末尾标注“另有X条未展示”。这样既控制了长度又不会让用户误以为待办只有十条。5.5 常见问题速查表问题现象可能原因排查方法解决方式某板块空白API密钥过期检查抓取脚本日志更新密钥某板块空白数据结构变化对比API返回与代码预期修改解析逻辑推送成功但没收到机器人被移出群组检查群成员列表重新添加机器人推送成功但没收到手机通知权限关闭检查系统通知设置重新开启权限定时任务没执行脚本无执行权限ls -l run.shchmod x定时任务没执行cron服务未运行systemctl status cron启动并设自启晨报内容过长数据源条目过多检查各源返回数量增加截断逻辑晨报乱码编码不一致检查原始数据编码统一转UTF-85.6 几个让我少走弯路的实操心得第一个心得是先跑通再优化。我一开始想把所有功能都做完美再上线结果拖了两周都没跑起来。后来改变策略先用最简陋的方式把“日历天气推送”这条链路跑通第二天早上就收到了第一份晨报虽然只有两行内容但那种“它真的在工作”的正反馈让我有动力继续加功能。第二个心得是每个数据源单独测试。不要等整个系统跑起来才发现某个源有问题。每写一个抓取脚本就单独运行一次确认输出格式正确再接入主流程。这样出问题时排查范围小很多。第三个心得是晨报内容宁少勿多。我删掉过好几个数据源原因都是“看了但不会采取行动”。判断标准很简单如果某条信息连续一周出现在晨报里但你从没因为它改变过任何行为那它就不该出现在晨报里。晨报的价值在于驱动行动不在于信息全面。第四个心得是保留手动干预的入口。自动化再完善也有覆盖不到的情况备忘文件就是我的手动入口。有时候我需要在晨报里加一句话提醒自己直接往备忘文件里写一行就行不用改代码。这个设计让系统保持了灵活性。第五个心得是定期回顾晨报本身。我每个月会翻一次过去三十天的晨报看看哪些板块从来没被认真看过哪些板块经常触发行动。然后据此调整数据源和优先级。晨报系统不是搭完就固定的它需要随着你的生活节奏一起演化。6. 这套系统的扩展方向与个人体会这套晨报系统跑到现在已经成了我每天早上离不开的东西。它的核心价值不在于技术多复杂而在于把“决定早上看什么”这件事从手动变成了自动。以前我每天早上要在好几个App之间切换现在一条消息搞定。后续可以扩展的方向有几个。一是增加周报模式每周日晚上推送一份本周回顾汇总本周完成的任务、未完成的任务、重要日程的分布。二是增加交互能力比如在晨报里直接回复某个数字就能标记待办完成不过这需要推送渠道支持回调实现复杂度会高一些。三是引入简单的优先级算法根据任务的截止日期、关联项目、历史拖延次数自动排序而不是简单地按添加时间倒序。我个人在实际操作中的体会是做这类个人自动化工具最大的成本不是写代码而是想清楚自己到底需要什么。我见过不少人搭了很复杂的系统接了几十个数据源最后因为信息过载反而不用了。晨报的本质是做减法是帮你把噪音过滤掉只留下真正重要的那几条。所以每次想加新功能时我都会先问自己这个功能会让晨报变短还是变长如果变长那就要慎重。最后分享一个小技巧晨报的标题格式里带上星期几看起来是小事但很实用。因为人对“周四”的感知比对“十月八日”强得多看到周四就知道这周还剩两天紧迫感自然就来了。这种细节上的用心才是让一个工具真正融入日常生活的关键。
1. 一份“每日晨报”到底在解决什么问题每天早上七点半我手机里会准时弹出一条自己给自己发的消息标题格式固定是“每日晨报 · 某年某月某日周几”。这个习惯我坚持了快两年中间断过几次最长的一次停了将近一个月后来还是捡回来了。原因很简单没有这份晨报的日子我打开手机的第一件事就是被各种推送牵着走刷完一圈下来脑子是满的但真正需要处理的事情一件没动。这份晨报本质上是一个个人信息聚合与预处理系统。它把分散在不同来源的信息——日程安排、待办事项、天气、行业动态、关注的几个数据指标——在每天固定时间抓取、清洗、排序然后以一条结构化消息的形式推送到我面前。它解决的核心问题不是“信息获取”信息早就不缺了缺的是在正确的时间以正确的顺序看到正确的那几条。适合谁来参考这套做法三类人最合适。第一类是每天需要处理多线程事务的人比如同时跟进几个项目的开发者、需要协调多方进度的产品经理、自己管自己节奏的自由职业者。第二类是对信息摄入有洁癖、不想被算法推荐喂养的人希望自己定义“什么值得看”。第三类是把自动化当乐趣、愿意花一个周末搭一套一劳永逸工具的人。如果你属于“每天早上醒来先刷半小时手机然后懊恼”的类型这套东西值得你花时间搭一次。我搭这套系统的原则只有一条晨报是给人看的不是给机器看的。所以它必须短、必须准、必须在我还没完全清醒的时候也能一眼扫完。下面我把整个设计思路、技术选型、实操步骤和踩过的坑完整拆一遍。2. 整体架构设计与技术选型思路2.1 为什么选择“定时任务 多源聚合 单条推送”的架构市面上做信息聚合的方案大致三种。第一种是RSS阅读器优点是成熟稳定缺点是它只解决“订阅源”这一种信息类型日程、待办、自定义指标它管不了而且你得主动打开App去看不符合“推送到面前”的需求。第二种是低代码自动化平台拖拖拽拽就能连各种服务上手快但免费额度有限、复杂逻辑表达吃力、数据经过第三方。第三种就是自己写脚本加定时任务灵活度最高但需要一点动手能力。我选的是第三种理由有三个。第一数据主权。晨报里会有我的日程和待办这些内容我不希望经过任何第三方平台的服务器。第二逻辑可控。比如“如果今天有超过三个会议就把行业动态压缩到两条”这种条件逻辑在低代码平台上要绕很大一圈在代码里就是几行判断。第三成本。一台最基础的云主机或者家里一台常开的迷你主机就够跑边际成本几乎为零。整个架构分四层数据源层、抓取清洗层、组装渲染层、推送层。数据源层是各种API和本地文件抓取清洗层负责把不同格式的数据统一成内部结构组装渲染层按优先级和模板拼成最终文本推送层负责在固定时间把消息发出去。四层之间用简单的函数调用串联不引入消息队列之类的重组件因为每天只跑一次没必要。2.2 推送渠道的选择为什么最终落在“自己给自己发消息”推送渠道我试过好几种。邮件的问题是打开率低早上根本不想点开邮箱。系统通知的问题是容易被淹没而且手机端和电脑端不同步。短信成本高且格式受限。最后我选的是一个支持机器人消息的即时通讯工具自己建一个只有自己的群机器人每天定时往里发。这个选择的关键考量是触达确定性。即时通讯工具的消息推送在手机上的到达率是最高的而且已读未读状态清晰。自己建群的好处是消息不会混在别人的对话里翻历史记录也方便。机器人消息支持Markdown格式加粗、列表、链接都能正常渲染排版可控。如果你不想用即时通讯工具退而求其次可以用系统自带的提醒事项或者日历事件把晨报内容塞进事件描述里但排版能力会差很多。提示推送渠道的选择标准只有一个——你每天早上第一眼会看哪个App。晨报发到你不会看的地方等于没发。2.3 时间调度的细节为什么是七点半而不是七点定时任务的触发时间我调过好几次。最早设的是早上六点半结果发现那个点我还没醒消息推来之后在通知栏躺着等我真正起床时已经被其他推送压下去了。后来改到八点又太晚出门路上才看到来不及根据晨报调整当天的安排。最终定在七点半是我平均起床时间前十五分钟。这个提前量的作用是消息到达时我可能刚醒扫一眼手机就能对今天有个全局认知然后起床洗漱时脑子里已经在排优先级了。定时任务的实现方式取决于你跑脚本的环境Linux上用cronWindows上用任务计划程序如果跑在容器里可以用宿主机的调度或者容器编排自带的定时能力。关键是时区要设对我有一次换了服务器忘记改时区晨报在凌晨三点推过来直接被静音了。2.4 数据源清单与优先级排序晨报的内容不是越多越好我最终保留的数据源经过了好几轮删减。目前稳定在六个来源按在晨报中出现的优先级排列优先级数据源内容类型更新频率1日历服务API当日日程实时2待办清单本地文件未完成任务手动维护3天气服务API天气与温度每小时4行业资讯RSS精选动态每日5自定义指标接口关键数据每日6本地备忘文件临时提醒手动维护优先级决定了渲染顺序也决定了内容超长时的截断策略。日历和待办永远完整展示天气一行带过行业资讯最多三条自定义指标最多五条备忘只在有内容时出现。这个排序逻辑背后是注意力预算的概念早上刚醒时能处理的信息量有限必须把最重要的放在最前面次要的放在后面甚至砍掉。3. 核心模块拆解与实操要点3.1 日历数据的抓取与格式化日历是晨报的骨架。我用的日历服务提供了标准的API接口通过授权令牌可以读取指定日历在指定时间范围内的所有事件。这里有几个实操细节值得展开。第一个是时间窗口的确定。晨报展示的是“今天”的日程但“今天”的边界不是自然日的零点到二十四点。我的处理方式是取当天零点到次日凌晨两点这样晚上十一点开始的跨夜事件也能被包含进来。如果严格按自然日切跨夜事件会被漏掉。第二个是全天事件的特殊处理。日历里的全天事件比如某人的生日、某个截止日期没有具体时间在排序时应该放在最前面因为它们代表的是当天的背景信息而非具体安排。我在代码里给全天事件设了一个特殊的排序权重确保它们出现在时间轴事件之前。第三个是冲突检测。如果两个事件时间重叠晨报里应该给出提示。实现方式是把所有事件按开始时间排序然后两两比较结束时间和开始时间。这个逻辑不复杂但很实用我有好几次就是因为晨报提示“十点和十点半两个会议重叠”才提前做了调整。# 日历事件抓取与格式化的核心逻辑示意 def fetch_calendar_events(date): start date.strftime(%Y-%m-%dT00:00:00) end (date timedelta(days1)).strftime(%Y-%m-%dT02:00:00) events calendar_api.list_events(calendar_id, start, end) formatted [] for ev in events: if ev.is_all_day: formatted.append({type: allday, title: ev.summary, weight: 0}) else: formatted.append({ type: timed, title: ev.summary, start: ev.start, end: ev.end, weight: 1 }) return sorted(formatted, keylambda x: (x[weight], x.get(start, )))注意日历API的授权令牌通常有有效期需要实现自动刷新逻辑。我踩过的坑是令牌过期后脚本静默失败晨报里日历部分空白了好几天才发现。建议在脚本里加一个“数据源健康检查”某个源返回空值时在晨报末尾标注异常。3.2 待办清单的本地化管理待办清单我没有用任何在线服务就是一个本地Markdown文件。格式很简单每行一个任务用方括号标记状态比如- [ ] 写周报表示未完成- [x] 回复邮件表示已完成。脚本读取这个文件把所有未完成的任务提取出来放进晨报。为什么用本地文件而不是待办App因为编辑成本最低。我在电脑前想到什么直接打开文件敲一行就行不需要打开App、点新建、选清单、设日期。而且Markdown文件可以用Git做版本管理哪天误删了还能找回来。缺点是手机端编辑不方便但我的待办主要是在电脑前产生的这个缺点可以接受。待办在晨报里的展示有个技巧按添加时间倒序排列。最新的任务放在最前面因为刚添加的任务通常最紧急或者最容易忘记。老任务排在后面如果连续多天出现说明它在被拖延晨报里看到它反复出现本身就是一种提醒。3.3 天气信息的精简呈现天气数据来自一个公开的天气API免费额度足够个人使用。晨报里天气只占一行格式是“天气状况 温度范围 降水概率”。比如“多云 18-26度 降水概率20%”。如果降水概率超过50%会在行尾加一个“带伞”的提示。这里的关键是不要展示太多天气细节。湿度、风速、紫外线指数这些信息在晨报场景下是噪音。早上需要知道的只有三件事要不要带伞、穿多厚、适不适合户外活动。温度范围告诉你穿什么降水概率告诉你带不带伞天气状况告诉你适不适合跑步。其他都是多余的。天气API的调用要注意缓存策略。我设的是每天早上六点抓一次如果抓取失败就用前一天的数据并在晨报里标注“天气数据可能过期”。不要每次渲染晨报时都去调API那样既慢又浪费额度。3.4 行业资讯的筛选与截断行业资讯来自几个RSS源脚本抓取最近24小时内的新文章按发布时间排序取前三条。筛选逻辑有两个一是关键词过滤只保留标题或摘要里包含我关注领域关键词的文章二是来源权重某些高质量源的文章优先展示。三条的限制是硬性的。我试过展示五条结果晨报太长扫读时间从三十秒变成两分钟反而降低了打开意愿。三条是一个刚好能扫完又不至于遗漏太多的数量。如果当天确实有很多重要动态我会在周末单独做一次深度阅读而不是塞进晨报。RSS抓取有个常见问题是编码混乱。不同源的XML文件编码格式不一样有的用UTF-8有的用GBK直接解析会出乱码。我的处理方式是先用二进制读取检测编码后再解码统一转成UTF-8再解析。这个坑我踩过好几次晨报里出现乱码非常影响阅读体验。3.5 自定义指标的接入方式自定义指标是我晨报里最个性化的部分。目前接入了三个一个是我的个人项目仓库的未关闭议题数量一个是某个我关注的数据接口的最新数值一个是我的阅读清单里未读书籍的数量。这些数据通过各自的API获取格式化成一行文字。接入自定义指标的关键是定义好“异常阈值”。比如未关闭议题数量超过二十个时晨报里会用加粗标注提醒我该清理了。未读书籍超过十本时也会标注。这种阈值提醒比单纯展示数字有用得多它把数据变成了行动信号。提示自定义指标不要超过五个。每增加一个指标晨报的认知负担就增加一分。只保留那些你看到数字变化后会真正采取行动的项目。3.6 备忘文件的触发式展示备忘文件是一个本地文本文件里面放的是临时性的提醒比如“今天下午记得取快递”“明天要交电费”。脚本读取这个文件如果内容不为空就展示在晨报末尾为空则整段省略。这个模块的设计意图是给晨报留一个手动干预的入口。自动化系统再完善也有它覆盖不到的临时事项。备忘文件让我可以在任何时候往里面加一行第二天早上就会出现在晨报里。用完即删不会积累成新的信息负担。备忘文件的读取要注意空行和注释的处理。我约定以#开头的行是注释不展示空行跳过。这样我可以在文件里留一些长期备注而不影响晨报内容。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装整套系统跑在一台常开的迷你主机上系统是Linux。需要的运行环境包括Python 3.9以上、几个HTTP请求库、一个XML解析库、一个模板引擎。依赖不多用pip一次性装好。# 创建虚拟环境并安装依赖 python3 -m venv morning-report-env source morning-report-env/bin/activate pip install requests feedparser jinja2 python-dateutil虚拟环境的作用是隔离依赖避免和系统里其他Python项目冲突。我一开始图省事直接装在系统环境里后来升级某个库导致另一个脚本挂掉才老老实实用了虚拟环境。目录结构我组织成这样morning-report/ ├── config/ │ ├── sources.yaml # 数据源配置 │ └── template.j2 # 晨报模板 ├── data/ │ ├── todo.md # 待办清单 │ └── memo.txt # 备忘文件 ├── scripts/ │ ├── fetch_calendar.py │ ├── fetch_weather.py │ ├── fetch_feeds.py │ ├── fetch_metrics.py │ └── render.py ├── output/ │ └── latest.md # 最新晨报 └── run.sh # 入口脚本配置和数据分离的好处是改数据源不用动代码改代码不会误伤数据。sources.yaml里存的是各个API的地址、密钥、参数template.j2里存的是晨报的排版模板。4.2 数据抓取脚本的编写要点每个数据源一个独立的抓取脚本输出统一格式的字典。这样做的好处是某个源出问题时不影响其他源而且方便单独测试。以天气抓取为例# fetch_weather.py 核心逻辑 import requests from datetime import date def fetch_weather(city_code, api_key): url fhttps://api.example.com/weather params { city: city_code, key: api_key, date: date.today().isoformat() } try: resp requests.get(url, paramsparams, timeout10) resp.raise_for_status() data resp.json() return { status: ok, condition: data[condition], temp_low: data[temp_min], temp_high: data[temp_max], rain_prob: data[precip_prob] } except Exception as e: return {status: error, message: str(e)}每个抓取函数都返回一个带status字段的字典ok表示成功error表示失败并附带错误信息。渲染层根据status决定是展示数据还是展示错误提示。这种设计让局部失败不会导致整体崩溃晨报里某个板块显示“数据获取失败”总比整条晨报发不出来要好。超时设置是必须的。我有一次某个API响应极慢脚本卡在那里等了将近一分钟导致晨报推送延迟。后来所有请求都加了timeout10超过十秒直接放弃用缓存数据或错误提示代替。4.3 模板渲染与排版控制晨报的最终文本用Jinja2模板渲染。模板里定义了各个板块的顺序和格式数据以变量的形式注入。这样做的好处是调整排版不用改Python代码改模板文件就行。# template.j2 简化示意 **{{ date_str }} 晨报** {% if calendar.events %} **今日日程** {% for ev in calendar.events %} - {{ ev.time }} {{ ev.title }} {% endfor %} {% endif %} {% if weather.status ok %} **天气** {{ weather.condition }} {{ weather.temp_low }}-{{ weather.temp_high }}度 降水概率{{ weather.rain_prob }}% {% endif %} {% if todos %} **待办** {% for t in todos %} - [ ] {{ t }} {% endfor %} {% endif %}排版上有几个细节我调了很久。第一板块之间用空行分隔但不要用分割线分割线在手机通知栏里显示效果很差。第二加粗只用在板块标题上正文不加粗否则满屏都是重点等于没有重点。第三列表项不要超过一行超过一行的内容要么截断要么换行缩进保持视觉整齐。4.4 推送环节的实现与容错推送用的是即时通讯工具的机器人接口本质上就是一个HTTP POST请求把渲染好的文本发到指定的群组。实现很简单但容错要做好。# push.py 核心逻辑 def push_message(webhook_url, content): payload {msgtype: markdown, markdown: {content: content}} for attempt in range(3): try: resp requests.post(webhook_url, jsonpayload, timeout10) if resp.status_code 200: return True except Exception: time.sleep(5) return False重试三次每次间隔五秒。如果三次都失败脚本会把晨报内容写入本地文件并在日志里记录不会静默丢失。我有一次网络波动导致推送失败因为没做重试那天早上就没收到晨报后来加了重试逻辑再没出现过。推送时间由cron控制crontab配置如下# 每天早上7:30执行 30 7 * * * /home/user/morning-report/run.sh /home/user/morning-report/logs/cron.log 21日志重定向很重要脚本运行时的输出都写到日志文件里出问题时可以回溯。日志文件我设了自动轮转每周清理一次避免占满磁盘。4.5 入口脚本的串联逻辑run.sh是整个系统的入口负责按顺序调用各个模块#!/bin/bash cd /home/user/morning-report source morning-report-env/bin/activate python scripts/fetch_calendar.py python scripts/fetch_weather.py python scripts/fetch_feeds.py python scripts/fetch_metrics.py python scripts/render.py python scripts/push.py每个脚本把结果写入output/目录下的中间文件下一个脚本读取。这种文件传递的方式比内存传递慢一点但好处是每一步的中间结果都可以检查。如果晨报内容不对我可以逐个文件看是哪个环节出了问题。注意脚本执行顺序有依赖关系render.py必须在所有fetch脚本之后执行push.py必须在render.py之后执行。如果某个fetch脚本失败render脚本要能处理缺失的数据而不是直接报错退出。5. 常见问题与排查技巧实录5.1 晨报内容为空或部分缺失这是最常见的问题表现是晨报正常推送但某个板块没有内容。排查思路是从后往前查。先看output/目录下的中间文件确认是抓取阶段就没拿到数据还是渲染阶段没渲染出来。如果是抓取阶段的问题常见原因有三个API密钥过期、网络请求超时、返回数据格式变化。API密钥过期最隐蔽因为脚本不会报错只是返回空数据。我的做法是在每个抓取脚本里加一个“空数据告警”如果连续两天某个源返回空值就在晨报末尾标注提醒。如果是渲染阶段的问题通常是模板变量名和数据结构不匹配。比如抓取脚本返回的是temp_high模板里写的是temp_max渲染出来就是空白。这种问题在修改代码后容易出现解决办法是每次改完代码手动跑一次渲染检查输出。5.2 推送成功但手机没收到通知这个问题我遇到过两次排查下来原因不同。第一次是即时通讯工具的机器人被移出了群组推送接口返回成功但消息实际没发出去。第二次是手机的通知权限被系统更新重置了消息到了但没弹通知。排查方法是先确认消息是否到达。打开即时通讯工具看群里有没有消息有消息说明推送成功问题在手机通知设置没消息说明推送环节有问题检查机器人是否还在群里、webhook地址是否有效。提示建议在晨报推送成功后脚本再发一条极简的确认消息比如一个句号如果连确认消息都没收到说明推送链路断了。5.3 定时任务没有按时执行cron任务不执行的原因通常有三个脚本没有执行权限、环境变量缺失、cron服务本身没运行。第一个最好排查chmod x run.sh就行。第二个比较隐蔽cron执行时的环境变量和登录shell不一样脚本里用到的命令可能找不到。解决办法是在脚本开头显式设置PATH或者用绝对路径调用命令。第三个原因我遇到过一次服务器重启后cron服务没有自动启动。后来加了一个开机自启的配置并且每周检查一次cron日志确认任务正常执行。5.4 晨报内容过长导致阅读体验下降内容过长通常是因为某个数据源返回了大量条目。比如RSS源某天更新了五十篇文章如果不过滤直接展示晨报会变成一篇长文。解决办法是在抓取阶段就做数量截断每个源最多取N条N的值根据板块重要性设定。另一个原因是待办清单积累太多未完成任务。如果待办超过十五条晨报会变得很长。我的处理方式是待办超过十条时只展示最新的十条并在末尾标注“另有X条未展示”。这样既控制了长度又不会让用户误以为待办只有十条。5.5 常见问题速查表问题现象可能原因排查方法解决方式某板块空白API密钥过期检查抓取脚本日志更新密钥某板块空白数据结构变化对比API返回与代码预期修改解析逻辑推送成功但没收到机器人被移出群组检查群成员列表重新添加机器人推送成功但没收到手机通知权限关闭检查系统通知设置重新开启权限定时任务没执行脚本无执行权限ls -l run.shchmod x定时任务没执行cron服务未运行systemctl status cron启动并设自启晨报内容过长数据源条目过多检查各源返回数量增加截断逻辑晨报乱码编码不一致检查原始数据编码统一转UTF-85.6 几个让我少走弯路的实操心得第一个心得是先跑通再优化。我一开始想把所有功能都做完美再上线结果拖了两周都没跑起来。后来改变策略先用最简陋的方式把“日历天气推送”这条链路跑通第二天早上就收到了第一份晨报虽然只有两行内容但那种“它真的在工作”的正反馈让我有动力继续加功能。第二个心得是每个数据源单独测试。不要等整个系统跑起来才发现某个源有问题。每写一个抓取脚本就单独运行一次确认输出格式正确再接入主流程。这样出问题时排查范围小很多。第三个心得是晨报内容宁少勿多。我删掉过好几个数据源原因都是“看了但不会采取行动”。判断标准很简单如果某条信息连续一周出现在晨报里但你从没因为它改变过任何行为那它就不该出现在晨报里。晨报的价值在于驱动行动不在于信息全面。第四个心得是保留手动干预的入口。自动化再完善也有覆盖不到的情况备忘文件就是我的手动入口。有时候我需要在晨报里加一句话提醒自己直接往备忘文件里写一行就行不用改代码。这个设计让系统保持了灵活性。第五个心得是定期回顾晨报本身。我每个月会翻一次过去三十天的晨报看看哪些板块从来没被认真看过哪些板块经常触发行动。然后据此调整数据源和优先级。晨报系统不是搭完就固定的它需要随着你的生活节奏一起演化。6. 这套系统的扩展方向与个人体会这套晨报系统跑到现在已经成了我每天早上离不开的东西。它的核心价值不在于技术多复杂而在于把“决定早上看什么”这件事从手动变成了自动。以前我每天早上要在好几个App之间切换现在一条消息搞定。后续可以扩展的方向有几个。一是增加周报模式每周日晚上推送一份本周回顾汇总本周完成的任务、未完成的任务、重要日程的分布。二是增加交互能力比如在晨报里直接回复某个数字就能标记待办完成不过这需要推送渠道支持回调实现复杂度会高一些。三是引入简单的优先级算法根据任务的截止日期、关联项目、历史拖延次数自动排序而不是简单地按添加时间倒序。我个人在实际操作中的体会是做这类个人自动化工具最大的成本不是写代码而是想清楚自己到底需要什么。我见过不少人搭了很复杂的系统接了几十个数据源最后因为信息过载反而不用了。晨报的本质是做减法是帮你把噪音过滤掉只留下真正重要的那几条。所以每次想加新功能时我都会先问自己这个功能会让晨报变短还是变长如果变长那就要慎重。最后分享一个小技巧晨报的标题格式里带上星期几看起来是小事但很实用。因为人对“周四”的感知比对“十月八日”强得多看到周四就知道这周还剩两天紧迫感自然就来了。这种细节上的用心才是让一个工具真正融入日常生活的关键。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
