人工接管不是兜底，它本来就是工作流的一部分

很多人设计 AI 工作流时，默认目标是“尽量自动化”。这没有错，但如果把自动化当成唯一目标，最后通常会把流程做脆。

因为企业流程不是单线程脚本，它本来就包含判断、例外、升级和协作。对这样的系统来说，人工接管不是失败，而是设计的一部分。

先写清楚接管触发条件

“模型觉得不确定时交给人”通常不够可执行。真正进入流程前，我会把接管触发条件分成五类，并为每一类指定接管人和回退动作：

• 信息不完整：关键字段、附件或来源缺失，系统不能继续推断。
• 规则冲突：客户约定、价格规则、权限规则之间出现矛盾。
• 风险越界：涉及付款、合同、敏感客户、不可逆写回或外部承诺。
• 置信不足：输出不满足已经定义的质量阈值，或无法给出依据。
• 业务例外：现有 SOP 没覆盖，但现场必须继续处理的新情况。

接管规则至少要回答四个问题：谁收到、收到什么、多久内处理、处理后回到哪个节点。只有“转人工”而没有这些字段，实际上只是把异常丢进另一个黑箱。

下面这张表是我在匿名流程梳理中使用的检查方式。它不是通用行业标准，但适合在试点前把五类触发器逐项问清楚。

触发类型	可观察信号	系统先做什么	人工需要决定什么
信息不完整	必填字段为空、附件不可读、来源无法定位	停止后续计算，列出缺失项	补充信息，或确认是否允许继续
规则冲突	两条仍在有效期内的规则给出不同动作	同时展示规则来源与版本	指定本次采用哪条，并确认是否废止旧规则
风险越界	即将产生外部承诺、资金动作或不可逆写回	保留草稿，不执行外部动作	审批、驳回或调整动作
置信不足	证据不足、字段有多种合理解释、质量校验未通过	标记不确定字段和候选解释	选择正确解释或要求重新取数
业务例外	输入合法，但现有 SOP 没有覆盖	保存现场上下文，创建例外记录	给出一次性处理决定，并判断是否补充 SOP

1. 不是所有节点都该自动完成

有些节点很适合自动化，比如分类、搬运、提醒、初步检索；但有些节点天然就需要人保留判断，比如规则冲突、边界案例、客户关系、风险决策。

真正稳的系统，不是把所有节点都自动化，而是知道哪些地方该停下来，把上下文整理好后交给人。

2. 接管设计不好，前面的自动化也会失效

很多流程的问题不是 AI 输出不好，而是接给人的那一步太差：

• 人不知道为什么被叫进来
• 看不到前面系统做了什么
• 接手之后得从头判断
• 处理完也回不到原流程里

这种接管方式会让团队越来越讨厌系统。久而久之，大家会觉得“还不如一开始就自己做”。

所以我现在更重视接管节点里要交付什么信息：

• 当前流程在哪一步
• AI 已经做了哪些判断
• 哪些材料被引用过
• 这次为什么需要人工介入
• 人工处理后下一步会发生什么

我现在使用的最小交接清单包括下面八个字段。字段名可以随业务系统调整，但不能只留下“请人工确认”这一句话。

最小字段	要解决的问题	示例写法
任务编号	这次处理如何被唯一定位	TASK-示意编号
当前节点	流程停在什么位置	规则匹配完成，等待确认
输入材料	人需要复核哪些原始内容	表单字段 + 脱敏附件摘要
系统判断	AI 已经做了什么，不必让人重跑	已识别 6 个字段，2 个待确认
引用依据	判断使用了哪条规则	SOP-示意-v3，第 2 节
触发原因	为什么不能继续自动处理	同时命中两条有效规则
建议动作	系统认为有哪些可选下一步	采用新规则 / 退回补充信息
回写位置	人工决定后如何回到流程	确认结果写回任务记录并恢复节点 4

接管人不需要重跑前面的步骤；系统也不应该让他重新寻找依据。最小交接包的目标，是让处理人只完成那一个必须由人完成的判断。

一个脱敏的失败样本：系统有结果，接管人却无法行动

下面是根据常见现场问题重构的示意案例，不是某家公司、客户或真实交易的逐字记录。

某次流程把一项异常标记为“需要人工确认”，随后只向处理人发送了一句提醒。处理人看不到原始输入、系统引用的规则，也不知道确认后应该回到哪个节点。为了避免作出错误承诺，他只能重新打开多个文档，从头复核整项任务。

这次失败并不是模型没有发现异常，反而是模型正确地停了下来。真正的问题出在交接：

1. 异常信号被识别了，但触发原因没有结构化传递。
2. 系统给了结论，却没有附上规则来源和版本。
3. 处理人完成决定后，没有明确的回写入口。
4. 这次人工判断没有形成例外记录，下次仍会重复发生。

修正时，我不会先改模型，而是先补齐交接字段、指定接管角色，并让人工选择“继续、退回、升级”中的一个明确动作。每个动作都绑定下一节点和回写位置。这样才能判断问题究竟来自输入、规则还是流程设计。

3. 人工接管其实在建立组织信任

一套流程能不能被团队长期使用，技术只是其中一半。另一半是组织是否信任它。

如果系统在该交人的时候不交人，团队会失去安全感；如果系统动不动就把问题扔给人，团队又会觉得它没有价值。好的人工接管，实际上是在建立一种清晰的合作关系：系统负责哪些事，人负责哪些事，边界在哪里。

这也是为什么我越来越少用“human in the loop”这种抽象说法，而更愿意直接谈协作节点设计。因为对业务团队来说，他们感受到的不是一个术语，而是工作到底有没有变顺。

4. 接管之后要能回到流程里

我很在意的一件事是，人工处理完之后，系统有没有“学到东西”。

这里的学习不一定是模型层面的学习，很多时候更现实的是：

• 新规则有没有被补进 SOP
• 例外情况有没有被记录
• 提示词或分流逻辑有没有更新
• 下一次遇到类似问题时，是否更少依赖人工

如果接管只是临时救火，系统就永远停留在原地。只有把接管结果重新纳入知识和流程，AI 工作流才会越跑越稳。

所以我现在更愿意把人工接管看成工作流的一部分，而不是兜底方案。真正成熟的系统，不是“从不需要人”，而是“知道什么时候该交给人，并且让这次交接产生长期价值”。

如果你正在选第一条流程，可以先用AI 试点优先级评分表检查风险和 owner，再进入具体的接管设计。