UML 在 AI 时代的三个用途：从「前置设计」到「后置理解」
AI 生成代码之后。
UML 的角色从「前置设计工具」变成了「后置理解工具」。
三个具体用途：
代码理解的可视化层。
AI 生成代码的质量验证。
团队沟通的通用语言。
核心转变
传统时代：
UML 是前置设计工具。
在写代码之前，先画类图、序列图、活动图。
然后根据设计写代码。
AI 时代：
UML 是后置理解工具。
AI 已经生成了代码。
你用 UML 来理解、验证、沟通这段代码。
为什么？
因为 AI 生成代码的速度太快了。
你来不及先设计再编码。
你需要的是快速理解 AI 生成的代码。
UML 从「设计」变成了「理解」。
用途一：代码理解的可视化层
第 13 章的 Understand-Anything 产出知识图谱。
文件、函数、类的节点和边。
但这只是原材料。
UML 把这些节点组织成有意义的模式。
类图：散落的类型 → 领域模型
类图把散落的类型组织成领域模型。
知识图谱告诉你：
- 有哪些类
- 类之间有什么关系
类图告诉你：
- 这些类如何组合成领域模型
- 聚合、组合、继承、关联的区别
- 哪些是核心实体，哪些是辅助类
- 领域的边界在哪里
示例：
知识图谱：
User
Order
Product
Payment类图：
┌─────────┐ ┌─────────┐ ┌─────────┐
│ User │────│ Order │────│ Product │
└─────────┘ └─────────┘ └─────────┘
│
│
┌─────────┐
│ Payment │
└─────────┘知识图谱是节点和边的集合。
类图是领域的视觉故事。
序列图：函数调用链 → 交互故事
序列图把函数调用链组织成交互故事。
知识图谱告诉你：
- 函数 A 调用函数 B
- 函数 B 调用函数 C
序列图告诉你：
- 这些调用如何随时间展开
- 谁是调用者，谁是被调用者
- 同步调用还是异步调用
- 哪些步骤是并行的，哪些是串行的
- 错误处理路径在哪里
示例：
知识图谱：
createOrder → validateOrder → processPayment → sendConfirmation序列图：
User System PaymentGateway EmailService
│ │ │ │
│──────────>│ │ │ createOrder
│ │ │ │
│ │──────────>│ │ validateOrder
│ │ │ │
│ │ │─────────────>│ processPayment
│ │ │ │
│ │<───────────│ │
│ │──────────>│ │ sendConfirmation
│ │ │ │
│<──────────│ │ │知识图谱是调用链。
序列图是交互故事。
核心价值
知识图谱是原材料。
UML 是成品。
知识图谱给你：
- 结构信息
- 关系信息
- 静态快照
UML 给你：
- 可视化组织
- 模式识别
- 动态故事
- 领域洞察
没有 UML：
你有 1000 个节点和 5000 条边。
你看了一小时，还是不知道这段代码在做什么。
有了 UML：
你有 10 个类图，5 个序列图。
你看 10 分钟，就理解了整个系统的架构。
用途二：AI 生成代码的质量验证
AI 生成了 2000 行代码。
你怎么知道架构没被写烂？
生成一张类图。
生成一张包图。
UML 就是 AI 代码的架构 X 光。
类图：继承链的健康检查
生成一张类图。
一目了然：
- 继承链有没有循环引用
- 继承层次是不是太深
- 有没有滥用继承
- 组合关系是不是清晰
示例：健康的继承
┌─────────┐
│ Animal │
└─────────┘
△
│
┌──┴──┐
│ │
┌─────┐ ┌─────┐
│ Dog │ │ Cat │
└─────┘ └─────┘清晰的层次，单一职责。
示例：不健康的继承
┌─────────┐
│ Animal │
└─────────┘
△
│
┌─────────┐
│ Mammal │
└─────────┘
△
│
┌─────────┐
│ Dog │
└─────────┘
△
│
┌─────────┐
│Labrador │
└─────────┘
△
│
┌─────────┐
│ MyDog │
└─────────┘继承层次太深，过度设计。
没有类图：
你读 2000 行代码，才发现继承链有问题。
有了类图：
你看一眼就知道架构是否健康。
包图：依赖方向的 Clean Architecture 检查
生成一张包图。
一目了然：
- 依赖方向有没有违反 Clean Architecture 的箭头规则
- 内层是否依赖外层
- 核心业务逻辑是否被隔离
- 框架细节是否渗透到业务层
Clean Architecture 的依赖规则：
外层依赖内层，内层不依赖外层。
┌─────────────────┐
│ Frameworks │ ←── 依赖方向
└─────────────────┘
△
│
┌─────────────────┐
│ Adapters │
└─────────────────┘
△
│
┌─────────────────┐
│ Use Cases │
└─────────────────┘
△
│
┌─────────────────┐
│ Entities │
└─────────────────┘示例：健康的依赖
Controllers → Services → Repositories → Entities箭头方向向外，依赖方向向内。
示例：不健康的依赖
Controllers ← Services ← Repositories ← Entities内层依赖外层，违反 Clean Architecture。
没有包图：
你读 5000 行代码，才发现依赖方向错了。
有了包图：
你看一眼就知道架构是否违反规则。
核心价值
UML 就是 AI 代码的架构 X 光。
AI 生成代码：
- 速度快
- 量大
- 你来不及逐行审查
UML 验证：
- 一张类图，看透继承关系
- 一张包图，看透依赖方向
- 一张序列图，看透交互流程
没有 UML：
你不知道 AI 生成的代码架构是否健康。
有了 UML：
你一眼就能看出问题。
用途三：团队沟通的通用语言
不同的人看同一段 AI 代码。
脑子里画的图可能完全不一样。
UML 给了一套标准化的可视化符号。
所有人坐下来看同一张图。
对「这段代码长什么样」的理解不会差太远。
问题：每个人脑子里的图不一样
同一段 AI 代码：
产品经理脑子里的图：
- 用户下单 → 支付 → 发货
- 流程图，关注业务流程
前端工程师脑子里的图：
- 用户点击按钮 → 发送请求 → 显示结果
- 序列图，关注交互
后端工程师脑子里的图：
- Controller → Service → Repository → Database
- 类图，关注架构
DevOps 脑子里的图：
- Server → Database → Cache → Queue
- 部署图，关注基础设施
问题：
每个人脑子里的图不一样。
沟通时就会产生误解。
产品经理说：「支付流程太复杂了。」
前端工程师说：「就三个接口，哪里复杂？」
后端工程师说：「需要保证事务一致性，当然复杂。」
DevOps 说：「部署了 5 个服务，确实复杂。」
每个人说的「支付流程」都不是同一个东西。
解决方案：UML 作为通用语言
UML 给了一套标准化的可视化符号。
所有人坐下来看同一张图。
支付流程的 UML 序列图：
User Controller Service PaymentGateway Database
│ │ │ │ │
│──────────>│ │ │ │ createOrder
│ │──────────>│ │ │
│ │ │ │ │ validate
│ │ │─────────────>│ │
│ │ │ │ │ processPayment
│ │ │ │───────────>│
│ │ │ │<───────────│
│ │ │<─────────────│ │
│ │<──────────│ │ │
│<──────────│ │ │ │现在所有人看同一张图：
产品经理说：「原来有 5 步，确实复杂。」
前端工程师说：「我只管第 1 步和第 7 步。」
后端工程师说：「中间 3 步是我的职责。」
DevOps 说：「PaymentGateway 和 Database 是我的职责。」
大家对「支付流程」的理解达成一致。
核心价值
UML 是团队沟通的通用语言。
没有 UML：
每个人脑子里有自己的图。
沟通时产生误解。
争论半天，才发现大家说的不是同一件事。
有了 UML：
所有人看同一张图。
对「代码长什么样」的理解一致。
沟通效率提升。
三个用途的协同
三个用途不是独立的。
它们是一个工作流。
工作流：AI 生成代码 → UML 理解 → UML 验证 → UML 沟通
步骤 1：AI 生成代码
AI 生成 2000 行代码步骤 2：UML 理解
生成类图、序列图、包图
理解代码的架构、流程、依赖步骤 3：UML 验证
检查类图：继承链健康吗？
检查包图：依赖方向正确吗？
检查序列图：交互流程合理吗？步骤 4：UML 沟通
团队坐下来看同一张图
对代码的理解达成一致循环：
如果验证发现问题，回到步骤 1，让 AI 重新生成。
如果沟通达成一致，继续下一步。
UML 在 AI 时代的具体实践
1. AI 生成代码后自动生成 UML
工具链：
# AI 生成代码"
ai-generate-code --prompt "实现用户下单流程"
# 自动生成 UML
plantuml-from-code --src src/ --output uml/
# 生成类图
plantuml-from-code --type class --src src/ --output uml/class.puml
# 生成序列图
plantuml-from-code --type sequence --src src/ --output uml/sequence.puml
# 生成包图
plantuml-from-code --type package --src src/ --output uml/package.puml2. 集成到 CI/CD
CI/CD 流程：
AI 生成代码
↓
自动生成 UML
↓
检查 UML 规则
↓
违反规则？→ 失败，人工审查
↓
通过规则？→ 继续部署检查规则示例：
# .uml-rules.yaml
inheritance:
max_depth: 3
no_cycles: true
dependency:
clean_architecture:
entities:
- no_depend_on: ["frameworks", "adapters"]
use_cases:
- no_depend_on: ["frameworks"]
adapters:
- no_depend_on: ["entities", "use_cases"]3. 文档自动生成
UML + Markdown = 自动文档
# 生成 UML
plantuml-from-code --src src/ --output uml/
# 生成文档
markdown-from-uml --uml uml/ --output docs/
# 输出
docs/
architecture.md # 架构说明
class-diagrams.md # 类图说明
sequence-diagrams.md # 序列图说明
package-diagrams.md # 包图说明4. Code Review 的标准附件
每次 AI 生成的代码，附带 UML 图。
Code Review 流程：
AI 生成代码
↓
生成 UML
↓
创建 PR
↓
Code Review
↓
审查代码 + 审查 UML
↓
批准 PR写在最后：UML 的复兴
UML 没有死。
它只是换了个角色。
传统时代：
UML 是前置设计工具。
在写代码之前，先画 UML。
AI 时代：
UML 是后置理解工具。
在 AI 生成代码之后，用 UML 来理解。
三个用途：
- 代码理解的可视化层 —— 知识图谱是原材料，UML 是成品
- AI 生成代码的质量验证 —— UML 是 AI 代码的架构 X 光
- 团队沟通的通用语言 —— 所有人看同一张图，理解一致
UML 的复兴。
不是因为设计需要它。
而是因为理解需要它。
AI 生成代码的速度越来越快。
我们需要更快的理解速度。
UML 就是这个加速器。
UML 在 AI 时代的三个用途
从「前置设计」到「后置理解」