我看 Understand Anything，先翻的是命令。
在 Claude Code 里装好插件，跑一次 /understand，再开 /understand-dashboard。
仓库会被扫成一张图。
文件、函数、类、依赖关系，全摊开。能点，能搜，也能顺着调用关系往下追。
几十万行的老项目，麻烦往往不是代码难。
是入口压根找不到。
你知道某个 service 在干什么，却不知道谁在调它；controller 改了一处，后面牵出多少东西，也只能靠搜关键词慢慢猜。README 看完了，业务流还藏在一堆 import 和函数调用里。
Understand Anything 干的，就是先把这些线拽出来。
它没有把整个仓库一股脑扔给模型。代码结构用 Tree-sitter 拆，函数、类、依赖这些尽量按静态分析来；模型主要补说明、标签，还有架构分层。
这个拆法我比较认。
至少调用关系不是让大模型现场编一张图。结构归结构，解释归解释，没全搅在一起。
结果会存进 .understand-anything/knowledge-graph.json。
后面代码改了，也不用每次从头扫，只处理变更文件。大仓库要是次次重跑，基本两回就懒得用了。这个细节反而比“知识图谱”几个字重要。
还有个 /understand-diff。
提交前跑一下，先看改动碰到了哪些节点，顺着会影响到哪。做 code review 时，这种东西比自动写一段总结实在。总结经常很漂亮，漏掉的依赖照样漏。
它也能切到 domain view，把代码节点往业务流程上挂。这个部分我会先保留意见。业务语义到底准不准，还是得拿真实项目跑，Demo 图好看没用。
项目页显示已有 23.9k Star，也接了 Claude Code、Codex、Cursor、Copilot、Gemini CLI 这些入口。
我大概会在两种时候开它。
刚接手老项目。或者新同事入组，先让他自己顺着图走一圈。
别急着读完整个仓库。先找入口，找主链路，看看哪几根线不能乱碰。这样下手，至少没那么瞎。
GitHub 地址：openspug/spug