图表图表类型
AI 状态图生成器
描述一个状态机,拿一张带跳转条件的状态图。
点一个试试 —— 会直接带进生成器
订单状态机:draft -> submitted -> paid -> shipped -> delivered。draft 可取消,paid 可退款,支付失败则 submitted 退回 draft。cancelled 和 refunded 是终态。
Try it →功能灰度发布状态机:draft -> internal_testing -> beta -> gradual_rollout -> stable。任何状态可回退到上一状态。gradual_rollout 如果指标恶化可以直接跳到 killed。killed 是终态。
Try it →客服工单流转:new -> triaged -> assigned -> in_progress -> waiting_customer -> resolved -> closed。任何非终态可以升级到 escalated。resolved 后客户可以在 7 天内重开回 assigned。
Try it →OAuth access_token 生命周期:issued(有效)。issued -> expired(TTL 到期)。issued -> revoked(用户登出或管理员撤销)。expired 若 refresh_token 有效可刷新回 issued。revoked 是终态。
Try it →适用场景 AI 状态图生成器
表单和向导的状态
多步向导、结账漏斗、新手引导。草稿、待审、已通过、已驳回各自对应不同的界面和权限时,状态图就是这套规则的唯一出处。
审批和工作流
代码评审状态、订单状态、工单状态。凡是会经过若干个有名字的阶段、并且规定了谁能触发哪次跳转的对象,都值得画一张。
重试和恢复
任务从等待到运行,再到成功、失败、取消、重试中。重试逻辑一复杂(退避、死信队列),看状态图比看重试代码好理解。
前端组件状态
加载中、空状态、出错、成功 —— 每个页面都得处理这四种。状态图把设计规范里的约定摆到明面上:这个组件管哪几种状态、怎么转。
协议和设备规范
TCP 握手、WebSocket 连接的生命周期、硬件的工作模式。协议规范一直用状态图写,因为它精确到可以照着实现。
用对话模式画状态图 —— 会吵起来的从来是转移,不是状态
AI 状态图生成器拿一句话就能画出主路径:试用、生效、已取消。真正会吵起来的是别的转移 —— 已经点了取消的订阅还能不能反悔?过期是一个状态还是一个事件?对话模式只就那个会改变状态机骨架的转移问一句,剩下的直接画,画完再把自己加的转移列出来。下面是一个 SaaS 订阅生命周期,起点是一句故意含糊的话。
- 把「试用中」设成了初始状态 —— 新订阅从试用开始,不是一上来就生效
- 加了一条从「到期后取消」回到「生效中」的转移,让用户可以撤销取消
- 续费扣款失败按「先挂在逾期未付里反复重试」处理,而不是一次失败就直接取消
- 你没说重试多久,逾期那条出口上自己填了 14 天的窗口
- 给「试用到期又没绑支付方式」补了一个终止状态「已过期」
四句话画出了一台带延迟取消、带真实退出条件的催款回路、还带套餐条件的暂停分支的状态机 —— 这三样开头那句话里一样都没有。同样一句话直接一次性生成,大概率只给你「生效 → 已取消」,而计费代码真正会写错的那几条转移,要等客服提工单才会被发现。
详细说明
当你关心的不是「先做什么再做什么」,而是「这个东西现在处于什么状态,从这个状态还能合法地跳到哪」,就该画状态图。适用的对象是那些会经过一串有名字的状态、并且哪个状态能接哪个状态有明确规则的东西 —— 订单、文档、账号、灰度开关、订阅。
有一个很明显的信号:团队开始争论「用户能不能同时处于已冻结和待验证」。这问的是状态合不合法,不是流程顺序。状态图逼着你把每个状态列一遍、每条跳转显式画出来 —— 画的过程里就会发现那些原本会以线上 bug 形式出现的矛盾。
Mermaid 的 stateDiagram-v2 支持复合状态、并发区域、进入和退出时的动作,还有标准的 `[*]` 起止标记。订单和订阅的流转、文档的审批状态、设备的工作模式、灰度的各个阶段,以及需要向审计证明边界清楚的生命周期,都适合。它不擅长的是几个有状态的对象之间怎么互相影响 —— 那种再配一张时序图。
自己试一下?
不知道怎么描述?
对话模式里 AI 会先问你两三个问题 —— 谁参与、发生什么、异常分支怎么走 —— 弄清楚了再动笔。
想画得更规范?
教程里讲了常用符号、几种基本结构、九条画法规范,还有可以直接拿去用的 prompt 模板和真实业务例子。