1. 一份“每日晨报”到底在解决什么问题每天早上七点半我习惯性打开自己维护的一个小工具屏幕上会弹出一份排版干净的简报昨天圈子里发生了什么、有哪些值得点进去看的链接、今天有什么值得留意的节点。这份东西我管它叫“每日晨报”日期戳是 2026-10-08周四。听起来像是个新闻聚合器但实际做下来它更像是一套个人信息过滤系统——把每天铺天盖地的信息噪音压缩成一份十分钟能读完的、真正跟我相关的摘要。很多人第一反应是这不就是个 RSS 阅读器吗或者搞个爬虫抓热搜不就行了我一开始也这么想但真动手做了才发现难点根本不在“抓取”而在“筛选”和“呈现”。信息抓取这件事技术上早就没有门槛了随便一个脚本就能把几十个源的内容拉下来。真正让人头疼的是抓下来之后呢几百条内容堆在一起你根本不想看。所以这份晨报的核心价值是用一套可调优的规则把“全量信息”变成“有效信息”再用一种让人愿意读的方式呈现出来。它适合什么人我觉得有三类。第一类是像我这样每天需要快速了解行业动态的从业者不想被算法推荐牵着走又没时间一个个刷第二类是对自动化工具感兴趣、想拿一个真实项目练手的技术爱好者这个项目的复杂度刚好——不太简单也不至于劝退第三类是任何想建立自己信息输入习惯的人哪怕你不写代码理解这套筛选逻辑本身就有用。我做的这个版本从最初的一个 Python 脚本慢慢迭代到现在有了一套相对稳定的流程。中间踩过的坑不少比如源站反爬、内容去重误杀、摘要生成跑偏等等。下面我把整套东西拆开讲包括设计思路、关键实现、参数选择以及那些只有真正跑起来才会遇到的问题。2. 整体架构与设计取舍2.1 为什么不做“大而全”而是做“少而精”最开始我犯过一个典型错误觉得信息越多越好一口气接了三十多个源从行业媒体到社交平台热搜恨不得把整个互联网都塞进晨报里。结果第一版跑出来每天生成的内容有七八十条我自己看了两天就放弃了——根本读不完而且大量内容重复同一件事被五个源报道摘要写五遍。后来我做了个决定砍源。从三十多个砍到八个只保留那些信息密度高、更新稳定、且跟我关注领域强相关的源。这个取舍背后的逻辑是晨报的定位不是“信息大全”而是“每日必读”。如果一份简报需要花半小时才能读完那它跟刷信息流没有本质区别只是换了个地方浪费时间。砍源之后我给自己定了个硬指标最终输出的条目控制在 10 到 15 条之间。这个数字不是拍脑袋来的。我实测过一个人早上愿意花在“快速浏览”上的时间大概是 8 到 12 分钟按每条内容平均 40 秒的阅读时间算12 条左右刚好。超过 15 条注意力就会明显下降后面的内容基本是扫过去的等于白做。提示源的数量不是关键源的质量和去重能力才是。宁可五个源覆盖 80% 的有效信息也不要二十个源带来 200% 的重复噪音。2.2 技术选型的几个关键决策整个流程我拆成了四个阶段采集、清洗、排序、呈现。每个阶段的技术选型我都纠结过这里把当时的思考过程还原一下。采集阶段我选了 Python 的httpx而不是requests。原因很简单httpx原生支持异步虽然我的源不多但异步采集能把整体耗时从十几秒压到三四秒体验上差别很大。而且httpx的 API 跟requests几乎一样迁移成本极低。至于为什么不用 Scrapy 这种重型框架——杀鸡用牛刀我的采集逻辑很简单不需要那么复杂的调度和中间件体系。清洗阶段核心是去重和正文提取。去重我用的是 SimHash 加汉明距离这个后面细讲。正文提取我试过几个库最后选了trafilatura它对中文内容的提取效果比newspaper3k稳定不少尤其是对那些结构混乱的页面。排序阶段我没有用机器学习模型而是设计了一套加权评分规则。原因是我发现对于个人使用的场景规则引擎的可解释性和可调性远比模型重要。模型跑出来一个分数我不知道为什么这条排前面那条排后面调都没法调。规则引擎虽然“笨”但每一条权重我都能说清楚为什么。呈现阶段我一开始想做个网页后来放弃了。网页要维护前端、要部署、要考虑移动端适配投入产出比太低。最后我选了最朴素的方案生成 Markdown 文件推送到自己的笔记软件里。Markdown 的好处是格式干净、跨平台、随时能改而且我本来就在笔记软件里工作不需要切换上下文。2.3 数据流全景把整个流程串起来看数据是这样流动的定时任务在每天早上 6:30 触发为什么是 6:30 而不是 7:00后面讲采集模块并行拉取所有源的最新内容存入一个临时的 JSON 文件清洗模块读取 JSON做去重、正文提取、字段标准化排序模块给每条内容打分按分数降序排列取前 15 条呈现模块生成 Markdown推送到笔记软件同时发一份到我的邮箱作为备份整个流程跑完大概需要 40 到 60 秒其中采集占大头。这个耗时完全可以接受因为它是后台跑的我起床的时候结果已经躺在那儿了。3. 核心模块的实操细节3.1 采集怎么应对源站的各种“脾气”采集看起来最简单实际上是最容易出问题的一环。不同的源站有不同的“脾气”有的需要伪装 User-Agent有的对请求频率敏感有的返回的数据结构三天两头变。我处理 User-Agent 的方式是维护一个列表每次请求随机选一个。这不是为了做什么见不得人的事纯粹是因为有些站点的默认配置会对陌生 UA 返回空内容。列表里放的都是常见浏览器的标识随机选是为了避免单一 UA 被识别为异常流量。请求频率方面我给每个源单独设了间隔。同一个源连续请求两次之间至少间隔 2 秒不同源之间并行但限制并发数为 5。这个数字是试出来的并发太高容易触发限流太低又浪费时间。5 个并发配合 2 秒间隔实测下来既稳定又够快。import httpx import asyncio import random USER_AGENTS [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36, ] async def fetch_source(client, url, semaphore): async with semaphore: headers {User-Agent: random.choice(USER_AGENTS)} try: resp await client.get(url, headersheaders, timeout15) resp.raise_for_status() return resp.text except Exception as e: print(f采集失败 {url}: {e}) return None async def collect_all(sources): semaphore asyncio.Semaphore(5) async with httpx.AsyncClient() as client: tasks [fetch_source(client, s[url], semaphore) for s in sources] results await asyncio.gather(*tasks) return results这里有个细节值得说超时设 15 秒。我试过 10 秒有些响应慢的源会被误判为失败试过 30 秒整体流程被拖得太长。15 秒是个平衡点实测 99% 的正常请求都能在这个时间内完成。还有一个坑不要用raise_for_status之后就完事。有些源站返回 200但内容是空的或者是个验证页面。所以我在采集之后加了一层校验检查返回内容的长度和关键字段长度过短或者缺少预期字段的直接标记为失败不进入后续流程。3.2 去重SimHash 的实战调参去重是晨报质量的关键。如果不去重同一件事被多个源报道晨报里就会出现好几条几乎一样的内容读起来非常烦。我用的方案是SimHash 汉明距离。SimHash 的原理简单说就是把一段文本映射成一个固定长度的二进制指纹我用的是 64 位内容越相似指纹的汉明距离越小。汉明距离就是两个二进制数不同位的个数。关键参数是汉明距离的阈值。这个阈值决定了多相似才算重复。我试过几个值汉明距离阈值效果问题2只去掉几乎完全一样的漏掉很多换汤不换药的重复3平衡点偶尔误杀角度不同的报道4去重很激进误杀明显增多不同事件被合并5过度去重晨报内容变得太少最后我定在3。这个值下同一事件的不同报道基本能被合并而角度差异较大的内容能保留下来。但这里有个前提SimHash 之前要先做正文提取。如果直接对整页 HTML 做 SimHash导航栏、页脚这些公共部分会干扰结果导致不同页面的指纹反而很接近。from simhash import Simhash def is_duplicate(hash1, hash2, threshold3): return hash1.distance(hash2) threshold def deduplicate(items, threshold3): kept [] hashes [] for item in items: h Simhash(item[content]) if not any(is_duplicate(h, existing, threshold) for existing in hashes): kept.append(item) hashes.append(h) return kept注意SimHash 对短文本效果一般。如果某条内容只有一两句话指纹的区分度会下降容易误判。我的做法是正文少于 100 字的内容直接跳过不参与去重也不进入晨报因为信息量太低。3.3 排序一套可解释的加权评分规则排序决定了哪 15 条能出现在晨报里。我设计的评分公式是这样的总分 来源权重 × 0.4 时效性得分 × 0.3 内容质量得分 × 0.2 关键词命中得分 × 0.1每个维度的计算方式来源权重是我手动给每个源打的 1 到 10 分。打分依据是这个源的历史信息密度和准确度。比如某个源我连续观察了两周发现它发的十条里有七条对我有用那就打 7 分。这个分数不是一成不变的我每个月会回顾一次根据实际阅读体验调整。时效性得分按发布时间计算。6 小时内发布的得 10 分6 到 12 小时得 8 分12 到 24 小时得 5 分超过 24 小时得 2 分。为什么给时效性这么高的权重因为晨报的核心价值之一就是“新”昨天的旧闻今天再推就没意义了。内容质量得分是个综合指标包括正文长度太短扣分、是否有明确的标题没有标题扣分、是否包含具体数据或案例有则加分。这个维度比较主观但能有效过滤掉那些只有一句话的“标题党”内容。关键词命中得分是根据我预设的一组关键词计算的。每命中一个关键词加 2 分上限 10 分。关键词列表我会定期更新比如最近在关注某个技术方向就把相关词加进去。def score_item(item, source_weights, keywords): source_score source_weights.get(item[source], 5) * 0.4 hours_ago (now - item[published]).total_seconds() / 3600 if hours_ago 6: freshness 10 elif hours_ago 12: freshness 8 elif hours_ago 24: freshness 5 else: freshness 2 freshness_score freshness * 0.3 quality 5 if len(item[content]) 500: quality 2 if item.get(title): quality 1 if any(c.isdigit() for c in item[content][:200]): quality 2 quality_score min(quality, 10) * 0.2 hits sum(1 for kw in keywords if kw in item[content]) keyword_score min(hits * 2, 10) * 0.1 return source_score freshness_score quality_score keyword_score这套规则跑下来效果比我预期的好。最大的好处是可调如果我发现某类内容总是排不上来就去检查是哪个维度拖了后腿针对性地调权重。用模型的话这个调试过程会痛苦得多。3.4 呈现Markdown 模板的设计考量呈现环节我改过好几版。第一版是纯文本所有内容堆在一起读起来很累。第二版加了分隔线好一点但还不够。现在的版本用了这样的结构## 每日晨报 · 2026-10-08周四 今日共 12 条预计阅读时间 9 分钟 ### 1. [标题] 来源xxx | 发布时间xx:xx [摘要2-3 句话] [原文链接] ### 2. [标题] ...几个设计细节每条内容配一句摘要。摘要不是我手写的是用提取式摘要算法从正文里抽出来的关键句。为什么用提取式而不是生成式因为生成式摘要偶尔会“编造”原文没有的内容对于晨报这种要求准确性的场景提取式更稳妥。我用的是基于 TextRank 的提取取权重最高的两到三句话。显示预计阅读时间。这个数字是按总字数除以每分钟 300 字估算的。加上这一行之后我对晨报的长度有了更直观的感知也促使我控制条目数量。原文链接放在最后。这样如果我只想看摘要读完就过如果某条特别感兴趣再点链接深入。链接不放在开头是为了避免注意力被过早分散。4. 定时与推送让晨报准时出现4.1 为什么定在早上 6:30 触发定时任务的时间选择比想象中重要。我试过几个时间点5:00 触发太早很多源还没更新完抓到的内容不全。7:00 触发刚好赶上我起床但有时候流程跑得慢我洗漱完还没生成好。6:30 触发大部分源已经更新完毕流程有充足时间跑完我 7:00 起床时结果已经在了。6:30 这个时间还有个好处如果流程出错了我有时间在出门前手动补跑一次。7:00 触发的话一旦出错就来不及了。定时我用的是系统自带的计划任务没有引入额外的调度框架。对于这种单机、单任务的场景系统级的定时器足够可靠而且不依赖任何外部服务。4.2 推送渠道的选择与备份策略推送我用了两个渠道笔记软件和邮箱。笔记软件是主要渠道因为我在那里工作晨报直接出现在我的工作环境里不需要切换。推送方式是通过笔记软件提供的接口把生成的 Markdown 文件写入指定目录。邮箱是备份渠道。为什么需要备份因为笔记软件的接口偶尔会抽风或者我某天在外面不方便打开笔记软件邮箱里有一份就能随时看。邮箱推送我用的是 SMTP把 Markdown 转成 HTML 邮件发送。两个渠道都失败的情况我遇到过两次一次是网络问题一次是接口变更。所以我还加了个本地文件备份每次生成的 Markdown 都会在本地存一份按日期命名。这样即使推送全挂了我回家也能从本地找到。提示推送失败一定要有告警。我的做法是如果两个渠道都失败就给我发一条短信。短信的到达率比邮件和接口都高基本不会漏。5. 常见问题与排查实录5.1 采集失败从“抓不到”到“抓到了但不对”采集环节的问题分两类完全抓不到和抓到了但内容不对。完全抓不到最常见的原因是网络超时和状态码异常。我的排查顺序是先看是不是所有源都失败那就是网络问题再看是不是单个源失败那就是源站问题。单个源失败的话我会手动用浏览器访问一下确认源站是否正常。如果源站正常但脚本失败大概率是 UA 或请求头的问题。抓到了但内容不对这个更隐蔽。表现是状态码 200内容长度也正常但提取出来的正文是乱的。原因通常是源站改版了页面结构变了正文提取规则失效。我的应对方式是在清洗阶段加一个内容质量检查如果提取出的正文里包含大量导航文字、或者正文长度异常短就标记这条为“可疑”不进入晨报同时记录日志。这样虽然会漏掉一些内容但保证了晨报里不会出现乱七八糟的东西。5.2 去重误杀怎么发现和调整去重误杀的表现是明明是两个不同的事件却被合并成了一条。这个问题很难自动发现因为程序认为它们是重复的不会报错。我的发现方式是定期人工抽查。每周我会随机抽一天的晨报把原始采集的内容和去重后的内容对比一下看看有没有被误杀的。抽查了几次之后我发现误杀主要发生在两类内容上一是同一主题的不同角度报道比如同一场活动的预告和回顾二是包含大量通用表述的内容比如“近日某公司宣布……”这种句式。针对第一类我把汉明距离阈值从 4 降到了 3。针对第二类我在 SimHash 之前先做了一步关键实体提取把公司名、产品名、人名这些实体抽出来如果两条内容的实体集合差异很大就不做去重。这一步加进去之后误杀明显减少。5.3 排序偏差为什么好内容排不上来排序偏差的表现是我明明知道某条内容很重要但它就是没进前 15。排查下来原因通常是来源权重给低了或者关键词没覆盖到。来源权重的问题好解决手动调高就行。关键词的问题更常见某个新话题出现了但我的关键词列表里没有相关词导致这条内容的命中得分是 0总分被拉低。我的应对是每周回顾一次没进晨报但我觉得应该进的内容看看是不是关键词的问题是的话就补进去。还有一个隐蔽的排序问题时效性得分对深夜发布的内容不公平。比如一条内容凌晨 2 点发布到 6:30 采集时已经过了 4.5 小时时效性得分是 10 分6 小时内。但如果它是前一天晚上 8 点发布的到采集时过了 10.5 小时得分就只有 8 分。这两条内容实际上只差了 6 小时但得分差了 2 分。对于这种情况我的处理是给深夜时段0 点到 6 点发布的内容加一个时间补偿把它们的“有效发布时间”往后推 3 小时这样就不会因为发布时段不同而吃亏。5.4 常见问题速查表问题现象可能原因排查方法解决方案所有源都采集失败网络问题或本机环境异常手动访问任一源站检查网络重启流程单个源采集失败源站反爬或改版浏览器访问源站对比更新 UA 或提取规则正文提取混乱页面结构变化查看原始 HTML更新提取规则或换库去重误杀阈值过高或短文本人工抽查对比降低阈值加实体校验好内容排不上权重或关键词问题查看各项得分调权重补关键词推送失败接口变更或网络查看推送日志切换备份渠道晨报内容太少源更新少或去重过激查看采集原始数量增加源或放宽去重6. 几个让我少走弯路的实操心得6.1 先跑通最小闭环再优化细节我一开始就想把去重、排序、摘要全做完美结果卡在细节上很久整个流程迟迟跑不起来。后来我换了个思路先用最简单的逻辑跑通全流程——采集用最笨的方法去重用完全匹配排序按时间倒序呈现用纯文本。这个版本花了一个下午就做出来了虽然粗糙但能跑。有了这个基础我再逐个模块优化每优化一个就能立刻看到效果。这个顺序很重要先有再好比一开始就追求好要快得多。6.2 日志要记够但别记太多排查问题全靠日志但日志记太多也会成为负担。我的做法是分级记录采集阶段记每个源的成败和耗时清洗阶段记去重前后的数量变化排序阶段记每条内容的各项得分。这些信息足够我定位绝大多数问题。至于每条内容的完整正文我不记日志只在需要的时候临时打印。日志文件我设了 7 天的滚动清理避免越积越多。6.3 源站是活的流程也要是活的源站会改版、会调整反爬策略、会改变更新频率。这意味着晨报流程不是“做完就完了”而是需要持续维护的。我给自己定了个规矩每周花 15 分钟检查一次流程健康度。检查内容包括各源的采集成功率、去重比例、晨报条目数量、推送成功率。任何一个指标异常就深入排查。这 15 分钟的投入避免了无数次“晨报突然变空”或者“晨报全是重复内容”的尴尬。6.4 别追求全自动留个人工干预的口子我一开始想做到完全自动后来发现有些判断机器做不了。比如某条内容到底重不重要机器只能按规则打分但有些内容的价值是规则覆盖不到的。所以我在流程里留了个口子每天生成晨报后我可以手动调整。调整的方式很简单就是在生成的 Markdown 里直接改删掉不想要的加上想保留的。这个口子让我对晨报有最终的掌控权也让我能持续发现规则的不足反过来优化规则。6.5 摘要宁短勿长宁缺勿滥摘要的目的是让人快速判断这条内容要不要细看不是替代原文。所以摘要要短两到三句话足够。如果提取算法抽不出合适的句子我宁可留空也不硬凑。硬凑出来的摘要往往语义不通反而影响阅读体验。留空的话读者直接看标题和来源也能做判断。7. 后续可以怎么扩展这套东西跑稳定之后我陆续加了一些小功能都是根据实际使用中的需求来的。一个是历史归档和检索。每天的晨报都存下来按日期归档。有时候我想找之前看过的一条内容直接搜关键词就能找到。这个功能实现起来很简单就是把每天的 Markdown 存到一个按年月组织的目录里检索用系统的全文搜索就行。另一个是周报自动生成。每周日我会把这一周的晨报内容汇总一下按主题聚类生成一份周报。聚类的逻辑很简单就是把 SimHash 距离近的内容归到一组每组取一条代表。这样一周的重要事件就能一目了然。还有一个想法是个性化调优。现在的权重是我手动调的未来可以记录我每天实际点击了哪些链接用这些数据反过来调整来源权重和关键词。不过这个功能我还没做因为涉及到数据收集和隐私需要想清楚再做。这套晨报系统说到底是个很个人的东西它的价值不在于技术多先进而在于它真正解决了我的信息焦虑问题。每天早上花十分钟读完该知道的都知道了剩下的时间可以安心做别的事。如果你也想做一套我的建议是从最简单的版本开始先让它跑起来然后在用的过程中慢慢调。工具是长出来的不是设计出来的。