构建应用时处理真实世界的异常

为什么干净的应用流程在现实中会失败

一个干净的流程图之所以看起来漂亮，是因为它假设人们会按正确的顺序、带着正确的数据、在正确的时间执行操作。但真实工作很少如此。有人迟交表单、经理因病请假、客户漏填了关键信息，或者一个付款需要最开始没人提到的特殊审批。

这就是为什么应用的第一个版本在演示时看起来完成了，但一旦真实用户使用就开始出问题的原因。顺利路径有效，但日常工作不会长时间停留在顺利路径上。

最安全的起点是认为那个整洁的版本不完整。一个小细节出错，简单的请求就会迅速变化。一个缺失字段、一个不寻常的客户或一项延迟的审批都可能阻塞整个流程，让人不知道下一步该怎么办。

常见的失败通常很简单：

• 请求前进了一步，然后因为审批人不可用而卡住。
• 记录无法保存，因为某个必填信息还未知。
• 一个特殊情况被当作普通情况处理，之后必须手动修复。

这不仅仅是小麻烦。一个奇怪的案例可以阻塞后面的所有工作。员工开始在聊天、电子表格或电子邮件里使用变通方法，应用不再是唯一的工作场所。

一个更好的目标很简单：在编写规则之前先收集异常。问一问当数据缺失、时间不对或请求不符合标准路径时会发生什么。这些混乱的例子不是旁枝末节，而是决定你的应用在现实中是否可用的关键。

优先发现哪些异常

首先要捕捉的不是罕见的边缘情况，而是那些每周都会发生、悄悄破坏干净工作流的混乱事件。要想做出更稳健的第一个版本，请关注那些使工作被延迟、阻塞或交由某人处理而不是系统做决定的环节。

迟到的审批通常是首要问题之一。经理在截止后批准请求、在工资结算后批准，或在库存已被重新订购后才批准。应用需要为那一刻设定规则。它应该重新打开请求、创建新请求、通知财务，还是把它转到复核，而不是假装审批按时到达？

缺失数据是另一个常见阻塞点。表单可能在没有税号、收据、交货日期或客户联系方式的情况下提交。如果下一步依赖该字段，流程不应以模糊错误失败，而应暂停、显示缺失项并让修复变得容易。

特殊情况重要，因为它们暴露了正常路径的局限。也许大多数退款很简单，但超过某个金额的退款需要额外凭证；也许某个部门遵循不同的审批规则。这些情况不需要整个新应用，但需要清晰的分支处理。

一个有用的初步检查是寻找四类模式：在原路线之外到达的迟到审批、阻塞下一步的缺失细节、需要不同规则的不寻常请求，以及系统应该停下来并询问人工的时刻。

人工审核不是失败。遇到冲突数据、政策例外或高成本操作时，人工往往是最安全的选择。一个被暂停的复核队列通常比一个悄无声息的错误要好。

如果你及早发现这些异常，第一个版本会显得更贴近真实、也更不脆弱。

在哪里收集真实案例

最容易错过糟糕异常的方式是只询问设计流程的经理。真实的问题通常掌握在每天做这项工作的人手里。他们知道哪些步骤会被跳过、哪些字段常为空，以及哪些审批会迟到、乱序或在系统之外发生。

从简短的对话开始。请人们讲述一个正常案例，然后问上一次出现混乱时发生了什么。不要询问对流程的总体看法，而要要真实的故事：发生了什么、缺了什么、谁修复了、他们手动做了什么。

旧的工作记录也是好来源。过去的邮件、支持工单、聊天记录和交接笔记常常显示干净流程崩溃的确切时刻。这些记录有价值，因为它们捕捉到人们在问题发生时使用的语言，而不是流程文档里的修饰版本。

还要检查人们在旁边使用的工具。如果有人保留电子表格、便签或私人文档来跟踪异常，那就是强烈信号。变通方法存在是有原因的，它们常常揭示应用需要从第一天就具备的规则。

通常首先审查的最佳来源是：影子系统（如电子表格和个人清单）、在邮件线程中询问缺失细节或手动审批的对话、关于紧急修复的聊天记录、提到延误或被拒记录的支持工单，以及最近几个出错案例的完整时间线。

最后一类来源比看起来更重要。近期失败的案例通常比古老的总结更有用，因为它们显示了确切的事件链。你可能会发现模式，例如审批在截止后到达、客户从未发送必需文件、或有人使用没人记录的特殊规则。

如果你在用基于聊天的构建器草拟第一个版本，请在生成逻辑前收集这些例子。早期能见到混乱案例，构建更安全的流程会容易得多。

如何把混乱故事变成应用逻辑

