缘起
我的个人图书馆里攒了快两百篇 Markdown 笔记。文件多了之后，光靠目录层级和记忆找东西越来越费劲，每次想翻出半年前写过的某段话，都像是在人肉 grep 自己的过去（经常还搜不到喵）。
因此我提出了 Notebit 的构想：坚持本地优先，在后台实时监听文件修改，异步更新索引，再用关键词和语义片段把散落的笔记重新串起来。所有数据都留在本地硬盘里，不依赖云端同步。
管线
文件写入、变更监听、构建索引和查询检索在工程上是四件节奏完全不同的事。如果偷懒把它们塞进同一个同步函数里，磁盘上稍微改几个文件就会把界面卡死；所以整条管线被拆成了彼此解耦、可以独立重试的五个阶段。
证据
- 01
真实的本地数据库：个人图书馆/data/notebit.sqlite 里保留了日常笔记库的真实索引数据，并非空跑的演示样本。
- 02
文件监听与异步索引队列：从 fsnotify 事件捕获、防抖去重到 Worker Pool 并发入库，整条链路都在本地笔记库上实际跑通。
- 03
产品形态探索：尝试把传统的「单次搜索框」延伸成「写作 — 召回旧笔记 — 再思考」的本地知识流。
边界
方向由我提出，落地由 AI 辅助，仍属于早期探索。
- 项目的需求痛点、工作流设计与验收判断由本人主导提出；具体代码实现大量借助了 AI 辅助，并非逐行手写。
- 召回与检索质量还没有做过量化的评测基准；文档里提到的 RAG 目前只是原型探索，还谈不上稳定的生成效果。
- 不做云同步、多人协作与移动端适配，最初就是为了解决我自己本地笔记库的检索痛点。
- 界面交互和切块索引策略后续还会继续推翻重调，当前版本主要是为了验证「本地优先 + 异步索引」这条路子走不走得通。