每天早上一睁眼就是热搜榜、推荐流、群里转发的链接看似什么都知道可真要回答过去一个月到底发生了什么绝大多数人只能含含糊糊说出几个碎片。我做的 last30days 这个项目就是想试试一件事当 AI 学会追热点它能不能比我们更清楚这个月发生了什么。从去年底到现在我花了大概六周时间搭了一个让 AI 自动完成采集、清洗、聚类、写复盘的月度热点报告系统。输入是过去30天的公开信息流输出是一份能直接读的月报像资深编辑做的那种而不是一堆链接。这篇文章把整套思路、技术选型、实操代码和踩过的坑都记录下来。适合谁看呢内容创作者要找选题运营要看话题风向产品经理要追踪用户讨论做行研的要把脉趋势甚至只是被信息过载折磨的普通人——这套系统都能直接抄作业。就算你完全不写代码我也给了最简替代方案用一条 Prompt 就能先体验一把AI 追热点和人刷热点的区别。1. last30days 在做什么把刷热点变成读报告1.1 为什么窗口偏偏是 30 天项目的名字就是核心设定只看最近30天。这个窗口不是拍脑袋定的而是我观察信息生命周期后的选择。一个热点事件的完整生命周期从爆发、发酵、回落到被后续事件覆盖通常在几天到三四周之间。7天太短你只能看到什么东西火了看不到它为什么火、火完之后留下了什么。90天又太长很多早期细节已经被后续发展淹没回顾变成了考古。30天刚好覆盖一个事件的完整叙事弧。举个例子一款开源工具从首次出现在 GitHub Trending到被技术媒体跟进报道再到社区里出现教程、争议和二次开发往往需要两到三周。如果你只做周报你只能看到零散的单点把窗口拉到30天这些单点才能连成一条看得见因果的故事线。另外30天也契合多数内容团队和运营团队的复盘节奏。月度汇报、月度选题会、季度规划前的趋势判断都需要一份能覆盖最近这段时间的全景资料。把窗口设成30天报告产出的频率是每月一次既有足够信息密度又不会因为太频繁而让人懒得看。1.2 AI 在这件事里解决的不是搜集做一个热点系统你可能会本能地想到爬虫、榜单 API、关键词监控。这些确实能把数据拿回来但拿回来之后呢100条新闻、200条帖子、50个视频散落在不同平台措辞完全不同人肉消化要一整天还免不了漏掉关键转折点。所以 last30days 里爬虫只负责第一公里真正的价值在 AI 的浓缩能力用聚类把不同平台上的碎片拼成同一个事件用生成能力把时间线、背景、相关讨论、趋势判断整合成一份人能直接读的稿子。简单说爬虫负责把书买回家AI 负责把书读完之后讲给你听。这里有个很核心的产品判断用户不缺信息缺的是已经消化好的信息。我们每天接收的信息量早就超载了缺的从来不是更多链接而是一个能告诉你这个月真正重要的是哪五件事它们之间有什么关系的助手。1.3 谁需要这份AI 月报内容创作者月度复盘是最好的选题库。AI 报告里标出的爆发型事件和持续型话题直接决定了下个月写什么方向的东西有流量潜力。运营和市场需要知道用户最近在讨论什么、竞品有哪些动作、哪些话题带了明显情绪。报告里的事件聚类和热度变化比你自己翻后台数据要全面得多。产品经理很多需求信号不是来自用户访谈而是来自社区讨论。某个功能被反复吐槽、某种使用技巧被大量分享这些都是产品决策的输入。行研和咨询快速扫描行业动态、识别关键变化点月报可以当作每周研究的预筛选器把需要深入阅读的事件挑出来。普通信息焦虑人群不想再被推荐流牵着走想花20分钟了解一个月的大局这份报告就是为你准备的。2. 方案设计与技术选型别一上来就写爬虫2.1 数据源选型别再只盯着热搜榜做这套系统我踩的第一个坑就是从热搜榜开始。微博热榜、百度热榜、知乎热榜数据很好拿但它有两个硬伤榜单受算法和商业投放影响一个话题上榜不代表它真的重要可能只是被推了大量的流量而且榜单大多给的是此时此刻的数据不保留历史你没法回看30天前的排名。后来我把热搜榜降级为兜底和交叉验证用的辅助信源。真正的主力信源应该这样搭配数据源类型代表延迟覆盖度信噪比适合扮演的角色垂直社区热榜Hacker News / V2EX / 豆瓣 / 小红书小时级特定圈层高讨论质量好主力信源RSS 聚合源36氪 / 少数派 / 科技媒体博客小时级行业动态中标题党多补全事件背景趋势数据Google Trends / 百度指数天级全网数据干净量化热度变化平台热搜榜微博 / 百度 / 知乎热榜分钟级全领域偏低有商业干扰兜底与交叉验证自建监控指定账号、域名变更监控分钟级精准定制高进阶玩法单独的科技媒体源会带来另一种偏食。我曾经有一整月只接了技术社区和科技媒体的源结果报告里全是 AI、开源、创业相关的消息大众话题几乎为零。后来检查才发现不是没发生是我的源没覆盖。所以现在我的固定组合是垂直社区 RSS 趋势数据热搜榜只用来月末做交叉验证。2.2 处理链路采集、清洗、聚类、叙事last30days 的完整处理链路我拆成四段采集定时从 RSS、API、目标站点抓取最近30天的条目保留标题、正文摘要、来源、发布时间、链接。清洗去掉 HTML 标签、无意义符号、广告和水文识别重复转载过滤营销内容。聚类把同一事件在不同平台的报道归并到同一个事件组里形成事件。叙事对每个事件和整个30天窗口做总结生成时间线、趋势判断、细节亮点。这四段里采集和清洗是基础工程做得越干净后面 AI 越不会出错。但真正不可替代的是第3和第4段。如果没有聚类AI 就会把同一件事的20篇报道当成20个独立话题报告会碎到没法读如果没有叙事你得到的只是一份数据目录离懂发生了什么还差很远。2.3 工具与模型选型通用 LLM 编排脚本做这个项目时我认真对比过两类方案。一类是直接用现成的热点聚合产品大多是榜单监控产品信息密度高但几乎是零观点输出它们解决的是发生了什么不解决为什么会这样和接下来会怎样。另一类是自己拼装通用 LLM 编排脚本可以完全控制数据源、处理逻辑和输出形式。我选了后者。现成产品大多只给列表而 last30days 的核心诉求是复盘——这个诉求用通用大模型反而更顺手因为你可以把数据、背景、你的口味全部以 Prompt 的形式喂进去。模型选用上我的经验是事实总结类任务把温度调到 0.3 左右观点评论类任务可以调到 0.7。尽量给模型原文片段而不是只给标题。成本方面一次完整月报大约消耗 5 万到 8 万 token按主流接口价格算几毛钱对比人工整理两三个小时这个性价比基本不需要犹豫。3. 实操记录把 last30days 跑起来3.1 数据采集层RSS 和榜单 API 的写法先给你看我采集层的 Python 脚本骨架。设备很简单feedparser 加 requests 就够了import feedparser from datetime import datetime, timedelta SOURCES [ {name: Hacker News, url: https://news.ycombinator.com/rss}, {name: 少数派, url: https://sspai.com/feed}, {name: 36氪, url: https://36kr.com/feed}, ] def parse_time(entry): # 不同源的字段结构不一样结构体、时间字符串都要兼容 for key in (published_parsed, updated_parsed): if key in entry and entry[key]: return datetime(*entry[key][:6]) return None def fetch_recent(days30): now datetime.now() threshold now - timedelta(daysdays) items [] for src in SOURCES: feed feedparser.parse(src[url]) for e in feed.entries: t parse_time(e) if t and t threshold: items.append({ source: src[name], title: e.get(title, ).strip(), link: e.get(link, ), published: t.isoformat(), summary: e.get(summary, ), }) return items榜单 API 的逻辑也差不多一个 GET 请求拿 JSON按时间过滤到30天内就行。但这里有个非常关键的提醒榜单类接口大多只提供当天数据没有历史存档所以你必须设计成每天跑一次、把结果存进数据库或文件里。30天窗口的最后一天数据是你过去一个月一点一点攒出来的而不是临时拉一下就能补出来的。如果没做这一步你运行月报时会发现窗口内一片空白这就是我最早踩过的坑。3.2 清洗与去重标题党和转载是最大噪声源数据采回来以后是没法直接用的。新闻、帖子、社区问答混在一起标题党的干扰非常严重一个叫《这个东西火了》另一个叫《xx项目为什么一夜爆红》措辞千差万别机器第一眼根本看不出是同一件事。我的清洗规则是分三层格式层统一小写去掉 emoji 和重复标点把【】里的栏目名剥掉。内容层对正文做摘要提取只保留前两条核心句子后续聚类时以摘要为主、标题为辅。去重层用 simhash 计算全文相似度相似度高于 0.8 的只保留最早发布的那条避免同一个新闻源被多个渠道转载造成重复计数。别指望清洗一步到位。我自己的体会是清洗规则是迭代出来的每次跑完报告把新出现的噪声类型加进规则表跑一个月之后规则库才基本稳定。3.3 聚类成事件从关键词向量到事件标签清洗之后进入聚类环节。简版我用 TF-IDF 加 DBSCAN代码长这样from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_distances from sklearn.cluster import DBSCAN titles [item[title] for item in items] vec TfidfVectorizer(ngram_range(1, 2), min_df2) X vec.fit_transform(titles).toarray() dist cosine_distances(X) clustering DBSCAN(eps0.4, min_samples3, metricprecomputed).fit(dist) labels clustering.labels_ for i, label in enumerate(labels): items[i][event_id] label # -1 表示没有归入任何事件这里两个参数最关键eps0.4表示两条内容余弦距离在 0.4 以内才会被视为同一事件的候选min_samples3表示至少三条内容聚在一起才值得被定义为事件。少于三条的我会丢进一个叫零散动态的组不在月报正文里展开。需要提醒的是TF-IDF 处理中文短文本的能力很有限同义改写基本认不出来。要做真正靠谱的中文事件聚类建议换成 embedding 模型比如 bge、text2vec把标题和摘要编码成向量后再做聚类效果完全是两个量级。TF-IDF 最多算个能跑的雏形认真做请直接上 embedding。3.4 提示词工程让 AI 输出人话月报聚类完成后重头戏就来了让大模型写报告。我设计了两轮生成第一轮做事件梳理第二轮做主编点评。事件梳理的 Prompt 长这个样子你是一个严谨的内容策展人。以下是过去30天内抓取并聚类好的信息条目每个事件 包含多个来源的标题、摘要、发布时间。 请为每个事件输出 1. 事件名不超过15个字 2. 一句话概述 3. 关键时间线列出重要的时间点和对应事件 4. 热度变化判断上升/下降/平稳并说明依据 5. 来源列表最多列出5条 要求只使用资料中出现的信息不要猜测不确定的信息标注“资料未提及”。这个 Prompt 的核心是给事实、要结构、限幻觉。生成完事件梳理后再让同一个模型做主编点评从事件列表里挑出三到五个最重要的分析它们之间有没有关联判断下个月哪些话题可能出现第二波。两遍拆分比一步生成全文要稳定得多。给你看一个我实测的输出片段【事件】某开源项目在开发者社区刷屏事件时间线7月12日首次出现在 GitHub Trending7月15日 Hacker News 讨论串突破300条7月18日国内技术社区出现第一批中文教程。热度变化7月12日到18日为快速上升期7月25日之后平稳回落。判断依据涉及来源数从2个增长到28个讨论周期持续9天后续以教程和二次开发为主。这种输出最大的价值在于它把散落的碎片整合成了有起承转合的故事。你读到的不是某项目很火而是它怎么火起来的、火到什么程度、现在处于什么阶段。3.5 定时运行与推送每天采集、每月出报告日常运行我放在了 GitHub Actions 上每天凌晨3点跑一次采集入库每周日生成一份周报草稿每月1号上午生成完整月报然后推送到企业微信机器人。你完全可以用本机 crontab 替代0 3 * * * cd /path/to/last30days python fetch_and_store.py 0 8 1 * * cd /path/to/last30days python generate_monthly_report.py推送渠道看你自己的使用习惯飞书机器人、钉钉机器人、邮件、Notion 数据库都可以。我最后选了飞书机器人因为可以直接发 markdown 消息手机端阅读体验最好。你甚至可以加一步摘要推送机器人每天早上先推三条昨日值得关注到月底再推完整月报这样你既不会漏掉大事件又不用被信息流推着走。4. 我踩过的坑与排查实录4.1 AI 一本正经地编热点是最让人头皮发麻的事第一次跑完整链路生成的月报里有一条某公司发布了下一代产品读起来有板有眼还自带时间线。我去核对原文发现原始资料里根本没有这个产品是模型把两篇不同公司的新闻缝合出来的。这个现象在总结类任务里非常常见尤其在你只喂标题和摘要、没喂全文的时候。我后来用四道锁防幻觉喂全文把原始条目的正文摘要至少前两条核心句一起放进上下文而不是只给标题。降低温度事件梳理阶段把温度压到 0.2 ~ 0.3。硬性要求Prompt 里明确写只使用资料中出现的信息不确定就标注并要求附来源链接。自动校验生成后跑一遍校验脚本报告里出现的每个事件名必须在原始条目里能找到对应关键词找不到就打回重写。第四道校验脚本尤其重要我建议所有人不管用什么模型都加上。它能兜住大部分缝合怪和编造热点的问题。4.2 最近30天最容易出问题的是时间锚定大模型对最近30天这种相对时间概念的理解很飘。你问它过去30天发生了什么它可能从训练数据里捞一段某年某月的记忆来凑数输出里甚至会出现今年一季度上季度这种莫名其妙的表述。我的解法是在 Prompt 里固定写上当前实际日期是2025年X月X日本次报告只覆盖从日期A到日期B之间采集到的资料同时把每条资料的发布时间字段作为元数据一起喂进去。摘要生成之前会把今天本周这类模糊时间词统一替换成具体日期。这个细节看起来不起眼但能显著减少时间混乱类的幻觉。4.3 数据源偏食会让整个月的报告呈现单一视角数据源偏食是比幻觉更隐蔽的问题因为它不会报错只会让报告看起来有点怪。有一段时间我只接了技术社区和科技媒体的源结果报告里全是 AI、开源、创业公司的消息用户视角、大众话题几乎为零。后来才发现不是没发生是我的源根本就没覆盖这些话题。我的调整是固定混合三类源大众平台热搜看大家在讨论什么垂直社区看专业圈子在讨论什么趋势指数看哪些话题在用量上出现拐点。每月报告末尾我还让模型输出本月来源结构占比一旦某类来源占比超过60%就会提醒自己需要补充信源。这个自查机制帮我挡住了好几次视角漂移。4.4 常见问题速查表症状可能原因排查思路修复办法报告里出现编造的事件没喂全文、温度过高、时间锚定混乱检查生成时的上下文资料喂原文、降温度、加来源校验30天窗口内条目极少采集任务没每天跑、源失效查看采集日志修复定时任务、更换备用源事件聚类过度碎裂TF-IDF 无法理解同义改写抽样看聚类结果换 embedding 模型、调高 eps事件聚类过度合并eps 太大不同主题混在一起抽样看事件内标题调低 eps、增加 min_samples报告视角单一数据源偏食看来源结构占比补充大众平台/趋势数据源5. 从月报到决策辅助last30days 还能怎么延伸5.1 指标化热度曲线和传播速度比谁火了更有用固定的月度复盘只能回答发生了什么但实际工作中我们更常问的是变化有多大。我在二期版本里加了一层指标每个事件用出现条数、来源数、讨论周期、热度增长斜率四项做量化再配一条简单的时间序列。比如某个话题在 7 天内从 2 个来源涨到 30 个来源模型就可以判定它是爆发型热点如果 30 天内均匀出现 40 条则是持续型话题。这个区分对内容选题和运营排期很有价值——爆发型可以追持续型更适合做深度内容。加上指标之后月报就从编辑摘要升级成了决策看板。5.2 垂直化把窗口从全网换成某个领域另一个我很看好的方向是垂直化。同样是 last30days 的框架把数据源换成一类特定渠道你就得到了一个完全不同用途的工具AI 行业30天动态、跨境电商独立站30天热点、某类小众兴趣社群30天讨论。我之前帮朋友改过一个宠物行业版本数据源只接宠物垂直媒体、小红书宠物话题和几个头部博主的 RSS生成出来的报告精准得惊人全是那个圈层真正关心的事。通用月报解决的是信息过载垂直月报解决的是行业盲区两者的价值完全独立。如果你本身就在某个行业里我强烈建议你从垂直版开始做数据源更好找输出也更容易被检验。5.3 最后的一点个人体会做 last30days 做到这里最让我意外的不是技术上的效果而是我自己的工作方式被改变了。以前找选题要花一整个晚上翻榜单、刷后台、问朋友现在我养成了一个习惯每个月月初先花 20 分钟读完 AI 生成的月报带着哪些事件可能有第二波的判断再决定本周写什么。这套东西不是让我偷懒而是把精力从找信息挪到了用信息上。如果你也想试我的建议是先别急着把链路做全。第一次跑哪怕只用一个 Prompt 把30天的搜索趋势或热榜内容粘贴进去让 AI 帮你归纳、聚类、下结论你就已经能感受到AI 追热点和人刷热点的根本区别人刷热点是在追赶已经发生的事AI 追热点是在帮你建立对时间段的整体感知。等确认这个输出对你有用再一步步加上采集、清洗、聚类、定时推送这些工程能力。我就是这么一步步从粘贴趋势榜走到全自动月报的这个过程中踩过的坑基本都写在上面了。