我用过的笔记工具能列一长串：印象笔记、Notion、Bear、Logseq，绕了一圈又回到纯文本。每换一个，我都以为这次终于能管好自己的信息，结果都一样——存进去的东西，再也没打开过。「收藏即遗忘」这句话，我用好几年亲身验证了。
后来我想明白，工具其实不是问题。问题是没人维护。一个知识库要活着，得有人天天给它除草、连线、归档，而我没那个耐心。
真正让我推倒重来、又搭一套系统的，是另一件事。
真正的痛点：AI 不认识我
我现在每天都在用 AI 干活——写代码、做决策、查资料。但每开一个新对话，我都得从头解释一遍：我是谁、在做什么项目、我的偏好是什么、上次我们聊到哪了。AI 很强，可它对「我」一无所知。它认识全世界的知识，唯独不认识我。
每次重新交代背景，几分钟就过去了。更糟的是，它给的建议永远是「通用最优解」，而不是「适合我的解」。它不知道我的约束、我的框架、我的来路，于是只能给一份放之四海皆准的答案。
所以我想要的，根本不是又一个更好的笔记软件。我想要一个持续可读、越用越懂我的「个人上下文层」——一个 AI 能反复读取的、关于我的记忆体。
北极星：只服务三件事
围绕这个目标，整套系统只服务三件事：
- 让 AI 更懂我：把我的规则、偏好、判断框架，写成机器能读的形式。
- 沉淀我的信息：把每天流过我的东西筛一遍，留下值得留的。
- 提升我的效率：让 AI 在高上下文下直接帮我干活，而不是每次从零开始。
后面讲的每一个设计，都得落到这三件事上。落不到的，我就不做。
沉淀：先把「捕获」和「沉淀」拆开
先说「沉淀」，因为这是最容易做错的一环。
大多数人的信息管理，死在一个混淆上：把「捕获」和「沉淀」当成同一件事。看到好文章就一键存进知识库，结果知识库变成一个塞满「待读」的垃圾场。
我把这两件事彻底分开。
最前面是捕获层，我用 Karakeep（一个自托管的稍后读工具）。刷到任何东西，随手一存，不评判、不整理、不打标签——它自己会用 AI 自动打标签、做全文索引。捕获的唯一要求是「低摩擦」：不能打断我当下在做的事。我也坦然承认，这里存进去的东西，大部分这辈子不会再看。这不是 bug，是特性。稍后读，从来就不是必读。
捕获层和知识库之间，隔着一道闸。每周我做一次回顾，把这一周捕获的东西过一遍，决定哪些配得上进入真正的知识库。这道闸有个明确标准（下面会讲），但它的精神就一句话：宁可漏掉，也不要让信息流变成焦虑源。
过了闸的，才进入沉淀层——我的 Obsidian 知识库。这里只放筛选过、要长期维护的东西。捕获层可以脏、可以乱、可以海量；沉淀层必须干净、有结构、可信。
底座：一套按「给 AI 读」组织的 PARA
沉淀层的骨架是老生常谈的 PARA（Projects / Areas / Resources / Archive）加 Obsidian，纯本地 Markdown。这部分没什么好讲，网上一搜一大把。
真正让它和别人不一样的，是下面这件事：我是按「给 AI 读」的方式来组织它的。
懂我（一）：把规则写给机器看
知识库的根目录有两个文件：CLAUDE.md 和 AGENTS.md。它们不是给我看的，是写给 AI 看的操作手册。
里面写了什么？文件夹规则、命名规范、移动文件后要更新双向链接、哪些带数字前缀的目录不许动、提交信息怎么写……还有一些更细的约定，比如「每当我提到个人近况，就自动追加到某个固定文件里」。
这件事的意义在于：我把对 AI 的要求沉淀成了文字，而不是每次重新交代。AI（我主力用 Claude Code）每次进来，先读这两个文件，就知道了这个库的规矩。它于是从一个「聪明但健忘的临时工」，变成了一个「读过员工手册的常驻维护者」。
懂我（二）：渐进式披露
光有规则不够。一个知识库大起来，几百个文件，AI（和人）都不可能每次全读一遍。读不过来，就等于没有上下文。
我的办法是渐进式披露（progressive disclosure）：信息分层暴露，按需下钻。
每个领域文件夹是三层：
- README——最薄的入口。一句话说明这个领域是干嘛的，然后告诉读者「先读哪几份」。
- MOC（Map of Content）——完整的链接地图，把这个领域所有笔记按主题列全。
- 正文——具体笔记，只在需要时才打开。
最关键的一笔，是给少数几份「权威文档」打上 role: 标记。比如一个领域的「当前状态」和「核心规则」，会被标成 canonical。AI 进到一个领域，先读 README 知道全貌，再顺着指引读那一两份 canonical，就掌握了八成上下文，而不用把几十份历史稿全吞下去。过时的过程稿则统一沉到 Archive/ 和 快照/，平时不进视野。
这套结构对人友好，对 AI 更友好——它直接降低了「读懂我这个库」需要的 token 和认知负荷。说白了，渐进式披露的本质，就是为了让 AI 高效读取关于我的上下文。
懂我（三）：沉淀的不只是信息，还有我的判断
前面都在组织「信息」。但要让 AI 真懂我，光有信息不够，还得沉淀我的判断标准。
举个真实的例子，就是前面提到的那道「闸」。
我把「一条信息该不该留」写成了一套打分规则：五个维度——可信度、可操作性、相关性、新颖性、反 hype——满分十二分。低于七分直接丢；七到八分进资源笔记；九分以上，安排一次小实验。
这套规则带来的变化是：当我把一篇文章丢给 AI，它不再泛泛地「帮你总结一下」。它会对着我的标准打分：可信度几分、有没有可复现的 eval、够不够进库、该归到哪、还是直接丢。它给我的，是对照我的取舍之后的判断，而不是一份谁都能拿到的摘要。
这里我得说句实话，免得显得比实际更高级：我并没有写一个「自动评分器」。 真正自动的只是搬运——有脚本把稍后读里的剪藏加上 frontmatter、改成规范文件名、归到对应文件夹。打分这件事，是 AI 对着我写下来的 rubric 在做判断。我做的不是把判断自动化，而是把判断标准写下来、结构化，让 AI 能稳定地复用它。
对我来说，这反而比假装全自动更靠谱。我做过一些 eval 和 harness 的活，很清楚一点：一个判断能被复用的前提，是它先被清清楚楚地写下来。
同样的模式，我也用在更敏感的决策上，比如理财——先让 AI 读我的框架，再对照现状指出缺口，但绝不替我拍板（具体数字我就不往博客里放了）。规则永远是那句：AI 做对照，人做决定。
提效与守底线：像运营代码库一样运营知识库
走到这一步，我其实是在像运营一个代码库一样，运营我的知识库。
既然是人和 AI 一起高频改动，就一定会生熵：断掉的双向链接、没人引用的孤儿附件、忘了写 frontmatter 的新笔记、堆成山的收件箱。靠人肉巡查，迟早漏。
所以我给知识库上了 lint。一个脚本定期检查：有没有死链、有没有孤儿附件、近期笔记缺不缺 frontmatter、收件箱是不是又堆超了。格式层面，还有 prettier 兜底。这套检查守护的，正是渐进式披露赖以成立的那些不变量——入口齐全、链接有效、元数据完整。
再加上一些日常自动化：Git 定时同步，几个固定的复盘流程（每日回顾、每周综合、收件箱处理）做成了可一键触发的 skill。
这些加起来，给了 AI 一种「CI 心智」：改完能自检，而不是「我觉得没问题」。对一个要把部分决策权交给 AI 的系统来说，这种兜底不是可选项。
一个最能说明问题的瞬间
这篇博客，就是用这套系统写出来的。
我没有从空白文档开始。我对 AI 说「写篇博客介绍下我的知识管理方式」，它做的第一件事，是去读我的库——读 CLAUDE.md 知道我的博客放在哪、frontmatter 怎么写；读我那几份关于信息系统的笔记，搞清楚打分规则的细节；甚至翻了它自己几天前帮我重构知识库时留下的记录。
于是它不是在替一个「通用用户」写一篇「通用的 PKM 文章」。它在替我写，带着我的上下文、我的例子、我的语气。我们来回改了好几版大纲，中途它还会提醒我「这个例子涉及隐私」「你这里之前的说法其实夸大了」。
这就是那三件事同时成立的样子：它懂我（读到了我的上下文），它用上了我沉淀的信息（打分规则、博客规范），它实实在在提了效（我省下了从零解释、从零起稿的时间）。
代价，和一个判断
这套系统当然有代价。
前期搭建不轻松——写规则、定结构、调脚本，花了不少功夫。它也只对「愿意把信息当资产来经营」的人有意义；如果你本来就不怎么记笔记，这套东西纯属过度工程。还有一条我一直在掂量的边界：信任。AI 能帮我维护、能帮我判断，但哪些事可以交给它、哪些事必须我自己来，这条线得始终清醒。我目前的答案，还是那句：AI 做对照，人做决定。
但我越来越相信一件事：往后每个人可能都需要一个「关于我」的上下文层。 不是为了管理信息本身，而是为了让那些越来越强的 AI，能真正为你所用，而不是每次都把你当陌生人。
我现在做的，只是提前给自己造了一个。