从 RAG 到 LLM Wiki：一种可持续演化的个人知识库技术方案

一、引言：知识不该死在聊天记录里

原文链接：LLM Wiki
原文副标题：A pattern for building personal knowledge bases using LLMs.

过去两年，很多人使用大模型处理资料的方式越来越像这样：上传几篇论文、几份会议纪要、几个网页剪藏，然后问它：“帮我总结一下”“这几份材料有什么冲突”“给我写一份技术方案”。模型确实能给出不错的答案，但问题也很明显：这次综合出的知识，大概率会死在这次聊天记录里。

下一次你换个角度再问，它又要重新检索、重新拼接、重新推理。上一次好不容易得出的概念关系、矛盾点、判断依据、对比表，并没有变成一个可以长期复用的资产。

这正是 Karpathy 在 LLM Wiki 里提出的关键洞察：传统 RAG 解决的是“从资料里找答案”，但它不天然解决“让知识长期沉淀、结构化演化并持续复用”。如果我们把 LLM 从一次性问答器，升级为一个长期维护 Markdown Wiki 的知识工程师，事情就会完全不同。

图注：RAG 更像“查询时综合”，LLM Wiki 更像“持续性知识编译”。两者不是互斥关系，LLM Wiki 可以在 RAG 之上增加一个可版本化、可审计、可复用的知识层。

本文会把原文中的模式扩展成一套更完整的技术方案：它应该如何分层？目录如何组织？LLM Agent 应该遵守什么规则？如何摄入资料、回答问题、做健康检查？如何用 Git、Obsidian、本地搜索和 MCP 把这个系统做成可长期运行的个人 Memex？

二、核心理念：从“检索增强生成”到“知识编译系统”

传统 RAG 的典型流程是：

1. 把文档切块；
2. 为每个 chunk 建索引；
3. 用户提问时检索相关片段；
4. LLM 基于片段生成答案。

这个模式非常适合“从资料里找信息”。但当问题变成“长期研究一个主题”时，它会暴露出三个结构性短板。

2.1 RAG 的第一个短板：没有长期综合层

RAG 检索到的是片段，不是知识结构。

比如你研究一个复杂开源项目，第一次问“它的架构怎么分层”，模型读了 8 个片段，生成了一份不错的架构说明；第二次问“它和另一个项目有什么差异”，模型又重新检索另一批片段。上一次的架构理解并不会自动变成下一次的中间表示。

这就像编译器每次执行程序都从源码重新猜 AST，却从不保存中间产物。

LLM Wiki 的做法是：把一次综合的结果保存成页面。架构说明变成 syntheses/architecture-overview.md，项目实体变成 entities/project-x.md，关键概念变成 concepts/scheduler.md。下一次查询时，LLM 不只读原始资料，也读这些已经编译过的知识页面。

2.2 RAG 的第二个短板：答案没有写回闭环

很多高价值内容不是来自原始资料，而是来自“围绕资料的提问”。

例如：

• “这三种方案的本质差异是什么？”
• “哪些结论互相矛盾？”
• “如果要落地成 MVP，优先级怎么排？”
• “哪些部分需要补充资料？”

这些问题会生成新的对比、新的抽象、新的判断。如果答案只停留在聊天窗口里，它就无法参与后续推理。LLM Wiki 的关键机制是：好的查询结果也要写回 Wiki。

这让 Query 不只是消费知识，也成为生产知识的一部分。

2.3 RAG 的第三个短板：缺少可审计的演化历史

知识不是静态的。今天的结论可能被明天的新资料推翻，两个来源可能互相冲突，早期摘要可能被后来的理解修正。

传统聊天记录很难维护这种演化过程。LLM Wiki 则天然适合 Git：每次新增页面、更新引用、标记矛盾、重构目录，都可以通过 diff 审查；如果 LLM 犯错，也可以回滚。

这就是原文那句非常重要的类比：

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

Obsidian 是知识 IDE，LLM 是知识库程序员，Markdown Wiki 是知识代码库。

三、总体架构：Raw Sources、Wiki、Schema 三层模型

