让 AI 读懂企业内部文档:我做了一个本地优先的文档知识图谱工具 DocGraph

大家好，这里是代码深处。最近我在做一个小工具：DocGraph。

它想解决一个很具体的问题：企业内部有很多文档，但 AI 用不上。

研发文档在 Git 仓库里，接口定义在 OpenAPI 里，产品说明在文档中心里，历史方案在 Confluence 里，部署手册可能是一个内部网页，老系统资料甚至还在 SFTP 或本地目录里。

人找这些东西已经很麻烦，AI 更麻烦。它不知道去哪找，不知道哪份文档是最新的，也不知道一个接口、一个模块、一篇方案之间有什么关系。

所以很多时候，我们用 AI 写代码、排查问题、理解系统，最后还是要手动复制一大段上下文给它。复制少了，它猜；复制多了，又乱。

DocGraph 想做的事情很简单：

把企业内部散落的文档接进来，放在本地索引起来，让 AI 可以自己查。

项目地址：

https://github.com/gwork1883/docgraph

为什么做这个

我自己在用 AI 辅助开发时，经常遇到一个问题：

AI 很聪明，但它不了解公司内部系统。

比如你问它：

>某个接口 401，是业务 token 问题，还是网关配置问题？

真正有用的信息可能分散在好几个地方：接口文档、鉴权说明、网关文档、历史排障记录、部署手册、代码仓库里的 README。

如果没有统一入口，AI 只能靠你手动投喂。每次问复杂一点的问题，都像是在重新帮它补课。

现在常见有两种做法。

一种是给每个项目写 skill。这个方式很有效，适合把项目结构、常见命令、排查流程告诉 AI。但项目一多，skill 会越来越多，而且它更像“经验规则”，不太适合承载大量经常变化的文档内容。

另一种是搭一个知识库。把各种内部文档统一接入，让 AI 在需要时自己检索上下文。

DocGraph 走的是第二条路。

它并不是要替代 skill。更合理的方式是：skill 负责告诉 AI 怎么做事，DocGraph 负责告诉 AI 去哪里找事实依据。

它能做什么

DocGraph 是一个本地优先的文档知识工具。

你可以把这些内容接进去：

本地目录里的 Markdown、文本、HTML 文档
Git 仓库里的项目文档
Confluence 页面
OpenAPI 接口定义
静态 HTML 文档
SFTP 目录
内部或外部网页文档中心

接入后，DocGraph 会把它们统一索引到本地 SQLite。你可以在 Web UI 里搜索，也可以通过 MCP 让 AI agent 调用。

它的重点不是做一个大而全的文档平台，而是做一个更适合 AI 使用的本地知识入口。

几个我比较在意的点：

数据默认留在本机或内网，不需要上传到外部 SaaS。
一个二进制文件就能跑，部署成本低。
支持 Web UI，普通使用不需要先理解一堆命令。
支持 MCP，能直接给 AI agent 当工具。
适合企业内部中英文混合、格式不统一的文档场景。

上手很简单

我希望 DocGraph 不是一个“看起来很强，但跑起来很重”的工具。

正常试用大概就四步。

第一步，到 GitHub Release 页面下载对应系统的二进制文件。

Release 地址：

https://github.com/gwork1883/docgraph/releases

第二步，初始化并启动 DocGraph。

解压后执行一次`docgraph init`初始化数据目录，再执行`docgraph serve`启动服务。浏览器打开http://127.0.0.1:8787，就能看到 Web UI。

第三步，在页面里连接你的文档来源。

可以先从最简单的本地目录开始，比如团队项目里的docs目录，或者一个内部文档导出的 HTML 目录。后面再逐步接 Git 仓库、Confluence、OpenAPI、网页文档中心。

第四步，把 DocGraph 接到支持 MCP 的 AI 客户端里。

README 里有 MCP 配置示例。接好之后，AI 在回答问题、写代码、排查问题时，就可以通过 DocGraph 搜索内部文档，而不是完全依赖你手动复制上下文。

你也可以先不接 MCP，直接把它当成本地文档搜索工具用。先把文档连起来、搜起来，价值就已经能看出来。

一个实际例子

假设新人接手一个支付系统，问：

>退款接口怎么鉴权？

在没有 DocGraph 的情况下，他可能要问同事：

退款接口文档在哪？
鉴权说明在哪？
网关有没有单独配置？
以前有没有兼容老 token 的逻辑？
哪份文档是最新的？

这些问题未必难，但很耗时间。

如果这些资料已经接入 DocGraph，AI 可以先围绕“退款接口”“鉴权”“支付系统”检索相关文档，再基于命中的内容整理答案。

这时 AI 的回答不再只是通用经验，而是更接近企业内部真实上下文。

为什么这件事对企业内部 AI 很重要

很多企业现在都在试 AI 编程、AI 排障、AI 问答、AI 助手。

但真正落地时，经常卡在同一个地方：模型不缺，内部上下文缺。

企业内部不是没有知识，而是知识太分散：

每个团队有自己的文档习惯。
每个系统有自己的文档入口。
新老项目格式不一样。
有些文档只能在内网访问。
有些资料只适合本地使用，不适合上传到外部平台。

这时单纯换更强的模型，效果提升是有限的。AI 要真正帮上忙，必须能看到企业内部可靠的资料。

DocGraph 的定位就是这个中间层：把文档留在本地或内网，把入口统一起来，再通过 Web UI 和 MCP 提供给人和 AI。

现在还不完美

这个项目还在早期阶段，我也不想把它包装成一个已经成熟的企业知识平台。

目前它更适合：

个人开发者本地试用
小团队内部文档整理
给 AI agent 补充企业内部上下文
验证 MCP + 本地知识库的工作流

还有不少事情需要继续做。

比如，不同企业的登录、SSO、Cookie、零信任网关都不一样，连接器还需要持续适配。

再比如，文档之间的关系还可以做得更强。一个接口影响哪些模块，一个配置关联哪些服务，一个报错可能对应哪些历史问题，这些都值得继续增强。

另外，团队共享时的权限、密钥管理、审计、同步调度，也还需要更完整的方案。

后面想做什么

后续我会重点做几件事：

继续增强连接器，覆盖更多内部文档来源。
优化中文和中英文混合文档的检索效果。
让 MCP 使用体验更顺，减少配置成本。
增强文档关系和影响分析能力。
做更适合团队内部部署的权限和同步机制。

我希望它最后能成为企业内部 AI 的一个基础组件：不抢模型的工作，也不取代现有文档系统，而是让已有文档更容易被 AI 使用。

最后

DocGraph 的初衷很朴素：

让 AI 少猜一点，多查一点。

如果你也在尝试把 AI 用到企业内部研发、排障、文档检索、代码理解或本地 agent 场景里，可以试试这个项目。

项目地址：https://github.com/gwork1883/docgraph