在一间普通的运营办公室里，最忙的往往不是处理标准订单的人，而是盯着屏幕找“不对劲”的人。地址少了一个门牌号，备注里写着“请联系后再发”，客户改了口径却没有同步到系统。这些事不宏大，却消耗注意力。人工智能被寄望于接住这一摊，但真到流程末端，问题常常不是模型会不会写一段话，而是它能不能在不确定时停下来。
顺畅的演示，卡在例外上
很多演示把流程切成整齐的几步：识别需求、生成回复、填入系统、通知下一步。每一步看起来都成立，连起来却未必。现实中的输入带着情绪、缩写、省略和前后矛盾。模型可以给出看似合理的判断，但业务需要的是“这一单能不能继续”“该由谁确认”。当例外被当成普通样本处理，自动化就会把错误放大，只是错得更安静。
所以，讨论人工智能落地时，我更愿意先看例外清单，而不是功能清单。功能回答“能做什么”，例外回答“做错时怎么办”。后者不性感，却决定一套系统能不能长期留在流程里。
把“不知道”留在系统里
一个可用的做法，是让系统显式保留“不确定”这个状态。不是所有请求都要立刻给答案，也不是所有判断都要伪装成确定。遇到信息缺失、规则冲突或超出权限的情况，系统可以停下来，把已知信息和缺口一起交给人工。这样做看起来降低了自动化比例，却减少了返工和解释成本。
这背后是人机分工的边界问题。机器擅长快速比对、归纳和生成草稿，人更清楚责任落在哪里、这句话说出去会引发什么后果。把边界划清楚，不是给人留退路，而是让流程有可追溯的停顿点。停顿不是失败，是控制。
先改流程，再谈模型
还有一个常被忽略的前提：如果流程本身没有把例外说清楚，模型只能猜。很多团队急着选工具，却没有先整理异常类型、处理权限和回退路径。结果就是模型上线后，人工环节没有减少，反而多了一层“检查机器做得对不对”的工作。
我不认为人工智能会一夜之间接管复杂流程。更现实的路径，是先在重复、边界清楚、反馈及时的环节里用它，把节省下来的注意力留给例外。等例外被记录、被归类、被慢慢消化，流程才有机会变得更稳。技术值得期待，但真正难的，仍然是那些没有被写进演示脚本的小问题。