UML活动图实战：从需求分析到流程建模的完整指南

我见过不少需求评审会，前一小时还风平浪静，一旦聊到某个业务流程的具体走法，会议室里立刻分成几派。A说“退回就是回到发起人改完再提交”，B说“退回应该直接结束流程”，C补充“那超过三天的单子是不是要走会签”。每个人脑子里都跑着一条不同的流程线，谁也说服不了谁。

后来我形成了一个习惯：凡是涉及流程类需求，不管复杂度高低，先逼自己画一张UML活动图。这张图一出来，讨论的焦点就从“我觉得流程是这样”变成“图上是这么走的，你说哪里不对”。分歧依然存在，但终于有了可以指着说的地方。

这篇文章就围绕UML活动图在软件需求分析与设计中的应用展开。我会把自己几年用下来的画图套路、符号理解、踩坑记录、评审方法和工具思路，一次性整理出来。适合正在做需求分析、产品设计、业务流程梳理，或者想从开发视角理解需求建模的读者，不管是新手还是老手，应该都能找到点有用的东西。

1. 为什么需求分析与设计离不开活动图

1.1 需求阶段的头号痛点：流程共识很难凑齐

我做过的项目里，返工率最高的不是技术难题，而是需求理解不一致。尤其是流程类需求，一句大白话就能延伸出好几种解读。

举一个很典型的例子，需求方说“审批不通过就退回”。这句话听着没问题，但落到图上就得问清楚：退回给谁，是退回申请人重新填写，还是退回上一个审批节点？退回之后流程是结束，还是重新走以前的路径？重新走的时候，之前的审批结果还算不算数？这些问题不确认清楚，开发按自己的理解写了代码，测试再按自己的理解设计了用例，两边对不上，最后撕扯一段时间，只能重新梳理。

活动图在这里扮演的角色，是把流程里每一个决策、每一条路径、每一个责任人，都变成图上可见的元素。它逼着你说清楚，而不是含糊地带过去。你没办法画一条“看情况再说”的边，只要有分支，就必须定义分支条件，而定义分支条件的过程，就是在挖掘真实业务规则的过程。

1.2 活动图在UML里的位置，以及它和其他图的分工

很多人一听到UML就想到类图，觉得那是开发的事，需求分析阶段用不上。其实UML是一整套表达工具，静态结构有类图、对象图，动态行为有用例图、序列图、通信图、状态图、活动图。活动图恰好是动态行为里最贴近业务流转的那一种。

简单区分一下：用例图回答的是“系统要提供哪些功能，谁在用这些功能”；活动图回答的是“这些功能背后，业务过程到底是怎么一步步走的”；序列图回答的是“某个用例的细节里，对象之间按什么顺序发送消息”；状态图回答的是“某个核心对象在不同阶段有哪些状态、怎么转换”。活动图的优势在于它是站在流程视角俯瞰全局的，不局限于某个对象，也不局限于某些消息。你可以在同一张图里看到员工、审批人、人事系统三个角色的动作，以及它们之间如何协作。这种全局视角，特别适合需求确认阶段。

1.3 活动图能解决的问题和不能解决的问题

能解决的问题很明确：第一，让流程清晰化，每个人看到的图一样，理解就更容易对齐；第二，让职责边界清晰化，泳道上这一步由谁完成，一目了然；第三，让分支规则显性化，每个判断节点必须写出条件；第四，让并行关系显性化，哪些步骤可以同时进行，图上直接分叉；第五，让异常路径有机会被讨论，而不是等项目上线后才暴露。

不能解决的问题也要心里有数。活动图画的是一个流程的骨架，它不擅长表达对象之间复杂的信息交换顺序，那是序列图的活；不擅长表达一个对象内部精细的状态转换规则，那是状态图的活；也不擅长定义数据结构，那是类图和表结构的活。所以活动图是一种前置工具，和后面几种图配合使用，而不是互相替代。明白这个边界，画图的时候就不会什么都往里塞。

1.4 哪些角色需要用它，在哪个阶段用