LLM Wiki 最小可行架构并不复杂，核心是三层：

• Raw Sources：原始资料层；
• Markdown Wiki：知识编译层；
• Schema：约束 LLM 行为的规则层。

图注：Raw Sources 提供不可变证据，Schema 约束 Agent 的维护行为，Markdown Wiki 保存结构化知识。Obsidian、Git、Dataview、本地搜索与 MCP 则构成外围工具链。

3.1 Raw Sources：不可变事实源

raw/ 目录保存的是原始资料，例如：

• 网页剪藏；
• 论文 PDF；
• 技术报告；
• 会议纪要；
• 图片、表格、日志；
• 用户自己的原始笔记。

这一层最重要的原则是：LLM 可以读，但不应该改。

原因很简单：Wiki 页面是解释、摘要、综合，可能出错；Raw Sources 是证据链的根。如果 LLM 可以随意修改原始资料，整个知识库就会失去可审计性。

这和数据库里的 source of truth 很像：上层缓存、视图、报表都可以重建，但原始事实不能被悄悄污染。

3.2 Markdown Wiki：知识编译层

wiki/ 目录保存由 LLM 生成和维护的结构化页面。它不是原始资料的简单摘要，而是一个持续演化的知识网络。

典型页面类型包括：

如果说 Raw Sources 是源码，Wiki 就是编译后的中间表示：更适合阅读、链接、查询和二次推理。

3.3 Schema：让 Agent 稳定工作的维护契约

Schema 不是数据库 schema，而是一份写给 LLM Agent 的规则文件。不同工具可以叫不同名字：AGENTS.md、CLAUDE.md、CODEBUDDY.md、README.md 都可以。

它至少要规定：

• 目录结构；
• 文件命名规则；
• 页面 frontmatter；
• 引用格式；
• Ingest 流程；
• Query 流程；
• Lint 流程；
• 何时创建新页面；
• 如何更新 index.md；
• 如何追加 log.md；
• 如何处理矛盾；
• 哪些修改必须等待人类审查。

没有 Schema，LLM 只是一个“会写 Markdown 的聊天机器人”；有了 Schema，它才更像一个“有工程纪律的知识库维护者”。

四、目录结构设计：先用文件系统表达知识边界

一个实用的 LLM Wiki 可以从下面的目录结构起步：

knowledge-base/
  raw/
    articles/
    papers/
    meetings/
    assets/
    notes/
  wiki/
    index.md
    log.md
    overview.md
    entities/
    concepts/
    sources/
    syntheses/
    comparisons/
    timelines/
    contradictions/
  AGENTS.md
  README.md

这套结构背后的设计原则是：用目录把不同知识对象的生命周期区分开。

4.1 raw/：保留事实原貌

raw/ 下的文件最好只做两类操作：新增和重命名。不要让 Agent 修改正文。

如果网页剪藏里有图片，建议把图片下载到 raw/assets/，不要只保留外部 URL。很多网页几年后会失效，图片链接更脆弱。本地化资产能让知识库更接近一个自包含档案馆。

4.2 wiki/index.md：让 Agent 不迷路

index.md 是内容地图。它不必复杂，但要稳定。

一个简单条目可以长这样：

## Concepts

- [[concepts/knowledge-compounding.md]] - 解释查询结果写回 Wiki 后如何形成知识复利。
- [[concepts/source-of-truth.md]] - 说明 Raw Sources 与 Wiki 页面之间的证据关系。

## Syntheses

- [[syntheses/rag-vs-llm-wiki.md]] - 对比传统 RAG 与 LLM Wiki 的系统边界。

对 LLM 来说，index.md 就像代码仓库里的 README + symbols index。当 Wiki 还在数百页以内时，一个维护良好的 index.md 往往比一套复杂向量库更可靠。

4.3 wiki/log.md：记录知识库如何演化

log.md 是 append-only 的时间线。每次摄入、查询写回、Lint、重大重构，都追加一条记录。

## [2026-04-29] ingest | LLM Wiki gist

