异常路径设计：在批准前规划拒绝

为什么理想路径不足以应对现实

大多数团队从工作流的干净版本开始。提交一个请求，有人审核，然后批准。看起来高效，但它掩盖了真正的工作所在。

理想路径通常是最短路径。表单完整、附件齐全、审核人知道下一步该做什么。在实际操作中，那往往不是导致延误的环节。

延误开始于某些内容缺失、不清楚、迟到或只被部分接受。经理可能批准了预算但拒绝了某一条目。财务可能需要一份从未上传的税务文件。支持负责人可能退回请求，因为“原因”栏过于模糊。每一个这样的时刻都会增加额外步骤、额外消息和额外等待。

如果这些情况没有提前规划，人们就会现场做决定。一个审核人发一封邮件，另一个在工具里留个评论，第三个在没有解释的情况下拒绝请求。提交人只能猜测：他们应该修复问题、重新开始，还是找人帮忙？

这种混乱有成本。它拖慢了提交请求的人、审核的人，以及所有被拉来解释的人。本来在白板上看起来简单的工作流，会变成后续聊天、重复提交和手工交接。

一个基本的审批流程很容易画出来：

• 提交请求
• 审核请求
• 批准请求

真正的版本更复杂。文件缺失怎么办？请求只被部分批准怎么办？审核人拒绝但用户可以修复怎么办？这些并非罕见情况，对许多团队来说，它们就是常态。

这就是为什么在画界面、命名状态之前，异常路径设计值得重视。异常路径定义了现实打断计划时会发生什么，而现实经常会这么做。

如果你在构建内部审批应用，包括在像 AppMaster 这样的无代码平台上，拒绝和不完整的情况需要和批准情况一样多的关注。它们决定了人们看到的消息、可执行的操作，以及流程是帮助人们恢复还是让他们卡住。

理想路径展示意图。异常路径展示流程在真实使用中能否存活。

什么是异常路径

异常路径是当请求无法按常规方式推进时会发生的事情。它不是罕见的边缘情况，而是处理真实世界混乱的部分：请求被拒、表单不完整、某一部分被批准但另一部分未通过，或工作被卡住。

清晰的异常路径使用明白的语言。不要用模糊的状态比如“失败”，要说明发生了什么："拒绝：因为预算超出限额" 或 "等待身份证明文件"。人们应该知道哪里出了问题、谁需要行动以及接下来会发生什么。

大多数工作流以几种可预测的方式出问题：

• 请求被明确拒绝
• 必需的文件或字段缺失
• 请求只被部分批准
• 请求没有负责人或没有定义下一步

信息缺失是最常见的问题之一。想象一个需要税务文件和银行账号的供应商入驻表单。如果任一项缺失，系统不应该就此停止。它应将请求标为不完整，准确显示缺少什么，并将其发回给合适的人。

部分批准同样重要。想想一个包含机票、酒店和餐补预算的出差申请。经理批准了机票和酒店，但削减了餐补预算。此时流程需要规则。员工接受变更、更新请求，还是取消行程？

停滞也很关键。请求可能因为分配的审核人离职、团队没有设置备用审批人，或流程走到没有下一位负责人的步骤而被搁置。技术上没有故障，但请求仍无法推进。

如果你不提前设计这些路径，人们就会通过邮件、聊天或表格笔记来处理。很快没人知道哪个版本是最终的。

一个简单的审批示例

以一个销售经理想参加为期两天的会议的出差申请为例。纸面上的流程很简单：员工填写行程日期、预计费用和出差理由。经理批准，财务确认预算，行程进入预订阶段。

这个流程看似完整，但其实不够。

现在把同一请求“打破”。员工上传了机票预估和会议门票，但忘记上传酒店报价。如果系统只知道“已提交”和“已批准”，人们会很快卡住。财务可能看到不完整的请求，经理可能认为一切就绪，而员工不知道缺了什么。

更好的流程会给该请求自己的状态，比如“等待文件”或“需要更新”。员工应看到清晰的信息：“在此请求进入财务前，请添加酒店报价。”经理不应不得不整单拒绝请求只是为了索要一个文件。

再加一个问题：经理同意员工出差，但不同意全部金额。他批准了机票和一晚酒店，但拒绝了额外的研讨会费用和第二晚酒店。

此时许多团队会发现他们并没有真正的部分批准流程。

如果工作流不能只批准请求的一部分，人们就开始使用变通办法：他们可能拒绝整个请求并要求员工重新提交，或因为系统只记录一个二选一的决定，财务可能错误地批准了全部金额。

更清晰的模型会跟踪每一项费用，或至少记录批准的总额。请求页可能显示：

