状态太多，通常不是标签组件不够用，而是团队把流程阶段、处理结果、风险提示和用户任务全塞进了同一个“状态”字段。先把业务模型理清，再画界面，很多状态自然会消失。
状态太多，通常不是标签组件不够用，而是团队把流程阶段、处理结果、风险提示和用户任务全塞进了同一个“状态”字段。先把业务模型理清，再画界面，很多状态自然会消失。
01 先区分四种经常被混在一起的信息
| 类型 | 回答的问题 | 示例 |
|---|---|---|
| 业务状态 | 这个对象当前处于哪个生命周期阶段 | 草稿、待审核、已生效、已关闭 |
| 处理结果 | 某次动作得到了什么结果 | 审批通过、校验失败、支付失败 |
| 用户任务 | 现在轮到谁做什么 | 待我审批、待补充材料、待财务确认 |
| 风险或属性标签 | 对象具有何种特征 | 高风险、即将逾期、重点客户 |
把“待我审批”和“高风险”都做成业务状态，会出现难以维护的组合：高风险待我审批、普通待我审批、高风险待他人审批……状态数很快失控。
更合理的方式是让业务状态保持互斥，让任务和风险以独立字段表达，界面再按场景组合展示。
02 用六个要素描述状态机
对象
状态属于谁？订单、合同、工单、审批单、付款批次可能各自有生命周期。不要用一张状态表同时描述多个对象。
状态
对象在某一时刻所处的稳定阶段。状态名称应能被业务人员理解，不是接口代码。
事件
什么事情触发变化，例如提交、审批、付款回调、超时、取消。
条件
事件发生后是否允许流转，例如金额超过阈值需要二级审批，只有草稿创建人可以撤回。
执行者
是谁触发或确认：用户、管理员、定时任务、第三方系统。
动作与结果
状态变化时系统还要做什么：记录日志、发送通知、锁定字段、生成账单、更新库存。
如果一条流转说不清这六项，界面设计很容易在后期反复补丁。
03 建一张状态流转表
以合同为例：
| 当前状态 | 事件 | 条件 | 执行者 | 下一状态 | 同步动作 |
|---|---|---|---|---|---|
| 草稿 | 提交审核 | 必填完整 | 创建人 | 审核中 | 锁定核心字段、通知审批人 |
| 审核中 | 通过 | 所有必需审批完成 | 审批人/系统 | 待签署 | 生成签署文件 |
| 审核中 | 退回修改 | 填写原因 | 审批人 | 待修改 | 解锁指定字段、通知创建人 |
| 待修改 | 重新提交 | 问题已处理 | 创建人 | 审核中 | 创建新审核轮次 |
| 待签署 | 双方签署完成 | 签署有效 | 签署系统 | 已生效 | 写入生效时间、启动履约 |
| 任意允许状态 | 取消 | 满足取消规则 | 授权角色 | 已取消 | 记录原因、终止后续任务 |
这张表比一张箭头很多的流程图更适合研发、测试和运营共同确认。流程图用于看整体，流转表用于把规则写清。
04 状态名称要描述事实，不要描述模糊情绪
“处理中”“已完成”“异常”看似通用，实际信息不足。处理中是等待用户、等待系统还是等待第三方？已完成是业务完成、数据同步完成还是款项到账？
建议遵循：
- 用当前事实命名，而不是未来承诺；
- 同一层级使用一致语法；
- 避免“正常、异常”作为唯一说明；
- 用户任务可以用“待我…”表达，但不要写进对象主状态；
- 终态名称清楚区分成功、取消、拒绝、失败和过期。
05 颜色只负责辅助，不负责定义
同一种绿色在不同模块里可能代表“已通过、已完成、已生效、正常”。如果用户必须靠颜色理解，系统已经缺少文字信息。
状态组件至少要有清楚的文本。颜色、图标和形状用于提高扫描速度，并保持跨模块一致。高风险状态还可以补充原因、截止时间或下一步，但不要把一整段信息都塞进标签。
| 类型 | 视觉建议 | 注意事项 |
|---|---|---|
| 进行中 | 中性色或品牌辅助色 | 说明正在等待什么 |
| 成功终态 | 正向色 + 明确结果 | 不要把“已提交”误作业务成功 |
| 需用户处理 | 强调色 + 任务文案 | 提供直接操作入口 |
| 警告 | 警示色 + 风险原因 | 与错误区分 |
| 失败/拒绝 | 负向色 + 可恢复说明 | 告诉用户能否重试或申诉 |
| 取消/过期 | 弱化色 | 保留原因和历史记录 |
06 每个状态都要定义可用操作
设计师经常先画一排按钮，再让产品决定哪些状态显示。更稳妥的方式是把操作写进状态规格：
- 当前状态允许哪些操作；
- 哪个角色可执行；
- 操作前需满足什么条件；
- 是否需要确认和填写原因；
- 操作后进入什么状态；
- 是否可撤销；
- 失败后保留在哪里。
同一个“撤回”在草稿提交后、审批通过后和付款发起后，业务含义可能完全不同，不能只复用按钮名称。
07 组合状态要用派生规则，不要无限新增枚举
例如工单主状态为“处理中”，同时有“已逾期”和“高优先级”。不要创建“高优先级逾期处理中”新状态。可以通过派生规则计算风险标签和用户任务：
这样列表可以显示“处理中 / 已逾期 / 待我处理”，筛选和统计也保持清楚。
08 异常和超时必须进入模型
真实业务不会一直沿理想路径运行。至少讨论：
- 第三方回调迟到或重复；
- 用户重复提交；
- 状态变更时数据已被其他人修改；
- 审批人离职或无权限；
- 长任务超时；
- 系统重试后成功；
- 人工修正；
- 历史数据没有新状态字段。
异常不一定都成为新业务状态。有些适合记录为任务、错误或系统事件。关键是用户能否知道当前事实和解决办法。
09 状态变化要留下可理解的历史
历史记录不应只写“状态从3变为4”。用户需要看到：谁在什么时间，因为什么动作，把什么从哪里改到哪里；涉及退回、取消和人工修正时，还应保留原因。
对于自动流转，明确显示“系统根据超时规则自动关闭”，不要伪装成某个人操作。
10 用模拟而不是凭想象检查状态
将状态模型放进真实场景中跑一遍：
1. 正常完成；
2. 中途退回并再次提交；
3. 多人同时操作；
4. 权限被撤销；
5. 外部接口失败后重试；
6. 超时、取消和恢复；
7. 历史数据迁移；
8. 用户从通知深链进入。
每个场景检查界面文案、按钮、通知、列表筛选、详情时间线和后端结果是否一致。状态机图看起来闭合，不代表产品体验闭合。
11 状态规格应该成为共享资产
建议将每个状态维护成一张规格卡：名称、定义、进入条件、退出条件、可执行角色、可用操作、界面文案、颜色图标、通知、审计和数据字段。产品、设计、研发、测试和运营共同使用，不要在各自文档里维护不同版本。
常见问题
状态数量多少算太多？
没有固定数字。若多个状态只在标签颜色或责任人上不同，可能需要拆分维度；若每个状态都有独立业务规则和生命周期意义，多一些也合理。判断标准是能否清楚解释和测试每条流转。
“审核中”和“待我审核”应该是两个状态吗？
通常不需要。前者是对象状态，后者是相对于当前用户生成的任务视图。分开建模，可以让不同审批人看到各自任务，而对象仍保持同一个业务状态。
状态修改后，历史数据怎么办？
要建立旧值映射、迁移规则和无法映射的处理方式。涉及统计口径时，还要决定历史报表按旧定义还是新定义展示，并保留版本说明。
12 让研究和设计真正进入产品决策
链接复制成功
