## 任务目标
请为业务设计可交给研发实现的状态流程。重点解决多步骤录入或审批流中下一步不清楚、操作后果不明确的问题。
交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。
## 输入信息（选填）
两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。
办理流程：
规则与流程资料：
## 信息不完整时
先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。
### 优先确认
- 核对业务状态定义、状态转换代码或规则配置，区分加载状态与真实业务状态。
- 逐项读取提交、驳回、重提、撤回和关闭的适用条件、角色、版本及历史保留方式。
- 查草稿保存、返回、关闭页面、网络中断后的数据恢复机制，以及幂等、并发版本控制和回调处理证据。
### 可采用的默认处理
- 只把已确认状态和转换纳入正式流程图，缺失规则以带影响说明的候选分支表达。
- 分离草稿保存与正式生效，业务终态说明办理结束，不强行安排下一责任人。
- 并发、重复点击和超时先按现有能力描述；无实现证据时列为待实现要求，不宣称系统已具备幂等或自动恢复。
### 必须有依据的事项
- 审批权限、合法状态转换或撤销生效后果缺少业务依据时，不能自行决定，先完成其他已确认路径。
- 历史记录与新版本的责任归属冲突时，不能猜测沿用原处理人或自动生效规则。
只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。
### 资料仍不足时的交付
- 没有工程时依据规则材料交付状态词典、状态转移表、分步表单和角色视角路径。
- 规则仅部分明确时交付已确认主流程、关键异常候选及逐项决策影响，不把未确认分支画成既定流程。
## 执行要求
将任务顺序、状态变化、权限和异常处理写清楚，具体规则以业务材料为准。
1. 以业务对象为单位列出状态，解释每个状态的业务含义及结束条件。分离业务状态与界面加载状态，不用一个含混的“处理中”同时代表审批、支付和文件上传。
2. 建立状态转移表，逐行填写当前状态、触发动作、可执行角色、前置条件、目标状态和失败结果。没有规则依据的撤销、删除或自动审批不能自行加入正式流程。
3. 明确提交、驳回、修改、重新提交、撤回和关闭等动作是否适用，注明是否保留原记录、是否生成新版本及原处理人是否继续有效。不能适用的动作说明理由。
4. 为步骤设计输入边界和保存时机，区分草稿保存与正式生效。说明返回上一步、关闭页面、网络中断后哪些数据保留，以及恢复入口在哪里。
5. 检查两人同时审批、重复点击、对象已被修改、账号权限变化和超时回调的处理结果。后端尚无幂等或版本控制依据时列为实现要求或待评审项，不能声称已具备。
6. 按办理角色走通一条正常路径和关键异常路径，检查每一步是否能看到对象当前状态、操作结果和下一责任人；已到合法终态时说明办理结束，无需下一处理人，并写出逐段验收条件。
## 交付与验收
输出：状态词典、状态转移表、完整业务流程、分步表单说明、异常处理表、角色视角走查记录与验收条件。流程图只表达已确认状态，未确认转移使用文字列出。
验收：中间状态具备明确进入和退出条件，初态明确触发来源，终态明确结束结果；每个动作均有角色和后果；中断和并发场景能够得到明确处理；用户可知道下一步由谁完成或当前流程已经结束。
信息边界：规则缺失时给出明确标注的候选方案及影响，不替业务方决定审批权限，不把设计走查写成已执行系统测试。
### 本条完成检查
- 每个状态有含义与进入退出条件，每个动作有角色、前提、后果和失败结果。
- 草稿、正式提交、中断恢复、并发及历史版本规则分别明确。
- 角色能知道下一步由谁办理或流程已经结束，设计走查与真实系统测试分开记录。
按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。
## 参考资料与适用边界
参考来源（核验于 2026-09-08）：
- [Ant Design 表单页](https://ant.design/docs/spec/research-form-cn/)
