信息过载把我逼急了：我给自己搭了个 560 信源的 AI 看板
先说一个我自己的真实场景。
早上睁开眼，AI 圈一夜之间冒出两百多条值得注意的消息。
推特、arXiv、公众号、HackerNews、GitHub Trending、十几个 Discord 群。
同一个事件，二十个信源写了二十遍。
等我筛完，一天已经没了三分之一。
于是我做了一个东西给自己治病：观澜，一个聚合 560+ 信源的 AI 态势看板。
事件聚类、三级分级、每小时视频播报，还有一个具身智能垂直专题。
跑了几个月，今天把它拆开复盘一遍。
定位：看板，不是资讯客户端
市面上不缺 AI 资讯聚合，缺的是态势感知。
资讯客户端解决"读什么"，观澜解决的是"现在 AI 世界的状态是什么、趋势往哪走"。
这个定位推导出三个关键设计：
事件为最小单元——二十篇同源报道聚成一个事件，看时间线就够；
事件分级——critical / warm / info 三档，红色的是真需要立刻知道的；
每小时视频播报——不是为了炫技，是为了通勤时把世界状态"听"完。
而被砍掉的功能更多：翻译、摘要生成、个性化订阅……每一个都问了同一个问题：它帮用户在 5 分钟内建立今天的图景了吗？答不了的，砍。
架构：朴素，但每一环都有讲究
技术栈说出来毫不性感：FastAPI + PostgreSQL 16 + Redis 7 + 原生 JS。
整套跑在我家里一台飞牛 NAS 上（Ryzen 8845HS + 96G 内存 + 六盘位 RAID），通过 Cloudflare Tunnel 穿透公网。
流水线的节拍是这样的：
抓取，每 20 分钟一轮 RSS/API 抓取，信源分级调度；
评分，每 3 分钟一轮 LLM 评分，判断值不值得进事件层；
聚类，相似内容聚合成事件，跨源合并；
产出，每晚 22:10 自动生成日报，每小时生成态势快照和播报视频；
分发，静态前端每 10 分钟 rsync 推到公网服务器，数据 JSON 走带密钥的隐藏路径防爬。
为什么自建 NAS 不上云？算过账：这个产品的重头开销在 LLM API（评分、聚类、摘要），跟部署位置无关；而部署相关的计算带宽成本，上云是大头，自建近乎零。
总账差一个数量级。
聚类，是整个项目最脏最难的坑
"OpenAI 发布新模型"和"奥特曼又放大招"，人一眼就知道是同一件事。
但这两句话，词面上没有任何重叠。
纯 embedding 相似度会把"讨论同一公司"的不同事件错聚到一起。
我最后用的方案分三层：先做实体识别（公司/人物/产品名），再在实体图谱之上做语义聚类，最后让 LLM 做合并仲裁。
准确率上来了，但链路变长、成本变高、延迟变大。
现实就是这样，没有银弹，只有取舍。
视频播报：我给自己下的一个套
每小时自动产出一条 60 秒播报视频，链路是：选出过去一小时 top 事件 → 生成口语化文案 → 合成配音 → 拼接画面 → 推流发布。
很多人以为这是炫技。
其实它是我最满意的设计，因为视频是整条数据流水线的端到端探针。
信源质量差，视频难看；评分漂了，视频难看；聚类错了，视频更难看。
任何一环出问题，视频立刻诚实地反映出来。
现在我判断观澜数据健康度的方法，就是看当天的废片率。
踩坑清单，每条都有尸体
信源二八定律：560 个信源里，贡献 80% 有效信号的只有 60 个左右。后来我上了信源进退机制，按历史贡献率动态调抓取频率，让优者多产、劣者退场。
LLM 评分会漂移：同一个模型，对不同批次内容的打分标准会悄悄漂移。必须用固定校准集定期回归，不然分数慢慢就失去意义了。
脆弱的定制爬虫：曾经为了多覆盖一个渠道写了个定制爬虫，维护成本远超它的信息价值。砍掉那天一身轻松。
隧道静默失联：NAS 重启后隧道没自愈，公网服务挂了而我不知道。后来补了自愈和探针——这事我单独写过，见自部署那篇。
垂直专题返工：具身智能看板是后期加的，因为事件模型一开始没预留"领域"维度，返工了一次。可预见的扩展维度，v1 就该留口。
下一步
事件因果链（A 事件怎么引发 B 事件）、开放 API、把具身智能专题做深——都是这条链路的自然延长。
如果你也被信息过载折磨，可以去 wen.pmparker.net 看看观澜的实际效果。
信源推荐、产品吐槽、或者你就是想聊聊怎么治信息焦虑，随时找我。