选择 API 平台之前，先写清楚验收条件

从工作流定义需求

先写下应用真正要完成的任务：输入是什么，怎样判断输出合格，响应需要多快，失败后如何处理。交互式助手与夜间批处理通常有不同的延迟和恢复要求，把它们放进同一张排名表容易得到错误结论。

准备一组不含个人信息或商业机密的样本，覆盖常见任务、较长输入和明确的边界情况。对所有候选配置使用相同的验收标准，记录模型 ID、协议、参数和测试日期，让结果可以复现。

把兼容性拆成可观察行为

能返回一段文字，只能证明最小请求成功。继续检查应用依赖的流式输出、工具调用、结构化结果和用量字段。不要从一个接口成功推断其他协议也可用；客户端版本和模型配置同样会影响结果。

• 按实际任务核对当前模型可用范围与精确 ID。
• 确认费用口径、限流说明、数据处理规则和支持入口。
• 验证超时、取消、错误分类及重复提交的处理方式。

用小规模试运行形成决定

在限定预算内运行代表性任务，分别记录质量、耗时、失败情况与费用，保留样本数量和时间窗口。小样本能发现问题，不能证明长期稳定性。为无法验证的项目标注“待验证”，比用主观分数填满表格更有价值。

最后检查退出成本：配置能否替换，日志是否可导出，业务层是否依赖某个特有字段。NexoToken 的公开页面可作为查找服务信息的入口；本文由 NexoToken 维护，不是对自身服务的独立认证。