业务分析师和需求工程师是主要使用者，产品经理也可以靠它跟研发对齐流程，避免需求文档写得满满当当但流程还是拎不清。开发角色同样应该看活动图。我见过的靠谱团队里，开发拿到需求后，会先把活动图过一遍，确认所有分支都覆盖到了，才开始设计接口和数据库。测试角色更应该看活动图，分支、异常路径、并行节点，这些都是测试用例设计的直接素材。如果团队里没有专门画活动图的人，我一般建议最熟悉业务的人来画，哪怕画得粗糙，也比没有强。

阶段上，需求分析阶段画的是业务活动图，角色用业务角色来表达，比如“员工”“审批人”“财务”。到了设计阶段，活动图会演化为系统活动图，角色换成“用户端”“审批服务”“消息中心”这类技术视角的模块。同一套流程，在两个阶段的价值完全不同，后面第4部分我会专门讲这个演化过程。

2. 先把图例看懂：活动图的核心元素与业务含义

2.1 基础元素：开始、结束、活动节点、控制流

活动图最基础的元素就四样。开始节点是实心圆点，一个流程永远是它的起点；活动节点是圆角矩形，里面写一个动词短语，表示一个动作；控制流是有向箭头，把节点连接起来，告诉你执行顺序；结束节点是实心圆外加一圈边界，流程到这里终止。

注意活动节点的命名习惯。很多人喜欢写“审批”两个字，这不行，它没有动作对象，也没有明确语义。规范一点应该写“审批请假单”“审核报销明细”“发送通知邮件”。一个好的活动命名，应该让一个不懂系统的人也能看出这一步在干什么。这不仅是画图规范的问题，也是判断你脑子里业务是否清楚的标准。

我在需求文档里见过不少这样的图，开始节点后面直接连着一个名叫“系统处理”的圆角矩形，再往后就没了。这等于什么都没说。“系统处理”是个黑洞，没有人知道它处理了什么、怎么处理、什么时候算结束。正确的做法是把“系统处理”展开成若干个动作节点，具体到“校验余额”“生成审批单”“记录操作日志”这种颗粒度。

2.2 决策与合并：把“如果…那么…”画成图

决策节点是一个菱形，它代表一个分支判断。进入决策节点的控制流只有一条，出来的至少两条，每条边上必须标注分支条件。比如“请假天数小于等于3天”和“请假天数大于3天”，这是两种不同的走向。关键点是分支条件要写成可判断、可验证的语句，不能写模糊说法。

我想强调“合并节点”的使用。合并节点同样是一个菱形，但它的作用是让多条分支汇合回同一条路径，它不产生判断逻辑，只代表“多条路走完后，在这里汇合继续往下走”。很多人会把决策节点和合并节点画成一个样子，这没问题，语义上要靠连接的条件和上下文区分，但合并节点的存在意义不能省。你不画合并节点，流程图的路径就会越拉越多，最后变成一团乱麻。决策是分岔，合并是收口，一收一放，图才干净。

2.3 分叉与汇合：把“同时做”画成图

分叉节点是一条控制流变成多条并行控制流的小粗线。汇合节点是它的逆操作，多条并行流恢复到一条。二者通常成对出现，表示并行执行。

有些需求里，一个审批操作触发后，同时要通知申请人、通知审批人、记录审计日志，这三件事没有先后依赖。这种情况下画三条串行路径是错的情绪，因为图会暗示它们有顺序关系。这时候应该用分叉，让这三个动作从同一个粗线出发并行执行，最后汇合，再进入下一个环节。

并行逻辑在业务上很常见，也很容易在实现时搞错。我见过一个案例，交付团队没画活动图，开发把“发消息”和“写日志”串行实现，结果消息通道超时导致主流程失败，日志没写，用户操作失败后连排查依据都没有。而活动图上如果一开始就把这两个动作画成并行分支，实现时就自然会考虑独立失败的处理方式。这种问题，用图表达比用文字描述清晰得多。

表格整理一下核心符号和对应业务含义，方便对照。

2.4 泳道：活动图最容易被忽略却最关键的元素

泳道是活动图里很关键的一个扩展，它把活动节点按角色或模块划分到不同区域、不同列。一个活动图可以没有泳道，但它能够把责任的边界表达得很清楚，大多数情况下我会建议加上。

