分流该按任务本身的可判定属性来切，不按模型名字的直觉来切。通常先看四件事：是否需要多步推理、输入是否长到跨段合并、输出是否要过严格格式校验、失败后能否低成本重试。Gemini 3.5 Flash-Lite 这类轻量模型适合接「问题明确、答案短、格式宽松或可校验」的常规问答；旗舰模型留给需要让模型自己拆步骤、跨长文归纳、或一次输出就要满足复杂结构的任务。切分点先用真实任务的打标结果定出来，再用同一批任务在两个模型上各跑一遍确认规则站得住。

建议把分流做成可复核的三步：抽近期真实任务按「多步推理、长文输入、严格格式」打标，为每类任务写一条条件加去向的规则，再用同一批样本在两个模型上各跑一遍对比。规则优先级要显式写死，边界样本默认走旗舰模型。判断依据以日志里能回看的字段为准，否则判不出对错，也没法复盘。

把近两周的真实任务抽五十条按类型打标签

先有一份可讨论的任务清单，比在会上口头分类有效得多。抽样时从线上日志或工单里按时间倒序取，覆盖不同入口和不同提问人，不要只挑自己熟悉的场景。标签维度建议固定为三项，并且每项都写判定口径，避免两个人标出两种结果：

• 是否多步推理：需要先得出中间结论再据此作答，或要跨段信息合并后才能回答，算「是」；单点事实查询、模板化改写算「否」。
• 是否需要长文输入：输入超过团队自定的阈值（例如用 tokenizer 或接口返回的 usage 字段确认是否越过某个长度档），或包含需要通读的多段材料，算「是」。
• 是否要求严格格式：输出要能过 JSON schema 校验、字段齐全、或要被下游程序直接解析，算「是」；自由文本算「否」。

每条任务的打标记录建议存成一行一条的结构化记录，便于后面统计和回放。下面的字段名可按自己的日志体系替换：

{
  "task_id": "q-0001",
  "scene": "产品参数问答",
  "input_len_bucket": "short",
  "multi_step": false,
  "long_context": false,
  "strict_format": true,
  "target_schema": "faq_answer_v1",
  "labeler": "someone",
  "note": "需要答案带固定字段，内容本身不复杂"
}

五十条不必等分，但要保证每个场景都有几条，否则规则会写在少数样本上。打标过程中出现分歧的记录单独存一份，分歧样本往往就是边界情况，后面写规则时会用到。

给每类任务写一条可判定的分流规则

规则要能被别人照着复核，所以写成「条件 + 去向」的形式，条件尽量落到日志里存在的字段上，而不是「看起来复杂」这种描述。下面是一份可替换的配置骨架，字段和取值按自己的打标维度改：

rules:
  - id: r1
    when: {multi_step: true}
    route: flagship
  - id: r2
    when: {long_context: true, multi_step: true}
    route: flagship
  - id: r3
    when: {strict_format: true, multi_step: false}
    route: lite_with_validate   # 轻量模型生成后过 schema 校验，失败再升级
  - id: r4
    when: {default: true}
    route: lite

边界情况按「先保守」处理：命中长文但推理很浅的任务，先看它是否需要跨段归纳，需要就走旗舰；格式严格但内容简单的任务，可以让轻量模型先出结果，再过一次 schema 校验，校验不通过就升级重跑，并把升级次数记进日志。规则冲突时显式排优先级，例如：内容安全与合规过滤 > 格式校验失败后升级 > 多步推理 > 长文输入 > 默认轻量。优先级写在配置注释里，别只留在某个人的记忆里。

用同一批任务在两个模型上各跑一遍收集表现

规则写完不能直接上线当定论，先用同一批抽样任务在两个模型上各跑一次，用固定 prompt 和固定参数，保证差异只来自模型和路由。对比记录表建议包含这些字段：

人工复核不必全量。可以先保证每条规则覆盖到足够看出趋势的样本，覆盖样本少的规则整类都看；命中默认轻量分支的任务抽一部分看，因为这里最容易藏住被错派的任务。发现规则失效时的修改流程建议固定为：把该样本标为规则失效 → 记录漏判原因（是条件缺失还是字段没采集）→ 改规则或补条件 → 用同一批样本重放 → 对比新旧规则在同样样本上的命中分布，再决定是否保留改动。

定下复盘周期和观察指标

分流表最容易死在「做完就放着」。建议每两周复盘一次，规则改动后额外补一次小复盘。指标口径要提前写死分子分母，否则每次算出来都不一样：

• 返工率：同一任务被人工重新派给旗舰模型、或被打回重写的条数 ÷ 该类任务总数。
• 人工改写比例：输出被编辑的字符数 ÷ 原输出字符数，按规则类汇总；口径固定为「人工最终稿对比模型原始输出」。
• 格式一次通过率：首次输出通过 schema 校验的条数 ÷ 该类任务总数。
• 升级率：轻量分支升级到旗舰的条数 ÷ 轻量分支任务总数，用来观察规则是不是切得太松。

指标异常时的调整动作按归因走，不要整体切回旗舰模型：返工率在某类任务上抬高，先翻样本看是否集中在长文输入，若是则收紧该类规则；升级率偏高说明轻量分支接了不该接的任务，回看打标记录补条件；格式一次通过率下降，优先查 schema 是否改过、prompt 是否漂移，再判断是否换模型。所有调整都留一条记录：改了什么条件、基于哪几条样本、下次复盘看什么。这样分流表才是能被验证和迭代的资产。