graphify vs Sourcegraph:为什么代码理解需要知识图谱而不仅是搜索
【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify
graphify是一个开源代码知识图谱工具:它能把任意代码库连同文档、SQL 表结构、配置文件甚至 PDF 一起,解析成一张可以查询的代码知识图谱,让你问"这两段代码是怎么连起来的",而不是再翻几百个文件。作为 Claude Code、Cursor、Codex、Gemini CLI 等的/graphify技能,它完全本地做 AST 解析,不用向量库,每条关系都会给出解释。
搜索工具找得到代码,但回答不了"关系"
Sourcegraph、grep、IDE 全文搜索都是优秀工具,它们的底层逻辑相同:给你一个关键词,还给你一批命中的文件和行号。这在"这个函数定义在哪"这类问题上够用,但换个问题就不行了:
- 🧩
UserService和DatabasePool之间经过了哪几层调用? - 🌐 整个项目里,哪些概念是"所有代码都绕着它转"的核心?
- 📊 认证模块改动后,会波及哪些看似无关的子系统?
搜索只能返回位置,无法返回结构。而理解代码,本质上就是理解"谁调用谁、谁依赖谁、谁解释谁"——这是一张关系网的问题。
graphify 的思路正是:先用 tree-sitter 对约 36 种语言的代码做确定性 AST 解析(本地运行、零 LLM、代码不出机器),再对文档、PDF、图片做语义补全,最终产出一张真正的图——节点是概念,边是调用、导入、继承、引用等关系。整个过程和原理见 docs/how-it-works.md。
一图看懂:搜索 vs 代码知识图谱
| 维度 | 传统搜索(grep / Sourcegraph) | graphify 知识图谱 |
|---|---|---|
| 输入 | 关键词、正则 | 自然语言问题 |
| 输出 | 命中的文件与行号 | 子图、最短路径、概念解释 |
| 关系理解 | ❌ 无,靠人脑拼凑 | ✅ 每条边带EXTRACTED/INFERRED置信标签 |
| 全局视角 | ❌ 逐次搜索 | ✅ God 节点(核心概念)、社区(子系统)一览 |
| 存储方式 | 索引 | 真实图结构,可遍历 |
| 向量库 | 部分方案需要 | 不需要,无嵌入、无向量库 |
值得注意的一点:graphify 里每条边都标注来源——EXTRACTED表示源码里明明白白写着的(如 import、函数调用),INFERRED表示工具推断出来的。这意味着你随时能分清"读到的"和"猜到的",而搜索工具从不告诉你命中是因为精确匹配还是模糊匹配。
graphify 如何构建代码知识图谱
构建过程分三步,对新手很友好:
- 代码结构解析(免费、本地):tree-sitter 提取类、函数、导入、调用图;SQL 文件还能确定性提取表、视图、外键和 JOIN 关系。纯代码仓库这一步之后就不需要任何 API Key。
- 音视频转写(本地):本地 faster-whisper 转写,且转写提示词会用当前图中最核心的概念做"预热",让转写更贴近你的领域。
- 文档/PDF/图片语义提取(需模型):AI 并行读取文档,输出节点与边的 JSON 片段并合并进同一张图。
随后用 Leiden 算法做社区检测,把图自动切成子系统,再找出连接数最多的God 节点。细节(含置信度评分规则)都在 docs/how-it-works.md 里讲得很清楚。
仓库里附带了可直接复现的示例:worked/httpx/README.md 用 6 个文件模拟了一个 httpx 风格的库,实际产出 144 个节点、330 条边、6 个社区,报告就在 worked/httpx/GRAPH_REPORT.md——你能看到Client以 26 条边成为 God 节点,以及DigestAuth和Response之间这条"你可能不知道的"跨文件关联。
三个高频场景:查询、路径、解释
图建好后,你不再"读文件",而是问图(以下命令在终端或 AI 助手中均可用):
/graphify query "auth 和数据库之间是怎么连通的?" /graphify path "UserService" "DatabasePool" /graphify explain "RateLimiter"- explain:给一个概念,返回它的来源文件行号、所属社区、连接度和所有关系边(如
APIRouter有 47 条连接,一眼看出它是路由中枢)。 - path:任意两个概念之间的最短路径逐跳展示,比如
FastAPI → DefaultPlaceholder → get_request_handler() → ModelField三跳直达。 - query:把自然语言问题编译成一个作用域子图,只给你相关的那部分,而不是塞给你一整个代码库。
配合 README.md 中的worked/示例(如 worked/mixed-corpus/GRAPH_REPORT.md),可以直观看到图谱对"代码 + 论文 + 图片"混合语料的效果;相关数据与基准见 BENCHMARKS.md。
快速上手:2 条命令搭建你的代码知识图谱
前置要求:Python 3.10+(推荐搭配uv)。
uv tool install graphifyy # 安装 CLI(pipx install graphifyy 亦可) graphify install # 把 /graphify 技能注册到你的 AI 助手然后在 AI 助手里输入/graphify .,30 秒后你会得到三个文件:
graph.html—— 浏览器打开即可点击节点、按社区过滤、搜索,就是文章开头那张图的交互版;GRAPH_REPORT.md—— 核心概念、意外连接、建议提问的精华报告;graph.json—— 完整图谱,随时可查,无需重读源文件。
💡 PyPI 官方包名是
graphifyy(双 y),命令仍是graphify,注意别装错同名包。
团队协作:把图谱提交进仓库,人人都能秒读项目
graphify 建议把graphify-out/目录提交到 git:一个人建图并提交,其他人拉下来后,其 AI 助手立刻就能基于图谱回答项目问题。再运行一次graphify hook install,每次 git 提交后自动增量重建(仅 AST 解析、零 API 费用),并注册 git 合并驱动——两人并行提交时,graph.json会自动做并集合并,不会出现冲突标记。
对新成员来说这是最大的福利:入职第一天不需要"读三周代码",而是让助手对着图谱解释架构、定位核心概念、追踪调用链。
总结:搜索回答"在哪",图谱回答"为什么"
- 🎯找定义、找字面量:搜索工具(Sourcegraph、grep)依然是最快的,两者不冲突;
- 🗺️理解架构、追踪依赖、评估改动影响:把代码库变成知识图谱,再提问,效率是量级差异;
- 🚀最省心的做法:保留你的搜索习惯,同时用 graphify 建一张图谱提交进仓库——搜索管"定位",图谱管"理解"。
如果你正在接手一个陌生代码库,或者想让 AI 助手真正"读懂"项目而不是逐文件瞎翻,不妨按 README.md 的指引花两分钟建一个/graphify试试。
【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考