按难度选推理模式
复杂提示方法并不是对所有难度都更优：简单问题走长链推理只会增加成本与出错机会。做法是先用一次轻量判断分难度，简单问题直接作答，复杂问题（多步推理、需要权衡）才启用分步推理与验证。两套流程各自写成独立提示并分别评估，避免改了一边导致另一边行为漂移。
基本信息
| 判断输出 | 简单 / 复杂，仅一个词 |
|---|---|
| 简单流程 | 直接作答，不展开推理 |
| 复杂流程 | 先分步推理再给结论 |
| 实现 | 两套提示 + 规则或轻量调用做路由 |
| 收益 | 简单流量不付额外推理成本，延迟与费用同时下降 |
典型使用场景
- 客服问答：常规查询直接答，涉及多方权衡的才走推理链路
- 数据核对：单值比对直接判，跨表核对走分步流程
- 代码问答：解释单行语法直接答，架构取舍走推理流程
- 批量处理：按难度分流，控制整体成本与响应时间
- 模型选择：简单请求用小模型，复杂请求用大模型
路由提示片段
路由提示片段
先判断问题复杂度（简单 / 复杂），只输出一个词：
- 简单：单步事实或一次计算，直接作答
- 复杂：多步推理或需要权衡，走「先分步推理再结论」流程
# 判定标准要可操作：给出 1-2 个正反例子
# 只输出一个词，便于程序直接分支
# 两套流程分别维护与评估，避免互相影响
# 监控简单/复杂占比，占比异常说明判定标准漂了两类流程对照
| 维度 | 简单流程 | 复杂流程 |
|---|---|---|
| 适用 | 单步事实、一次计算 | 多步推理、需要权衡 |
| 输出 | 结论 + 依据片段 | 分步推理 + 结论 + 复核 |
| 成本 | 低，一次调用 | 高，分步与验证多次调用 |
| 评估 | 准确率与格式合规率 | 准确率、推理步骤质量、成本 |
「简单/复杂」的判定标准不写清会让路由不稳定；补 1-2 个判定例子能明显降低误判率。
两套提示要分别维护与评估：复杂流程改动后若共用同一份评估集，简单流程的行为漂移不易被发现。