怎么判断一个 AI API 中转有没有给你降智?六个可复现的探针(2026)
大多数被叫做"降智"的体感,真实原因不是模型被换了,而是请求被改写了:提示词被追加、参数被压低、上下文被截断、协议专有字段被丢弃。这篇给出五种形态对应的探针、可直接复制的 curl 和一页自查清单,最硬的两条各只要几十秒,不看输出质量、只看骗不了人的数字。
1. "降智"的五种形态
先给三条结论。第一条是反直觉的:大多数被叫做"降智"的体感,真实原因不是模型被换了,而是请求被改写了。提示词被追加内容、max_tokens 被压低、上下文被悄悄截断、协议专有字段被丢弃,这四件事任何一件都能让一个完全正确的顶配模型表现得像个便宜货,所以判别的第一步不是比较输出质量,而是比较请求的回声与账本。第二条,降智可测,不是玄学,它有五种形态,每种都有可复现的探针。换模型的症状是明显不是那个档位的水平,用回声加指纹题判别,两三次调用;低精度部署的症状是偶尔犯低级错、长输出后期崩坏,用确定性测试判别,五到十次;上下文截断的症状是长文件问答答非所问,用针尖测试判别,一次就够;参数改写或提示词注入的症状是回答变短、风格变了、拒答变多,用 usage 一致性判别,两次;能力阉割的症状是工具调用不稳、专有字段无效,用工具调用和专有块测试判别,两到四次。第三条,测出异常先别下结论说对方作恶,相当一部分异常来自上游的能力边界或配置失误,怎么区分文章最后讲。这五种的严重程度完全不同,先测出是哪一种,再决定怎么沟通。
2. 探针一:回声测试(30 秒)
发一次非流式请求,把原始 JSON 打出来,看 model 字段是不是你请求的那个,id 的格式是否符合厂商惯例。这条测不出高级伪装(model 字段是可以被改写的),但它能一秒筛掉最粗的问题:模型名写错被回退到默认模型、路由配置指错了目标、返回体被中间层重写。加上 -i 参数把响应头也打出来更好,有的中间层会在头里留下自己的痕迹。做完这一条,你至少知道自己请求的和拿回来的是不是同一个名字,这是后面所有探针的前提;字段对不上,后面的都不用测了,先去核对模型列表里的准确 id 再说。
curl -si https://cocodot.co/api/ai/v1/chat/completions \
-H "Authorization: Bearer 你的-key" -H "content-type: application/json" \
-d '{"model":"你的模型名","max_tokens":32,
"messages":[{"role":"user","content":"只回复:ok"}]}'
3. 探针二:usage 一致性(3 秒,最硬的一条)
把完全相同的请求体连发两次,对比 prompt_tokens(Anthropic 侧为 input_tokens)。两次必须完全相等。不相等,唯一的解释是有人往你的请求里加了每次都不同的内容,比如注入的提示词带了时间戳或会话 id。如果两次相等、但明显大于你自己数出来的量,说明有一段固定内容被稳定追加,差值就是被注入的 token 数。这条探针珍贵在于它完全不依赖主观判断,三秒就能跑完,而且顺带说明一件事:被注入的提示词不但改变模型行为,还在花你的钱。做这条测试时注意两点,一是请求体要一字不差地重发(包括消息顺序和空格),二是别用流式,流式下有的客户端不返回 usage,你会误以为是供应商不给。
4. 探针三:长上下文针尖测试(1 次调用)
造一段五万到六万 token 的填充文本,在大约 30% 的位置插入一句独一无二的口令,例如"紫色犀牛的注册编号是 7391",然后在末尾问"紫色犀牛的注册编号是多少"。三个要点:口令埋在 30% 到 50% 之间,首尾没有诊断价值,那两处即使被截断也答得出来;口令必须是模型猜不到的随机内容;换三个位置各测一次,三次都在中段失败才算数。答不出来,再把材料缩到一万 token 重测:短的能答、长的不能答,就是上下文问题;都不能答,是提问方式的问题。这条探针也是自建网关最该跑的一条,上下文窗口配小了是最常见的自伤,症状和被别人截断一模一样。
5. 探针四:工具调用完整性(2 到 4 次)
工具调用是协议转换中最容易掉字段的地方,而且掉了通常不报错。分三个层次测。基础层:定义一个简单函数,看是否返回 tool_calls、参数是不是合法 JSON。并行层:定义两个函数,提一个同时需要两者的问题,看是否一次返回两个调用,有的转换层只保留第一个。复杂 schema 层:定义一个带嵌套对象、枚举和必填项的结构,看返回的参数是否满足枚举约束,这一层最能暴露"schema 被简化后转发"。最后别忘了把工具结果回传给模型,看它能不能接着往下走,很多问题恰恰出在回传这一半:请求方向的字段都在,回传方向的 tool_call_id 或角色字段被改坏了,表现就是模型开始胡说或者反复重试同一个工具。
6. 探针五和探针六:确定性测试与专有字段是否被静默丢弃
探针五,确定性测试。temperature 设 0,发同一个有唯一答案但需要推理的问题,重复八次,统计答案分布。温度 0 并不保证完全确定(硬件和批处理都有抖动),要看的是分布形状:正确答案占绝大多数属于正常,散成好几种就值得警惕。关键在于纵向对比——接入时跑一次存成基线,以后和自己的基线比,没有基线,单次结果说明不了什么。探针六,专有字段是否被静默丢弃,最少人测,也最能说明链路的本质。原理是:如果中转把 Anthropic 请求翻译成 OpenAI 格式再转发,Anthropic 独有的内容块(缓存标记、文档块)在目标协议里没有对应位置,就会被丢掉;它不报错,照样返回 200,内容看起来正常,只是那部分根本没进模型的输入。自测方法是同一段消息,一次带上专有内容块、一次不带,对比 input_tokens,两次完全一样就说明那部分被丢了,因为它压根没被计入输入。它不依赖对方的任何说明,只依赖一个骗不了人的数字:两次调用就能判断这条链路是原生直通,还是中间隔着一层翻译。
7. 指纹题只能当旁证,想省事就自动化
关于"指纹题",可用的有两类:知识边界题,以及长输出的结构稳定性(要一个 300 行的规整列表,看后半段会不会崩)。不可用的也有两类:问它"你是什么模型",以及靠文风判断,这两样系统提示词都能改。定性还是要靠前面几条数字探针。想省事就自动化:probe.cocodot.co 是一个免费在线检测,填入任意中转的地址和 key 就会跑一组探针输出报告,key 只在本次请求里转发、不落库,不需要注册,也不限定检测对象,测别家、测你自建的网关都行。通用建议是:临时建一把额度很小的 key 专门做检测,测完删掉,这个习惯对所有第三方工具都适用。另外把上面那张自查清单存成文件,每接一个新供应商填一遍,半年后你会感谢自己有这份基线。
8. 测出异常之后怎么办,以及我们这一端
这一节比前面所有探针都重要,因为结论下错了会伤到你自己。先区分三种性质完全不同的原因。一是上游能力边界:上游本身就不提供,中转再努力也变不出来,特征是换任何一家走同一上游的供应商表现都一样。二是配置失误:超时、上下文窗口、默认参数设错了,症状和降智一模一样,供应商自己也常常不知道,特征是说一声就能修好。三才是主动改写,到这一步才涉及诚信,需要硬证据。正确顺序是:先自查自己这一端(contextLength、超时、模型名,这三样出问题的概率比你想象的高),再带着数据去问供应商,别忘了对照组——同一套探针在你自己直连的路径上也跑一遍。关于同行:不同产品的取舍本来就不一样,都是合理选择,前提是说清楚;用户要做的不是站队,是拿到一套自己能验的方法。至于我们这一端,cocodot 是这套方法的适用对象之一,不是例外:API 侧同时提供 OpenAI 兼容端点 https://cocodot.co/api/ai/v1 和 Anthropic 原生端点 https://cocodot.co/api/ai(请求体原样透传,Claude Code 设 ANTHROPIC_BASE_URL 就能直连),usage 如实回传、含缓存字段。六个探针欢迎照样往我们身上跑,尤其是第二和第六个。充值走支付宝,主体是海外注册公司,建议先小额验证再加量。
一页自查清单:每接一个新供应商填一遍
| 探针 | 通过标准 | 不通过通常意味着 |
|---|---|---|
| 回声 | model 字段与请求一致 | 路由到了别的模型,或返回体被重写 |
| usage 一致性 | 相同请求两次 token 完全相等 | 请求被注入了动态内容 |
| 针尖测试 | 六万 token 上下文中段的口令能被复述 | 上下文被截断 |
| 工具调用 | 并行调用正常、复杂 schema 合法 | 协议转换中丢了字段 |
| 确定性 | 与自己的历史基线相比无退化 | 后端部署或精度发生变化 |
| 专有字段 | 带与不带专有块时 input_tokens 有差异 | 中间有翻译层,专有能力被丢弃 |