核心用法
llm-wiki 是 Andrej Karpathy 提出的知识管理模式的实现，核心理念是"LLM 作程序员，Wiki 作代码库，用户作产品经理"。提供两种使用模式：
协议模式（推荐）：无需安装，通过自然语言指令让 Agent 直接操作
请摄入 sources/xxx.pdf 到 wiki— 提取资料关键信息生成 Wiki 页面查询 wiki: 问题内容— 基于 Wiki 内容生成带引用的回答检查 wiki 健康状况— 检测孤立页面、死链、过时内容
CLI 模式（可选）：Python 脚本辅助批量操作，需安装依赖
显著优点
1. 零部署架构：纯 Markdown 文件，无数据库、无服务、git 原生版本控制
2. Obsidian 兼容：双向链接 [[PageName]] 格式，可直接用 Obsidian 打开 wiki/ 目录
3. 累积式学习：每次查询可归档为新页面，知识持续沉淀
4. 隐私安全：数据不上云，无需 Embedding API，无外部依赖
5. 轻量极简：约 500 行代码 vs Sage-Wiki 约 1 万行
潜在局限
- 规模瓶颈：基于符号导航而非向量检索，适合 500 页以下；超量需手动维护索引或升级 Embedding
- 模糊查询弱：无法处理"关于优化的那篇论文"类语义搜索，依赖精确关键词和人工整理的 index.md
- Agent 依赖：核心功能（摄入、查询）依赖 LLM Agent 的上下文理解和执行能力，不同 Agent 效果差异大
- PDF 安全风险：依赖 pdfplumber/pdfminer.six，需严格使用安全版本（>=0.11.8 / >=20251107）避免 CVE-2025-64512 漏洞
适合人群
- 研究人员、学生：管理论文、技术博客等学习资料
- 个人知识管理用户：偏好本地优先、避免 SaaS 锁定
- Claude Code 用户：原生集成，自然语言交互
常规风险
- 无 Embedding 的精确检索依赖人工维护索引，长期可能产生知识孤岛
- 多 Agent 协作时需确保均遵循 CLAUDE.md 协议，否则可能破坏 Wiki 结构
- CLI 模式的 PDF 处理依赖存在历史漏洞的库，必须按文档要求版本安装