Understand-Anything 评测：当代码变成一张可以走进去的地图
上个月我接了个活儿，帮一个朋友看他们公司的订单系统。2018 年写的 NestJS + TypeORM，七八万行代码，前任开发半年前就跑了，文档停留在"TODO: 补充文档"的阶段。我打开项目，翻了半小时，脑子里只有一个念头：这玩意儿到底是从哪里开始跑的？
我试过 grep，试过 IDE 自带的"查找引用"，但面对一个你完全不熟悉的代码库，这些工具给你的只是碎片，拼不出全貌。就在那时候，我刷到了 Understand-Anything。
这是什么
这个项目做的事说起来不复杂：把你的代码转成一张知识图谱。函数调用、变量引用、类型定义、模块依赖，全部变成图上的节点和边，然后你可以直接在上面搜索、跳转、甚至用自然语言问问题。GitHub 3 万星，光一天就涨了 5000 多，我觉得不会是纯靠营销冲上去的，就决定试一下。
简而言之，它的核心能力有三层：
- 代码解析层 —— 用 Tree-sitter 做AST分析，提取函数、类、接口、变量之间的调用引用关系
- 图谱构建层 —— 把解析结果转换成图谱数据库（类似Neo4j的图结构）
- AI 查询层 —— 把图谱数据作为上下文喂给 LLM，让你能用自然语言问代码
安装和基本使用
安装没什么好说的，一行命令搞定：
npm install -g understand-anything
然后 ua init ./你的项目，工具就开始扫描代码、生成图谱。我那个朋友的项目大概 8 万行，初始化花了一分多钟，生成了一个 JSON 文件，10 来 MB。速度比我预期快不少。
CLI 界面比较朴素，就是命令行加颜色高亮，没有图形界面。刚开始我还有点嫌弃，后来想明白了——它的定位不是给你"看"图谱的，而是给 AI 工具提供数据支撑的。真正用起来是在 Cursor 里：官方有对应的插件，装好之后你可以在 AI 对话里直接查询代码库。
还有其他几种使用方式：
- VS Code 插件 —— 不需要离开编辑器就能查询
- REST API —— 可以作为后端服务集成到CI/CD流水线里
- CLI 命令行 —— 适合在终端里快速查询
实战：让我惊艳的几个问题
这才是真正让我眼前一亮的地方。我问了它几个问题：
"从用户提交订单到支付完成，整个调用链是什么"
AI 列出了 11 个关键函数和它们之间的调用关系，其中三个函数我之前完全没注意到——它们藏在一个叫 order-status-transition.ts 的文件里，如果不是通过调用链追溯，根本不会想到订单状态机是通过这种方式驱动的。
"这个模块的错误处理有什么遗漏"
它指出了两个边界情况是之前从没在注释里提过的：一个是网络超时后的重试逻辑缺失，另一个是并发场景下状态竞态。这两个问题在流量的确不会暴露，但大促期间随时可能炸。
"这个项目的整体架构是什么"
它给了一张模块依赖图，用的是 mermaid 格式，我之前以为整个项目是一个的整体，结果发现其实是三个相对独立的服务在相互调用，其中一个还在用老版本的 RPC 框架。这个信息对后续重构的优先级判断非常有用。
不是那种泛泛而谈的"这个函数处理了xxx"，而是基于实际代码结构给的具体分析。这种质量在同类工具里真的少见。
它适合谁？
经过这段时间的使用，我觉得 Understand-Anything 最适合以下几类场景：
场景一：接手老项目。 这是最直接的使用场景。接手一个缺文档的老代码库，传统做法是从小功能开始改，边改边理解。有了 Understand-Anything，你可以先看整体架构，再有针对性地深入细节。
场景二：代码review。 当你review一个较大的PR时，可以用它快速理解改动的波及范围。"我在这个函数里改了逻辑，会影响哪些模块"——这类问题以前要手动查调用链，现在几秒钟就有答案。
场景三：技术方案评审。 写方案的时候不确定某个改动点会不会有连锁反应，可以提前用图谱查询影响范围，而不是等上线了才知道。
场景四：新人入职。 团队新成员前三天最痛苦的就是"看不懂代码在干嘛"。有这个工具，新人可以直接问"这个项目的用户登录流程是什么"，比挨个翻代码效率高太多。
不完美的地方
不过这东西不是没有缺点。
大项目初始化慢。 我拿一个 20 万行的 monorepo 试了一下，跑了将近 7 分钟，生成的图谱 80 多 MB。查询的时候偶尔会有几秒延迟，全库范围的路径查询等个 3-5 秒是常事。日常开发倒还能接受，但如果想塞进 CI/CD 流水线里，缓存策略得好好想想。
图谱不自动更新（重点）。 图谱生成之后，它不会自动跟着代码变。改了代码之后如果不重新跑 ua sync，AI 给你的答案还是基于旧图谱的。我第一次用的时候就很自信地改了三个文件，然后问 AI 调用关系有没有变化，结果 AI 给我的是旧的答案，完全对不上。这个坑官方文档里写了，但不太显眼，容易中招。
我现在的解决办法是在 .git/hooks/post-commit 里加了一条自动运行 ua sync 的脚本，每次提交代码后自动更新图谱。但这也有个副作用：commit 的时候会慢几秒。
不理解业务逻辑。 图谱能告诉你"代码是怎么写的"，但理解不了"业务逻辑是什么"。想让 AI 帮你分析业务流程对不对，它做不到——它画不出业务意图，只能画出代码结构。这一点是所有代码分析工具的通病，Understand-Anything 也不例外。
超大 monorepo 不建议全量分析。 如果你的 monorepo 有几十个子项目，别一上来就全量生成图谱。我试过一个 50 个子包的 monorepo，等了 15 分钟还没跑完，出来 200 多 MB 的图谱，根本没法用。正确的姿势是先用增量模式，只分析你关心的那个 package。
竞品对比
跟同类的工具比，我觉得 Understand-Anything 占的位置挺独特的。
Sourcegraph 是很好，但配置复杂价格也贵，小团队用起来有点浪费。Sourcegraph 更适合几十上百人的大团队，它 strengths 在代码搜索和导航，而不是图谱分析。
Mermaid 和 PlantUML 画出来的图是静态的，看看可以，没法交互。你得自己手动写 Mermaid 代码或者画图，不像 UA 那样自动从代码生成。
deepdeps 轻量但功能太轻，能做文件级别的依赖分析，但做不了函数级别的调用链追踪。
CodeGraph / ast-grep 这些工具在特定场景下也很好用，但它们是开发者工具，不是面向 AI 场景设计的。
Understand-Anything 的好处是零配置、免费、能跟 Cursor / Claude Code / Copilot 这类 AI 工具直接集成，对于个人开发者或者小团队来说性价比拉满。
使用小技巧
官方文档说的不多，我总结了一些提高效率的技巧：
- 先问整体的，再问局部的。 比如先问"这个项目的整体架构"，确认大方向对了，再深入某个模块的具体逻辑。
- 用它来理解第三方库。 有些库的文档很差，源码又多，用 UA 问"这个库的核心流程是什么"，比翻源码快得多。
- 配好 .uaignore 文件。 如果你项目里有大量生成代码（比如 GraphQL 自动生成的类型定义），记得加到忽略列表里，可以有效缩小图谱体积。
- 结合 git blame。 "这个函数谁写的"加上"为什么这么写"形成组合拳，效率翻倍。
总结
总结一下我的感受：如果你经常接手陌生代码库、维护缺乏文档的老项目，或者你已经在做 AI 编程（Cursor / Claude Code），Understand-Anything 值得装一个。
它不是万能的，业务逻辑还得你自己想明白，但至少在"搞清楚代码结构"这件事上，它能帮你省大量时间。对我来说，它已经成了看新项目时的第一步——先 ua init，再问 AI，比闷头翻代码效率高太多了。