客服系统要从一段中文对话里提取订单号、问题类型和待办动作时，可以先把 Qwen 3.8 Flash 设为候选，再用 Qwen 3.8 Max 跑同一批样本。选型看每千条工单里有多少条能直接入库、多少条要人工复核，以及两者加起来的成本。
先定义一条合格工单
从历史数据里抽取一批已脱敏、人工标注的工单，保留真实比例，并单独记录容易出错的分组，例如一次提到两个订单、用户改口、没有给出订单号。测试前先约定字段和判分规则。
| 字段 | 判分规则 |
|---|---|
order_id |
与原文和人工标签一致。缺失或指代不清时返回 null |
category |
从物流、退款、商品、其他中选择。按团队约定标注多意图工单 |
next_action |
摘要复述原文明确提出的待办。缺失时返回 null |
evidence |
引用支撑字段判断的原文片段，便于复核 |
例如，“上周那单已经到了，帮我查这周这单到哪了”可以归到物流，订单号留空。评估时应把凭空补订单号和漏填订单号分别统计，前者可能把工单挂到错误订单上。
固定输入，记录真实用量
通过 OpenAI 兼容的 Chat Completions 接口发送相同的消息。先用 qwen3.8-flash，再把请求的 model 改为 qwen3.8-max。固定提示词、输出字段和重试规则。下面是单条样本，可用来检查返回格式。 API 接入文档
curl https://api.teamorouter.com/v1/chat/completions \
-H "Authorization: Bearer $TEAMOROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3.8-flash",
"messages": [
{"role":"system","content":"只返回 JSON。字段为 order_id、category、next_action、evidence。category 只允许物流、退款、商品、其他。无法从原文确定的订单号或待办填 null。evidence 引用原文。"},
{"role":"user","content":"上周那单已经到了，帮我查这周这单到哪了。"}
]
}'
在应用侧解析 JSON、校验字段和枚举，再检查订单号和证据能否在原文中找到。每次请求记录用量、延迟、校验结果和重试原因。最终按难例分组比较字段准确率，也记录整条工单一次通过的比例。格式合法的结果仍要和人工标签核对。
把重试和人工复核计入成本
分别测试全量 Flash、全量 Max 和 Flash 首轮加 Max 复核。第三种可以在 JSON 解析失败、同段出现多个订单号或证据与原文不匹配时升级。Max 的返回仍走同样的校验，存在歧义的工单交给人工。另抽查首轮通过的样本，估计规则放行了多少错误结果。
用账单核对初次请求和重试的总费用，缓存命中时按实际账单计入。把人工复核时间乘以内部单位成本，再用总费用除以最终验收合格的工单数。上线前同时比较每千条需复核的工单数、关键字段误填率和端到端 P95 延迟，避免平均成本掩盖难例的代价。
截至 2026 年 11 月 11 日，两款模型均出现在 TeamoRouter 公开目录，按 token 计费。复测时可在 Flash 模型页 和 Max 模型页 核对当前价格、供应商与可用性。