从一个真实案例开始，而不是理论。像同事间口述那样写出来：他们想做什么、出了什么问题、谁出手相助、最后如何收场。

像“请求因为经理休假而卡住，后来财务在一个字段缺失的情况下批准”这样的混乱故事，比整齐的流程图更有用。它显示了应用常见破裂的节点。

从故事到规则

对于每个案例，提取四个事实：发生了什么、谁做了决定、他们为什么这样做，以及应用下一步应该怎么处理。

这样可以把注意力聚焦在行为上，而不仅仅是界面。目标不是第一天覆盖所有奇怪情况，而是识别可重复出现的模式。

当你收集到几个故事后，把相似的归为一类。简单的桶通常会自然而然出现：迟到审批、缺失信息、找错人处理、重复请求或超过限额需要特殊审批。

然后把每个桶转换为最轻量的可行规则。这个规则并不总是需要完全自动化。有时最好的规则是警告、暂停或人工复核步骤。

例如，如果审批迟到是因为审批人在外，应用可以在24小时后发送提醒、48小时后重新分配，或请备用审批人复核。如果某个重要字段缺失，最好的做法可能是允许保存为草稿而不是硬性阻止。这样既不阻塞流程，也不会掩盖问题。

如果你在诸如 Koder.ai 的基于聊天工具里构建，通俗的案例非常有帮助。它们给系统具体内容，使第一个工作流基于真实决策而不是干净但不现实的猜测。

用真实案例测试

在锁定逻辑之前，用两到三个真实故事跑一遍。问几个基本问题：流程能否得出与真实案例相同的结果？当信息缺失时是否安全失败？它是否知道何时暂停并请求人工？

如果答案是否定的，不要立刻增加复杂性。先用更简单的语言重写规则。清晰的规则通常比没人能解释的巧妙规则更能带来更好的工作流。

一个简单例子：费用审批

先看干净版本。员工报销一笔 $42 的出租车费，填写了日期、金额、项目名和收据。经理在工资结算截止前批准，财务把它计入下一次报销。

这条路径很容易建模，但它不是全部工作。

现在加入第一个异常。员工按时提交请求，但经理在工资截止后一天才批准。应用不应悄悄把它当作按时批准，也不应直接拒绝该报销。

更好的处理是把请求移到一个清晰的状态，例如“截止后批准”。从那里，应用可以把付款保留到下一个工资期，通知员工新的发放日期，并且只有在公司政策允许人工补发时才把案件路由到财务。

这意味着应用需要存储不止一个日期。它应该记录报销何时提交、何时批准，以及错过了哪个结算期。

再加入第二个异常。员工忘记附收据，经理仅凭说明批准。两天后收据到达。

如果应用设计得好，案件不会消失或从头重来。它会进入“等待收据”的挂起状态、发送提醒并保持打开。当收据后来上传时，应用重新打开案件并只把它发送到还需操作的步骤。

这样的流程可能经过几个简单状态：已提交、等待经理审批、截止后批准、等待收据、以及为财务复核而重新打开。

这就是实践中真实异常处理的样子。应用不仅仅决定同意或拒绝，而是在保持上下文、日期和责任的情况下决定是否挂起、路由或重新打开案件。

如何在不破坏流程的前提下处理缺失数据

缺失信息是常态，不是罕见的边缘情况。如果你的应用假设每个表单第一次就会填写完整，真实用户遇到空缺时流程就会停滞。更好的规则很简单：只强制要求下一步真正需要的信息。

逐步规划。问问现在应用必须知道什么、什么可以等到以后再补。报销申请在提交前可能只需要金额和员工姓名，但最终的收据或许只需在付款前提供。这样既保持流程推进，又不会降低控制力。

让不完整的工作可见

用户应能在某些细节缺失时保存进度。可再次打开的草稿远胜于迫使人们从头开始的表单。当缺失信息依赖他人（如经理、供应商或财务）时，这一点尤为重要。

清晰的状态帮助每个人了解发生了什么。保持简短易扫读的状态标签：等待信息、因缺失文件被阻塞、需要复核、准备审批、退回更新。

这些标签同时完成两项工作：显示当前状态，并告诉用户需要关注哪类问题。

每个缺失项也需要一个负责人。如果缺少税号，谁来补？如果收据不清楚，谁来替换？如果缺少审批备注，谁能提供？当没人负责修复时，记录就会停滞不前。

举个简单例子。想象员工提交了差旅报销但酒店尚未寄来发票。应用仍应允许他们保存并以“等待收据”状态提交。财务可以先复核其余部分，员工知道缺少什么，请求也不会消失在无声的错误里。

何时自动化，何时交给人工

