结论先说： 检测报告的总分是“接口综合兼容度”，不是模型智力分，也不是官方身份概率。阅读顺序应该是先看模型声明，再看失败证据，最后才看总分。
打开检测工具后建议选择标准模式。标准模式会增加 SSE、工具调用、输出风格和知识边界采样，因此更适合接入前检查。
Link 在线检测覆盖什么协议
Link 当前网页工具只对公开 HTTPS OpenAI Chat Completions 兼容入口执行固定探针：读取 /models，并调用 /chat/completions。可检测 GPT、Claude 与 Gemini 通过该兼容入口暴露时的表现；这不等于检测了 OpenAI Responses、Anthropic Messages 或 Gemini generateContent 原生协议。模型品牌、价格或月卡适用范围不会改变检测器的协议覆盖范围。
在线兼容性检测与统计指纹不是同一种方法
当前网页工具以少量固定协议和行为探针筛查兼容性，包括模型声明、可见响应字段、Token、动态题，以及标准模式中的 SSE 与工具调用。报告中的“可见元数据交叉核对”检查 id、object、created、model 和请求 ID 等字段；这些字段不是加密签名，可能被网关改写。Token/提示字符比值是本次请求的单次观察值，受语言、提示词和序列化文本影响，不用于推断分词器或模型身份；输出风格也只记录当前样本，不自动跨次比较。
单 token 输出分布研究通过多轮短回答建立经验分布，再与可信参考端点比较，例如使用 Jensen-Shannon divergence 衡量分布差异。该方法需要可信参考、足够样本，以及一致的题目、语言、系统提示和采样参数。
另一项留出集研究考察的是多段受控文本的 prompt-token-count 序列，而非单次 Token/提示字符比值。其 12 组预设留出样本中只有 6 组满足有效比较条件，样本不足以支持把 Token 数当作通用模型家族识别依据；这也不是对本站比值字段的直接验证。
GitHub 上的 lm-detector 是另一类数字序列方法。2026-10-18 的更新在闭集排名前增加形态预筛，检查相邻数字的一阶自相关和相邻差绝对值不超过 20 的比例，并以有效回答的中位数与项目参考库校准的阈值比较。其文档要求三条回答、每条至少 80 个有效整数；触发筛查时不给排名和置信度。阈值仅适用于该项目的数字任务与参考库，不能搬到其他题集，也不是模型身份认证。AIFast Link 未集成该预筛、单 token 分布算法、参考数据或判定阈值；外部论文和工具结果不代表本站实测能力。
需要用统计指纹作补充时，至少应：
- 记录可信参考和待测端点各自的模型来源、精确 ID/版本、Base URL、工具版本与采样时间。
- 对齐题集、语言、系统提示、温度等条件；保存有效样本量、无效响应和脱敏原始结果。
- 只在相同协议与方法版本下比较经验分布，不跨题集套用距离阈值，也不把单次不匹配说成造假。
- 在另一个时段复测，并排查模型更新、系统提示注入、量化和动态路由等其他解释。
| 接口类型 | Link 在线检测 | 说明 |
|---|---|---|
| OpenAI Chat Completions 兼容接口 | 支持固定探针 | GPT、Claude、Gemini 需由目标服务按兼容接口提供。 |
| OpenAI Responses 原生接口 | 不覆盖 | 需按 Responses 请求与事件结构单独验收。 |
| Anthropic Messages 原生接口 | 不覆盖 | 兼容层调用不能替代 Messages 原生协议验收。 |
Gemini generateContent 原生接口 |
不覆盖 | Gemini 兼容入口与 Google 原生接口属于不同范围。 |
Link 检测结果与月卡账单怎样对照
检测 Link 时，保存所选模型、分组与计费偏好，再运行少量请求。通过协议检查不代表该模型属于你购买的月卡范围；应在订阅页确认适用分组，并在使用日志确认这次请求实际消耗哪类额度。
日额度用尽后，有的套餐允许使用钱包余额。报告中的 Token 数和成功次数无法单独证明本次调用免费或已经包含在月卡内；成本判断应同时保留用量日志中的扣费记录。
报告应该按什么顺序看
1. 被检地址和请求模型
先确认 Base URL 和模型 ID 没有填错。常见错误包括重复追加 /v1/v1、把展示名称当作模型 ID，或者填写到 /chat/completions 具体路径。
2. 请求模型与响应模型
一致表示本轮接口声明一致；不同表示可能存在别名、版本解析或路由差异。两者都不能单独证明底层身份，需要继续看能力和元数据。
3. 分项状态
| 状态 | 含义 | 建议动作 |
|---|---|---|
| 通过 | 本次探针满足预期 | 加入业务题集继续验证 |
| 存疑 | 有结果但存在结构或一致性问题 | 查看证据并复测 |
| 失败 | 关键协议或能力未满足 | 先排查配置，再联系服务商 |
| 观察 | 弱信号，不计入兼容度 | 仅用于多轮趋势对比 |
| 无结果 | 上游未返回可判读内容 | 检查权限、限流、超时与协议范围 |
| 未执行 | 当前模式没有运行该项 | 需要时改用标准模式 |
4. 总分和业务影响
高分表示协议和关键探针更完整，不代表生产环境稳定。低分也不一定代表模型是假的，可能是目标端点只实现了部分兼容协议。
应根据业务决定权重：普通问答更关注基础协议和流式输出；Agent 更关注工具调用；成本敏感项目更关注 usage 完整性；生产系统还要单独测试延迟、并发、错误率和限流。
十项检测分别说明什么
- 认证与模型列表： Bearer Key 是否通过认证、
/models是否返回可识别目录，以及所选模型 ID 是否可见；目录受限不等于模型造假。 - 协议层合规： Chat Completions 状态码、响应 JSON 和关键字段是否可识别。
- 固定指令遵循： 能否原样返回随机字符串，独立观察约束遵循。
- 可见元数据交叉核对：
id、object、created、model和请求 ID 是否存在或一致；不具备签名验证能力。 - 计费 Token 字段： 输入、输出和总 Token 是否可用且算术一致。
- 输出风格特征： 记录本次回答的段落、标题、列表和代码围栏等弱特征；工具不自动比较历史样本或可信基线。
- 知识 cutoff 边界： 模型自述的知识边界，属于容易被改写的弱信号。
- R1 动态题： 使用随机参数和 nonce 进行能力抽样。
- SSE 流式输出： 流式事件、增量内容和结束标记是否兼容。
- 工具调用： 函数名、JSON 参数和随机值是否按要求返回。
教学示例：短请求成功，但流式输出未正常结束
以下是为解释报告而构造的假设场景，不是 Link 或任何服务商的实测结果，也不是模型真伪鉴定。
| 假设报告中的证据 | 合理解释 | 不应得出的结论 |
|---|---|---|
| 模型列表可读，短请求返回 JSON | 这两项基础请求可用 | 所有客户端与高级能力都兼容 |
| 请求与响应的 model 字段相同 | 本轮接口声明一致 | 底层一定是厂商官方模型 |
| SSE 有增量文本，但缺少预期结束事件 | 流式链路需要复测，保留最后事件和错误 | 一定是模型降智或身份造假 |
| 工具调用显示未执行 | 本次没有该项证据 | 工具调用通过或失败 |
| 返回 usage，但没有账单记录 | 只能核对响应中的用量字段 | 本次免费、一定扣钱包或一定属于月卡 |
遇到类似情况，先记录客户端版本、所选模型与分组、最终路径和脱敏错误；用相同输入分别复测非流式与流式请求，再核对用量日志。若 SSE 仍异常，继续阅读流式断连排查。
如何公平比较两个中转站
- 为两个站分别创建临时限额 API Key。
- 选择同一模型系列和同一检测模式。
- 尽量在相近时间、相同网络环境执行。
- 每个端点至少重复三轮。
- 记录模型声明、失败项、Token、耗时和业务题集结果。
- 比较证据，不要只比较一次总分。
如果两个服务商使用不同的模型别名，应先向各自控制台确认实际映射。无法确认时，在报告中标记为未知，不要自行补全结论。
什么情况应立即停止接入
- API Key 或敏感信息可能被记录、暴露或经非 HTTPS 传输。
- 认证、模型路由或计费数据持续异常且服务商无法解释。
- 业务必需的工具调用、流式输出或结构化结果反复失败。
- 同一条件下结果持续漂移，且缺少可追踪请求 ID 或售后响应。
这些条件关注的是可用性、透明度和安全边界，不依赖“是否能百分百鉴真”。
报告不能代替什么
检测报告不能代替厂商签名、供应链审计、合同与隐私条款，也不能预测未来稳定性。生产上线还需要持续监控延迟、错误率、限流、路由变化和账单一致性。
下一步
先阅读模型降智的可重复检测方法，再用固定业务题集补充报告。发现模型声明不一致时，查看套壳与路由替换风险排查。