技术 · 熟练
索引建好了，为什么一点没快？
索引管取件，指令管动作
给编码 agent 装一层本地索引，收益不会自动到来 —— 它同时取决于两件事：检索层本身，以及一条让它先检索、再翻文件的常驻指令。一套本地优先的开源实现给出的自测口径是：工具调用次数少 43% · 令牌少 16% · API 成本低 18% · 耗时短 21%；但作者在同一处写明，这些收益取决于「检索」与「让 agent 先搜的指令」成对存在 —— 只建索引不改指令，数字落不下来。同一份说明还点了它自己的软肋：精确的文本搜索工具没有新鲜度问题，而索引有；编辑与切分支之后谁负责重建，这条不定就等于没有索引。
方法 · 一图看懂
1
先量它现在把时间花在哪 — 数工具调用次数，别凭感觉说它慢
2
建一层本地只读索引 — 把仓库、变更、文档与会话历史建成可检索的本地库
3
把「先检索」写进常驻指令 — 索引管取件、指令管动作，缺一半收益落不下来
4
给索引定新鲜度规则 — 编辑与切分支之后由谁重建、多久一次，这条必须写出来
原理 · 为什么有效
模型翻文件的方式是「猜关键词、再重试」——它没有索引可查，只能一次次试，试错的成本就是工具调用。索引把这件事从「反复猜」变成「一次查」，省下的正是调用次数与随之而来的令牌。但索引只在被使用的时候才存在：如果常驻指令里没有一句「先检索再动手」，模型仍然会走它习惯的老路。所以这两半是乘法关系，不是加法 —— 任一半为零，收益就是零。而新鲜度是索引自带的代价：精确搜索每次都读当前文件，永远不过期；索引快，但必须有人负责重建。
适用场景
适用：代码库大到自己都记不住、或 agent 每次都要重新摸索的项目；也适用于文档库、变更历史、历史会话这类「同一份内容被反复取用」的场景。不适用：项目很小（几百行以内）、改动频繁到索引永远追不上、或你要找的本来就是当前分支的最新文件（那时精确搜索更快也更准）。
自测 · 5 问
改动之前先记下了「工具调用次数」这个基线数字，而不是只凭感受
索引覆盖的范围写得出来：哪些目录、哪些类型（代码 / 文档 / 变更 / 会话）
常驻指令里有一句明确的「先检索，再决定要不要翻文件」
写清了重建触发条件：改完之后、切分支之后、还是每天一次
保留了一条退路：索引没命中时允许回到精确文本搜索，而不是硬让它查索引
怎么上手 · 验证步骤
第一步只做「量」：在常驻指令里加一句「这次任务里，报告你用了几次工具调用」，跑三个你熟悉的日常任务，把数字记下来 —— 没有这个基线，后面所有优化都是感觉。第二步建索引，范围先窄后宽：只索引你最常被问到的那个目录，跑一周看命中率。第三步才写指令：把「先检索」这句话放进每次会话都会读到的那个规则文件里，而不是放在某次对话里。
过一周后回看：如果工具调用次数没降、或你发现自己经常手动把文件内容贴给它，说明索引没被真用上 —— 先查常驻指令里那句话还在不在，再查索引上一次重建是什么时候。