泳道回答的是“这一步到底是谁干的”。业务活动图用业务角色做泳道，比如员工、直属领导、人事专员；系统活动图用模块做泳道，比如客户端、服务端。画泳道的过程往往会逼出一个业务痛点：你发现有些活动节点不知道该放进哪个泳道，这说明职责归属本身是模糊的。模糊的职责在需求文档里会被一句话带过，但在系统设计里一定会炸，因为总得有服务去实现它。

泳道还有一个额外作用，就是辅助沟通。评审时，某个领导只看自己的泳道，能快速确认哪些步骤和他有关，他有没有遗漏。这种按角色审图的方式，远比让所有人从头到尾看一遍高效。

2.5 对象节点与进阶场景：数据流、异常流、信号

对象节点是可选的，用矩形表示，描述活动之间流转的工件。比如“填写申请单”这个活动会产生一个“申请单”对象，它作为输入流进入“审批请假单”活动。对象节点强调活动之间传递的产物，对后续设计接口和数据结构有参考价值，但需求初期不用过度建模，简单标出关键工件即可，避免图面过重。

异常流在真实业务里很重要，标准活动图里可以用中断区域来表达。简单场景下，大部分团队直接用额外的条件分支来表达异常，比如“审批超时”“第三方接口返回错误”，不一定要用到中断区符号，但必须把异常路径画出来。这个我后面会重点说，因为只画正常路径是活动图最大的坑之一。

信号相关的元素，发送信号用凸五边形，接收信号用凹五边形，用于表达跨流程的信息传递。在分布式系统、消息队列里这个符号很实用。需求阶段遇到“审批通过后发送通知”之类的描述，用接收发送信号表达比较清晰，但这属于进阶内容，新手可以先跳过，先把主干流程和泳道玩明白。

3. 从一段白话需求到活动图：完整实操流程

3.1 场景设定：一个典型的“请假审批”需求

为了把步骤讲清楚，我模拟一个常见的需求，这是某内部管理系统里的请假审批流程。

需求文档的原文大概是这样的：“员工请假需要在系统里提交申请，填写请假类型、时间段和事由。请假三天及以下由直属领导审批，三天以上需要再经部门负责人审批。审批通过后系统通知人事部门记录备案，流程结束。审批不通过的话，流程退回员工，员工修改后可以重新提交。”

这段描述看上去挺完整，但真要画活动图，立刻会发现好几个信息缺口。第一个，审批不通过退回后，员工是只能修改还是也能撤销？第二个，重新提交是回到同一个领导那里，还是重新走完整条审批链？第三个，人事备案是不是必经环节，还是只有通过后才触发？这些问题在需求文档里没有答案，活动图却逼着你去问。这就是画图的最大价值。

3.2 第一步：先圈边界，再画主干

拿到需求，别急着补细节。先确定流程从哪里开始、到哪里结束。这个例子的开始节点是“员工发起请假申请”，结束节点有两个方向：一个是走完审批和备案后正常结束，另一个是员工取消或放弃后的非正常结束。

主干路径很简单：员工提交申请，先判断请假天数，三天及以下走直属领导审批，三天以上走两级审批，全部通过后人事备案，流程结束。这张主干图可以先画在白板上，不纠结符号画得是否标准，用最简单的方框和箭头，把顺序列出来。等主干确认无误，再往上面加分支和异常路径。流程边界一旦画清楚，需求范围也就基本锁定了，那些“跟流程无关的功能”自然而然会被排除在外。

3.3 第二步：补全分支和异常路径

这一步是对需求挖掘深度的考验。正常路径上，分支主要在两个地方：审批通过与否，请假天数是否超过3天。我们先把这两个决策画出来。

在“直属领导审批”这个活动节点后面，应该是一个决策节点，一条边标“通过”，另一条边标“不通过”。不通过的方向，需要再准备一个决策节点，判断员工是“重新提交”还是“撤销申请”。“撤销申请”直接连到结束节点；“重新提交”则要回到一个合并节点，然后连回“提交申请”的入口。这里有一个以前容易踩的坑：重新提交后是回到审批人那边，还是重新从“提交申请”开始？答案是看业务规则，这就是画图要确认的事情。如果业务方没有明确说，你画图时落了一个分支，开发那里就会按自己的想象选一种，测试又按另一种设计用例，问题就埋下了。补分支和异常路径，本质上是在把业务规则问透。

