本地文档管理索引（本地资料库搜索支援系统）

真正想做的，是一个可以本地部署的资料库搜索支援系统。

它不是一个单纯的全文搜索工具，也不是一个只会聊天的 AI。它更像是一个围绕本地资料库工作的 AI 阅读、检索和调查工具。

用户可以把本地文档、项目代码、笔记、PDF、Word、Markdown 等资料加入一个资料库，然后用自然语言提问。区别是：资料不上传云端，索引和 AI 推理都尽量在本地完成。

所以，这个项目的第一目标可以很明确：

做一个本地资料库搜索支援系统。

在这个基础上，再逐步加入更适合个人工程和本地项目管理的能力。比如根据用户输入的问题，在现有工程里的文档、代码、SQL、配置和接口说明中搜索相关内容，最后输出命中的文件、位置和相关上下文。

简单说，它要解决的是这个问题：

用户用自然语言提问，系统能在本地资料库里找到真实依据。

例如用户问：

归档状态影响哪里？

普通全文搜索只能搜索“归档”两个字。如果代码里实际叫 archive_flag、storage_status 或 ArchiveService，就很容易漏掉。

本地 AI 的价值就在这里：它负责把人的模糊问题，翻译成资料库和项目里真实存在的关键词。

核心目标

这个系统应该做到几件事：

• 管理多个本地资料库。
• 读取本地文档、笔记和项目代码。
• 自动建立资料词典和项目词典。
• 根据用户问题生成搜索关键词。
• 通过本地索引检索真实文件。
• 输出命中的文件、行号和上下文。
• 基于真实结果整理出处和相关片段。

第一阶段先做好资料导入、摘要、引用、问答。

第二阶段再增强为工程资料搜索支援系统：把代码、SQL、配置、API 文档也纳入索引，让它能辅助用户查找“这个字段在哪里出现”“这个接口在哪些文档里提到”“相关内容分散在哪些文件中”。

这里的重点不是让 AI 凭空回答，而是让 AI 站在真实搜索结果上做整理。

也就是说：

AI 负责理解问题
索引系统负责提供事实
AI 负责整理出处

只要这个边界守住，系统就会比单纯问 AI “这个功能影响哪里”可靠很多。

明确不做的范围

这个项目不是 AI 智能分析系统。

它的定位应该是：

本地搜索支援系统。

它负责帮助用户从本地资料库中找到出处、内容和上下文，但不替用户做判断。

明确不做：

• 不判断某个设计是否正确。
• 不判断某段代码是否一定有问题。
• 不判断某个功能的最终影响范围。
• 不承诺 AI 能完整理解整个项目。
• 不输出没有出处支撑的结论。
• 不把检索结果包装成确定性的决策建议。
• 不做复杂知识图谱和自动深度推理。
• 不做音频概要、多模态理解等高风险功能。

优先做好：

• 帮用户找到相关文件。
• 帮用户找到关键字所在位置。
• 展示命中的原文片段。
• 提供文件路径、行号、章节和上下文。
• 把分散的命中结果整理到一起。
• 让用户自己基于出处做判断。

也就是说，系统只做辅助索引和资料定位。

它有点像我平时写的 PowerShell 搜索脚本。

区别在于，PowerShell 脚本通常需要用户自己决定搜索目录、文件类型、关键字和输出格式。用户要先想清楚应该搜什么，再手动执行脚本，最后自己把结果整理出来。

这个系统要做的，是把这些搜索整理步骤包起来。用户可能只说一句话，系统就自动完成：

理解用户想找什么
↓
扩展可能相关的关键词
↓
搜索代码和文档
↓
整理命中的文件、位置和片段
↓
把结果交还给用户确认

最终给用户的，可能不是一个“AI 判断结论”，而是一份代码和文档的搜索结果。

它的优点是：用户不用自己反复换关键字、切目录、跑脚本、复制片段。用户只需要提出一个自然语言问题，系统就帮他完成搜索和整理的步骤。

它可以说：

这些文件里出现了相关内容。
这些片段可能和你的问题有关。
这是原文出处。

但它不应该说：

结论一定是这样。
你必须这样改。
这个功能一定影响这些地方。

这条边界非常重要。它会让项目从“很难做准的 AI 分析系统”，变成“可落地、可验证、可长期使用的本地搜索支援系统”。

产品形态：参考资料库问答产品

产品形态可以参考成熟资料库问答产品的信息架构，但界面、品牌、命名和视觉设计都应该保持独立。

基础界面可以分成三块：

• 左侧是资料源列表。
• 中间是聊天问答区域。
• 右侧是资料摘要、引用内容和文档片段。

用户打开一个 notebook，就能看到当前资料库中有哪些文件。提问以后，AI 的回答必须带引用来源，用户可以继续点回原文查看上下文。