- Added source summary: [[sources/llm-wiki-karpathy.md]]
- Updated concept pages: [[concepts/llm-wiki.md]], [[concepts/knowledge-compounding.md]]
- Created synthesis: [[syntheses/rag-vs-llm-wiki.md]]
- Open questions: how to evaluate contradiction detection quality?

log.md 的价值在于：它让知识库有“时间感”。你不仅知道现在有什么页面，还知道这些页面为什么出现、何时被更新、哪些问题还悬而未决。

4.4 页面 frontmatter：给工具和人类共同读取的元数据

Markdown 页面建议统一 frontmatter。比如：

---
title: "Knowledge Compounding"
type: "concept"
status: "draft"
created: "2026-04-29"
updated: "2026-04-29"
sources:
  - "raw/articles/llm-wiki.md"
confidence: "medium"
tags:
  - llm-wiki
  - knowledge-management
---

这里的 status、sources、confidence 很关键：

• status 表示页面成熟度，避免草稿被误当成定论；
• sources 表示证据来源，防止无引用主张扩散；
• confidence 表示综合结论的置信度，提醒读者哪些内容还需要复核。

如果配合 Obsidian Dataview，这些元数据还能生成动态列表，例如“所有低置信度结论”“最近 7 天更新的 synthesis”“没有来源引用的页面”。

五、核心工作流：Ingest、Query、Lint

LLM Wiki 的生命力来自三个循环：摄入资料、查询生成、健康检查。

图注：Ingest 负责增长，Query 负责复用和再生产，Lint 负责维护知识库健康度。三者共同构成长期知识系统的运行闭环。

5.1 Ingest：新资料不只是“入库”，而是“并入知识网络”

当一份新资料进入 raw/ 后，Agent 不应该只做摘要，而应该执行一次结构化摄入。

推荐流程：

1. 阅读新资料，提取标题、作者、日期、来源、核心论点；
2. 创建 wiki/sources/<source-name>.md；
3. 标注关键事实和引用位置；
4. 查找现有实体页、概念页、综合页；
5. 更新相关页面；
6. 如果出现新概念，创建新概念页；
7. 如果新资料推翻旧结论，写入 contradictions/ 或在相关页面标记；
8. 更新 index.md；
9. 追加 log.md。

这一步的本质不是“总结文件”，而是“把一个新证据并入已有知识图谱”。

一个好的摄入提示可以这样写：

请摄入 raw/articles/llm-wiki.md：

1. 创建 source summary 页面，保留核心引用和原文链接。
2. 找出已有 wiki 页面中需要更新的实体、概念和 synthesis。
3. 新建必要概念页，但避免重复创建同义页面。
4. 如果新资料与旧页面冲突，不要覆盖旧结论，先标记 contradiction。
5. 更新 index.md，并在 log.md 追加本次摄入记录。
6. 所有新增主张必须能追溯到 source 页面或 raw 文件。

这里最重要的一句是：不要覆盖冲突，先标记冲突。知识库不是只保存“看起来一致”的结论，而是要保存证据之间的张力。

5.2 Query：从 Wiki 中回答，并把高价值答案写回 Wiki

Query 阶段不只是问答。它应该遵守三段式：定位、综合、沉淀。

第一步，Agent 先读 index.md，确定可能相关的页面。必要时再用本地搜索工具查找关键词或语义相似页面。

第二步，Agent 阅读相关页面和 source 引用，生成答案。答案里要区分：

• 哪些是来源明确的事实；
• 哪些是跨来源综合；
• 哪些是推断；
• 哪些仍然不确定。

第三步，如果这次回答产生了可复用知识，就应该写回 Wiki。例如：

• 生成了一个新的多方案对比表；
• 梳理出一个系统架构；
• 总结出一条技术路线图；
• 发现两个概念之间的新关系；
• 提出了值得后续研究的问题清单。

这类内容不应该只存在于聊天记录中。它们应该成为 syntheses/、comparisons/ 或 questions/ 页面。

5.3 Lint：知识库也需要静态分析

当 Wiki 页面越来越多，知识债务会自然出现：重复页面、孤岛页面、过期结论、缺失引用、概念命名不一致、页面互相矛盾。

