路由分发的结构
路由模式先用一次轻量分类调用判断请求类型，再把请求分发给对应的专门提示或处理流程。好处是每个下游提示可以更短更专注，新增类别只需加一个分支，不必改动一个巨型提示。代价是每次请求多一次调用，以及类别边界重叠时的误路由。设计时必须同时定好兜底分支（other）与失败回退路径。
基本信息
| 结构 | 轻量分类 → 分发到专门提示或流程 |
|---|---|
| 收益 | 下游提示更专注、更短；新增类别只需加分支 |
| 兜底 | 必须有 other 分支与失败回退（统一入口或转人工） |
| 成本 | 每请求多一次轻量调用，可用规则或小模型做路由器 |
典型使用场景
- 客服入口分流：计费、技术故障、账号、其他四类分派到不同话术
- 内部工单系统：按业务线分派到对应处理队列与知识库
- 代码助手：区分解释代码、生成测试、修复报错三类任务
- 检索增强问答：先判是否需要检索，需要时再走检索链路
- 内容处理：区分抽取、摘要、改写三类，各自使用不同输出模板
路由提示示例
路由提示示例
判断用户消息属于哪一类，仅输出类别名：
billing 计费 / technical 技术故障 / account 账号 / other 其他
消息：<user_message>
类别：
# 输出限定为类别名，不要解释，便于程序直接分支
# 类别定义要写在系统提示里，避免边界重叠造成误路由
# 兜底：other 分支接统一入口提示或直接转人工
# 监控：统计各类别占比与 other 占比，other 偏高说明类目划分有问题路由常见故障与处理
| 现象 | 可能原因 | 处理 |
|---|---|---|
| 误路由到错误分支 | 类别定义边界重叠 | 梳理类目定义，补反例 |
| other 占比过高 | 类目未覆盖常见请求 | 抽样看 other 内容，补类目或改判定标准 |
| 同一请求分类飘忽 | 判定标准含模糊词 | 换成可判定的客观特征 |
| 下游提示失效 | 分发时未传递必要上下文 | 分发请求里带上原始输入与关键字段 |
类别边界重叠（技术故障与账号问题都能收的登录失败）时误路由率显著上升，先梳理类目定义再上线。
路由失败没有兜底会把用户卡在错误分支里得不到答案；设计阶段就规定回退路径，并在监控里统计回退比例。