Python + Gemini JSON Schema 实现可校验的工单路由
内容提要
文章介绍用Python调用Gemini的JSON Schema实现可校验的工单路由：让模型输出受限JSON，再由本地程序复核队列、置信度与敏感词，失败或低置信度时转人工。强调Schema只约束结构不保证正确，需设置超时、回退与抽样评估，适用于售后分单等可复核场景。
延伸解读
Schema 只约束结构，不保证判断正确
文章反复强调，JSON Schema 能规定字段、类型和枚举，却无法验证“支付”这个分类是否真的正确。因此不能把 Schema 当成事实校验器。生产系统需要保留抽样标注集，持续观察各队列的误分率，尤其对高风险类别先只允许进入人工复核，避免模型给出结构合法但语义错误的工单路由。
本地安全门禁是可靠性的关键
示例中的 safe_route 把 API 失败、字段缺失、低置信度和敏感投诉统一降级到人工队列。这意味着即使供应商限流或模型响应异常，也不会让订单卡在半自动状态。文章建议生产环境还应记录请求 ID，便于排查空候选、配额耗尽等异常，而不是只依赖模型返回的合法 JSON。
适用边界：可复核场景才适合自动化
文章明确区分了适用与不适用场景。售后分单、表单归类、内容标签等队列有限、错误可复核、能接受数秒延迟的任务适合使用；而直接退款、封号、授信或医疗结论不应交给模型做最终决定。工程化时还需把 Schema 版本、提示版本和人工纠正结果写入审计表，并定期用纠正样本回放评估。
提示与日志中的隐私风险
文章提醒不要把规则机密塞进提示，因为提示可能进入日志。应仅发送完成任务所需的最少字段，并对日志脱敏。这一限制与本地敏感词门禁相配合，能在模型之外增加一层保护，降低因提示泄露或日志留存带来的合规风险。
Q&A
为什么用关键词做客服工单路由会越来越难维护？
关键词只能匹配字面，无法处理语义差异。例如用户说“银行卡被扣了两次”不含“退款”却应进支付队列，“想问电子发票”又可能被误判为支付故障。规则越堆越难维护。
Gemini 的 JSON Schema 输出能保证分类结果正确吗？
不能。Schema 只约束字段、类型和枚举，不保证“支付”这个判断真的正确。它只保证结构，不保证分类正确性。
在 Python 中调用 Gemini 实现工单路由时，如何设置超时和失败回退？
使用 urllib.request.urlopen 设置 timeout=20 秒；在 safe_route 函数中捕获 KeyError、ValueError、URLError、TimeoutError 等异常，统一降级到 human_review 队列。
本地程序在收到模型返回的 JSON 后，会做哪些安全复核？
检查 queue 是否在允许的枚举值内、confidence 是否为数字且不低于 0.80、消息中是否包含“盗刷”“泄露”“起诉”等敏感词。任一不通过则转人工队列。
这种可校验的工单路由适合用在哪些场景？不适合哪些？
适合队列有限、错误可复核、能接受数秒延迟的售后分单、表单归类、内容标签。不适合直接退款、封号、授信或医疗结论等需要确定性规则和资质人员最终决定的场景。
实现时最常见的三个坑是什么？
一是把 Schema 当真相，它只保证结构不保证分类；二是不处理空候选，安全拦截或配额耗尽可能导致没有 candidates[0]；三是在提示中塞入规则机密，提示可能进入日志，应仅发送最少字段并对日志脱敏。