这时需要 Lint。

典型检查项包括：

Lint 的频率可以按规模调整：小型个人 Wiki 每周一次即可；团队 Wiki 或快速增长的研究项目，可以每天或每次批量摄入后执行。

六、Schema 设计：Agent 的“操作系统说明书”

LLM Wiki 成败的关键不在模型有多聪明，而在 Agent 的行为是否稳定。稳定性的核心就是 Schema。

图注：Schema 不是摆设，而是 Agent 维护 Wiki 的操作系统说明书。它定义目录、页面格式、工作流、索引、日志、冲突处理和安全边界。

6.1 Schema 应该包含哪些规则

一份实用的 AGENTS.md 可以包含以下章节：

# Knowledge Base Maintenance Rules

## Repository layout
- raw/ is immutable evidence. Never edit raw files unless explicitly asked.
- wiki/ is maintained by the Agent.

## Page types
- source: one page per raw source
- entity: people, projects, organizations, systems
- concept: reusable ideas and technical terms
- synthesis: cross-source analysis
- comparison: side-by-side evaluation
- contradiction: unresolved conflicts

## Citation rules
- Every factual claim must link to a source page or raw file.
- If a claim is inferred, mark it as inference.
- If confidence is low, set confidence: low in frontmatter.

## Ingest workflow
...

## Query workflow
...

## Lint workflow
...

规则不要写成散文，尽量写成可执行 checklist。LLM 对明确步骤的遵守通常比对抽象原则更稳定。

6.2 “无引用，不主张”原则

知识库最怕的是幻觉被沉淀下来。一旦错误结论进入 Wiki，它会被未来查询反复读取，形成“自我污染”。

因此建议把下面这条写进 Schema：

No citation, no claim.
If a statement cannot be traced to a source, mark it as hypothesis or remove it.

中文可以理解为：没有证据链的内容，只能作为假设，不能作为结论。

6.3 冲突不是异常，而是一等公民

很多知识库会下意识追求“整洁一致”，但真实世界的资料经常互相矛盾。LLM 不应该急着把冲突抹平。

更好的做法是：

When sources conflict:
1. Do not overwrite the older claim silently.
2. Record both claims with source references.
3. Create or update a contradiction page.
4. Explain possible reasons: date, scope, definition, measurement method.
5. Mark what evidence would resolve the conflict.

这种设计会让 Wiki 更像研究系统，而不是宣传材料。

七、检索策略：不是一上来就需要向量数据库

很多人一提知识库就想到 embedding、向量数据库、rerank、混合检索。它们当然有价值，但 LLM Wiki 的一个重要观点是：中小规模知识库不必一开始就上复杂基础设施。

7.1 第一阶段：index.md + 文件系统搜索

如果资料规模在 100 个 source、几百个 Wiki 页面以内，维护良好的 index.md 加上文件系统搜索已经足够强。

优点：

• 简单；
• 可读；
• 易调试；
• 没有索引同步问题；
• Agent 能直接理解目录结构。

这一阶段最重要的是索引质量，而不是搜索算法。index.md 的摘要越清晰，Agent 越容易定位页面。

7.2 第二阶段：BM25 + frontmatter 过滤

当页面数量增长后，可以加入本地 Markdown 搜索工具。关键词搜索依然非常有价值，因为很多技术术语、项目名、函数名、论文名就是精确字符串。

可以按这些字段过滤：

• type：只搜 concept 或 synthesis；
• status：排除 archived；
• updated：优先近期页面；
• tags：限定主题；
• confidence：区分低置信度和高置信度页面。

这一阶段的目标是“让 Agent 更快找到候选页面”，而不是让搜索系统替代 Wiki 结构。

7.3 第三阶段：向量搜索 + MCP 工具化

当知识库达到数千页面、跨主题、多团队协作时，向量搜索和混合检索才开始明显必要。

推荐路线是：

1. 保留 Markdown 文件作为主存储；
2. 用索引器派生 BM25 / embedding 索引；
3. 通过 CLI 或 MCP 暴露搜索能力；
4. 搜索结果返回页面路径、摘要、匹配片段和置信度；
5. Agent 最终仍然读取 Markdown 原文再回答。

