业务流程 · 实作指南
维修请求分流：加快日常处理，也别把紧急事件藏起来
先设计清晰的升级处理渠道，再加入 AI 请求分类。
先定义哪些事情不能等
假设物业团队在下班後收到维修讯息。AI 分类或能整理日常工作，但把紧急事件错列为普通请求，与分类标签选错，後果并不相同。先请营运人员定义警示情况、清楚可用的紧急联络渠道，以及系统无法判断时的处理方式。不要让住户以为填好表格就等同已有人接手。
分流不等於安全指示
收集位置、联络方式、问题描述和报告时间，并把原文放在建议分类旁边。不要产生危险维修的操作指示。即使分类仍待确认，也可以透过明确规则通知指定人员。升级安排必须符合团队真实值班能力，不能在网站上暗示存在一个实际上没有人的二十四小时处理中心。
流程一览
输入整理审核执行
跟踪谁接手，而非只看状态
标记处理中的请求应有负责人及下一步行动。通知发送失败时，请求要留在例外队列，并提供後备渠道。事件驱动系统中，收到讯号与完成业务行动是不同阶段；系统回应已接收，也不等於员工已确认接手。这种区分比再增加几个分类标签，更能防止工作消失在交接之间。
检讨漏接与误分
先用影子模式，由现有员工维持正式分流，再检查模型与人员的差异，特别是模型判为普通而员工要求升级的个案。记录逾时未分派的请求，以及人员确认接手所需时间。这是营运设计建议，并非紧急应变服务，也不表示分类模型能识别所有危险；真正的安全渠道必须独立且明确。
可以立即进行的练习
与真实值班团队演练普通讯息、可能紧急但语意不清的讯息，以及通知失败。逐项写出收件人、请求人看到的状态与後备渠道；失败状态没有人负责，就先停止推出。不要用模拟支援中心取代真实人手安排。也请新同事只看指引，找出紧急联络方式与暂停自动化的方法；若他需要开发者在旁提示，表示操作流程尚未交付，而不是员工需要更相信模型。
来源与延伸阅读
- The Events APIThe Events APISlack Developer Docs · 官方文件 ·
- Building effective agentsBuilding effective agentsAnthropic · 官方文件 ·
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。