不知道你们有没有这种状态手机里截图一堆、浏览器书签几十个、微信收藏里躺着一大堆“稍后读”但真到写月度总结或者做分享的时候什么都找不到。我折腾 YuE 这个项目的初衷就是想把散落在各个角落的信息统一收拢让它们真正能被我自己的思考用起来。简单说YuE 是一个本地优先、开源的个人知识库管理工具核心思路不是“多记一笔”而是“少丢一个线索”。这篇文章我会把整个项目的定位、架构、实操步骤和踩坑记录原原本本拆给你看适合正在纠结怎么做个人知识管理、或者想自己造轮子整合信息源的朋友。YuE 全称是Your unread Echo有点文艺但说白了就是“你那些还没被翻过的回声”。我做它的直接原因是市面上的笔记软件各有各的围墙有的支持 Markdown 但没有好的全文检索有的能剪藏网页但移动端体验稀烂有的同步很快但数据格式私有化严重。我理想中的工具应该满足三个条件数据完全握在自己手里、抓取方式足够自由、检索结果足够“聪明”。所以我不打算再等别人把功能做全干脆自己写了 YuE把常见的信息流网页剪藏、微博收藏、微信公众号文章、本地 PDF、语音备忘统一收进一个本地仓库再做一层轻量的标签和全文检索最后生成周报式的回顾清单。如果你也想搭一套“自己能掌控”的知识库或者单纯对桌面端工具的架构选型、数据库方案、检索优化感兴趣这篇文章应该能给你不少可以直接抄作业的东西。1. 项目定位与设计初衷1.1 是什么一句话讲清 YuEYuE 本质上是一个跑在本地桌面端的“信息聚合与再发现”工具。它不像 Notion 那样从一块空白页面开始让你慢慢整理而是反过来先把信息从各个源头抓进来再用自动化规则帮你归类、打标签、建索引最后通过搜索和周报的形式倒逼你去“回看”。一句话概括就是收集足够野蛮检索足够快速回顾足够省心。技术栈上YuE 使用 Electron 搭建跨平台桌面壳前端框架选了 Vue 3后端逻辑跑在 Node.js 上数据存储采用 SQLite 配合 FTS5 全文搜索模块。为什么选这套组合后面我会专门解释。这里先给你一个感性的认识它安装之后是一个普通的桌面应用双击打开左侧是信息源列表中间是内容流右侧是预览和标签面板很像一个“本地版稍后读 自托管知识库”的结合体。1.2 解决什么问题信息过载与知识碎片化我先说一个场景你白天在公司看到一篇讲“分布式事务”的好文章微信收藏了通勤路上刷到一条关于“大模型 RAG 落地”的微博顺手截图晚上回家又想起来了把文章链接丢进了 Telegram 的 Saved Messages。一周之后你想写一篇技术博客发现自己要同时打开微信、微博、Telegram、浏览器书签四个地方才能把素材找齐而且其中一半内容你已经忘记当时为什么收藏了。这就是典型的知识碎片化信息本身不稀缺稀缺的是“把信息从收藏夹里捞出来”的能力。YuE 要解决的就是这个问题。它把不同来源的信息统一转成标准的数据结构标题、正文、来源链接、抓取时间、标签然后落到本地数据库里。你不需要再关心某条内容存在哪个 App 里只需要问 YuE“我跟分布式事务相关的素材有哪些”它会在几十毫秒内把相关内容全部列出来。1.3 为什么不直接用现成的笔记软件这个问题我几乎被每个朋友问过。说实话Notion、印象笔记、Obsidian 各有优势但我个人的核心痛点在于三点数据私有性我不想把几年的知识积累放在一个我无法完全控制的云端服务上万一服务调整策略或者账号出问题风险太大。采集链路的封闭性很多笔记软件的网页剪藏依赖官方插件遇到反爬严格的站点就抓不下来而且移动端“分享到笔记”这个动作经常失效。检索的智能化不足普通的标签系统太机械全文搜索又往往只是简单的关键词匹配缺少“标题匹配优先、正文匹配其次、综合时间衰减排序”这类更贴近真实使用习惯的逻辑。YuE 的选择是用开放的格式SQLite 数据库 纯文本导出保存数据用可编程的抓取规则替代固定的剪藏插件用可调的排序算法做搜索结果排名。它不追求功能大而全但保证你能“折腾得动”。2. 整体架构与核心技术选型2.1 架构总览本地优先、插件化输入、全文检索引擎YuE 的整体架构可以拆成四层采集层、处理层、存储层、展示层。采集层负责对接不同的信息源。我一开始只写了网页剪藏后来陆续加了微信公众号文章的自动导入通过复制链接触发抓取、本地 PDF/Word 文档的批量导入、微博收藏的 JSON 文件解析。处理层拿到原始内容后做三件事把 HTML 转换成干净的正文文本、提取关键词生成候选标签、计算内容指纹用于去重。存储层就是我前面说的 SQLite FTS5所有数据都存本地不强制同步。展示层是个单页应用提供搜索、筛选、时间线、周报四个主要视图。这个架构最大的好处是“边界清晰”。采集层和处理层是松耦合的新增一个信息源只需要写对应的采集器不影响其他模块。存储层用 SQLite 这种嵌入式数据库省去了单独搭建数据库服务的麻烦数据文件就是一个.db文件备份和迁移都非常简单。2.2 为什么选 Electron SQLite 这套组合先坦白Electron 这几年没少被人吐槽体积大、内存占用高。但我依然选了它核心原因是生态成熟度和开发效率。YuE 的定位是“个人工具”不是面向百万用户的平台级产品所以我更在意的是能不能用一套代码覆盖 Windows/macOS/Linux能不能快速调用 Node.js 生态里现成的解析库比如读取 PDF 的pdf-parse、处理 HTML 的cheerio。SQLite 的选择则更多是出于“省心”。它不需要单独装服务不需要运维一个文件就是整个数据库。加上 SQLite 自带的 FTS5 全文搜索扩展做中文全文检索只需要在创建表的时候加上tokenize unicode61或者直接分词逻辑比引入 Elasticsearch 这种重型方案轻太多。个人项目最重要的就是“别给自己找麻烦”SQLite 恰好满足了这一点。当然Electron 也有坑比如后续打包体积会到 80MB 以上首次启动稍微慢一点。但这些在“可控”的范围内真跑起来之后日常使用没有明显短板。2.3 核心模块拆解采集、处理、组织、检索采集模块是我觉得最值得说的部分。网页剪藏不能简单地把 HTML 存下来因为页面里塞满了导航、广告、推荐位之类的噪音。YuE 的做法是用cheerio加载 HTML然后根据预设的正文提取规则比如优先找article、main标签退回到div加特定 class提取出干净的正文同时记录来源链接和抓取时间。处理模块负责打标签和去重。打标签不是靠硬编码规则而是用一套“词频 位置加权”的简单算法把标题里出现的词权重加高正文里反复出现的词次之。比如一篇文章标题里有“RAG”正文里“检索”“增强”“生成”出现了很多次系统就会自动贴RAG、检索这类标签。去重则是计算内容的 SimHash 指纹相似度超过某个阈值就自动标记为“重复”。组织模块是 YuE 区别于普通笔记软件的亮点。所有内容进入数据库后会按照“来源”和“标签”两个维度建立索引视图。同时我设计了一个“时间衰减权重”离今天越近的内容在搜索结果里的排序越靠前2019 年收藏的和昨天收藏的即便关键词完全一致排序也完全不同。检索模块使用了 FTS5 的 MATCH 语法做关键词查询再配合一段自定义排序公式score bm25_score * 0.6 freshness_score * 0.3 title_match_score * 0.1。实测下来中文分词的效果比纯 LIKE 查询好很多尤其搜一些技术术语时准确率提升明显。3. 核心功能实操从安装到日常使用3.1 环境准备与安装YuE 目前在 GitHub 上开源安装分“开发者模式”和“打包安装”两种。如果你只是想先体验一把可以直接下载 releases 里的安装包。如果打算二次开发则需要先准备好这些环境Node.js 16 以上我长期用 18 LTS没遇到问题npm 或 pnpmPython 3.8 以上只有启用 PDF 解析增强插件时需要克隆代码之后在项目根目录执行npm install npm run dev然后应用就会以开发模式启动窗口标题栏会显示 “YuE Dev”数据默认存放在用户目录下的~/.yue/data.db。npm run dev本质上是并行启动了 Electron 主进程和 Vite 开发服务器所以你在前端代码里做任何改动都能立刻热更新。如果你用打包版安装完第一次启动会在当前用户目录自动建好数据结构这一步不需要任何手动操作。3.2 五步完成你的第一条内容采集安装完成后第一次录入信息我建议按这个顺序走一遍过程比较顺第一步打开一个你觉得写得不错的网页复制它的 URL。第二步在 YuE 左下角的采集框里粘贴 URL点“抓取”。这时候采集模块会启动几秒钟后右侧预览区会显示提取出来的正文。第三步确认正文没有明显遗漏某些站点做了懒加载抓到的可能是空内容这种情况后面我再说怎么处理。第四步手动微调标签。系统自动生成的两个标签可能不够准确比如一篇讲“PostgreSQL 死锁处理”的文章只打了数据库你可以手动改成PostgreSQL和死锁。第五步点击“入库”。内容正式写入 SQLite之后就能被搜到。整个过程熟练之后不到三十秒。我自己现在每天的固定动作就是刷到好文章复制链接粘贴入库三连。晚上睡觉前打开“今日新增”看一眼不需要当场消化。3.3 自动标签、去重检索与周报三个最有用的功能自动标签我用“词频 标题加权”的方式生成了候选标签但说实话纯靠它不可能做到完全准确。我的经验是把它当成“首版草稿”入库前手动快速过一眼多半只需要增删一两个词。自动标签省掉的是你从零开始思考“这段内容该归在哪”的时间。去重检索同一篇文章可能先被你看过网页版过几天又在公众号里刷到。如果两条都入库搜索结果里就会出现高度雷同的两条。YuE 的做法是入库前计算 SimHash相似度超过 0.92 的会弹提示“相似内容已存在是否仍然入库”我一般选“否”这样库里不会堆一堆重复内容。但如果你想保留不同平台的评论也可以强制入库。周报这是我最喜欢的功能。每周日晚自动生成一份“本周回顾”内容包含本周新增了多少条信息、按标签聚合的占比、本周高频关键词、以及“已沉睡超过 60 天的高价值内容”列表。最后那一项特别有用它会提醒你有些好文章收藏之后就再没打开过。周报会生成一个 Markdown 文件可以手动整理成博客或者直接存库。4. 部署中的关键配置与参数调优4.1 工作空间初始化与目录结构YuE 启动后会在用户目录自动生成.yue文件夹下面是默认的目录结构.yue/ ├── data.db # 主数据库SQLite ├── config.json # 用户配置 ├── attachments/ # 图片、PDF 等二进制附件 ├── exports/ # 周报导出目录 └── logs/ # 运行日志我建议不要把attachments目录改到系统临时盘因为附件会包含你收藏的 PDF 和图片放临时盘容易被系统清理。默认配置已经够用但如果你在多台设备之间同步我会建议用同步盘比如 Syncthing 或坚果云直接同步整个.yue目录比导出再导入省事。4.2 仓库配置与搜索参数调优核心配置在config.json里初次打开大概是这样的{ dataDir: .yue, search: { bm25Weight: 0.6, freshnessWeight: 0.3, titleBoost: 0.1, freshnessHalfLife: 30 }, tagging: { enabled: true, maxTagsPerItem: 10, minWordFrequency: 2 }, watcher: { enabled: true, watchClipboard: true, watchFolder: ~/Dropbox/Inbox } }重点说一下三个最值得调的参数freshnessHalfLife时间衰减的半衰期按天算。默认 30 表示 30 天前的内容新鲜度权重降为原来的一半。如果你更看重近期内容建议调到 14不然 30 天太久一些干货很容易被压下去。bm25Weight这是全文检索排序里最核心的权重。如果你经常搜技术方案、需要精确匹配建议调到 0.7如果更看重“最近看过的内容优先”就调低 BM25 权重。watchClipboard开启后监控系统剪贴板复制到剪贴板的文本如果超过 20 个字会作为待入库草稿弹出来。这个功能对经常复制代码片段的人很友好但如果你复制频繁可能会觉得打扰可以根据自己的习惯开或者关。还有一段经验之谈修改config.json后不需要重启应用它会监听文件变更并热更新。只有改了dataDir这种路径级配置才需要重启。4.3 同步方案与隐私考虑YuE 默认所有数据都在本地不上传任何云端。这是隐私性最好的选择。但如果你需要在公司电脑和家里电脑之间共享就需要自己规划同步方案。我实测过的方案有三种Syncthing 同步整个.yue目录免费、去中心化推荐首选。但注意两台电脑不能同时打开同一个数据库文件否则 SQLite 会报database is locked。我一般只在一台电脑上开库另一台只读。坚果云/网盘同步配置简单但坚果云对非文本文件的同步有时会滞后。建议只同步data.db不同步attachments。Git 私有仓库适合有编程习惯的人。每天定时git add -A git commit好处是每次修改都有历史记录能回溯到任何一天的数据状态。隐私方面有一个细节提醒如果关闭.yue目录的写权限某些系统索引服务比如 macOS Spotlight可能会去扫描数据库文件并生成缓存但那也仅限于本地。YuE 自身不做任何遥测统计也不内置广告和三方跟踪代码。5. 常见问题与排查实录5.1 抓取网页时总抓到广告或空白内容我遇到最多的就是这类问题。某些网站的正文不是服务端渲染的而是前端通过 JavaScript 动态加载cheerio拿到的 HTML 里根本没有正文数据。这是静态抓取方式的天然短板。解决的思路有两个第一在抓取设置里给该域名配置“延迟等待”让抓取器多等几秒再提取正文第二如果站点有完整的 RSS/Atom 输出我会优先用 RSS 抓取正文提取的成功率会高很多。另外也可以给抓取器配置puppeteer模拟浏览器但代价是每次抓取要起一个 Chromium 进程慢且吃内存。我的建议是只给确实需要的少数站点开这个模式不要全局启用。5.2 数据量大了之后搜索明显变慢当入库内容超过 1 万条时有些人会发现搜索速度从几十毫秒掉到几百毫秒。这种情况大概率是 FTS5 索引没有跟上或者你在配置里把fts表删了。可以定期跑一次数据库优化命令sqlite3 data.db INSERT INTO items_fts(items_fts) VALUES(rebuild);这条命令会重建全文字段索引。另外也建议定期执行VACUUM清理空洞数据如果数据文件膨胀得厉害执行完效果会非常明显。5.3 数据库锁定的奇怪报错SQLite 在单用户本地使用场景下极少报错但如果你开了同步盘比如坚果云或者同时开了多个实例就会遇到SQLITE_BUSY或database is locked。排查思路很直接关掉所有其他可能占用data.db的程序确认同一时间只有一个 YuE 实例在写数据。如果还是锁检查是不是把数据库文件放进了某些会做文件锁的同步目录。经验是把data.db排除出实时同步白名单改成每天定时同步基本就解决了。5.4 周报没有生成或内容为空周报生成依赖一个后台定时任务默认是每周日晚 22:00。如果你电脑那个时间点是关机状态周报任务会被跳过。解决方案有两种第一种在配置里把周报触发时间改成你通常在线的时段第二种使用“手动生成”按钮随时强制触发一次。还有一种情况是周报内容为空多半是因为“近 7 天新增”查询条件里的时间戳和本地时区不一致。可以检查系统时区是否为 UTC8或者在配置里显式设置timezone: Asia/Shanghai。下面是我整理的常见问题速查表问题现象可能原因解决方式网页抓取为空前端 JS 动态渲染启用 Puppeteer 抓取或换 RSS 源搜索速度变慢FTS5 索引碎片化执行rebuild重建索引database is locked多实例或同步盘占用关闭其他实例排除同步文件锁周报未生成定时任务错过手动触发或修改触发时间中英文混排搜索不准分词不够细自定义分词插件或拆分关键词搜索PDF 导入乱码扫描版 PDF 无文本层先做 OCR 再导入6. 一些踩过坑后的心得与技巧折腾 YuE 这段时间最大的体会是工具本身只是骨架真正有价值的是你围绕它建立的“工作流”。很多人以为装一个知识库软件就能治好收藏强迫症其实不然。软件只能帮你把信息“存下来、找得到”但“想得起、用得上”还是需要你自己设计一个回顾机制。我现在是一周看一次周报两周清理一次低价值标签每个月挑三篇库存内容写成真正的笔记或文章。这套节奏跑下来收藏的东西才算真正活起来了。另外有一个小技巧值得分享在配置里打开watchClipboard后我在电脑上复制任何超过二十字的文字YuE 都会问我要不要入库。最开始觉得它烦后来发现这个轻微的“打扰”反而是好事。它逼着你在复制完一段内容后下意识地做一个“这值不值得存”的判断而不是无脑收藏。经过一段时间之后入库的内容质量明显比从前高检索时的“噪声”也少了很多。最后再聊一个后续可扩展的方向YuE 目前已经能跟 Readwise、Instapaper 这类服务的导出文件做对接我下一步准备把 Telegram 的收藏频道也接入采集层这样整个信息流的闭环会更完整。若你也在搞类似的知识管理工具或者只是对本地优先的架构感兴趣欢迎基于这篇记录去延展自己的版本。工具是死的流程是活的拿我的经验去打底你一定能跑出更适合自己的一套玩法。