让 AI 帮你打理知识，而不是反过来。
基于Andrej Karpathy「LLM 友好型知识库」为基础逻辑，并增加渐进式匹配，构建面向AI的知识库，重新定义人与 AI 的知识协作方式。
中文 | English
LLM Wiki 是一个为 AI 设计的知识库管理技能（Skill）。它不是传统笔记软件里的搜索增强，而是一整套让 LLM 能够自主创建、消化、组织、维护知识的工具。
核心理念：人类只管丢入原始素材，AI 负责消化、归类、索引和长期维护。
适合谁？ 使用 AI 的开发者、研究者、知识工作者 —— 任何希望让 AI 帮忙管理持续积累的知识的人。
传统知识管理的痛点：
| 传统方式 | LLM Wiki |
|---|---|
| 🗂️ 手动分类、打标签 | 🤖 AI 自动分类、建索引 |
| 📝 手动整理笔记 | 🧹 AI 自动提炼、去重 |
| 🔍 关键词搜索，经常找不到 | 🎯 AI 语义路由，精准命中 |
| 📚 文件越来越多，越来越乱 | 📊 自动重组，永远整洁 |
| ❌ 写了就忘，从不回顾 | ✅ 健康检查，持续维护 |
不需要一开始就设计复杂的分类体系。知识库会自动进化：
扁平阶段（< 20 篇） 分类阶段（20+ 篇）
───────────────── ─────────────────
_surface.md _surface.md
├── page_a.md → ├── programming/ (12篇)
├── page_b.md │ └── _index.md
└── page_c.md ├── ai/ (8篇)
│ └── _index.md
└── reading-notes/ (6篇)
└── _index.md
- < 20 篇：保持扁平，简单直接
- 20–50 篇：AI 主动建议分类
- > 50 篇：AI 强烈建议重组
不管知识库长到多大，
_surface.md始终保持简短，LLM 一次就能定位目标。
支持三种知识来源，灵活适配你的工作流：
| 来源 | 使用方式 | 适用场景 |
|---|---|---|
| 📥 Inbox | 把文件丢进 inbox/ 文件夹 |
批量处理文章、笔记、PDF |
| 💬 对话 | 直接在对话中粘贴内容 | 随手记录想法、会议纪要 |
| 🔗 URL | 给 AI 一个链接 | 收藏网页文章、技术文档 |
你："帮我消化一下这篇文章 https://example.com/article"
AI：✅ 已提取核心知识，创建 wiki/defi_basics.md
✅ 已更新索引 _surface.md
✅ 已记录操作日志 log.md
✅ 原文已归档至 inbox/_processed/
内置 Lint 健康检查机制，一条命令全面体检：
📋 知识库健康报告
=============================
🔍 孤儿页面（未被索引收录）：
- wiki/forgotten_note.md
🔗 断裂引用：
- _surface.md → wiki/deleted_page.md (文件不存在)
📄 疑似重复：
- wiki/python_basics.md ↔ wiki/python_intro.md
⏰ 过期页面（超过90天未更新）：
- wiki/old_research.md (上次更新: 2025-12-01)
✅ 无问题: 索引一致性
每篇 Wiki 页面都保留 完整的溯源链：
---
source: https://example.com/original-article
source_file: inbox/_processed/article_20260413.md
created: 2026-04-13
updated: 2026-04-13
---- 原始文件永不删除，统一归档至
inbox/_processed/ - 支持根据原始素材重新消化
- 操作日志
log.md记录每一次变更
独创的分层索引架构，让 LLM 在海量知识中秒速定位：
扁平阶段（1 次读取即可命中）：
_surface.md → 目标页面
分类阶段（最多 2 次读取）：
_surface.md → _index.md → 目标页面
┌────────────────┐ ┌─────────────────┐ ┌──────────────┐
│ programming/ │──→ │ Python 异步编程 │ ──→ │ 完整内容... │
│ ai/ │ │ Go 并发模式 │ │ │
│ reading-notes/ │ │ ... │ │ │
└────────────────┘ └─────────────────┘ └──────────────┘
知识库越小越快，越大也不慢。_surface.md 始终保持短小，扩展成本几乎为零。
对比传统方案：
| 方案 | Token 消耗 | 可扩展性 |
|---|---|---|
| 把所有知识塞进 System Prompt | 🔴 灾难级 | ❌ |
| RAG 向量检索 | 🟡 中等 | 🟡 需要额外基础设施 |
| LLM Wiki 分层索引 | 🟢 极低 | ✅ 无限扩展，零依赖 |
涉及文件移动、重命名、合并等结构性变更时：
- ✅ AI 必须先展示方案，获得用户确认后才执行
- ✅ 原始文件永不删除，只移动到
_processed/ - ✅ 所有操作全程记录在
log.md
第 1 步 — 安装 Claude Code（如果还没有的话）
第 2 步 — 克隆到你的 Skills 目录
git clone https://github.com/ishicm/llm-wiki.git .claude/skills/llm-wiki或者手动下载，将 llm-wiki 文件夹放入项目的 .claude/skills/ 目录。
第 3 步 — 在 Claude Code 中告诉 AI：
帮我在 ./my-kb/ 创建一个知识库
完成！接下来把文件丢进 inbox/，AI 会自动消化整理。
创建知识库：
> 帮我在 ./my-kb/ 创建一个知识库
投喂知识：
> 处理一下 inbox 里的文件
> 帮我消化这篇文章 https://example.com/xxx
> 把下面这段内容整理进知识库：[粘贴内容]
健康检查：
> 检查一下知识库的健康状况
自动重组： （当文件数达到阈值时，AI 会主动建议）
试试示例知识库：
查看 example/ 目录，里面有一个开箱即用的示例知识库。Clone 后告诉 AI「处理一下 inbox 里的文件」，即可体验完整的消化流程。
my-kb/
├── README.md # 给人看的说明文档
├── _surface.md # 根索引（AI 的入口）
├── _rules.md # 操作规则（人类维护，AI 只读）
├── log.md # 追加式操作日志
├── inbox/ # 原始素材投放区
│ └── _processed/ # 已消化的原始文件归档
└── wiki/ # 知识页面（AI 维护）
├── page_a.md # 扁平阶段：直接放
└── crypto/ # 分类阶段：按主题分文件夹
├── _index.md # 子索引
└── page_b.md
| 维度 | RAG | LLM Wiki |
|---|---|---|
| 基础设施 | 需要向量数据库、Embedding 模型 | 纯 Markdown，零依赖 |
| 可读性 | 向量不可读，无法人工审查 | 人和 AI 都能直接阅读 |
| 可维护性 | 重新索引成本高 | 就地编辑，即时生效 |
| 透明度 | 检索过程是黑盒 | 索引路径完全透明 |
| 可移植性 | 绑定特定技术栈 | 随便搬，随便用 |
它们是优秀的工具 —— 如果你需要可视化编辑、团队协作、富媒体排版，它们仍然是更好的选择。
但它们是为人类使用优化的。LLM Wiki 解决的是另一个问题：让 AI 能高效消费和维护知识：
- 结构化的 frontmatter 方便 AI 解析
- 分层索引减少 token 消耗
_rules.md让 AI 自带操作手册- 标准化的文件格式让 AI 可以自主维护
两者可以共存：用 Notion 做日常笔记，用 LLM Wiki 做 AI 知识库。
"One day, I realized that LLMs basically need a Wikipedia for themselves — a structured, hierarchical knowledge store designed specifically for AI consumption rather than human browsing." — Andrej Karpathy（原始 Gist）
LLM Wiki 将这个洞察变成了一个可落地的工程实践。
- 首次创建 & 迁移已有文档
- 多源摄入（Inbox / 对话 / URL）
- 渐进式自动重组
- Lint 健康检查
- 多知识库交叉引用
- 知识库版本快照
- 与 MCP 工具链集成
- Web UI 可视化仪表盘
欢迎 PR 和 Issue！详见 CONTRIBUTING.md。
尤其欢迎以下方向的贡献：
- 新的 Lint 检查规则
- 更多摄入源适配（RSS、Email 等）
- 其他 AI 编码工具的适配（Cursor、Windsurf 等）
- 实际使用案例分享
MIT License — 自由使用，自由修改。
如果你厌倦了手动整理知识，让 AI 来。
⭐ 觉得有用就 Star 一下 ⭐