打开你的文件管理器，随便翻翻。
合同、报告、论文、方案、发票、电子书、笔记、备忘、会议纪要 —— 这些是你电脑上最有价值的文件。它们记录了你的工作成果、你的知识积累、你的商业往来。
现在问你自己一个问题：你的 AI 助手，能读到它们吗？放心上传吗？
答案是：不能。
资源管理器、Spotlight、Raycast... 只能搜文件名。Linux 中的 grep 无法读取 PDF 和 Word 的二进制格式。Claude、ChatGPT、Cursor——它们对你电脑上的这些非代码文档一无所知。
代码已经被充分索引了。IDE 有搜索，grep 能精确到行，Claude Code 用 Glob+Grep+Read 三板斧就能把整个代码库翻个底朝天。但你的文档呢？它们似乎成了 AI 时代的"暗物质"——存在，却不可见。
有很多 AI 知识库试图去挖掘这些内容，但至今都不够好。
我们做了一个工具来解决这个问题。这篇文章讲讲我们为什么做它、怎么做的、以及踩了哪些坑。
我们正处在一个奇怪的断裂点上。
一边是 AI 能力的爆炸式增长。Claude 能写代码、分析数据、总结文献、起草方案。另一边是你电脑上那几百个 PDF、几十个 Word 文档，AI 很难够的着。
几十个文档我们还可以上传到这些 AI 中，几百上千个文档将无能为力。
你可以问 ChatGPT 任何通用问题，它对答如流。但你问它"我上个月那份项目方案里关于技术选型的部分写了什么"，它只能说：抱歉，我无法访问你的本地文件。
这不是 AI 的问题，是基础设施的问题。AI 已经足够聪明了，但它缺少一种“连接“去看你存在各处的笔记文档的方式，尤其是本地的文档。
而这些文档恰恰是最有价值的上下文。通用知识，AI 本来就知道。真正能让 AI 帮到你的，是它了解你的具体情况——你的合同条款、你的项目背景、你的研究资料。
你可能听说过 RAG（Retrieval-Augmented Generation）。过去两年，几乎所有"让 AI 读你的文档"的方案都是基于 RAG 的。
RAG 的工作方式是这样的：把文档切成小块（chunk），对每个 chunk 做 Embedding 向量化，存到向量数据库里。用户提问时，先用向量搜索找到最相关的几个 chunk，把它们塞进 AI 的 prompt 里。
听起来很合理。问题在哪？
AI 拿到的是预先嚼碎的碎片。
它不知道这个碎片来自文档的哪个部分，不知道前后文是什么，不知道整个文档的结构。如果碎片不够用，它也没办法"再多看一点"。
当然有很多补丁技术可以解决这些问题，但通常会带来更多问题，比如成本上涨、性能下降，架构复杂带来的效果不稳定等问题。
这就像你让一个研究员帮你分析一份报告，但你不给他报告原文，而是给了他 5 张从报告里随机撕下来的纸条。
实际体验是什么样的？AI 的回答似是而非，经常答非所问，有时候明明文档里有答案，但因为切片策略不好，相关内容被切成了两个 chunk，向量搜索只匹配到了其中一个，答案就这么丢了。
我们在去年花了几个月搭了一套完整的 RAG 管线——三阶段处理（Extract、Chunk、Embed），三种搜索策略（Vector、BM25、Hybrid + Reranking），基于此开发过一版。
技术上很漂亮。但最终我们不得不承认一个事实：效果不够好。
转折点来自去年的一个共识：LLM 仅使用少量的检索命令就可以自动完成复杂检索任务。
Claude Code 不用 RAG。它用三个简单的工具：Glob（按模式找文件）、Grep（搜索关键词）、Read（读取文件内容）。
它的工作方式不是"搜索引擎返回碎片"，而是像一个研究员翻阅文件柜——先看目录找到可能相关的文件，打开看看目录结构，确定哪一章有用，然后精准地阅读那一部分。
这和人类的阅读方式完全一致。你不会把一本书撕成碎片再搜索，你会先找到一本感兴趣的书，看它的目录找到相关章节，然后翻到那一页去读。
但 glob 和 grep 只适用于代码。为什么？因为代码库有清晰的目录结构和命名规范，src/services/auth.ts 这个路径本身就在告诉你这是认证服务的代码。而你电脑上的文档呢？2024年度总结(修改版)(最终版)(真的最终版).docx——路径告诉你的信息约等于零。更别提 PDF 和 Word 是二进制格式，grep 根本读不了。
所以问题变成了：能不能给文档也建立一套类似代码库的“目录索引“，让 AI 用 search-browse-read 的方式渐进式地翻阅你的文件？
我们提出的方案叫 Outline Index。
核心思想很简单：为每个文档建立一张"AI 名片"。这张名片浓缩了文档的核心信息——这个文件是什么、讲了什么、结构是怎样的。
它不是文档的副本，不存储原文。它是一个导航工具。AI 通过它了解文档的全貌，然后决定要不要深入阅读原文。
这恰巧与 Agent Skills 的原理是类似的。SILL.md 通过元数据和简短的描述，让 AI 了解整个技能的全貌，再决定要不要用怎么用。
我们给每个文档创建了一个 Outline Index，它包含两部分：
Metadata：文件名、路径等元数据。让 AI 在搜索阶段就能快速"判断"文档是否相关。
Outline：根据文档类型生成不同的导航信息（结构大纲）。PDF ，Markdown 和 Word 提取章节标题、摘要、行号等信息。
关键设计是渐进式披露（Progressive Disclosure）：不用一次性把所有信息倒给 AI，而是让它按需逐层深入。
对比传统 RAG：RAG 一次返回 几十 个 chunk，几千上万个 tokens，杂乱的碎片信息反而有可能影响 AI 回答的质量。
Outline Index 方式更精准、更省 token、具备 Agentic 能力的 AI 完全有能力快速找到准确的哪些信息。
整个系统对外只暴露三个 MCP 工具：
就这三个。
举个例子。你在 Claude Code 里问："帮我找关于 Docker 部署的文档。"
search("Docker 部署") → 返回 5 个文件的 Metadata.env.example（文件很短）和 deployment-guide.pdf（长文档）read（几百字，读完了）outline 看结构 → 发现 "Docker Setup" 章节 → read 精确读取那一章传统 RAG 在同样的场景下返回 10 个预切碎片，4000-6000 tokens，AI 不知道上下文，也没法"再多看一点"。
更有趣的是涌现能力。三个原子工具组合起来，LLM 天然就会做这些事：
这些能力不需要我们开发任何 Agent 编排逻辑。LLM 天然就会组合工具来完成复杂任务。我们只需要提供好这三个原子工具。
Linkly AI 是一个后台常驻的工具。它应该像 Dropbox 一样：安装 → 选文件夹 → 忘记它。后台默默建索引，你该干嘛干嘛。
对于一个 24/7 后台运行的应用，体积和资源占用是生命线。用户会在活动监视器里看到内存占用。一个常驻后台的工具如果吃 150MB 内存，用户会毫不犹豫地退出它。
Linkly AI 的安装包仅 20MB 左右，自带完整的搜索引擎和文档解析能力，运行时内存占用约 50-100MB。它的设计目标是：轻量到你完全感觉不到它的存在。
渐进可用性设计也很重要：安装 1 分钟后，关键词搜索就可用了。语义搜索在完成索引后随后可用，用户无感。
你的文件不会离开你的电脑。
所有的文本提取、索引构建、搜索匹配都在本地完成。没有数据上传到云端，没有遥测，没有"匿名使用数据收集"。
Outline Index 存储在你的本地，提取的纯文本同样存储在本地文件系统中。
这不是一个商业策略上的选择（虽然隐私确实是差异化卖点），而是一个工程上的必然——文档搜索必须快，网络往返会破坏体验。本地混合检索的延迟通常是毫秒级的，这是任何云端方案做不到的。
通过 MCP 协议和 CLI 工具，Linkly AI 无缝集成到 Codex、Cursor、Claude Code 等 AI 工具中。未来我们将支持隧道功能，让云端 AI 也能安全地访问本地文档。
一行配置，你的 AI 助手就能"看到"你电脑上的文档了。不换入口，继续用你喜欢的 AI 工具。
Linkly AI 的定位很简单：Spotlight for AI。让 AI 能无摩擦的使用你电脑上的文档。
安装 → 选文件夹 → 忘记它。
后台默默建索引。然后你会发现，你的 Claude、你的 Cursor、你的 ChatGPT，突然能"看到"你电脑上那些 PDF、Word、笔记、电子书了。
不需要配置 API Key。不需要选择模型。不需要创建"知识库"。不需要理解什么是 RAG、什么是 Embedding。
你只需要告诉它你的文件在哪，剩下的交给Linkly AI。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。