如何搭建 LLM Wiki

概述

LLM Wiki 不是“把资料扔给 AI，随时搜一搜”的系统，而是一套由 AI 持续维护的知识层。它的目标不是一次性回答问题，而是把资料、对话和灵感逐步整理成可复用、可追溯、可继续生长的页面。

搭建一套可用的 LLM Wiki，关键不在工具堆叠，而在工作流清晰、分层明确、归档稳定。

核心思路

• raw 存放原始输入，不等于知识
• wiki 存放整理后的理解，才是可复用资产
• capture 负责把聊天或灵感变成结构化 note
• ingest 负责把 note 正式并入 wiki
• lint 负责定期检查结构、标签、链接和页面质量

如果一句话概括：

先把内容变成 note，再把 note 变成 wiki 页面。

推荐分层

一个实用的 LLM Wiki，至少建议分成下面几层：

• raw/inbox/notes/：等待 ingest 的结构化 note
• raw/inbox/sources/：等待 ingest 的外部资料
• raw/processed/：已经 ingest 过的输入
• wiki/：综合后的主题页、方法页、概念页
• index.md：内容入口
• log.md：时间线记录
• AGENTS.md：项目规则

这些目录不是为了好看，而是为了让系统知道：

• 什么是输入
• 什么是待处理
• 什么是已归档
• 什么是长期知识

标准工作流

建议按下面的顺序使用：

1. 收集资料，或围绕一个主题和 AI 讨论
2. 如果是聊天内容，先执行 idea-capture
3. 生成结构化 note，放入 raw/inbox/notes/
4. 对 note 或 source 执行 wiki-ingest
5. 更新 wiki 页面、index.md、log.md
6. 将已处理输入移到 raw/processed/
7. 未来写作、检索、回顾主题时，优先从 wiki/ 使用这些页面
8. 定期运行 wiki-lint 做体检和修补

如何使用产物

wiki 页面通常不是最终产物本身，而是最终产物背后的知识资产层。

它常见的使用方式包括：

• 写文章前，先读相关主题页
• 做提纲时，调取已有观点、例子和结构
• 回顾某个长期主题时，快速定位已形成的理解
• 找可以继续展开的选题和开放问题

所以：

wiki 更像素材发动机，而不是最终文章仓库。

归档与检索

一个 LLM Wiki 要真正好用，必须把归档和检索规则做清楚。

归档

• 待处理内容只放在 raw/inbox/
• ingest 完成后，默认移到 raw/processed/
• raw/processed/ 保留来源、frontmatter 和 tags，确保可追溯

检索

下次检索时，建议按下面顺序：

1. 先看 index.md
2. 再按 wiki 页面主题进入
3. 根据 tags 缩小范围
4. 根据页面链接查看上下文
5. 如有需要，再通过 source_notes 回溯到原始 note

真正高效的检索，不只是搜关键词，而是顺着：

• 页面主题
• 标签
• 交叉链接
• 来源链条

把上下文一起找回来。

PlantUML 流程图

@startuml
title LLM Wiki 工作流

start

:收集资料或与 AI 讨论主题;

if (输入是对话内容?) then (是)
  :执行 idea-capture;
  :生成结构化 note;
else (否)
  :准备原始 source 文件;
endif

:将输入放入 raw/inbox/notes/\n或 raw/inbox/sources/;

:执行 wiki-ingest;

:读取 note/source;
:更新或创建 wiki 页面;
:补充 tags 和 source_notes;
:更新 index.md;
:向 log.md 追加记录;

:将已处理输入移动到 raw/processed/;

if (需要立即产出?) then (是)
  :基于 wiki 页面\n写文章 / 做提纲 / 做检索;
endif

if (需要定期维护?) then (是)
  :执行 wiki-lint;
  :检查链接、重复页、\n过时内容、缺失标签;
  :做安全修补或输出问题清单;
endif

stop
@enduml

可复用表达

• 资料不是知识，整理后的页面才是知识
• capture 是把灵感拎出来，ingest 是把它正式并入体系
• wiki 不是终点，而是未来写作和思考的中间资产层

关联页面

• LLM Wiki 工作流
• LLM Wiki 价值
• 写作型 Wiki 架构
• 项目规则与技能分工