GitHub 9.8 万 Star！把整个代码仓库变成知识图谱，这个 AI Coding 工具太适合 Claude Code / Codex 了

问 AI 编码助手"认证链路最后在哪里写数据库"，它往往先翻十几个文件；换成"这个函数影响哪些模块"，又得从头 grep 一轮。仓库一大，这些临时搜索很快就会挤满上下文，最后给出的调用关系还可能不准。

我今天看到的开源项目 Graphify，处理的就是这类问题。它会扫描目录里的代码、文档、SQL schema、脚本、图片和视频，把识别出的实体与关系存进一张可查询的知识图谱。Claude Code、Codex、Cursor、Gemini CLI 这类助手接入后，可以先从图谱定位相关节点和路径，再决定需要打开哪些文件。

项目地址是：github.com/safishamsi/...

截至我查看仓库页时，这个仓库已经有 约 9.8 万 GitHub Star 、9.5k Fork ，默认开发分支是 v8，页面上的最近提交信息已经到 chore(release): 0.9.29。

至少从发版节奏看，它不是那种 README 写得很热闹、代码半年没动的小工具。最近几个版本还在补 CodeBuddy、MCP HTTP、Azure OpenAI、PostgreSQL introspection、Apex 抽取这些集成能力。

先说怎么用。

官方包名有点容易踩坑，PyPI 上叫 graphifyy，两个 y，但命令仍然叫 graphify。

复制代码

uv tool install graphifyy
graphify install

装完之后，在支持的 AI 编码助手里跑：

bash 复制代码

/graphify .

如果是在 Codex 的 assistant 命令里，README 特别提醒要用 $graphify，不是 /graphify。Windows PowerShell 也别写 /graphify .，直接用 graphify .，因为开头的斜杠会被 PowerShell 当成路径。

跑完之后，项目里会多一个 graphify-out/ 目录，里面主要有 3 个东西：

graph.html：浏览器里看的交互式图。
GRAPH_REPORT.md：项目的关键概念、意外关联、推荐问题。
graph.json：完整图谱，后面查询、MCP、团队共享都靠它。

这个产物思路挺直接。以前 AI 助手回答项目问题，经常是临时读文件、临时总结、临时猜关系。Graphify 先把项目里的实体和关系沉淀下来，后面再问问题时，不需要每次从零翻仓库。

举个更具体的例子。

你可以问：

lua 复制代码

graphify query "what connects auth to the database?"
graphify path "UserService" "DatabasePool"
graphify explain "RateLimiter"

这几条命令分别对应查关联、找路径、解释节点。它还有 MCP server，可以用 stdio 方式给本机助手调用，也可以用 HTTP 方式在团队里共享，默认 HTTP 端口是 8080，公开到局域网时可以加 --api-key。

这比单纯生成一份架构说明更实用。

架构说明适合人读，但 AI 助手真正需要的是可反复检索的结构化上下文。Graphify 暴露的 MCP 工具包括 query_graph、get_node、get_neighbors、shortest_path 这些，刚好是 Agent 做代码理解时经常需要的动作。

README 里列的宿主很多，包括 Claude Code、CodeBuddy、Codex、OpenCode、Kilo Code、Cursor、Gemini CLI、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Amp、Kimi Code、Devin CLI 和 Google Antigravity 等。

支持列表虽长，Graphify 写入各宿主的内容并不相同。Claude Code、CodeBuddy、Codex、Gemini CLI 会得到对应的 skill、规则文件或 hook，Cursor 用的是 .cursor/rules/graphify.mdc。部分工具目前只能顺序执行，Graphify 的并行 Agent 能力在这里不会完整生效。

能自动调用这些规则和工具的宿主，可以主动利用图谱；接入较浅时，用户仍能手动执行 graphify query，只是每次查询都要自己发起。

代码侧主要靠 tree-sitter 做 AST 抽取，常见语言基本都覆盖了，比如 Python、JavaScript/TypeScript、Java、Go、Rust、C/C++、C#、Kotlin、Swift、PHP、Ruby、Shell 等。除此之外，它还扩展到了 SQL schema、Terraform/HCL、MCP 配置、Markdown、HTML、YAML、PDF、Office、图片、音视频、YouTube 或普通 URL 这类材料。

不过这里有个前提。

代码类材料可以本地解析，纯代码仓库不需要 API key；文档、PDF、图片这类语义抽取会走你配置的模型或 IDE 会话。 如果你的仓库里有敏感需求文档、内部截图、合同 PDF，不能只看到"本地知识图谱"几个字就默认全程离线。

README 的隐私说明写得比较清楚：代码文件通过 tree-sitter 本地处理；视频、音频用 faster-whisper 本地转录；文档、PDF、图片会发给 AI 助手或你指定的后端做语义抽取。可用后端包括 Gemini、Kimi、Claude、OpenAI、DeepSeek、Azure OpenAI、AWS Bedrock、Ollama 和 Claude CLI。

