代码知识图谱怎么选：纯代码结构 vs 全模态知识图谱
想让 AI 助手”读懂”你的代码库，常见方案是建代码知识图谱。但”读代码库”其实有两种完全不同的需求，对应两类不同的工具：
- 代码结构图谱：回答”这个函数被谁调用了？”
- 全模态知识图谱：回答”这个系统的设计动机是什么？”
把这两类混为一谈，是选型时最常犯的错。
两类工具的本质差异
纯代码结构图谱：源码 → 语法分析（AST）→ 存进数据库 → 一个查询工具。只含代码结构：函数、类、调用关系、导入关系。
源码 → AST → 数据库 → "authMiddleware 被谁调用了？"全模态知识图谱：代码 + 文档 + PDF + 图片全部索引 → 代码走语法分析，文档/图片走 LLM 提取概念 → 存进图结构 → 交互式可视化 + 多种查询。
代码 + 文档 + PDF + 图片 → AST(代码) + LLM(文档) → 图谱 → 可视化 + 查询对比表
| 维度 | 纯代码结构 | 全模态知识图谱 |
|---|---|---|
| 索引内容 | 只有代码 | 代码 + 文档 + 图片 + PDF |
| 代码提取 | 语法分析 AST | 语法分析 AST（相同） |
| 文档 / 图片 | ❌ 不支持 | ✅ LLM 提取概念和关系 |
| 索引成本 | 零（纯本地解析） | 文档部分走 LLM（有 token 费） |
| 输出 | 文本查询结果 | HTML 交互图 + JSON + 多种格式 |
| ”为什么” | ❌ 只有结构 | ✅ 从注释/docstring 提取设计动机 |
| 社区发现 | ❌ | ✅ 自动聚类相似模式 |
| 置信度 | 无 | ✅ 区分事实（抽取）与推测（推断） |
四个典型场景怎么选
场景一：日常代码导航——“上传接口在哪个文件？调用链是什么？” 两个都能做，但纯代码结构更轻更快。
场景二：跨项目 Bug 模式——“ZIP 编码问题在 A 和 B 两个项目都出现过，它们有共同点吗？” 纯代码结构看不到跨项目概念；全模态图谱的社区发现会把两个 bug 自动聚类到一起。
场景三：新人接手项目——“系统整体架构什么样？关键设计决策是什么？” 纯代码结构能给结构，但没有”为什么”；全模态图谱能提取设计动机、输出架构报告。
场景四：文档与代码联动——“这份文档说的修复，对应代码里哪个函数？” 纯代码结构不索引文档；全模态图谱把文档和代码放进同一个图谱，直接关联。
选型建议
如果你的资产只有代码 → 纯代码结构图谱（零成本、极简、快）。
如果代码 + 文档（wiki / bug 记录 / 设计文档）都要 → 全模态知识图谱。代码部分走语法分析（零 token），文档部分走 LLM（有缓存，只处理一次），成本可控。
如果两个都要，先装轻的。 纯代码结构解决 80% 的日常导航需求；等文档资产多起来，再补全模态的做跨项目分析。
一个务实的组合
很多人最终会走到”分层”的路线：
- 代码导航用轻量的结构图谱（毫秒级响应、零成本）
- 知识沉淀用文档型知识库（人机共用、版本可控）
- 跨项目洞察用全模态图谱（按需建，处理文档资产）
三个各司其职，而不是一个工具试图解决所有问题。
结论
选型先分清问题：
“函数被谁调用”是结构问题，用代码结构图谱；“系统为什么这么设计”是知识问题，用全模态图谱。
先回答你要解决哪个问题，再选工具。两个都答不出”哪个适合你”，那就先上轻的那个。
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或打赏支持！