当AI知识库沦为数字仓库，如何让信息真正转化为个人认知资产？本文作者用半年时间重构Obsidian知识管理体系，从三层处理架构到主题驱动治理，揭示AI时代个人知识管理的核心不是收集而是淬炼。特别揭秘如何让LLM在不同工作流阶段扮演多重角色，实现从被动囤积到主动经营的认知跃迁。

2025 年底到 2026 年初，AI 感觉第一次在普通人之间大爆发，一瞬间如海啸般涌向还在沙滩上观望的人们。我的第一反应和大多数并未深度浸淫过AI行业但早有耳闻的产品人一样：与其被淹没，不如用新能力武装自己。

具体来说，我觉得应该先有一个适合自己的知识库工具，把内部外部知识收集起来、管理起来，形成自己的一套AI时代的操作系统底座（是的，之前我常年的企业领域知识和个人知识基本上都是通过企业在线文档的形式留存，属于企微/飞书，属于我所在的每一家企业平台，但回头想想很少有真正属于我自己的沉淀）。

考虑到本地化数据的自治权，要把知识掌握在自己手里，一番调研后我选了 Obsidian。然后我做了一件看似顺理成章的事情——把之前收藏的高质量文章一股脑存进去，知识库不就是干这个的？

但很快我就意识到，这种做法不亚于买了各种典藏新书，粗略翻了两页甚至有的都没开封，就直接摆在书架上吃灰。

因为这些文章是别人思考和实践后的产物，不是我的。我的 Obsidian 里躺着两百多篇好文章，但遇到具体问题需要调用这些所谓知识的时候，我依然要从头翻、从头读、从头想。笔记越来越多，知识越来越散。

这个矛盾逼着我重新想一个问题：个人知识库到底应该是什么？

我存了两百篇文章，但没有一篇是我的

回头看，我最初犯的错误很典型：把知识库理解成了“资料收集系统”。

收集本身没有错，但它只回答了“知识怎么进来”，没有回答“知识怎么变成我的”。这两件事的差距，比想象中要大得多。

一篇讲企业 RAG 落地的文章，作者踩过坑、做过判断、形成了自己的框架。我把它存进我的 Obsidian，它只是一段文本。我读了一遍，草草记录几行笔记，它依然只是“作者的理解”，不是“我的判断”。只有当我拿着这篇文章里的方法，去对照自己负责的业务、对照自己做过的产品决策，在真实场景里校准过之后，它才开始带上我的印记。

这个认识后来被我提炼成一条原则：个人知识库真正长期有价值的，不是收集了多少知识，而是能否把外部信息逐步淬炼成带有个人判断、可持续演化的认知资产。

认知资产和资料的区别在于：资料是通用的，谁都能搜到；认知资产是经过你的经验、你的场景、你的失败和成功校准过的，不可替代。

这也是为什么我说知识库的核心本体不是知识集合，而是认知资产。搭建和使用知识库的大半年里，我最大的认知变化就是从这里开始的——目标从“存了多少篇文章”变成了“沉淀了多少只有我理解和迁移后才能写出来的判断”。

批量处理了几十篇文章之后，我发现中间缺了一层

明确了目标之后，第一个工程问题是：怎么把原始文章变成认知资产？

我最初的方案很简单粗暴：写个脚本，把所有文章批量处理成统一格式。输入各异的文章，输出统一的结构——摘要、知识点、启发、金句。拉齐起跑线，方便后续理解。

这个方案跑了几个月，处理了几十篇文章。然后我发现了一个问题：这些处理后的笔记，只是大模型理解后的输出，不是我的。

批量处理确实降低了信息噪声，但它跳过了最关键的一步——理解。一篇讲 AI PM 能力迁移的文章，大模型可以提炼出五个核心观点，但这五个观点和我有什么关系？在我的业务里哪些成立、哪些不成立？哪些和我已有的判断冲突？这些问题，大模型的处理回答不了。

于是我做了一个调整：把批量处理的产物定义为中间层（我后来叫它 Processed 层），它不是终点，而是为后续讨论提供结构化输入。在 Processed 之后，我加入了讨论机制——和 AI 做深度对话，让 AI 扮演文章作者甚至是第三方视角的领域专家，我们来回追问、质疑、碰撞。

这个改变的效果出乎意料。同样是那篇 AI PM 能力迁移的文章，批量处理只产出了五个知识点，但一轮深度讨论之后，我发现了自己之前没意识到的一个判断：能力迁移的关键不是学新技能，而是重新定义旧技能在新场景下的表达方式。这个判断不是文章里的，是讨论过程中产生的——它属于我。

由此形成了三层结构：

中间层看起来“多了一步”，但它是知识系统的必要缓冲层。如果没有它，你会面临两个问题：原文噪声太大，讨论效率低；讨论和沉淀不分开，单次理解容易直接污染主知识层。

