文档平台 Mintlify 发了一篇工程博客，讲了一件挺有意思的事

剑澜

文档平台 Mintlify 发了一篇工程博客，讲了一件挺有意思的事：他们给自家 AI 文档助手造了一套假的文件系统，叫 ChromaFs，让 AI 以为自己在用 grep、cat、ls 这些命令浏览文件，实际上每个命令都被拦截、翻译成了数据库查询。

效果很直接：会话启动时间从原来沙箱方案的 46 秒降到 100 毫秒，每次对话的边际计算成本几乎为零。

Mintlify 之前的方案是标准的 RAG 流程：把文档切块、向量化、存进 Chroma 数据库，用户提问时检索最相关的片段喂给大模型。问题是，如果答案分散在好几个页面里，或者用户要的是某段精确的代码语法，向量检索经常找不对。

他们想让 AI 像开发者翻代码一样翻文档，而不是靠语义相似度碰运气。

核心思路是：AI 不需要真的操作系统，只需要一个足够逼真的幻觉。

ChromaFs 基于 Vercel Labs 的开源项目 just-bash（一个用 TypeScript 重写的 bash 子集）构建。just-bash 提供了可插拔的文件系统接口，负责解析命令和管道逻辑，ChromaFs 则把所有底层文件操作翻译成 Chroma 数据库查询。每个文档页面变成一个"文件"，每个章节变成一个"目录"，AI 就可以用 grep 搜精确字符串、用 cat 读整页内容、用 find 遍历结构。

之前用真沙箱的方案（给每个用户起一个微型虚拟机），按 Mintlify 月均 85 万次对话的量算，一年光计算成本就要 7 万美元以上。ChromaFs 复用了已有的数据库基础设施，这笔钱省了。

grep 是最难虚拟化的命令。如果真让它逐文件扫描，走网络 IO 会很慢。ChromaFs 的做法是先把 grep 的参数解析出来，用 Chroma 的元数据查询做粗筛，找出可能命中的文件批量预取到缓存里，再让 just-bash 在内存中做精确匹配。

权限控制也很优雅：初始化时根据用户身份裁剪文件树，没权限的路径直接从树里删掉，AI 连路径都看不到，不存在越权风险。

所有写操作一律返回"只读文件系统"错误，AI 能随便看但改不了任何东西，整个系统无状态，不用担心清理和数据污染。

这篇文章在 Hacker News 上引发了一个有意思的讨论。好几位开发者指出，大家不知不觉中把 RAG（检索增强生成）等同于了向量搜索，但 RAG 里的 R 是 Retrieval（检索），本来可以是任何方式：全文搜索、SQL 查询、甚至翻电话簿。把 RAG 绑死在向量数据库上，是早期技术路径的惯性。

有人解释了这种惯性的由来：RAG 概念流行的时候，大模型还不太会用工具，多轮搜索和纠错能力也差，向量检索是当时最省事的方案。现在模型的工具调用和推理能力上来了，让 AI 自己决定用什么方式找信息，反而比预设一条检索管道更灵活。

也有人提出了务实的质疑：Mintlify 的场景是结构化的技术文档，天然适合文件系统隐喻，但如果是组织内部那种乱七八糟、没有层级结构的知识库，这套方案未必好使。

这个方向和 Claude Code 的做法有相通之处：与其把所有信息预检索好喂给模型，不如给模型一套探索工具，让它自己决定看什么、怎么找。对于正在搭建 AI 文档助手或内部知识库的开发者来说，Mintlify 的这套方案提供了一个向量检索之外的选项，尤其适合文档结构清晰、对精确匹配要求高的场景。