揭秘与评测 30K+ Star 的 Graphify：企业存量系统 AI 编码的"第二大脑"。- 大数跨境

首页

揭秘与评测 30K+ Star 的 Graphify：企业存量系统 AI 编码的"第二大脑"。

AI大模型应用实践

2026-04-27

导读：企业存量系统做 AI Coding，最难的不是写代码，而是让 AI 弄懂现有业务与系统。

点击上方蓝字加入我们

故事最初来自 AI 大神 Karpathy 分享的个人知识库：将文档、网页、截图等放入一个原始文件夹（raw/），然后用 LLM 自动“编译”与维护一个 Wiki 库用于导航与检索 — 一种“预编译好的结构化知识库”。

方法很优雅，不过他也期待：

"...... there is room here for an incredible new product instead of a hacky collection of scripts."

Graphify 就是这里的“Incredible product”，它把 LLM-wiki 向前推了一步 — 不只是 Markdown，而是知识图谱，从而打开新世界的大门。

本文将解读 Graphify 如何在 AI 编程领域最具挑战性的任务 — 企业存量软件系统的 AI 编程 — 充当“第二大脑”。

本文内容：

Graphify 是什么：给 AI 编程助手的“地图”
Graphify 如何作为存量软件开发的“第二大脑”
上手 Graphify：快速构建存量软件的图谱
揭开面纱：Graphify 原理拆解
效果对比：有 Graphify vs 无 Graphify
别神化 Graphify：并非万能解药

Graphify 是什么：给 AI 编程助手的“地图”

Graphify 的官方定位是“一款 AI 编程助手的技能“，它并不是泛泛的个人知识管理，而是用于构建更容易被 AI 编程助手使用的知识地图。它的核心能力，不是把所有资料堆成一个好看的、给人类翻阅的知识库，而是把下面这些分散的材料转变成一张结构化“地图”：

代码（符号、关系、docstring、注释）
业务知识、需求、设计、接口说明、辅助理解材料等
各类编程、设计、测试、CI/CD规范

有了这张“地图”，你的 AI 编程助手就可以更好的理解、设计与编写代码。

我们把几种知识管理的方法放在一起对比：

尽管各自定位不同，但也都为了解决同一个问题：信息量太大，不能让模型每次都把所有原始材料读一遍，再输出答案。

但差别在于：

RAG 的方法是“只召回相关的文本”，然后让模型据此回答。
LLM Wiki 则是让 LLM 编译成结构化的 MD 文档 + 导航，直接查阅。
Graphify 则是创建文档与代码的深层结构：知识图谱，给 AI 使用。

当然，这里最大的区别是：

前两种服务对象是“人”，而 Graphify 的服务对象主要是 AI 编程助手。

Graphify 如何作为存量软件开发的“第二大脑”

你或许会说，现在的 AI Coding 能力这么强大，我没有 Graphify，我的 Claude Code、Cursor 们不也工作的好好的？

是的，对于很多需求边界清晰、依赖单纯、业务通用且失败代价低的新项目或者模块，AI 编程的确可以凭借自身的能力完成大部分工作。

但问题在于，在金融、医疗、制造这样的企业软件领域，很多真实的应用并不是这种“干净”系统。

你看到的是一个UI界面，背后可能牵动的是复杂的数据模型、个性化的流程、大量第三方系统对接、某些客户的特殊逻辑，以及某个已经离职工程师留下的一段看不懂的“特殊处理” — 复杂性远超一个通识模型能够稳定理解的范围。

以笔者参与的一个项目为例，实施超过10年，上万个源代码文件，上千张数据表，已经淘汰的技术、封装的私有组件库等。如果没有足够的、为 AI “量身定做”的知识库，直接 AI 编程的可用率极低、Token 成本极高。

问题的本质是业务与系统知识没有被结构化沉淀。只有口口相传、不健全的文档；AI 一遍遍重读源码，结果就是理解成本越来越高。

Graphify 可以很好的协助解决这样的问题。

它把散落在代码与文档里的事实，用 LLM “编译”成一层 AI 消费的知识地图：谁调用了谁，哪个模块依赖哪个模块，某个业务概念落在哪些类、接口、表结构和配置项上，某条规则又和哪些文档、设计相关。

所以说，Graphify 更像是 AI 编程助手的“第二大脑”：

第一大脑（LLM）负责推理与生成代码；第二大脑则负责告诉它：现有系统怎么设计的，长什么样，代码怎么写的，某个新需求应该从哪里下手，改动可能影响到哪里，等等。

上手 Graphify：快速构建存量软件的图谱

现在拿一个 GitHub 上的真实项目 BettaFish（一个优秀的舆情监控智能体），来看看 Graphify 可以如何帮助 AI 认识一个存量软件系统。

如何“建”图？

