状态转换表要写清“对象处于什么状态、收到什么事件、满足什么条件、进入哪个状态、同时发生什么动作”。只列“待处理、处理中、已完成”是状态清单，还不足以指导研发实现或测试判断。
产品经理可以先写表，再在墨刀原型中把业务状态对应到页面反馈。本例用售后维修工单说明：工程师接单、提交维修结果、客户确认和重新处理，如何形成一套能走通的约定。
先确定对象，再给状态命名
“已完成”是谁完成了什么？工程师完成维修，不一定等于客户确认问题已解决。因此本例把“工程师提交结果”后的工单记为“待确认”，客户接受后才进入“已完成”。这比在说明里补一句“已完成但还没真正完成”更清楚。
同一个页面还可能显示加载、提交中、网络错误。这些是界面或请求状态，不宜都塞进维修工单的业务状态。请求失败时，工单可能仍然处于处理中；页面显示红色提示，不代表业务对象已经变成“失败工单”。
先给状态一个简短定义，再决定可用操作。例如待接单表示尚无工程师承接，处理中表示已有工程师负责，待确认表示已经提交结果等待客户判断。每个状态都要能通过业务记录解释，而不是只能看按钮颜色识别。
一行转换只说明一次业务变化
Stately的状态转换说明将事件与状态变化联系起来，并区分触发事件、转换条件和目标。写PRD时无需采用它的代码格式，但这种拆分能让“什么时候允许变化”更具体。
| 当前状态 | 事件 | 前置条件 | 目标状态与动作 |
|---|---|---|---|
| 待接单 | 工程师接单 | 有接单权限；尚未被他人接走 | 处理中；记录负责人和接单时间 |
| 处理中 | 提交维修结果 | 操作者为当前负责人；结果说明非空 | 待确认；保存结果并通知客户 |
| 待确认 | 客户确认解决 | 操作者可代表该客户；对应当前结果版本 | 已完成；记录确认人和时间 |
| 待确认 | 客户反馈未解决 | 填写仍存在的问题 | 处理中；保留上次结果，通知负责人 |
| 待接单 | 申请人取消 | 尚未进入处理 | 已取消；保存取消记录 |
本例不允许处理中直接取消，也不包含完成后重开。真实业务如果需要这些路径，应另加转换并写明后果，而不是让研发根据“通常应该可以”自行补齐。表格的价值也包括把当前不支持的行为显露出来。
记录通知、计时和分配变化时，别把“动作已经计划执行”写成“用户一定收到”。通知发送失败是否重试、工单状态是否仍然变化，需要业务和技术共同约定。状态与外部动作的成功条件不能含糊地绑在一起。
条件失败要有结果，不能只有允许路径
两名工程师同时看到待接单工单，第一人接单后，第二人的旧页面仍可能显示接单按钮。第二次提交时应重新判断当前状态，并反馈“此工单已由其他工程师接单”，刷新负责人。不能仅依靠进入页面时的检查。
同样，客户确认的是某一版维修结果；如果结果已更新，旧确认页应提示重新查看，而不是把旧决定直接应用到新内容。涉及并发时，表格可以补“状态版本”或“结果版本”的校验字段，让双方明确提交依据。
建议在表后列三类禁止路径：当前状态不支持的事件、操作者不符合条件、事件引用的对象版本已变化。每类都给用户可理解的反馈与下一步。禁止不是把按钮全部藏起来，而是保证真实提交也不能越过规则。
重复请求不应重复产生业务后果
用户点击提交后网络超时，无法确定服务器是否已收到，可能再次点击。需求应写清重复提交如何识别：是返回同一次提交的结果，还是重新创建一个处理动作。对于接单、确认等操作，不能因为一次重试就重复通知、重复计费或多次推进。
产品文档无需替研发决定所有实现细节，但应给出可验收的行为。例如：同一次确认重试后仍只有一条有效确认记录；显示当前真实状态；不会重复触发后续工作。具体使用请求标识、状态版本还是事务机制，由技术方案补齐。
把状态表映射到原型和测试
状态表、页面和测试用例应共享编号。例如转换T02是“处理中提交结果到待确认”，原型中的提交按钮说明引用T02，测试则分别覆盖成功、缺少结果、负责人不符和工单已变化。这样修改规则时能找到受影响的位置。
这与PRD和原型的需求追踪互相补充：追踪矩阵说明一条需求落在哪些成果里，状态转换表说明一个业务对象如何变化。不要让一张表同时承担所有目的，最后每个单元格都塞满长段说明。
评审时按顺序走“接单→提交结果→客户反馈未解决→再次提交→确认”，再打断其中一次操作。若表中每次变化都有依据，页面也能说明当下发生了什么，团队才真正对齐了规则，而不只是统一了状态名称。
