前段时间一直在折腾 LMSpeed

它原来主要是用来测 LLM API 速度的

但我后来发现，中转站最麻烦的地方，往往不在速度

真正麻烦的是，你以为自己在调用 Claude ，实际上中间层可能改了请求，截了上下文，换了上游，甚至让 system prompt 失效

这些问题平时很难发现

因为你随便问一句，它还是会正常回答

这就很烦。。。

所以我给 LMSpeed 加了一个新功能中转站检测

Demo 报告在这里 👉 https://lmspeed.net/zh/audit/NJyPLRp4mGHMeXoT

Demo 报告解读

这次报告测的是一个 claude-opus-4.6 中转接口

LMSpeed 会帮你看这些东西

• 模型是不是你以为的那个模型
• system 指令有没有被中间层盖掉
• 长上下文有没有真的送进去
• Prompt 会不会被套出来
• 错误里有没有泄漏 Key 、环境变量、内部路径
• 工具命令、钱包签名这类危险场景有没有异常
• 延迟是否稳定，避免只看偶发高峰

这份样例里，接口和流式返回都正常

但有三个明显风险

• system 指令没守住
• 50000 字符 canary ，一个都没找回
• 延迟从 0.322s 到 5.382s，波动比较大

如果只是普通聊天，这些问题可能不明显

但如果你把它接到 Claude Code 、Cursor 、Codex ，或者让它读私有文档和代码库，就不一样了

这也是我做这个检测的原因

它会先告诉你快不快

更重要的是告诉你这条链路能不能信

什么时候该测一下

如果你只是偶尔聊天，可能不用这么紧张

但如果你在用中转站跑这些东西

• Claude Code
• Cursor
• Codex
• 自己写的 agent
• 会读私有文档的工作流

那我建议先用一个低额度，随时能撤销的测试 Key 跑一次 👉 去跑一次中转站检测

后续我还会继续把这块做细一点