也就是说，搜索索引是加速器，不是 source of truth。

八、质量控制：让知识库可信，而不是看起来很聪明

LLM Wiki 的最大风险不是“生成得不够多”，而是“生成得太顺滑”。一篇语气自信但引用薄弱的页面，会比空白页面更危险。

8.1 风险一：幻觉被长期保存

聊天里的幻觉，最多影响一次回答；Wiki 里的幻觉，会影响未来许多次回答。

治理方式：

• 所有事实主张必须有 source；
• 推断必须标记为 inference；
• 低置信度页面必须写明不确定性；
• 重要 synthesis 需要人工审查；
• 定期 Lint 查找无引用断言。

8.2 风险二：错误合并概念

LLM 有时会把相似概念合并。例如把“个人知识库”“企业知识库”“RAG 系统”“Wiki 系统”混成一个页面。短期看很整洁，长期会造成概念污染。

治理方式：

• 合并页面前列出相同点和差异点；
• 无法确定时保留两个页面，并建立 related 链接；
• 在概念页开头写清楚定义边界；
• 对同名不同义概念使用命名空间。

8.3 风险三：自动编辑污染大范围页面

一次摄入可能影响 10 到 15 个页面。如果 Agent 大范围重写，会让 Git diff 失去可审查性。

治理方式：

• 要求 Agent 做最小修改；
• 大规模重构前先生成计划；
• 每次提交只包含一个明确主题；
• 对关键页面启用人工审查；
• 用 Git diff 检查是否有无关改动。

8.4 风险四：隐私和敏感资料泄露

个人 Wiki 可能包含健康、财务、日记、公司内部资料。团队 Wiki 可能包含客户信息和商业机密。

治理方式：

• 明确哪些目录不能被外部模型读取；
• 本地优先处理敏感资料；
• 对导出和分享设置白名单；
• 不把密钥、账号、个人隐私写入可公开页面；
• Git 仓库注意私有权限和历史记录清理。

九、落地实施方案：30 天把 LLM Wiki 跑成一个可用系统

LLM Wiki 不应该一开始就做成大工程。真正可行的路线是：先用一个真实主题跑通闭环，再围绕质量、检索、协作逐步工程化。如果第一周就引入向量数据库、复杂权限系统和自动化流水线，通常会把注意力从“知识是否真正复用”转移到“工具是否足够酷”。

下面给出一套可以直接在实际项目中照搬的 30 天实施方案。

图注：30 天路线图强调每个阶段都要有可检查产物。不要追求一次性完美架构，而要持续验证“摄入—查询—写回—审查”闭环。

9.1 第 0~3 天：准备与建仓

目标不是“搭完平台”，而是准备一个可被 Agent 稳定维护的最小工作区。

输入材料：

• 一个明确主题，例如“LLM Wiki 落地”“某个开源项目调研”“竞品分析”“团队故障复盘”；
• 5~10 个高质量 source，优先选择你真的会反复使用的资料；
• 一个 LLM Agent 工具，例如 Claude Code、CodeBuddy、Codex CLI 或其他能读写本地文件的 Agent。

必须完成的目录结构：

knowledge-base/
  raw/
    articles/
    papers/
    meetings/
    assets/
  wiki/
    index.md
    log.md
    sources/
    concepts/
    syntheses/
    comparisons/
    contradictions/
  AGENTS.md
  README.md

AGENTS.md 最小规则：

# LLM Wiki Maintenance Rules

1. raw/ is immutable evidence. Never edit raw files unless explicitly asked.
2. wiki/ is maintained by the Agent.
3. Every factual claim in wiki/ must cite a source page or raw file.
4. New pages must be added to wiki/index.md.
5. Every ingest, query writeback, lint, or refactor must append wiki/log.md.
6. If sources conflict, preserve both claims and create/update contradictions/.
7. Prefer small diffs. Do not rewrite unrelated pages.

验收标准：

