全都用最强的模型，是最贵的懒政
模型选择是个取舍 ✔：快而省 vs 准而贵 ✔。
如果全站只用最强的 ✗，成本高、延迟差 ✔；如果只用最便宜的 ✗，质量差 ✔。
做法：默认自动路由 + 允许用户覆盖 ✔。
一、自动路由的三条规则
① 复杂度路由：简单任务（分类/抽取/格式化）→ 小模型
② 长度路由：超长输入 → 长上下文模型（或先摘要）
③ 兜底路由：小模型校验失败 → 自动升级到大模型重试一次
第 ③ 条最实用 ✗→✔：多数请求走小模型 ✔，
只有"小模型没做好"的少数请求才升级 ✔ —— 成本与质量都能兼顾 ✔。
二、给用户的"两档"而不是"参数表"
用户不需要看模型清单 ✗，需要能判断的两档 ✔：
○ 快速模式 — 约 2 秒，适合分类、改写、格式整理
○ 精确模式 — 约 8 秒，适合分析、多跳推理、复杂约束
（默认：自动选择）
要点：写清耗时与适用场景 ✔（见界面文案那篇 ✔），
而不是暴露模型名与参数 ✔。
三、用户覆盖的三种方式
- 预设档位（快速/精确 ✔ —— 最常用 ✔）；
- 自动 + 标注（系统选了哪个，为什么 ✔ —— 透明度 ✔）；
- 允许"升级重试"（对结果不满意时一键用更强模型重跑 ✔，并提示会消耗更多额度 ✔）。
四、该观测什么
- 路由分布（多少请求走小模型 ✔ —— 比例高说明路由有效 ✔）；
- 升级率（小模型失败升级的比例 ✔ —— 过高说明路由判据不准 ✔）；
- 各档的质量与成本（分别看 ✔ —— 不能只看平均 ✔）；
- 用户覆盖率（多少用户手动选档 ✔ —— 高说明自动选择不被信任 ✔）。
五、三个反模式
- 全用最强模型 ✗（成本与延迟都不必要地高 ✔）；
- 全用最便宜模型 ✗（复杂任务质量差，用户流失 ✔）；
- 让用户选模型版本号 ✗（用户无法判断 ✔）。
六、一条判据
用户能否说出"我该选哪档、为什么" ✔，而系统是否会把简单请求自动走便宜路径 ✔？
两者缺一，说明模型选择还没设计好 ✗。