AI 工作流失败检测与复盘：别只监控有没有报错

直接判断：可靠的 AI 工作流必须能主动暴露“我不知道、我只完成了一部分、目标状态没有变化”，而不是把所有运行都包装成成功。

传统监控常盯进程、耗时和错误码，但 AI 工作流还会出现语义错误、置信度漂移、真源过期、范围扩大和证据断链。一个每天准时生成的错误报告，比偶尔报错的脚本更难被发现。复盘要同时看系统状态与判断质量。

先做判断

先定义失败分类：输入失败、身份或权限错误、数据不完整、变换错误、低置信度、范围外变化、外部写入部分失败、目标回读不一致、业务结果未达预期。最后一种不一定表示系统错误，必须与产品或市场结论分开。

每类失败都要对应检测信号、owner、自动响应和人工升级条件。没有响应设计的告警，只会变成新的噪声。

诊断与决策框架

第一层监控输入。检查来源更新时间、记录数、分页、关键字段缺失、身份与环境。若输入异常，默认停止写入并保留上次有效产物，不能用空结果覆盖。

第二层监控变换。记录输入、过滤、跳过、未知、低置信度和输出数量；对关键规则设置不变量，例如价格不能无原因变成负值、对象数不能异常膨胀、非目标字段不能被修改。

第三层监控输出。验证文件格式、schema、链接、构建与抽样语义。AI 生成内容还要检查事实来源、禁用信息与隐私边界，而不是只做语法通过。

第四层监控应用与回读。外部写入后统计 submitted、processed、rejected、pending，并独立读取目标系统。若实际结果与预览不一致，立即停止后续批次，输出差异和可恢复动作。

第五层监控业务结果。按照任务契约的观察窗口评估点击、处理状态、用户路径或运营效率。系统状态正确但商业结果无改善时，结论是“假设未被证实”，不能篡改阈值或把责任推给自动化。

每周复盘只回答四件事：发生了什么失败；为什么现有检查没提前发现；应该增加、删除还是调整哪条规则；是否需要新的人工闸门。优先修能拦截同类错误的最小规则，不为一次异常搭建庞大平台。

常见误判

• 告警越多越安全，结果 owner 被噪声淹没。
• 所有错误自动重试，导致重复写入、成本增加或错误扩散。
• 为了稳定通过而降低阈值，却没有记录标准变化。
• 将业务结果不佳等同于 AI 执行失败，或反过来用执行成功证明策略正确。

验证清单

• 失败分类覆盖输入、变换、输出、应用、回读和业务结果。
• 每个告警有 owner、优先级、响应与关闭证据。
• 空数据、低置信度、部分失败和未知状态不会被包装成成功。
• 高风险异常会停止后续批次并保留上次有效状态。
• 技术验收与商业验证分别记录。
• 复盘产出的规则有作用域、证据、版本和使用前核验标记。

适用边界

本剧本适合长期运行的 Feed、页面 QA、数据同步、报告和知识更新流程。极低频手工任务可简化监控，但仍要保留完成证据；涉及安全事件、支付或个人数据时，应接入组织现有的专门响应流程。

用 AI 证据链操作系统 定义可观察状态，并参考 自动化没有回读的诊断 排查为什么绿灯仍不可信。