GitHub 9.8万Star AI工具 将代码仓库转为知识图谱 适配Claude Code/Codex

## 当你的AI助手能在代码海洋里精准导航 你有没有遇到过这种场景：问AI编码助手“认证链路最后在哪里写数据库”，它要么翻十几个文件，要么从头grep一轮，最后给出的调用关系还未必准确。仓库一大，这种临时搜索很快就会挤满上下文，效率和准确率都会打折扣。 今天要聊的开源项目Graphify，正好切入这个痛点。说白了，它做的事情其实很直接——扫描项目目录里的所有代码、文档、SQL schema、脚本、图片，甚至视频文件，把识别出的实体与关系存进一张可查询的知识图谱。Claude Code、Codex、Cursor、Gemini CLI这类AI助手接入后，可以先从图谱定位相关节点和路径，再决定需要打开哪些文件。 项目地址是：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编码助手里跑： ``` /graphify . ``` 如果是在Codex的assistant命令里，README特别提醒要用$graphify，不是/graphify。Windows PowerShell也别写/graphify .，直接用graphify .，因为开头的斜杠会被PowerShell当成路径。 跑完之后，项目里会多一个graphify-out/目录，里面主要有3个东西： - graph.html：浏览器里看的交互式图。 - GRAPH_REPORT.md：项目的关键概念、意外关联、推荐问题。 - graph.json：完整图谱，后面查询、MCP、团队共享都靠它。 这个产物思路挺直接。以前AI助手回答项目问题，经常是临时读文件、临时总结、临时猜关系。Graphify先把项目里的实体和关系沉淀下来，后面再问问题时，不需要每次从零翻仓库。 ### 举个例子 你可以问： ``` 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 Antigra vity等。 支持列表虽长，Graphify写入各宿主的内容并不相同。Claude Code、CodeBuddy、Codex、Gemini CLI会得到对应的skill、规则文件或hook，Cursor用的是.cursor/rules/graphify.mdc。部分工具目前只能顺序执行，Graphify的并行Agent能力在这里不会完整生效。 能自动调用这些规则和工具的宿主，可以主动利用图谱；接入较浅时，用户仍能手动执行graphify query，只是每次查询都要自己发起。 代码侧主要靠tree-sitter做AST抽取，常见语言基本都覆盖了，比如Python、Ja vaScript/TypeScript、Ja va、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： ``` 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写入时间、问题、语料路径、返回节点数、耗时等信息，但不保存完整的子图响应。如果不希望记录，可以设置： ``` GRAPHIFY_QUERY_LOG_DISABLE=1 ``` graph.html也有规模限制。图谱超过5000个节点后，官方建议跳过HTML，直接查询JSON： ``` graphify cluster-only ./my-project --no-viz graphify query "..." ``` 可视化只是检查图谱的一种入口，真正影响使用效果的还是query、path等查询能否命中正确关系。 从当前版本的完成度来看，我更愿意把Graphify当作一层待验证的项目记忆，用来辅助Claude Code、Codex、Cursor、Gemini CLI回答跨文件、跨模块、跨文档的问题。要承担生产级代码理解中枢的角色，它还需要证明抽取结果和各类宿主集成的稳定性。 更稳的用法是：先在一个中等规模项目里跑一遍，问几个你自己知道答案的问题，比如认证入口、数据库访问链路、核心服务调用关系、某个接口影响范围。如果这些问题命中率不错，再接到日常工作流里。 纯代码仓库可以先本地跑一遍，成本不高；如果涉及PDF、图片、内部文档，就要先看清楚模型后端、数据流向和查询日志。不要只看graph.html好不好看，重点看它能不能稳定回答你关心的那几个工程问题。