三层结构还有一个设计选择值得一提：我用目录位置而不是布尔字段来表达工作流状态。Inbox 里的就是待处理的，Processed 里的就是待讨论的，Review 里的就是已讨论的。不需要额外加 discussed: true 这种字段——目录本身就是最高效的筛选器，状态语义也更清晰。

从文章驱动到主题驱动：知识库的阶段跃迁

三层结构跑通之后，知识卡片开始稳定产出。到 2026 年 4 月，我的知识库里已经有六十多张卡片。然后我遇到了一个新问题：

卡片越来越多，但系统反而更难用了。

同一个知识主题下出现了好几张内容重叠的知识卡片；有些卡片彼此相关但没有建立连接；有些主题已经形成了一簇卡片，但没有主卡来统领全局；新产出的卡片默认都是 NEW，旧卡片几乎不被更新。

这让我意识到一个新的判断：对我来说，知识系统从“积累阶段”进入“治理阶段”的标志，不是内容变多了，而是结构问题开始出现，单纯新增已经不能继续提升系统清晰度。

这个阶段切换，对应的不只是工作重心变化。回头看，有三个认知是在这个阶段里逐步形成的。

最早出现的变化是选题逻辑的反转。之前是“今天处理哪篇文章决定今天产出什么卡片”——文章驱动。切换后变成“哪个主题域有空白带，为了补这个空白带应该调度哪些文章”——主题驱动。选题的驱动力从有什么待讨论的文章变成了我现在的知识主题网络的缺口在哪里。

紧接着我注意到，讨论过程中产生的高价值内容正在被浪费。一轮深度讨论中，为什么最终选了 B 方案而不是 A？某个边界条件是在什么对话中被识别出来的？这些与大模型的推理过程往往不会完整进入卡片正文（因为卡片最终产出约束的限制）。但它们本身就是知识资产的一部分。后来我建立了 Discussion Insights 机制，专门沉淀这类“结论之外的高价值推理”，用于记录讨论过程的灵感迸发和决策梳理。

第三个认知来自治理实践的深入。我发现检查一张卡片的 frontmatter 是否合规，只是治理的入门。真正的治理要深入到网络结构层面：这个主题下有没有主卡？主卡和支卡的角色是否失衡？有没有孤儿卡没有被任何主题页索引？有没有重复卡或高相似卡？

这三个认知，有一部分是我在实践中逐步摸索出来的，也有一部分来自 2026 年 4 月偶然读到 Andrej Karpathy 的一篇 gist——他称之为 LLM Wiki。读到那篇东西的时候，我有一种“不谋而合”的感觉，同时它也补上了我还没想清楚的几个点。

读了 Karpathy 的 LLM Wiki 之后，我给 LLM 赋予了多角色

Karpathy 的核心隐喻很简洁：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。

这句话的深意不在于类比本身，而在于它重新定义了 LLM 在知识系统中的角色。LLM 不只是帮你总结文章的摘要工具，而是帮你持续维护一个结构化知识体系的协作者。它负责总结、交叉引用、归档、记账——这些人类最容易放弃的重复性维护工作。

这个隐喻映射到我的实践中，LLM 的角色其实随着工作流阶段在变化。在处理层，它是批量引擎——批处理脚本调用大模型 API，把原始文章提炼转化为 Processed 笔记，对应 Karpathy 所说的 Ingest。到了讨论层，它变成了一个有知识储备的对话伙伴，深度讨论 Skill 支持 AI 带教、相互 battle 共创、批判性质疑等多种模式，帮我校准边界、发现盲区、深化理解。到了治理层，它又变成了巡检员——知识卡片治理 Skill 扫描整个知识库，识别孤儿卡、重复卡、主题结构失衡，对应 Karpathy 所说的 Lint。

同一个 LLM（当然也可以不同），在不同层做不同的事。这比“让 AI 帮我总结”要丰富得多。

而我的日常流程，围绕这三层角色形成了一个闭环：

1. 收集：每周定期抽时间阅读和筛选，好文章入池
2. 处理：执行脚本三连（预处理→验证→修复），把原文变成结构化中间层
3. 讨论：与 AI 开启深度讨论，产出知识卡片和 Discussion Insights
4. 沉淀：把讨论结果固化为知识卡片网络——这里最关键的动作不是新建卡片，而是先判断它应该 UPDATE（更新旧卡）、EXTEND（扩展子卡）、LINK（建立关联）还是 NEW（新建）。这套四分机制是防止知识库退化为流水账的核心规则
5. 审视：通过 Obsidian的Dataview 视图全局扫描知识网络的健康度
6. 治理：对异常指标运行治理 Skill，完成知识库修复
7. 输出：运行知识应用 Skill，检验知识库能否支撑一篇逻辑连贯的文章，同时完成面向外部的知识输出

