Trending 排名：#8｜快照日期：2026-09-12｜Stars：18,739｜今日新增：647｜Forks：2,134｜主语言：TypeScript｜License：GPL-3.0
把文档丢给 RAG，确实能问出答案；但下一次提问，系统往往还要重新检索、重新拼上下文、重新推导。LLM Wiki 走了另一条路：让模型先把资料“编译”为有目录、有来源、有交叉链接的 Markdown Wiki，之后查询面对的是一份持续演进的知识资产，而不是一袋每次临时召回的碎片。
这个差异听起来只像产品包装，源码里却对应着一整套工程约束：原始资料保持不可变，Wiki 页面带 sources[] 追踪来源；摄入拆成分析与生成两次调用；SHA-256 缓存和持久队列避免重复烧 token；检索把关键词、向量和图谱扩展串起来；桌面端再通过本地 HTTP API 与 MCP 把知识库开放给 Claude Code、Codex 等 Agent。
它也不是“RAG 已经过时”的证明。两条路线解决的问题不同：RAG 更适合频繁变化、按需读取的大语料；持久 Wiki 更适合需要人工审阅、长期积累和可编辑结构的个人知识。LLM Wiki 的代价是摄入更慢、更新会产生写放大，而且 LLM 写出的页面仍需审核。
📋 项目概览
| 项目 | 内容 |
|---|---|
| 项目名 | nashsu/llm_wiki |
| 一句话 | 将文档增量编译为可追溯、可编辑、Obsidian 兼容的持久知识库 |
| GitHub | github.com/nashsu/llm_… |
| 历史快照 | 2026-09-12 Trending #8，18,739 Stars、2,134 Forks、今日 +647 |
| 后续 API 核验 | 2026-09-14 10:35 CST：19,355 Stars、2,192 Forks |
| 语言 | TypeScript 为主，Rust 后端；另含 JavaScript/Python/CSS |
| License | GPL-3.0；GitHub API 当时未正确识别，但仓库 LICENSE 明确是 GNU GPL v3 |
| 当前版本 | v0.6.11，发布于 2026-08-25 |
| 默认分支 | main |
| 审计提交 | e8082119649e6a8e1cf85eaf289adcabfdf39d4e |
🔥 为什么值得关注
传统 RAG 的主要产物是“一次回答”。检索到的片段如何组织、不同来源怎样合并、旧结论要不要更新，通常被留给下一轮 prompt。LLM Wiki 把主要产物改成文件：wiki/entities/、wiki/concepts/、wiki/synthesis/ 等目录里的 Markdown 页面，以及 index.md、overview.md、log.md 这些能被人和 Agent 共同读取的控制面。
这让知识第一次生成时更贵，却换来三个长期收益：结果可版本化，来源可追溯，结构可人工修订。尤其对个人研究、项目交接、读书笔记和代码库知识来说，“模型已经得出过什么结论”不再只藏在聊天历史或向量库里。
项目的难点不在三栏 UI，而在维持一致性。导入一个来源可能同时修改摘要页、实体页、概念页、索引、全局概览和日志；失败时不能留下一半新、一半旧的 Wiki。源码因此有摄入提交协调器、持久队列、文件监听、缓存迁移、冲突清理和大量场景测试。这也是它比“把几段 prompt 包进桌面壳”更值得读的原因。
🏗️ 核心特性
1. 三层文件系统把知识所有权留给用户
项目沿用 Karpathy LLM Wiki 方法里的三层结构：不可变资料、模型维护的 Wiki、约束结构的 Schema，同时增加 purpose.md 表达“为什么建这份库”。
my-wiki/
├── purpose.md # 研究目标、关键问题与范围
├── schema.md # 页面类型、目录和生成规则
├── raw/
│ ├── sources/ # 原始文档，摄入后仍保留
│ └── assets/ # 提取图片等资产
├── wiki/
│ ├── index.md # 内容目录与 Agent 导航入口
│ ├── overview.md # 全局摘要
│ ├── log.md # 可解析的操作历史
│ ├── entities/
│ ├── concepts/
│ ├── sources/
│ ├── synthesis/
│ └── comparisons/
└── .llm-wiki/ # 队列、配置、聊天与审核状态
Wiki 页面使用 YAML frontmatter 的 sources: [] 指回原始文件，正文用 [[wikilink]] 建立关系。结果仍是普通 Markdown，整个目录也能作为 Obsidian Vault 打开，不依赖专有数据库才能读取。
2. 摄入不是一次总结，而是两阶段写入
src/lib/ingest.ts 是前端侧最大的运行时文件之一，负责把解析、模型调用、页面计划、写入和后处理连起来。README 对两次调用的分工描述得很清楚：
源文件
-> 解析文本、图片与元数据
-> 第一次 LLM：分析实体、概念、矛盾、已有 Wiki 关系
-> 形成结构化分析结果
-> 第二次 LLM：生成或更新具体 Wiki 文件
-> 提交 index / overview / log / 页面
-> 更新缓存、Embedding 与审核队列
第一步不急着写页面，先识别“应该写什么”；第二步再基于已有目录和分析结果生成文件。这会多付一次调用成本，但能把内容理解与文件操作拆开，减少模型一边推理一边随意改结构的问题。
src/lib/ingest-cache.ts 使用内容哈希跳过未变化来源；src/lib/ingest-queue.ts 负责串行队列、重试和重启恢复；src/lib/ingest-commit-coordinator.ts 集中协调一次摄入产生的多文件提交。对应测试覆盖队列恢复、路径碰撞、sanitize、prompt、推理结果解析和提交冲突。
3. 检索是关键词、向量与图谱三段式
项目没有因为生成了 Wiki 就放弃检索。src/lib/search.ts 先做词法搜索，英文过滤停用词，中文使用 CJK 二元组，标题匹配额外加权；可选向量检索通过 OpenAI 兼容 Embedding API 生成向量，Rust 端用 LanceDB 保存；随后以命中页面为种子做图谱扩展。
query
├─ 词法通道：wiki + raw/sources，标题加权
├─ 向量通道：Embedding -> LanceDB ANN
└─ 融合结果
-> 图谱 2 跳扩展
-> 按相关度衰减
-> 组织最终上下文与引用
图谱相关度不是只数双链。README 给出的四个信号是：直接链接 ×3、共同来源 ×4、Adamic-Adar ×1.5、页面类型亲和 ×1。src/lib/graph-relevance.ts、wiki-graph-analysis.ts 和 graph-insights.ts 分别处理相关度、社区与洞察。UI 使用 graphology、Louvain 与 ForceAtlas2 展示社区、桥接节点和稀疏区域。
4. Tauri/Rust 后端承担能力边界
React/TypeScript 负责知识工作流与界面，Rust 后端承担本地文件、向量存储、HTTP 服务和 Agent 运行时。关键实现包括：
| 模块 | 职责 |
|---|---|
src-tauri/src/commands/fs.rs | 项目文件读写、路径和权限边界 |
src-tauri/src/commands/search.rs | 本地检索命令 |
src-tauri/src/commands/vectorstore.rs | LanceDB 向量索引 |
src-tauri/src/api_server.rs | 本地 JSON API |
src-tauri/src/agent/runtime.rs | 聊天 Agent 的工具循环与流式事件 |
src-tauri/src/agent/tools.rs | Wiki、Source、Graph、Web、workspace、shell 等工具 |
src-tauri/src/agent/provider.rs | 模型 Provider 适配 |
本地 API 默认使用 127.0.0.1:19828。源码还区分 loopback 与 LAN：局域网客户端要携带同一个 API token，避免公开项目路径和写入接口。shell 工具带审批而不是默认静默执行，这一点对“知识库 + Agent”组合尤其重要。
5. MCP 把桌面知识库变成 Agent 工具
仓库的 mcp-server/ 是独立 Node 包。它不复制知识库，而是把 MCP 调用转换为本地 API 请求，暴露项目、搜索、页面、图谱、审核和聊天等能力。这样桌面程序保持数据与索引的单一事实源，外部 Agent 只拿到受控接口。
本次实际运行 npm run mcp:test：先完成 TypeScript 构建，再执行 Node TAP 测试，结果 22 pass、0 fail。覆盖 bearer token、search 请求体、跨项目 pin、防止越界 override、API 错误转换和版本读取。
🔬 技术架构深度解析
从原始资料到可持续知识
PDF / Office / EPUB / 网页 / 音视频 / 文件夹
│
▼
解析与多模态提取
pdfjs / Office parser / OCR / vision
│
▼
持久摄入队列
hash 去重 -> 串行 -> 重试 -> 恢复
│
▼
两阶段 LLM
分析已有知识 -> 规划页面 -> 生成补丁
│
▼
多文件原子式提交
source summary / entity / concept
index / overview / log / review
│
├── Markdown + YAML + wikilink
├── LanceDB embedding
└── 图谱、社区与知识空白
这里最值得借鉴的是“模型输出不是最终答案，而是受 Schema 约束的增量补丁”。purpose.md 提供任务方向，schema.md 提供结构规则，已有 Wiki 提供当前状态，原始资料提供证据。模型的自由度被夹在四层上下文之间。
一致性和写放大
持久知识的代价是一次摄入可能触及多个文件。假设一份资料贡献了两个实体、一个概念和一个跨来源结论，那么系统至少可能写摘要页、三类知识页、目录、概览和日志。相比把一个 chunk 写进向量库，它有明显写放大。
项目用三种办法控制风险：
- 内容哈希避免相同资料重复摄入；
- 队列串行化，避免两个任务同时重写
index.md； - 提交协调器将多文件变更按一个摄入事务管理。
但它仍不等于数据库事务。用户在应用外直接编辑文件、同步盘制造冲突、模型生成不合法 frontmatter，都需要清理与恢复逻辑。选择这套架构时，应该把“人类可编辑”视为收益，也视为并发输入源。
源码规模
我用 git ls-files -z 获取 tracked 清单，再由 Python 逐文件统计，避免 shell 分词和输出截断：
| 指标 | 数值 |
|---|---|
| tracked files | 465 |
| 生产代码/配置/文档类文件 | 289 个，116,598 物理行 |
| 测试文件 | 145 个，33,201 物理行 |
| TypeScript | 293 文件，67,696 行 |
| TSX | 61 文件，23,144 行 |
| Rust | 41 文件，33,853 行 |
src/lib | 231 文件，57,188 行 |
src-tauri/src | 40 文件，33,847 行 |
mcp-server | 11 文件，2,765 行 |
最大运行时文件是 src-tauri/src/agent/runtime.rs（5,775 行），其次是 agent/tools.rs（3,722 行）、src/lib/ingest.ts（3,529 行）和 api_server.rs（3,472 行）。这说明复杂度已经集中到 Agent 运行时、工具面与摄入主链，后续维护最需要继续拆边界。
本地验证
审计提交上执行了以下确定性验证：
npm ci
npm run typecheck
npm run test:mocks
npm --prefix mcp-server ci
npm run mcp:test
npm run build
结果：
npm ci安装 820 个 package 成功；npm audit 同时报出 21 个依赖漏洞（3 low、8 moderate、10 high），这是需要升级或逐项确认的供应链风险；- TypeScript typecheck 退出码 0；
- mock 测试 132 个文件、1,876 个测试全部通过；
- MCP 测试 22 pass、0 fail；
- Vite 生产构建完成，转换 4,242 个模块；
- 构建警告指出主 JS chunk 约 1.34 MB，并有几个动态导入同时被静态引用，代码分割尚有优化空间；
- 没有运行
test:llm，因为它调用真实模型，结果会依赖外部凭据、Provider 与网络，不能当成确定性验证。
📖 README 核心内容摘要
README 的核心判断是：知识应该“编译一次并持续维护”，而不是每次查询都重新推导。它保留 Karpathy 方法里的 Ingest、Query、Lint 三个操作，再扩展成完整桌面产品。
支持的输入覆盖 PDF、Office、EPUB/MOBI、Org mode、图片、音视频、网页剪藏、URL 与文件夹。PDF 可以使用内置解析，也可接云端或本地 MinerU；图片可交给视觉模型生成事实描述。能力很全，但不同格式最终质量仍取决于解析器和模型，特别是扫描 PDF、复杂表格与音视频不能因为“支持导入”就默认高保真。
模型配置允许 Chat 与 Ingest 分开路由，并支持自定义 OpenAI 兼容 Provider、请求头和流式输出。这个设计很实用：摄入需要长上下文和结构化生成，聊天更在意延迟与成本，不必强迫两条链使用同一模型。
🚀 快速上手
对普通用户，最简单的方式是从 Release 下载 v0.6.11 桌面包。若要审计或二次开发：
git clone https://github.com/nashsu/llm_wiki.git
cd llm_wiki
npm ci
npm run dev
先创建项目并配置 purpose.md、schema.md，再导入资料。建议从一个主题清晰的小目录开始，不要第一次就把整个硬盘扔进去；先检查页面类型、来源路径与语言是否符合预期，再扩大规模。
如需让 Agent 访问，启动桌面应用提供的本地 API，然后构建 MCP server：
npm --prefix mcp-server ci
npm run mcp:build
公开到局域网前要配置 API token，并确认防火墙、项目目录权限和 shell 审批策略。默认 loopback 是更稳妥的部署边界。
📊 增长速度与社区热度
Star 增长
2026-09-12 公开历史快照记录 18,739 Stars、今日 +647，新增量约占快照总量的 3.45%。两天后的 GitHub API 核验为 19,355 Stars，比历史快照高 616；这个差值跨越了不同采样时刻，不能反推为某一天的“今日新增”。
快照 Forks 为 2,134，约为 Stars 的 11.39%。9 月 14 日 API 核验为 2,192。当前仓库有 176 个 open issues、87 个 open PRs；热度带来了反馈，也形成了不小的维护队列。
贡献者 API 前十中，维护者 nashsu 有 731 次贡献，之后是 22、20、9 次等，贡献集中度较高。项目当前可用，但关键架构与发布节奏仍明显依赖主维护者。
2026-09-12 GitHub Trending 完整榜单
本机当天的定时任务在抓取前因脚本导入错误失败，没有留下可用榜单。下表采用 SegmentFault 在目标日期发布的历史快照，共保留 16 项；排名、总 Stars、Forks 与“今日新增”都只按该页面记录，不用 9 月 13 日或 9 月 14 日数据回填。原页面后六项未展示 Forks，因此保留为“—”。
| Rank | Repository | Language | Stars | Forks | 今日新增 Stars |
|---|---|---|---|---|---|
| 1 | ayghri/i-have-adhd | Python | 41,838 | 2,367 | 3,463 |
| 2 | bilawalsidhu/gods-eye-view | JavaScript | 27,120 | 5,553 | 3,680 |
| 3 | nab138/iloader | TypeScript | 2,908 | 203 | 50 |
| 4 | melgarafael/DeskcommCRM | TypeScript | 1,346 | 496 | 152 |
| 5 | vastsa/PI-Desktop | TypeScript | 2,778 | 217 | 552 |
| 6 | armory3d/armorpaint | C | 4,721 | 533 | 350 |
| 7 | alsk1992/CloddsBot | TypeScript | 2,153 | 282 | 626 |
| 8 | nashsu/llm_wiki | TypeScript | 18,739 | 2,134 | 647 |
| 9 | obra/superpowers | Shell | 285,380 | 25,521 | 729 |
| 10 | Sonarr/Sonarr | C# | 15,736 | 1,949 | 191 |
| 11 | jihe520/MathModelAgent | Python | 4,858 | — | 129 |
| 12 | p1neappleXpress/OpenFlux | Go | 1,148 | — | 198 |
| 13 | jordan-gibbs/hyperresearch | Python | 2,615 | — | 153 |
| 14 | alphaXiv/OpenResearch | Rust | 1,277 | — | 120 |
| 15 | github/spec-kit | Python | 135,770 | — | 1,015 |
| 16 | pascalorg/editor | TypeScript | 23,602 | — | 106 |
数据来源：
- 目标日历史快照：segmentfault.com/a/119000004…
- 仓库与源码：github.com/nashsu/llm_…
- 后续 API 核验：api.github.com/repos/nashs…
- Release：github.com/nashsu/llm_…
🎯 适用场景
| 场景 | 适合程度 | 原因 |
|---|---|---|
| 个人研究与读书知识库 | 高 | Markdown、来源追踪、Obsidian 兼容，适合长期整理 |
| 多轮项目调研与交接 | 高 | 结论写回 Wiki，后续 Agent 不必从零恢复背景 |
| 私有文档的本地管理 | 中到高 | 数据目录在本机，但模型与搜索 Provider 可能把内容发往外部 |
| 高频变化的大型企业语料 | 中 | 持久页面的写放大和冲突治理比纯检索更重 |
| 强审计、零幻觉知识库 | 低到中 | 有来源字段不等于每句话都自动逐句引用，仍需审核 |
| 临时问一个 PDF | 低 | 直接 RAG 或长上下文通常更快，没必要先建完整 Wiki |
| Agent 的长期项目记忆 | 高 | 本地 API、MCP、Skill 与普通文件系统都便于接入 |
💡 总结
LLM Wiki 真正有价值的不是“再做一个知识库”，而是把 LLM 产生的中间知识从聊天缓存提升为一等资产：有文件、有目录、有来源、有关系，也允许人直接修改。它用两阶段摄入、持久队列和提交协调器，为这种资产化付出了工程成本。
如果资料只是临时问答，传统 RAG 更省事；如果知识需要积累数月、反复修订并交给多个 Agent 使用，持久 Wiki 会逐渐显出复利。部署时要重点检查真实模型调用的数据边界、GPL-3.0 义务、依赖漏洞、主维护者集中度，以及摄入生成内容的人工审核流程。