“三天以上需要再经部门负责人审批”的分支，我倾向于把它做成一个独立的子流程，不要在主干图里把两级审批串得太细。具体做法是，在三天以上分支里，先经过一个“直属领导审批”节点，再进入“部门负责人审批”节点，决策和退回路径类似。两条路径最后的共同汇合点是“通过并提交人事备案”，这样可以少画一些重复的边。

还有一个容易被忽略的异常路径是审批超时。纸面上没有写超时规则，但实际系统里不可能无限期等。评审时就应该问一句：领导一周不点审批，系统怎么办？有些企业会加自动撤回，有些会发催促通知，有些会转交其他领导。把这条路径补到活动图里，是画图过程中最有价值的动作之一。

3.4 第三步：用泳道把职责分到位

画完主干和分支，加泳道。这个例子里至少有三条泳道：员工、审批领导、人事系统/人事专员。

员工泳道里放“提交请假申请”“修改申请”“撤销申请”；审批领导泳道里放“直属领导审批”“部门负责人审批”“审批不通过退回”；人事泳道里放“记录备案”。分泳道时我注意到，大多数活动节点都归属清晰，唯独“重新提交后走什么流程”这个节点如果放进员工泳道，就不太对劲，因为重新触发流程的动作是系统自动完成的。这种归属模糊其实暴露了一个隐含的系统规则：员工修改后重新提交，需要一个系统动作更新审批状态并通知审批人。这个系统动作在需求文档里完全没出现。画泳道不是为了装饰，而是为了把责任边界逼到明面上。

泳道画好之后，每个角色可以只读自己的通道，检查是否有缺失。这比整体扫描一张密密麻麻的图要有效率得多。

下面我用文字描述这段流程在图上如何布局，方便你对照绘制：

• 开始节点在“员工”泳道，向下连接“提交请假申请”
• “提交请假申请”向下连接到“请假天数判断”决策节点
• “小于等于3天”走向“直属领导审批”活动节点，“大于3天”走向“两级审批”子流程入口
• 两级审批子流程内在“审批领导”泳道依次连接“直属领导审批”和“部门负责人审批”
• 审批后的决策节点分出“通过”和“不通过”两个分支
• “不通过”走到“员工处理”决策节点，分出“修改重新提交”和“撤销申请”两个方向
• 所有通过路径汇合到“人事记录备案”活动节点，位于“人事”泳道
• 最后连接到结束节点

3.5 第四步：检查节点粒度，避免“大筐”活动

画图过程中，最容易出问题的不是分支逻辑，而是活动节点的粒度控制。同一个层级里，既要避免把动作拆得比程序函数还细，也要避免用一个大节点包揽一切。

我见过一句话就能说明白的活动节点，也见过“处理申请”这种东西，它把校验、计算、状态更新、消息发送全部装进一个方框。这种节点在图上好看，但一到设计阶段就没法用了，开发不知道要拆出几个方法，测试不知道要造多少数据。我的经验是，一个活动节点应该满足两个条件：第一，能用一句动词短语说清楚它做了什么；第二，它在业务上是一个完整的、不可再细分的动作，而不是一组动作的集合。

比如“提交请假申请”这个节点，它内部可能包括表单校验、保存草稿、更新状态等若干技术动作，但在业务活动图这一层，这些内部细节不需要展开。画到系统活动图那一层再拆分，会合理得多。层级不同，粒度标准不同。一个常见的毛病是把业务活动图当成程序流程图，活动节点直接写成“调用退单接口”“更新数据库状态”，这种技术实现细节放进需求阶段的活动图里，只会让业务人员看不懂，让评审失去意义。

3.6 附带收获：活动图就是测试用例的草稿

