# Graph Engineering: The 11-Step Roadmap From Obsidian Vault to Graph Fable 5 Can Actually Use
**作者**: unicode
**日期**: 2026-07-24T16:38:01.000Z
**来源**: [https://x.com/unicodef1wn/status/2080693998180606075](https://x.com/unicodef1wn/status/2080693998180606075)
---
Everyone's building a second brain in Obsidian. Almost no one builds the part that makes it work.
Open your vault right now. If it's a flat pile of notes with no structure, here's what happens every time you ask Fable 5 one question: it reads all of them.
That's 2,000 notes and a few hundred thousand tokens burned to hand you one answer. Slow, expensive, and it still grabs the wrong file half the time.
That's not a second brain. It's a vault full of markdown files you taught Fable 5 to search blind.
A second brain is only as good as the graph underneath it, not the vault. This is the 11-step roadmap from an Obsidian folder Fable 5 drowns in to a structure it walks in seconds.
The vault every note read, every single question The tokens hundreds of thousands per answer, billed every time The graph 2 to 3 files read, answer back in under a second The delta a fraction of the cost, right far more often
> Before we go further: follow me on X, @unicodef1wn, and the deeper breakdowns go out first on Telegram, t.me/unicodef1wn. That's the only ask in this article. Everything below is the actual system.
Everyone screenshots the wrong layer, Obsidian's graph view, the glowing web of dots. One builder running this at scale put it well:
> "The pretty graph is for you. The index is for Fable 5. Only one of them makes it faster."
The poster on the wall versus the engine under the hood.
Graph engineering means building the engine inside your vault: the router, the index, the nodes, the edges, and the logic that walks them.
11 steps. The part that decides whether your Obsidian vault thinks, or just sits there looking impressive.
## Part 1: What a Graph Actually Is
1. A graph is a routing structure, not a picture
Four parts. A router Fable 5 reads first. An index it checks against. Nodes that hold the knowledge. Edges that point between them.
That covers it. Obsidian's graph view proves connections exist. It doesn't stop Fable 5 from reading 2,000 notes to answer one question.
2. The whole graph lives in one folder
Everything that shapes retrieval sits inside your vault, in one directory. Learn this layout once and you can read anyone's second brain in ten seconds:
vault/
├─ ROUTER.md # read every session, kept tiny
├─ index.md # one line per note: name, link, description
├─ nodes/ # your notes, one idea per file
│ ├─ billing-rules.md
│ └─ client-acme.md
├─ routines/ # how you save and how you find
└─ state.md # what survives between sessions
You should be able to say why every file exists. If you can't explain a note, it shouldn't be a separate node.
3. Pile vs. graph vs. system
- The pile. An Obsidian vault with no map. Ask Fable 5 anything, it reads everything.
- The graph. The same vault with a router, an index, and edges. Ask it anything, it reads two or three files.
- The system. A graph with memory that compounds. Every session leaves the next one sharper.
Most "my Obsidian vault is a mess" complaints are these three tangled together. Pull them apart and it gets fast.
4. The default vault is a hoarder, not a librarian
Point Fable 5 at a raw Obsidian folder and it "works." It finds things by reading the whole vault on every question.
That's fine at 30 notes. At 3,000, every question scans your entire vault and you pay for it.
A hoarder owns everything and finds nothing on command. A librarian owns the same shelf and hands you the right book in five seconds. The next seven steps turn Fable 5 into the librarian.
## Part 2: Build the Graph
5. The router, kept brutally short
The router is a single note Fable 5 reads at the start of every session. It's a map, not a manual: "billing lives here, this client lives there."
The mistake almost everyone makes: it grows into a novel, and every session drags that novel into context before Fable 5 does anything.
Keep it under 500 tokens. Facts and directions only. The actual knowledge lives in the nodes, not the router.
6. The index, one line per node
The index is how Fable 5 knows where an answer lives without opening a note. One line per node: name, link, one sentence.
# index
- billing-rules.md | rates, refunds, escalation | how we bill and when
- client-acme.md | Acme account | contacts, scope, gotchas
- voice.md | writing voice | tone rules + banned words
Every new note gets a line here, automatically, from day one. A current index keeps retrieval cheap for life. Let it drift and your vault turns back into a pile.
7. Nodes, one idea per file
A node does one job. Small, specific, named so the title alone tells you what's inside.
The enemy is the mega-note, the file that quietly grew to cover ten topics because starting a new one in Obsidian felt like overhead. To use one line of it, Fable 5 has to swallow all ten.
Split by idea. Small nodes are cheap to open. Fat ones cost you every time.
8. Edges, pointers, not the graph view
An edge is a link inside one note to another, an Obsidian [[wikilink]] with a purpose. That's the real graph, the pointer, not the visual you'd screenshot from graph view.
A node answers half your question and links to the one that finishes it. Fable 5 follows one edge instead of digging through the whole vault.
Link only what a node actually depends on. Ten sharp edges make a graph. Fifty is just noise wearing a graph's clothes.
9. Retrieval as logic, not model calls
Here's why most vaults stay slow: they let Fable 5 do the finding. But finding doesn't need intelligence. It's a matching problem, and it shouldn't cost you a model call.
The order that works:
1. Strip the question to keywords, drop the filler
2. Score every node from index.md alone, open nothing
3. Open only the best match, not three "just in case"
4. Read only the section that answers, not the whole note
5. Follow one edge if that section points elsewhere
6. Now Fable 5 runs once, evidence already in hand
Steps one through five cost nothing, because they're logic, not model turns. One real build of this cut cost sharply against the default and answered faster on nearly every question.
## Part 3: Make It Compound
10. Prove it
Don't take it on faith. Run the same questions through a raw Obsidian vault and through your graph, side by side.
Compare tokens. Compare wall-clock time. Check that the answers are actually right. This is the step most people skip, and the one that turns "I think it's faster" into an actual table you can point to.
11. Add memory, then ship it
Fable 5 wipes clean between runs. Your vault doesn't have to.
A state file logs what was tried, what worked, what didn't. Every run ends by writing to it and starts by reading it.
The value was never Fable 5. It's the router, the index, the edges, the rules: plain markdown in a vault you own. Swap the model behind it next year and you lose nothing.
## The Graph Mistakes That Keep Your Vault Slow
- Running on the raw vault. No router, no index. Fable 5 reads everything to answer anything.
- A bloated router. A router note that turned into a manual. Cut it to 500 tokens of pointers.
- No index. Without it Fable 5 can't guess where an answer lives, so it opens notes blind.
- Mega-notes. One giant file it has to swallow whole to use one line of. Split by idea.
- Letting the model do the finding. That's a logic job. Save Fable 5 for the thinking.
- No memory. Every run restarts from zero. The state file is what lets tomorrow pick up where you left off.
- Building the graph before you have notes. Empty structure is busywork. Write first, then engineer.
## Conclusion
Obsidian's graph view gets the screenshots. The index does the work.
Everyone falls for the galaxy of dots. It's a poster.
Every decision that makes Fable 5 fast or slow, cheap or expensive, sharp or vague lives one floor beneath your vault: the router you wrote, the index you kept honest, the edges you drew, the logic that finds before the model thinks.
Build that floor and everything above it compounds. Fable 5 reads three notes instead of two thousand. The bill drops. The answers get sharper.
Pick the one thing you're not doing, probably the index, or logic before model calls, and add it today. Keep the graph small enough to explain out loud.
P.S. If you build one thing off this, make it the index. Not the router, not the edges, the index. It's the cheapest step here and the one every other step scores against. Get that right and the rest gets fast almost on its own.
Bookmark this before it gets buried. If it helped, send it to one person still dragging Fable 5 through a raw Obsidian vault.
More of this, before the rest of the feed buries it too: follow on X at @unicodef1wn, and get the next breakdown early on Telegram at t.me/unicodef1wn.
## 相关链接
- [unicode](https://x.com/unicodef1wn)
- [@unicodef1wn](https://x.com/unicodef1wn)
- [@unicodef1wn](https://x.com/unicodef1wn)
- [t.me/unicodef1wn](https://telegram.me/unicodef1wn)
- [@unicodef1wn](https://x.com/unicodef1wn)
- [t.me/unicodef1wn](https://telegram.me/unicodef1wn)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:38 AM · Jul 25, 2026](https://x.com/unicodef1wn/status/2080693998180606075)
- [8,097 Views](https://x.com/unicodef1wn/status/2080693998180606075/analytics)
- [View quotes](https://x.com/unicodef1wn/status/2080693998180606075/quotes)
---
*导出时间: 2026/7/25 11:40:48*
---
## 中文翻译
# 图谱工程：从 Obsidian 仓库到 Fable 5 真正能用的 11 步路线图
**作者**: unicode
**日期**: 2026-07-24T16:38:01.000Z
**来源**: [https://x.com/unicodef1wn/status/2080693998180606075](https://x.com/unicodef1wn/status/2080693998180606075)
---
每个人都在 Obsidian 里建立第二大脑。但几乎没人去构建让它运转起来的那部分。
现在打开你的仓库。如果它只是一堆没有结构的扁平笔记，那么每次你问 Fable 5 一个问题时，都会发生这样的事：它会通读所有笔记。
这就意味着，为了给你一个答案，它要读取 2,000 条笔记，并消耗几十万个 token。速度慢、成本高，而且它有一半的时间还会抓错文件。
那不是第二大脑。那只是一个装满了 markdown 文件的仓库，而你教会了 Fable 5 在里面盲目搜索。
第二大脑的效能取决于底层的图谱，而不是仓库本身。这是一份 11 步路线图，旨在将 Fable 5 会淹没其中的 Obsidian 文件夹，转化为它几秒钟就能轻松驾驭的结构。
每个笔记都读取的仓库，每一个问题 数以十万计的 token，每次计费 图谱读取 2 到 3 个文件，不到一秒回传答案 差异成本仅为几分之一，正确的频率却高得多
> 在继续之前：在 X 上关注我 @unicodef1wn，更深度的解析会首发在 Telegram 上，t.me/unicodef1wn。这是本文唯一的要求。以下内容全是实际操作的系统。
大家都截错了图层，截的是 Obsidian 的图谱视图，那个发光的点状网络。一位大规模运行这套系统的开发者说得很到位：
> “漂亮的图谱是给你看的。索引才是给 Fable 5 看的。只有其中一个能让它变快。”
挂在墙上的海报与引擎盖下的引擎。
图谱工程意味着在你的仓库内构建引擎：路由器、索引、节点、边，以及遍历它们的逻辑。
11 个步骤。正是这一部分决定了你的 Obsidian 仓库是在思考，还是只是静静地摆在那儿看似令人印象深刻。
## 第一部分：图谱究竟是什么
1. 图谱是路由结构，不是图片
四个部分。一个 Fable 5 首先读取的路由器。一个供它检查的索引。储存知识的节点。指向彼此的边。
这就涵盖了。Obsidian 的图谱视图证明连接存在。但它不能阻止 Fable 5 读取 2,000 条笔记来回答一个问题。
2. 整个图谱存在于一个文件夹中
所有影响检索的内容都位于你的仓库内，在一个目录下。学会这种布局，你就能在十秒钟内看懂任何人的第二大脑：
vault/
├─ ROUTER.md # 每个会话读取，保持极简
├─ index.md # 每个笔记一行：名称、链接、描述
├─ nodes/ # 你的笔记，每文件一个想法
│ ├─ billing-rules.md
│ └─ client-acme.md
├─ routines/ # 你如何保存以及如何查找
└─ state.md # 会话之间留存的内容
你应该能说出每个文件存在的理由。如果你无法解释一条笔记，它就不应该是一个独立的节点。
3. 堆砌 vs 图谱 vs 系统
- 堆砌。没有地图的 Obsidian 仓库。问 Fable 5 任何事，它都通读所有内容。
- 图谱。同一个仓库，但带有路由器、索引和边。问它任何事，它只读两三个文件。
- 系统。带有记忆复利效应的图谱。每个会话都让下一个会话更敏锐。
大多数“我的 Obsidian 仓库乱七八糟”的抱怨，都是把这三种情况混为一谈。把它们拆分开，速度就上来了。
4. 默认仓库是个囤积狂，不是图书管理员
将 Fable 5 指向一个原始的 Obsidian 文件夹，它确实能“工作”。它通过在每个问题上通读整个仓库来找到东西。
在 30 条笔记时这没问题。到了 3,000 条，每个问题都会扫描你的整个仓库，而你要为此买单。
囤积狂拥有一切却无法按指令找到任何东西。图书管理员管理着同样的书架，却能在五秒内递给你正确的书。接下来的七步将把 Fable 5 变成图书管理员。
## 第二部分：构建图谱
5. 路由器，保持极度简短
路由器是 Fable 5 在每个会话开始时读取的单条笔记。它是一张地图，不是手册：“账单在这里，那个客户在那里。”
几乎每个人都犯的错误：它长成了一本小说，而每个会话在 Fable 5 做任何事之前，都要把这本小说拖进上下文里。
把它控制在 500 token 以内。只写事实和方向。实际知识存在于节点中，而不是路由器里。
6. 索引，每节点一行
索引是 Fable 5 在不打开笔记的情况下知道答案何在的方式。每个节点一行：名称、链接、一句话。
# index
- billing-rules.md | rates, refunds, escalation | how we bill and when
- client-acme.md | Acme account | contacts, scope, gotchas
- voice.md | writing voice | tone rules + banned words
从第一天起，每条新笔记都会自动在这里占一行。保持索引最新能让检索成本终身低廉。任其漂移，你的仓库就会退化回堆砌状态。
7. 节点，每文件一个想法
节点只做一项工作。小巧、具体，命名要光看标题就知道里面是什么。
敌人是巨型笔记，那种因为觉得在 Obsidian 里新建文件是额外负担而悄悄膨胀到涵盖十个主题的文件。为了使用其中的一行，Fable 5 必须吞下所有十个。
按想法拆分。小节点打开成本低。大节点每次都要让你付出代价。
8. 边，是指针，不是图谱视图
边是一条笔记指向另一条笔记的链接，是有目的的 Obsidian [[wikilink]]。那才是真正的图谱，是指针，而不是你会从图谱视图截屏的那种视觉效果。
一个节点回答了你问题的一半，并链接到完成另一半的节点。Fable 5 跟随一条边，而不是挖掘整个仓库。
只链接节点真正依赖的内容。十条锋利的边构成一个图谱。五十条只是穿着图谱外衣的噪音。
9. 检索是逻辑，不是模型调用
大多数仓库之所以保持缓慢，原因就在这里：它们让 Fable 5 去做查找。但查找不需要智能。这是一个匹配问题，不应花费一次模型调用的成本。
有效的顺序如下：
1. 将问题剥离为关键词，去掉填充词
2. 仅凭 index.md 对每个节点打分，不打开任何文件
3. 只打开最佳匹配项，而不是打开三个“以防万一”
4. 只阅读回答问题的部分，而不是整条笔记
5. 如果该部分指向别处，则跟随一条边
6. 现在 Fable 5 运行一次，证据已经在手
步骤一到五不花费任何成本，因为它们是逻辑，不是模型轮次。按照这种方式构建的一个真实案例，与默认方式相比大幅削减了成本，并且在几乎每个问题上回答得更快。
## 第三部分：让其复利
10. 验证它
不要听信空话。用原始 Obsidian 仓库和你的图谱分别运行相同的问题，并排比较。
比较 token。比较实际耗时。检查答案是否真的正确。这是大多数人跳过的步骤，也是将“我觉得它更快”转化为你可以展示的实际表格的步骤。
11. 添加记忆，然后交付
Fable 5 在运行之间会清空状态。你的仓库不必如此。
状态文件记录了尝试了什么、什么有效、什么无效。每次运行结束时写入，开始时读取。
价值从来都不在 Fable 5。而在路由器、索引、边、规则：即你拥有的仓库里的纯 markdown 文本。明年更换背后的模型，你也不会损失任何东西。
## 让你的仓库保持缓慢的图谱错误
- 在原始仓库上运行。没有路由器，没有索引。Fable 5 读取所有内容来回答任何问题。
- 臃肿的路由器。变成了手册的路由器笔记。将其削减到 500 token 的指针。
- 没有索引。没有它，Fable 5 无法猜测答案在哪里，所以它会盲目打开笔记。
- 巨型笔记。为了使用其中一行而必须整本吞下的巨大文件。按想法拆分。
- 让模型做查找。那是逻辑的工作。把 Fable 5 留给思考。
- 没有记忆。每次运行都从零开始。状态文件是让明天能从你停下的地方继续的关键。
- 在没有笔记之前构建图谱。空结构是瞎忙活。先写，再工程化。
## 结论
Obsidian 的图谱视图负责截图。索引负责干活。
每个人都迷恋那个点状星系。那是张海报。
每一个让 Fable 5 变快或变慢、变便宜或变昂贵、变敏锐或变模糊的决定，都存在于你的仓库下一层：你写的路由器、你保持诚实的索引、你画的边、以及在模型思考之前进行查找的逻辑。
构建这一层，其上的一切都会产生复利。Fable 5 读取三条笔记而不是两千条。账单下降。答案变得更敏锐。
挑出一件你没在做的事，可能是索引，或者模型调用前的逻辑，今天就加上它。保持图谱足够小，以便能口头解释清楚。
P.S. 如果你基于本文只做一件事，那就做索引。不是路由器，不是边，是索引。这是这里最便宜的步骤，也是其他所有步骤都要据此打分的步骤。把这一步做对，其余的几乎会自动变快。
在它被淹没之前收藏这条推文。如果它对你有帮助，把它发给一个还在拖着 Fable 5 跑原始 Obsidian 仓库的人。
更多此类内容，在其余信息流将其掩埋之前：在 X 上关注 @unicodef1wn，并在 Telegram t.me/unicodef1wn 上提前获取下一篇解析。
## 相关链接
- [unicode](https://x.com/unicodef1wn)
- [@unicodef1wn](https://x.com/unicodef1wn)
- [@unicodef1wn](https://x.com/unicodef1wn)
- [t.me/unicodef1wn](https://telegram.me/unicodef1wn)
- [@unicodef1wn](https://x.com/unicodef1wn)
- [t.me/unicodef1wn](https://telegram.me/unicodef1wn)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:38 AM · Jul 25, 2026](https://x.com/unicodef1wn/status/2080693998180606075)
- [8,097 Views](https://x.com/unicodef1wn/status/2080693998180606075/analytics)
- [View quotes](https://x.com/unicodef1wn/status/2080693998180606075/quotes)
---
*导出时间: 2026/7/25 11:40:48*