llm-wiki

llm-wiki - 持续由大模型维护的 Markdown 知识库

关键词：llm-wiki · obsidian wiki · research vault · knowledge base

当用户希望知识积累为持续维护的 Markdown 文档，而不是每次查询都从原始文件中重新发现时，请使用此技能。

llm-wiki 将 Andrej Karpathy 的 gist 转化为可执行的工作流。核心模式很简单：保持原始来源不可变，让大模型负责维护知识库层，并将维护约定写入 AGENTS.md 或 CLAUDE.md。

何时使用此技能

• 为长期知识工作初始化新的 Obsidian 或 Markdown 知识库
• 将原始文章、论文、转录稿或笔记转换为来源摘要和相互链接的知识库页面
• 在引入更重型的搜索基础设施之前，将 index.md 和 log.md 作为导航基础
• 将有价值的答案归档回知识库，而不是让它们埋没在聊天记录中
• 定期运行 lint，检查失效链接、孤立页面、过时观点和缺失的综合分析页面
• 添加可选辅助工具，例如用于 URL 摄取的 Scrapling、用于搜索的 qmd，或用于知识库自动化的 Obsidian CLI

说明

第 1 步：初始化知识库

首先创建知识库骨架：

bash scripts/bootstrap-vault.sh /path/to/vault

在 jeo 运行时中，不要自行指定新的知识库位置。知识库的作用域为项目级：工具流程规则（~/.agents/rules/jeo-tool-flow.md）和摄取钩子都会按 $LLM_WIKI_VAULT → <obsidian-mind vault>/llm-wiki 的顺序解析路径，其中 obsidian-mind 知识库的解析顺序为 $OBSIDIAN_MIND_VAULT → 当前目录的 git 顶层目录 → 不在任何 git 仓库中时的 ~/vaults/obsidian-mind。因此，每个仓库都在 <repo>/llm-wiki/ 下拥有自己的知识库。将同一路径传给 bootstrap-vault.sh，确保技能使用的知识库与钩子使用的知识库完全一致：

OM_VAULT="${OBSIDIAN_MIND_VAULT:-$(git rev-parse --show-toplevel 2>/dev/null || echo "$HOME/vaults/obsidian-mind")}"
bash scripts/bootstrap-vault.sh "${LLM_WIKI_VAULT:-$OM_VAULT/llm-wiki}"

在完整模式安装期间，setup-all-skills-prompt.md（第 5 步“知识管道钩子”）会使用完全相同的路径解析方式调用此脚本，并将 hooks/ingest-prompt.py 注册为 Claude Code、Codex 和 Gemini 的 prompt-in / turn-end 钩子；在其他仓库中首次捕获提示词时，摄取脚本会初始化尚不存在的知识库，因此全新的 jeo 设置和手动初始化始终保持一致。

初始化过程会创建：

• raw/sources/，用于存放不可变的来源 Markdown 文件或复制的文件
• raw/assets/，用于存放下载的图片和附件
• wiki/sources/，用于存放每个来源的摘要
• wiki/entities/ 和 wiki/concepts/，用于存放长期保留的综合分析页面
• wiki/queries/ 和 wiki/reports/，用于存放归档的答案和更有价值的输出
• index.md、log.md 和 AGENTS.md

不要跳过架构文件。架构文件能让 Agent 像严谨的维护者一样工作，而不是像通用助手一样处理任务。请参阅 references/architecture.md 和 references/schema-playbook.md。

第 2 步：将 AGENTS.md 或 CLAUDE.md 视为操作约定

架构应写入在不同会话中始终适用的规则：

• raw/ 是事实来源，必须保持不可变
• wiki/ 以及 index.md 和 log.md 是由大模型维护的工作文档
• 每次摄取都要更新来源摘要、相关综合分析页面、index.md 和 log.md
• 每个需要长期保留的查询答案都要归档到 wiki/queries/ 或 wiki/reports/
• lint 必须检查失效链接、孤立页面、过时观点、相互矛盾的内容，以及缺失的候选页面

架构要简短且可执行。Agent 确实会遵循的小型约定，胜过没人会重读的大型策略文件。bootstrap-vault.sh 提供的起始架构刻意保持精简；请使用 references/schema-playbook.md 对其进行完善。

第 3 步：一次摄入一个来源，直到工作流稳定

如果来源已在本地，请将其放入 raw/sources/，并让 Agent 处理。如果来源是 URL，请使用由 Scrapling 驱动的辅助工具：

bash scripts/ingest-url.sh /path/to/vault "https://example.com/article"
bash scripts/ingest-url.sh /path/to/vault "https://app.example.com/post" --mode fetch --wait-selector article
bash scripts/ingest-url.sh /path/to/vault "https://protected.example.com/post" --mode stealth --solve-cloudflare

预期的摄入涉及以下操作：

1. 将不可变的原始抓取内容保存到 raw/sources/
2. 在 wiki/sources/ 下创建或更新来源页面
3. 更新相关实体或概念页面
4. 更新 index.md
5. 按时间顺序向 log.md 追加条目