每次画完活动图，我都会顺手基于它筛一遍测试路径。从开始节点到结束节点，后经一个不同的分支组合，就是一条场景流。还是拿请假审批举例，可以轻松列出至少四个主要场景：三天及以下审批通过；三天及以下审批后驳回再修改通过；三天以上两级审批通过；三天以上审批驳回后撤销申请。如果再加超时、系统异常、重新提交，还能拆出更多场景。

测试人员如果用活动图做素材，能很快生成一份覆盖率比较高的用例清单。决策节点就是测试分支点，泳道边界就是权限校验点，分叉汇合点就是并发测试点。很多团队抱怨需求文档写得太抽象，测试用例不知道怎么设计，其实只要流程类需求配一张合格的活动图，测试设计的工作量会减掉一半。我甚至见过有团队直接在活动图节点上标注优先级和用例编号，让需求、设计、测试三份文档指向同一张图，维护成本一下降下来。

4. 从需求到设计：活动图怎么继续演化

4.1 业务活动图与系统活动图的区别

需求阶段画的活动图，本质上是业务人员的语言，泳道里是业务角色，节点里是业务动作。到了设计阶段，这张图往往需要做一次翻译，变成设计人员能用的系统活动图。

同一个请假流程，业务活动图里写“员工提交申请”，系统活动图里就可能变成“客户端提交表单，后端校验字段并持久化”这种更细的描述；泳道也从“员工”“审批人”变为“客户端”“审批服务”“行政服务”。节点粒度差异很大，系统活动图需要表达出技术边界和模块职责。很多团队把两张图混在一起画，业务节点和技术节点混在同一张图里，结果业务人员看不懂后半张，开发看不懂前半张。我的做法是分两层维护：需求阶段一张业务活动图，设计阶段在它的基础上生出一张系统活动图。两张图之间通过节点编号保持对应关系，后期追溯起来十分清晰。

4.2 活动节点到系统功能模块的映射

活动图不仅用于画流程，还能直接辅助确定系统功能清单。业务流程里的每一个活动节点，落到技术上几乎都能对应一个或一组系统功能。

拿请假审批流程里最不起眼的“发送通知消息”来举例，业务活动图里一个节点，到设计阶段可能就要拆解为：从审批结果生成消息内容、查询接收人、通过消息服务发送、记录发送结果、处理发送失败重试。设计人员可以从活动图的活动节点中提取功能点，再按照系统模块归类，形成功能结构图。这个推导过程反过来也能检验活动图的完整性：如果某个业务动作找不到对应的系统功能承载，那说明流程没有闭环，或者需求漏掉了什么。

我在一些规范的项目里会建一张映射表，把“活动节点编号、活动名称、所属泳道、对应系统功能、后续关联接口”五列放进去，作为需求到设计的桥梁。这张表的来源就是活动图，Excel就可以维护，不需要高深的工具。有了这张表，开发排期、测试分工，甚至数据字典的建立都能找到出发点。

4.3 活动图与状态图、序列图的配合顺序

这是我经常被人问到的点。活动图和状态图、序列图到底先画谁？我的习惯是：活动图最先，序列图紧跟其后，需要关注某个核心对象的生命周期时再补状态图。

原因很直接。活动图解决的是流程的整体骨架，这是需求分析阶段最需要确认的东西。骨架稳定后，再针对每个用例细化对象交互，画序列图就有据可依了。序列图里每个消息的先后顺序，理论上都要能回溯到活动图里的流程顺序。如果二者不一致，说明某张图画错了。至于状态图，它关注的核心对象的状态变迁，比如请假单在流程里的状态迁移：草稿、待审批、审批中、已通过、已驳回。这些状态变化可以从活动图的流程里提炼出来，但并不等于简单照搬。状态图更侧重某个对象在什么事件下从什么状态迁移到什么状态，映射到活动图时会涉及跨泳道的节点交互，所以通常等主要流程稳定后再画，针对性更强。

我见过一种团队协作模式：需求阶段以活动图为主，设计阶段在活动图之外补序列图和状态图。三张图不是说必须一张不少，而是按需使用。核心流程用活动图，对象交互复杂时用序列图，核心实体状态多时用状态图。这里的关键不是图越多越好，而是让每一张图都解决一个明确的问题。

4.4 从活动图中提取数据与审计字段

