1 个人知识库

结合LLM优化个人知识库的目标很明确，就是为了更好地整理手头的所有文档。

本周调研了三种实现方式： - LLM+知识库_01_basic-memory - LLM_知识库_02_记忆宫殿 - LLM_知识库_03_LLM_Wiki

本篇是对LLM+知识库的一些总结和思考。

1.1 核心点

根据几种方案的对比，以及自己的实验，总结如下核心点：

  • 数据保存在本地
  • 需要保存原始文本，尽量不在原始文本上修改
  • 所有内容都要明文保存，包含原始内容和LLM生成的内容
  • 系统本身需要具备自我进化的能力
  • 文档和文档之间最好能自动建立连结

1.2 架构分层

在具体架构上，需要有一层清晰的划分，这里更倾向 LLM Wiki 的方案：

  • 原始资料必须原样留档。
  • 模型的输出结果需要存下来，避免每次提问都重新生成。这些存下来的输出未来如何持续更新，需要进一步设计逻辑。
  • 面对复杂场景，单靠一个 Agent.md 可能不够。未来在和大模型交互时，大概率需要按需注入多套不同的独立规则。

1.3 具体实现

落实到具体实现上，大家都在摸索，不过有几个确定的方向。

首先，不管是跑出来的模型产出还是原始资料，都得让人能直接看懂，不能搞成黑盒，这是底线。在技术选型上，大家现在普遍倾向于轻量化的方案，比如直接写个 Python 库配合 SQLite 或 ChromaDB 就能跑起来，不需要搞很重的后端服务。当然，纯文本可能不够，还是需要概念分层、向量检索这些组织机制来打底做辅助。

当内容多起来后，会涉及到成本管理和项目拆分。比如，已经结项的内容就可以归档，不需要频繁更新；而新知识则处于激活区，享有更高的处理优先级。不同的项目也可以适用不同的规则和风格，在此基础上，还要把自己的产出（一手资料）和摘录（二手资料）严格区分开。

另外还有一个关键点是“自我进化”。进化的不仅仅是每天让模型跑数据，提示词和结构设计本身也应该在这个过程中跟着进化。不过这也带来一个新问题：规则进化后，以前按老规则处理过的数据怎么办？这也是一套完整系统必须考虑的。

回到需求端，不同人对数据整理的需求差异很大。普通用户可能完全不想知道底层细节，但知识工作者通常希望能自己把控整个处理过程。总的来说，目前大家在“具体怎么抽取”、“提示词怎么定”、“怎么更新”以及“如何保持稳定”这些具体落地上，都还没完全想透，基本还在摸着石头过河。

1.4 能对已有的知识库做些什么

把知识库接入大模型后，能做的事情就非常丰富了：

  • 全局搜索与整合：不需要死记硬背哪个文件存在哪，直接用自然语言提问，大模型就能跨文件把相关信息整理出来。
  • 发现隐性关联：从平时零散的随笔、对谈和截图中，自动识别并连接出那些原本注意不到的知识图谱。
  • 格式转化：随时可以把过去积累的零碎知识，一键转化为可发布的技术文章或是对外分享的大纲。

1.5 普通人是否需要个人知识库

如果是完全不用大模型、也没有记笔记习惯的人，那个人知识库确实没什么用。

但如果你日常会跟大模型聊聊股票分析、技术心得、查查常识或者写写读书笔记，这些对话自然沉淀下来，以后甚至能用来训练一个懂你的“数字分身”。

有人觉得既然能直接问大模型，为什么还要自己存一份？对于像“什么是 MCP”这种纯客观概念，确实不用存。但很多问题并没有标准答案。知识库里存的，是我和模型经过多轮探讨、反复试错后最终得出的有效结论。它最大的核心价值非常简单：让你不用再做重复劳动。

2 新趋势

2.1 以何种形式提供

从 LLM Wiki 项目可以看到，作者只是把想法写下来，大家就让LLM按照想法自行实现了。未来可能会从交付“软件”，变成交付“Skill”，再进一步直接交付“想法”。

2.2 人机配合

虽然我现在已经可以把自己的习惯用法和流程写进 skill 里，但这些东西目前还是比较散乱，迫切需要更好的整合。这就如同我现阶段虽然积累了大量的文档，但它们还没完全串联成一个扎实的知识体系，人机配合的深度还有很大挖掘空间。

3 RAG 已死？

现在说这话还不至于。像 LLM Wiki 目前在处理海量数据和语义搜索上还不够完备，而 basic-memory、ontology skill、mempalace 这些跑在前面的工具也各有局限，还不能完全替代 RAG。况且，RAG 本身也是个不断进化的概念。

不过得承认，现在的知识管理工具演进得非常快。从全明文结构、记忆宫殿式的分层，到向量检索、知识图谱、再到自动关联……这些层层叠加的抽象能力，已经比传统类似数据库结构的早前 RAG 方案走得远太多了。

4 MCP 已死？

目前依然很有用。未来 Skill 确实有可能直接调用 API 或命令行，但现在单靠满天飞的 Skill 其实有隐患。

最常见的一个坑是：Skill 的说明提示词和它背后的 CLI 代码，往往不是同一拨人维护的。一旦 CLI 升级、参数变了，而 Skill 没同步更新，功能直接就挂了。如果是自己写 Skill，也要一直费心去查文档、盯维护。

而 MCP 直接把“能力描述（Skill）”和“具体执行（代码）”打包在一个 Server 里，天然就避开了这种版本错配的坑。