可靠的 AI 接口测试，先锁定边界再评价答案

测试调用 AI 接口的代码，不能只检查回答是否通顺。网络故障、响应格式变化、重复请求和模型输出波动，都可能让一次成功演示变成线上事故。更可靠的顺序，是先验证程序能够控制的行为，再用少量真实请求评估模型表现。

本文由 BestRelay 发布，下面沿着一个提取工单信息的应用，逐步建立这套测试。

第一步先把业务判断与远程模型调用明确分开

假设应用需要从用户描述中提取问题类别、紧急程度和联系方式。先把远程调用放在独立边界后面，让业务层只接收经过校验的结果，而不是直接处理供应商的完整响应。

这个边界应明确输入、超时、错误类型和输出结构。这样，分类规则与后续派单逻辑就能独立测试，不必每次联网，也不会因为一次措辞变化而失败。

第二步用可控替身覆盖成功路径与失败路径

在单元测试中，用测试替身返回预先设计的响应。正常样本只需覆盖必要字段；异常样本则要包括空内容、字段缺失、类型错误、拒绝回答和输出截断。

不要只模拟一段漂亮答案。还要验证认证失败不会被无限重试，限流会进入有上限的等待流程，连接超时会交给业务层处理。测试替身应模拟实际使用的客户端边界，避免测试与真实调用方式脱节。

第三步用契约断言检查请求结构与流式生命周期

接下来检查发出的请求：模型标识、消息顺序、工具定义和输出限制是否正确。对于稳定字段，可以使用精确断言；对于生成文本，不宜把整段内容固定为唯一答案。

如果应用采用流式响应，还应模拟分段到达、空片段、中途断开与用户取消。工具调用参数可能跨多个片段传来，必须在完成组装后再解析。测试还要确认取消后连接会释放，不会继续向界面追加内容。

第四步用少量真实请求确认外部接口仍然兼容

测试替身证明的是本地逻辑，不能证明真实服务仍然接受请求。准备一组规模有限的集成测试，验证认证、响应解析、流式结束信号和用量字段，并为调用设置预算与超时。

经过中继时，还要检查模型标识是否按预期透传。BestRelay 以质量优先，将请求转发至其中指定的官方模型，不做模型替换，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen 和 Grok 等系列。但这一服务约定不能代替应用自身的契约验证。

它可配合 Claude Code、Codex、Gemini CLI 和 OpenAI SDK 使用，具体能力仍需按所用工具与接口测试。需要跟着验证时，可以创建一个 BestRelay 账户。

第五步用任务评分替代对生成答案的逐字比较

建立一组去标识化工单，分别标注正确类别、必需字段和不可接受行为。优先用确定性规则评分，例如字段能否解析、枚举是否合法、联系方式是否来自原文；对语义判断，再采用人工抽查或经过校准的评审流程。

不要把低随机性设置当成完全确定性的保证。对关键样本重复运行，观察通过率和波动范围，并记录提示词版本、模型标识与测试日期。这样才能区分偶发偏差与持续退化。

第六步把重试成本与敏感数据纳入发布门槛

最后测试完整失败链路：服务端可能已处理请求，但客户端没有收到结果。此时重试可能增加费用；若后续还会创建工单，应由业务幂等机制防止重复执行，而不是假设每次重试都安全。

BestRelay 按供应商报告的令牌用量随用随付，缓存读取与写入分别计价，因此费用测试应分别记录这些项目，不能只统计请求次数。会员邀请他人充值可获得推荐佣金，但这类账务记录不应混入模型质量评分。

发布前，再确认日志已遮蔽凭证与个人信息，并为通过率、延迟、重试次数和费用设置阈值。最终目标不是证明模型永远答对，而是让失败可识别、影响可限制、变化可追踪。