活动图对数据设计的帮助，很多人没有意识到。业务流程里的对象节点，其实就是数据输入输出的雏形。“员工填写申请单”产生“申请单数据”，这个数据最终落到数据库里要有哪些字段，看图就能推导出来。审批环节需要记录审批人、审批意见、审批时间，这对应一个“审批记录”数据表。流程中涉及审计需求的，一般要求在关键节点记录操作人、操作时间、操作类型。从活动图的节点和泳道里，就能大致提取出这些审计字段。

这样做的价值在于，数据设计不再依赖开发拍脑袋。曾经有一个交付项目，上线后客户要求追溯两个月前每一次审批操作的完整记录，结果数据库里只存了一张申请单主表加一个状态字段，历史审批过程完全没有落库，不得不临时补数据。如果当初画活动图时把“审批节点”对应的数据沉淀想清楚，就不会有这种返工。活动图和数据模型之间多了一道映射思考，比事后补日志字段要省事太多。

5. 工具选择与画图习惯：让图真正用起来

5.1 工具怎么选：别让工具绑架建模

经常有人问我用什么工具画活动图。我的建议是，先选一个团队里所有人都能打开、共享、评论的工具，再去考虑符号是否齐全。建模的价值在于沟通与共识，不是画多漂亮的图。

目前在团队协作中比较主流的有三类。第一类是在线白板工具，适合需求评审初期头脑风暴，自由度高，但最终成图往往不够规范，分支多时很容易乱。第二类是开源的文本绘图工具，用文字描述节点和连接关系，自动生成图，版本管理方便，适合追求效率的技术团队，缺点是复杂图需要手动调整布局，符号美观度一般。第三类是商业建模工具，功能全，符号标准，适合大型项目做整套UML建模，但对业务人员不够友好，上手成本高。

我自己在不同阶段会混用：需求讨论阶段用在线白板，快速涂改；评审通过稳定后，再用文本绘图工具生成标准图，纳入需求文档。比工具更重要的是一致性约定，团队必须统一用同一套活动图符号规则，否则A画的菱形在B眼里是状态标记，评审会就变成了符号争论会。如果团队刚起步，我甚至建议直接用白板加手机拍照，先让画活动图的习惯养成，再考虑工具规范。

5.2 我的画图三步法：草稿、结构、美化

画活动图几年，我形成了一套固定的三步法。

第一步是草稿草绘。只画方框和箭头，不管符号规范，重点是流程主干和分支逻辑，目标是让参与讨论的人快速看到全局架构。在这个阶段，图的水平布局也不一定要对齐，哪里放不下就往哪里摆。第二步是结构调整。流程确认稳定之后，才开始补符号、补条件标签、加泳道、理清布局。这一步我会把七个节点以内的流程图尽量放在一页内，超过的话考虑分层或拆成子流程。符号和布局一旦理顺，隐藏的逻辑问题就会自己跳出来，比如某条分支没有对应合并节点，某个活动节点跨了两个泳道没有归属。第三步是美化定稿。统一字体、间距、对齐、线条走向，加版本号和日期，嵌入需求文档。这步如果团队没有强制要求，做基本对齐就够了，不要把时间花在炫技上。

5.3 活动图纳入需求资产：可维护、可评审、可追溯

活动图画完，不该只是评审会上的一个临时产物，它应该和需求描述绑定在一起，成为需求资产的一部分。我的做法是，在需求文档里把活动图作为流程图补充放进正文，并在节点上加上编号，比如“N1 提交请假申请”“N2 直属领导审批”，后续邮件、评审纪要、测试用例都引用这个编号。

这样的好处是，当需求变更发生时，大家能精准定位改动影响。比如“审批不通过改成直接结束，不再允许修改重新提交”，就只需关注N2后面的决策分支。开发排期受影响范围、测试回归范围、文档更新范围都能从这一张图上推导出来。没有编号的活动图，每次变更都要对着一整张图重新口述一遍，低效且容易遗漏。

版本管理也值得强调。需求变更后，活动图如果不更新，它就是一张过期的错误地图，比没有图更危险。我见过团队延续旧图做开发，结果流程早已调整，开发完的系统和真实需求对不上。建议每次涉及到流程的需求变更，都同步更新活动图，并在图角标注版本号，和需求文档的同次变更版本保持一致。

