做了这么多年系统设计我一直觉得画图比写代码更见功力。代码写错了顶多一个 Bug架构图画歪了整个团队可能就要在一个错误的方向上忙活几个月。时序图作为描述对象间交互的利器在电商这种高并发、多系统协作的场景里几乎是每个技术方案的必备附件。以前手画时序图费时费力线条一多就乱成一团后来接触了 Visual Paradigm后面简称 VP的 AI 辅助建模功能这个过程才慢慢变得可控。这篇文章从时序图的基础图形语言讲起到 Visual Paradigm 的手绘与 AI 辅助流程再到电商订单、支付回调这类真实业务场景的建模全过程。适合正在做系统设计、接口方案评审或者想在简历上写熟练使用 UML 建模工具的同学。我会把实际项目中踩过的坑也一并写出来希望能帮你把脑子里的业务逻辑真正变成一张别人也读得懂的时序图。1. 为什么选择 Visual Paradigm 画时序图1.1 时序图在系统设计中的角色先把时序图这个名词对齐一下。它的含义在两个圈子里不太一样软件领域说的时序图是 UML统一建模语言里的 Sequence Diagram描述不同对象之间按时间顺序的消息往来而嵌入式领域说的时序图比如 I2C、SPI 那些画的是信号线高低电平随时间的变化。这两者常常被人混为一谈导致讨论半天讲的是两件事。本文核心是 UML 时序图但在第 2 章我也会专门做一次辨析。UML 时序图解决什么问题一句话说明谁在什么时刻给谁发了什么消息、期待什么结果。它把代码还没动工之前的协作关系讲清楚。在电商系统里一次下单请求可能横跨 App 前端、API 网关、订单服务、库存服务、账户服务、数据库、消息队列甚至还要对接外部支付渠道。这么多人协同如果只靠口头描述碰上一个多分支、多回调的场景基本就是对不齐、互相甩锅的节奏。时序图的价值就是把时间维度和交互维度压到一张图上谁先谁后、谁等谁、谁失败怎么处理一目了然。1.2 Visual Paradigm 相比绘图工具的核心优势市面上的画图工具很多draw.io、Visio、ProcessOn、PlantUML 我都用过但 VP 在 UML 建模这个领域的定位不太一样。它本质上是一个建模工具而不是单纯的画图工具。差异在哪普通画图工具画的是形状和线条图的背后没有任何语义VP 里每一个生命线、每一条消息都是带类型的模型元素模型和图是一体的。你在图上拖一个 Lifeline实际上是在模型层面创建了一个参与者后续如果改了模型图也跟着更新。第二个优势是覆盖面。VP 支持 UML 的绝大多数图种用例图、类图、时序图、状态机图、活动图、组件图、部署图等还支持 BPMN、SysML、ArchiMate 这些扩展。这意味着你可以用同一个工具、同一个模型体系把需求分析、概要设计、详细设计一路画下去而不是换一个阶段就换一个工具然后图与图之间完全对不上。第三个优势是代码工程集成。VP 能从 Java、C、Python 等代码反向生成类图也能通过执行轨迹生成调用关系的时序图这对梳理存量系统的调用链非常有用。它还有团队协作的 Teamwork Cloud多个人能同时操作一个工程比邮件发文件、合并图版本要省心得多。1.3 AI 辅助能把建模效率提升多少老实说AI 生成 UML 图这件事目前的成熟度参差不齐。像 PlantUML、Mermaid 这类文本描述即图的语法AI 处理得还算不错因为把文字逻辑翻译成图结构非常自然。VP 在较新版本里也加入了 AI 辅助能力可以在对话框里输入业务描述让它生成时序图框架。实测下来直接让 AI画一张完整的时序图往往会有元素错位、消息顺序错误的问题但让它分析这段业务描述输出参与者清单、消息序列、分支条件却很靠谱。所以我的工作流总结起来就一句话AI 出结构人做图。AI 先把业务描述拆成参与者、消息、分支这些建模要素我再在 VP 里做图形化落地和审查。这样既省去从空白画布开始的成本又避免了 AI 生成一张表面好看、逻辑不通的图。这个思路在后面的实操章节会完整演示。2. 时序图基础图形语言与建模原理2.1 核心元素与图示含义画时序图和写代码一样先要掌握基本语法。这里把最常用的几个元素讲透。生命线Lifeline图上顶部那个矩形头往下延伸一条虚线代表一个参与交互的角色或对象。它头顶的名称可以是类名也可以是系统外的角色名比如用户支付渠道。一条虚线向下延伸代表这个角色在时间轴上的生命过程。激活条Execution Specification生命线上那条细长的矩形表示这个对象正在执行一段逻辑。可以理解为这个对象正在忙忙的范围就是那条矩形。画图时如果某个对象从收到消息到返回结果之间有一段处理时间就会给它加激活条。消息Message生命线之间的箭头分成三种基本类型同步消息实线实心箭头表示发送方发出调用后要一直等到对方返回才能继续就像打电话你说完必须等对方回答。异步消息实线开放箭头表示发出去就不等了就像发微信消息发出后你该干嘛干嘛。返回消息虚线开放箭头表示处理结果的返回相当于对方回了你一条收到。还有一个容易漏掉的类型是自调用消息箭头从生命线出发又回到同一条生命线表示对象内部的方法调用或递归。这个在表达同一服务内部先做校验再落库时非常常用很多人画电商时序图会把内部逻辑硬画成两个系统交互这就是没用好自调用。组合片段Combined Fragment这是时序图表达逻辑控制的核心像一块透明框把一组消息包起来框角写类型名。常用的有alt分支选择多个互斥路径opt可选步骤满足条件才执行loop循环重复执行par多个交互并行执行break异常跳出当前交互ref引用另一张图避免一张图无限膨胀。用生活化的比喻理解组合片段alt 像 if-elseopt 像 if 不带 elseloop 像 for/whilepar 像多线程并发。你要是能把这几个用熟时序图基本就能表达绝大多数业务逻辑了。2.2 从业务描述到时序图的分析方法拿到一段业务需求不要急着开画。我一般按三步走第一步圈定参与者。把描述里的所有名词过一遍凡是会发出请求或接收请求的对象都列成候选生命线。常见的坑是把数据库漏掉把消息队列漏掉把外部系统漏掉。判断标准很简单它会不会自己执行操作它会不会收到消息后给出反馈会就是参与者。第二步梳理消息流。把业务描述里的动词按时间顺序排出来先扣库存还是先生成订单支付回调是在下单之后还是之前每一步是同步等结果还是异步发通知排的时候我会用编号消息方向的方式写草稿比如1. App→网关提交订单2. 网关→订单服务转发请求。这个草稿就是后续图的骨架。第三步标注控制逻辑。把描述里的如果当同时最多重试这些词抽出来对应到 alt、opt、loop、par。很多时候业务描述并不会把失败路径说完整这一步恰恰是建模最关键的地方也是最容易被 AI 和新人忽略的。这里给个简单对照表方便你从描述直接映射到图形语言业务描述用词时序图表达A 先调用 B等结果后再继续同步消息发送通知后不等结果异步消息如果库存不足则返回失败alt 片段一条成功路径一条失败路径条件满足时才执行opt 片段最多重试 3 次loop 片段校验通过后内部再落库自调用消息该步骤引用另一方案ref 片段2.3 建模误区时序图不是流程图说实话我在评审团队画的时序图时见过太多把时序图画成流程图的例子。两者最大的区别在于流程图关心一个节点往下走到哪个节点时序图关心多个对象之间如何按时间交互。如果你画出来的图主体是开始→判断→操作→结束这种链条那应该用活动图如果你画的是用户发给前端、前端发给服务端、服务端调用数据库返回数据这才是时序图。还有一个常见问题是一张图塞进十几个参与者和几十条消息。我曾经见过一张订单全流程时序图从用户下单选品到库存、支付、物流、发票全部堆在一起打印出来 A1 纸都看不清。这种图根本没法评审。经验做法是分层一张图只承载一个业务场景的主脉络比如下单主线支付回调主线场景之间的衔接用第 6 章讲的 ref 引用或者超链接。另一个常见错误是只画成功路径。时序图如果不画失败分支就和把代码里的 try-catch 删掉一样危险。库存不足怎么办、支付超时怎么办、MQ 消费失败怎么办这些分支不画出来到开发测试阶段全都会变成返工成本。2.4 同为时序图UML 时序与硬件信号时序的辨析前面提到时序图一词有两个含义这里单独说清楚。硬件领域的时序图比如 I2C、SPI、I2S、UART、CAN 的读写时序画的是一条条信号线SCL、SDA、CS、MOSI 这些上的电平状态随时间的波形关系。它本质上是一种波形图用来描述芯片之间的物理信号时序约束保证双方能按约定的时钟沿采样数据。这类图在嵌入式开发里非常重要但它和 UML 时序图完全不是一个体系工具也不一样硬件时序图通常用波形绘图工具或逻辑分析仪导出UML 时序图用建模工具画。如果你需要在一个嵌入式系统设计文档里同时表达软件交互和硬件信号我建议分两张图硬件部分用专门的波形时序图VCD 波形、逻辑分析仪截图或者手绘信号时序图软件部分用 UML 时序图。VP 本身也有 SysML 支持和时序约束相关的建模能力但不要指望在同一张 UML 图里既画生命线交互又画高低电平波形那会两边都表达不清。这个区分在团队评审时特别容易翻车提前说明白可以省很多解释成本。3. Visual Paradigm 绘制时序图实操流程3.1 创建工程与新建时序图第一次用 VP 的人最容易被它的模型-图双重结构搞晕。简单理解左边 Models 面板里管理的是模型元素中间画布上是图形元素两者是一一对应的。你从工具栏拖一个 Lifeline 到画布左侧 Models 面板就会自动多出一个模型对象。改名字时要注意右键选择 Rename 是同时改模型如果只想改图上的显示名需要在图元属性里单独调整。这个细节很多人不知道结果改个名字把整个工程里所有引用这个元素的地方全改了后悔都来不及。我建议建图流程这样走打开 VP选择 Blank Project 新建工程命名时直接叫项目名避免后续文件满天飞。在 Model 上右键新建 Diagram UML Behavioral Diagrams Sequence Diagram也可以直接 CtrlN 快速创建。先设置网格对齐在空白区域右键打开 Diagram Properties把 Snap to Grid 勾上这样后面拖动元素时不会歪歪扭扭。顺手设置字体和线条风格让图输出时统一风格。这个步骤虽然简单但对团队文档一致性影响很大。3.2 手工绘制订单场景主流程手工绘制虽然费时间但能让你把每一步的对象和消息关系想清楚。以一个最简单的用户下单主流程为例我来还原一遍实际画图时的操作细节。第一步拖四个生命线到画布用户、前端应用、订单服务、数据库。这四个就是上面分析步骤里的参与者。拖完之后把每条生命线的头部命名好然后用虚线对齐功能顶部的 Align Vertically把它们排整齐。第二步从用户生命线向前端应用生命线拉一条线。VP 默认会弹出消息类型选择菜单选 Synchronous Message同步消息在消息文本里填写提交订单请求。这是因为用户在界面点击下单后前端要等后端返回结果才能展示所以是同步等待。第三步从前端应用向订单服务再拉一条同步消息文本写POST /orders。如果这里用的是 HTTP 调用消息类型仍然选同步因为 HTTP 天然是同步语义的请求/响应模式前端会一直阻塞在响应上。第四步从订单服务向数据库拉一条同步消息写插入订单记录。订单服务的生命线上会自动出现激活条表示这段逻辑正在处理中。第五步画返回路径。从数据库回到订单服务拉一条虚线开放箭头写返回订单ID再从订单服务到前端应用拉一条虚线箭头最后从前端应用到用户拉一条虚线箭头这样整个同步链路就闭环了。画完之后检查一下每个请求消息后面是否都有对应的返回消息是不是漏了哪一层这个检查习惯养成了出来的图很少有逻辑缺口。3.3 AI 辅助生成与人工调整的配合方式VP 的 AI 辅助能力在不同版本里的入口和命名有差异但核心思路一致通过自然语言对话生成建模要素。我个人的实操建议是不要一上来就让 AI直接画图而是先让它输出结构化的建模草稿。你可以把下面这类提示词直接丢给它你是一个 UML 建模专家。下面是一段电商下单的业务描述。请列出1参与者清单2按时间排序的消息序列每条消息注明同步/异步3所有分支、循环、可选项对应的条件4容易遗漏的失败路径。业务描述用户在 App 提交订单订单服务先调用库存服务预扣库存再写入订单表然后通过消息队列发送订单创建事件。AI 输出的东西哪怕只是文字清单也能帮你快速把思考框架搭起来。之后你再在 VP 里按清单拖生命线、画消息线。如果你喜欢用 PlantUML 或 Mermaid 做前验证也可以把 AI 生成的脚本先渲染出来看一眼整体结构再手动在 VP 里复刻。个人体会是AI 在生成骨架上的效率优势很明显但它在语义正确性上还不可靠尤其是 alt 分支条件经常被简化失败路径经常缺失。所以 AI 产出后你至少要花一半精力做审查和修正图的质量才有保障。4. 电商实战订单创建流程时序图建模4.1 业务场景与角色识别电商下单看起来简单实际上牵扯的角色很多。这里我们定义一个相对完整但不至于过度复杂的场景用户在 App 下单走 API 网关网关鉴权后转发给订单服务订单服务先调用库存服务预扣库存再落订单库发布订单创建事件到消息队列。支付环节放到第 5 章单独讲这里先聚焦下单主链路。先把参与者列成一张表这张表也是你画图前的建模资产参与者类型职责用户外部角色发起下单请求接收结果App 前端外部参与者交互展示后端接口调用方API Gateway系统边界鉴权、路由、限流订单服务核心服务订单创建主控逻辑库存服务协作服务库存预扣与回滚订单数据库数据存储订单数据持久化消息队列基础设施异步事件流转这张表的用处是防止画图时漏角色。我见过太多人画电商下单图画到后面把数据库和消息队列漏了整个图变成服务之间两两对话完全看不出数据的落点和事件的流向。4.2 主流程一版从下单到订单生成一版主流程不需要管太多异常分支先把正常链路画通。时序依次是用户向 App 前端发起提交订单——同步消息。App 前端向 API Gateway 发送 POST /orders——同步消息。这一步在图上要体现出网关做鉴权和限流可以用一个 note 标注在网关生命线旁边或者用自调用表达鉴权逻辑。API Gateway 向订单服务转发请求——同步消息。这里我习惯在消息文本里标注透传请求头含用户ID与幂等键提醒后续服务用。订单服务向库存服务发送预扣库存——同步消息。注意这一步为什么要同步因为订单服务需要马上知道库存够不够决定要不要继续创建订单。库存服务向库存数据库发送条件更新 SQL——同步消息。条件就是库存余量 扣减数量这一步如果失败库存服务直接返回失败。库存服务返回预扣成功给订单服务——返回消息。订单服务向订单数据库发送插入订单记录——同步消息。订单数据库返回插入成功——返回消息。订单服务向消息队列发送订单创建成功事件——异步消息。这里必须用异步因为订单服务不需要等消费者处理完事件再返回。订单服务逐层返回下单成功订单号给 App 前端和用户——返回消息。这张一版图画出来已经把最核心的业务时序表达清楚了。注意第 4 步到第 8 步是跨三个系统的同步链路激活条会很长这正是分布式事务问题的温床也为第 4.3 节的迭代埋下伏笔。4.3 增加分支、幂等与分布式事务后的设计迭代一版图只是骨架真正能指导开发的是迭代后的完整图。下面三个场景是电商下单里最常见的复杂性来源。第一个是库存不足分支。在第 4 步和第 5 步之间需要用 alt 片段框住两条路径一条是库存充足继续创建订单另一条是库存不足订单服务直接返回库存不足给前端并且不做任何订单落库。这个 alt 如果不画出来开发时很容易漏掉失败回滚线上就会出现订单已创建但库存没扣的状态错乱。第二个是幂等处理。下单请求可能因为网络超时被前端重试所以订单服务必须校验幂等键。我通常在第 3 步和第 4 步之间给订单服务加一个自调用消息校验幂等键是否已存在并用 note 标注相同幂等键直接返回原订单号。如果不画这个细节后面的接口设计评审时幂等逻辑就很容易被当成非功能需求忽略掉。第三个是分布式事务的落地。订单服务、库存服务、订单库三处数据要最终一致业界常用的是 Saga 模式每步都是本地事务失败后逐级反向补偿。在时序图里的表达方式是在第 5 步库存扣减失败时alt 的失败分支里再画一条订单服务 → 库存服务补偿回滚预扣库存的异步消息。这个补偿路径看着简单却是整个设计中最重要的兜底不画清楚联调阶段准出问题。这个迭代版图画完你会发现它和一版图在信息量上完全不是一个层级。一版图只能让团队知道正常流程长什么样迭代版则在回答失败时系统如何自保。评审时我会要求团队至少把失败分支画全否则方案不通过。5. 进阶场景支付回调与库存扣减的时序设计5.1 支付回调的异步建模支付是电商系统里最典型的异步场景。用户在 App 上点击支付订单服务把支付请求提交给外部支付渠道然后用户跳转到支付页支付渠道处理完后并不是让用户的页面直接通知订单服务而是由支付渠道的服务器主动回调订单服务的接口这个回调就是典型的异步消息。画支付回调时序图时我建议分两段表达。第一段是发起支付用户向订单服务发起支付请求订单服务生成一个支付单号然后以异步消息方式提交给支付渠道用户端进入等待状态。第二段是接收回调支付渠道异步调用订单服务的回调接口订单服务先做验签、再校验金额和订单状态然后更新订单表为已支付再以异步消息通知库存服务执行预扣转正式扣减。这里有一个关键点回调接口本质上是被外部系统调用所以它的消息方向是从支付渠道到订单服务。很多新人会画反把订单服务画成主动去支付渠道拉结果。除非你是做主动查询对账否则支付结果基本都是靠回调推送。画反方向会在方案评审时被直接指出。5.2 超时重试与幂等表达支付回调既然是网络调用就一定会碰到超时和重复通知。支付渠道的通用做法是如果回调没有得到正确响应就按策略重试多次而接收方必须保证重复回调不会造成重复业务处理。这个机制在时序图里怎么表达我用两个手段一是 loop 片段表达重试。在支付渠道 → 回调接口这条消息外侧加一个 loop 框标注最多重试5次间隔递增。注意重试条件要写清楚比如未收到成功响应则重试。这个 loop 直接告诉运维和开发回调接口必须做得足够快和幂等否则会造成大量重试流量。二是幂等校验的表达。在回调接口收到请求后画一个自调用消息校验支付单号与幂等标记。note 标注同一个支付单号的处理结果只生效一次重复回调直接返回成功。这是支付系统设计的命根子我在无数次的线上事故复盘里见到重复通知导致重复发货的案例。时序图上不画这一步等于没设计。还有一个容易漏掉的细节回调的返回消息也必须正确。支付渠道是按是否收到业务成功响应来判断要不要重试的所以订单服务处理完回调后必须返回明确的成功标记不能说业务成功但接口返回 500那会导致渠道反复重试。这个可以在返回消息上标注返回 success 标记。5.3 时序图与状态机图配合时序图善于表达系统之间如何交互但表达状态如何流转就很吃力。支付这一块恰好是状态流转的重灾区待支付、支付中、已支付、已取消、退款中、已退款。状态一多在时序图上写 if-else 会让人崩溃。我的经验是先画状态机图定义状态与事件再画时序图定义触发器间的交互。在 VP 里状态机图和时序图可以共享同一个模型还能通过超链接互相关联。实际操作中我在时序图的更新订单状态消息旁边加一个超链接指向对应的状态机图评审时讲完时序再点开状态机图看状态流转整个方案就闭环了。这种图与图之间的联动是 VP 这种建模工具最大的优势单纯画图工具做不到。5.4 硬件接口场景的建模提示如果你所在的团队做嵌入式设备需要表达设备与主控芯片之间的 I2C 或 SPI 读写动作我的建议是不要硬往 UML 时序图上套。可以用 VP 画系统级的组件交互但涉及信号时序细节时回到专业的波形工具去画然后以图片形式嵌入文档。UML 时序图的生命线和消息语义是为软件对象设计的硬画信号线会丢失时序精度评审时也说服不了硬件工程师。工具选择上我见过不少人试图用一个工具覆盖所有时序需求最后两边都不讨好这个教训值得记下来。6. 常见问题与排查技巧实录6.1 AI 生成内容的典型问题与修正AI 辅助建模虽然效率高但生成结果的坑我也踩了不少。最典型的有四类第一类是参与者遗漏。AI 从一段业务描述里往往只抽出最明显的两个对象比如用户和服务端把数据库、消息队列、网关这些中间角色丢掉。修正方法很简单用触发事件→处理→持久化→通知这四步检查清单过一遍凡是链条上有独立职责的元素必须补上。第二类是消息方向画反。回调场景尤其容易出问题AI 经常把支付渠道回调订单服务画成订单服务调用支付渠道。这个问题靠眼力检查很难发现建议画完后拿着消息序列逐条过这一条消息是谁发起的发起方为什么有权限和能力发起多问几个为什么方向错误就藏不住了。第三类是分支不对称。AI 生成的 alt 片段几乎都只画成功路径失败路径完全缺失。我说过很多次时序图上失败路径不是可选项而是必选项。修正方式是在 AI 生成清单里显式地加一句补充所有失败分支如果没有就自己对着业务描述把所有否则、如果失败、异常词翻出来。第四类是过度工程化。AI 有时会把一个系统内部的方法调用拆成多个参与者之间的消息导致图里出现一堆并不存在的服务。这种情况我会把不存在的参与者删掉内部方法调用统一用自调用表达。下面把这些常见问题的修正汇总成一个速查表问题类型表现修正方法参与者遗漏只有两三个生命线按四步清单补漏触发、处理、持久化、通知消息方向错误箭头与调用关系相反逐条追问谁发起、谁响应、谁有调用权限分支不对称alt 里只有成功路径强制列出失败路径异常、超时、重复请求过度工程化出现不存在的服务删除多余参与者内部逻辑改为自调用同步/异步混淆MQ 发送画成同步看发送后是否等待等同步不等异步6.2 时序图质量自检清单画完一张图我习惯按下面的清单自查也建议团队评审时按这个标准来每个参与者是否有且只有一个生命线各自的生命周期范围是否合理消息编号和时间顺序是否和业务描述一致有没有循环依赖同步消息和异步消息是否区分正确消息队列、回调、事件通知必须用异步。每条请求消息后面是否都有返回消息没有返回的要有明确理由。所有 if、else、异常、重试是否都体现在 alt、opt、loop、break 片段里事务边界是否清晰跨服务的补偿路径是否已经画出是否有一张图塞下超过 20 条消息的情况如果有拆图并用 ref 引用。是否有与状态机图、活动图的关联状态变化是否在对应图中可追溯。这八条都通过了图基本上能达到评审不会被拍砖的水平。我见过很多团队重写方案核心问题往往不是技术方案本身而是图没画清楚导致评审人理解不一致。图的质量就是方案的第一张脸。6.3 VP 操作层的避坑心得最后补几个 VP 具体操作上的细节都是我从项目里总结出来的。模型与图的关系前面提过这里再强调一次在左侧模型树上直接重命名元素会导致所有引用该元素的图都跟着改。如果你只想改当前图的显示名在图元属性面板里调整Name和Display Name的区别。我在一次交付文档准备时被这个坑害过一个名字改完好几张类图时序图全部变了样。布局和导出也值得注意。VP 有自动布局功能右键菜单里的 Layout Tools对于复杂时序图选中全部元素后让它自动排列能省不少拖拽时间。但自动布局的结果经常不够美观建议先用自动布局做初始排列再手动微调关键生命线的顺序。导出图片时不要直接截图用菜单里的 Export Diagram 选择 PNG分辨率设置为 300 dpi 以上如果文档需要矢量图就导出 SVG这样放进 Word 或 PDF 里缩放也不会糊。版本兼容这块也要留个心眼。VP 的 AI 辅助功能在较新版本里才逐步完善不同版本菜单名称差异较大。如果你用的版本没有 AI 入口不要花太多时间去折腾按照我前面说的AI 出文字清单、VP 手工落图的工作流也一样能高效产出。工具只是放大器建模思路才是核心生产力。回到我开头说的那句话画图比写代码更见功力。时序图画得好的工程师通常也是业务逻辑拆得最清楚的人。AI 能帮你从一段描述里快速拉出参与者清单和消息序列能把最枯燥的草稿环节省掉但它替代不了你对业务的理解和对失败路径的判断。我自己现在的工作流仍然是先让 AI 出结构清单再在 VP 里逐条审查落地最后拿着图跟开发、测试、运维逐行对需求。这个过程比让 AI 一键生成然后直接贴进文档要多花半小时但项目后期省下来的沟通成本远远超过这半小时。最后再分享一个小技巧每张时序图完成后都把图上所有 alt 分支的失败路径单独列一遍对着列表写测试用例。坚持三轮之后你会发现系统设计的漏洞密度明显下降——这是时序图能给你的最大回报。