AI UML 类图生成器

描述类、属性和继承关系,拿一张 UML 类图。

点一个试试 —— 会直接带进生成器

适用场景 AI UML 类图生成器

用对话模式画 UML 类图 —— 从一句含糊的话开始

一句话 prompt 能把你提到的每个名词都变成一个框,真正会猜错的是箭头:继承还是接口实现、组合还是聚合,在中文描述里长得一模一样。对话模式只就那根会改变设计的箭头问一句,剩下的直接画,画完再把它替你定的箭头一条条列出来。下面这张图是一个 SaaS 的对外通知服务,起点是一句故意含糊的话。

帮我画一下通知服务的类图。
反问
几个渠道之间是共用一个抽象基类(重试逻辑写在基类里),还是各自实现同一个接口、各自带传输客户端?
共用接口,各渠道自己带传输客户端
抽象基类,重试逻辑放基类里
第一版草稿。三个渠道用 ..|> 直接来自你的回答。其余每一根箭头 —— 包括 Notification 和 DeliveryAttempt 之间的 *-- —— 都是它自己定的,没来问你,而是写在下面。
第一版草稿。三个渠道用 ..|> 直接来自你的回答。其余每一根箭头 —— 包括 Notification 和 DeliveryAttempt 之间的 *-- —— 都是它自己定的,没来问你,而是写在下面。
有几处你没提,我先按常见做法补上了
  • 把「通知服务」理解成了对外投递那条链路,不是站内的消息列表
  • DeliveryAttempt 按跟着 Notification 一起删处理(*--),没当成单独留存的审计日志
  • 把 Notification.vars 定成了 Map<string, string> —— 模板变量长什么样你没说
  • 给 Channel 加了 supports() 方法,dispatch() 才有东西可以用来选渠道
  • 给 Notification 加了 priority: int 字段
  • 把 dispatcher 和渠道之间画成了组合(*--),即渠道随 dispatcher 一起销毁
就这样删掉勾中的 1 项
已去掉 Notification 上的 priority 字段,另外三条还留在图里。
渠道是启动时按配置注册一次、所有 dispatcher 实例共用的,不会跟着 dispatcher 一起销毁,那条关系应该是聚合不是组合。另外给 dispatcher 加一个它读的 RetryPolicy(maxAttempts、backoffMs)。priority 和排期一类的字段以后也别加回来,那是营销投放系统管的。
最终版。只有一条关系从 *-- 变成了 o--,Notification 和 DeliveryAttempt 之间那条组合没动 —— 那条是你亲口确认过的。
最终版。只有一条关系从 *-- 变成了 o--,Notification 和 DeliveryAttempt 之间那条组合没动 —— 那条是你亲口确认过的。

五句回答换来一张每个箭头都有出处的类图:..|> 是渠道契约,*-- 是随通知一起销毁的投递记录,o-- 是活得比 dispatcher 久的渠道。一次性 prompt 也会给你这三个箭头,只是不会告诉你它凭什么这么选 —— 而一条画错的 *--,读起来是一个你代码里根本不存在的生命周期承诺。

用这段对话开始 →打开对话模式,上面那句话已经替你填好了。

详细说明

类图讲的是代码的结构:有哪些类型、每个类型有什么字段和方法、类型之间靠继承、组合还是关联连起来。

三个常用场合:新人文档里说明领域模型怎么组织;技术方案里提一套新的类层次或者一次重构;面试白板上快速把设计画出来。它也是写设计模式最省事的方式 —— 工厂、策略、观察者、访问者各有一套固定画法,看的人一眼就认出来。

Mermaid 的 classDiagram 支持常用的 UML 记号:可见性(`+` 公开、`-` 私有、`#` 受保护、`~` 包内)、抽象类和抽象方法、`<<interface>>` 标注、泛型,以及各种关系箭头(继承 `<|--`、组合 `*--`、聚合 `o--`、关联 `--`、依赖 `..>`)。它不是完整 UML —— 没有泳道,也没有完整的活动图语义 —— 但写工程文档的时候这反而是好事,能逼着你写简单点。真要完整 UML,那多半是拿错工具了。

自己试一下?

不知道怎么描述?

对话模式里 AI 会先问你两三个问题 —— 谁参与、发生什么、异常分支怎么走 —— 弄清楚了再动笔。

试试对话模式

想画得更规范?

教程里讲了常用符号、几种基本结构、九条画法规范,还有可以直接拿去用的 prompt 模板和真实业务例子。

看教程

相关工具