• 机票：已批准
• 酒店：批准 1 晚
• 研讨会附加费：不批准
• 申请总额：$1,450
• 批准总额：$980

这个例子说明了为什么审批流程错误往往来自规则缺失，而不是人的粗心。如果你在设计界面前先定义这些规则，剩下的流程就更容易被信任。

在画界面前设计异常

一种改善工作流的好方法是假设请求不会顺利通过。这个思维转换能快速提升设计质量。

从混乱的情况开始：表单不完整、政策不清晰、审批人缺席或仅允许部分通过。大多数团队可以把这些归类为三种主要模式：

• 拒绝
• 信息缺失
• 部分批准

这样工作量就可控了。不是为每个边缘情况发明新答案，而是为每种请求类型定义一小组模式并应用它们。

按这个顺序工作。

首先，列出请求可能停止的每一点。考虑缺失文件、无效值、政策冲突、过期期限、重复提交和人工审核。如果请求可以等待、失败或返回给提交者，把它写下来。

接着，为每种情况决定会发生什么。对于每个异常，回答四个简单问题：

• 谁会收到通知
• 请求显示什么状态
• 用户下一步必须做什么
• 请求何时会再次推进

例如，想象一名员工提交了一笔 $600 的差旅报销，酒店发票缺失且一餐超出政策。如果你只设计理想路径，请求要么卡住，要么被作为一个整体拒绝。如果你先设计异常，系统可以为缺失的发票暂停该报销，给员工发送清晰的提示，同时把允许的部分标记为有条件批准。

这就是部分批准规则重要的地方。你需要决定已批准的金额是否可以先行推进，剩余部分是否继续保留，申请人是只能编辑被争议的部分还是必须重新提交整份申请。

如果你在 AppMaster 中构建流程，这是在完善界面前把这些分支映射到业务逻辑的时刻。当拒绝、退回修改和带条件批准被视为独立路径，而不是隐藏在一个模糊状态后面时，工作流更容易被信任。

最后，从头到尾测试一个真实场景。使用实际数字、一个真实的文件缺口和一项政策例外。如果阅读流程的人在一分钟内无法判断下一步，设计仍然太模糊。

先定规则再做界面

界面看起来很具体，所以团队常常从那里开始。他们在达成规则前就画出按钮、表单和仪表盘。这通常会带来后续问题，因为界面最终会隐藏那些没人真正做出的决定。

更好的顺序很简单：先定义状态、交接、截止时间和推进所需的凭证。然后围绕这些构建界面。

当规则集小而清晰时，异常路径设计会容易得多。如果请求可以被批准、拒绝、退回修改或部分批准，这些状态需要用简洁明了的名字表示唯一含义。避免像“已退回”“已重新打开”“需要变更”这类近义但行为不同的标签，除非它们确实行为不同。

以采购申请为例。经理打开申请发现报价缺失。如果团队没有决定接下来该怎么办，人们会即兴处理：有的经理会拒绝它，有的会保持待审，有的会发聊天消息却不在系统里做任何变动。很快没人信任状态了。

先写规则。当报价缺失时，请求转为“需要文件”。提交者承担下一步。该请求在五个工作日内保持该状态。如果未收到材料，状态变为“已过期”，需要重新提交。

这一条规则比一个原型更能塑造产品。现在你知道用户应看到什么、该发什么提醒、以及该保留什么历史记录。

一组实用规则应回答四个问题：

• 哪些是大家每天都会用到的少数状态名称？
• 在每个状态中谁是下一位行动者？
• 项目在该状态下能停留多久，然后会升级、过期或关闭？
• 在进入下一步前需要哪些字段、文件或检查？

部分批准也需要同样的关注。如果出差被批准但酒店费用未被批准，申请人是在同一条记录上编辑还是创建新记录？财务是只复核更改部分，还是要全部再审？如果不早做决定，屏幕可能看着整洁，但背后的流程依然混乱。

当团队先把规则敲定，界面会变得更简单。更重要的是，即使答案是“尚未批准”，用户也知道下一步该怎么做。

写出便于执行的消息

糟糕的异常消息会拖慢一切。人们不仅需要知道某事失败了，更需要知道发生了什么、这影响到哪部分，以及下一步该做什么。

这是设计对用户真正生效的地方。内部规则可能很清楚，但如果界面只显示“错误”或“待审”，人们会猜测、重复发送错误的文件或求助支持。

以供应商审批为例。用户提交了税务文件、银行信息和保险证明。银行信息没问题，税务文件过期，保险证明缺失。如果系统只显示“请求未通过”，用户就不知道下一步该做什么。

