4.7 出错以后，我怎样让工作继续
试点第二周，财务系统短暂无法访问。
系统没有拿到最新付款记录，却继续生成交接材料，并显示“未发现逾期风险”。销售看到这句话，以为客户付款正常。
工程师很快修复了连接，但我更在意另一个问题：为什么资料拿不到时，系统选择了一个看起来正常的答案？
真正可靠的系统，不是永远不出错，而是出错以后不会把工作带向更危险的方向。
我先列出工作可能怎样失败
我们过去只画正常流程：读取资料、整理、确认、写回。
我和工程师重新从每一步追问：
- 来源系统不可用；
- 资料只有一部分；
- 两份资料互相冲突；
- AI 输出明显异常；
- 用户没有所需权限；
- 写入一半时失败；
- 已经确认的规则后来发生变化。
不同失败不能都显示“请稍后再试”。它们对经营的影响不同，需要不同处理。
第一种处理是停止并交给人
涉及价格、合同、客户承诺和财务事实时，只要证据不足，系统就停止相关动作。
停止以后不能只弹出错误。人工接管人要能看见：
- 这笔订单原来走到哪一步；
- 已经取得哪些资料；
- 哪一步失败；
- AI 曾经做出什么整理；
- 接下来需要人决定什么。
如果员工接管后还要重新搜集全部资料，所谓人工接管只是把问题甩回给人。
第二种处理是降级
有些失败不需要整条工作停下。
例如，外部行业资料暂时无法读取，系统仍可以整理公司已有的客户纪要，但必须注明信息不完整；无法生成综合建议时，可以只列出原始来源和缺失项。
降级结果要明确告诉用户少了什么、哪些结论不能使用。不能把缩水后的结果包装成完整结果。
我只允许在不会改变高风险事实的地方降级。
第三种处理是有限重试
短暂网络故障可以重试，但重试必须有限制。
我要求工程师写清重试几次、间隔多久、重复动作会不会造成两次写入。如果已经成功创建项目，第二次重试不能再创建一个。
超过限制后，系统进入明确的失败状态并通知负责人。无限重试会让问题隐藏在后台，也可能不断产生费用和重复动作。
第四种处理是回滚
如果错误内容已经写入系统，我们需要回到确认前状态。
回滚不是简单删除一条记录。团队要知道哪些对象受到影响，哪些通知已经发出，是否有人根据错误结果开始工作。
例如，错误交接单已经让项目团队安排资源，即使记录被撤回，也要通知项目负责人重新确认。涉及客户外部材料时，还可能需要由有权的人决定是否联系客户修正。
错误动作、撤回过程和受影响对象都要保留证据。
我为关键依赖写一张恢复表
| 失败情况 | 用户看到什么 | 工作怎样继续 | 谁负责 |
|---|---|---|---|
| 财务状态无法读取 | “付款状态无法确认”及最近更新时间 | 财务确认前不放行相关结论 | 财务负责人 |
| 客户资料部分缺失 | 已取得资料和缺失清单 | 销售补齐后继续 | 销售 |
| 两个系统主体冲突 | 冲突来源并列显示 | 停止合并，等待确认 | 客户资料负责人 |
| AI 输出异常 | 保留原始资料，不显示结论 | 人工完成本次判断 | 业务负责人 |
| 写回项目系统失败 | 显示未写入，不改变业务状态 | 限制重试后人工处理 | 运行负责人 |
这张表让恢复成为工作设计的一部分，而不是事故发生后临时决定。
我专门安排一次“故障演练”
上线前，我们主动让一个测试来源不可用，制造资料冲突，并撤销一个测试用户的权限。
业务人员要在没有工程师提示的情况下判断系统发生了什么，找到人工入口并继续工作。工程师则检查日志、提醒和回滚是否完整。
第一次演练时，系统确实停下了，但没有告诉销售该找谁。第二次，接管人收到了提醒，却看不到已经整理的上下文。
这些问题不会在正常演示里出现，只有真正演练才能发现。
恢复以后还要复盘
恢复运行不是结束。
我记录失败从什么时候开始、影响哪些订单、怎样被发现、人工接管花了多久、有没有错误结果流向客户，以及哪条验收情境需要加入长期测试。
如果一次故障只被写成“接口异常，现已修复”，组织没有获得任何新能力。
故障演练把恢复方案改了两次
| 演练 | 第一版失败在哪里 | 修订后的恢复 |
|---|---|---|
| 财务状态读不到 | 页面显示“未发现逾期” | 显示无法确认和最后时间；财务确认前不使用付款结论 |
| 客户主体冲突 | 系统选择最相似名称 | 停止合并，并列来源，交数据与法务确认 |
| AI 输出异常 | 只显示“生成失败” | 保留原始资料和已完成步骤，业务人员从失败处接管 |
| 项目写回失败 | 用户看见成功提示，后台准备重试 | 业务状态保持未写入；有限重试且不能重复创建 |
| 权限被撤销 | 接管人收到提醒却看不到上下文 | 在其获准范围内提供订单、来源、失败步骤和待决定事项 |
执行包最终规定：价值流负责人可以暂停新流程；员工使用经过批准的最小交接表继续；工程保留故障前状态和受影响订单；数据负责人核对错误写入；恢复后由业务责任人决定补录什么。系统不得根据聊天记录推测批准，也不能为了“自动修复”改变业务事实。
完整停止条件和恢复动作见 执行包第 10 节。有了可操作的降级和恢复，经营层才可能逐步授予权限；下一节会说明为什么二十笔历史订单通过，仍然不能直接创建项目或发送报价：我怎样逐步扩大 AI 的自主范围。