小团队的 Make 错误处理清单

错误处理不是给每个模块都加一条复杂路线，而是提前决定：场景没有完整成功时，业务应该看到什么状态、由谁接手，以及怎样恢复才不会制造新的问题。

如果流程只生成低风险草稿，而且每次结果都有人检查，简单提醒加人工重跑可能已经足够。如果失败会造成重复联系、遗漏重要记录或让两个系统状态不一致，就需要更明确的错误处理和复核路径。

先定义“完整成功”

在设计错误路线之前，先写清楚一次运行怎样才算完成。例如，“客户记录已经创建，负责人已经分配，并且结果已经写入复核日志”。只写“场景运行成功”不够，因为其中某个模块成功、后续模块失败时，业务状态可能仍然不完整。

对每个关键动作标注三件事：

动作是否对客户可见，或难以撤销。
动作能否安全重复执行。
动作完成后，在哪个系统记录真实状态。

快速检查清单

输入缺失、格式错误或重复时，有明确处理规则。
外部服务拒绝请求或暂时不可用时，失败不会被静默忽略。
高风险动作之前有稳定键或状态检查。
某些模块成功、后续模块失败时，能够识别部分成功。
只有可安全重复的动作才进入自动重试。
失败提醒包含记录标识、失败位置和可执行的下一步。
已指定负责复核、重跑或停止流程的人。
使用真实样本测试过正常、缺失、重复和失败输入。

检查一：输入可能怎样出错？

常见输入问题包括必填字段缺失、日期或编号格式不符、重复事件、空值以及上游字段含义发生变化。应在第一个不可逆动作之前校验关键字段；不符合规则的数据进入复核队列，而不是勉强映射到后续模块。

错误提醒应保留足够的上下文，让负责人能定位原始记录，但不要把不必要的敏感字段发送到公开频道或不受控的日志中。

检查二：重复动作会造成多大影响？

重复内部草稿和重复客户消息的风险完全不同。只要重复动作会影响客户、款项、业务记录或公开内容，就应先设计幂等规则。

通用做法是使用稳定业务键，在执行关键动作前查询处理状态，并在动作真正成功后写入完成标记。若关键动作成功但完成标记写入失败，不要直接重跑整个流程；先进入人工复核，确认外部系统里的真实结果。

检查三：是否存在部分成功？

场景可能已经在一个系统创建记录，却在更新另一个系统或发送通知时失败。此时简单重跑可能再次创建第一条记录。

为每个关键步骤记录清楚的状态，例如“已接收”“已创建”“待通知”“需复核”。恢复时从已确认的业务状态出发，而不是仅凭某次运行显示失败就从头执行。无法确定外部动作是否完成时，应先查询目标系统或交给人工确认。

检查四：错误是暂时的还是结构性的？

暂时性错误可能来自短时连接问题、服务限流或超时。只有在动作可安全重复、重试次数有边界并且每次尝试都有记录时，自动重试才合适。

结构性错误通常来自错误映射、无效权限、缺少必填字段或业务规则不明确。反复重试不会修复这些问题，反而可能增加噪声。应停止相关路径、通知负责人并修正根因，再决定是否恢复处理。

检查五：采用哪种恢复方式？

可以从最小可操作方案开始：

停止并提醒：适合需要先修正配置或输入的问题。
写入复核队列：适合规则需要人工判断，或外部结果无法自动确认的情况。
有限重试：适合暂时性且可安全重复的动作。
跳过并记录：只适合该条失败不会破坏整体数据，而且负责人能够之后补处理的情况。
补偿或回退：仅在撤销动作的含义清楚、经过测试且不会删除正确数据时采用。

Make 提供错误处理路线和未完成执行等机制，但选择哪一种仍取决于业务影响、数据状态和团队的复核能力。不要把工具默认行为当作业务恢复规则。

检查六：AI 输出是否需要人工复核？

AI 生成、分类或抽取的结果可能不稳定。若结果会直接发给客户，或影响资金、法律、医疗、财务和品牌敏感决策，应在最终动作前保留人工确认。场景可以负责收集输入、生成草稿和整理候选项，但复核人需要看到来源、关键字段和修改入口。

一个简单原则是：错误结果如果昂贵、尴尬或难以撤销，就不要让不确定输出直接触发不可逆动作。

检查七：谁负责失败路径？

为每个重要场景指定负责人，并在提醒中提供：

场景名称和运行或记录标识。
失败模块及简明错误说明。
已经完成的业务动作。
原始记录或复核队列的位置。
建议的下一步，以及是否允许重跑。

如果没人负责查看提醒，再完整的错误路线也无法形成可运营的流程。规则尚未稳定时，先保留人工处理，比自动化一个无人接手的恢复路径更可靠。

三个常见场景

线索入库后通知失败

场景已经保存线索，但发送内部通知时失败。不要重复创建线索。保留已创建记录的标识，把通知状态标记为待处理，并向负责人提供该记录的入口。

同一事件重复到达

上游重复发送状态变更事件，而后续动作是联系客户。场景在发送前检查稳定键和成功状态；已经处理的事件直接记录为重复，不再次执行客户可见动作。

每周异常报告未生成

报告只供内部复核，且数据可以重新查询。这里不一定需要复杂的自动恢复。明确的失败提醒、可安全执行的人工重跑步骤和负责人，可能就是足够的第一版方案。

上线前演练

用正确样本确认完整成功路径及最终状态。
删除一个必填字段，确认场景在高风险动作前停止。
重复发送同一事件，确认不会重复执行关键动作。
模拟中间步骤失败，核对已完成动作是否被准确记录。
检查提醒能否让负责人独立定位并处理问题。
仅对确认可安全重复的路径测试恢复或重跑。

参考资料

发布前写下三句话：“在 X 失败时，业务风险是 Y；负责人是 Z；允许的恢复动作是停止、复核、有限重试或跳过。”如果团队无法明确回答，就先保持人工处理，并把状态与责任人定义清楚。