AI API 返回 200 也可能不可用：响应校验与质量门禁实战指南

传统接口返回 HTTP 200，通常意味着请求成功；大模型接口却可能返回空文本、截断 JSON、拒答说明、与问题无关的内容，甚至把工具参数写成看似合法但无法执行的值。只判断状态码，会把“传输成功”误当成“业务成功”。

更稳妥的做法是在 AI API 与业务之间增加质量门禁。本文聚焦常青工程方法，不依赖具体模型版本、榜单或价格。

四级校验：从便宜到昂贵

不要一上来就调用第二个模型评分。校验应该按成本递增执行，前一层失败就提前结束。

第一级：传输层

检查状态码、内容类型、请求号、流式结束标记和超时状态。对于 SSE，还要区分“正常结束”“客户端取消”“连接断开”和“上游报错”。如果中转站返回 HTML 错误页却标记为 200，内容类型和首段格式检查可以立即识别。

第二级：结构层

需要 JSON 时，用 Schema 校验字段类型、枚举、长度与必填项，而不是只执行 JSON.parse。能解析的对象仍可能缺少业务字段，数字也可能以字符串形式出现。

import { z } from "zod";

const Ticket = z.object({
  category: z.enum(["billing", "technical", "other"]),
  priority: z.number().int().min(1).max(5),
  summary: z.string().min(8).max(300),
});

const result = Ticket.safeParse(JSON.parse(modelText));
if (!result.success) {
  throw new Error("MODEL_OUTPUT_SCHEMA_INVALID");
}

结构错误应保留字段路径和规则编号，但日志中不要直接记录含隐私的完整输出。

第三级：语义层

检查语言、主题相关性、引用是否存在、答案是否包含禁用表达，以及数值关系是否自洽。语义规则应尽可能确定化：例如订单号必须来自输入候选集，引用 ID 必须能在检索结果中找到。不要用“感觉答案不错”替代可执行标准。

第四级：业务层

业务校验决定输出是否可以真正执行。例如退款金额不能超过可退余额，邮件收件人必须属于审批名单，SQL 只能访问只读视图。模型生成参数不应绕过既有权限系统；质量门禁也不能代替鉴权。

把失败分成可修复与不可重试

响应不合格不等于应该原样重试。建议按原因分类：

• 格式可修复：缺少字段、JSON 截断，可向模型返回精简错误提示后重试一次
• 上下文不足：应补充资料或转人工，不要重复同一请求
• 策略拒绝：尊重拒绝结果，不能通过换模型规避安全边界
• 供应商异常：可切换健康路由，但要保持同一业务幂等键
• 业务冲突：例如库存变化，应重新读取权威数据再生成

每次修复都要设置最大次数。无限“让模型再试一次”会同时放大延迟和账单，也可能制造重复副作用。

设计统一的门禁结果

不要只抛出一个模糊异常。统一输出能够帮助监控、回退和产品提示：

type GateResult<T> =
  | { ok: true; value: T; checks: string[] }
  | {
      ok: false;
      stage: "transport" | "schema" | "semantic" | "business";
      code: string;
      retryable: boolean;
      safeMessage: string;
    };

客户端只展示 safeMessage，内部日志保存 code、模型、Prompt 版本、路由和请求号。这样既避免泄露内部规则，也能统计“哪个模型在哪类任务上最常失败”。

多模型回退不能降低标准

常见错误是主模型失败后切换便宜模型，同时跳过原有校验。正确做法是让所有路由通过同一份业务契约；如果模型能力不同，可以调整提示词和字段适配器，但不能降低关键约束。

回退前还要判断任务是否有副作用。内容草稿可以重新生成，发邮件、下单、修改数据库则必须把“生成”和“执行”拆开。模型仅产生提案，质量门禁验证后进入审批或受控执行器。

如何建设回归样本集

线上失败样本是门禁演进的最佳素材，但入库前要脱敏并标注预期。样本集至少覆盖：

• 正常短输入与超长输入
• 空结果、拒答和截断响应
• 中文夹杂代码、表格或特殊字符
• 工具参数越权与不存在的资源 ID
• 中转站超时、重复分片和错误内容类型
• 模型切换后容易发生的字段漂移

每次修改 Prompt、模型、SDK 或中转路由，都运行同一套回归测试。门禁通过率只是一个指标，还应观察误杀率：把正确结果大量拦截，同样会损害体验。

监控哪些指标

建议按模型与任务类型统计结构通过率、语义通过率、修复成功率、平均修复次数、回退率和最终人工接管率。延迟应拆分为首轮生成、校验、修复和回退，避免只看到总耗时却不知道瓶颈。

告警要关联发布版本。如果某个 Prompt 发布后结构错误集中上升，应自动暂停灰度，而不是让值班人员先怀疑网络。

上线检查清单

• 是否把 HTTP 成功与业务成功分开
• 是否使用 Schema 而非手写零散判断
• 是否定义可重试和不可重试错误
• 所有模型路由是否执行同一关键约束
• 有副作用的操作是否经过鉴权与审批
• 是否保留脱敏失败样本用于回归
• 是否能按 Prompt、模型和中转站定位通过率变化

总结

AI API 的稳定性不仅是“能否连通”，还包括输出能否被程序安全消费。通过传输、结构、语义和业务四级门禁，可以让错误在进入用户界面或执行系统前被发现，并为重试、回退和人工处理提供清晰边界。

选择中转服务时，也应测试它是否完整透传错误、结束原因和请求标识。前往 openairouter.net 查看 AI API 中转站对比与排行榜，用真实验收用例比较兼容性与稳定性，而不只是看宣传页上的模型数量。