乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > 让 AI 读懂企业内部文档:我做了一个本地优先的文档知识图谱工具 DocGraph

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

当前时间： 2026-08-13 16:40:42 分类：办公文件 评论(0)
让 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