你有没有过这样的经历收藏了 500 篇技术文章买了 20 本电子书存了无数 PDF 论文——然后每次需要某个知识点时还是去 Google 重新搜一遍。你的硬盘里躺着一座金矿但你永远懒得去挖。不是因为懒是因为没人帮你整理。今天我们要聊的这个项目就是来当那个帮你整理的人的。而且它不嫌烦、不喊累、不会做到一半跑去刷手机——它是一个 LLM。一、故事的起点为什么我们需要重新思考知识管理1.1 一个古老而尴尬的困境先说个扎心的事实人类发明了搜索引擎、笔记软件、知识库工具但绝大多数人的知识管理状态依然是收藏即埋葬。你把文章存进收藏夹的那一刻心里想的是以后再看。但以后永远不会来。那些精心分类的文件夹、那些打了标签的笔记、那些花了半小时整理的思维导图——它们静静地躺在硬盘里像一座座从未被发掘的陵墓。原因很简单维护知识库是一件反人类的事情。更新交叉引用烦。保持摘要最新烦。发现新资料和旧资料矛盾了还要去改更烦。人类的大脑天生就不适合做这种重复性的、低刺激的、需要持续注意力的图书管理员工作。1.2 RAG 的承诺与局限后来RAGRetrieval-Augmented Generation出现了。它的思路很直接你把文档丢进去提问的时候它去检索相关片段然后让 LLM 基于这些片段生成回答。听起来很美好但 RAG 有一个根本性的问题——它每次都是从零开始。你问它一个问题它去检索、拼凑、回答。你再问一个相关问题它又从头检索一遍。没有任何积累没有任何沉淀。知识不会随着使用而增长就像一个人每天早上醒来都失忆了一样。Karpathy 在他的 llm-wiki.md 里把这个问题描述得很透彻Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up.翻译成人话就是每次提问都要重新拼图拼完就散下次再拼。1.3 LLM Wiki 的破局思路LLM Wiki 项目的核心洞察只有一句话但足够颠覆与其每次查询都从头检索不如让 LLM 增量地构建和维护一个持久化的 Wiki。知识只编译一次然后持续更新而不是每次查询都重新推导。这就像是从每次做饭都去菜市场买菜变成了在家里建一个食材库有人帮你随时补货和整理。你只需要负责想吃什么菜剩下的交给那个不知疲倦的厨房管理员。而这个厨房管理员就是 LLM。二、技术架构全景三层蛋糕的配方2.1 三层架构原始层、知识层、规则层LLM Wiki 的架构可以用一个三层蛋糕来理解┌─────────────────────────────────────────────┐ │ Schema 层规则与配置 │ │ schema.md purpose.md — 告诉 LLM 怎么干活 │ ├─────────────────────────────────────────────┤ │ Wiki 层LLM 生成 │ │ entities/ concepts/ sources/ ... — 知识本体 │ ├─────────────────────────────────────────────┤ │ Raw 层不可变原始资料 │ │ raw/sources/ — 你的 PDF、DOCX、Markdown... │ └─────────────────────────────────────────────┘最底层是 Raw Sources——你上传的原始文档PDF、Word、网页剪藏什么格式都行。这一层是不可变的LLM 只读不写。它是你的事实来源source of truth就像学术研究中的原始文献。中间层是 Wiki——这是 LLM 的作品。它读取你的原始文档提取实体、概念、论点生成结构化的 Markdown 页面页面之间用[[wikilink]]交叉引用。这一层完全由 LLM 拥有和维护你只负责看不负责写。最顶层是 Schema——这是规则书。它告诉 LLMWiki 的结构是什么样的有哪些页面类型摄入新文档时要遵循什么流程。还有一个叫purpose.md的文件定义这个 Wiki为什么存在——它的目标、关键问题、研究范围。Schema 是结构规则Purpose 是方向意图两者缺一不可。2.2 三大核心操作Ingest、Query、Lint整个系统围绕三个核心操作运转Ingest摄入你丢一份新文档进来LLM 读取它写一个摘要页面更新相关实体和概念页面在 index.md 里登记在 log.md 里记录一笔。一份文档可能触及 10-15 个 Wiki 页面。Query查询你问问题LLM 搜索相关页面读取它们综合出一个带引用的答案。有价值的回答还可以存档回 Wiki变成新的知识页面——你的探索也会让知识库变得更丰富。Lint检查定期让 LLM 给 Wiki 做体检。找矛盾、找过时信息、找孤立页面、找缺失的交叉引用。就像代码的 linter 一样保持知识库的健康度。2.3 技术栈选型为什么是这些来看技术选型每一层都有讲究层级技术选择为什么桌面框架Tauri v2Rust 后端轻量、安全、跨平台Rust 处理文件 I/O 和解析速度快前端React 19 TypeScript Vite生态成熟类型安全Vite 开发体验极佳UI 组件shadcn/ui Tailwind CSS v4不锁定组件库样式可定制性强编辑器MilkdownProseMirror 内核WYSIWYG 编辑支持数学公式插件图谱可视化sigma.js graphology ForceAtlas2性能好支持力导向布局交互流畅向量数据库LanceDBRust 嵌入式可选模块Rust 原生与 Tauri 后端天然契合状态管理Zustand轻量、无样板代码、TypeScript 友好文档解析pdf-extract docx-rs calamine纯 Rust 实现无需外部依赖这里有几个值得玩味的选择。为什么用 Tauri 而不是 Electron因为 Electron 打包一个 Hello World 就要 150MB而 Tauri 利用系统自带的 WebView安装包可以小到 10MB 以下。对于一个需要频繁读写本地文件的知识库应用来说Rust 后端的 I/O 性能也是关键优势。为什么用 Zustand 而不是 Redux因为这个项目的状态管理需求虽然复杂多对话、多项目、图谱缓存、摄入队列但并不需要 Redux 那种重型架构。Zustand 用几行代码就能创建一个 store没有 action、reducer、middleware 的概念负担代码量少了一半。为什么 LanceDB 是可选的因为不是所有人都需要向量搜索。对于中小规模的知识库几百个页面分词搜索 图谱扩展已经够用了。向量搜索是锦上添花不是必需品——这种渐进增强的设计理念贯穿了整个项目。三、核心实现深度剖析拆解引擎盖下的精密齿轮3.1 两步思维链摄入先想清楚再动手这是整个项目最精妙的设计之一。原始的 Karpathy 方案是单步摄入LLM 一边读文档一边写 Wiki。听起来高效但实际效果不好——因为 LLM 在理解和写作之间没有切换容易写出流水账式的摘要遗漏关键实体或者忽略与已有知识的关联。LLM Wiki 把它拆成了两步第一步分析LLM 阅读源文档 → 产出结构化分析 ├── 关键实体、概念、论点 ├── 与现有 Wiki 内容的关联 ├── 与已有知识的矛盾和张力 └── Wiki 结构建议 第二步生成LLM 基于分析结果 → 生成 Wiki 文件 ├── 带 frontmatter 的资料摘要页 ├── 实体页面、概念页面 交叉引用 ├── 更新 index.md、log.md、overview.md ├── 标记需要人工判断的审核项 └── 预生成深度研究的搜索查询这就像写论文先做文献综述和分析第一步再动笔写正文第二步。先想清楚要写什么再写质量自然比边想边写高得多。在代码层面摄入流程的核心在src/lib/ingest.ts中。这个文件是整个项目最复杂的模块之一处理了从文件读取、内容清洗、图片提取、LLM 调用、页面合并到缓存管理的完整链路。一个容易被忽略但非常关键的细节是SHA256 增量缓存。每次摄入前系统会先计算源文件内容的哈希值如果和上次一样就直接跳过async function sha256(content: string): Promisestring { const encoder new TextEncoder() const data encoder.encode(content) const hashBuffer await crypto.subtle.digest(SHA-256, data) const hashArray Array.from(new Uint8Array(hashBuffer)) return hashArray.map((b) b.toString(16).padStart(2, 0)).join() }这看起来是个小优化但实际使用中能省下大量 LLM token 和时间。想象一下你有 200 篇论文的知识库重新打开应用时不带缓存的话200 篇全部重新摄入按每篇 0.5 美元的 API 成本算就是 100 美元。有了缓存只有真正变化的文件才会被重新处理。缓存还有一层防护检查缓存记录的所有写入文件是否仍然存在于磁盘。如果有文件被手动删除了缓存就会被判定为过期触发完整重新摄入。这个细节避免了幽灵条目的问题——点击一个不存在的页面链接比没有缓存更让人崩溃。3.2 四信号知识图谱不只是连点成线大多数知识图谱工具只做一件事把有链接的页面连起来。LLM Wiki 不满足于此它构建了一个四维关联度模型。在src/lib/graph-relevance.ts中四个信号的权重定义如下const WEIGHTS { directLink: 3.0, // 直接链接 sourceOverlap: 4.0, // 来源重叠 commonNeighbor: 1.5, // Adamic-Adar 共同邻居 typeAffinity: 1.0, // 类型亲和 } as const逐个拆解信号一直接链接权重 3.0——最直观的。页面 A 用[[页面B]]链接到了页面 B它俩就有关系。双向链接各算一次。信号二来源重叠权重 4.0——这个权重最高有意思。如果两个页面都引用了同一份原始文档通过 frontmatter 中的sources: []字段说明它们来自同一个知识源头。这比人为添加的链接更有意义——它反映了知识的客观来源关系而不是作者主观的关联意图。信号三Adamic-Adar权重 1.5——这是一个经典的图论指标。如果页面 A 和页面 B 有很多共同邻居都链接到了同一批页面但它们之间没有直接链接那它们很可能在讨论相关的话题。Adamic-Adar 的精妙之处在于共同邻居的信息量与其度数成反比。一个连了 100 个页面的超级节点比如 AI作为共同邻居贡献很小一个只连了 3 个页面的特定节点比如 Transformer 架构作为共同邻居贡献很大。代码实现里这一步的计算是for (const neighborId of neighborsA) { if (neighborsB.has(neighborId)) { const neighbor graph.nodes.get(neighborId) if (neighbor) { const degree getNodeDegree(neighbor) adamicAdar 1 / Math.log(Math.max(degree, 2)) } } }1 / Math.log(degree)就是 Adamic-Adar 的核心公式——度数越高的邻居贡献越小。信号四类型亲和权重 1.0——实体和实体之间更可能有意义的关系概念和概念之间也是。但实体和查询页面之间的关系就比较弱了。项目定义了一个亲和度矩阵const TYPE_AFFINITY: Recordstring, Recordstring, number { entity: { concept: 1.2, entity: 0.8, source: 1.0, synthesis: 1.0, query: 0.8 }, concept: { entity: 1.2, concept: 0.8, source: 1.0, synthesis: 1.2, query: 1.0 }, // ... }这四个信号加权求和就得到了任意两个页面之间的关联度分数。这个分数不仅用于图谱可视化边的粗细和颜色还用于查询时的图谱扩展——找到和搜索结果相关的更多页面。3.3 多阶段检索管线从关键词到语义到图谱当你在聊天框输入一个问题时背后发生的事情远比搜索关键词复杂。LLM Wiki 的检索管线分为四个阶段阶段一分词搜索对英文做分词 停用词过滤。对中文用 CJK 二元组分词——把每个拆成[每个, 个…]虽然简单但 surprisingly effective。标题匹配还会额外加 10 分。搜索同时覆盖wiki/和raw/sources/两个目录。阶段 1.5向量语义搜索可选如果用户开启了向量搜索默认关闭系统会调用任意 OpenAI 兼容的/v1/embeddings端点生成页面 embedding存储在 LanceDB 中。余弦相似度能发现即使没有关键词重叠也语义相关的页面。向量搜索的结果会和分词搜索结果合并已有的匹配获得分数提升新发现的结果被加入候选池。基准测试显示开启向量搜索后整体召回率从 58.2% 提升到 71.4%——13 个百分点的提升对于找得到和找不到的差别来说非常可观。阶段二图谱扩展把搜索结果作为种子节点用前面讲的四信号关联度模型做 2 跳遍历发现更深层关联的页面。带衰减因子越远的页面权重越低。这一步是 LLM Wiki 区别于传统 RAG 的关键——它不只在文档中搜索还在知识网络中顺藤摸瓜。阶段三预算控制这一步解决一个很现实的问题LLM 的上下文窗口是有限的。你不能把 500 个页面全塞进去。src/lib/context-budget.ts实现了一个精密的预算分配器┌─────────────────────────────────────────────────────┐ │ maxCtx (100%) │ ├──────┬───────────────┬──────────────────┬───────────┤ │ idx │ pages │ history sys │ resp │ │ 5% │ 50% │ ~30% │ 15% │ └──────┴───────────────┴──────────────────┴───────────┘索引预算 5%够列出所有页面标题页面内容预算 50%聊天历史和系统提示约 30%响应预留 15%。页面按搜索 图谱关联度的综合分数排序优先塞高分页面直到预算用完。这个设计有一个很巧妙的点单页截断上限会随总预算缩放。以前是硬编码 30000 字符不管你的上下文窗口是 4K 还是 1M。现在一个 1M 窗口的模型单页可以放到更多内容不会浪费预算。阶段四上下文组装把选中的页面编号、附上完整内容不是摘要加上 purpose.md、语言规则、引用格式说明、index.md组装成最终的系统提示。LLM 被要求按编号引用页面[1]、[2]这样你能知道答案的依据来自哪个页面。3.4 多 LLM 提供商支持一个接口千军万马LLM Wiki 支持的 LLM 提供商列表读起来像一份 AI 军备竞赛的参展名单OpenAI、Anthropic、Google Gemini、Ollama、DeepSeek、Qwen、Kimi、MiniMax、智谱 GLM、小米 MiMo……还有自定义选项只要兼容 OpenAI API 格式的端点都能接。实现这套兼容层的核心在src/lib/llm-providers.ts。设计思路很优雅——定义一个ProviderConfig接口每个提供商提供三个东西interface ProviderConfig { url: string // 请求地址 headers: Recordstring, string // 请求头 buildBody: (messages, overrides?) unknown // 构建请求体 parseStream: (line: string) string | null // 解析流式响应 }不同提供商的 API 差异很大。OpenAI 把采样参数放在顶层Gemini 要嵌套在generationConfig里还要改名top_p→topPmax_tokens→maxOutputTokens。Anthropic 的 system prompt 不在 messages 数组里而是单独的字段还支持cache_control做缓存。图片的格式更是五花八门OpenAI 用image_url.urlAnthropic 分出source.media_typeGemini 用inline_data。代码里有一段注释特别能说明问题——关于为什么本地 LLM 端点Ollama 等需要特殊处理 Origin 头export function localLlmOriginHeader(): Recordstring, string { return { Origin: http://localhost } }Tauri 的 WebView 会自动注入自己的 originmacOS 上是tauri://localhostWindows 上是http://tauri.localhost。Ollama 的 CORS 白名单接受tauri://*但不接受http://tauri.localhost——于是 Windows 用户会碰到 403。解决方案是强制设置Origin: http://localhost这个值在 Ollama 的默认白名单里。这种跨平台 CORS 的坑不踩过根本想不到。流式响应的解析也各有千秋。Gemini 2.5/3.x 的推理模型会在一个事件里交替输出thought: true思维链和正常文本的 parts旧代码只取parts[0].text后面的内容全丢了。修复方案是遍历所有 parts跳过标记为 thought 的拼接其余文本。这些细节看起来琐碎但正是它们决定了能不能用和好不好用之间的差距。3.5 Rust 后端脏活累活我来扛前端负责交互和展示真正的体力活——文件解析、格式转换、文件监听、HTTP 服务——全在 Rust 后端。多格式文档解析是最典型的脏活。src-tauri/src/commands/fs.rs中的read_file函数是一个分发器根据文件扩展名选择不同的解析路径PDF用 pdfium FFI 提取文本和图片结果缓存在.cache/目录DOCXdocx-rs 解析保留标题、加粗斜体、列表、表格结构转成 MarkdownPPTXZIP 解压 XML 解析逐页提取标题和列表XLSX/XLS/ODScalamine 库正确处理单元格类型、多工作表输出 Markdown 表格这里有一个非常重要的设计决策所有解析操作都通过spawn_blocking在 tokio 的阻塞线程池中执行。注释里解释了原因——PDF 和 Office 文档的解析涉及 FFI 调用和大量同步 I/O可能耗时 10 秒以上。如果在 async 函数体里直接跑会阻塞 tokio worker 线程饿死同线程上的其他异步任务比如导入进度 UI 的重渲染。spawn_blocking把工作移到专门的阻塞线程池这是 Tokio 的标准实践但很多 Tauri 项目都会忽略。文件监听是另一个精巧的 Rust 实现。src-tauri/src/commands/file_sync.rs使用notifycrate跨平台文件系统监听实现了 Source 文件夹的自动监听。当你在应用外部往raw/sources/文件夹里拖文件时应用会自动检测并触发摄入流程。监听器的设计考虑了很多边界情况用 MD5 哈希做文件变更检测不只是看 mtime有重试机制最多 3 次有应用自身写入忽略机制应用自己写文件时不会触发重复摄入4 秒窗口甚至在 Linux 上有定期全量重扫的兜底逻辑因为 Linux 的 inotify 在某些场景下可能丢事件。本地 HTTP API是 Rust 后端的重头戏。src-tauri/src/api_server.rs使用tiny_httpcrate 在127.0.0.1:19828启动一个 JSON API 服务器支持以下端点GET /api/v1/health — 服务状态无需鉴权 GET /api/v1/projects — 项目列表 GET /api/v1/projects/{id}/files — 文件树 GET /api/v1/projects/{id}/files/content — 读取文件内容 GET /api/v1/projects/{id}/reviews — 审核项列表 POST /api/v1/projects/{id}/search — 混合检索 GET /api/v1/projects/{id}/graph — 知识图谱 POST /api/v1/projects/{id}/sources/rescan — 触发重新扫描这个 API 服务器的设计体现了几个安全意识第一只绑定 127.0.0.1不对外网暴露。外部机器无法访问你的知识库。第二Token 鉴权。可以生成 API Token也可以选择允许本机无鉴权访问方便本地脚本调用。第三路径白名单。文件读取只允许wiki/和raw/sources/等公共路径内部状态文件不暴露。第四速率限制。每秒 120 个请求的上限最多 64 个并发请求防止恶意调用打垮服务。第五panic 防护。每个请求处理器都包在catch_unwind中即使某个请求处理 panic 了也不会拖垮整个服务器。这些细节加在一起让这个本地 API 既能被外部工具方便地调用又不会成为安全漏洞。3.6 Chrome 扩展知识库的入口不止一个LLM Wiki 还有一个 Chrome 浏览器扩展让你一键剪藏网页内容到知识库。扩展用 Manifest V3 开发核心流程是注入 Mozilla 的 Readability.js 提取文章正文去掉广告、导航、侧边栏再用 Turndown.js 把 HTML 转成 Markdown支持表格然后通过本地 HTTP API端口 19827发送给桌面应用自动触发摄入。extension/popup.js里的内容提取逻辑值得一看。它先注入两个库到当前页面await chrome.scripting.executeScript({ target: { tabId: tab.id }, files: [Readability.js, Turndown.js], })然后执行提取函数用 Readability 解析文章用 Turndown 转换格式。Turndown 还自定义了表格规则——因为 HTML 表格转 Markdown 不是开箱即用的turndown.addRule(tableCell, { filter: [th, td], replacement: (content) ${content.trim()} |, }) turndown.addRule(tableRow, { filter: tr, replacement: (content) |${content}\n, })还有一个细节自动过滤小于 10x10 像素的图片通常是追踪像素避免它们污染 Markdown 输出。如果 Readability 提取失败比如页面结构太特殊还有 fallback 逻辑——直接取document.body.innerText作为兜底。这种优雅降级的思路贯穿了整个扩展的设计。3.7 MCP 服务器让 AI Agent 成为你的知识库管理员MCPModel Context Protocol是 2024 年兴起的一个标准让 AI Agent 能够以统一的方式访问外部工具和数据源。LLM Wiki 内置了一个 MCP 服务器让 Claude Code、Codex 等 AI Agent 可以直接查询你的知识库。MCP 服务器在mcp-server/src/index.ts中实现暴露了 8 个工具工具名功能llm_wiki_status检查 API 是否可达列出当前项目llm_wiki_projects列出所有已知项目llm_wiki_files列出项目文件llm_wiki_read_file读取项目中的文本文件llm_wiki_reviews列出审核项默认未处理的llm_wiki_search混合检索关键词 向量llm_wiki_graph查询知识图谱llm_wiki_rescan_sources触发源文件重新扫描设计上有一个很重要的决策MCP 服务器不直接扫描项目文件夹不复制应用的搜索和图谱逻辑。每个工具调用都是转发给本地 HTTP API 的。这意味着 MCP 客户端使用的是和应用完全相同的项目注册表、文件权限、搜索后端、图谱后端——不存在两边逻辑不一致的风险。安装也极其简单一行命令npx skills add https://github.com/nashsu/llm_wiki_skill.git --skill llm_wiki_skill安装后你可以在 Claude Code 里直接说我的知识库里关于 Transformer 是怎么说的Agent 就会调用llm_wiki_search工具搜索你的 Wiki引用页面路径方便你核对。四、实际应用场景知识库的 N 种活法4.1 学术研究读论文的新姿势想象你在做一个关于大语言模型推理能力的文献综述。传统方式下载 50 篇论文用 Zotero 管理手动写笔记手动整理成表格手动找论文之间的联系。一周后你已经忘了第一篇论文讲了什么。用 LLM Wiki把 50 篇论文 PDF 拖进去LLM 自动提取每篇的核心贡献、方法、数据集、结果生成实体页面人物、机构、数据集、概念页面Chain-of-Thought、Self-Consistency、Tree of Thoughts自动建立交叉引用。你在知识图谱里一眼就能看到哪些论文共同引用了 CoT哪些用了相同的数据集。当你问CoT 和 Self-Consistency 的关系是什么时LLM 不是去 50 篇论文里重新检索而是直接读取已经整理好的概念页面给你一个带引用的综合回答。更妙的是图谱洞察功能会告诉你惊奇连接——比如某篇数学推理的论文和某篇代码生成的论文通过某个共同概念产生了意想不到的关联这种跨领域的连接往往是创新的灵感来源。4.2 技术团队的知识沉淀技术团队最痛苦的事情之一项目文档永远过时。代码在变架构在变但 Wiki 没人更新。因为更新文档的 ROI 太低了——你花一小时更新文档没人看也没人感谢你。LLM Wiki 可以改变这个动态。把 Slack 讨论记录、会议纪要、设计文档、代码评审记录都丢进去LLM 自动维护一个持续更新的团队知识库。新来的同事不用再问这个模块为什么这么设计——他可以直接问 Wiki。审核系统在这里特别有用LLM 在摄入时发现这个设计决策和三个月前的那份文档矛盾了会标记为审核项附带预生成的搜索查询方便你追踪原因。是需求变了还是之前的决策有误4.3 个人成长给自己建一本人生百科这是 Karpathy 原始方案里提到的一个场景也是最有温度的一个。把你的日记、播客笔记、读书摘录、健康数据、心理咨询记录都存进去。LLM 会帮你建立一张关于你自己的知识网络——你的目标如何随时间演变你的情绪模式和什么因素相关你读过的书之间有什么潜在联系。purpose.md在这个场景下特别重要。它不是冷冰冰的配置文件而是这个 Wiki 的灵魂——你定义自己关心的关键问题、研究方向、演进中的论点。LLM 在每次摄入和查询时都会读取它确保知识库的生长方向和你的个人目标一致。这就像有了一个永远在线、永远耐心、记得你所有经历的数字分身秘书。4.4 竞品分析让 LLM 帮你盯着对手把竞品的产品文档、新闻稿、用户评测、财报电话会议记录都丢进去。LLM 自动提取产品特性、定价策略、用户痛点、市场定位建立竞品之间的对比页面。当竞品发布新功能时你只需要把新闻稿丢进去LLM 会自动更新相关的对比表格标记出和自家产品的差异。图谱洞察可能会告诉你竞品 A 的新功能和你三个月前放弃的方向有关——这种信息差可能就是下一个产品决策的关键输入。五、设计哲学代码背后的思考方式5.1 编译一次持续维护 vs 每次重新检索这是 LLM Wiki 和传统 RAG 最根本的区别也是整个项目的设计基石。RAG 是即时检索——每次查询都从头搜索原始文档。优点是简单缺点是没有积累。LLM Wiki 是预编译——知识在摄入时就被提取、结构化、交叉引用查询时直接使用编译好的知识网络。优点是查询质量高、知识有积累缺点是摄入成本高需要调用 LLM。这就像是解释执行和编译执行的区别。RAG 是解释器每次都从头解释源代码。LLM Wiki 是编译器先把源代码编译成机器码Wiki之后直接执行机器码。trade-off 很明显如果你只查询一次RAG 更划算。如果你会反复查询、需要跨文档综合、希望知识随时间增长——LLM Wiki 的优势就越来越大。5.2 人类策展LLM 维护的角色分工Karpathy 的原始方案里有一句话特别精辟Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.翻译过来就是Obsidian 是 IDELLM 是程序员Wiki 是代码库。人类的角色是什么策展人。你决定读什么、关注什么、问什么问题。LLM 的角色是什么维护者。它做所有的脏活累活——总结、交叉引用、归档、记账。这个分工之所以有效是因为它顺应了人类和 LLM 各自的优势。人类擅长判断什么重要、提出好问题、理解上下文。LLM 擅长处理大量文本、保持一致性、不知疲倦地做重复性工作。维护知识库之所以难不是因为读和想难而是因为记账难——更新交叉引用、保持摘要最新、标记矛盾。人类放弃 Wiki 是因为维护成本增长得比价值快。LLM 不会感到无聊不会忘记更新一个交叉引用可以一次性修改 15 个文件。Wiki 保持维护因为维护成本趋近于零。5.3 渐进增强从简单到复杂的平滑路径LLM Wiki 的一个重要设计原则是渐进增强——核心功能开箱即用高级功能按需开启。不配置向量搜索分词搜索 图谱扩展已经能用。不安装 Chrome 扩展直接拖文件导入也行。不开启 MCP应用本身功能完整。不配置 Deep Research普通聊天和摄入照常工作。这种设计降低了入门门槛。你不需要一开始就理解所有功能先跑起来再说。随着使用深入再逐步开启高级功能。5.4 跨平台不是口号是细节的堆砌跨平台兼容性是 LLM Wiki 做得特别扎实的地方。不是嘴上说我们支持三大平台而是在代码里处理了大量平台差异。路径规范化统一的normalizePath()函数在 22 个文件中使用把 Windows 的反斜杠统一成正斜杠。这看起来是小事但如果不做Windows 上的路径在 JSON 里需要转义在正则里需要转义在 URL 里需要转义——到处都是坑。Unicode 安全中文文件名按字符切片而不是按字节切片。按字节切片会在多字节字符中间截断导致崩溃。这种 bug 在纯英文环境下永远不会出现但在中文环境下是定时炸弹。关闭行为差异macOS 上关闭按钮是隐藏窗口应用后台运行点 Dock 图标恢复Windows/Linux 上是弹出确认对话框。这符合各平台的用户习惯——macOS 用户习惯关了就是藏起来Windows 用户习惯关了就是退出。六、未来趋势知识管理的下一个十年6.1 从个人 Wiki到组织知识中枢LLM Wiki 目前定位是个人知识库但它的架构天然适合扩展到团队场景。想象一下团队的每个成员都有自己的 LLM Wiki 实例摄入各自的文档和笔记。通过某种同步机制比如 Git这些 Wiki 可以合并成一个组织级的知识网络。LLM 负责发现跨个人的知识关联——小王上周的会议纪要和小李三个月前的设计文档讨论了同一个问题。MCP 协议的标准化让这种跨 Agent 的知识共享变得更加自然。不同人的知识库可以成为不同 Agent 的工具Agent 之间可以互相查询对方的 Wiki。6.2 多模态知识库的深化目前 LLM Wiki 已经支持图片摄入——从 PDF 中提取内嵌图片用视觉 LLM 生成描述。但这只是多模态的起步。未来的方向包括视频内容的自动转录和关键帧提取、音频的说话人分离和主题建模、代码仓库的结构化解析不只是读 README而是理解代码架构。当知识库不再局限于文本文档它就真正成为了全息记忆。6.3 主动学习与知识发现当前的 LLM Wiki 是被动的——你喂什么它吃什么。未来的方向是主动学习。图谱洞察功能已经迈出了一步它主动发现知识空白孤立页面、稀疏社区并建议你去做 Deep Research。未来可以更进一步LLM 基于现有知识网络主动推荐你应该读什么论文、关注什么新闻、追踪什么趋势。这就像从图书管理员进化成了研究助理——不仅帮你整理已有的知识还告诉你还缺什么知识。6.4 知识的时效性管理知识会过时。今天正确的结论明天可能就被新研究推翻了。当前 LLM Wiki 的 Lint 功能可以发现矛盾但时效性管理还可以更精细。未来可能引入知识置信度和时效标签——每个知识点标注来源日期、引用次数、是否有矛盾证据。当新信息摄入时系统自动评估对已有知识的影响生成知识更新报告。6.5 与 Agent 生态的深度融合MCP 协议的出现让 AI Agent 生态迎来了爆发。LLM Wiki 作为一个本地知识库服务天然适合成为 Agent 的长期记忆。未来的 Agent 不再是无状态的——它们可以持久地访问你的知识库在对话中积累上下文跨会话保持一致性。LLM Wiki 的本地 HTTP API 和 MCP 服务器就是为这种融合准备的基础设施。想象一下你的 AI 编程助手不仅知道你当前项目的代码还知道你三个月前读过的架构论文、上周的会议决策、你个人的编码偏好——所有这些都在你的 LLM Wiki 里Agent 通过 MCP 随时查询。七、上手实践五分钟跑起来7.1 安装最简单的方式是下载预编译版本macOS.dmg支持 Apple Silicon 和 IntelWindows.msiLinux.deb或.AppImage如果你是开发者也可以从源码构建git clone https://github.com/nashsu/llm_wiki.git cd llm_wiki npm install npm run tauri dev # 开发模式 npm run tauri build # 生产构建前置条件Node.js 20 和 Rust 1.70。7.2 配置启动应用创建新项目选择一个场景模板研究、阅读、个人成长、商业、通用进入设置配置 LLM 提供商——填入 API Key 和模型名称可选配置网络搜索提供商Tavily、SerpApi 或 SearXNG用于 Deep Research可选开启向量搜索配置 embedding 端点7.3 开始使用进入资料源导入文档支持 PDF、DOCX、PPTX、XLSX、Markdown、图片等观察活动面板——LLM 自动构建 Wiki 页面逐文件显示进度用聊天查询你的知识库浏览知识图谱查看页面之间的关联查看审核处理需要你关注的项目定期运行Lint维护 Wiki 健康度7.4 进阶接入 AI Agent如果你想让 Claude Code 或 Codex 直接查询你的知识库在设置中开启 API MCP构建 MCP 服务器npm run mcp:build安装 Agent Skillnpx skills add https://github.com/nashsu/llm_wiki_skill.git --skill llm_wiki_skill在 Agent 中直接提问我的知识库里关于 X 是怎么说的八、写在最后当知识管理遇见 LLM回顾整个项目我最感慨的是它对知识管理这件事的重新定义。过去几十年知识管理工具的演进方向是让人更方便地管理知识——更好的编辑器、更强的搜索、更漂亮的界面。但 LLM Wiki 指出了另一条路让 LLM 来管理知识让人专注于思考和决策。这不是工具的升级是范式的转变。从 Vannevar Bush 1945 年提出 Memex 的构想到如今 LLM 让这个构想真正可行中间隔了 80 年。Bush 当年无法解决的问题是谁来维护那些关联线索——现在 LLM 给出了答案。LLM Wiki 项目的价值不在于它用了多么前沿的技术虽然技术确实很硬核而在于它把一个深刻的洞察——知识应该编译一次并持续维护而不是每次重新推导——变成了一个普通人可以下载安装、开箱即用的桌面应用。它不完美。摄入大量文档时的 API 成本不低图谱可视化在页面数量过千时会有性能压力多 LLM 提供商的兼容性维护是个无底洞。但它的方向是对的实现是扎实的而且——也许是最重要的——它让维护一个知识库这件事从反人类变成了令人愉悦。下次你再看到一篇好文章想收藏的时候也许可以换个思路不是收藏了以后再看而是丢进 LLM Wiki让它成为你知识网络的一部分。以后不用再看直接问就好了。毕竟知识的价值不在于拥有而在于连接。而 LLM Wiki就是那个帮你织网的人。项目地址GitHub - nashsu/llm_wiki: LLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。 · GitHub许可证GPL v3.0更多AIGC文章RAG技术全解从原理到实战的简明指南更多VibeCoding文章