更好的信息如下："您的银行信息已通过。我们仍需要更新的税务文件和保险证明，才能最终批准。" 这一句把已完成的和未完成的清楚分开，节省时间。

好的消息通常回答四个小问题：

• 哪一部分被拒、缺失或仍在审核？
• 哪一部分已经被接受？
• 用户需要上传、修改或确认什么？
• 他们重新提交后会发生什么？

最后一点很重要。当下一步明确时，人们更有可能完成任务。"上传缺失文件并重新提交审核" 比 "需要操作" 好得多。

模糊的标签也会造成焦虑。"待审" 可能意味着在等人、缺失数据或内部检查。如果你知道原因，就直接说明。"等待经理批准" 和 "等待地址证明" 不是同一种情况，不应看起来一样。

如果流程允许部分批准，就在状态里清楚显示。简短的分项通常比一个标签更好：

• 已批准：身份证明
• 需要更新：税表
• 缺失：保险证明

现在用户只需修复重要部分，而不必重头开始。

重新提交的入口也应易于找到。把下一步操作放在消息附近，而不是另一个屏幕上。如果你在 AppMaster 中构建流程，最好让面向用户的状态文本与实际业务流程状态相匹配，这样应用会准确说明工作流在做什么。

好的消息能减少支持工单、加速批准并让流程显得公平。人们在理解原因时更愿意接受被拒。

导致返工的错误

大多数返工始于一个错误假设：正常路径才是主要设计对象。团队把“提交—审核—完成”画好就停下，然后真实情况出现：文件缺失、经理想要修改，或只有部分能通过。

这一差距会迅速产生额外工作。人们会发明手工修补办法、发送旁路消息并随意修改状态名。几周后没人再信任工作流，因为每个异常都像特殊案例一样处理。

一个常见错误是把理想路径当作产品，把其他情况当作清理工作。想象一个需要收据、部门批准和财务复核的报销请求。如果收据缺失，请求是暂停、退回员工还是被拒？如果这个规则一开始不清楚，团队通常会事后用邮件和评论来补丁。

混乱的状态名又会引发一轮返工。像“复审中 2”或“等待操作”这样的标签看似无害，但它们迫使人们猜下一步。清晰的名称能减少错误，因为它们展示问题、负责人、结果或下一步中的一项。

归属也是工作流破裂的高发点。请求不应停留在不属于任何人的状态中。如果案件在等待，必须有人负责推进、索要更多信息或关闭它。否则，沉默的延迟会积累，用户会以为系统丢失了他们的请求。

部分批准常被处理不当。团队倾向把它当成完整拒绝，因为那看起来更简单。但两者含义不同。如果出差申请中的机票和酒店被批准而餐补被否，那就需要自己的处理路径、专门的消息以及通常需要的后续操作。

当部分批准与拒绝混在一起处理时，人们会重新提交整份请求、重复上传文件并重新开启已经完成的审核。这就是纯粹的返工。

一个简单的测试能说明问题：读每个非理想路径的状态并问——"谁负责、用户看到了什么、接下来会发生什么？" 如果回答模糊，流程很可能在同一环节出问题。

构建前的快速检查

在构建界面或自动化之前，对混乱情况再做一次检查。好的异常路径设计通常只是一些在早期就做出的明确决定，防止混乱变成返工。

如果请求被拒、暂停或只部分批准，总应有人知道下一步是什么、谁来做以及还缺哪些信息。

对流程中的每个异常做以下快速检查：

• 每个异常都有负责人。
• 每个状态都引导到一个清晰的下一步。
• 缺失项用明白的语言列出。
• 部分批准有规则，而不是猜测。
• 时间点明确。

然后做一个简单测试。把流程交给一个没参与设计的人，给他们一份被拒的请求和一份缺一份文件的请求。如果他们在一分钟内不能说出该怎么做，流程仍然太模糊。

一个小例子能说明问题。想象经理批准了软件请求但拒绝了硬件部分。如果状态只显示“部分批准”，员工可能认为一切都能继续推进。更好的状态会明确说明已批准什么、被拒什么，以及员工是否可以只重新提交被拒部分。

如果你想把这些规则做成可用的内部应用，先把异常状态映射出来，再做理想路径。在 AppMaster 中，这可能意味着先定义状态、业务规则和必需字段，然后再考虑美化界面。这是构建能处理真实工作而不仅仅是理想版本的无代码应用的实用方法。

下一步很简单：列出你的五大异常，为每个异常指定负责人，并写出用户应该看到的消息。如果这三项清楚，构建通常会容易得多。