如何评测模型与 API 渠道：用自己的任务建立验收表

先确定不能妥协的条件#

列出协议、上下文、工具调用、结构化输出、媒体输入、响应时间和预算要求。精确到实际需要的能力，例如“输出能通过这份 JSON Schema”，比“支持 JSON”更容易验收。

查看 渠道说明，确认模型身份、来源标签、权限与计费。客户端有某个开关，不代表所有渠道都支持该参数。

用小样本覆盖真实困难#

初次可以整理 30～50 条有代表性的样本，覆盖高频任务、长输入、歧义、缺失信息和必须拒答的边界。这个数量用于发现明显问题，不足以证明极低故障率；关键业务需要扩大样本并持续观察。

样本应来自你有权使用的数据，去掉身份信息与密钥。将调试集和最终验收集分开，避免不断修改提示词后只在同一批题目上取得好成绩。

冻结变量并记录版本#

对同一轮测试，固定提示词、工具定义、输出约束与可共同支持的参数。记录模型 ID、渠道、日期、参数和客户端版本。不同协议无法完全对齐时，把差异写入结果，不要装作严格等价。

部分模型具有随机性，抽取一部分样本重复运行，观察一致性；不要只挑最好的一次。轮换测试顺序，减少特定时段网络负载造成的偏差。

一张可以直接使用的验收表#

能自动检查的先自动检查；主观质量去掉模型标签后交叉评分。若使用另一个模型评分，抽样人工复核，并记录评分模型的偏好与成本。

如何写出可信结论#

结论应写成“在这批任务、这组参数和这个时间段，A 的格式通过率更高”，并附样本数量。不要从 20 条样本推导“永不降智”或“99.99% 稳定”。输出风格、速度或某个冷知识的变化，也不能单独证明模型被替换。

上线时先用小流量，保留回退路径；扩容前再做受控并发测试，并与运营方确认并发和额度。团队沟通字段见 团队接入，成本口径见 费用计算。