• raw/ 和 wiki/ 边界清晰；
• Agent 能读到 AGENTS.md 并按规则输出；
• 手工摄入 1 个 source 后，能看到 sources/、index.md、log.md 同步更新；
• Git diff 中没有无关重写。

9.2 第 4~10 天：MVP 闭环

这一阶段只关心一件事：让知识真的复用起来。

图注：MVP 不需要复杂平台，但需要清晰任务拆解。每张卡片都应该对应一个可检查交付物，而不是一句抽象愿望。

推荐执行顺序：

1. 每天摄入 1~3 个 source，不要一次性批量导入；
2. 每个 source 都创建一个 wiki/sources/<slug>.md；
3. 每次摄入至少更新一个 concepts/ 或 syntheses/ 页面；
4. 每天结束前检查 index.md 是否能导航到新增页面；
5. 每天追加 log.md，记录本次摄入影响了哪些页面；
6. 第 7~10 天提出 5 个跨资料问题，观察是否能基于 Wiki 回答；
7. 对高价值答案执行写回，形成新的 syntheses/ 或 comparisons/ 页面。

建议的 5 类回归问题：

MVP 成功标准：

• 至少摄入 10 个 source；
• 生成 20~40 个 Wiki 页面；
• 至少有 3 个 syntheses/ 页面不是单篇摘要，而是跨资料综合；
• 至少 30% 的高价值查询被写回 Wiki；
• 一周后再问相似问题，答案明显能复用之前的综合页面。

9.3 第 11~20 天：质量门禁与检索增强

当页面开始增长，真正的风险不是“资料不够”，而是“知识债务变多”。这时要引入质量门禁。

图注：LLM Wiki 的健康度不能只看页面数量。更重要的是引用覆盖率、孤岛页面、索引延迟、冲突积压、查询写回率和审查 SLA。

建议落地的 6 个指标：

首次 Lint 提示模板：

请对 wiki/ 执行一次健康检查：

1. 找出没有进入 index.md 的页面。
2. 找出没有 source 引用的事实主张。
3. 找出孤岛页面：没有入链或出链。
4. 找出疑似重复概念页，并说明是否建议合并。
5. 找出过期结论：被更新 source 推翻但未标记 outdated 的页面。
6. 输出一份 Wiki Health Report，并按优先级列出修复清单。
7. 不要直接大规模修改，先给出计划和影响范围。

何时引入搜索增强：

• 页面少于 100：优先维护 index.md，不要急着上向量库；
• 页面 100~500：加入本地全文搜索或 BM25；
• 页面超过 500，且跨主题明显：考虑向量搜索 + BM25 混合检索；
• 团队共享场景：通过 MCP 或 CLI 暴露搜索能力，并保留 Markdown 作为主存储。

9.4 第 21~30 天：团队化运行与 Runbook 固化

当 MVP 被证明有价值后，就要把“个人使用习惯”固化成“团队可执行流程”。否则知识库会再次退化成少数人的私人笔记。

图注：团队化运行的关键是明确人类、Agent、Git、Obsidian 和检索索引各自负责什么。知识库不是生成一次，而是每天运行。

每日 Runbook：

Daily LLM Wiki Runbook

1. Human selects 1~3 new sources and writes the research focus.
2. Agent ingests each source separately.
3. Agent updates sources/, concepts/, syntheses/, index.md, log.md.
4. Human reviews Git diff.
5. Human opens Obsidian graph and checks whether new pages are connected.
6. If search index exists, rebuild or refresh it.
7. Run one regression query from the question set.
8. If answer produces reusable insight, write it back to wiki/.

每周 Runbook：

Weekly LLM Wiki Review

1. Run wiki lint and generate Wiki Health Report.
2. Review unresolved contradictions.
3. Merge duplicate concepts or add disambiguation notes.
4. Find top 10 orphan pages and decide: link, merge, archive, or delete.
5. Review draft synthesis pages and promote reliable ones to reviewed.
6. Update AGENTS.md if Agent repeatedly makes the same mistake.
7. Pick next week's research questions.

团队角色建议：