这个产品外壳很重要。它决定了用户不是在面对一个普通搜索框，而是在面对一个围绕资料库工作的 AI 助手。

后续可以支持多个 notebook 或 project。每个 notebook 有自己的资料源、索引、聊天历史和项目词典。

这样产品主线就更清楚：

第一层：做好资料库和问答体验
第二层：本地化资料索引和本地 AI 推理
第三层：加入代码和工程资料检索

不是训练模型，而是建立资料词典

“让 AI 理解资料库”听起来很大，但第一步不需要训练模型。

更现实的方式是先扫描资料源，自动抽取一层资料词典。对于普通文档，它抽取标题、段落主题、专有名词和常用表达；对于工程项目，它再额外抽取类名、函数名、字段名、表名、API 路径和模块名。

例如：

业务词：用户状态、归档、入库、退会、承认
代码词：user_status, archive_flag, import_task, approve_status
文档词：有効/無効、取込、保存先、重複判定
模块词：ImportService、ArchiveService、DedupTask
接口词：/api/import, /api/archive, /api/duplicates
数据库词：photo_status, archived_at, storage_status

有了这层词典以后，用户再问文档问题或者工程问题，AI 都能把自然语言转换成更贴近资料库的关键词。

例如在工程资料库里，用户问：

归档状态影响哪里？

AI 就不是凭空猜关键词，而是结合资料词典和项目词典扩展搜索计划：

archive
archive_flag
archived_at
ArchiveService
photo_status
storage_status
归档
归库
保存先
取込後処理

这样检索准确率会高很多。

最现实的三步流程

这个系统最小可行版本可以分成三步。

第一步，扫描资料库，生成资料词典。

系统读取 notebook 中的 Markdown、Word、PDF、TXT、代码、SQL、配置文件和接口说明。普通文档先抽取标题、段落、关键词和摘要；工程资料再抽取类名、函数名、字段名、表名、API 路径和常用业务词。

第二步，用户提问，AI 生成搜索计划。

用户输入的是自然语言，例如“这份资料主要讲什么”，或者“增加归档状态会影响哪里”。AI 根据资料词典，把这个问题转换成一组关键词、文件类型和优先搜索范围。

第三步，本地索引搜索，输出命中结果和出处整理。

索引系统负责搜索真实文件，并返回文件路径、行号、片段和匹配原因。AI 再把这些结果整理成用户更容易阅读的出处列表。

用户问题
↓
AI 生成搜索计划
↓
本地索引检索
↓
返回真实命中
↓
AI 整理出处和片段

这个流程里，AI 不直接编造结论。它只能基于搜索结果做归类和整理。

系统分层

这个本地资料库搜索支援系统可以分成三层。

第一层：本地资料索引库

这是最重要的一层，甚至比 AI 更重要。

索引库需要统一管理这些内容：

• 代码文件
• Markdown 文档
• PDF、Word、TXT 等文档
• SQL 文件
• 配置文件
• API 文档
• 数据库结构说明

索引时至少要保存：

• 文件路径
• 文件类型
• 标题或模块名
• 行号或段落位置
• 原始文本片段
• 抽取出的关键词
• 更新时间和文件哈希

如果这一层不可靠，AI 再聪明也没有用。

第二层：AI 意图转换

AI 主要负责把用户问题转换成搜索计划。普通文档问题可以转换成语义检索计划，工程问题可以进一步转换成关键词和符号检索计划。

例如用户问：

增加归档状态会影响哪里？

AI 输出的不是最终答案，而是一份搜索计划：

核心关键词：
archive
archive_flag
archived_at
归档

扩展关键词：
ArchiveService
photo_status
storage_status
保存先
取込後処理

优先范围：
代码
SQL
API 文档
业务说明文档

这样系统就从“问 AI 答案”变成了“让 AI 指挥本地搜索”。

第三层：引用回答和出处整理

搜索完成后，AI 根据真实结果整理回答。普通资料库里，它输出带引用的问答和摘要；工程资料库里，它输出相关文件、命中片段和需要用户自行确认的内容。

结果可以按资料类型输出：

搜索结果整理

1. 代码命中
   - 命中的服务类
   - 命中的函数
   - 命中的接口

2. 文档命中
   - 命中的设计文档
   - 命中的业务说明
   - 命中的运维说明

3. 数据库命中
   - 命中的表
   - 命中的字段
   - 可能相关的状态值

4. 需要用户确认
   - 命中较少但语义相关的内容
   - 名称不一致的字段
   - 可能存在遗漏的模块

最终用户看到的不只是“可能相关”，而是可以点击或打开的真实文件和真实内容。这一点也是资料库问答体验里最重要的部分：回答必须能回到来源。

文档和代码要一起处理

如果只做第一阶段的资料库问答，这个系统可以先只处理文档。

但我真正想要的本地系统，不应该永远停留在文档层面。

