index.md 失效那一刻：我怎么让知识库在“几百页之后”仍然找得到、用得上、写得出（附触发条件/流程模板）
一只阿木木约 8 分钟index.md 失效那一刻：我怎么让知识库在“几百页之后”仍然找得到、用得上、写得出（附触发条件/流程模板）
我第一次把“编译式知识库”（raw → wiki → 交付）跑顺的时候，最爽的一件事是：index.md 就像目录一样好用——你先翻目录，再钻进相关页面，很快就能回答问题、写方案、写文章。
然后知识库变大了（来源多了、页面多了、概念开始分叉），我开始出现一种非常典型的“系统性疲劳”：
我明明写过，但想不起在哪； 我搜得到一堆相关页面，但不知道该信哪一个； 我越怕写错，就越不敢沉淀，最后又回到“收藏夹=焦虑”。
这篇我想把我后来走出来的路径讲清楚：什么时候 index 还够用、什么时候必须上搜索、什么时候需要引入“图谱分析/Graphify”来把 Obsidian 的图从“好看”变成“好用”。
这套升级路线的理论底座来自 Karpathy 在 2026-04-04 的《LLM Wiki》：index.md 在中等规模很好用，但随着 wiki 增长迟早需要“proper search”；他还明确推荐 qmd 这种本地混合检索工具，并强调 Obsidian 的 graph view 用来观察 wiki 形状、找 hub 和孤岛。 1
1）先把话说狠：你卡住不是因为你不努力，而是“导航系统”换代了
你早期靠 index.md 顺，是因为它解决的是导航（navigation）问题：
“我有哪些页面？大概在哪个分类？我先读哪几页？”——目录非常适合做这个。1
但规模上来之后，你遇到的是检索（retrieval）问题：
“我现在要找的那一句关键事实/那次决策理由/那个参数对比，究竟在哪个段落？”
这时目录再长也只能提供“从哪开始翻”，无法提供“最相关的几段”。（这就是你感觉“明明写过但找不到”的根因。）
结论：
- index.md
适合“人类先看目录再阅读” - 搜索引擎
适合“机器先检索再给你候选证据” - 图谱分析
适合“发现结构问题：孤岛、神页、重复概念、意外连接”
2）我如何判断：什么时候 index 还够用？什么时候必须升级？
Karpathy 给了一个非常实用的经验边界：index.md 在“约 100 个 sources、几百页 wiki”这种中等规模“surprisingly well”，并且能避免一开始就上 embedding/RAG 基建；但随着增长，迟早需要 proper search。1
我自己的判断不是用“页数”拍脑袋，而是用症状触发（你只要中 2 条，就该升级）：
升级触发条件（我用的 7 条）
- 重复问同一个问题
：你开始反复问“我们当时为什么这么定？” - 同义词爆炸
：同一概念出现 3 个名字（比如“Agent 记忆/长期记忆/持久记忆”），你自己都不确定哪页是主版本 - 索引更新变重
：每次 ingest 更新 index 都像在维护一本“越来越难翻的字典” - 答案缺证据链
：query 生成的答案常常漏掉关键页面或关键段落 - 局部真相很多，但总论写不出来
：你有很多碎片卡片，但交付层（备忘录/方案/长文）迟迟出不来 - 孤岛页变多
：很多页面没有入链（你写了，但系统从未再用到） - “神页”（God node）出现
：所有东西都往同一页塞，导致它又长又乱、任何改动都牵一发动全身
当你出现这些症状，本质上是在告诉你：你需要第二个系统来协助“定位证据段落”，而不是继续扩写目录。
3）升级路线图（最重要的一张图）：目录 → 搜索 → 图谱分析 → 回填交付
我把升级做成四段，不要求你必须用某个软件，但每一段都要有“可交付产物”。
阶段 A：index-first（目录优先）
目标：人读得懂、能导航 产物：index.md（按分类列出页面 + 一句话摘要 + 关键元数据）1
阶段 B：search-first（检索优先）
目标：机器先帮你找到“可能相关的 5–10 页/段落” 产物：一个本地搜索索引（关键词 + 语义）
Karpathy 明确把“搜索引擎”称为 wiki 增长后的最 obvious 工具，并点名 qmd：本地混合 BM25/向量检索 + LLM rerank，并且有 CLI 与 MCP 两种接入方式。1
阶段 C：graph-first（结构优先）
目标：让系统告诉你“结构哪里烂了”：重复概念、神页、意外连接、孤岛 产物：一份结构报告（哪些是枢纽，哪些是孤岛，哪些连接出乎意料）
如果你的材料里包含“代码 + 文档 + 论文/PDF + 图”，Graphify 这类工具能用 Tree-sitter 静态分析 + 语义抽取构建知识图，并用 Leiden 社区发现做聚类，输出GRAPH_REPORT.md、graph.html/json，还能导出到 Obsidian。2
阶段 D：deliverable-first（交付优先）
目标：每次 query/分析必须落到“可交付文本”（一页结论、决策记录、FAQ、长文骨架） 产物：可发人/可复用的交付件
Karpathy 特别强调：好的答案不该消失在聊天里，而应回填成新页面，让探索复利。1
4）实操：我怎么把“搜索”接进工作流（把找不到变成可复现流程）
这里我只讲“流程”，不讲安装命令（因为工具可以换）。我自己用的是 qmd 这一类“本地混合检索”：BM25（擅长精确名词/编号/专有词）+ 向量语义（擅长同义改写）+ rerank（把候选再排一遍），而且完全 on-device。3
我固定的一次 Query 流程（SOP：Search → Read → Synthesize → File back）
Step 1：先检索，不要先读目录
用关键词（BM25）找“精确命中”：人名、项目名、指标名、版本号 用自然语言（混合检索）找“语义相关”：比如“我们为什么不做 B 方案？”
qmd 的 CLI 设计就很贴这套分工：既有 search（偏 BM25），也有 query（混合检索 + rerank）。3
Step 2：限制阅读窗口：只读 Top 5–10 页 这一步是反人性的，但必须做。否则你又回到“无限翻资料”。
Step 3：强制输出“证据表”，再写结论 我要求 LLM（或我自己）先产出一个表：
目的只有一个：把“顺滑叙事”拆回“可核查证据”。
Step 4：生成交付件（不是生成散文） 把答案写成：
一页结论备忘录 / 决策日志 / FAQ / 对比表
Step 5：回填到 wiki（必须） Karpathy 的原话非常明确：好的答案应该回填成新页面，否则探索不会复利。1
Step 6：在 log.md 里记一条“这次做了什么” Karpathy 把 log.md 定义为 append-only 的时间线，建议用统一前缀让它可被 grep 等工具解析。1
5）Obsidian 图谱为什么常常“好看但没用”（以及我怎么让它变有用）
先泼冷水：Obsidian 的 Graph view 画的只是“笔记之间的内部链接”——节点是笔记，边是内部链接；被引用多的节点会更大。它不是语义理解，也不会自动帮你补连接。4
所以你很多时候看到的只是：
一团星云（你不知道从哪里下手） 或者一堆孤岛（你写了但没链接，当然不连）
我让图谱变有用的三个动作（都很“笨”，但有效）
动作 1：给每个主题一个“主入口页”（Hub page），强制所有页面至少入链一次
这不是为了美观，是为了消灭孤岛页，让未来检索/导航都有抓手。
动作 2：把“索引”从一页长名单，变成“多级入口” Karpathy 的 index.md 是 content-oriented 的目录；我把它拆成：
总 index（只保留一级入口） 每个分类/项目一个子 index（像文件夹说明书）
这样图谱会自然长出“清晰的骨架”。
动作 3：用 lint/体检把结构问题变成待办 Karpathy 把 lint 定义为健康检查：矛盾、过时、孤岛、缺交叉引用、缺口要补来源。1
图谱最有用的时候，往往不是“看全局”，而是用它配合 lint 去修复结构问题。
6）当你有“代码 + 文档 + PDF + 图”：我为什么会引入 Graphify（不是为了炫技）
如果你的素材是纯文本，其实“搜索 + 目录 + 体检”已经很能打。
但如果你在做的是“项目/产品/技术体系”的知识资产化，你会遇到一个现实：结构关系藏在代码与图里，单靠 Markdown 链接很难完整表达。
Graphify 这一类工具给我的价值不在“又一个可视化”，而在它的输出物：
它会把代码、Markdown、PDF、图像等多模态材料抽取成一个图； 通过 Tree-sitter 提取 AST/调用关系等结构信号，并结合语义抽取； 用 Leiden 做社区发现聚类； 输出 GRAPH_REPORT.md（人能读的审计报告）、graph.html/json（可交互/可程序化）。2
更关键的是：它会识别所谓的 “god nodes”（高度节点）和“surprise connections”（意外连接）。2
这两个信号非常适合反过来指导你怎么维护 wiki：
god node：提示你“哪个概念/模块过载，需要拆页、加边界、加子索引” surprise connection：提示你“这里可能需要一页对比/一页解释”，否则你永远不知道它们为何相关
7）我踩过的坑（这部分决定你做大之后会不会崩）
坑 1：只上向量检索，放弃关键词（BM25）
你会丢掉大量“精确检索”场景：编号、版本、参数名、专有名词。
qmd 这类混合检索之所以更稳，是因为它把 BM25、向量语义与 rerank 组合起来（而不是二选一）。3
坑 2：把搜索当答案生成器，而不是证据定位器
搜索的正确作用是：给你候选证据。
真正的“可交付结论”必须经过：证据表 → 结论 → 反例/边界 → 下一步验证。
坑 3：图谱沉迷
Obsidian 图谱只是链接图；Graphify 的图谱是结构/语义抽取后的图。两者都不是“真理”，它们只是帮助你发现问题。4
你如果只看图，不回填交付层，最后还是“好看但没用”。
坑 4：不做“本地资产化”，规模一大就被工具锁死
我坚持文件化/本地化的底层原因，是 local-first 的那套价值：数据主要在你设备上、可离线、可长期保存、可用各种工具加工。Ink & Switch 在 2019 的文章里把这种软件称为 local-first，并强调数据所有权与长期可用性。5
这也是 Karpathy 选择“markdown + git repo”作为 wiki 形态的根本好处：可迁移、可审计、可回滚。1
附：我直接给你三份“可复制”的模板
A）升级触发条件卡（贴在你的 index 顶部）
Markdown
## 何时必须从 index 升级到 search？
- [ ] 我开始重复问同一问题（每周≥2次）
- [ ] 同一概念出现≥3个命名
- [ ] index 更新成本明显变高
- [ ] 答案经常漏掉关键证据页
- [ ] 孤岛页变多 / 神页出现
=> 命中2条：上本地搜索；命中4条：加结构体检 + 图谱分析
B）Search → Answer → File-back（每次 query 的固定输出）
Markdown
# Query Session — YYYY-MM-DD
## Question
...## Retrieval (top hits)
1) [[...]] — why relevant
2) [[...]] — why relevant
## Evidence Table
| claim | evidence | source | counterexample |
|---|---|---|---|
## Deliverable (1-page memo / FAQ / decision)
...
## File-back
- created: [[deliverables/...]]
- updated: [[concepts/...]], [[index.md]], [[log.md]]
C）读 GRAPH_REPORT.md 的三步（如果你用 Graphify）
Markdown
1) God nodes：哪个页/模块过载？=> 拆页 + 加边界 + 建子索引
2) Surprises：哪些意外连接值得写“解释页/对比页”？
3) Communities：每个社区是否有一个“入口页”？没有就补
结尾（我自己的“规模化心法”）
我的结论很简单：
- index 解决导航
，但不会解决规模化检索； - 搜索解决定位证据
，但不会自动给你结构； - 图谱分析解决结构健康
，但不会替你做交付； 真正让知识库“越大越值钱”的，是你坚持把每次产出回填成可复用交付件（而不是让答案烂在聊天里）。
如果你按这条路线走，你会明显感觉到：知识库不再是“越积越沉的资料堆”，而是一个能持续产出决策与作品的系统。
AII
松花酿酒，春水煎茶。
眉上风止，见字如晤。
一只阿木木