9.6 万 Star!这个仓库把代码、文档和 PDF 串成图谱,AI 才不容易答偏

接手一个旧项目时，后端接口写在 Python 里，表结构散在 SQL schema，部署参数在配置文件，业务规则又藏在 PDF 文档里。你让 AI 查“某个字段从哪里来、会影响哪些接口”，它可能每个文件都读到了，但把调用链、依赖关系和规则来源串错。graphify-labs/graphify（https://github.com/graphify-labs/graphify）解决的就是这类问题：先把代码、文档、SQL schema、配置和 PDF 整理成可查询的知识图谱，再让 AI 基于关系去问。

按公开材料看，v8 版本有 96374 Stars、9336 Forks、660 个 open issues，语言是 Python，许可证是 Apache-2.0。

它的定位很明确：把任意 codebase 连同 docs、SQL schemas、configs、PDFs 变成可查询的知识图谱，配合 Claude Code、Cursor、Codex、Gemini CLI 使用。README 里强调的是 本地、确定性的 AST 解析，并且尽量把每条边解释清楚，不靠向量库。

Graphify 更像关系层工具，不是单纯的问答层工具。代码部分先用 tree-sitter 做 AST 解析，再把节点和边组织成图。README 也写得很直接：代码解析走 deterministic 路径，nothing leaves your machine。在追调用链、规则来源、跨文件依赖时，它先拿到结构关系，再处理语义问题。

边界也要分清。代码是本地结构解析，docs、PDF、图片、视频则会走语义通道，可能用到助手模型或你配置的 API key。也就是说，它对“代码关系”这条线很强，但不承诺所有输入都用同一种纯本地无模型方式处理。

README 给的安装方式很直接，装完就能在支持的 AI 编程环境里调用 /graphify。

然后在支持的助手里直接用：

它支持的环境包括 Claude Code、Cursor、Codex、Gemini CLI、GitHub Copilot，以及 15+ 其他平台。README 的意思很明确：不是换一个搜索框，而是先把项目映射成知识图谱，再去查询。

公开材料里能确认的边界有几条。

第一，它不是把所有文件都塞进同一种向量检索流程里，而是把代码解析和语义材料处理分开。

第二，公开信息里 open issues 是 660，热度不低，也说明不能只看 README 就默认它在所有项目里都能稳定覆盖。

第三，它把“边都尽量解释清楚”当成设计目标，这对排查问题有帮助；但公开材料没有把大仓库表现、完整评测和部署成本展开得很细。

如果拿 patchy631/ai-engineering-hub（https://github.com/patchy631/ai-engineering-hub，36702 stars）和 NirDiamant/GenAI_Agents（https://github.com/NirDiamant/GenAI_Agents，23496 stars）对照，Graphify 的位置更偏底层。前两者更像教程和案例集合，适合学习 AI 应用的构建方式；Graphify 更像先把项目级资料结构化、关系化的基础设施。

这个区别很关键。教程仓库主要回答“怎么做 RAG、怎么做 agent”；Graphify 面向的是混着代码、文档、schema、配置和 PDF 的真实仓库，先把这些材料之间的关系铺出来，再让 AI 基于图谱回答问题。

项目地址：https://github.com/graphify-labs/graphify

我是 Alten，持续分享 AI 工程化观察与干货，这里记录从论文、开源项目到工程系统的拆解。