首先执行命令安装(xxx为你使用的编码智能体）：

pip install graphifyy && graphify install --platform xxx

graphify install 命令会在你的编程智能体目录下注入 Skills 与 Claude.md（或AGENTS.md）指令，接着你就可以在 AI 编码助手调用 Skill 建图：

/graphify .

# 在终端查看产出
ls graphify-out/
# ├── GRAPH_REPORT.md # 总览报告
# ├── graph.json # 结构化数据
# ├── graph.html # 可视化 HTML
# ├── wiki/ # 社区的Wiki文档
# └── cache/ # 增量更新缓存

这个 Skill 会扫描项目目录（或指定一个目录）下的代码与文档，构建一个完整的知识图谱（Graph），并使用社区识别算法做聚类，最后输出结构化的图谱，及一些辅助文档。

如何“用”图？

AI 编码助手如何使用 Graphify 生成的图谱？主要方式为：

AGENTS.md（或CLAUDE.md）的常驻系统指令。让 AI 在回答问题或者试图 grep 搜索时，优先看“地图”，而不是直接看代码：

使用 /graphify 技能，并告诉它你需要查询的内容。比如：

/graphify query "这个系统的一次完整分析流程是怎么启动的？"

还有一种方式是启动 Graphify MCP，让 AI 调用工具查询。

三种方式的本质分别是：系统提示、Skill、MCP 工具。

如何维护？

软件是一个不断更新迭代的系统，那么当代码或者文档发生修改后，如何保持知识图谱的同步，防止知识“过期”？可以使用技能：

/graphify update .

如果说第一次建图就像数据库的“初始化索引”，后面则更像“增量维护索引”。

Graphify 生成的图谱应该像代码一样进入仓库维护。Graphify 提供了较完善的自动维护手段，包括：

所以，Graphify 的图谱并不是跑一次后的静态分析结果，而是一个可以跟着项目一起演化的认知层（AI编程助手使用）。

揭开面纱：Graphify 原理拆解

在了解 Graphify 的价值并上手体验后，我们还需要“知其所以然”。

生成阶段

在你调用Graphify后，其创建图谱的过程可以粗略表示成：

第一步：识别文件类型

首先遍历目录并识别文件类型（代码还是文档）。

第二步：节点与边的抽取

Graphify 对于代码和文档采取不同的抽取策略：

代码：AST（抽象语法树）抽取策略，拿到类、函数、调用、继承等显式结构与关系，不需要消耗 Token。
文档：借助模型进行语义理解与抽取，由 AI 编程助手的模型来完成。

相对更结构化的代码，文档的语义抽取则需要让模型先读取文档（或图片、视频等），再抽取其中的概念、关系、理由、相似性等，然后把这些结果写入 Graph。特别注意，文档的抽取结果只是一个核心语义层 — 保存了“文档中的核心语义概念及它们之间的关系“，而不是拆碎的原文（不同于 RAG）。

抽取的节点中会包含”来源指针“信息，用来指导 AI 回到原文档/源代码。

第三步：社区检测

通俗的讲，社区检测就像在一张城市路网图上识别“商圈”和“居民区” — 将图谱中的高度相关的节点关系组织成一个个“主题”。

比如，代码或文档里那些靠得很近、互相频繁引用的部分，会“长成”一个社区。这个结果很有价值，因为它更接近真实的软件结构。

社区检测通常借助成熟的 Leiden 聚类算法，这是上一节中识别出的社区：

最后一步：输出结果

把这层结构化结果分发成 GRAPH_REPORT、graph.json、graph.html、wiki 等不同视图，分别服务于不同的使用场景。

Graphify 的输出中可以看到一些“God Nodes”，这是指连接度特别高、能代表系统核心抽象的枢纽节点。还有“Hyper Edges”，这是表示一种多节点的Group关系，比如“这几个模块共同组成一个流程”。

查询阶段

当你用 Graphify 技能做查询，比如：

它的工作过程是怎样的呢？

在没有图谱之前，通常只能由模型根据输入问题进行推理，比如首先从目录结构推断程序入口，然后逐步文件探索；或者关键词做 grep 查找，再对一些关联文件读取分析。

这种方式对小型且结构清晰的代码库还能奏效，但对于中大型的代码库，最大的问题是覆盖度有限导致分析偏差，Token 消耗较大。

而在 Graphify 里的自行过程大致如下：

所以，大部分时候 Graphify query 不是直接从图谱里得到答案，而是：

图谱先给 AI 助手提供方向
图谱告诉 AI 助手去看哪些源文件、哪些位置
AI 助手通过代码或文档完成证据闭环，得到答案

注意：这里的查询是指 /graphify 技能查询；而不是 graphify query 命令行查询（简单的返回图谱搜索结果，无需模型）。

效果对比：有 Graphify vs 无 Graphify

为了更直观的了解 Graphify 对 AI 编程助手的帮助，我们用一个实际的问题来做一个测试，评估有无 Graphify 两种方法的差异。

【测试问题】

“ BettaFish 一次完整的分析是如何完成的？涉及哪些核心代码组件？”

【测试方法】

在使用 Graphify 与不使用 Graphify 增强的两种场景下，分别让编程助手自主探索，输出答案，并对各自所花时间、Token 成本、答案质量等做评估。

关键约束：限制 AI 不能参考任何项目中已有的说明与报告文档；防止 AI 参考已有的结论性信息。

【测试工具】

Github Copilot + Claude Sonnet 4.6

为了更务实的考察 Graphify 的效果，这里特地没有使用最强模型。

【测试结果】

最终的结果如下：

探索过程指标

成本指标

这里的 Token 消耗是比较出乎意料的部分，下文会解释。

质量指标

【结论与一些分析】

实际测试中，我们进行了多个问题、多个模型的评估，一些观察如下：

Graphify 在综合质量上提升非常明显。而探索成本（工具调用次数）反而更低，这证明了"以结构化知识导航代替直接文件探索"的策略有效性。
Graphify 的最大价值在于跨文件架构事实的获取。比如上面例子中的多引擎并行关系等需要"关系视图"的知识，这是纯代码探索较难完整获得的。
Graphify 方法是否一定节约 Token 会依赖于问题类型与模型/Agent。

问题类型：在探索系统整体架构、跨模块依赖的问题上，由于图谱及其报告中的信息很多时候能直接给出答案，节省 Token 更多；但是在细节性的问题上，由于必须深度读源代码，在 Token 上消耗差异不大。可以总结为：跨文件探索程度越高，Graphify 才能体现更高的 Token 优势。

此外，由于Graphify 在查询时通常会首先读取graph_report.md，本身也是一笔 Token 消耗。

模型/Agent：有时候探索倾向性更强的模型，会有很多”验证性“的读取大量源代码的行文，导致 Graphify 优势反而不明显。

别神化 Graphify：它不是万能解药

那么，是不是只要把存量系统的源代码、设计文档、规范文档都交给 Graphify，给 AI 编程助手一张“地图”，它就能彻底胜任存量系统开发了？

答案显然不是。

Graphify 是一块非常重要的拼图，它能显著提升 AI 对系统结构的理解效率，却不能替代源码、业务文档、架构约束，也不能替代一套稳定的研发流程。

它不能替代源代码

Graphify 的价值，是先帮 AI 找到相关结构、相关概念、相关模块和相关来源。但它并不负责替代源码本身。

比如下面这些问题，最后仍然要回到代码里确认：

某个函数的参数签名到底是什么
某段分支逻辑最终是怎么执行的
某个异常到底在哪里被抛出

所以，合理的用法不是“让 Graphify 直接给答案”，而是：

先用 Graphify 查地图，再回到源码看现场。

Graphify 负责缩小搜索范围，告诉 AI 该看哪里；源码负责提供最终证据，告诉 AI 事实到底是什么。

它更适合“带着问题查地图”

Graphify 生成的图谱，非常适合带着明确问题去查询。比如：

这个业务概念和哪些代码相关？
哪些接口处理了这个场景？
如果更改这个接口，可能影响哪些代码和业务？

但真实开发中，需求一开始往往并不是这样清晰的问题，而是一段描述：

“供应商主数据变更，需要新增审批流程，并在审批通过后同步校验到采购、财务和库存系统。”

这时候，AI 还没有明确的“问题锚点”。如果直接拿这段话去查 Graphify 的代码与文档图谱，效果未必很好。

所以很多时候你需要借助其他方法来逐步细化需求，收敛出一些具体问题；再通过 Graphify 查询这些问题背后的知识，帮助 AI 理解系统并辅助编码。

存量系统开发需要“组合拳”

Graphify 擅长的是问题驱动的知识查找与穿透。但存量系统里有很多天然属于“整体认知型”的知识，更适合作为完整文档被 AI 线性读完。通过拆分后的图节点再回溯理解，反而可能破坏叙事、因果和约束的完整性。

比如：

业务理解需要完整阅读业务目标、领域术语和业务流程等，因为这些内容有顺序、有因果，碎片化的”跳跃式“阅读很难拼出全貌。

再比如编码规范，包括命名、异常处理、提交约定等。这些知识不应该是“用到时查一下”就够了，而应该是 AI 写代码时默认遵守的规则。

因此，很多时候与其让 AI 到图谱里零散检索，不如直接把它导航到对应的上下文文档，让它完整阅读。

比如现在很多团队会引入 SDD（规范驱动开发），并让 AI 在不同阶段加载不同的上下文文档，从而可以更精准地控制 AI “此刻该看到什么、不该看到什么”。比如：

在specs 阶段，可以补充需求的边界场景、既有规则和约束文档；
在design阶段，可以加载架构约束、接口约定、原型参考等；

这种场景下，由于 Graphify 图谱并不知道 AI 现在处在哪一步，也不知道哪些文档此刻应该被完整通读，哪些信息只需要按需检索。“自定义的上下文加载策略 + Graphify 发现关联信息/代码影响”，或许是合适的组合方案。

END

喜欢就关注哦

动动小手点个赞

点在看最好看

【声明】内容源于网络

AI大模型应用实践

专注大模型应用的深度研究与开发实践。《基于大模型的RAG应用开发与优化》、《MCP原理揭秘与开发指南》作者。ToB为主，ToC为辅。

内容 56

粉丝 0

AI大模型应用实践专注大模型应用的深度研究与开发实践。《基于大模型的RAG应用开发与优化》、《MCP原理揭秘与开发指南》作者。ToB为主，ToC为辅。

总阅读221

粉丝0

内容56