做内容的人都有一个共同的痛苦：选题。每天打开微博、知乎、百度、B站，来回刷一遍热搜榜，其实只是想搞清楚一个问题——今天大家到底在聊什么。后来我干脆写了一个叫buzz的小工具，每天定时把各平台的热搜榜抓下来，做归一化合并，按一套自己的规则算热度，超过阈值就推给我当晚报告。这篇文章就是buzz从0到1的完整记录，从需求、架构、热度模型到实测踩坑，你能看到这个工具是怎么一步步变成我的"选题雷达"的。
如果你也靠内容吃饭，或者需要关注某些关键词的热度变化，这篇文章里的思路、代码结构和踩坑记录应该能帮你省不少时间。它不追求大而全，只解决一个核心问题：把"大家都在聊什么"变成一个可持续追踪的结构化数据源。
1. 为什么想做buzz：一个写作者的选题雷达
1.1 手动刷热搜的痛点
我最初的工作流是这样的：早上起来刷一遍微博热搜，通勤路上刷一遍知乎热榜，中午吃饭看一下百度实时热点，晚上睡前再补一轮B站热门。一天下来，花在"看大家在聊什么"上的时间至少一个小时，但收获却很零散。
问题有三个：碎——信息分散在四五个平台，每个平台的榜单逻辑还不一样；飘——今天看了明天就忘，想回顾这周的热点趋势只能靠记忆硬凑；被动——平台推什么我看什么，没办法对我关心的特定关键词做持续追踪。
尤其是当我要连续一周盯某个领域的动向时，纯靠手工基本不现实。比如上周我打算写一个某技术方向的选题，需要观察这个话题在该领域的热度走势，手动记录完全做不下去，两天的热度数据就能让我心态崩掉。
1.2 为什么不用现成的舆情工具
市面上做舆情监测的产品很多，亿级的数据能力、全网抓取、情感分析、报告导出，功能看着很完善。但实际用起来有三个不适合我的地方。
第一个是贵。面向企业的舆情系统基本是按年付费，个人根本扛不住。第二个是重。大部分舆情系统关注的是整个网络的声量和情感倾向，我只想知道"哪些词上了热榜"和"它今天热不热"，用不上那么复杂的维度。第三个是慢。企业系统的报告周期以周、月为单位，而我需要的是每天早晚各一次实时提醒，它们的交互路径对个人用户来说太繁琐了。
说到底，就是杀鸡用牛刀。我需要的是一个"够用就好"的工具：把几个主流平台的榜单抓下来，算热度，存历史，做提醒。数据量不大，逻辑不复杂，一台小服务器就能跑。于是buzz就诞生了。
1.3 buzz的定位：回答三个问题
buzz的设计目标非常聚焦，我只想让它在每天的任何时刻都能回答我三个问题：
- 此刻大家都在聊什么？
- 这个话题的热度是刚刚起来，还是已经快到尾声？
- 跟我关心的领域相关的词，今天有没有新变化？
三个问题对应的能力分别是：榜单采集、热度评分、关键词追踪。整个项目的架构都是围绕这三件事展开的，没有额外加任何功能。这也是buzz能保持轻量的根本原因——每加一个功能都会带来维护成本，所以只做最核心的部分。
2. buzz的架构拆解：收集"大家都在聊什么"的数据链路
buzz的整体流程可以概括为一条链路：定时任务触发采集 → 请求各平台榜单接口 → 解析JSON或HTML → 话题归一化 → 写入SQLite → 热度计算 → 触发推送或生成日报。下面我按模块拆开讲。
2.1 数据源选型：公开榜单接口就够了
数据源是整个项目的地基，选对了后面都顺。我最终选了四个数据源，全部是公开的榜单页面或半公开的JSON接口。
| 平台 | 入口 | 大致更新频率 | 解析方式 |
|---|---|---|---|
| 微博热搜榜 | 网页版热搜页面对应的JSON接口 | 1-5分钟 | JSON |
| 知乎热榜 | 热榜聚合JSON接口 | 5分钟左右 | JSON |
| 百度实时热点 | 百度热榜页面 | 30分钟左右 | HTML解析 |
| B站热门视频 | 排行榜聚合接口 | 10分钟左右 | JSON |
为什么选这四个？因为它们的用户群体差异够大：微博覆盖泛娱乐与突发事件，知乎偏深度讨论和知识型话题，百度反映搜索真实需求，B站代表年轻用户的兴趣热点。四个平台交叉覆盖，基本上能拼出互联网讨论的全貌。
这里有个关键的取舍：我优先选择平台提供的JSON接口，而不是去爬网页HTML。原因很简单，JSON接口结构稳定、直接返回结构化数据，不容易因为页面样式调整而失效。微博的接口偶尔需要带Cookie请求，这个后面踩坑部分细说。百度没有公开的JSON热榜接口，所以我只能解析HTML，但百度页面结构优化得比较保守，几个月都不大改版，加上解析逻辑独立成一个函数，维护成本可控。
2.2 采集策略与存储设计
采集频率我设置的是每10分钟跑一次。这个频率是基于两个考量：一是热搜榜本身的更新节奏大约在1-30分钟之间，10分钟一轮能捕捉到大部分排名变化；二是数据量可控，四个平台每次抓50条，一天下来也就不到三万条记录，SQLite轻松处理。
存储我用的是SQLite，没有上MySQL或者PostgreSQL。很多人一听数据库就觉得要上正经服务，但对于buzz这种单机运行、单表写入、查询集中在时间范围和关键词过滤的场景，SQLite完全够用，而且零运维、备份就是复制一个文件，极其适合个人项目。
表结构设计了两张表：
-- 热搜榜单原始记录表 CREATE TABLE hot_rank ( id INTEGER PRIMARY KEY AUTOINCREMENT, source TEXT NOT NULL, -- 数据来源：weibo/zhihu/baidu/bili keyword TEXT NOT NULL, -- 归一化前的话题文本 norm_keyword TEXT NOT NULL, -- 归一化后的话题文本 rank INTEGER NOT NULL, -- 排名，1为榜首 heat_score INTEGER, -- 平台给出的热度分数，没有则为NULL captured_at INTEGER NOT NULL -- 采集时间戳（UTC） ); -- 话题词频统计表（用于后续聚合查询） CREATE TABLE keyword_daily ( id INTEGER PRIMARY KEY AUTOINCREMENT, norm_keyword TEXT NOT NULL, date TEXT NOT NULL, total_score REAL NOT NULL, first_seen INTEGER NOT NULL, last_seen INTEGER NOT NULL );captured_at统一存UTC时间戳，所有展示层的时区转换延迟到最后一步。这个习惯是从后面要讲的时区踩坑里学到的，一开始就直接用时间戳省了很多事。
2.3 话题归一化：不同平台的同一件事怎么合并
四个平台的榜单抓回来后，最麻烦的问题出现了：同一个新闻事件，在四个平台上的表述完全不一样。举一个典型的例子：某个地区发生了地震，微博热搜是"四川泸定地震"，百度热榜是"泸定地震"，知乎热榜是"如何评价泸定地震"，B站热门则可能是"地震瞬间男子一把抱起女儿往外冲"。
如果不做归一化，这四个话题在系统里就是四个独立条目，热度被拆散，统计出来的数据毫无意义。我的归一化处理分三步走：
第一步，字符清洗。去掉话题标签的#号、去除首尾空格、统一全角半角、英文字母统一小写。
第二步，模板剔除。很多平台喜欢给话题加引导语，知乎的"如何评价XX""如何看待XX"，微博的"XX爆""XX沸"，这些前缀后缀对话题身份没有意义，需要从文本中剥离。
第三步，包含匹配。如果两个话题之间存在包含关系，并且长度差不超过8个字符，就归为同一话题。比如"泸定地震"是"四川泸定地震"的子串，长度差为2，判定为同一话题。这个逻辑用MySQL的LIKE或者Python的in运算符都能实现。
归一化不能用太过激进的规则。我一开始加入了一个模糊匹配的词向量方案，结果误把两个完全不同的话题合并到了一起，导致统计数据污染。后来学乖了：用保守的字符串规则处理70%的情况，剩下30%的复杂情况宁可漏掉也不冒险。合并是损人不利己的事，漏掉只是不完整，做错了直接误导决策。
3. 热度评分模型：短跑选手和马拉松选手的PK
榜单数据有了，接下来要回答一个核心问题：怎么把一个话题的"热度"量化成一个可比较的分数？
3.1 热度公式：排名、来源和时间衰减的乘积
最初我想直接拿平台的heat_score来用，但很快发现不可行。微博的热搜词后面是一个热度值，百度给的是一个百分比，知乎则根本没有原始的分数展示，不同平台的热度单位完全不一样，直接相加没有意义。于是我自己定义了一套热度评分，核心公式是：
single_score = rank_weight(rank) × source_weight(source) × decay(dt)其中：
rank_weight：排名权重。第1名100分，第2-5名85分，第6-10名70分，第11-20名55分，第21-50名40分。排名差距在头部影响力差异巨大，用分档压制尾部的噪声。source_weight：来源权重。微博1.2，知乎1.0，B站0.9，百度0.8。这个是我根据平台讨论的深度和广度主观设定的，没有绝对对错，你可以根据自己关注的领域调。decay：时间衰减。一个话题如果连续多个周期出现在榜单上，分数会累积；但太早之前出现的记录对当下热度的贡献应该递减。我用半衰期6小时的指数衰减：decay = 0.5 ^ (hours_since_seen / 6)。
一个话题的buzz值就是它所有历史采样点得分之和。这个公式的好处是逻辑透明，每个参数都可解释，而且方便调试。我不喜欢一上来就用复杂的机器学习模型，因为数据量不够，模型训出来的结果可能还不如一个手工调的公式可解释。
3.2 爆发型与长尾型话题的识别
热度公式跑起来之后，我发现只看buzz值的高低是不够的，趋势形态才更有价值。这就像评价运动员，短跑选手和马拉松选手都有"成绩"，但完全是两种物种。
举两个例子：
某明星的绯闻事件，30分钟内冲上微博热搜第一，知乎紧随其后也出现了相关问题，但百度搜索量还没起来，B站基本无感。buzz值在短时间内暴涨超过1500，但6个小时后随着新瓜出现，搜索和讨论量迅速回落。这是典型的爆发型话题。
另一部新的剧集开播，微博热搜稳定在Top20，知乎出现多篇高赞剧评在持续发酵，B站有大V发的解说视频挤进热门榜，百度搜索量稳步上升。buzz值没有暴涨，但连续三天都在稳步爬升。这是长尾型话题。
基于这两个形态，我给buzz加了一个分类逻辑：
- 爆发型：连续两轮采样（约20分钟）内buzz值增量超过600，触发"爆"标签。
- 长尾型：连续12轮采样（约2小时）以上持续在榜，且buzz值每轮增量保持在50-300之间，触发"长"标签。
这个分类逻辑对我的选题帮助非常大。爆发型话题适合快速蹭热度出短文，长尾型话题则值得投入精力做深度内容，因为它的讨论生命周期长，产出内容能吃到更长时间的流量。
3.3 阈值设置的经验：没有基线，不要设阈值
推送提醒是buzz的高频使用功能，但阈值怎么设很有讲究。我第一次跑通完整流程时，随手定了一个"buzz值超过1000就推送"的规则。结果是每隔一会儿就推送一条，噪音大得直接把微信通知关了。
后来我做了两步调整。第一步是空跑三天，不设任何推送，先把数据攒下来做基线。三天后统计发现，普通热词的日常buzz值大概在200-800之间，偶尔有突发话题能冲到1200以上。第二步是把固定阈值改成了动态规则：buzz值超过当日所有话题buzz值均值的3倍，或者连续两轮排名第一，才触发推送。
动态阈值比固定阈值可靠得多。因为热度的绝对水平和很多外部因素相关，比如重大新闻日整体buzz值都会抬升，固定阈值不是被堵死就是被刷爆，而动态阈值天然适应这种环境变化。
4. 提醒与日报：让buzz从"看"变成"用"
数据本身没有价值，用起来才有。buzz的数据采集和热度计算做完后，我面临的问题是：怎么让结果高效地触达我，而不是让我每天都去数据库里查。
4.1 推送链路：阈值命中后的消息模板
推送渠道我选的是Server酱，因为它能直接推到微信里，微信是我们每天都离不开的入口，不需要额外装App。后来我又加了一条PushDeer通道作为备用，因为Server酱的免费额度有限制，而推送本身很便宜，双通道保障更稳。
命中阈值后的推送内容长这样：
【buzz预警】话题「沪指失守3100点」buzz值达1560，热度异常上升 - 来源：微博(第2位)、知乎(第5位)、百度(第1位) - 首次上榜：10分钟前 - 热力形态：爆发型，建议尽快跟进这个模板是调试了几版后定下来的，核心信息就四样：话题名称、buzz数值、来源平台分布、趋势形态。很多舆情工具的推送只有"XX话题热度上升"这句话，没有来源和趋势，收到了还是得自己去查，效果大打折扣。
4.2 日报生成：用SQL聚合当日热点
每日日报是buzz用得最频繁的产出物。每天22点自动触发一个聚合查询，生成当日热点Top20。
日报的数据来源其实很简单，就是对hot_rank表做一次条件查询和聚合：
def generate_daily_report(date): conn = sqlite3.connect('buzz.db') cursor = conn.cursor() # 当日所有话题按照buzz值聚合排序 cursor.execute(''' SELECT norm_keyword, SUM(rank_weight) / MAX(1, (julianday('now') - julianday(min(captured_at))) * 24) as buzz_score, MIN(captured_at) as first_seen, MAX(captured_at) as last_seen FROM hot_rank WHERE captured_at BETWEEN ? AND ? GROUP BY norm_keyword ORDER BY buzz_score DESC LIMIT 20 ''', (day_start, day_end))日报模板包含四个模块：
- 今日总览：当天的Top10话题和buzz值，一句话总结当天最大热点是什么。
- 环比变化：对比前一天同话题的buzz值，列出涨幅最大和跌幅最大的5个话题。
- 新晋榜单：今天首次出现在Top50的话题，标记为"新"。
- 潜力预判：根据最近6小时的热度走势，预测明天持续发酵的话题，这个模块用的是简单的线性外推，不复杂但很实用。
日报生成后通过邮件发送到我的邮箱。邮件的优势是可以慢慢看、可以归档，配合微信的实时推送刚好形成互补——实时推送用来触发行动，邮件日报用来做复盘。
4.3 主动查询：命令行里的"这个词热不热"
有了提醒和日报之后，buzz的使用方式已经覆盖了大部分场景，但还有一个缺口：临时起意的主动查询。比如我在写一篇文章前，想快速知道某个词最近两天的热度走势，总不想去翻数据库。
于是我加了一个命令行入口，支持两种查询：
python buzz.py check 关键词 python buzz.py trend 关键词 --hours 48check返回这个词当前的buzz值、排名、上榜时长和热力形态。trend返回最近48小时的采样点，并且画一个粗糙的ASCII趋势图，直接在命令行里打印出来。
这个主动查询功能看着不起眼，实际使用频率很高。每周做选题规划时，我会把候选关键词挨个check一遍，数值会直接告诉我哪个方向最近有话题性。
5. 踩坑记录：接口改版、时区错乱和话题合并
buzz从上线到现在，踩过的坑不少。我把最有代表性的三个写下来，它们都不是网上教程会提前告诉你的细节。
5.1 微博接口改版：解析器必须有降级路径
微博热搜的接口是我踩过的最深的坑。第一版buzz用的是HTML解析，从热搜页面的网页结构调整当中提取数据。跑了两周后，某天早上突然所有微博的热搜数据全是零。查了之后发现微博改版了，热搜列表的DOM结构变了，class名全都换掉了，原来的解析逻辑全军覆没。
这次事故之后我做了两个改进。第一个是给解析层做了一个catch的降级逻辑——优先走JSON接口，如果JSON接口返回异常，自动回退到HTML解析，再不行就把这条采集任务标记为失败但并不影响其他平台的采集。第二个是给所有外部接口的解析函数增加了"最后成功时间"的记录，一旦发现异常就告警，避免损坏的解析器静默运行好几天。
这里想多说一句，凡是依赖第三方接口的项目，都必须默认接口随时可能变。写解析器的时候，尽量用稳定的特征定位，比如JSON里的字段名，而不是HTML里的某个class。JSON也会改版，但改的频率远低于HTML页面。
5.2 时区错位：数据库里的时间戳到底是哪里时间
时区问题是我第一次生成日报时就遇到的。现象是：每天凌晨4点收到的日报，内容却是前天晚上的数据。找了一个小时才发现，服务器用的是UTC时区，而我所有的时间判断和分组逻辑都在拿UTC时间去切"今天"和"昨天"的边界。
比如北京时间5月15日22点的数据，在UTC时间戳里已经是5月15日14点，但如果我的日报查询条件是"WHERE captured_at >= 今天0点(UTC)"，那它实际只包含了北京时间早上8点以前的数据，晚上发布的内容全部被划到了"明天"。
解决方案是统一规范：数据库里所有时间戳一律存UTC，应用代码里所有涉及"今天""昨天"这种语义的边界计算，显式地转换为北京时间（Asia/Shanghai）后再分组，转换动作集中在一个工具函数里，不允许在业务代码里散落着time.localtime()这种系统时区依赖的调用。这个规范立好之后，时间问题就再没出现过。
5.3 话题合并的边界：宁可漏，不可错
前面讲了用包含关系做话题合并，这个逻辑在实际运行中的问题是边界判定。有个真实案例：某天发生了地震，"泸定地震"和"四川泸定地震"正确合并了，但与此同时，"地震预警系统"这个词也频繁上百度热榜。如果只按"包含关系"合并，"地震预警系统"包含了"地震"两个字，但话题含义完全不一样。
这个问题的教训非常深刻：简单的字符串包含判断会把两个完全无关的话题绑定在一起，导致热度统计直接跑偏。
我的补救措施是双管齐下。第一，增加长度差约束，子串和长文本长度差超过8个字符就不再自动合并，减少误判面。第二，维护一个"排除词库"，把容易干扰匹配的通用词放进去，比如"系统""方法""原因""背后"等。这个词库是随着运行不断补充的，每次发现一个错误的合并案例，就加一条规则。
因为有了这个教训，后来我在归一化上变得非常保守。宁可漏掉20%的同话题合并，也不能把2%的不同话题错误合并。数据完整度可以慢慢优化，可信度一旦崩塌就全完了。
6. 换个视角用buzz：从选题工具到趋势观察
buzz运行了一段时间后，它的角色逐渐从"选题工具"变成了我的"外部注意力系统"。它的用途比最初设想的更广，这里分享几个实际用得很顺手的场景。
内容选题是最直接的用法。每天日报看完，基本能知道今天该写什么、什么话题值得投入时间做深度内容，什么话题只是路过看一眼就好。爆发型话题当天快速出稿，长尾型话题规划成系列文或视频脚本。
竞品关注是第二个实用场景。我给自己关注的几个竞品关键词建立了独立追踪，一旦它们的buzz值出现异常上升，第一条推送往往预示了产品更新或市场动作。结合自动保存的历史数据，我可以回看竞品每一次热度高峰的时间点和触发原因。
历史复盘是运行两个月后开始有价值的。把热度数据按周维度看，会发现一些周期规律：娱乐类话题周末爆发，科技类话题的波峰多在周一和周四，教育类话题的讨论高峰集中在开学前两周。这些规律反过来会指导我的内容排期——计划在用户讨论某类话题的高峰期前发布相关文章，流量效果比随机发布时间稳定很多。
给未来想复刻buzz的人几个建议：第一，平台入口选择和更新策略要有备份方案，接口改版是必然的，不是"如果"而是"什么时候"；第二，历史数据一定保留，趋势分析才有意义，跑不满两周的数据很难支撑任何结论；第三，功能保持克制，满足核心需求后就停手，每加一个功能都是维护负担。
buzz这个项目让我最大的体会是，热度从来都不是一个瞬时值，而是一条持续累积的曲线。所谓"蹭热点"，本质上是识别这条曲线处在哪个阶段，在它快速爬升时跟上，在它滑落时及时收手。把这个问题想明白了，后面所有算法参数设计都有了方向。如果你也每天被各种榜单和信息流搞得疲惫不堪，不妨也搭一个自己的buzz。一套抓取脚本、一个SQLite、一个通知接口，就能让追热点这件事从"每天刷手机"变成"每天看报告"，省下来的时间足够做很多更有价值的事情。
