87 lines
5.2 KiB
Markdown
87 lines
5.2 KiB
Markdown
---
|
||
title: "LLM Wiki：构建持久累积型个人知识库"
|
||
source: "https://github.com/nashsu/llm_wiki/blob/main/llm-wiki.md"
|
||
author: "nashsu"
|
||
published:
|
||
created: 2026-08-02
|
||
description: "关于使用 LLM 增量构建、维护和查询个人 Wiki 的方法论；已去除项目宣传和产品推广内容。"
|
||
tags:
|
||
- "个人知识库"
|
||
- "LLM Wiki"
|
||
- "知识管理"
|
||
---
|
||
|
||
# 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 的实现模式]] - 将方法论落实为摄取、检索和维护组件
|
||
|
||
## 原始来源
|
||
|
||
- [nashsu/llm_wiki：llm-wiki.md](https://github.com/nashsu/llm_wiki/blob/main/llm-wiki.md)
|