LLM Wiki：把读过的文档编译成自维护的知识库
攒了半年的论文、公众号文章和会议记录，想让模型帮忙回答一个跨越多份材料的综合问题——常见做法是把文件传进对话框，模型现场检索片段、现场拼装；下次换个问题，一切从头再来，没有任何东西沉淀下来。LLM Wiki 把顺序反过来：LLM 读完一份新文档后，立即把理解写进一个由 Markdown 页面组成的维基——更新实体页、修订主题综述、标记与旧结论的冲突。之后提问时，模型站在一份已经组织好、互相链接的知识上回答，而且这份知识随每次导入持续变厚。
这套做法来自 Andrej Karpathy 公开的 llm-wiki 模式文档：原始版本是一页写给 Agent 看的设计稿，靠复制粘贴驱动。nashsu/llm_wiki 将这套模式实现为一款跨平台桌面应用（Tauri v2 加 React），补上了摄取队列、知识图谱、向量检索、浏览器剪藏和本地 API。理解成本因此从"每次提问"前移到了"导入文档"的那一刻；代价是每份文档都要消耗一次真实的 LLM 调用。值不值这个前移，读完下文可以自己判断。
GitHub 仓库信息
| 信息 | 内容 |
|---|---|
| 项目标题 | LLM Wiki |
| 项目描述 | 一款跨平台桌面应用：LLM 阅读你的文档，增量构建并持续维护一个有组织、互相链接的持久知识库，免去每次提问都从头检索拼装。 |
| GitHub 仓库 | nashsu/llm_wiki |
| 官网地址 | 未知（已检索但未找到可靠官网） |
| 主要开发语言 | TypeScript 70.68%、Rust 25.56%、JavaScript 3.32%（GitHub Languages，2026-09-20） |
| 开源许可证 | GPL-3.0（GitHub metadata 因自定义版权头显示 NOASSERTION） |
| 最近代码更新 | 2026-08-25（GitHub pushed_at，核对日期：2026-09-20） |
LLM Wiki 改变了哪一步
一座 LLM Wiki 知识库就是磁盘上的一个普通目录，分三层：raw/sources/ 存放你导入的原始文档，LLM 只读不改，是可核对的事实底座；wiki/ 完全归 LLM 所有，实体页、概念页、来源摘要、综述全部由 LLM 生成和维护；schema.md 与 purpose.md 提供规则与方向——前者定义页面类型和结构约定，后者记录这份知识库为何存在、关心哪些问题；仓库文档说明 LLM 在每次摄取和提问时都会读取 purpose.md，提问的上下文里还会带上 index.md 作为导航。日常操作围绕三个动作展开：Ingest（消化新来源）、Query（基于 wiki 提问）、Lint（体检链接与页面健康）。
对普通用户，这层设计换来两个具体好处。生成的 wiki 目录本身就是一个 Obsidian 库（应用会自动写入 .obsidian/ 配置），你可以随时用 Obsidian 打开，逐页核查 LLM 写了什么——不必信任黑盒，链接、frontmatter、原文引用都在眼前。同时每份生成页都带 sources: [] 字段回指原始文件，答案能一层层追到你亲手导入的那份 PDF。
摄取：分析与生成分成两轮
导入文档是价值发生的现场。LLM Wiki 把一次摄取拆成两个连续的 LLM 调用：第一轮只做分析，抽取来源里的关键实体、概念、与已有 wiki 的关联和矛盾；第二轮拿着这份分析结果去生成和更新页面。仓库文档称这一步拆分显著改善了生成质量——先想清楚再动笔，避免模型一边读一边写时的顾此失彼。
正在准备渲染...
查看源码
flowchart LR
A[raw/sources 原始文档] --> B{SHA256 与上次相同?}
B -->|是| C[跳过 不消耗 token]
B -->|否| D[第 1 轮 LLM 分析<br/>实体 概念 关联 矛盾]
D --> E[第 2 轮 LLM 生成<br/>实体页 概念页 来源摘要]
E --> F[更新 index.md log.md overview.md]
E --> G[Review 项 留给人判断]围绕这条主线，队列和缓存替用户兜底：摄取按 SHA256 哈希跳过内容未变的文件；任务串行处理并持久化到磁盘，应用崩溃或重启后队列可恢复，失败任务自动重试至多三次，活动面板实时显示进度并可取消。
格式覆盖按材料类型分档（README 格式表）：PDF、DOCX、PPTX、XLSX、EPUB/MOBI、Org mode、网页剪藏和批量 URL 做结构化提取，转成 Markdown 后进摄取管线，复杂排版的 PDF 可选接 MinerU（云端 API 或本机部署）做深度解析，失败时回退内置解析器；图片支持原生预览，PDF 内嵌图还能提取出来、由视觉模型生成事实性说明并参与搜索；音视频则在应用内直接播放。递归导入文件夹时保留目录结构，并把路径作为分类线索交给 LLM；raw/sources/ 还可以开启外部目录监听，你在应用外增删改文件，队列同步跟进。
知识图谱替你把窟窿找出来
wikilink 交叉引用只是起点，LLM Wiki 在链接之上建了一个相关度模型，图谱用四种信号给页面两两打分：
| 信号 | 权重 | 含义 |
|---|---|---|
| 直接链接 | ×3.0 | 页面之间有 [[wikilink]] |
| 来源重叠 | ×4.0 | 两页的 sources[] 引用了同一份原始文档 |
| Adamic-Adar | ×1.5 | 两页共享的邻居页，其连接数参与加权计算 |
| 类型亲和 | ×1.0 | 同类型页面（实体对实体、概念对概念）加分 |
权重最高的信号是"来源重叠"——两个页面出自同一份原始材料，在相关度里比一条直接链接更有分量。图谱进一步用 Louvain 算法自动聚出知识社区并给每个社区算内聚分，然后基于结构给出两类可操作的洞察：跨社区、跨类型的"惊人连接"，以及孤立页、稀疏社区这类"知识缺口"。缺口卡片可以直接一键发起 Deep Research：LLM 结合 overview.md 与 purpose.md 拟定研究主题和检索词，经确认对话框（主题与检索词可编辑）后，通过 Tavily、SerpApi 或自建的 SearXNG 做多查询网络搜索，把综合结果写回 wiki 并再次摄取。发现缺口、发起研究、结果回流成新知识，这个闭环是纯聊天式文档问答给不了的。
提问：检索管线与模型路由
一次提问的检索分多阶段：先做分词搜索（中文按双字切分，标题命中加分，同时搜 wiki 和原始来源），再可选地叠加向量语义检索，然后用图谱把排名靠前的页面按相关度扩展出关联页，最后在预算控制下组装上下文——窗口从 4K 到 1M 可调，wiki 页、历史、索引、系统提示按比例分配。答案要求按编号引用具体页面，回答质量因此可抽查。向量检索默认关闭，开启后嵌入走任意 OpenAI 兼容的 /v1/embeddings 端点、存进内嵌的 LanceDB；仓库文档给出的一项基准是召回率从 58.2% 提到 71.4%，这属于来源声明，实际收益取决于语料和问题类型。
模型配置按项目走：OpenAI、Anthropic、Google、Ollama 和自定义端点五种 provider，Chat 与 Ingest 可以路由到不同模型——仓库文档只声明了这条独立路由，"便宜模型摄取、强模型回答"的成本搭配需要自己实测。聊天运行时位于 Rust 后端的 Agent 里，可调用 wiki/来源/图谱/网页检索等工具，生成的文件落在 agent-workspace/ 供预览；外部 shell 命令需要显式批准。应用还兼容 SKILL.md 格式的 Agent Skills，可在对话里用 /skill 选择启用。
适合谁，不适合谁
持续为某个主题积累材料、又希望沉淀物是自己磁盘上可读可查的 Markdown 的人，最能吃到这套设计的红利：研究者管理文献、读书人建伴读 wiki、个人成长记录者整理日记与笔记，仓库的场景模板（Research、Reading、Personal Growth、Business、General）就是按这些人群预配置的。
不适合的情况同样清楚。LLM Wiki 定位个人桌面工具，没有账号体系和多人协作；Issue 区有人提议增加 Server 模式做团队知识库（#194，该请求已关闭），如果你需要的是团队协作的 RAGFlow 类产品，这个仓库不是目标。成本上，每份文档都要真金白银的 token：一个 咨询 50 万–80 万量级飞书文档性能的开放 Issue 也提醒超大语料需要先小规模评估。对隐私敏感的用户反而多一层选择——接 Ollama 本地模型即可全程离线推理，代价是效果受本机硬件限制。
最短有效体验
以下流程来自仓库文档（README 的 Installation 与 Quick Start 章节），本次写作没有把这份流程在机器上装出来跑过。目标是完成一次能体现核心价值的操作：导入几份同主题文档，看着 wiki 长出来，再提一个跨文档问题。
前置条件：一台 macOS、Windows 或 Linux 桌面机；一个可用的 LLM API key（OpenAI、Anthropic、Google 任一兼容端点，或本机 Ollama）。
- 从 Releases 下载安装包。核对日期内最新为 v0.6.11（2026-08-25），macOS 分 Apple Silicon 与 Intel 两种
.dmg，Windows 为.msi，Linux 提供.deb与.AppImage。 - 启动后新建项目，选一个场景模板。
- 进入 Settings 配置 LLM provider 与模型，Chat 与 Ingest 可分别选择。
- 进入 Sources，导入 3–5 份同主题文档（PDF、DOCX 或 Markdown 均可）。
- 观察 Activity Panel：文件逐个进入两步摄取，生成实体页与概念页，
overview.md随进度更新。 - 在 Chat 里问一个需要综合多份材料的问题，检查回答引用的页面编号。
可观察的成功信号：图谱视图里能看到新节点和连线；Review 面板出现需要你判断的条目。常见卡点在 Issue 区都有真实案例，处置办法以各 Issue 的讨论结论为准：接入 OpenAI、Kimi、MiniMax 等端点时全部报 analysis failed（#46，已关闭）；macOS 从 Dock 启动应用时 Claude Code CLI provider 提示 claude not found，而同一个命令在终端里可用（#86，已关闭）；把 Ollama 配成局域网地址后应用侧连接失败（#79，已关闭）。
浏览器剪藏与 Agent 接入
Chrome 扩展（extension/ 目录，Manifest V3）负责网页进库：开发模式加载解压扩展后，一键把当前页面经 Readability 抽取正文、Turndown 转成 Markdown，投递给本机应用并自动触发摄取，快捷键是 Alt+Shift+L（macOS 为 Command+Shift+L）。
对 Claude Code、Codex 这类编程 Agent，仓库提供了两条标准接口。应用内置 127.0.0.1:19828 的本地 HTTP API（Settings → API + MCP 中启用并生成 token），暴露混合检索、文件读取、图谱遍历、Review 管理、来源重扫等端点；mcp-server/ 是把同一 API 面包装成的 MCP 服务器，构建后在设置页可复制本机路径的客户端配置。MCP 工具继承本地安全模型：默认只连回环地址（可用 LLM_WIKI_API_BASE_URL 覆盖）、文件读取走应用的路径白名单、令牌用环境变量传递而不写进命令行参数（mcp-server/README.md）。官方另备一个现成的 Agent Skill，一条命令装入 Claude Code / Codex：
npx skills add https://github.com/nashsu/llm_wiki_skill.git --skill llm-wiki该 Skill 默认只读、引用 wiki 页面路径，且只在明确点名 LLM Wiki 时触发。
从源码构建与运行
想改界面或跟进未发布功能时，按 README 的构建说明准备 Node.js 20+、Rust 1.88+ 和 protoc（macOS brew install protobuf，Linux sudo apt install protobuf-compiler，Windows choco install protoc），然后：
git clone https://github.com/nashsu/llm_wiki.git
cd llm_wiki
npm install
npm --prefix mcp-server ci && npm run mcp:build # mcp-server/dist 会打进 Tauri 资源
npm run tauri dev # 开发运行
npm run tauri build # 产出安装包仓库自带 macOS/Windows/Linux 的 CI 构建工作流，个人试用建议直接用 Release 安装包，把源码方式留给定制需求。
数据、迁移与清理
一座知识库的磁盘结构决定了数据归属（README 项目结构）：
my-wiki/
├── purpose.md # 目标、关键问题、研究范围
├── schema.md # 页面类型与结构规则
├── raw/sources/ # 原始文档（不可变）
├── raw/assets/ # 本地图片资源
├── wiki/ # LLM 生成层：index、log、overview、
│ # entities、concepts、sources、queries…
├── agent-workspace/ # Agent 生成文件的位置（未列于 README 结构图）
├── .obsidian/ # 自动生成的 Obsidian 配置
└── .llm-wiki/ # 会话历史、Review 条目等应用状态删除一份来源会级联清理：对应的摘要页移除，被多来源共享的实体页只从 sources[] 里摘掉这一项，index.md 与失效 wikilink 同步更新。项目整体支持 ZIP 导出/导入，跨设备迁移后可从现有页面确定性地重建索引。全部内容是明文 Markdown，备份就是复制目录。需要留意的是 GPL-3.0 许可证：自用与分享文档没有障碍，但分发修改版应用要遵守 copyleft 义务。
限制与下一步
这套架构的软肋与优点同源。wiki 是 LLM 写的，就会错——Review 系统、引用编号和 Obsidian 兼容都是在给错误兜底，但核查责任仍在使用者；摄取质量与模型能力强相关，弱模型加超大语料的组合成本可观。桌面形态决定了没有服务端权限模型，本地 HTTP API 虽然只绑回环地址，同机进程仍可访问，开启"无 token 本地访问"前要想清楚这一点。
下一步最有信息量的动作，是拿自己真实的 5–10 份文档跑一遍上面的最短体验，再故意问一个跨两份材料、答案互相矛盾的问题，观察 Review 与图谱如何呈现冲突——这比任何评测数字都更能说明 LLM Wiki 适不适合你的知识库。