当AI工具面对数万本地文件时，遍历效率极低。本文作者借鉴开源工具思路，用Python+SQLite自建轻量索引系统，仅三个文件实现秒级文件查询。分享如何绕过复杂集成陷阱，用简单方案解决AI工具链的本地数据瓶颈。

你有没有遇到过这种场景——你在用 Claude Code 或者 Codex 干活，想让 AI 帮你找一个文件：

“帮我看一下那个微信缴费的介绍材料。”

然后 AI 开始遍历文件夹。一等就是几十秒。有时候还找不到，因为文件太多它扫不过来。

我的 E 盘上有9 万多个文件。项目资料、介绍材料、产品文档……几年下来攒的。每次让 AI 找东西，它都得从头翻一遍，效率极低。

不是 AI 不够聪明，是它没有索引。

就像你去图书馆找书，但没有目录系统，只能一排一排书架自己翻——再聪明的图书管理员也扛不住。

所以我花了一天时间，做了个 3 个文件的索引系统。现在 AI 找文件，秒级响应。

这篇文章聊聊整个过程——不是从零开始的，是借鉴了一个开源工具的理念，绕开它的坑，自建了一个轻量版本。

一、痛点：9 万 + 文件，AI 再聪明也扛不住

先说清楚问题出在哪。

Claude Code、Codex 这类工具的能力很强，但有一个前提：它能”看到”你的文件。文件少的时候没问题，但如果你的工作目录下有几千几万个文件，让它全扫一遍再回答，就很慢了。

更麻烦的是，我的文件分布在 E 盘不同目录下。不是每个目录都会用到，但 AI 不知道哪些是常用的、哪些是不用管的。每次找东西，它只能一把梭——全盘扫。

核心矛盾就是这样：AI 的能力在指数增长，但本地文件的组织方式还停留在 DOS 时代。

认知破壁：AI 的”聪明”建立在”看得见”的基础上。文件太多，它根本看不过来。

二、调研：选了一圈，最后借鉴思路自己搭

发现问题之后，我的第一反应不是写代码，而是先看看市场上有什么现成的方案。

尝试过的方向

• 知识关联系统。Obsidian 的双向链接、Zettelkasten 卡片盒法、Logseq 的块级引用……理念很好，但太重了。我不是要建一个知识库，我只是想让 AI 快速找到文件。
• DocGraph。这是最接近我需求的方案——专为文档设计，支持 40+ 文件格式，离线嵌入，提供 MCP 接口让 AI 直接查询。但安装时卡在了 better-sqlite3 的编译依赖上，来回试了好几种方式都装不上。
• Cortex。功能更强，有 LLM 自动提取实体关系。但需要持续付 API 费用，而且偏代码场景，对我的文档用途不太匹配。
• Graphify。GitHub 5.5 万 Star，很火。但核心价值在代码 AST 解析，对文档无效，也没有 MCP 查询接口。

一圈下来，情况很清晰：DocGraph 的思路是最对路的，但它的编译依赖我搞不定。

那就换条路——思路用它的，实现自己写。

认知破壁：最合适的工具不是”最先进”的那个，是能解决你当前问题、同时你搞得定的那个。

三、落地：3 个文件，搞定 9 万+ 文件索引

思路一旦定了，实现其实不复杂。核心逻辑

一句话就能说清楚：os.walk() 扫一次目录，把文件名、路径、大小、时间这些元数据存到 SQLite 数据库。以后查询直接搜数据库，不再遍历文件系统。

就这么简单。

首次扫描目标目录（不是全盘扫，只扫你关心的那个目录），花了十几秒，索引了 790 个文件、156 个目录。之后所有查询，毫秒级。最终只有 3 个文件

file-indexer/
├── find.py ← 查询脚本（一次写好，永久使用）
├── file-index.db ← SQLite 索引数据库（定期更新）
└── 卸载指南.md ← 不需要时怎么删

零外部依赖。find.py 只用了 Python 标准库——sqlite3、os、sys、datetime。不需要 pip install 任何包。

源文件零改动。整个索引过程只读不写，不碰你原来的文件。

查询速度。实际测了几次：

对比传统方式：不用索引时每次几十秒，走索引后几毫秒。MCP 这条弯路

中间还试了走 MCP 集成——想让 AI 直接调工具，不用手动执行脚本。结果 VS Code 扩展的 MCP 配置在调试过程中变了 3 个版本，配置机制也变了。折腾一番后决定放弃，直接走 Python 脚本。

这里有个教训：不要过度追求”高级集成”。简单方案先用起来，比折腾半天的完美方案实在得多。

认知破壁：三个文件解决的问题，很多时候不需要九个 MCP 工具。

四、几个可以带走的方法论

回头看这件事，有几个思路可以复用。

① 先调研市场，再决定做不做。

我花了不少时间看 DocGraph、Cortex、Graphify、Obsidian……虽然最后没直接用上它们，但调研让我知道了”这个问题别人是怎么解决的”。没有这个调研过程，我可能会走很多弯路——比如一上来就写代码，或者一上来就追求”最先进”的方案。

② 安装失败三次就换方案。

DocGraph 装不上，我试了 standalone 安装器、npm overrides、网络代理……折腾了挺久。但如果一开始就设个规则——”三次装不上就换方案”——能省不少时间。

③ 简单方案 > 完美方案。

3 个文件比 9 个 MCP 工具实用。不是因为工具不好，而是因为”能用起来的方案”比”躺在 GitHub 上的方案”价值高 100 倍。

④ AI 工具链的”最后一公里”往往是本地数据。

Claude Code 能力再强，如果它找不到你的文件，一切白搭。AI 的能力上限很高，但本地数据的组织方式决定了它的实际效率。

AI 的能力是上限，本地数据的组织方式决定了它的实际效率。

如果你也在用 Claude Code 或 Codex，而且本地文件多到 AI 找东西费劲，这个思路可以直接上手——一个 Python 脚本 + SQLite，不需要装任何额外工具。