很多人画完活动图，拿给同事看，同事说：这不就是流程图吗。
这句话一般不是抬杠，是图的确画成了流程图。
活动图和流程图长得几乎一样：都是圆角框、菱形、箭头。但它俩要回答的问题完全不同——流程图回答"下一步做什么"，活动图回答"哪几步可以同时做、什么时候必须凑齐才能往下走"。
差别只有两个字：并发。
而这两个字，恰恰是流程里最省时间、也最容易出事故的地方。
一、先把四张图划清楚
动手之前先确认你该画哪一张。这四张图经常被人混着用，结果画出来谁也看不明白。
| 图 | 回答什么问题 | 关键元素 | 什么时候用 |
|---|---|---|---|
| 流程图 | 下一步做什么 | 判断框、流向 | 单线程、线性步骤 |
| 泳道图 | 这一步归谁 | 泳道、跨泳道交付 | 要分清责任边界 |
| 活动图 | 哪几步能同时做、什么时候必须凑齐 | 分叉、汇合、对象流 | 有并行、有等待、有超时 |
| 状态图 | 这个东西现在是什么状态 | 状态、迁移、守卫 | 围绕单个对象的生命周期 |
一句话判断：只要流程里有"等"这个字，就该画活动图，不该画流程图。
等审批、等回调、等对账、等对方确认——凡是有等待的地方，就有并行优化的空间，也就有汇合漏画的风险。
二、六个零件，只有一个是新东西
活动图的零件大部分你都见过，只有一组是新的。
1. 起点：实心圆。整个流程只有一个。
2. 动作：圆角矩形。写法有讲究，必须是"动词 + 名词"，例如"提交报销单"，不能只写"提交"。只写动词的活动图，跟没写一样。
3. 判断：菱形。出口分支上必须写守卫条件，用方括号包起来，例如 [金额 > 2000]。守卫必须可判断——写"金额较大"是废话，写不出数字就说明这条规则还没定。
4. 分叉与汇合：粗横线。分叉（fork）是一进多出，汇合（join）是多进一出。这是活动图唯一的独门元素，下面单独讲。
5. 泳道：纵向或横向的分区，每个动作必须落在某个泳道里。活动图里泳道是可选的，但只要有跨角色交付，就必须画。
6. 终点：实心圆加外圈。可以有多个（正常结束、被撤销、超时终止各画一个）。
三、分叉和汇合：一条粗线的分量
分叉的意思很简单：从这一根线往下，几条分支同时开始。
用活动图内部的话说，就是走到这里的那个"令牌"分裂成了几个，每个分支各拿一个，各跑各的。
汇合的意思更关键：必须等所有分支都走到，才能继续往下。
不是"任一到达就继续"，是"全部到达才继续"。这个区别看着只有两个字，实际是钱的问题——下面算例会讲。
画法就一条粗横线，进出线数不一样：
- 分叉：一根进，两根（或多根）出
- 汇合：两根（或多根）进，一根出
验收口诀：分出去几条，就得合回来几条。 分了三条只合回来两条，那条没合的就会在上线以后自己跑出去。
四、完整算例：一个月8600单的报销流程
下面这个例子是我照着我们自己的系统改的，每一步都能验算。
4.1 现状：全是串行的
原来的流程是这样的：
员工填单 → 提交 → 财务审核 → 部门审批 → 判断金额 [> 2000] → 是则总监审批 → 付款 → 出账 → 结束
每一步的耗时（系统里拉出来的真实均值）：
| 步骤 | 类型 | 耗时 |
|---|---|---|
| 员工填单 | 人工 | 12 分钟 |
| 提交 | 自动 | 0.5 分钟 |
| 财务审核 | 人工等待 | 26 小时 |
| 部门审批 | 人工等待 | 9 小时 |
| 总监审批（仅大额） | 人工等待 | 14 小时 |
| 付款 | 自动 | 5 分钟 |
| 出账 | 自动 | 2 分钟 |
金额分布：月 8600 单，其中超过 2000 元的占 39%（3354 单），其余 61%（5246 单）不需要总监这一关。
加权平均走完一圈的时间：
- 小额：0.2 + 26 + 9 ≈ 35.2 小时
- 大额：35.2 + 14 = 49.2 小时
- 平均：0.61 × 35.2 + 0.39 × 49.2 = 21.5 + 19.2 = 40.7 小时
也就是说，一笔报销从提交到打款，平均要躺在系统里一天半还多。
4.2 改造：把三个等待并行
画活动图的好处在这儿体现出来了——把三个等待画到一张图上，立刻能看出它们是并列关系，谁也不依赖谁的结论。
前提是：财务审的是票据合规性，部门审的是事由真实性，总监看的是预算。三个人看的是同一张单据的三个方面，不需要等彼此。
改造后的图：
员工填单 → 提交 → 【分叉】 → 三条并行：财务审核 / 部门审批 / 总监审批（小额单跳过） → 【汇合】 → 判断"三票是否都通过" → 是则付款 → 出账 → 结束
耗时变成取最大值：
- 小额：max(26, 9) + 0.2 ≈ 26.2 小时
- 大额：max(26, 9, 14) + 0.2 ≈ 26.2 小时
- 平均：26.2 小时
从 40.7 小时压到 26.2 小时，一天半变成一天出头，平均省 14.5 小时，降了 35.6%。
注意这里有个反直觉的地方：小额单从 35.2 降到 26.2，也省了 9 小时。因为它原本要排在大额单后面排队等，而现在大额和小额走的是同一条时间线，队列不再被大额拖住。
这就是活动图最实在的用处：它把"等"这个字从图上暴露出来，逼你去问一句——这几个等待，真的有先后关系吗？
4.3 漏画汇合的代价
我们第一版改造完，上线第十一天出了一件事。
一笔 26800 元的报销，付款成功了。而部门审批那条线，状态是"未通过"。
原因就是汇合画漏了。
图上是分叉出去三条线，然后三条线各自往下走，最后都指向"付款"。看着每个箭头都对，可"付款"这个动作只要任意一条线到达就会触发——它根本没在等另外两条。
那个月的 8600 单里，命中这个漏洞的有 3 单，占比 0.035%。
数字小得可怜，但其中一笔两万六千八。
后来改法很简单：三条线在付款前必须全部汇合到一条粗横线上，汇合后再判断"三个审批结果是否都为通过"，是才付款，否则进人工处理。
这就是分叉汇合这条粗线的分量。它不是装饰，它是"必须凑齐"这四个字的唯一表达方式。
4.4 顺手加的两个东西
对象流。用虚线箭头，把"报销单"这个对象在各步骤之间的状态变化连起来：草稿 → 待审 → 审批中 → 已通过 → 已付款。
对象流不画流程，画的是"这张单据被改成了什么样"。有了它，评审时一眼能看出哪个步骤在改单据、哪个步骤只在读。
中断活动区。审批等待那条分支，可以框一个可中断区，标上"超过 48 小时 → 自动撤销并通知申请人"。
这是活动图才有、流程图没有的东西。它回答的是"卡住了怎么办"——而凡是有人等待的流程，一定会卡住。
五、五个最常见的坑
1. 画成了流程图。 通篇没有一个分叉汇合，那这张活动图等于白画，改叫流程图更诚实。
2. 分了三条只合回来两条。 上面那两万六千八就是这么没的。画完数一遍：分出去几条，合回来几条。
3. 假并行。 两条分支画成并行，实际上 B 要用到 A 的结果。图上是并行的，跑起来是串行的，工期估算是错的。判断方法：问一句"这两条线，先做完的那条要等后做完的那条吗"，答案是"要"，就不能分叉。
4. 守卫条件写不出数字。 [金额较大]、[情况特殊] 这类守卫，评审时没人能判断，开发完也只能自己拍脑袋。写不出具体数值或具体条件，说明业务规则没定，先把那条线摘掉。
5. 泳道画了，动作没落进去。 有些图把泳道画成背景，动作全堆在中间。这样的泳道没有任何意义。验收办法：随便指一个动作，能不能立刻说出它是谁的活。
六、画完自检的 9 条
- 图和流程图相比，有没有新增至少一个分叉或汇合？没有的话，回去找"等待"的步骤。
- 分出去几条，合回来几条？数一遍。
- 每一条并行分支，真的不依赖别的分支的结果吗？
- 每个动作的命名是"动词 + 名词"吗？
- 每个判断的守卫条件，能取到具体数值或具体状态吗？
- 判断的出口是否覆盖了所有情况（包括"都不满足"）？
- 有人等待的分支，有没有超时处理（中断区或超时分支）？
- 终点有几个？被撤销、超时终止这些非正常结束，画出来了吗？
- 拿这张图给一个没参与设计的人看，他能不能说出"哪几步是同时做的"？
第 9 条最难，也最有用。说不出来，就是图还没画明白。
七、和其它图怎么配合
一次需求评审通常不止一张图，顺序大致是这样：
用例图定范围 → 活动图定并行与等待 → 时序图定接口调用顺序 → 状态图定单据（或订单）的生命周期 → ER 图定数据怎么存。
其中活动图是唯一一张会直接改变工期估算的图。流程图告诉你要走几步，活动图告诉你这几步里有多少能叠在一起。
一个流程如果有四个等待节点，串行加起来是 49 小时，并行压到 26 小时——这中间的 23 小时，不画图就永远不会被发现，因为每个人都默认"审批嘛，总得一个个来"。
最后说一句实在话：活动图真正画的不是动作，是时间。
那些粗横线画在哪儿，就决定了这个流程要花多久，以及——在哪儿可能出事。