9.5 可直接复用的 Agent Prompt 模板

下面这些模板可以直接复制到实际项目中使用。

单篇摄入模板：

请摄入 raw/articles/<file>.md。

要求：
1. 创建 wiki/sources/<slug>.md，包含摘要、核心论点、关键引用、局限性。
2. 更新相关 concepts/、entities/、syntheses/ 页面。
3. 如果没有合适页面，先说明新建理由，再创建页面。
4. 所有事实主张必须引用 source。
5. 如果与旧页面冲突，不要覆盖旧结论，更新 contradictions/。
6. 更新 wiki/index.md。
7. 追加 wiki/log.md。
8. 最后输出 Git diff 摘要：新增页面、修改页面、潜在风险。

查询写回模板：

请基于 wiki/ 回答下面的问题：<question>

要求：
1. 先读取 index.md 定位相关页面。
2. 回答中区分事实、综合判断和推断。
3. 每个关键结论给出来源引用。
4. 如果本次回答产生可复用洞察，请建议写回到哪个页面。
5. 在我确认后，再执行写回和 log.md 更新。

质量检查模板：

请执行一次 Wiki Lint，不要直接修改文件，先输出报告：

- orphan pages
- duplicate concepts
- missing citations
- outdated claims
- unresolved contradictions
- index drift
- log missing entries
- recommended fixes ranked by impact

9.6 实战验收清单

一个 LLM Wiki 项目是否已经“可用”，可以用下面这张清单判断：

这时 LLM Wiki 就不只是个人第二大脑，而是一个可被持续运营的知识系统。

十、为什么它像 Memex：LLM 补上了“维护关联”的缺口

原文最后把 LLM Wiki 和 Vannevar Bush 在 1945 年提出的 Memex 联系起来。Memex 的核心不是搜索框，而是个人化、可关联、可追溯的知识空间。

过去的问题是：谁来维护这些关联？

人类一开始很有热情，后来会被琐碎维护拖垮：补链接、改摘要、合并重复页面、更新索引、处理冲突、维护时间线。知识库价值越高，维护成本也越高，最后很多 Wiki 都变成了“曾经很有用的废墟”。

LLM 的优势恰好在这里：它不怕重复劳动，擅长读写 Markdown，可以一次修改多个文件，可以按规则更新索引，可以做周期性检查。人类不再需要承担所有簿记工作，而是把注意力放回更重要的事情：选择资料、提出问题、判断意义。

图注：LLM Wiki 的核心飞轮是“摄入—结构化—链接—查询—写回—Lint”。只有形成写回闭环，知识才会产生复利。

十一、技术方案小结：LLM Wiki 的十条设计原则

最后，把这套方案浓缩成十条原则：

1. Raw Sources 不可变：原始资料是证据源，不要让 Agent 悄悄修改。
2. Wiki 是知识编译层：它不是文件仓库，而是持续演化的结构化理解。
3. Schema 是系统稳定性的核心：规则越清晰，Agent 越像维护者，而不是聊天者。
4. index.md 让 Agent 不迷路：中小规模下，一个好索引比复杂基础设施更重要。
5. log.md 让知识库有时间感：每次摄入、查询写回和重构都应该可追溯。
6. 好答案必须写回：查询不是终点，而是知识增长的一部分。
7. 冲突要保留，不要抹平：矛盾是研究对象，不是格式错误。
8. 无引用，不主张：没有证据链的内容只能是猜想，不能沉淀为结论。
9. Git 是安全网：diff、review、rollback 让知识库维护具备工程纪律。
10. 从简单开始，按规模演进：Markdown + Obsidian + Agent 足以启动，复杂检索和 MCP 可以后置。

如果说 RAG 是给大模型装上“临时资料夹”，那么 LLM Wiki 就是给它一个“长期工作区”。前者让模型在一次问答中更聪明，后者让你的知识系统在每一次互动后都更聪明。

真正迷人的地方也在这里：当 LLM 不再只是回答问题，而是持续维护一个可版本化的知识网络时，我们离个人 Memex 的设想就近了一大步。

× 爱折腾的工程师

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →