AI 时序图生成器

时序图

时序图用参与者与消息箭头描述调用顺序，适合登录、支付与链路讲解。构图AI 可一句话生成可编辑手绘时序图。

登录可免费体验 1 次；VIP 期内不限制日常画图；导出 PNG / SVG / .excalidraw。

什么时候用

• 接口联调前：前后端、多服务对齐「先调谁、带回什么、失败怎么回」。
• 排查延迟与故障：把超时、重试、回调画出来，定位卡在哪一跳。
• 协议说明：OAuth、支付、WebSocket 握手等需要严格顺序的场景。
• 新人 onboarding：比口头讲「登录大概是这样」更可核对、可评审。

不适合表达组织汇报关系（用组织结构图），也不适合表达数据表结构（用 ER 图）。若只有单系统内部步骤与判断，流程图往往更轻量；时序图的价值在「多方协作的时间顺序」。

核心元素

画时序图时建议固定节奏：先定参与者名单 → 画主成功路径 → 再补失败、超时与回调。消息命名要可执行，例如「校验验证码」「签发 JWT」，避免「处理一下」。

排版规则（时序专用）

1. 参与者从左到右按调用链排序：用户/客户端靠左，基础设施靠右，箭头多为短跳。
2. 生命线间距均匀：过密会导致箭头文字重叠，过疏则画面空洞。
3. 请求与返回成对：同步调用务必画返回，否则联调对不上字段来源。
4. 垂直方向只增不减：时间永远向下；不要为了省空间把晚发生的消息画到上方。

反例：把「浏览器、CDN、网关、鉴权、用户服务、订单服务、库存、支付、短信、日志、监控」十一个参与者全画进一张支付时序——线交叉到无法讲解。应拆成「支付主链路」与「通知/对账」两张，或合并同角色实例。

Prompt 好坏对比

实践建议：先画「主成功路径」再叠加失败与超时；评审时也可分两张图——主路径与异常路径。

常见错误

1. 参与者过多：线交叉、箭头密成一团，读者抓不住主路径。
2. 漏掉返回或回调：只画请求不画响应，联调时对不上字段来源与错误码。
3. 把业务判断全塞进时序：复杂分支应拆图，或在旁注简写条件，避免一张图讲完所有故事。
4. 命名含糊：箭头上写「调用接口」无法落地；应写清动作与关键资源。
5. 用时序代替架构：时序讲「一次调用怎么走」，架构讲「系统长期长什么样」，二者不要互相顶替。

与相邻图类型的区别

若消息经过消息队列，箭头上写清「投递」与「消费」是两次交互，不要画成同步往返；否则研发会误以为调用方在等待结果。

第三方回调类链路要把「验签失败」画出来，否则联调只覆盖快乐路径，上线后对账会对不上。

用构图AI怎么画

选择「时序图」，写清参与者与场景，例如：「画微信支付时序图，含用户、商户、微信支付平台」。生成后核对请求/返回是否成对，标注关键接口名，再导出。可先对照 OAuth、支付示例页的参与者粒度，再改成自己的链路。

构图AI 共 12 种技能，复杂系统可搭配架构图（看全景）与流程图（看业务）使用，形成「结构—流程—交互」三件套。若只是产品对齐步骤，先用流程图往往更省事。

相关：时序图入门 · OAuth 示例 · 支付时序示例 · 登录时序示例 · 使用此技能画图

联调前怎么用这张图

时序图的读者通常是要写代码的人。评审时投影大屏，按箭头逐条念「谁在什么时刻请求谁、带回什么」：

• 念不顺的地方，就是实现时会踩坑的地方。
• 每条消息最好能对上真实接口名或事件名，临时代号也比「调用一下」强。
• 异步回调单独成段：先画完同步往返，再画「平台 → 商户」的后到消息，避免和请求叠在同一高度。

把会上改过的参与者名单和消息顺序写回 prompt，下次重生成比从零描述更快。登录、支付类可先对照 OAuth 示例、支付时序、登录时序，再换成你们的服务名。

需要业务步骤给产品看时，另开流程图；需要看系统长期长什么样时，另开架构图。三张图共用同一套专有名词，文档才不会各说各话。