维度一二：任务与输出
先写清任务要什么：中文长文理解、结构化输出、工具调用、多模态还是低延迟。不同模型强弱不同，榜单只反映平均表现；怎么选：把三到五个真实任务写成练习集，再让候选模型各跑一遍，比看排名可靠得多。
维度三四：质量与工程
质量要可测：通过率、格式合规率、拒答率与人工接管率，缺一项都难判断。工程侧看上下文长度、并发、延迟与函数调用稳定性；怎么取舍：先满足业务可用，再追指标，别为几分评测分牺牲数倍延迟，多数项目卡在这里。
维度五六：合规与替换
合规看备案情况、数据是否用于训练、部署位置与内容标识要求，这些决定能不能上线。可替换性怎么判断：看有没有抽象层，把模型调用封装在一层接口后面，换模型只改配置；忽略这条，第二年想换供应商就要重写业务代码。
打分表怎么用
六个维度各给一到五分，权重按业务优先级定，任务匹配权重最高。设一票否决项，例如数据必须出内网、要求不用于训练却拿不出条款；总分怎么用：只用来排序，最终要给出一份在什么任务上用哪个模型的说明。
适用与不适用
适合谁
- 要在两三个模型之间做选择的团队
- 有真实任务样本、愿意搭评测集的企业
- 需要兼顾质量、延迟与合规的项目
不适合谁
- 只看榜单和价格、不做评测的采购
- 没有样本、也不准备做验证的团队
典型场景
某制造企业的客服与报价场景要选模型。团队整理一百二十条真实问答与六十条结构化报价任务，统一提示词后让三个候选各跑两遍，记录通过率、格式错误与延迟；合规侧核对备案与数据处理条款，最后按打分表排序并保留两个模型做路由。
可执行步骤
- 列出三到五个真实任务，写明输入、期望输出与失败类型，并标注最容易出错的一步
- 从业务系统抽一百到三百条样本，做成固定评测集并封存，附一份评分说明
- 用同一套提示词与参数跑候选模型，记录通过率、格式错误与平均延迟
- 核对备案情况、训练条款与部署位置，再按六个维度的权重打分排序
常见坑
- 看榜单排名选模型，榜单任务与自家业务差异很大，上线后通过率远低于预期，返工又要两周。
- 用通用问答做演示来判断能力，缺少结构化输出与长文场景，真实任务一跑就露馅，返工代价很高。
- 忽略版本升级，供应商换模型后输出风格突变，原有提示词与校验规则全部失效，只能临时回滚。
自检与验收清单
- 是否列出真实任务、期望输出与失败类型的清单
- 评测集是否由业务样本构成，并在测试之前封存
- 是否记录模型版本号、测试日期与运行参数，并纳入评测记录
- 备案情况与数据处理条款是否已经逐条核对，并有书面结论
- 是否保留了一层可以整体替换模型的抽象封装层
常见问题
一定要自己建评测集吗？
建议建，规模可以小。用一百条真实样本、固定提示词与评分表就够起步；没有评测集，选型只能靠演示与口碑，出了问题也无法判断是模型、提示词还是数据的原因，也便于安排后续的验证节奏。
多模型路由会不会太复杂？
前期可以只用两个模型：一个主力、一个兜底。路由规则写清什么情况切换、切换后如何记录；复杂的是运维与计费口径，因此要先把日志与用量统计做好，再考虑扩到三个以上。
开源模型和闭源模型怎么选？
看数据边界与运维能力。数据不能出内网、且团队有能力维护推理服务时，本地部署更合适；反之用成熟接口更快。两者也可以并存，把敏感任务放本地，通用任务走接口，并按阶段逐步切换。