结论先说： 检测报告的总分是“接口综合兼容度”，不是模型智力分，也不是官方身份概率。阅读顺序应该是先看模型声明，再看失败证据，最后才看总分。
打开检测工具后建议选择标准模式。标准模式会增加 SSE、工具调用、输出风格和知识边界采样，因此更适合接入前检查。
报告应该按什么顺序看
1. 被检地址和请求模型
先确认 Base URL 和模型 ID 没有填错。常见错误包括重复追加 /v1/v1、把展示名称当作模型 ID，或者填写到 /chat/completions 具体路径。
2. 请求模型与响应模型
一致表示本轮接口声明一致；不同表示可能存在别名、版本解析或路由差异。两者都不能单独证明底层身份，需要继续看能力和元数据。
3. 分项状态
| 状态 | 含义 | 建议动作 |
|---|---|---|
| 通过 | 本次探针满足预期 | 加入业务题集继续验证 |
| 存疑 | 有结果但存在结构或一致性问题 | 查看证据并复测 |
| 失败 | 关键协议或能力未满足 | 先排查配置，再联系服务商 |
| 观察 | 弱信号，不计入兼容度 | 仅用于多轮趋势对比 |
| 无结果 | 上游未返回可判读内容 | 检查权限、限流、超时与协议范围 |
| 未执行 | 当前模式没有运行该项 | 需要时改用标准模式 |
4. 总分和业务影响
高分表示协议和关键探针更完整，不代表生产环境稳定。低分也不一定代表模型是假的，可能是目标端点只实现了部分兼容协议。
应根据业务决定权重：普通问答更关注基础协议和流式输出；Agent 更关注工具调用；成本敏感项目更关注 usage 完整性；生产系统还要单独测试延迟、并发、错误率和限流。
九项检测分别说明什么
- 协议层合规： 认证、状态码和 Chat Completions 结构是否可识别。
- 固定指令遵循： 能否原样返回随机字符串，独立观察约束遵循。
- 元数据指纹：
id、object、created、model和请求 ID 是否完整。 - 计费 Token： 输入、输出和总 Token 是否可用且算术一致。
- 输出风格： 段落、标题、列表和代码围栏等弱特征，只用于对照。
- 知识 cutoff： 模型自述的知识边界，属于容易被改写的弱信号。
- R1 动态题： 使用随机参数和 nonce 进行能力抽样。
- SSE： 流式事件、增量内容和结束标记是否兼容。
- 工具调用： 函数名、JSON 参数和随机值是否按要求返回。
如何公平比较两个中转站
- 为两个站分别创建临时限额 API Key。
- 选择同一模型系列和同一检测模式。
- 尽量在相近时间、相同网络环境执行。
- 每个端点至少重复三轮。
- 记录模型声明、失败项、Token、耗时和业务题集结果。
- 比较证据，不要只比较一次总分。
如果两个服务商使用不同的模型别名，应先向各自控制台确认实际映射。无法确认时，在报告中标记为未知，不要自行补全结论。
什么情况应立即停止接入
- API Key 或敏感信息可能被记录、暴露或经非 HTTPS 传输。
- 认证、模型路由或计费数据持续异常且服务商无法解释。
- 业务必需的工具调用、流式输出或结构化结果反复失败。
- 同一条件下结果持续漂移，且缺少可追踪请求 ID 或售后响应。
这些条件关注的是可用性、透明度和安全边界，不依赖“是否能百分百鉴真”。
报告不能代替什么
检测报告不能代替厂商签名、供应链审计、合同与隐私条款，也不能预测未来稳定性。生产上线还需要持续监控延迟、错误率、限流、路由变化和账单一致性。
下一步
先阅读模型降智的可重复检测方法，再用固定业务题集补充报告。发现模型声明不一致时，查看套壳与路由替换风险排查。