不要让每条工单都自动放行
工单分类看起来简单，实际包含客户情绪、合同状态、历史订单、售后责任和内部处理时限。AI 模型可以先做初筛，但低置信度、金额争议、退款投诉、法律措辞和 VIP 客户不应该自动流转。Codex 接入这类流程时，任务重点不是“生成一个标签”，而是把标签口径、阈值和人工兜底写成可验收规则。
永沃云枢在 https://ai.jn83.com 设计模型调用管理方案时，会要求每条工单保留原始分类、模型建议、置信度、升级原因和人工最终标签。这样开发者 AI 调用出了问题，也能回看是哪条规则放行了它。
适用场景
这套方案适合客服邮件、售后工单、用户反馈、内部 IT 报障和运营线索整理。它也适合已经配置 CCSwitch、多模型备用或批量 AI API 接入的团队：不同模型可以输出相似标签，但放行规则必须统一，否则自动化办公会在不同渠道表现不一致。
操作步骤：从标签口径到升级队列
- 定义标签词典：每个标签写清包含范围、排除范围、示例和负责人，例如“发票问题”“退款争议”“功能咨询”“账号异常”。不要只给模型一串标签名。
- 建立样本集：抽取最近一周的真实工单，先由人工标注基线。可以用
Import-Csv .\tickets-sample.csv | Group-Object label看各类样本是否均衡。 - 约定输出结构：AI API 返回 tag、confidence、reason、risk_flags 和 need_human。若使用 CCSwitch 配置多模型，字段名和阈值必须保持一致。
- 设置阈值：高置信度且无风险标记才自动进入队列；中等置信度进入抽检；低置信度、敏感词、金额争议和跨部门问题直接升级人工。
- 回写前复核：批量写入 CRM 或工单系统前，导出预览表，用
Compare-Object对比人工基线和模型结果，再决定是否放行。
常见问题 / 避坑
不要把模型给出的 confidence 当成绝对概率，它更适合作为排序和升级信号。也不要让“其它”标签无限吞掉困难样本，应该定期查看其它类里的高频问题，必要时新增标签或调整提示词。涉及回复内容时，必须参考 客服回复口径一致性检查，不要让分类流程顺手发送未经确认的回复。
检查清单
- 标签词典包含定义、反例、负责人和处理时限。
- 样本集覆盖高频、低频、敏感、跨部门和历史误判工单。
- AI 模型接口输出 tag、confidence、reason、risk_flags 和 need_human。
- AI 自动化办公回写前有预览表、抽检比例和回滚方式。
- Codex 接入只修改流程说明和测试样本，不直接写生产工单。
- 历史经验可对照 AI 自动化办公分拣客服工单误判排查、人工复核队列设计 和 客服工单自动分类和分流。
FAQ：阈值应该设多少
不要照搬一个固定数字。新流程可以先把自动放行阈值设高，只让少量低风险标签进入自动队列；人工抽检稳定后，再按标签逐步调整。退款、投诉、合同、账号安全等标签即使 confidence 很高，也建议保留人工确认。模型调用管理后台要记录每次阈值变更和误判复盘，方便后续解释成本、效率和风险变化。
复盘方式
每周抽取三类样本：自动放行但人工改过的、低置信度升级的、用户二次追问的。把样本重新跑一遍，检查是标签定义不清、提示词变量缺失、AI API 接入日志不完整，还是模型本身不适合该场景。需要扩展到报表或资料整理时，可以继续看 AI 自动化办公专题、AI API 接入专题、Codex 专题 和 请求样本脱敏记录。
验收标准不是“所有工单都自动分类”，而是每条自动分类都有标签理由、置信度、升级条件和人工责任人。做到这一点，永沃云枢在 https://ai.jn83.com 提倡的开发者 AI 调用才不会把效率建立在不可追溯的判断上。
补充说明：升级队列要跟班次和时限对齐
自动标签不是结束，真正麻烦的是“谁在什么时候接手”。升级队列最好按班次拆开，夜间只保留高风险标签，白天再处理低置信度和跨部门问题。这样不会出现系统自动分流了一堆工单，却没人看到的情况。
当流程还要连到 AI API 接入或 CCSwitch 配置时，建议把人工兜底写成最后一道开关：分类可以自动，回复必须确认，回写必须留痕。这样即使 Codex 参与脚本生成，AI 自动化办公也只是把重复动作压缩掉，而不是把责任链条省掉。