为什么还在用 RSS

算法推荐越做越聪明，我反而把信息摄入退回 RSS 了。原因很实际：推荐流会替你决定看什么，而 RSS 只把你订阅的东西按时间摆出来，不插队、不藏、不因为互动低就不推。做技术的人需要的是确定性和可回溯，这两点 RSS 都给得了。这一组放的既是阅读器，也是我筛出来的信息源清单。

它和导航页其它组还有个区别：别的组是按需打开，这一组是每天被动接收。所以质量要求更高，收错一个源，代价不是多点一次，而是连续几周被无关内容占掉注意力，我删源比加源勤得多。

常驻的站点和各自角色

  • 自托管或桌面 RSS 阅读器：所有订阅的落点。我要求它支持全文抓取、按文件夹分组、以及标记稍后读，这三条缺一条就会退回开一堆标签页。
  • 官方博客与变更日志页：语言、框架、云厂商的发布说明。版本里改了什么、废弃了什么，只有官方 changelog 最准，我给每条都单独订阅而不是订阅首页，避免被无关文章冲淡。
  • 技术团队的工程博客：看别人踩过的真实坑，比教程有价值。数量控制在十个以内，多了读不完反而有负担。
  • 邮件周刊转 RSS 的聚合工具：把一些只发邮件、不给订阅源的周刊转成 RSS，统一进阅读器，不另开一个收件箱。
  • 订阅源查找与校验工具：站点没明给地址时找一下，以及订阅前验证源是否还有效，季度清理时全靠它。

留在书签栏的理由是不放过任何一次版本变更。我吃过亏：一个依赖悄悄改了默认行为，等我发现时已经写坏了两处逻辑，事后翻官方 changelog 才发现那条更新三个月前就发了。从那以后，主力技术栈的发布页一律单独订阅，并且和工程博客分层放，发布页的未读我当天清，博客按周翻。

我怎么控制信息量

分组比退订更重要。我把订阅分成三层：必读，放官方发布和安全公告；选读，放工程博客和周刊；存档，留着全文搜索但不进日常列表。阅读器里只有必读层开未读计数，其余按周批量翻一次标题。这样每天真正要处理的通常不到二十条，不会一打开就几百条未读然后干脆全标记为已读。

另外每条订阅我都会写一句备注，记下当初为什么订它，半年后清理时一眼能判断还值不值得留。订阅源失效是很常见的，站点改版、换域名、关掉 RSS 都会让订阅静默死掉，所以每季度我用校验工具跑一遍，把连续三个月没更新的源单独看一遍，该删就删。阅读器本身也要能导出数据，我不想再被任何一个平台绑住，这一点和我的笔记用纯文本存是同一个道理。

RSS 不是为了多读，是为了少读且读得准。一个干净、按时间排列、能搜能存的收件箱，比任何智能推荐都更适合长期做技术积累。