起点 · 课程作业，方向调整
先做过移动端 SwiftUI 原型，很快意识到「网页收藏」这个场景天然发生在浏览器里——让用户复制链接再切到另一个 App，流程就断了。于是转向 Chrome 扩展。
SYSTEM · CASE STUDY
Bookmark
书签助手 · 收藏的瞬间，遗忘就开始了。
把浏览器书签变成可对话的知识库：自动聚类、语义搜索、RAG 问答；Chrome 扩展直接读现有书签，零迁移成本。我关心的不是收纳，是「再次被用上」。从课程作业的小 demo，迭代成一个评测驱动的 AI 产品原型。
Demo
展示在网页中保存当前内容、自动生成标签，并从「今日回顾」重新打开收藏的扩展流程。
项目背景（问题）
收藏夹是最典型的「信息垃圾填埋场」：只进不出。人们在小红书、知乎、掘金和各类网站上收藏「想稍后再看」的内容，但绝大多数在保存的那一刻就被遗忘——过段时间既想不起当初为什么收藏，也无法按主题重新找到。
这个项目要解决的不是「存不下」，而是「存了取不回、也从不回看」。
定位 · 一次产品重定义
用户真正的痛点不是「分类不准」，而是「存了就忘」。于是我把核心价值重新定义——从「更好的文件夹」转向「主动帮你重新想起」。
✗ 原来的方向：整理
做一个「更好的文件夹」——把分类、搜索做准。本质还是等用户主动回来翻。
✓ 重定义后：回顾
引入间隔重复式的「今日回顾」作为核心，主动把遗忘的收藏推回来；分类与搜索退为支撑能力。
项目演进 · 从课程 demo 到 AI 产品
早期版本 · 闭环通了，但很弱
能一键保存、抓正文、启发式摘要、关键词匹配分类、本地 JSON 存储。核心闭环通了，但分类很差、检索只能靠标题关键词。
深化为 AI 产品 · 围绕重定义的问题重做
- 产品重定义：核心从「整理」改为「主动回顾」，今日回顾成为第一入口。
- 重建数据层：SQLite 四表把「原始页面 / AI 衍生 / 用户行为 / 向量」分离——改进分类器只重跑 AI 层、换模型只重算向量层，都不丢用户已读/收藏状态。
- 升级 AI 能力：用 LLM 按固定 taxonomy 分类替代关键词表；用 embedding（BGE-M3，本地运行）做跨语言语义搜索与相似推荐。
- 建立评测体系：标注数据集 + 逐类指标，用数据而非直觉驱动迭代。
这是把项目带出「作业范畴」的一步：围绕一个重新定义过的问题，把小 demo 重做成能持续迭代的 AI 产品。
架构 · 后端做大脑，客户端做薄采集
扩展只负责交互和网页内容提取，后端负责富化、向量化、排序与存储。好处：AI 逻辑收敛成一份、API key 不进插件代码、无 AI 服务时插件仍可用、未来加移动端只是多一个调后端的客户端。
Chrome 扩展（薄采集）
popup / 快捷键 / 页面浮动按钮 · 网页内容提取
↓API
Python 后端（大脑）
富化 · 分类 · 摘要 · 向量化 · 排序
LLM 优先 → AI 不可用时降级本地规则（仍返回真实分类，而非全 Other）
↓
数据层 · SQLite 四表分离
原始页面
AI 衍生
用户行为
向量
改进分类器只重跑 AI 层、换模型只重算向量层——都不丢用户的已读 / 收藏状态。这是「能持续迭代 AI 而不破坏数据」的前提。
核心功能
- 一键保存（popup / 快捷键 / 页面浮动按钮），自动抽取标题、正文、og 元数据（描述、封面、作者、阅读时长）
- LLM 自动分类（15 类固定 taxonomy）+ 摘要 + 关键词；AI 不可用时降级本地规则
- 来源识别（知乎 / 微信 / 小红书 / 掘金 / 通用网页）
- 今日回顾：按「未读 × 时间衰减」评分主动推送，支持「打开 / 稍后 / 不看了」
- 语义搜索：用一句话的意思检索（中文 query 命中英文文章，反之亦然）
- 相似推荐：查看某条时展示「相关收藏」
- 独立管理页：搜索、来源 / 分类筛选、删除与撤销
测评 · 一次评测驱动的根因定位
一度「分类几乎全是 Other」，第一反应是「模型不行、该换模型」。但我先建了标注评测集用数据定位，发现真凶是配置 / 降级链路的 bug（后端没读到 key、直接把一切打成 Other），而非模型能力。修好后再用逐类指标发现并修复了总分掩盖的类别回归——全程不 train-on-test。
57% → 96%早期标注集 · 配置 bug 修复前后
98.2%当前56条 · LLM 分类路径（macro F1 0.98）
92.9%当前56条 · 本地关键词分类器（macro F1 0.88）
56 / 14条人工标注 / 类别（中英混排 + 边界样本）
94.6% → 98.2%当前56条 · prompt 消歧修复类别回归（Product F1 0.40→0.89）
CI带准确率门槛的冒烟测试
核心想法也被验证：网页收藏一旦加入内容提取、语义检索和主动回顾，会比传统书签明显更容易被「再次用起来」。
成长与反思
「功能完整」不等于「产品可用」
早期我盯着「能不能接上 AI、能不能生成摘要」，实测后才明白：用户首先要的是稳定保存、快速找回、清晰管理；AI 是增强，不是地基。这直接体现在「LLM 优先 + 本地降级」的设计上。
不被表象带偏——用评测找根因
「分类全是 Other」时先用早期标注集量化归因，定位到是配置 bug 而非模型能力（本地 57%→96%）；扩充到当前56条后，本地分类为92.9%、LLM路径为98.2%。先量化、先归因，再动手。
逐类指标能看见总分掩盖的问题
整体准确率看着没问题，但逐类 F1 暴露 LLM 在 Product 类崩到 0.40——是 taxonomy 边界设计问题，不是模型问题。用给 prompt 加类别定义消歧（刻意避免拿测试样本调参），整体回到 98.2%。
工程与安全意识 · 范围控制
API key 从写死改为 .env + .gitignore；CORS 从全开收紧到只允许扩展来源；加 CI 与准确率门槛的冒烟测试。整理杂乱的原型/demo，只把完成度最高的浏览器插件版本作为正式仓库发布。
局限性 & 下一步
局限性
本地单机服务，未做多用户 / 云同步 · 回顾评分是手调启发式，未用真实行为校准 · 推荐仅到「相似条目」 · taxonomy 固定 15 类。
下一步
兴趣聚类 + 用 review_log 行为信号优化回顾排序 · 回顾节奏 A/B 校准 · 埋点北极星指标（每周「被回顾并读完」数）· 多端采集与云同步。
技术栈
Chrome Extension (Manifest V3) · JavaScript / HTML / CSS · Python 后端 (SQLite) · LLM (NVIDIA API, Llama 3.1) · Embeddings (BGE-M3 / sentence-transformers) · scikit-learn（评测）· GitHub Actions（CI）