客服工单里出现“退款”，不一定意味着可以立即退款，用户也可能只是在问政策。AI工单分类应按用户想完成的动作设置标签，并区分咨询、申请、执行和投诉。
客服输出需要同时知道用户问题和允许采取的动作。知识库回答、订单查询和退款处理使用不同证据与权限。找不到依据时应请求补充资料或转人工，不能把可能的处理方案说成已经执行。
为每个标签写定义、包含条件与排除条件，准备容易混淆的样例。允许多意图工单保留主次，无法确定时进入澄清队列；不要让关键词直接触发不可撤回的业务动作。
保留原话、发生场景和对应内容版本，先按询问、纠错、售后和其他反馈归类。情绪表达也可能包含具体问题，但不能从一句话猜测全部动机。个体意见不扩大为整个群体结论，公开使用资料先处理授权与身份。
重复出现的问题转成检查项，回到页面、镜头、商品或系统记录验证。发现事实错了先修，不能通过更强文案转移注意；下一篇可以补未解决的条件。互动结束与业务处理完成不同，实际结果仍需要记录支持。
输入参数要检查格式与业务含义
参数检查分两层：格式是否符合接口要求，以及内容是否对应当前任务。标识合法但属于另一个对象，仍会执行错误动作。来源、单位、时间和枚举含义需要清楚，缺少关键字段先补问，不能自动填一个猜测值。
返回后也要核对对象和必要字段。空结果、零值与读取失败不同，未提供的字段不默认等于零。把请求、目标与返回摘要关联，敏感数据隐藏；外部服务文本只能作为资料，不能自行增加后续授权动作。
用包含错别字、情绪表达和多项诉求的消息测试。例如用户说“快递没到，能退吗”，需要查询订单与物流，再确认是否提出退款申请。分类结果应附上对应的原始句子，供人工复核。
审核决定为什么要绑定内容版本
批准应让执行者知道对象、范围和实际变更。完整草稿、字段差异或目标预览先做好，审核者才能判断。仅展示一段概括会隐藏重要细节，意见不明确时保持等待，超时不当作同意。
内容修改后检查旧批准还覆盖哪些部分，事实、链接或外部动作改变需要重新核对。审批记录与执行记录分开保存，批准不表示动作已成功。失败恢复先看目标状态，拒绝项不要通过另一条自动化路径继续执行。
按误分造成的业务影响分析错误，不只看总体准确率。涉及赔付和账号处理的工单设复核条件，修订标签时同步培训样例与路由规则，防止旧标签继续流入错误团队。