举个例子：上周五我的例行流程是——先把三篇关于 Agent 协作的文章入池，跑完脚本三连得到 Processed 笔记，然后和 AI 做了一轮批判性讨论，讨论中识别出一个和我已有卡片相关的边界判断，最终做了一次 LINK 而不是 NEW，补充了主题知识缺口。之后打开 Dataview 面板扫了一眼，发现 RAG 主题域有两张卡长期没更新，跑了一轮治理 Skill 确认是正常状态。整轮下来大概两个小时，但知识库的清晰度又往前推进了一点。

七步闭环，每一步都有 LLM 参与，但每一步的决策权都在我手上。

Karpathy 的 gist 里还有一个让我眼前一亮的设计：知识库的演进日志。他认为 log 不是噪音，关键 log 本身就是知识资产的一部分。受此启发，我在项目中增加了 Evolution Logs 机制——记录“什么变了、为什么这样定、放弃了什么方案”。这些决策记录让知识库不只是保存“当前共识”，也保存了“共识是怎么形成的”。长期使用下来，它们会让知识库越来越符合我的思维方式和判断偏好。

不忘初心、牢记使命：别急着做RAG，知识先能轻量级用起来

搭建知识库的过程中，我也一直在思考一个问题：就是当前我做的这一切只是构建知识库本身，知识库本身并不是目的，而是手段，利用知识库进行实际的产出才应该是知识库的价值所在。那么是否应该在知识库差不多具备雏形的时候先搞一套轻量级RAG呢？

经过与我的知识库管家（其实就是这套知识库体系本身）的多轮拉扯，最终回答是：不急。

这不是说 RAG 不重要，而是顺序不能反。如果知识结构还处于高频变动期——卡片模板没稳定、主题索引没成形、治理规则没固化——就急着做向量化和 RAG，只会把不稳定结构放大。你检索到的是一堆格式不统一、边界不清晰、互相重叠的碎片，能指望检索质量有多高？（大模型就是这么说服我的）

另外就是别急着做所谓的知识库自动化（不论是Ingest自动化还是Lint自动化），还有一个更基本的问题没回答：你的知识库被用起来了吗？

我看到很多参考了LLM-wiki方法论搭建的个人知识库在完成收集和沉淀之后，直接跳到“活体进化”或“自动化更新”。但如果系统还没有进入真实使用场景，这种推进往往会落空——沉淀的知识长期停留在库存状态，系统无法暴露真实的知识缺口，后续的“自动进化”也缺少反馈源。

所以我现在的做法是：先用知识应用 Skill 来检验知识库的可用性。写一篇文章，需要调用多个主题域的知识卡片，需要论据可追溯，需要叙事逻辑连贯。如果写不出来，说明卡片网络有结构缺口——这个信号比任何自动化指标都直接。

Karpathy 的 LLM Wiki 框架里有一个类似的洞察：好的查询结果可以反向归档为新的 wiki 页面，让探索本身也成为知识资产。我的知识应用 Skill 就是这个思路的实现——每次写文章的过程，既是调用知识库，也是检验知识库。写完之后，回溯校验表会告诉我哪些主张可追溯到源卡片、哪些是延伸推断、哪些找不到来源。找不到的那些，就是知识库的真实缺口。

先把 wiki 层稳定下来，再考虑切片、向量化和 RAG 集成。这个顺序，是我实践下来收获的最大财富——确保食材源头质量的同时，主厨自己先不定期搞搞试菜，验验这批原材料、菜谱、厨具以及自身手艺到底有没有食客青睐，再谈厨房流程自动化也不迟。

从知识仓库到私人图书馆

半年前，我把 AI 和 Obsidian 的结合当工具用。它帮我解决的是“有没有知识”的问题——有了就存，存了就忘。

现在，我把它们当个人知识库智能体。它像一个专家，和我做高质量的讨论和碰撞；也像一个管家，帮我维护知识网络的结构和健康。

最直观的变化不是系统变复杂了，而是我和系统的关系变了。以前是“需要的时候才打开”，现在是每天不交互一轮就浑身难受。因为每次交互不只是在消费知识，而是在生产认知——那些经过讨论校准的判断、经过治理沉淀的卡片网络、经过输出验证的知识框架，都在变成只属于我的认知资产。

Karpathy 说人类放弃 wiki 是因为维护成本增长得比价值快。LLM 解决了这个问题——它不嫌烦，不会忘记交叉引用，一次操作可以触及十五个文件。

但 LLM 解决不了的，是你往知识库里注入什么判断、什么经验、什么偏好。这部分只能你自己来。

搭建知识库大半年，我最大的感受是：目标不应该定在”存更多笔记”上，而是定在”沉淀更多只属于自己的认知”上。前者是囤积，后者是经营。

区别在于，前者越做越重，后者会因为知识复利而越做越值钱。

下一篇预告：谈谈我具体是怎么用搭建产品的方法论和Claude code来搭建这套个人知识库的