如果你想尽量本地化，可以选 Ollama：

bash 复制代码

graphify extract ./docs --backend ollama

如果是云端模型，就按后端设置对应环境变量，比如 OPENAI_API_KEY、ANTHROPIC_API_KEY、GEMINI_API_KEY、DEEPSEEK_API_KEY、AZURE_OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT 等。

技术栈也比较简单。主语言是 Python，要求 Python 3.10+，核心依赖里能看到 networkx、datasketch、rapidfuzz 和一大串 tree-sitter grammar。可选依赖按 mcp、neo4j、pdf、office、video、postgres、terraform、ollama 等功能拆开，默认安装不至于太重。

Graphify 还有一些很偏工程现场的小功能。

比如 graphify hook install 可以装 git hook，提交后自动重建代码图谱。团队协作时，官方建议把 graphify-out/ 也提交到仓库里，这样其他人拉下来后，助手马上就能读已有图谱，不用每个人先跑一遍完整抽取。

不过这一步别无脑做。graphify-out/graph.json 里会包含项目实体、路径、关系和部分语义信息，私有仓库问题不大；开源仓库，或者包含敏感业务命名、接口名、SQL schema 的仓库，提交前最好先看一眼产物内容。

再比如 graphify export callflow-html 可以导出可读的调用流 HTML；graphify merge-graphs 可以合并多张图；graphify prs 会看 PR、CI、review 状态和图谱影响范围。里面的 graphify prs --triage 属于 AI 排序能力，会用到你配置的模型后端，别把它理解成纯本地静态分析。

Release notes 里，0.8.35 新增了 CodeBuddy 支持，并修复 --update 场景下同名符号被错误折叠的问题。前一个版本 0.8.34 则加入 MCP Streamable HTTP、Azure OpenAI、PostgreSQL introspection、Apex 抽取，以及图片/PDF 的 headless extract 支持。

连续两版的变更说明项目仍在快速迭代，抽出的关系是否可靠还得单独验证。

Graphify 保存的是抽取结果，Agent 仍需校验其中的关系。代码里的 AST 关系相对可靠；文档、PDF、图片依赖模型做语义抽取，可能漏掉关系，也可能把两个名称相近的概念连在一起。仓库结构本身混乱时，这个问题会更明显。

图谱中的边会标成 EXTRACTED、INFERRED、AMBIGUOUS。前者来自明确抽取，后两类包含推断或歧义；Agent 的答案如果依赖这些边，仍然需要回到源文件确认。

我复查时，GitHub 页面能看到约 120 多个 open issue，其中包括 OpenAI backend 参数兼容、AST 跨文件继承漏抽、多仓库集成等问题或需求。接入的宿主和文件类型越多，类似的兼容问题也越容易暴露；把它接进团队主流程前，最好先用个人项目或非核心仓库验证。

查询还会留下本地日志。README 提到，graphify query、graphify path、graphify explain 和 MCP 的 query_graph 默认向 ~/.cache/graphify-queries.log 写入时间、问题、语料路径、返回节点数、耗时等信息，但不保存完整的子图响应。如果不希望记录，可以设置：

ini 复制代码

GRAPHIFY_QUERY_LOG_DISABLE=1

graph.html 也有规模限制。图谱超过 5000 个节点后，官方建议跳过 HTML，直接查询 JSON：

perl 复制代码

graphify cluster-only ./my-project --no-viz
graphify query "..."

可视化只是检查图谱的一种入口，真正影响使用效果的还是 query、path 等查询能否命中正确关系。

按当前版本的完成度，我更愿意把 Graphify 当作一层待验证的项目记忆，用来辅助 Claude Code、Codex、Cursor、Gemini CLI 回答跨文件、跨模块、跨文档的问题。要承担生产级代码理解中枢的角色，它还需要证明抽取结果和各类宿主集成的稳定性。

更稳的用法是：先在一个中等规模项目里跑一遍，问几个你自己知道答案的问题，比如认证入口、数据库访问链路、核心服务调用关系、某个接口影响范围。如果这些问题命中率不错，再接到日常工作流里。

纯代码仓库可以先本地跑一遍，成本不高；如果涉及 PDF、图片、内部文档，就要先看清楚模型后端、数据流向和查询日志。不要只看 graph.html 好不好看，重点看它能不能稳定回答你关心的那几个工程问题。

项目地址：github.com/safishamsi/...

⭐️推荐阅读：

后端开发学习 + 面试指南：覆盖 Java、计算机基础、数据库、框架、系统设计等后端开发核心知识与面试内容。
AI 应用开发学习 + 面试指南：覆盖 LLM、RAG、Agent、MCP、Prompt、评测、系统设计等 AI 应用开发知识与面试内容。
AI 编程实战指南：覆盖 Claude Code、Cursor、Codex、Trae 等工具的使用技巧与面试内容。