路由、分支与业务校验

核心概念

路由决定请求进入哪条处理路径；分支决定满足什么条件才进入下一步。模型可以提出任务分类，但确定性规则适合处理必填字段、枚举值、门店归属和状态转换。服务端还要独立校验身份与权限。

分类不确定、多个意图混在一起或任务不受支持时，应追问、拆分或转人工。不能把无法判断的请求默认送进写入分支；模型自报的置信数值不等于错误概率。

情境拆解

员工说“查一下昨天的工单，没建就建一个”。先在授权范围内查询，并核对设备、时间及状态。只有确认没有对应工单、必要字段齐全且用户确认了动作，才能进入创建分支。搜索无结果也可能来自过滤或接口异常，不能直接等同于工单不存在。

业务校验应在执行前再次检查，因为工单状态可能在对话期间发生变化。知识回答可以解释规则，但是否允许修改工单，仍以服务端当时的校验结果为准。

常见误区

把工作流画成一条成功直线，会遗漏缺字段、无权限、查询失败和状态变化。让模型凭描述绕过门店归属检查，会把语言理解变成未经授权的业务裁决。

查询失败不等于没有工单

先查询已有工单，可以避免不必要的新建。但查询接口不可用时，只知道读失败，不能推断记录不存在，更不能立即创建替代工单。

路由决定下一条受控路径；真正执行时还要检查资源、权限和最新状态。之前通过一次检查，不代表这些条件永远不变。

动手：写一张请求路由表

1. 定义咨询、查询、新建、修改和人工接手五类路径。
2. 写六个请求，包含含糊指代、跨门店、读取失败和明确新建。
3. 对每项记录路由依据、需要补齐的字段以及执行前检查。
4. 为读取失败设计停止或核对路径，不把“未找到”和“没能查询”混成同一种结果。

请求与可信身份范围：
路由：
路由依据：
必需字段与仍缺的信息：
读取结果：已找到、确认不存在或未知
执行前权限与状态检查：
下一步及用户反馈：

检查产物

咨询不会触发写入；读取失败不会自动触发新建。另一个开发者能够从表中复现路由，并知道哪里需要追问或接手。