搞知识工作的人大多都有个共同毛病信息来得太快自己记得太慢。看到一篇好文章先收藏读到一句有用的话复制到备忘录遇到一段关键代码截个图扔进文件夹。结果攒了大半年收藏夹成了黑洞备忘录里全是断头句子截图文件夹更是从来不会打开第二次。我一直在维护一个叫knowledge-work-plugins的自用插件合集目的不是造一个大而全的效率工具而是把知识工作里最常出现的几个断点——信息收集、内容检索、摘要打标、自动归档——用一组轻量插件串起来。整套体系跑下来最直观的变化不是存得更多了而是存完之后真的会回头再看。这篇文章就把这套插件的设计思路、核心实现和踩坑过程完整拆开讲一遍。如果你是搞研究、做分析、写技术文档的人或者只是日常被信息淹得喘不过气的普通打工人里面这套收集-索引-摘要-联动的框架都可以直接抄走。1. 收集环节为什么看到就存比看完再存更能留住信息1.1 最原始的复制-粘贴-整理为什么低效我过去收集信息的方式非常原始看到有用的段落鼠标选中复制切到笔记软件新建文档粘贴起标题找分类放进去。这套流程看起来很严谨实际上每执行一次都要消耗大概二三十秒的上下文切换成本。更致命的是这种操作会打断你正在进行的深度思考——本来在读一篇论证严密的文章突然为了记录一段话切走注意力回来时思路已经断了。后来我试着看完再存但人类对信息的判断力远没有自己想象中可靠。一篇三千字的文章读完后你可能觉得整体很有启发但具体哪段话值得存、哪个数据点以后要引用当时的记忆已经开始模糊。到最后往往整篇保存或者干脆不存。两个极端都让知识管理变成摆设。1.2 MarkKeeper 的字段设计来源、时间、标签与上下文所以我在 knowledge-work-plugins 里做的第一件事是给浏览器装一个叫MarkKeeper的收集插件。它的核心思路是把你从复制-粘贴-整理这个三步操作里解放出来只保留最关键的选中-锚定-确认三个动作。选中一段文字后按快捷键MarkKeeper 会立即弹出一个小窗里面自动带上了几项信息原文的 URL、页面标题、采集时间和一个可编辑的临时标签。你只需要按一下回车这一段文本就会带着这些元信息一起落到本地的一个 Markdown 收件箱文件里。整个过程三秒以内不用切换窗口不用思考分类。这里值得多说一句字段设计。很多人做笔记只存正文这是个大坑。一条信息如果没有来源、没有时间、没有上下文存储三天之后就会变成无源之水。MarkKeeper 强制带上 URL 和标题看起来只是多记两个字段实际上给后续的溯源和去重留了命根子。我在字段里还留了一个上下文选项默认截取选中文字前后各 200 个字符目的是避免以后看到一条孤零零的句子时不知道它原本在论证什么。{ id: 20250207-001, type: text-selection, title: 关于长期记忆与工作记忆的研究综述, url: https://example.com/papers/working-memory, captured_at: 2025-02-07T09:30:0008:00, tags: [认知科学, 待整理], context: ...前文提到工作记忆容量有限...正文内容...后文进一步指出..., content: 工作记忆的容量约为 4±1 个组块且受到任务复杂度的显著影响。 }这份 JSON 最后会被追加进收件箱 Markdown 文件的对应用例区块里。为什么不用数据库因为在收集阶段数据库的强约束反而是负担。Markdown 文件人人可读、可 diff、可手动修改出了问题随时能救回来。数据从收集到最终归档的路径上越早期越应该保持松耦合。2. 检索环节编辑器里的本地全文索引方案2.1 为什么索引要放在本地而不是云端收集到足够多的内容后第二个问题马上浮现存下来的东西怎么找回来我试过直接在收件箱文件里用编辑器的全局搜索收集量到五百条以后搜索速度开始变得不能忍。你也肯定体会过那种感觉明明记得存过一句话但怎么搜关键词都搜不出来——多半是当初存的片段和现在想的关键词根本不同字。这个阶段的正确解法是做一次本地全文索引。做这个选择之前我纠结过要不要上云后来想明白了知识工作者最私密的东西就是自己的阅读轨迹和笔记碎片这些数据放云端等于把自己的思考过程交给别人保管。而且笔记检索这种场景单机 SQLite 的全文索引速度已经绰绰有余完全没有跨设备实时同步的刚性需求。我最终的方案是在本地维护一个 SQLite 数据库里面只存索引不存原始文件原始内容仍然保留在 Markdown 里两边用文件路径和时间戳关联。2.2 FTS5 字段映射与查询逻辑索引库的逻辑不复杂核心就一张表。我用的是 SQLite 自带的 FTS5 全文索引引擎它支持中文分词的方案比较灵活我这里没有上额外的分词器而是采用整条文本按字符索引 优化查询写法的方式。对一千条以内的笔记规模来说这套方案完全跑得动。CREATE TABLE IF NOT EXISTS note_index ( id TEXT PRIMARY KEY, file_path TEXT NOT NULL, captured_at TEXT NOT NULL, title TEXT, tags TEXT, content TEXT, context TEXT, source_url TEXT ); CREATE VIRTUAL TABLE IF NOT EXISTS note_fts USING fts5( title, tags, content, context, contentnote_index, content_rowidrowid, tokenizeunicode61 );这张虚拟表让你可以用 SQL 的 match 语法做全文检索。我实际更常用的是一个带权重的查询标题命中权重最高正文命中其次上下文命中权重最低然后按时间和权重综合排序。这样搜出来的结果才不是乱七八糟按时间倒序排列的而是最相关排在最前面。SELECT id, title, snippet(note_fts, 1, [, ], ..., 12) AS preview, bm25(note_fts, 1.5, 1.2, 1.0, 0.8) AS score FROM note_fts WHERE note_fts MATCH ? AND id IN (SELECT id FROM note_index) ORDER BY score ASC LIMIT 20;这段逻辑最后被封进了编辑器里的一个插件起名叫DocPilot。它的交互很简单在编辑器中按下专属快捷键弹出一个命令面板输入关键词展示预览和来源链接回车后可以一键跳回原始 Markdown 文件的对应行。不需要单独开一个搜索窗口也不用离开当前正在写的文档它始终待在你手边。2.3 索引同步增量和全量之间的权衡索引和 Markdown 文件之间的同步我经历了三个版本的迭代。第一版是全量扫描每次打开编辑器都重新读所有文件内容少的时候无所谓内容上千条以后每次都要等十几秒彻底不能接受。第二版做了增量监听用文件系统监听事件只有收件箱文件变化时才去解析新追加的对应用例并插入索引库。增量方案跑得很顺但有一个隐蔽的坑文件监听在某些网络磁盘和同步盘上会失效。如果你把收件箱放在网盘同步目录里偶尔会碰到文件变了但监听事件没触发的情况索引就悄悄落后于实际内容了。所以我在插件里保留了一个手动重建索引的命令也在启动时做一次快速校验对比收件箱文件最后的修改时间和索引库里的最大时间戳不一致就自动补齐。这个兜底逻辑看起来简单却是整套检索稳定性的关键所在。3. AI 环节摘要、打标与自动归档的工程化写法3.1 摘要模型调用不是越智能越好而是要扛得住批量收集和检索的路通了之后我又很自然地产生了第三个需求把那些长段落快速压缩成一句话摘要再自动揣摩出几个标签这样以后浏览索引的时候能更快地做判断哪些要精读、哪些只需要看摘要就够了。我接入了一个对话式 AI 服务的接口写了个独立的小服务叫TLDR-Sync。技术上不复杂就是拿到 MarkKeeper 新写入的条目调用模型生成摘要和标签回写进索引库。但工程上细节不少随便拎一个出来都够写一篇避坑实录。首先是成本控制。刚开始我把每条新信息都立刻发给模型处理一百条信息一百次请求一个下午代币就烧掉不少。后来改成了批量触发的策略每积累十条信息或者每十五分钟统一处理一次用一条 prompt 一次喂进去让模型批量输出。长文本用截断策略控制输入长度——超过三百字的段落只取前后各一百五十字宁可稍微丢一些细节也要保证 API 成本和延迟都在可控范围内。import json import time import requests def process_batch(items: list[dict]) - list[dict]: prompt 请为以下信息逐条生成一句话摘要和2-4个中文标签。\n prompt 严格按JSON数组返回不要输出额外内容。\n for item in items: prompt f\n[{item[id]}] {item[title]}\n{item[content]}\n resp requests.post( https://api.example-ai-service.com/v1/chat/completions, headers{Authorization: Bearer YOUR_KEY}, json{ model: compact-summary-model, messages: [{role: user, content: prompt}], temperature: 0.2, }, timeout60, ) result resp.json()[choices][0][message][content] parsed json.loads(result) return parsed这里有个很容易翻车的细节模型输出的 JSON 格式偶尔会不合法尤其在摘要内容里出现换行或引号时。我的处理方式是先做一次正则兜底把明显多余的前缀摘出来如果还是解析失败就把这一批退回队列下次单独放开 temperature 重新跑。千万不要因为一次解析失败就丢掉原始数据——原始数据才是资产摘要只是衍生品。3.2 打标规则先规则后模型控制幻觉自动打标签这件事我一开始完全交给模型效果其实一般。模型的标签有很强的幻觉倾向特别容易给出一堆看着漂亮但根本没有检索价值的词比如知识学习方法。这种词当标签等于没打搜出来一百条全都带着。后来我改成规则优先、模型兜底的两段式方案先用正则规则基于关键词词库打标词库来自我之前手动整理过的所有历史标签如果一条信息没被任何词库命中才交给模型去猜。这样改之后标签的准确率提升非常明显。规则标签是确定性的同一篇文章今天打和明天打结果完全一致模型标签则保留一定的扩展能力用于覆盖那些新概念、新词汇。我还给标签做了一个频度统计每周跑一次把连续多周没有新命中的僵尸标签自动降级到候选标签避免词库越滚越大。这套AI 赋能知识工作的姿势我的最大体会是AI 在流程里只负责锦上添花的部分——摘要和冷门标签——而所有决定信息安全和检索可靠性的部分比如存储、索引、规则标签都必须用确定性的传统代码来实现。把太多环节交给模型最后模型抽一次风你的知识库就跟着乱一次。4. 联动环节让各插件通过同一份索引文件协作而不是互相乱调4.1 一条信息的完整生命周期到这儿我已经有了三个独立组件浏览器端收集插件 MarkKeeper、编辑器内检索插件 DocPilot、AI 摘要服务 TLDR-Sync。很快我意识到如果不把它们的协作关系理顺就会陷入工具越来越多流程越来越乱的困境。实际设计时我给每条信息定义了一个完整的生命周期第一步MarkKeeper 在浏览器里捕获一段文字写入收件箱 Markdown同时向索引库插入一条状态为待处理的记录。第二步TLDR-Sync 通过轮询收件箱发现新的待处理条目生成摘要、补充标签更新索引库的状态为已归档。第三步DocPilot 在编辑器里被唤起时查的就是这份已经归档完毕的索引因此用户永远看到的是完整字段中间状态不会暴露出去。这个流程最大的好处是每一步都在上一个步骤的产物上工作而不是直接去调对方的内部接口。MarkKeeper 完全不知道 TLDR-Sync 的存在它只负责写文件和一条索引记录。TLDR-Sync 也只认收件箱文件不去碰浏览器的任何内部状态。各自的失败和降级都不会波及其他组件。4.2 事件模型还是轮询模型这是一个工程决策这里有个值得展开讲的工程决策组件之间到底该用事件推送还是轮询拉取。我最初设计的是一件基于文件监听的事件驱动方案MarkKeeper 写文件后立即触发回调让 TLDR-Sync 处理。听着很优雅实际跑起来难维护。原因在于文件监听事件本身不可靠比如编辑器自动保存、网盘同步产生的瞬时文件写入会让监听器同时触发多次而且进程崩溃重启后事件丢失后续处理就断了。后来我改成客户端的启动时检查 定时轮询模型。TLDR-Sync 每隔十五分钟扫一次索引库找到所有待处理的条目批量交给模型摘要处理完更新状态。事件驱动改轮询听起来像是技术倒退但稳定性成倍提升。甚至是凌晨笔记本休眠之后第二天早上醒来打开它定时任务会立刻补跑一次把昨晚没处理的条目全部消化掉。{ inbox_file: ~/notes/inbox.md, index_db: ~/notes/.index.db, poll_interval_minutes: 15, batch_size: 10, ai: { enabled: true, endpoint: https://api.example-ai-service.com/v1/chat/completions, model: compact-summary-model, temperature: 0.2, max_input_chars: 300, daily_quota: 200 }, rules: { tag_priority: rule-based-first, fallback_to_model: true, zombie_tag_weeks: 4 } }注意配置里的daily_quota这是我自己加的一层保险。AI 工具有时候会磨洋工批量处理的请求可能因为网络抖动连续失败如果没有每日配额它会无限重试白白消耗代币。设置配额之后超出部分自动跳过留到第二天再处理损失最多少量标签但绝不会从根上破坏整条流水线。5. 配置管理插件合集的同步、锁版与重建索引5.1 中央配置文件的层级设计组件多起来之后你会发现一个特别现实的问题配置项散落在各个插件自己那三五行的设置文件里。改一个 AI 的温度参数要去翻浏览器插件的设置页改轮询时间又要去编辑器的配置文件里翻半天。为了让 knowledge-work-plugins 真正好维护我把所有配置收拢到一个config.json里三个组件启动时都只读这一份配置。配置层级的设计原则是全局共享项放顶层组件私有的放各自命名空间下。比如inbox_file是三个组件都要用的放顶层ai.temperature只有 TLDR-Sync 用放ai子对象里rules.zombie_tag_weeks属于打标规则单独归到rules。这样的好处是你一眼就能看出哪些改动会牵一发动全身哪些改动只影响局部。我在注释里把每条配置的默认值来源和改动后果都写清楚了防止过两个月自己都忘了某个参数是干嘛的。5.2 版本锁与升级避坑实录插件合集涉及到第三方库和模型接口的依赖最怕的是昨天还正常今天突然不工作。我遇到的真实案例是某次给 AI 摘要模块升级底层 SDK 之后模型的 prompt 格式变了老的chat/completions接口直接把temperature0.2给禁用了返回了校验错误。这个错误理论上应该在集成测试里被拦住但因为我升级后没有立刻跑批量任务直到第二天轮询执行时报错才发现。从此我养成了一个习惯给整个项目加了一份版本锁文件把关键的依赖版本、模型名称、API 版本全部记录下来并且每次升级只允许一个小版本号的跳跃。升级之后的第一件事不是看仪表盘而是手动跑一遍最小样本——拿三条真实的历史笔记走一遍收集、摘要、归档的全流程确认没问题时再放开给批量任务使用。# 手动触发一次完整链路自检 python tl dr-sync.py --self-check --sample 35.3 索引重建的三种触发条件最后说说索引库的维护。全文索引和源文件之间本质上是缓存关系缓存就免不了失效。我总结出三种必须触发重建索引的场景写成了三个入口。第一种是文件结构变更。如果你把收件箱从一个目录迁移到另一个目录索引里的file_path字段全部作废必须重建。第二种是索引库自身损坏。SQLite 在异常断电后偶尔会出现database disk image is malformed错误这时候只能用备份恢复。第三种是规则升级。比如我调整了标签权重字段旧索引的结构和新代码对不上也需要重建。重建索引的命令我做成了一键式的交互命令它会把当前索引导出为一个 JSON 备份然后从零开始扫描所有 Markdown 文件重新建表。在内容量不超过一万条的情况下重建时间通常在十秒以内完全是可以接受的运维成本。结尾一点关于工具使用哲学的体会整套 knowledge-work-plugins 从第一版到现在已经跑了小半年。回顾下来最让我意外的不是某个插件本身有多好用而是插件与插件之间的弱连接设计带来的稳定性红利——因为每个组件都只依赖同一份索引文件和同一份中央配置任何一个组件单独崩溃都不会拖垮整套体系。如果你也想搭一套自己的知识工作插件我的建议是不要一上来就堆功能。先把你目前最痛的那个环节——通常都是收集——用一个最简单的方式打通跑两周再决定要不要加 AI 和联动。我在第一个版本里就是只做了浏览器选段收集和本地 Markdown 收件箱这两个功能那时候检索靠的还是编辑器自带的搜索虽然粗糙但已经比收藏了从来不看强出很多。流程跑通了后面的一切都是增量优化流程没跑通工具越多负担越重。这个顺序比任何插件本身都重要。