可靠的人工智能测试，先守住边界再检查答案

第一次给调用人工智能接口的程序写测试，很容易想到一个办法：发出问题，再检查答案是否与预期完全一致。这个办法看似直接，却把两件事混在了一起：你的程序是否正常工作，以及模型这次是否给出了合适的回答。模型措辞可能变化，网络也可能出错，不能把每次失败都归为程序缺陷。

更可靠的起点，是把测试拆成三个层次：先检查自己控制的逻辑，再检查接口能否接通，最后评估回答是否适合业务。三个层次分别设定标准，失败时才容易找到原因。

先用可控的接口替身检查程序是否正确处理结果

测试替身可以理解为一个配合演练的假接口。它不访问真实模型，而是按照测试安排，返回成功结果、空内容或者错误。这样既不产生模型调用费用，也能重复制造平时难以碰到的情况。

假设你在开发客服摘要功能，首先应检查：用户输入是否完整传递，模型标识是否正确，返回内容是否被保存，异常是否被转换成用户看得懂的提示。这些主要是程序责任，不需要依赖模型临场发挥。

替身还应覆盖不顺利的情形。例如，请求超时、访问凭证无效、调用频率受限，以及返回结果缺少必要字段。不要只测试“成功返回一段文字”，否则最容易在上线后暴露的分支，反而没有接受检查。

替身证明的是程序能处理你安排的情形，不是远端接口一定如此工作。如果替身凭空编造了一种响应格式，全部测试通过也可能只是自我安慰。因此，仍需保留少量真实调用。

少量真实调用负责验证请求响应与流式处理边界

真实接口测试的目标应当小而明确：凭证能否使用，请求能否被接受，响应能否解析，以及流式输出能否正确结束。以 Gemini 2.5 Flash 为例，检查实际发送的模型标识，比检查测试名称里写了哪个模型更有意义。

如果程序逐段展示回答，还要检查分段内容能否拼接、用户取消后是否停止处理，以及连接中断时是否保留明确的失败状态。不能因为已经收到几个字，就把整次任务记为成功。

本文由 BestRelay 发布。它以质量为先，按请求指定的模型转发至官方服务，不替换模型，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列，并可配合 Claude Code、Codex、Gemini CLI 和采用 OpenAI SDK 的应用使用。即便接入方式兼容，也仍要测试实际业务所依赖的字段和行为；兼容并不意味着所有模型的能力完全相同。

固定样本与明确评分标准比逐字核对答案更实用

对开放式回答，逐字比较通常过于脆弱。摘要测试更适合检查关键事实是否保留、是否添加了原文没有的信息，以及篇幅是否符合要求。分类任务则可以检查类别是否属于允许范围，再与人工标注对照。

先收集一小组有代表性的输入，包括常见请求、信息不足的请求，以及容易诱导错误的请求。为每个样本写清合格条件，并记录提示词、模型标识和相关参数。以后调整提示词或切换模型，都用同一组样本复测，比较才有依据。

事实准确性和高风险建议不宜只交给另一个模型打分。自动评分可以帮助筛查，但关键样本仍需要人工复核。即使降低随机性设置，也不要承诺每次输出完全一致，更不要把一次通过当成长期保证。

把重试费用与敏感数据也纳入测试的验收条件

重试能缓解临时故障，也可能增加等待时间和费用。测试应确认重试次数有上限，不会反复尝试明显无效的凭证；如果回答会触发发信、付款等操作，还要确认重复请求不会重复执行这些动作。

费用判断应以实际用量记录为依据。BestRelay 按提供方报告的令牌数量按量计费，缓存读取与写入分别计价，因此测试记录不应把不同类型的用量混成一个数字。邀请成员充值可获得推荐佣金，但这与测试是否合格没有关系，不应影响评估结论。

真实调用前，使用虚构或脱敏数据，并设置调用次数和预算上限。日志不要保存访问密钥，也不要默认完整记录用户材料。需要动手练习时，可以创建一个 BestRelay 账户，从少量测试请求开始。

最终，一套适合新手的测试不必庞大：大多数检查由快速、稳定的替身完成，少量真实调用验证接口边界，固定样本负责观察回答质量。每一层都回答一个明确的问题，比单纯追求“所有测试都是绿色”更有价值。