90 lines
5.3 KiB
Markdown
90 lines
5.3 KiB
Markdown
---
|
|
title: "LLM Wiki：构建持久累积型个人知识库"
|
|
source: "https://github.com/nashsu/llm_wiki/blob/main/llm-wiki.md"
|
|
author: "nashsu"
|
|
created: 2026-08-02
|
|
description: "使用 LLM 增量构建、维护和查询个人 Wiki 的方法论；已去除项目宣传和产品推广内容。"
|
|
tags:
|
|
- "个人知识库"
|
|
- "LLM Wiki"
|
|
- "知识管理"
|
|
raw_sources:
|
|
- path: raw/LLM Wiki - Persistent Personal Knowledge Bases.md
|
|
hash: "sha256:cd64125fcf5070abff12dd8f25f0371658833d08e0138bd8ee71fc7cb9bfc89d"
|
|
last_updated: 2026-08-02
|
|
---
|
|
|
|
# LLM Wiki：构建持久累积型个人知识库
|
|
|
|
## 页面定位
|
|
|
|
本页是 LLM Wiki 的方法论总览，回答“为什么需要持久 Wiki、它由哪些层组成、摄取/查询/Lint 如何协作”。检索、队列、图谱、API 和 MCP 的工程细节见 [[LLM-Wiki-Implementation-Patterns|LLM Wiki 的实现模式]]与 [[LLM-Wiki-Desktop-Implementation|LLM Wiki 桌面实现与外部接入]]。
|
|
|
|
## 核心问题
|
|
|
|
传统 RAG 通常在每次提问时从原始文档检索片段，再即时拼接答案。它适合一次性问答，但跨多篇文档的综合结论不会自动沉淀；下一次查询仍然需要重新检索、比较和组织材料。
|
|
|
|
LLM Wiki 的方法是让 LLM 增量维护一组持久、结构化、相互链接的 Markdown 页面。新来源进入后，系统不仅保存原文，也提炼关键信息、更新实体和概念页面、修订主题总结、记录来源之间的矛盾，并把有价值的查询答案归档回 Wiki。知识因此成为持续累积的人工制品，而不是一次性响应。
|
|
|
|
## 三层架构
|
|
|
|
### 原始来源层
|
|
|
|
`raw/` 保存用户筛选过的文章、论文、图像、数据和其他材料。原始来源应当被视为事实依据，保持可追溯和尽量不可变；LLM 读取它们，但不以 Wiki 重写原文。
|
|
|
|
### Wiki 层
|
|
|
|
`wiki/` 保存由 LLM 编译出的摘要、实体页、概念页、比较、综合分析和查询归档。LLM 负责创建页面、更新页面、维护交叉链接和处理来源之间的关系；人主要负责选择来源、提出问题和审阅重要判断。
|
|
|
|
### Schema 层
|
|
|
|
Schema 是指导 LLM 维护知识库的规则文档，例如项目级 `CLAUDE.md`、`AGENTS.md` 或专门的技能文件。它应说明目录结构、页面类型、元数据格式、命名和链接约定，以及摄取、问答和健康检查的工作流。
|
|
|
|
## 三个核心操作
|
|
|
|
### Ingest：摄取
|
|
|
|
处理一个新来源时，LLM 应先理解来源内容，再将其整合到已有 Wiki：
|
|
|
|
1. 读取并概括来源，提取实体、概念、主张和证据。
|
|
2. 检索可能受影响的现有页面。
|
|
3. 判断新增内容是支持、补充、修正还是挑战已有结论。
|
|
4. 创建来源摘要，并更新相关实体、概念、索引和交叉链接。
|
|
5. 记录来源、时间和变更，保留不确定性与待核查问题。
|
|
|
|
来源可以逐篇处理以获得更强的人类监督，也可以批量处理以提高吞吐量；选择取决于内容风险和用户对自动更新的信任程度。
|
|
|
|
### Query：查询
|
|
|
|
回答问题时，先阅读索引定位相关页面，再深入读取 Wiki 和必要的原始来源，最后给出带引用的综合答案。答案不应只停留在对话中：具有通用研究价值的比较、分析、连接或新结论，应归档到 `wiki/queries/`，并加入索引。
|
|
|
|
### Lint：健康检查
|
|
|
|
定期扫描 Wiki，寻找：页面之间的矛盾、已被新来源取代的陈旧主张、没有入链的孤岛页面、被频繁提及但尚未成页的重要概念、缺失的交叉链接，以及需要外部研究填补的知识空白。Lint 的目标不是追求页面数量，而是保持知识网络可导航、可解释和可更新。
|
|
|
|
## 索引与日志
|
|
|
|
`index.md` 是面向内容的导航目录：按类别列出页面、摘要和可选元数据。它应当是 LLM 开始查询时的入口。
|
|
|
|
`log.md` 是按时间追加的操作记录，记录摄取、查询和 Lint。索引回答“知识库里有什么”，日志回答“知识库如何演变”，两者不应混为一谈。
|
|
|
|
## 为什么这种模式有效
|
|
|
|
知识库维护中最费时的部分往往不是阅读，而是重复性的整理工作：更新摘要、维护反向链接、比较新旧来源、标注矛盾和保持命名一致。LLM 擅长执行这些跨文件的 bookkeeping 工作，因此可以降低维护成本，让知识库的长期价值不再随着页面数量线性崩溃。
|
|
|
|
人和 LLM 的职责应当分开：人负责来源选择、研究方向、重要判断和高风险审阅；LLM 负责提炼、链接、归档和一致性维护。涉及事实争议、隐私或高风险决策时，应提高人工介入程度。
|
|
|
|
## 边界与代价
|
|
|
|
LLM Wiki 不是所有场景的替代方案。来源很少、问题是一次性的，或答案必须完全基于原文时，直接检索可能更简单。Wiki 层也会引入编译成本、摘要失真、旧页面漂移和错误扩散风险，因此需要来源追踪、版本控制、定期 Lint 和必要的人工审阅。
|
|
|
|
该模式最适合持续积累、需要跨来源综合、且能够接受知识在查询之间被重新组织的个人研究或项目。
|
|
|
|
## 相关研究
|
|
|
|
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
|
- [[Harness-Engineering|Harness 工程]]
|
|
- [[Memory-Systems|记忆系统]]
|
|
- [[Agent-Protocols|智能体协议]]
|
|
- [[LLM-Wiki-Implementation-Patterns|LLM Wiki 的实现模式]]
|