行业中大佬的的知识管理方法
@garrytan分享了自己的知识管理方法： https://gist.github.com/garrytan/49c88e83cf8d7ae95e087426368809cb
Karpathy大神的： https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
一种利用大语言模型（LLMs）构建个人知识库的模式。
这是一份思路文档，设计初衷是可复制粘贴到你自己的大语言模型智能体（如 OpenAI Codex、Claude Code、OpenCode / Pi 等）中使用。其核心目标是传递核心思路，具体落地细节则由你的智能体与你协作完成。
大多数人使用大语言模型处理文档的方式都是检索增强生成（RAG）：上传一批文件，大语言模型在接收到查询请求时检索相关文本块，再生成回答。这种方式确实可行，但大语言模型每次回答问题时，都要从零开始重新挖掘知识，不存在知识积累的过程。若你提出一个需要整合五份文档信息才能解答的复杂问题，大语言模型每次都得重新查找并拼接相关片段，无法实现知识的沉淀。NotebookLM、ChatGPT 的文件上传功能，以及大多数 RAG 系统均采用这种模式。
而本文提出的思路与之不同。我们不再仅在查询阶段从原始文档中检索信息，而是让大语言模型增量式地构建并维护一个持久化的维基百科—— 即一套结构化、互相关联的 Markdown 文件集合，作为你与原始数据源之间的中间层。当你新增一个数据源时，大语言模型不仅会为后续检索建立索引，还会读取该数据源、提取关键信息，并将其整合到现有维基百科中：更新实体页面、修订主题摘要、标注新数据与旧观点的矛盾之处、完善或修正逐步形成的知识整合内容。知识只需编译一次，后续便会持续更新，而非每次查询都重新推导。
这就是核心差异所在：该维基百科是一个持久化、可不断积累的产物。知识间的交叉引用早已存在，矛盾点已被标记，整合内容也已体现你阅读过的所有信息。每新增一个数据源、每提出一个问题，这个维基百科都会变得更丰富。
你几乎无需亲自编写维基百科内容 —— 所有编写和维护工作均由大语言模型完成。你负责筛选数据源、探索方向，并提出有价值的问题；大语言模型则承担所有繁琐工作：汇总信息、建立交叉引用、分类归档、记录管理，这些工作正是让知识库长期发挥作用的关键。实际使用时，我会在一侧打开大语言模型智能体，另一侧打开 Obsidian（一款笔记软件）。大语言模型会根据我们的对话进行编辑，我则实时浏览结果 —— 点击链接、查看图谱视图、阅读更新后的页面。Obsidian 如同集成开发环境（IDE），大语言模型是程序员，而维基百科就是代码库。
这种模式可应用于多种场景，举例如下：
整体架构分为三层：
原始数据源层—— 你精心整理的源文档集合，包括文章、论文、图片、数据文件等。这一层是不可变的：大语言模型仅读取其中内容，绝不修改。它是你的事实依据来源。
维基百科层—— 由大语言模型生成的 Markdown 文件目录，包含摘要、实体页面、概念页面、对比分析、总览、整合内容等。这一层完全由大语言模型掌控：创建页面、新增数据源时更新页面、维护交叉引用、确保所有内容一致。你负责阅读，大语言模型负责编写。
模式定义层—— 一份配置文档（例如给 Claude Code 用的 CLAUDE.md，或给 Codex 用的 AGENTS.md），告知大语言模型维基百科的结构、命名规范，以及处理数据源、回答问题、维护维基时需遵循的工作流程。这是核心配置文件 —— 正是它让大语言模型成为严谨的维基维护者，而非通用聊天机器人。你可与大语言模型共同优化这份文档，逐步探索适配自身场景的最佳方案。
数据导入（Ingest）：将新数据源放入原始文档集合，告知大语言模型进行处理。典型流程：大语言模型读取数据源，与你讨论核心要点，在维基中编写摘要页面，更新索引，完善维基中相关的实体和概念页面，并在日志中添加记录。单个数据源可能涉及 10-15 个维基页面的更新。我个人倾向于逐个导入数据源并全程参与 —— 阅读摘要、检查更新内容、指导大语言模型确定重点。你也可以选择批量导入多个数据源，减少人工干预。关键是制定符合自己使用习惯的工作流程，并将其记录在模式定义文档中，方便后续使用。
查询（Query）：基于维基百科提问。大语言模型检索相关页面、读取内容，并结合引用生成合成回答。根据问题类型，回答形式可灵活调整 ——Markdown 页面、对比表格、幻灯片（Marp 格式）、图表（matplotlib 生成）、画布等。核心要点：优质的回答可作为新页面归档到维基中。你要求的对比分析、研究结论、发现的关联点都具有价值，不应淹没在聊天记录中。如此一来，你的探索过程如同导入数据源一样，能持续为知识库添砖加瓦。
校验（Lint）：定期让大语言模型对维基进行 “健康检查”，重点关注：页面间的矛盾内容、被新数据源推翻的过时观点、无入站链接的孤立页面、被提及但未单独建页的重要概念、缺失的交叉引用、可通过网络搜索补充的数据缺口。大语言模型擅长提出值得深入研究的新问题，以及可补充的新数据源。这能确保维基在规模扩大的同时保持 “健康”。
有两个特殊文件帮助你和大语言模型管理日益庞大的维基，二者功能不同：
index.md 面向内容管理：是维基所有内容的目录 —— 每个页面均附带链接、单行摘要，还可选择性添加日期、数据源数量等元数据。按类别（实体、概念、数据源等）组织。大语言模型每次导入数据时都会更新该文件。回答查询时，大语言模型会先读取索引找到相关页面，再深入分析内容。在中等规模下（约 100 个数据源、数百个页面），这种方式效果极佳，无需搭建基于嵌入向量的 RAG 基础设施。
log.md 按时间排序：是一份仅追加的操作记录，记录所有操作及时间 —— 导入数据、查询、校验。实用技巧：若每条记录以统一前缀开头（如 ## [2026-04-02] ingest | 文章标题），可通过简单的 Unix 工具解析日志，例如 grep "^## \[" log.md | tail -5 可查看最近 5 条记录。日志不仅能呈现维基的演进时间线，还能帮助大语言模型了解近期操作。
随着维基规模扩大，你可能需要开发小型工具提升大语言模型的操作效率。最基础的需求是维基页面搜索引擎 —— 小规模时 index 文件足够用，但规模扩大后，需要专业的搜索工具。qmd 是不错的选择：这是一款本地 Markdown 文件搜索引擎，支持 BM25 / 向量混合搜索和大语言模型重排序，全程本地运行。它同时提供 CLI 接口（方便大语言模型调用）和 MCP 服务器（支持大语言模型原生调用）。你也可以自行开发更简易的工具 —— 当需求出现时，大语言模型可协助你快速编写一个基础的搜索脚本。
raw/assets/）；再在设置 → 快捷键中搜索 “Download”，找到 “Download attachments for current file”（下载当前文件的附件），绑定快捷键（如 Ctrl+Shift+D）。剪辑文章后按下该快捷键，所有图片会下载到本地磁盘。这一步可选，但能让大语言模型直接查看和引用图片，避免依赖可能失效的 URL。需注意：大语言模型无法一次性读取包含内嵌图片的 Markdown 文本，解决方案是让大语言模型先读取文本内容，再单独查看部分或全部引用图片以获取更多上下文。虽稍显繁琐，但整体效果良好。
维护知识库的难点不在于阅读或思考，而在于繁琐的 “台账工作”：更新交叉引用、保持摘要时效性、标注新数据与旧观点的矛盾、确保数十个页面内容一致。人类放弃维护维基，是因为维护成本的增长速度远超其价值；而大语言模型不会感到枯燥，不会遗漏交叉引用的更新，还能一次性处理 15 个文件。维护成本几乎为零，维基才能持续更新。
人类的核心职责是筛选数据源、指导分析方向、提出有深度的问题、思考信息背后的意义；其余所有工作都可交由大语言模型完成。
这一思路在理念上与万尼瓦尔・布什（Vannevar Bush）1945 年提出的 “记忆延伸器（Memex）” 一脉相承 —— 一个个人化、经过筛选的知识存储库，文档间存在关联路径。布什的构想更接近本文所述模式，而非如今的互联网：私有化、主动筛选，文档间的关联与文档本身同等重要。他未能解决的难题是 “谁来负责维护”，而大语言模型恰好能填补这一空白。
GBrain 作为开源的个人知识脑系统，核心优势围绕轻量化、一体化、易用性、兼容性四大维度展开，具体可拆解为以下几点：
GBrain完整版
brain.db 文件中，无需服务器、Docker、连接字符串或托管数据库，可通过 scp/rsync 传输、备份到 S3 或存入 U 盘，完全适配个人使用场景。
export 还原原始目录结构，页面数、内容哈希、链接数均可验证，解决 Git 管理大量文件 “卡顿” 的问题。 gbrain query 可同时触发关键词匹配 + 语义相似性检索，合并结果并排序，无网络开销。
gbrain serve 启动 stdio 服务后，任何 MCP 客户端（Claude Code、Cursor、Wintermute 等）均可无需定制集成，直接读写 / 检索知识库。 完美适配个人知识 “持续迭代 + 可追溯” 的需求，导出时自动还原分层结构。
import/export 保证与现有 markdown 目录结构双向无损转换，无需重构历史知识；
两者同源同理念：都是AI 驱动的持久化个人知识库，抛弃传统 RAG “每次查询从零检索” 的模式，用 LLM 做增量编译、交叉引用与维护，实现知识复利增长。
核心区别：LLM Wiki 是理念 / 方法论，GBrain 是该理念的工程化开源实现。
都采用结论层 + 证据层分离：结论（最新状态）可更新，证据（历史 / 来源）只追加不修改。
人类：筛选数据源、提问题、把控方向；LLM：摘要、建链、归档、维护、矛盾检测。
解决 Git / 纯文件管理大量笔记卡顿、传统 RAG 无积累、人工维护维基成本过高的问题。
最终知识以结构化 Markdown呈现，可读、可迁移、可手动修正。
二、核心差异（对比总表）
表格
维度 | LLM Wiki | GBrain |
本质定位 | 理念 / 方法论（无代码、无固定实现） | 开源工程化项目（可直接编译运行） |
存储架构 | 纯 Markdown 文件目录（raw+wiki+schema） | 单 SQLite 文件（整合 FTS5 + 向量 + 结构化数据） |
检索能力 | 靠 index.md 索引 + 可选第三方搜索 | 一体化：FTS5 关键词 + 向量语义 + 结构化查询 |
AI 驱动方式 | 靠一份 schema 文档（如 CLAUDE.md）指引 | Thin CLI+Fat Skills（Markdown 技能文件）+ 原生 MCP |
知识模型 | 三层抽象（原始源→wiki→schema） | 固化为 Compiled Truth+Timeline 双列结构 |
部署依赖 | 无部署，依赖 Obsidian 等笔记工具 | Bun 编译二进制，零额外依赖，单文件运行 |
维护机制 | 手动触发 Lint 检查 | 内置自动化维护技能（矛盾 / 过期 / 孤立页 / 死链） |
数据迁移 | 手动导入导出，无校验 | 无损双向迁移，自动校验页数 / 哈希 / 链接数 |
工具生态 | 依赖第三方插件（Obsidian/Dataview/Marp） | 原生 CLI+MCP，可对接任意 MCP 客户端（Claude/Cursor） |
规模上限 | 适合百级页面、小规模知识库 | 支持数万页面，SQLite 承载更强 |
三、关键差异详解
1. 形态：理念 vs 可落地产品
2. 存储：文件散列 vs 单文件一体化
3. 检索：弱检索 vs 三位一体强检索
一次查询合并结果，无网络开销。
4. AI 协作：松散指引 vs 标准化工具调用
5. 维护：人工触发 vs 自动化治理
四、选型建议
选 LLM Wiki 如果你：
选 GBrain 如果你：
上网困难的请访问
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。