当相同输入几乎每次都会导致相同结果时，自动化效果最好。如果请求遵循明确模式，就给它规则；如果答案取决于缺失的上下文、不寻常的时机或判断力，就交给人处理。

这个分界很重要。好应用应在正常情况下快速推进，在不明确时放慢脚步。错误的自动决策可能比一次简短的人工复核产生更多工作。

一个简单测试：两名不同团队成员在收到相同数据时会做出相同选择吗？如果会，就自动化；如果不会，就让人工介入。

合适自动化的候选是：填写完整且包含所有必需字段的表单、符合政策限额的请求、具有明确截止的重复操作以及始终遵循相同路径的审批。

有些情形绝不应被猜测：关键细节缺失、请求打破常规、两条规则冲突、成本或风险高、或有人需要解释例外。

想象一个没有目的地、日期紧急且费用高于常规上限的出差请求。应用不应尝试变聪明，而应标记案件、暂停流程并把它路由给合适的人。

同样重要的是，保持每个异常触发原因可见。显示应用为何停止、触发了哪条规则以及缺少哪些信息。这加快复核并帮助团队后续改进工作流。

常见错误要避免

许多应用项目在写逻辑之前就出问题了。团队画出干净路径，假设人们会遵循它，忽视每周都会发生的奇怪情况。这就是简单工作流变成支持工单、手动修复和用户困惑的原因。

第一个错误是只凭假设设计。如果你猜测审批、缺失字段或异常通常如何处理，就会漏掉最重要的情况。经理迟到批复、客户记录半成品到达、或一笔付款因金额异常需要额外复核，这些都可能被忽视。

另一个错误是把许多不同情况隐藏在一个模糊规则里。像“如果看起来有问题就发给管理员”这样的规则听起来灵活，但会带来新问题。谁是管理员？什么算“有问题”？如果两天没人响应怎么办？

强制完整重做也会伤害用户。如果只缺一份文件或审批人拒绝，用户不应被迫重新输入所有内容。更好的流程会保存进度、清晰标注问题，并只让用户修复被阻塞的部分。

还有些问题容易被当作次要而忽略：时序、责任和历史记录。但它们并非次要。如果审批在截止后到达，应用需要知道是接受、升级还是重新打开请求；如果案件被阻塞，必须有人承担下一步；如果状态改变，人们需要看到是谁在什么时候为什么改的。

审计历史很重要：人们需要知道谁改了哪个值、谁批准了例外以及状态何时移动。

在生成逻辑前的快速检查

在把工作流变成规则前，暂停一下，核对你的输入是否与真实工作相符。干净的图表常常遗漏那些会导致延误、混淆或需要手动修复的奇怪情况。

一个快速复查可以包括：

• 从真实例子开始，而非猜测。
• 用一句短句命名每个异常。
• 决定谁负责被阻塞的案件。
• 检查用户如何从缺失信息中恢复。
• 从头到尾测试一个现实场景。

一个简单的测试用例就能暴露薄弱逻辑。想象一个在没有供应商名称的情况下提交的采购请求，然后由部门负责人迟批。请求人能否修复缺失字段？应用是否知道该重新打开请求、继续处理，还是请财务审查？

这就是在生成逻辑前你需要的细节级别。简短、真实的故事会带来更安全的第一个版本，减少用户使用后出现的惊喜。

为更安全的第一个版本做的下一步

从小处开始。选一个工作流，而不是整个业务。然后从每天做这项工作的人那里收集五个真实异常案例，例如迟到审批、缺失收据、经理休假、重复请求或需要财务介入的案件。

围绕那个窄的流程和那五个案例构建第一个版本。保持规则易读。如果请求不完整，展示缺失项；如果审批迟到，决定何时提醒、何时升级、何时暂停；如果案件不符合常规路径，明确谁需要复核。

然后和相关人员一起测试：提交请求的人、第一审批人、负责修复异常的人、收到升级通知的经理以及看到结果的任何人。

观察他们在哪些地方停下、猜测或寻求帮助。这些时刻比顺利的环节更重要。如果三个人在同一步卡住，说明规则或界面需要改动。

一个报销应用可能在多数情况下运行良好，直到有人提交一张没有项目代码的出租车收据或在月度截止后提交。你的第一个版本不需要解决所有罕见案例，但需要捕捉常见异常、说明下一步，并保留清晰的人工复核路径。

然后以小步调整规则。移除造成混淆的步骤；只有在能防止重复问题时才增加字段；如果提醒太早或太晚再调整审批时机。在真实测试后的小幅修改通常比过早加入复杂特殊逻辑更有效。

如果你想快速原型，基于聊天的构建器如 Koder.ai 可以帮助把这些真实例子逐步转换为可运行的应用。但关键不变：先从混乱的故事开始，再围绕它们构建规则。