开发者平均 35% 的工作时间花在理解和阅读代码上——这是微软开发效率报告里的数据。接手一个新项目，前几周基本就在各种文件之间跳来跳去，试图搞清楚模块调用关系、核心入口在哪、改一处会不会牵一发而动全身。
AI 编程工具普及后，这个问题反而更突出了。Cursor、Claude Code、Windsurf 写代码很快，但它们并不真正"懂"你的代码库。AI 改了一个函数的返回类型，不知道有几十个地方依赖这个返回值，然后你就收获了一个运行时崩溃。
市面上的代码分析工具，Sourcegraph 很强但需要部署服务器；CodeSee 有可视化图谱但是商业产品，代码要上传到别人服务器。对于代码不能出本地的团队来说，都有痛点。
GitNexus 提供了一个不同的方案：零服务器、零配置、完全在浏览器端运行的代码知识图谱引擎。
GitNexus 是什么
GitNexus 的定位很清晰：零服务器代码引擎。把 GitHub 仓库 URL 拖进去，或者上传一个 ZIP 包，它会在浏览器里把整个项目解析成一张交互式知识图谱。
内置的 Graph RAG 代理可以回答代码相关问题："谁调用了这个函数"、"改这个模块会影响哪些地方"、"项目里有没有循环依赖"。作者称之为"为 AI 代理构建代码理解的神经系统"。
项目在 GitHub 上已有 3.55 万 Star，单日涨星最高记录 1800+。
核心特点
完全在浏览器端运行
整个知识图谱的构建、渲染、查询都在浏览器里完成，代码永远不会离开你的电脑。技术实现：
- WebAssembly 在浏览器端跑解析引擎
- IndexedDB 做数据持久化
- Web Workers 多线程解析不卡 UI
对企业合规敏感、代码不能出本地的团队来说，这一点直接解决了核心顾虑。
知识图谱，不只是搜索
传统 IDE 全局搜索能告诉你"这个函数被引用了 12 次"，但 GitNexus 能画出从入口点到目标函数的完整调用链，标注每一步的置信度。它追踪的是关系，而不只是文本匹配。
图谱中每个节点是一个函数、类或模块，每条边是一种关系——调用、继承、导入、实现。Leiden 社区检测算法自动把相关符号聚成功能社区，快速理解"这一堆文件是干什么的"。
Graph RAG，让 AI 真正理解代码
普通 RAG 是把文档切片存向量库，查询时召回相关片段。GitNexus 拿代码的结构化图谱做 RAG，精度比文档切片高得多。
对比示例：问"Auth 模块如果被拆分出去会影响什么"，普通 RAG 召回包含"Auth"关键词的文档片段；Graph RAG 直接返回依赖关系图谱，列出直接依赖的 7 个模块和间接依赖的 12 个模块，并标注风险等级。
MCP 集成，给 AI 编程工具装上眼睛
GitNexus 提供 16 个 MCP 工具，让 Claude Code、Cursor、Codex、Windsurf 等 AI 编程工具通过标准 MCP 协议访问代码知识图谱。配置一次之后，AI 代理在改代码之前会先查图谱知道影响面，再动手。
支持 14 种编程语言
| 支持程度 | 语言 |
|---|---|
| 完整支持（导入/导出/继承/类型推断） | TypeScript, JavaScript, Python |
| 部分支持 | Java, Kotlin, C#, Go, Rust, PHP, Ruby, Swift, C, C++, Dart |
技术架构
GitNexus 有两套运行模式：
| 组件 | CLI 模式 | Web UI 模式 |
|---|---|---|
| 解析引擎 | Tree-sitter 原生绑定 | Tree-sitter WASM |
| 存储 | LadybugDB 原生 | LadybugDB WASM |
| 嵌入向量 | 本地模型 | transformers.js (WebGPU/WASM) |
索引管道分六个阶段依次执行：结构映射 → AST 解析 → 关系解析 → 社区聚类 → 执行流追踪 → 混合搜索索引构建（BM25 + 语义向量 + RRF 融合）。
可视化层用 Sigma.js + Graphology，基于 WebGL 渲染。中型以上项目建议先缩小到目标模块再分析。
三种使用方式
CLI 模式（推荐日常开发）
npm install -g gitnexus
cd 你的项目
gitnexus analyze索引存在项目里的 .gitnexus/ 目录，默认被 gitignore。配置 MCP：
gitnexus setup自动把 MCP 配置写入你正在使用的 AI 编程工具。
Web UI 模式（开箱即用）
访问 gitnexus.vercel.app，粘贴 GitHub 仓库 URL 或拖入 ZIP 包，等待解析完成即可看到知识图谱。
Docker 部署（团队服务）
docker compose up -d为团队提供统一访问入口，数据通过 volume 持久化。
实际体验
打开 Web UI，找一个你熟悉的开源项目，中小型项目大概一两分钟就能解析完。点击任意节点，高亮显示所有上下游调用关系。左侧对话框可以用自然语言提问：
- "项目的入口在哪里" → 返回主要执行流的起点
- "如果我改了 UserService，会影响哪些模块" → 返回影响面分析，含直接/间接依赖和置信度评分
CLI + MCP 模式下体验更无缝。在 Cursor 或 Claude Code 里问"帮我分析这个项目的架构"，AI 会先通过 GitNexus 的 MCP 工具查询知识图谱，拿到结构化上下文后再回答，准确度和深度比盲目读文件好很多。
苏米注：实测中等规模项目（几百个文件）体验流畅。大型项目（上万文件）浏览器内存占用会飙到 2GB 以上，建议拆模块分别分析。
适用场景
- 接手新项目：把仓库拖进去，看社区聚类结果，几分钟搞清模块划分
- 重构前依赖评估：先分析目标模块的影响面，心里有数再动手
- 代码审查：PR 里改了底层函数，快速确认影响范围
- 新成员入职：快速建立对项目整体架构的感知，缩短上手周期
注意事项
GitNexus 使用 PolyForm Noncommercial License 1.0.0，这是源可见（source-available）许可证，非 OSI 认证开源协议。个人学习、非商业研究、开源项目使用没问题。公司集成到商业产品需联系作者获取商业授权。
当前局限：大项目性能有瓶颈，部分语言支持还在完善，许可证对商业使用有限制。
总结
GitNexus 把代码知识图谱做到了零服务器、零配置、浏览器端运行。Graph RAG 加知识图谱的组合比传统文档切片 RAG 更贴合代码理解场景，MCP 集成也踩在了 AI 编程的趋势上。
工具值得花半小时试一下，说不定能改变你读代码的方式。