原则（一句话）#

要采集某类信息，先问它有没有原生 RSS / API，再问 RSSHub 等聚合器，再问浏览器手动存档，最后才是爬虫。

为什么#

橘鸦原文理由就三条，很朴素但经得起推：

1. 很多站原生就有 RSS（LINUX DO、Reddit 等）
2. 没原生 RSS 的主流站，第三方方案基本成熟（RSSHub）
3. RSS 通过 XML 交换，结构化、保留样式——爬出来还得自己清洗结构

爬虫的隐性成本除了反爬，还有「清洗 + 去重 + 样式补回」的活儿，这些时间没体现在工时里但都在账上。

何时调用#

• 「我要 X 类资讯 / 数据 / 公众号 / 博客的内容」
• 「帮我监控 Y 的更新」
• 「抓 Z 网站的内容汇总成 M」
• 任何「持续 / 批量 / 跨源」信息采集任务的第一步

怎么做（决策树）#

1
有原生 RSS / API？
2
  ├─ 是 → 直接订阅
3
  └─ 否 ↓
4
RSSHub / Feedbin / RSS.app 等聚合器能转？
5
  ├─ 是 → 配置路由
6
  └─ 否 ↓
7
Obsidian Web Clipper / 浏览器手动存档？
8
  ├─ 是 → 元信息 + Markdown 存档
9
  └─ 否 ↓
10
才考虑爬虫（且优先官方 API > 第三方 > 自写）

反例 / 边界#

• 实时性要求极高（分钟级）+ 无官方推送 → RSS 不够，得 WebSocket / 轮询
• 需要登录后才能看到的内容 → 浏览器手动存档 + cookies 复用是唯一稳妥路径
• 站内搜索 / 特定聚合视图（如「今日热榜」）→ 通常没有 RSS，但 RSSHub 多数能路由

关联原则#

• 03-信息护栏：有了干净数据源，下一步是过滤
• 02-Workflow编排：采集到处理之间，这一段是窄 AI 跑得最稳的