演示里一路顺畅，现场第一天就遇到从没讨论过的客户
销售线索分配助手在测试时按地区和行业顺利派单。上线后出现集团客户跨三个区域、老客户使用新公司名、海外号码缺少省份、战略客户要求指定负责人。系统按标准规则分错，员工开始绕过助手手工处理。
企业流程图往往记录正常路径，真正占用管理时间的是例外。员工凭经验知道哪些客户不能自动分、哪些订单要先问财务、哪些资料缺失也能继续。若这些经验没有进入设计，AI 只能在最理想的输入上表现良好。
异常案例库不是错误截图堆，而是可复用的业务样本
每个案例应记录触发条件、原始输入、当时结果、正确处理、业务依据、风险等级和负责人。去除不必要的个人信息后，保留真实的缺字段、错别字和上下文，因为这些正是系统需要面对的情况。
案例可以按数据异常、规则冲突、权限不足、特殊客户、外部系统失败和人工临时决定分类。先收集高频或高损失例外，不必追求一次覆盖所有角落。分类的目的，是决定哪些可以补规则，哪些必须交给人。
- 保留真实输入形态，不把样本过度清洗。
- 写清正确处理依据和最终责任人。
- 高风险低频例外也应纳入测试。
不要试图让 AI 自动处理每个例外，先设计安全出口
有些例外有稳定规则，例如号码缺省份时根据客户归属查询；有些需要判断，例如战略客户跨区域分配；还有些根本不应自动化，例如超权限折扣和特殊合同承诺。为每类情况指定自动补全、请求补充、转人工或拒绝执行。
转人工不能只显示“无法处理”。系统要附上已识别信息、触发原因、建议动作和原始记录，送到明确队列。人工处理后选择最终原因，结果再回到案例库，下一轮才知道是否值得新增规则。
异常数量突然上升，往往说明业务已经变了
每周查看异常类型、发生频率、处理时长和重复出现的业务对象。某类缺字段快速增加，可能是上游表单改了；指定客户越来越多，可能是销售分工变化；外部接口频繁超时，则需要调整重试与人工接管。
不是所有异常都要消灭。稳定且合理的例外可以成为正式分支，偶发个案继续人工处理。判断标准是规则是否清楚、样本是否足够、自动处理的失败代价是否可接受。
异常案例越真实，企业 AI 越能从演示走进日常
上线前让一线员工各提供几个“最难处理”的真实案例，通常比管理层再开一次方案会更有价值。上线后把转人工和人工修改持续沉淀，避免团队每次遇到相同问题都重新讨论。
企业 AI 的成熟，不是宣称覆盖百分之百，而是标准情况自动完成，特殊情况及时停下，人工处理后还能留下经验。异常案例库把隐性的现场判断变成组织资产，也让下一次迭代有据可依。
要点总结
- 可从一线员工访谈、人工转交、投诉、失败日志和上线后的修改记录中收集。
- 不需要。规则不清、样本少或失败代价高的例外，应保留人工处理。
- 按最小必要原则脱敏，去除姓名、电话等无关信息，同时保留影响判断的业务特征。
参考来源说明
本文围绕“正常流程都能跑，为什么上线后总被例外打败？企业 AI 要建立异常案例库”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。