Article
很多团队做审批系统，一开始讨论得最热闹的是要几个页面、几个列表、几个按钮。可真正把项目做乱的，往往不是界面数量，而是状态到底有几种、哪些动作能改变状态、例外情况如何进入和退出、人工能不能改写，以及改写后谁来负责。只要这些边界没先定，页面做得越快，后面返工就越多。
发布时间
2026年5月5日
阅读时间
7 分钟
流程
审批、工单、售后、采购、报销、订单流转，这类系统表面上看都是表单加节点，真正难的是状态管理。草稿、提交、退回、撤回、作废、补资料、再次审批、人工接管，这些状态一旦定义含糊，前后端、运营和业务方对同一个单据就会出现不同理解。
我现在做这类项目，一期通常不会先追求页面铺满，而是先把状态机、关键动作、例外分支和操作日志的边界定清。因为系统能不能长期维护，主要取决于这套骨架是否稳定，而不是首页列表是不是已经全部做出来。
很多项目需求会直接写“做发起页、审批页、待办页、详情页”，但很少先把状态字典写清。结果就是前端以为“退回”和“驳回”差不多，后端把“已取消”和“已关闭”混在一起，业务方又希望“补资料中”还能继续催办。页面都能做，流程却说不清。
更稳的起点是先把一个业务对象从开始到结束可能出现的状态列出来，再定义每个状态下允许哪些动作、动作后进入什么新状态、谁有权限触发。只要状态图清楚，列表筛选、按钮显示、消息通知、统计报表和审计记录都会顺很多。
先定义状态名称、状态含义和进入条件，而不是先讨论页面排版
把“退回”“驳回”“撤回”“作废”这类容易混淆的词拆成明确业务动作
同一个状态是否可编辑、可审批、可催办，要和权限一起写清
很多系统上线后被迫回到线下，不是因为主流程跑不通，而是例外路径没人接。比如审批人请假了怎么办，资料补交后回到原节点还是重跑，紧急单能不能跳过部分环节，金额超限时是升级审批还是转特殊流程。这些问题只要靠群消息临时拍板，系统很快就会变成“正常单走系统，异常单走人工”的两套流程。
如果某类例外高频出现，就不应该把它留给实施阶段临场处理，而应该在一期模型里定义成正式分支。不是所有边角情况都要系统化，但高频、可预见、影响责任划分的例外，越晚补越贵。
区分低频噪音和高频例外，高频例外应该进流程设计
升级审批、临时代理、补资料、撤回重提这类分支通常要提前建模
如果例外路径只能靠备注解释，说明系统边界还没定住
真实交付里，总会遇到必须人工介入的场景：管理员代提交、主管临时转交、财务纠正状态、客服补录信息、运营撤销误操作。如果系统只允许理想动作，不允许合规的人工改写，团队最后会直接改数据库或回到 Excel；但如果所有人都能随意改状态，审计和责任又会立刻失真。
所以人工改写不是要不要有的问题，而是要不要被设计成可追踪的正式能力。哪些角色可以改，什么条件下能改，改完是否保留原值和原因，是否需要二次确认，是否触发通知，这些都要在一期说清。
把“人工修正”设计成少数受控动作，而不是隐藏后门
关键改写要保留原状态、操作者、原因和时间
人工改写后是否继续自动流转，要有明确规则而不是默认猜测
很多团队会分别开会讨论前端页面、后端接口、消息通知和管理报表，最后每块都看起来合理，但拼不成一个统一系统。根因通常不是某个模块做错了，而是大家没有共享同一套状态真相，所以每个人都在按自己的理解补功能。
一旦状态机和例外分支先定住，很多实现判断会简单很多。哪些列表需要分组，哪个按钮在哪个状态出现，哪些通知是状态变化触发，哪些报表按动作统计，哪些接口必须幂等，都会有统一依据。这样一期虽然前期看起来讨论更慢，后期返工通常会少很多。
审批和流程系统的一期骨架，不是页面树，而是状态机、动作和例外分支。
高频例外和人工改写边界如果不先设计，系统很容易只适合跑主路径。
页面、接口、通知和报表都应从同一套状态真相反推，后续维护才不会各说各话。