Claude和国内大模型怎么排查，步骤和注意事项

用 Claude 或国内大模型干活，突然变慢、答非所问、报错、或者怀疑被换成了便宜模型——这类问题最容易瞎猜，换模型换半天也不见好。这篇把排查拆成几步：先分清是链路问题、账号额度问题还是模型本身的问题，再按清单往下查，最后给出什么情况下该停手、什么情况下才值得换。

用 Claude 或国内大模型干活，最烦的不是它一开始就不好用，而是本来跑得好好的，突然变慢、答非所问、报错，甚至怀疑自己调用的模型被悄悄换成了便宜货。这时候最常见的反应是瞎猜，换模型换半天，问题可能根本不在模型身上。

下面把排查拆成几条线：先分清是链路、账号额度还是模型本身的问题，再按清单逐项往下排除，最后说清什么情况该停手、什么情况才值得换。全程只给判断标准和动作，不给你绝对结论，因为同样的现象在不同项目里成因可能完全不同。

先定位在哪一层出的问题，别急着换模型

出问题先别动模型配置，把现象分到四层里：网络与网关、账号与额度、模型与版本、提示与上下文。同一份提示词在网页版正常、走接口就不正常，基本能锁定在链路或参数层，而不是模型变笨了。分层的目的不是严谨，是省时间——层定错了，后面每一步都是白测。

1. 做一次最小复现用短提示、单轮、纯文本请求跑一次。这个也挂，说明问题在链路或账号层，别往下测业务逻辑；这个正常，再上真实提示词。
2. 把「慢」和「错」拆开慢就看延迟基线，连续发几次短请求记录耗时分布；错就看输出内容，判断是答非所问、格式崩了还是硬报错。两者混在一起查，会互相干扰判断。
3. 记录可复现条件能稳定复现的才叫问题；偶发一次的先记下时间点、请求内容和返回，攒够样本再下结论，别拿单次异常当证据。

Claude 一侧和国内大模型一侧，分别查什么

两条线要查的重点不一样。Claude 这条线容易出问题的地方在中间层和长度限制；国内模型这条线更容易卡在兼容格式、模型名有效性和内容安全拦截上。逐项过一遍，比凭感觉换模型靠谱。

判断标准很简单：能写进复现步骤、换个人照做也能重现的，才是需要处理的；偶发的一律先归档观察。两边都查完还是定位不了，再去看是不是账号层面的问题。

排查顺序：按成本从低到高走

顺序错了，排查就变成折腾。原则是迁移成本最低的先动：换通道不换模型、换模型不换任务、换参数不换模型，最后才考虑换供应商。每动一步只改一个变量，否则出了结果也不知道是谁的功劳。

• 第一步换通道不换模型：同一个模型名换一条链路请求，最快分辨是模型的问题还是通道的问题
• 第二步换模型不换任务：同一份任务换一个价位相近的模型跑，看结果差异是否在可接受范围
• 第三步换参数不换模型：调低温度、缩短上下文、去掉多余系统提示，很多「变傻」其实是参数闹的
• 最后一步才换供应商：迁移成本最高，不该最先动，换之前先有基线数据
• 硬约束情况反着来：数据不能出内网这类限制下，从通道限制开始查，别先折腾模型

每步做完都回到同一个最小复现用例上验证，不要换着用例测。用例一变，结论就没法比，你只是在制造新的不确定性。

什么情况下该停手，什么情况下才值得换

排查最怕没有终点。两种典型情况要分清：一种是问题只在高并发或极端长文本下出现，你已经接受这个边界，继续查的收益低于成本，那就停手并写进项目说明；另一种是同类任务反复验证同一模型持续不达标，换一个模型能明显改善，才值得动。

换之前必须先有基线，没有基线你换完也不知道是不是真的变好。至少记三项：延迟、单次任务成功率、人工返工次数。这三项在换之前测一遍，换后再测一遍，比感觉靠谱得多。

换模型是最后手段，不是第一反应；先证明问题在模型身上，再换。