6. 常见错误与排查技巧：记下这五个坑

6.1 把活动图画成程序流程图，业务语言被技术细节淹没

我只要看到一个活动图里出现“调用接口”“判断标志位”“查询数据库”这种字眼，就知道这张图被技术表达污染了。需求阶段的活动图，角色应该是业务角色，节点应该是业务动作，不用出现任何技术实现细节。

程序流程图表达的是代码执行逻辑，活动图表达的是业务流转过程，两者的抽象层级完全不同。把技术细节塞进业务活动图，最直接的后果就是业务人员看不懂，评审没有抓手，图的作用直接废掉。正确做法是，业务活动图只描述业务动作和业务规则，技术实现细节放到设计阶段另画系统活动图。

关于循环，很多画过程序图的人习惯在活动图里表达循环结构。业务流程图里如果真的有重复做某件事的场景，比如“收货单未确认前反复发出提醒”，可以在决策节点上标注“未确认则重新发送提醒”，不用特意画出程序式的循环箭头。活动图不是用来描述循环控制结构的，它更关注一次流程里不同角色的协作和分支选择。

6.2 没有泳道、分支写不清、只画happy path

这是三个老生常谈但依然频繁出现的质量问题。

没有泳道的活动图，看起来像一串动作串成的顺序图，根本看不出每一步的负责人和协作边界。光看图，你能看出“提交申请”和“审批申请”是两个不同角色完成的吗？看不出。这张图就缺失了职责信息。分支条件写不清楚同样致命。“审批通过”和“审批不通过”这些条件是合格分支条件，但有人会写“有条件”“无问题”这种无法判断的标签，这种图落到测试手里，用例完全没法设计。“无问题”到底怎么量化？是靠审批人点一下，还是靠系统自动判断？必须落在可验证的语句上。

只画happy path是我见过最常见的问题。正常路径从开始一路走到结束，非常顺畅，但真实系统不是这样跑的。异常路径包括数据校验失败、审批驳回、超时未操作、第三方服务不可用、消息发送失败。这些路径在需求阶段不画出来，就会在设计阶段变成各种临时判断、紧急补丁。每次我评审活动图，都会逐条问：如果这个节点失败了，下一环节去哪？图上有那条线吗？没有就补。活动图的完整度，很大程度上取决于异常路径的覆盖程度。

6.3 用一份检查清单审图，效率翻倍

我审活动图多年，整理出了一份检查清单，分享出来。

第一，图里有没有两个及以上开始节点或结束节点，如果没有明确语义，通常说明范围没有收住；第二，每个活动节点是否都是动词短语，有没有“处理数据”“综合汇总”这类无动作对象的短语；第三，每个决策节点连出来的每条边是否都有清晰可验证的条件，没有条件的分支一律要求补齐；第四，泳道是否齐全，每个活动节点是否都能放进唯一一条泳道，放不进去的节点需要重点解释；第五，是否覆盖了异常和驳回路径，只画通路的图直接打回；第六，节点粒度是不是统一，有没有一个大节点吞掉整段流程；第七，图面和需求文字是否一致，节点编号能否一一对上。

这套清单我在评审里用过很多次，效率很高。拿到一张图，不用从头看到尾，直接把清单过一遍，问题点就能快速暴露。审图不是挑刺，目的是让需求方、设计方、开发方、测试在流程认知上一致。活动图作为需求分析与设计之间的桥梁，它的终点不是画出图，而是让所有人都通过对这张图的讨论，真正理解未来系统要跑起来的业务过程。

我最近一次梳理流程类需求，还是靠活动图把几个部门之间的扯皮收敛下来的。业务方反复强调的“灵活处理”，在图上被拆成了五条明确分支之后，大家才发现每个人对“灵活”的理解完全不一样。真正有价值的不是那张图，而是画图时逼出来的这些对话。如果你手里正有个流程类的需求说不清楚，不妨找个白板开始画。第一张图肯定会很丑，但第二张、第三张会越来越接近真正的业务流程。