现实工程里，很多重要信息分散在不同地方：

• 业务意图在 Markdown 或 Word 里。
• 实际逻辑在代码里。
• 状态字段在数据库或 SQL 里。
• 接口行为在 API 文档里。
• 运行差异在配置文件里。

所以第二阶段的索引对象应该同时包含文档和代码。

文档侧更适合做语义检索。代码侧更适合做精确关键词、符号和引用关系检索。两者结合起来，才更像一个真正的本地搜索支援系统。

第一阶段：先做本地文档检索

本地资料库搜索支援系统的第一层难度，是文档检索。

可以先支持：

PDF
Word
Markdown
TXT

导入流程可以是：

读取文件
↓
提取文本
↓
切块
↓
生成 Embedding
↓
写入向量数据库
↓
用户提问
↓
RAG 检索和回答

这一部分现在已经有很多成熟开源方案：

• Ollama
• Qdrant
• Chroma
• FAISS

这一阶段的目标不是分析代码，而是先把文档问答跑通。

第二阶段：加入代码和工程词典

第二阶段要从“文档问答”升级成“工程调查”。

这时需要扫描代码并抽取：

• 文件路径
• 类名
• 函数名
• 变量名
• 表名
• 字段名
• API 路径
• 注释
• 配置 key

同时生成项目词典，把业务词、代码词、文档词连接起来。

例如：

归档
↕
archive_flag
↕
ArchiveService
↕
PhotoEntity
↕
storage_status

这一层不需要做成复杂关系系统。可以先用词典和同现关系实现，也就是哪些词经常出现在同一个文件、同一个段落或同一个模块里。

第三阶段：补充项目词典关系

最大的风险不是 AI，而是关键词搜索容易漏。

例如用户问“归档”，但代码里真正使用的是 storage_status。如果系统不知道二者有关，就搜不到关键内容。

所以未来比较有价值的，不是复杂知识图谱，而是可维护的项目词典关系。

它可以逐渐记录：

• 业务词和代码词的对应关系
• 文档章节和代码模块的对应关系
• API 和服务类的对应关系
• 数据库字段和页面功能的对应关系
• 历史问题和相关文件的对应关系

这些关系不需要做成复杂的自动推理系统。它们更像是搜索辅助词典，可以随着每次使用不断补充。

例如每次用户确认“storage_status 其实就是归档状态的一种实现”，系统就把这个关系记录下来。下一次再问“归档”，就能自动扩展到 storage_status。

和 ZeroTraceBrowser 的相似性

这个项目和 ZeroTraceBrowser 有很强的相似性。

ZeroTraceBrowser 的核心流程是：

照片
↓
索引
↓
查找

项目调查助手的核心流程是：

代码 + 文档
↓
索引
↓
查找

本质上都是把分散的信息统一入库，然后快速定位。

照片管理解决的是“我有很多照片，怎么找到和整理它们”。本地搜索支援系统解决的是“我有很多代码和文档，怎么找到相关内容和出处”。

所以它不是凭空冒出来的新方向，而是同一种思想在工程知识管理上的延伸。

最小可行版本

如果要真正开始做，我觉得可以先做一个很小的版本。这个版本应该优先验证资料库问答和出处引用的基本体验，而不是一开始就把工程分析全部做完。

第一版只需要支持：

• 创建一个本地 notebook。
• 添加 Markdown、TXT，后续再加入 PDF 和 Word。
• 抽取标题、段落、关键词和摘要。
• 建立 SQLite 索引。
• 用户输入问题后，由本地 AI 生成检索计划。
• 用关键词检索或简单语义检索命中资料。
• 输出回答、引用来源、文件路径和命中片段。

第一版可以先不做复杂关系图，也可以先用 SQLite 和关键词检索把体验跑通。向量库可以作为下一步增强。

真正重要的是先把这条链路跑通：

用户问题
↓
关键词计划
↓
本地真实命中
↓
带引用的回答

只要这条链路跑通，它就已经不是一个普通搜索框，而是一个本地资料库搜索支援系统的雏形。后面再加入代码和工程词典，它才会进一步长成本地工程资料搜索支援系统。

结论

这个系统的核心价值不是“AI 替我凭空总结一切”。

更准确地说，是：

AI 把人的模糊问题翻译成资料库里的真实检索计划，索引系统找到真实证据，AI 再把证据整理成带引用的回答。

这个边界很重要。

AI 不负责凭空判断事实，事实必须来自本地索引。AI 负责的是理解用户问题、扩展检索关键词、整理命中片段和表达出处关系。

所以，产品主线应该先定成：做一个本地资料库搜索支援系统。

在这个主线跑通以后，再把文档、代码、SQL、配置和 API 都纳入同一个本地索引，逐步建立资料词典和项目词典。这样它就会慢慢变成真正适合个人和小团队使用的本地搜索支援系统。