很多人的“收藏系统”一开始都能跑起来，但跑久了会越来越重：
- 每次都全量抓网页
- 每次都重新查表结构
- 分类规则越来越散
- 成功率看起来还行，但速度慢、链路长、难排查
我最近把自己的 Notion 收藏 skill 又整理了一轮，目标不是“功能更多”，而是把它打磨成一条长期可执行、可维护、可审计的链路。
这篇文章就分享这次升级后的思路：怎样把一句“收藏 + 网址”，变成一条真正适合长期使用的自动化流程。
先说结论：最优链路不等于最复杂链路
真正好的收藏链路，不是抓得越多越好，而是：
- 先快速判断应该落到哪个表
- 只提取“够用”的信息
- 尽量直接写入
- 只有失败时才进入回退流程
也就是说，优先级应该是：
- 先路由
- 再轻量抓取
- 再直写
- 最后才回退
这套思路看起来朴素，但它直接决定了收藏系统能不能长期稳定运行。
v1 的问题：能跑，但不够“工程化”
旧版流程当然能工作，但还有几个典型问题：
- 有些网页一上来就抓全文，成本偏高
- 表的 data source 有时每次都重新 search，没吃到缓存收益
- 普通网页和文章页没有严格区分“轻量信息”和“正文补抓”
- 链路虽然成功率尚可，但并不是最短路径
如果只是偶尔收藏几条链接，这些问题不大。
但一旦你想把它当成长期能力，就必须开始关心三个指标：
- 请求数够不够少
- 路径够不够稳定
- 出错时能不能快速定位
我现在采用的 v2 原则
这次升级后，我把收藏 skill 的执行原则收敛成 5 条。
1. 先路由，后抓取
以前很多自动化都会先抓一大段内容，再决定它属于“文章”“工具”还是“社媒”。
现在我反过来：
- 先看 URL
- 再看域名
- 先做大类判断
例如：
github.com→ GitHub 收藏表mp.weixin.qq.com→ 文章收藏表x.com/twitter.com→ 社媒收藏表youtube.com/bilibili.com→ 视频收藏表
只有在 URL 本身不能稳定判断时，才继续看标题和描述补充判断。
这样做最大的好处是：避免不必要的重抓。
2. 先轻量，后补抓
对普通网页、文章页，我现在优先只取这些信息：
<title>og:titlemeta descriptionog:description
这些信息够了，就直接生成：
- 标题
- 一句中文简介
只有在下面几种情况，才去补抓正文：
- 标题拿不到
- 简介拿不到
- 元信息明显是噪音
- 路由还不够确定
这条规则非常重要，因为它决定了系统会不会“默认过度工作”。
3. 先复用稳定配置，再动态搜索
Notion 的表如果已经有稳定的 data_source_id，最优做法不是每次都 search，而是直接复用。
所以 v2 的顺序是：
- 优先复用已知稳定
data_source_id - 直接
POST /v1/pages - 只有直写失败时，才回退到
POST /v1/search
这会让路径明显更短，也更容易 audit。
换句话说：
- search 不是默认动作
- search 是恢复动作
4. 只生成“够用”的信息
收藏系统不是知识库全文归档系统。
它的核心目标其实很简单：未来你回看这条记录时，能立刻知道：
- 这是什么
- 为什么值得留
- 点进去是不是我要的东西
所以标题和简介不需要写得很长。
我现在的规则是：
- 标题：尽量保留页面短标题
- 简介：一句中文，说明“这是什么 + 核心价值”
例如：
- “一篇介绍 AI 工作流设计的文章，重点讲如何把复用优先做成稳定流程。”
- “一个用于整理 Menubar 应用的网站，适合快速发现 macOS 效率工具。”
- “一个 GitHub 仓库，提供用于自动化收藏和路由的 Notion 集成能力。”
这比大段摘要更实用。
5. 默认直写，不查重
很多收藏系统会在写入前做查重、比对、全表读取。
这些动作理论上更“精致”，但对高频使用来说，代价很大：
- 变慢
- 更容易失败
- 调试更复杂
所以我给自己的系统定了一个明确边界：
- 默认直接追加一条
- 不查重
- 不全表扫描
如果未来真的需要查重，再单独设计一条去重链路，而不是把所有收藏都拖慢。
一条更适合长期运行的执行顺序
基于上面这些原则，v2 的标准流程变成了下面这样：
- 从消息里提取 URL
- 根据 URL / 域名快速路由到目标表
- 轻量提取标题
- 轻量提取简介
- 如果信息不足，再补抓一次正文
- 组装统一字段
- 直接用稳定
data_source_id写入 Notion - 如果写入失败，再 search 回退
- 返回简短结果：写到了哪个表、标题是什么
这个顺序本质上就是一句话：
先走最短成功路径，只有失败时才增加复杂度。
为什么我还加了“执行分级”
为了让这条 skill 更好维护，我又把它拆成了 3 档。
S 档：最优直写
满足这些条件时，直接走最短路径：
- URL 类型明确
- 路由明确
- 已有稳定
data_source_id - 轻量信息足够生成标题和简介
这是理想状态，也是应该最常发生的状态。
A 档：轻量回退
当路由明确，但轻量信息不足时：
- 允许补抓一次正文
- 再完成标题和简介生成
这一步仍然是“可控回退”，而不是无限加步骤。
B 档：动态恢复
只有在这些情况下才进入：
data_source_id失效- Notion schema 变化
- 搜索结果不确定
- API 写入报错
到了这一层，才允许：
- 重新
search - 读取更完整规则文件
- 必要时等待人工确认
这样一来，日常高频链路和异常恢复链路就被分开了。
一个很典型的例子：微信公众号文章
比如收藏一篇微信公众号文章，v2 的最优路径应该是：
- 识别域名：
mp.weixin.qq.com - 直接判定：文章收藏表
- 轻量取标题
- 轻量取描述
- 生成一句中文简介
- 直接使用文章收藏表的稳定
data_source_id POST /v1/pages- 返回结果
和“先抓全文、再 search 表、再创建页面”的链路相比，这条路径明显更短。
这个升级真正带来的，不只是更快
我觉得更有价值的是，它把收藏系统从“偶尔能用的小自动化”，升级成了“有明确边界的长期能力”。
因为当你开始明确这些原则之后：
- 你知道什么时候该少做
- 你知道什么时候该回退
- 你知道哪些步骤属于默认路径
- 你知道哪些步骤只是异常恢复
这就是工程化的意义。
不是让系统更花哨，而是让系统更可持续。
最后，给自己留一条可复用模板
如果你也想做一套类似的 Notion 收藏系统，可以直接从下面这条模板开始：
触发：收藏 + 网址
路由：先按 URL / 域名快速分类
提取：先 title / meta / og，信息不足再补抓正文
写入：优先直用稳定data_source_id，失败再 search
字段：名称 / 链接 / 中文简介 / 收藏时间（UTC+8）
策略：默认直写，不查重，不全表读取
反馈：只返回表名和标题
如果你的收藏链路已经能跑，那下一步最值得优化的，通常不是“支持更多网站”，而是让默认路径更短、异常路径更清楚。
这才是一个收藏系统能长期用下去的关键。