AI 热点监控工具采用前后端分离加定时任务引擎驱动的分层架构：前端 React + Vite 负责展示，后端 Express 5 + TypeScript 提供 REST API 与 WebSocket 实时通道，采集层以 8 个以上数据源并行抓取，AI 分析层通过 OpenRouter 统一接入大模型做真假识别、相关性评分与重要性分级，最终由通知层把高价值热点推给用户。模块划分遵循”采集与业务解耦、AI 能力插件化、通知可独立开关”三条原则，这是我在做这个项目时反复调整后确定的边界。
一、整体架构的分层思路
架构图自上而下可以拆成四层加一个旁路调度器。前端层只消费接口和 WebSocket 事件，不感知数据从哪来；后端把业务、采集、分析、通知四个域拆成独立模块，各自有明确的职责边界；调度器用 node-cron 驱动整个流水线，每 30 分钟跑一轮”采集 → 清洗 → AI 分析 → 落库 → 推送”。
| 层级 | 技术选型 | 职责 |
|---|---|---|
| 展示层 | React 19 + Vite + Tailwind CSS | 热点雷达、列表、筛选、排序 |
| 接口层 | Express 5 + Socket.io | REST API 与 WebSocket 实时推送 |
| 业务与调度层 | node-cron 定时任务引擎 | 触发采集、分析、通知全流程 |
| 存储层 | Prisma ORM + SQLite | 关键词、热点、通知的持久化 |
| AI 分析层 | OpenRouter（DeepSeek / Claude / GPT） | 查询扩展、真假识别、评分分级 |
采集与 AI 分析没有耦合在业务接口里，而是由定时任务异步驱动。这样即使用户正在刷新列表，采集进程也不会阻塞接口响应，SSE 之外的热点刷新走 WebSocket 广播，前端不需要轮询。
二、六大核心模块的划分
2.1 关键词管理模块
用户添加监控关键词后，系统先做 AI 查询扩展（Query Expansion），把”AI 编程”扩展成”AI 编程助手、大模型 IDE、AI 写代码”等多个查询变体，再写入关键词表。模块提供激活、暂停、删除三个状态操作，暂停的关键词不参与下一轮采集。
2.2 多源采集模块
这是架构里最重的一块。采集模块按数据源类型抽象成三种接入方式：有官方 API 的走 API（Hacker News Algolia、B 站公开接口、TwitterAPI.io），没有 API 的走网页爬虫（Bing、搜狗搜索结果页用 Axios 抓 HTML 再交给 Cheerio 解析），RSS 订阅源单独走 RSS 解析器。每个数据源实现同一个 Collector 接口，新增一个源只写配置和解析函数，不改核心代码。
2.3 AI 分析模块
采集到的原始条目先做轻量级文本预过滤（匹配关键词命中），命中的才交给大模型做四件事：真假内容识别、相关性评分（0–100）、重要性分级（urgent / high / medium / low）、智能摘要生成。OpenRouter 做了一层 Provider 无关抽象，换模型只改配置不改业务代码。
2.4 热点展示与筛选模块
前端雷达仪表盘展示实时统计，列表支持最新发现、最新发布、重要程度、相关性、热度综合五种排序，来源、重要性、关键词、时间范围四个维度筛选，分页加载。相关性分析理由展开 / 折叠，方便用户判断这条热点为什么被推上来。
2.5 通知模块
Socket.io 向在线浏览器实时推送新热点；邮件通知走 SMTP，只对 high / urgent 级别触发，避免噪音；站内通知维护已读 / 未读状态。通知策略可配置，重要级别阈值改了立刻生效。
2.6 Agent Skills 模块
项目把采集脚本与分析框架封装成完全自包含的 AI 技能包，可在 Cursor、VSCode Copilot、Claude Code 等工具里直接复用，脱离 Web 服务也能单独跑采集。
三、一轮采集的完整执行流程
整条流水线由定时任务触发，具体步骤如下：
- node-cron 按间隔触发采集任务，读取所有 active 状态的关键词；
- 关键词先送 OpenRouter 做查询扩展，生成多个变体；
- 采集模块按数据源配置并行抓取，统一做超时与重试控制；
- 原始条目做预过滤，标题或摘要命中关键词的进入候选集；
- 候选集交给 AI 分析，输出真假结论、相关分、重要性级别与摘要；
- 结果去重后写入数据库，通过 WebSocket 广播新热点；
- high / urgent 级别的热点再触发邮件通知。
四、模块边界设计的三个要点
第一，采集与业务解耦。采集器只负责拿数据，不碰数据库写逻辑，写库统一走服务层，出问题时能单独摘掉某个源而不影响整个系统。第二，AI 能力插件化。OpenRouter 的抽象让换模型、降级到启发式模式（无 Key 时按热度阈值粗筛）都只改一个配置文件。第三，通知可独立开关。邮件、WebSocket、站内通知各自独立，环境变量控制，本地调试时可以全关。
这套结构最大的收益是扩展成本低。项目后期新增了小红书、掘金两个源，每新增一个源只写一个实现了 Collector 接口的文件加一段配置，整个系统零改动上线。
常见问题（FAQ）
Q1：热点监控工具必须用前后端分离吗？
不一定，单机用 Express 直接渲染页面也行，但分离后采集任务和接口互相不阻塞。
Q2：定时采集间隔设多少合适？
30 分钟一档兼顾实时性与成本，热榜类源可单独调短，接口类源注意限速。
Q3：AI 分析挂了会不会拖垮整个流程？
不会，采集与入库先完成，AI 分析失败只标记未分析，不影响列表展示。
