AI时代，UML还有用吗？

"

以前是"先画图再写代码"，现在是"先写代码再画图"。

---

问题来了

AI写代码越来越快，那UML还有用吗？

有人说："代码都自动生成了，还画什么图？"

这是个真问题。

但答案可能跟你想的不一样。

---

根本变化

AI生成代码之后，UML的角色发生了根本转变：

从「前置设计工具」→「后置理解工具」

以前是：先画UML → 再写代码
现在是：先写代码 → 再生成UML

不是设计工具，是理解工具。

---

用途一：代码理解的可视化层

你让AI理解一个20000行的项目。

它会做什么？

第21章的 Understand-Anything：

• 扫描文件
• 提取函数
• 分析类
• 构建知识图谱——节点和边

这是原材料。

但知识图谱太抽象了——几万个节点、几十万条边，人脑根本看不过来。

UML把这些节点组织成有意义的模式：

• 类图 → 把散落的类型组织成领域模型
• 序列图 → 把函数调用链组织成交互故事

知识图谱是面粉，UML是面包。

举个例子

你接手一个电商系统。

AI先跑一遍分析：

节点：User, Order, Product, Payment, Shipping...
边：User-Order, Order-Product, Order-Payment...

这是原材料。

然后AI生成一张类图：

┌─────────┐    ┌─────────┐    ┌─────────┐
│  User   │───→│  Order  │───→│ Payment  │
└─────────┘    └─────────┘    └─────────┘
                    ↑
                    │
              ┌─────────┐
              │ Product │
              └─────────┘

一眼就看懂了：

• 用户下订单
• 订单包含商品
• 订单关联支付

这就是可视化层的价值——

把抽象的知识图谱，变成人脑能理解的图形。

---

用途二：AI生成代码的质量验证

AI生成了2000行代码。

你怎么知道架构没被写烂？

传统做法

人工review，一行行看。

但代码长了，人也累了，容易漏。

UML做法

生成一张类图。

问题一目了然：

• 继承链有没有循环引用？
• 依赖关系是不是单向？
• 有没有不该耦合的类绑在一起？

再生成一张包图：

违反Clean Architecture的箭头规则：

• 领域层 → 依赖 → 基础设施层？（反向！）
• 表现层 → 直接调用 → 数据访问层？（跳过业务层！）

UML就是AI代码的架构X光。

实战案例

你让AI写一个用户系统。

代码写完了，让AI生成类图：

┌─────────┐
│  User   │
└────┬────┘
     │
     ├──→ UserController
     ├──→ UserService
     ├──→ UserRepository
     └──→ UserValidator

看起来没问题？

再看依赖方向：

UserController ──→ UserService ──→ UserRepository
     ↑                                    ↓
     └────────────────────────────────────┘

循环依赖！

UserRepository反过来依赖UserController——架构烂了。

这种问题，看代码很难发现，看图一秒就看出来了。

---

用途三：团队沟通的通用语言

不同的人看同一段AI代码，脑子里画的图可能完全不一样。

• 前端想的是"API怎么调"
• 后端想的是"数据怎么存"
• 架构师想的是"模块怎么分"

没有统一语言，沟通就是各说各话。

UML给了什么？

一套标准化的可视化符号。

所有人坐下来看同一张图，对"这段代码长什么样"的理解不会差太远。

场景

团队review一段AI生成的订单流程代码。

• 开发说："逻辑没问题"
• 产品说："流程是这样吗？"
• 测试说："边界在哪？"

吵了半小时，谁也说服不了谁。

这时，让AI生成一张序列图：

用户   订单服务   库存服务   支付服务
 │        │          │          │
 │──下单─→│          │          │
 │        │──检查库存→          │
 │        │←────OK───│          │
 │        │──创建支付──────────→│
 │        │←────支付结果────────│
 │←─订单ID│          │          │

所有人一眼就看懂了：

• 先检查库存
• 再创建支付
• 最后返回订单ID

产品说："对，就是这个流程。"

测试说："那我测这三个节点。"

沟通成本直接降一半。

---

总结

AI时代，UML没死。

它的角色变了：

以前	现在
前置设计工具	后置理解工具
手工绘制	AI自动生成
规范驱动	质量验证

三个核心用途：

1. 代码理解的可视化层 — 把知识图谱变成人脑能看的图
2. AI代码的质量验证 — 用图一眼看出架构问题
3. 团队沟通的通用语言 — 所有人看同一张图，不再各说各话

---

实操建议

1. 接手旧项目，先让AI生成类图

看图比看代码快十倍。

2. AI写完代码，生成UML验证架构

别等review时才发现架构烂了。

3. 团队讨论，带着图开会

代码是给机器看的，图是给人看的。

---

最后

UML不是考试的，是用的。

AI让它变得更强大——

以前画图要半天，现在一秒生成。

以前要学一堆符号，现在AI帮你画。

核心能力不是画图，是读图。

能从图中看出问题，才是真的本事。

---

关注公众号 Fen9Pi，聊聊AI时代的软件工程。