刚开始时，优先一次摄入一个来源。这样可以促使人工检查 Wiki 的变更、发现缺失的约定，并改进架构。工作流可靠后，可以批量处理。请使用 references/ingest-playbook.md 中的操作检查清单。

第 4 步：基于 Wiki 查询，而不是原始资料堆

回答问题时：

1. 首先阅读 index.md
2. 打开最相关的 Wiki 页面
3. 仅在 Wiki 需要依据或解决冲突时深入查看原始来源
4. 明确注明页面路径和原始来源路径
5. 将可长期使用的输出归档到知识库中

对于明确的 Jevgrep 请求，请对所选知识库的 wiki/ 来源文档使用 jevgrep，并遵循其单独的远程内容／成本门槛。上述先读索引、引用和持久归档步骤保持不变；原始来源摄入和图谱刷新不属于此可选搜索的一部分。

为高价值回答创建可复用的笔记模板：

bash scripts/new-query-note.sh /path/to/vault "How does Company A differ from Company B?" --question "How does Company A differ from Company B?"
bash scripts/new-query-note.sh /path/to/vault "Q2 product thesis" --section reports --citation "[[wiki/concepts/product-thesis]]"

问题形式的输出请放入 wiki/queries/；备忘录、比较或演示文稿框架等更持久的综合成果请放入 wiki/reports/。更多详情请参阅 references/query-and-filing.md。

第 5 步：定期检查并修复 Wiki

运行本地健康检查：

python3 scripts/lint-wiki.py /path/to/vault
python3 scripts/lint-wiki.py /path/to/vault --format json

此脚本检查的是结构，而非事实准确性。它会检查必需的文件和目录、损坏的 Wiki 链接以及孤立页面。将检查输出作为人工引导清理工作的起点：

• 合并重复的概念
• 将被大量引用的想法提升为独立页面
• 删除已被更新来源取代的过时说法
• 在图谱过于稀疏时添加反向链接或摘要页面

更高层级的检查清单请参阅 references/maintenance-and-scaling.md。

第 6 步：只有在规模需要时才添加搜索和自动化

对于中小型知识库，index.md 加上 log.md 就足够了。之后再添加更强大的工具：

• Scrapling：当经常需要从 URL 摄入内容时
• qmd：当索引已不足以支持 Wiki 搜索时
• Obsidian CLI：当你想通过 Shell 驱动自动化，对正在运行的桌面应用操作知识库时
• Dataview：当你开始依赖由 frontmatter 驱动的表格和列表时
• Git：从第一天起就用于版本历史、分支和可审查的差异

不要在第一天就强行引入嵌入、MCP 或浏览器自动化。此工作流的重点在于，简单的 Markdown 仓库就能以惊人的方式不断积累知识。

示例

示例 1：初始化一个全新的知识库

bash scripts/bootstrap-vault.sh ~/vaults/company-research

示例 2：将静态文章保存到原始来源中，并创建来源页面模板

bash scripts/ingest-url.sh ~/vaults/company-research "https://example.com/article"

示例 3：抓取由 JavaScript 渲染的页面

bash scripts/ingest-url.sh ~/vaults/company-research "https://app.example.com/dashboard" --mode fetch --network-idle

示例 4：创建可长期使用的查询笔记

bash scripts/new-query-note.sh ~/vaults/company-research "Why this market is consolidating" \
  --question "Why is this market consolidating?" \
  --citation "[[wiki/concepts/market-structure]]"

示例 5：创建报告模板，而不是查询笔记

bash scripts/new-query-note.sh ~/vaults/company-research "Q3 diligence memo" --section reports

示例 6：运行结构检查

python3 scripts/lint-wiki.py ~/vaults/company-research

最佳实践

1. 保持 raw/ 不变。更正应写入 wiki 页面或后续来源说明，而不是重写原始捕获内容。
2. 每次摄取、归档查询和 lint 检查时，都更新 index.md 和 log.md。如果这些内容不同步，整个工作流会更难导航。
3. 优先创建少量高质量的实体和概念页面，而不是数百个质量低下的零散页面。真正的累积效应来自综合整理，而非页面数量。
4. 在进行耗费资源的检索前，先阅读 index.md。对于中等规模的知识库，这是最简单且实用的搜索系统。
5. 区分事实与综合整理。来源页面应以事实为依据；概念页面可以包含更多阐释。
6. 将有价值的答案归档回知识库。如果某个答案曾经重要过，它很可能还会再次派上用场。
7. 使用 git 提交区分摄取、查询和 lint 操作，以便 wiki 保持可审计性。
8. 保持架构规范持续完善。发现反复出现的偏差或歧义时，更新 AGENTS.md。

参考资料

• references/architecture.md
• references/schema-playbook.md
• references/ingest-playbook.md
• references/query-and-filing.md
• references/maintenance-and-scaling.md
• scripts/bootstrap-vault.sh
• scripts/ingest-url.sh
• scripts/new-query-note.sh
• scripts/lint-wiki.py
• Karpathy gist：llm-wiki