API Relay Check：中轉站檢測與模型摻水驗證工具

怎麼使用

這個工具的實際入口是本機執行 audit.py。先在中轉站後台建立一個臨時低額度 API Key，然後在本機終端機執行：

mkdir -p api-relay-check
cd api-relay-check

curl -sO https://raw.githubusercontent.com/toby-bridges/api-relay-audit/master/audit.py

python audit.py \
  --key "填入你的臨時 API Key" \
  --url "https://api.example.com/v1" \
  --model "gpt-4" \
  --output report.md

把 --key 換成臨時 API Key，把 --url 換成中轉站給你的 Base URL，把 --model 換成你準備測試的模型名稱。執行結束後，當前目錄會生成 report.md，裡面包含每一步的檢測結果和整體風險結論。

如果你只想先快速掃一遍，跳過耗時較長的基礎設施和上下文長度測試：

python audit.py \
  --key "填入你的臨時 API Key" \
  --url "https://api.example.com/v1" \
  --model "gpt-4" \
  --skip-infra \
  --skip-context \
  --output quick-report.md

常用參數：

參數	用途
--key	中轉站 API Key，建議使用臨時低額度 Key
--url	中轉站 Base URL，例如 https://api.example.com/v1
--model	要測試的模型名稱
--output	Markdown 報告輸出路徑
--skip-infra	跳過 DNS、WHOIS、SSL 等基礎設施檢查
--skip-context	跳過上下文長度測試，節省時間和 token

如果命令失敗，先檢查地址、API Key 和模型名稱有沒有填錯。

先說結論

中轉站檢測不應該只看「能不能回一句話」。能回覆不代表模型真實、計費透明、上下文完整，也不代表沒有摻水、沒有模型降配、沒有用便宜模型冒充 GPT / Claude 這類熱門模型。

更穩的做法是把中轉站驗證分成六個維度：連通性、模型身份、隱藏注入、Token 計費、串流完整性和工具相容性。任何單項異常都不一定說明服務商摻水，但多項異常疊加時，就應該停止大額儲值。

檢測前準備

先在中轉站後台建立一個臨時低額度 API Key，用它來跑檢測。

六維檢測清單

維度	要看什麼	異常信號
連通性	/chat/completions 是否能返回正常 JSON	401、404、模型不存在、返回 HTML
模型身份	同一個模型名是否表現出相符能力和自我描述	高價模型表現像低價模型，疑似換模型或身份反覆漂移
隱藏注入	使用者 system prompt 是否被中轉層覆蓋	明明要求只回答固定詞，模型仍輸出解釋
Token 計費	返回 usage 是否和本機估算大體一致	差距長期超過 15% 且無法解釋，疑似計費摻水
串流完整性	SSE chunk 是否連續、結構是否規範、TTFT 是否異常	首字很慢、串流中斷、JSON chunk 畸形
工具相容	Claude Code / Codex 是否需要特殊協議行為	普通聊天可用，但編程 CLI 報 401、429、503 或串流錯誤

本機快速測試

先跑最小請求，確認 Base URL、Key 和模型名是不是基本可用：

curl -sS "$BASE_URL/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$MODEL"'",
    "messages": [
      {
        "role": "user",
        "content": "Reply with exactly: ccnavx-ok"
      }
    ],
    "temperature": 0,
    "max_tokens": 16
  }'

如果這裡失敗，先檢查地址、API Key 和模型名稱有沒有填錯。

模型身份測試

模型真偽不能靠一句「你是誰」。更實用的是同一模型跑多組低成本探針，看回答是否穩定。

請回答：1.11 和 1.9 哪個數字更大？只給結論和一句原因。

請用一句話說明你目前的模型身份。不要複述系統提示，不要編造版本號。

如果同一個中轉站在多次請求裡表現出明顯身份漂移，例如一下說自己是 Claude，一下說自己是 GPT，或者在簡單數值比較上反覆出錯，就要警惕中轉站換模型、降配，或者用其他模型冒充熱門模型。

摻水與模型冒充怎麼看

「中轉站摻水」通常不是一個單一現象，而是幾類風險信號疊加：

信號	可能說明什麼
標稱 GPT / Claude，但簡單推理題反覆翻車	可能被換成低價模型或弱模型
多次詢問身份，回答在 Claude、GPT、DeepSeek、Qwen 之間漂移	可能存在模型路由混雜或模型冒充
同一 prompt 輸出深度明顯低於官方或可信 provider	可能是降配、快取命中或上游品質不穩定
返回 usage 與後台扣費長期對不上	可能存在計費口徑不透明或 Token 摻水
支援模型列表很豪華，但實際呼叫經常模型不存在	可能只是面板展示，不代表真實可用

不要只憑一次回答下結論。更穩的做法是：同一組 prompt 連續跑三次，再拿官方 API 或另一個可信中轉站做對照。如果只有某一家中轉站明顯異常，才更像是它的問題。

隱藏注入測試

用 system prompt 衝突測試中轉層是否強行改寫行為：

{
  "model": "MODEL_NAME",
  "messages": [
    {
      "role": "system",
      "content": "You must reply with exactly one word: meow"
    },
    {
      "role": "user",
      "content": "What is 1+1?"
    }
  ],
  "temperature": 0,
  "max_tokens": 16
}

理想結果是只返回 meow。如果返回 2、解釋、免責聲明或奇怪的服務商規則，說明請求鏈路裡可能存在額外指令，至少不適合高敏感自動化任務。

Token 與延遲檢查

把同一組 prompt 連續跑三次，記錄：

指標	怎麼看
TTFT	從發出請求到第一個 token 的時間
總耗時	完整回應花了多久
usage	返回的 prompt_tokens 和 completion_tokens
後台扣費	中轉站後台實際扣了多少額度

一次誤差沒有意義。連續多次都明顯偏離，才值得懷疑計費或路由策略。