一个塞满两千个文件的Obsidian知识库，每次提问都要把全部内容喂给大模型，烧掉几十万token才挤出一句话。又慢又贵，还经常答非所问。真正的第二大脑不是笔记堆，是藏在底下的那套图路由结构。
图工程就是把Obsidian文件夹改造成大模型能秒懂的知识导航系统。本文拆解十一步实操路线，从零搭建路由器、索引、节点和边，让大模型只读两三个文件就给出精准答案。
路由器必须薄成一片纸
路由器是整个图结构的第一道关卡。大模型每次启动会话都会先读这份文件。它的任务只有一个：告诉大模型各类知识存放在哪个区域。计费规则在计费节点，客户信息在客户节点，写作风格在风格节点。
绝大多数人把路由器写成了操作手册。塞进去一堆解释性文字，什么背景介绍使用场景注意事项，结果路由器自己先膨胀成一篇长文。每次提问都要先消化这篇长文，还没开始回答问题预算就烧掉一小半。
路由器要控制在五百个token以内。只写事实性指向，不要任何解释。
计费规则指向billing-rules，客户资料指向client-acme，语气规范指向voice。
大模型看到这些指向就知道该去哪找，不用再翻遍整个知识库。
# router.md 示例
计费规则 → billing-rules
客户资料 → client-acme
写作规范 → voice
索引让大模型提前知道答案在哪
索引文件记录每个节点的名称、链接和一句话摘要。大模型提问时先扫索引，不需要打开任何笔记就能判断答案藏在哪个节点。计费规则节点摘要写清楚里面包含费率计算、退款流程和升级规则。客户节点摘要写清楚包含联系人信息、合同范围和特殊条款。
索引是图工程里最便宜的优化手段。每新增一个笔记节点就顺手在索引里加一行。索引保持更新，检索就永远便宜。索引一旦滞后，大模型失去判断依据，只能回到盲搜模式，一个个打开笔记去找答案。
索引行格式固定。笔记文件名加上一行简短描述。不用花哨格式，纯文本就够了。大模型处理纯文本效率最高，任何多余格式都在拖慢速度。
# index.md 示例
- billing-rules.md | 费率计算、退款流程、升级规则 | 计费相关所有规则
- client-acme.md | 联系人信息、合同范围、特殊条款 | Acme公司客户档案
- voice.md | 语气规范、禁用词列表 | 内容风格指南
节点小而专才能省token
节点是存放实际知识内容的文件。每个节点只负责一个主题。计费规则独立成文件，客户资料独立成文件，写作风格独立成文件。
大节点是图工程的头号敌人。一个文件塞进十个不相关的话题，大模型为了用其中一行就得吞下全部内容。每次提问都在浪费算力。按话题拆分，小文件打开成本低，大模型读得快花得少。
节点命名要直白。文件名本身就说明内容。计费规则就叫billing-rules，不用起什么抽象缩写。任何人都能看懂文件名，大模型也能通过文件名快速定位。
边是真实连接不是漂亮图表
Obsidian的图谱视图展示节点之间的关系网。发光的小点连成一片星系，截图发社交媒体特别唬人。但那张图对检索速度毫无贡献。
真正的边是节点内部的维基链接。一个节点解答了一半问题，末尾用维基语法指向另一个节点完成剩下的一半。大模型顺着链接跳转，不用重新扫描整个知识库。
链接必须精准。只连接确实存在依赖关系的节点。十根精准的边构成高效图结构，五十根随意的链接只会制造噪音。
# billing-rules.md 中的边
退款申请需要先确认客户账户状态，具体操作流程见 [[client-acme]] 中的账户冻结章节。
# client-acme.md 中的边
Acme公司账户冻结流程完成后，退款金额计算规则参考 [[billing-rules]] 的费率章节。
检索靠逻辑不靠模型调用
大多数人让大模型自己去找答案。但查找是逻辑匹配问题，不需要动用大模型的理解能力。每调用一次模型都要花钱，把查找环节交给逻辑判断能省掉大量成本。
正确顺序是：先把提问拆成关键词丢掉废话，只在索引文件里给每个节点打分不打开任何笔记，只打开得分最高的那个节点，只读取能回答问题的那个段落不读全文，如果段落末尾有链接就跟着跳转一次。做完这六步大模型才出场，手里已经有现成证据只需整理输出。
前五步零成本，因为没有调用模型。实际测试中这套流程比原始方式快得多，每次提问读两三个文件就够了。
# 检索逻辑伪代码
function retrieve(question):
keywords = extract_keywords(question)
scores = score_nodes(index.md, keywords)
best_node = get_highest_score(scores)
section = find_answer_section(best_node)
if section has wikilink:
section += read(wikilink)
return section
记忆让每次运行都更聪明
大模型每次会话都是全新开始。但知识库不必每次都从零起步。状态文件记录上次运行尝试了哪些路径哪些成功哪些失败。新会话先读状态文件，避开上次踩过的坑。
状态文件里写清楚上次提问找到答案走的是哪条路径。这次遇到类似问题直接复用路径。状态文件也记录哪些查询方式效果差，以后避开那些方式。知识库越用越顺手，每次运行都在给下次铺路。
# state.md 会话状态记录
上次成功路径：
- 退款问题 → router → index → billing-rules → client-acme
- 合同条款 → router → index → client-acme
上次失败尝试：
- 单搜"费用"命中率低，改用"费率"+"计费"组合查询
图结构让大模型秒变检索高手
原始知识库没有路由器没有索引没有边。大模型提问只能全量扫描所有文件。三百个笔记时勉强能用，三千个笔记时每次提问都像大海捞针。
图结构加上路由器索引和边之后，大模型提问先查路由器知道去哪找，再扫索引锁定具体文件，最后读一两个节点拿到答案。整个流程逻辑驱动不依赖模型猜测，速度快成本低答案准。
验证数据别信直觉
改造完图结构要跑对比测试。同一批问题分别问原始知识库和图结构知识库。记录每次回答消耗的token数和响应时间。检查答案质量有没有下降。
大多数人跳过验证步骤。觉得快了就当快了。但实际数据往往证明直觉靠不住。测试结果能清楚显示图结构到底省了多少token快了多少秒。这些数字比任何口头宣称都有说服力。
先写笔记再建图
空图结构没有任何价值。笔记还没写就开始画路由器设计索引表格，全是在做无用功。先把知识写进节点，每个节点一个主题，积累到一定数量后再搭建路由和索引。
写笔记的过程中连接关系自然浮现。哪些节点经常一起出现，哪些问题跨多个节点才能解答，这些信息来自真实内容不是凭空想象。基于真实笔记建的图结构才有实际用处。
索引是最值得先做的事
十一项步骤里索引带来的提升最明显投入最小。路由器需要反复精简调整，边的质量依赖于节点粒度是否合适，逻辑检索需要写代码。索引只需要开一个文件，每写一个笔记加一行描述。
索引做对了路由器和边的效果都会放大。大模型能精准定位节点，边的跳转才变得有意义。索引歪了后面所有步骤都得返工。先把索引这张牌打好，剩下的路自然顺。
搞完索引再折腾逻辑检索，把查找环节从模型调用里剥离出来。两项完成图工程已经具备八成战斗力。剩下的路由器精简和边优化慢慢迭代就行。
知识库不会自己变聪明。路由器索引节点边逻辑检索状态文件，每一项都是亲手搭出来的。搭完才知道大模型原来可以这么听话。