graphify 代码知识图谱怎么用 建图与查询
graphify 代码知识图谱怎么用：代码文档 SQL PDF 同图、本地 AST 无向量库，讲清查询方式与适用边界。
想把仓库连同文档、SQL、PDF 一起查，而不是只建符号表时，graphify 代码知识图谱怎么用，关键看建图范围、查询命令和失效边界。
和只扫源码的图谱差在哪
Graphify-Labs/graphify 的仓库描述写得很直：把代码库连同 docs、SQL schemas、配置和 PDF 建成可查询知识图谱，并以 /graphify skill 接到 Claude Code、Cursor、Codex、Gemini CLI 等助手。机制上强调本地确定性 AST、每条边可解释、不依赖向量库。
本站已写过「代码图谱怎么帮 agent 省 token」那篇，主线是 CodeGraph 一类纯代码符号图：调用边、依赖边、建库成本、何时不如 grep。本文不重复那条账单账本，只把 graphify 多出来的那一块写清楚：同一张图里除了源码，还能挂文档与 schema；查询是 query / path / explain；哪些仓库值得装，哪些场景会失效。
2026 年 8 月 5 日查 GitHub API：仓库 Apache-2.0，默认分支 v8，近期仍在推送。star 量级只能说明关注度，不能替你证明语言栈覆盖率。
建图能吃进哪些材料
README 的文件类型表把输入分成几层。代码侧走 tree-sitter AST，扩展名覆盖很长一串，从 .py .ts .go .rs 到 .sql、部分配置与工程文件；Salesforce Apex、Terraform（需 graphifyy[terraform]）另有条目。文档侧包括 .md .mdx .txt .rst .yaml 等，markdown 链接与 wikilink 会变成文档之间的 references 边。PDF 需要可选依赖 uv tool install "graphifyy[pdf]"；图片走视觉抽取；音视频要 graphifyy[video]。
SQL 有两档。仓库里的 .sql 文件可进代码抽取路径；若要「SQL schema extraction」能力，README 写明装 graphifyy[sql]。还想对着活库 introspect，则用 graphifyy[postgres] 加 --postgres DSN。这和「只索引 .ts 调用图」不是同一产品形态：schema 与 ADR 可以和实现落在同一张 graph.json 里。
成本分界也写在 README：代码抽取本地完成、不调模型；文档、PDF、图片等语义抽取要走你配置的助手模型或 API。全量把设计稿和论文塞进图之前，先想清楚每次 --update 的账单。
边为什么敢说可解释
graphify 反复强调：它不做向量索引，也不靠「语义相似的一段」凑答案。查询时遍历图上的节点与边。每条关系带置信标签。README 主文写 EXTRACTED（源里写明）与 INFERRED（解析器推导）；报告一节还列出 AMBIGUOUS，表示猜的成分更高。查路径时，你可以按标签决定信多少。
社区发现用 Leiden（可选 graphifyy[leiden]，且注明 Python 3.13 以下），产出 god nodes、社区、以及「跨文件意外连接」。产物默认进 graphify-out/：graph.html 可点、GRAPH_REPORT.md 给人看摘要、graph.json 给后续查询复用，不必每次重读全仓库。需要把图推进 Neo4j 或 FalkorDB 时，README 提供对应 extras；默认路径不要求你起图数据库服务。
PyPI 包名暂时是 graphifyy（双 y），CLI 仍叫 graphify。README 警告其它 graphify* 包不附属；装错包等于白装。团队若用 uvx，务必写成 uvx --from graphifyy graphify …，把第一个词当成包名会直接找不到发行版。
装好之后怎么查
最短路径按官方 30 秒流程：
uv tool install graphifyy
graphify install
在助手里对当前目录执行 /graphify .（Codex 侧 README 写的是 $graphify）。Cursor 用 graphify cursor install 写 .cursor/rules/graphify.mdc（alwaysApply: true）；Claude Code 可 graphify claude install 挂 PreToolUse 提醒；Codex 主要靠 AGENTS.md。
图建完后三类查询最常用：
graphify query "what connects auth to the database?"
graphify path "UserService" "DatabasePool"
graphify explain "RateLimiter"
README 用 FastAPI 语料示范过 explain "APIRouter"：返回源文件行号、社区编号、度数，以及带标签的连接列表；path 则给出最短跳数路径。日常探索优先 query 拿子图，架构追链用 path，搞清单概念用 explain。需要 agent 用文件爬知识库时，可加 --wiki 生成按社区拆开的 markdown。
增量方面有 --update（只重抽变更文件）、--watch，以及 graphify hook install 的 post-commit 重建（README 写明 hook 侧重 AST、避免无谓 API 费用）。SHA256 缓存只重跑变过的文件。多人同时改 graph.json 时，hook 还会装 git merge driver 做并集合并，降低冲突标记卡死流水线的概率。
一次完整跑完后，先打开 GRAPH_REPORT.md 看 god nodes 与 suggested questions，再决定要不要开 strict 模式逼助手先查图。报告里的「意外连接」适合当审查线索，不适合直接当成缺陷工单。
什么仓库值得跑 graphify
优先三类仓库。第一，源码与文档、schema 强绑定：OpenAPI、ADR、迁移 SQL、运维 runbook 和实现必须对照着读。第二，跨语言或多包单体，agent 用 grep 会在路径与同名符号之间打转。第三，你已经接受「文档语义抽取要花模型钱」，并且会把 PDF/设计说明当一等输入。
反过来，纯几百个文件、几乎没有 docs/SQL 的小服务，graphify 的多模态优势用不上；这时 Semble 做代码搜索省 token 或官方 LSP/grep，往往更轻。若你的痛点只是「调用链与影响面」，先看 代码图谱怎么帮 agent 省 token 里对纯代码图的取舍，再决定要不要上 graphify 的文档层。
探索阶段本身也会烧 token。图谱省的是「反复 Read 全文件」；会话里其它浪费源，仍要对照 agent 别把 token 浪费在哪。
局限与失效场景
第一，图是快照。重构、改路由、改表结构之后，若不跑 --update 或 hook，答案会漂。grep 永远读磁盘现状；图不会。
第二，静态分析天花板仍在：反射、动态派发、DI 约定入口，AST 看不见。INFERRED / AMBIGUOUS 边尤其不能当编译器证明。
第三，文档与 PDF 质量决定语义边质量。过时 README、互相矛盾的 wiki，会把错误关系画进图里，而且带上「像那么回事」的标签。
第四，可选依赖与平台差异多。PDF、office、postgres、leiden 都是 extras；Python 版本还会卡住 leiden。Cursor 靠 rules、Claude Code 靠 hook，严格模式（--strict）会拦截会话首次裸读源码，团队要先对齐策略。
第五，厂商平台与开源 CLI 是两套叙事。README 提到 graphify.com / app.graphify.com 的 always-on 产品在早鸟阶段；本文只按开源仓库 README 与 API 描述写本地 skill 路径，不把商业平台能力写成已随包附赠。
版本与 extras 列表会变，装之前打开当日 README 核一眼命令即可。