让流程会停下：AI 自动化的交班设计
很多人对 AI 自动化的第一印象，是"收到一封邮件，让模型替我回一封"。这当然有用，但它仍然是一种聊天式使用：人发现事情、复制内容、发起提问、决定下一步。
真正值得自动化的，往往不是某一句回复，而是这段反复发生的交接：收到信息、判断归属、补全背景、创建任务、通知负责人、等待处理、记录结果。
AI 工作流自动化的目标不是"把人拿掉"，而是让流程在合适的时机自己运行，并在不确定或高风险的地方主动停下、交班、留下记录。
先分清：聊天、单点自动化与工作流
| 方式 | 谁发起 | 能解决什么 | 常见局限 |
|---|---|---|---|
| 聊天式 AI | 人每次手动发起 | 写邮件、总结材料、给出建议 | 上下文靠人搬运，结果仍要人分发和跟进 |
| 单点自动化 | 事件或定时器触发 | 自动把表单写入表格、把附件存到网盘 | 主要按固定规则处理，遇到自然语言和模糊判断容易卡住 |
| 端到端 AI 工作流 | 事件或定时器触发，模型与工具协同 | 理解内容、补全上下文、路由、执行、审批、记录 | 需要清楚定义权限、异常路径和人工接管方式 |
一个完整工作流可以由事件触发或按固定时间运行，并跨工具读取信息、更新工单、编辑文档或发送通知。关键不在于它是否"像人一样聊天"，而在于它能否在明确边界内持续推进工作。关于将模型与工具、业务数据及人工监督结合的思路，可参考 OpenAI 对工作区智能体的介绍。(openai.com)
主案例：每天进来的客户反馈，怎样不再靠人工搬运
设想一个产品团队每天都会收到客户反馈：有的是功能疑问，有的是故障报告，有的是续费风险，也有的是销售线索。原来的处理方式通常是：运营同学浏览收件箱或表单，把内容复制到表格；判断该交给客服、产品还是研发；再到另一个系统创建任务；最后在群里提醒负责人。
问题不只是慢，而是每次都在切换系统、重复判断和等待交接。
下面是一条可从小范围试运行的流程：
- 触发：新反馈进入表单、共享邮箱或工单系统。
- 清洗与去重：读取反馈编号、客户标识、正文、附件链接和提交时间；若相同事件已经处理，则停止后续写入。
- 补全上下文：从 CRM、历史工单、产品版本记录或知识库中读取必要背景，例如客户等级、近期问题、已知故障和当前负责人。
- 模型判断：模型处理需要理解自然语言的部分，例如提取问题摘要、识别意图、判断紧急度、给出建议归属，并说明判断依据。
- 结构校验 ：要求模型返回固定字段，而不是一段散文。例如：
category、priority、owner_team、confidence、missing_fields、suggested_next_step。下游系统应校验字段是否完整、分类是否在允许范围内。这里的confidence只能作为辅助信号，不能单独等同于结果可靠性。 - 规则与工具执行：由规则、脚本或 API 完成确定动作：创建或更新工单、添加标签、写入负责人、设置 SLA、发送内部提醒。
- 审批或升级：低风险的内部标签可以自动写入；模型输出不完整、规则检测到不确定因素、内容敏感或涉及对外承诺的事项进入人工队列；金额、权限、合同、法律与合规相关动作必须先批准。
- 结果留痕：记录本次运行的输入版本、模型输出、调用过的工具、执行结果、失败原因、人工改动和最终状态。
这不是"AI 自动回复客户"的故事，而是把理解、路由、执行和交班连成一个可管理的闭环。
一条重要分工：模型负责判断，系统负责落地
AI 工作流常见的失控方式，是让模型既负责理解，又直接拥有所有执行权。更稳妥的分工是：
| 更适合模型的环节 | 更适合规则、脚本或 API 的环节 |
|---|---|
| 分类、提取、摘要、翻译、草拟 | 金额计算、字段格式校验、权限控制 |
| 从自然语言中识别意图和风险线索 | 创建记录、更新状态、发送已批准消息 |
| 依据上下文给出路由建议 | 去重、幂等处理、SLA 计时、重试策略 |
| 判断信息是否缺失，并提出补充问题 | 访问控制、审计日志、不可逆操作 |
模型的输出应该是"建议和结构化决定"，而不是绕过业务规则的最终命令。工具权限也要按只读或写入、是否可逆、需要什么账户权限、是否有财务影响进行分级；高风险工具应触发暂停或人工升级。(openai.com)
不要把人工审批当作失败补丁
人工在环不是因为模型"不够聪明"，而是因为不同动作承担的风险不同。可以用红黄绿三档设计交班点：
- 绿灯：自动执行。 内部标签、摘要写入、草稿生成、可撤销的任务创建。
- 黄灯：进入待审队列。 输出不完整、模型自报置信度偏低、关键字段缺失、检测到敏感关键词，或知识库没有可靠匹配结果。
- 红灯：必须人工批准。 对外发送承诺、退款或付款、修改权限、合同与法律事项、删除数据等高影响或不可逆操作。
这意味着"自动化完成"并不总是流程终点。对于黄灯和红灯任务，流程的正确行为是暂停、附上上下文和建议、通知正确的人，并等待明确的批准、驳回或补充信息。NIST 的 AI 风险管理框架提出，应关注系统边界、人的监督、预期收益和风险，而不是只记录模型是否成功输出。(airc.nist.gov)
异常不是脚注，而是主流程的一段
如果一条流程只能在理想输入下运行，它只是演示，不是生产流程。下面这些情况应在上线前写清楚：
| 异常 | 流程应怎样做 |
|---|---|
| 缺少客户编号、产品版本等关键字段 | 不猜测；标记为"待补信息"，通知提交人或转人工 |
| 模型没有按约定字段返回 | 拒绝写入；有限次数重试后进入人工队列，并保存原始输出 |
| 知识库没有匹配内容 | 不伪造答案；仅创建待处理工单并标记"无依据建议" |
| 下游 API 超时或限流 | 按退避策略重试；超过阈值告警；避免把失败误记为已完成 |
| 同一事件被重复投递 | 使用稳定事件 ID 或幂等键；已写入成功则返回已有结果，不重复建单或通知 |
| 人工驳回模型建议 | 回写驳回原因，保留为后续评估样本，而非悄悄覆盖 |
| 审批超时 | 提醒审批人；达到时限后升级给备用负责人或回到待处理队列 |
尤其要重视重复执行。不少事件驱动系统采用"至少一次"投递或重试机制，网络中断也可能让某一步再次运行。对外部写入操作使用幂等键或支持幂等的更新方式，能避免重复创建任务、重复发消息或重复扣费。(docs.aws.amazon.com)
第一个自动化对象，怎么选才不容易翻车
不要一开始就让 AI 判断复杂授权、替你谈客户，或者自动发送所有对外信息。先用下面五个问题筛选：
- 频率高吗？ 每天、每周都会重复，节省才会积累。
- 步骤稳定吗？ 大多数任务是否遵循相近的处理顺序？
- 输入输出较结构化吗？ 是否至少有可识别的标题、正文、编号、负责人、状态等字段？
- 错误可逆吗？ 分错标签可以改，误发报价或改错权限则代价高得多。
- 收益可量化吗？ 能否比较处理时长、人工接管率、错误率或单次成本？
一个很实用的起点是：让 AI 先做"准备工作"，人做"最终承诺"。 例如先自动提取会议任务并同步到待审列表，而不是直接替负责人承诺交付日期；先自动给工单分类和补充背景，而不是直接替客服向客户下结论。
可复用的 AI 工作流设计清单
在连接任何模型和自动化平台之前，先填完这份清单：
- 目标与基线：当前每周处理量、平均处理时长、人工步骤数、现有错误率分别是多少？
- 验收指标：希望改善处理时效、人工接管率、误分类率、重复执行率还是单次处理成本？
- 触发条件：由新事件、字段变化、定时任务还是人工按钮启动？
- 输入字段：哪些字段必填？哪些数据需要脱敏？附件和历史记录是否允许读取？
- 上下文来源：模型需要查询哪些知识库、业务系统或历史记录？哪些来源只能只读？
- 模型任务：模型究竟做分类、提取、摘要、草拟还是路由建议？不要用"帮我处理"代替任务定义。
- 输出结构：字段、允许值、置信度、理由和缺失信息是否有固定格式？置信度的触发阈值是否经过样本验证？
- 工具权限：每个工具是只读、可逆写入还是高风险写入？谁授予权限？
- 审批点：哪些条件进入黄灯待审，哪些动作必须红灯批准？
- 失败兜底：格式错误、无知识匹配、API 失败、重复事件和审批超时分别怎么处理？
- 幂等与状态：用什么键识别同一事件？如何避免重跑时重复执行？
- 日志字段：是否记录运行 ID、输入摘要、版本、工具调用、耗时、错误、人工接管和最终结果？
- 成本上限：单次任务允许消耗多少时间、模型调用和外部 API 次数？
- 试运行范围：先选哪一类低风险任务、跑多少样本、由谁复核？
日志不是为了证明"AI 很忙"，而是为了定位瓶颈并判断是否值得扩展。自动化平台的运行历史通常可以提供成功率、失败率、动作耗时与错误明细；这些数据应和人工修改记录一起进入复盘。(learn.microsoft.com)
最后：衡量的不是聪明，而是可交付
一条 AI 工作流是否有价值，不看演示时回答得多漂亮，而看它是否稳定地减少了无意义的搬运与等待。
建议至少持续跟踪六个指标：
- 节省工时：与上线前基线相比，人工实际少花了多少分钟；
- 处理时效：从事件进入到首次分流、首次响应或最终关闭的时长；
- 人工接管率：多少任务需要人接手，这不一定越低越好；
- 误分类率：模型路由与人工最终归属不一致的比例；
- 重复执行率：重复建单、重复通知、重复写入的发生比例；
- 单次处理成本：模型、自动化平台、外部 API 与人工复核成本的合计。
最好的第一条流程通常不"全自动"，但它会自动开始、知道边界、遇到问题会停下，并把足够的信息交给下一个人。先把这一条跑稳，再扩展到更多任务；这比追求一个无所不能的 AI 助手，更接近真正可交付的自动化。