图表图表类型
AI 时序图生成器
写清楚谁调谁,拿一张带参与者和箭头的时序图。
点一个试试 —— 会直接带进生成器
OAuth 2.0 授权码流:用户在客户端应用点击登录,重定向到授权服务器,登录并同意授权,授权服务器通过重定向返回 code 给客户端,客户端用 code + client_secret 换取 access_token,再用 token 调用资源服务器 API。
Try it →Stripe 结账流程:前端通过后端创建 payment intent,后端调 Stripe API,Stripe 返回 client_secret,前端在 Stripe 侧确认支付,Stripe 通过 webhook 通知后端支付成功,后端履约订单并通过 WebSocket 推送给前端。
Try it →Saga 模式:订单服务创建订单(pending),发布事件,支付服务扣款并发布结果事件,成功则库存服务锁库存,失败则支付服务补偿退款。订单服务监听所有事件最终确定状态。
Try it →WebSocket 聊天消息:客户端 A 通过 WebSocket 发消息到服务器,服务器持久化到数据库,通过 B 的 WebSocket 推送给接收方 B,B 发送已读回执,服务器更新消息状态并通知 A。
Try it →适用场景 AI 时序图生成器
接口文档和联调对齐
REST 或 GraphQL 接口互相调用的时候 —— 鉴权、限流、重试、回调 —— 时序图把每次调用的来龙去脉写死:谁调的、什么顺序、返回什么。
登录和鉴权握手
OAuth 2.0、SAML、JWT 刷新、WebAuthn,凡是多方交换令牌的协议。时序图逼着你给每个角色和每条消息命名,安全评审的时候要用。
服务之间的消息往来
微服务编排、事件驱动、消息队列(Kafka、RabbitMQ)、WebSocket 和 SSE 推送。没有一个中心调度的时候,时序图能说清楚谁发的、谁收的。
数据库事务和加锁
多步骤事务、乐观锁、两阶段提交。BEGIN、SELECT FOR UPDATE、INSERT、COMMIT 的先后关系,以及锁超时之后会发生什么,画出来最清楚。
事件驱动的系统
一个领域事件扇出给多个订阅方、saga 协调长事务、CQRS 里一条命令触发一串事件。一张时序图往往比翻链路追踪更快讲明白。
对话模式下的 AI 时序图生成器 —— 从一句几乎什么都没说的话开始
一句话 prompt 也能出箭头,但你没点名的参与方、没提的失败分支,模型只能自己编。对话模式只就那个会改变箭头顺序的地方问一句,剩下的直接画,画完再告诉你哪些参与方是它自己加的。下面这张移动端 token 刷新时序图,起点是一句几乎什么都没说的话。
- 每次刷新都把 refresh token 轮换掉,用过的立刻作废
- 所有调用都走了 API 网关,没让 App 直连各个服务
- 在认证服务后面加了一个 Redis Token 存储来放 refresh token 记录
- 拿 GET /orders 当那个撞上 401 的请求
- 请求画成实线箭头,响应画成虚线的异步箭头
四句话换来一张带 401 触发刷新、refresh token 轮换、原请求重试、以及重放检测吊销整串 token 的时序图 —— 开头那句话里一样都没有。同样一句话直接一次性生成,大概率只给你一个客户端、一个服务端和一条顺利路径,而重放那段漏没漏,得你自己看出来。
详细说明
要说清楚几方之间谁先调谁、传了什么、返回了什么,时序图是最合适的。接口联调、登录鉴权握手(OAuth、SAML、JWT 刷新)、服务之间的消息往来、带锁的数据库事务、WebSocket 和 SSE 推送,都属于这一类。
它在工程文档里用得多,是因为它逼着你把每个参与者点名。你没法含糊地写「后端处理一下」—— 每根箭头都得写清楚从谁到谁、传的是什么。方案评审的时候这一点很有用:评审的人可以一根箭头一根箭头地挑。
一个判断标准:你口头解释的时候「然后……然后……然后……」说了三次以上,要画的就是时序图,不是流程图。时序图能表达异步消息、参与者的忙碌区间,还能在单根箭头上加注释说明原因。它不擅长的是完全并行、没有明确先后的关系,那种画组件图更合适。
自己试一下?
不知道怎么描述?
对话模式里 AI 会先问你两三个问题 —— 谁参与、发生什么、异常分支怎么走 —— 弄清楚了再动笔。
想画得更规范?
教程里讲了常用符号、几种基本结构、九条画法规范,还有可以直接拿去用的 prompt 模板和真实业务例子。