API调用报错400/404？从模型ID到网关路由的排查实战

说实话，看到这个报错组合我一点都不意外，甚至有点亲切。真值表里查得到的模型 ID，偏偏调不通，这种事在我折腾 API 网关和模型路由的这几年里，已经遇到过不下一二十回了。每次碰到这种“列表里有、调用时废”的情况，我心里都清楚：要么是我某个环节配错了，要么就是平台侧的映射关系悄悄变了，只是这次一口气撞上两个不同的状态码，还挺值得拿出来当案例拆一拆的。

我最近干的事，是精心挑了 40 道从易到难的编程题，打算系统性测一轮 kimi 系列模型在代码生成上的真实水平。题目很快就备好了，从 5 位水仙花数、1990 到 2000 之间的素数输出，到循环嵌套、递归回溯、字符串处理，再到 CDN 分发服务器选址这种偏工程建模的题，覆盖面拉得很满。结果第一轮批量调用就翻车——kimi-k2.7-code-highspeed 报 400，kimi-k3 报 404，而这两个 ID 在平台给的模型真值表里都是白纸黑字存在的。

这个经历听起来像个“灵异事件”，但颗粒度拆开之后全是常识。我在本地代理、OpenAI 兼容网关、模型渠道这一条链路里排查了整整一天，最后把原因拆成了几个层次。这篇文章就把整个过程完整梳理一遍，包括错误码的解读、模型路由的机制、参数校验的坑，以及用编程题批量测试模型时真正需要注意的事项。如果你也在折腾 API 调用、网关配置，或者打算批量评测模型的代码能力，这篇应该能帮你省下不少时间。

1. 先把场景讲清楚：40 道编程题撞上的“灵异事件”

1.1 我到底在做什么

这次测试的初衷很简单：我想知道 kimi 系列这几个模型在代码生成场景下，到底是“能用”还是“好用”。网上一堆人说它们强，但“强”不能靠感觉，得有量化结果。所以我按难度阶梯准备了 40 道编程题，大致分布是这样：

• 入门级（10 道）：基本输入输出、条件判断、简单循环，比如输出 1990 到 2000 之间所有的素数，每个素数之间用 tab 分隔；
• 进阶级（12 道）：字符处理、数组操作、模拟题，比如实现一个简易的计算器解析；
• 提高级（10 道）：递归、回溯、动态规划，比如 5 位水仙花数（一个 5 位数，其各位数字的五次方之和等于该数本身）；
• 综合级（8 道）：偏工程和建模，比如 CDN 分发服务器选址问题，要求写清楚算法思路和代码实现。

题目本身没有任何问题，问题出在起跑线上。我写好批量请求脚本，用统一格式把 40 道题逐个发出去，第一轮跑下来，两个目标模型的错误率是 100%。脚本记录里一片红：kimi-k2.7-code-highspeed 返回 400 Bad Request，kimi-k3 返回 404 Not Found。

这里要先说明一下我的调用链路，因为后面所有排查都跟这条链路有关。我没有直连 kimi 官方 API，而是通过本地代理转发到一个统一网关，网关再根据配置把请求路由到对应的上游模型提供商。这种模式在团队里很常见：统一管理 key、统一计费、统一鉴权，还能在多个渠道之间做负载均衡。但也正是因为中间多了一层转发，出问题时的排查范围会比直连大得多。

1.2 两个错误码的初步解读

在动手排查之前，先把 HTTP 状态码本身读懂。这是很多人忽略但非常关键的一步——状态码只告诉你“结果不对”，但不同状态码对应的排查方向完全不同。

400 Bad Request 的意思是：请求本身有问题，服务器能识别你的请求，但认为它不符合要求，拒绝处理。换句话说，网络通了、鉴权大概率也过了、路由也找到了，但在参数校验或者内容校验这一层被拦下来了。这个错误要重点查请求体里的每一个字段。

404 Not Found 的意思则完全不同：服务器找不到你请求的资源。顺着翻译过来就是，网关在整个路由规则里都没有匹配到 kimi-k3 这个模型 ID。这个错误要重点查模型 ID 的拼写、映射规则、渠道挂载关系。

有意思的是，这两个错误同时出现，反而帮了我大忙。因为它们说明问题可能不是一个，而是两套逻辑分别出了岔子。400 大概率是参数或格式问题，404 大概率是路由或命名问题。接下来的排查，就是沿着这两条线分别往上游走。

1.3 排查链路：本地代理 → 网关 → 上游

我的排查习惯是先画链路，再逐层验证。这次调用的完整链路是这样的：

text复制Python 批量脚本
  → 本地代理（负责 API key 注入、请求转发）
    → 统一网关（负责模型路由、渠道调度）
      → 上游模型服务（kimi 系列模型实际运行的地方）

每一层都可能出问题，所以排查时要自下而上逐层确认。第一步是确认本地代理有没有正确转发请求；第二步是确认网关侧收到的模型 ID 到底是什么；第三步是确认上游是否真的接受了这个 ID。

实际操作中，我强烈建议先绕过所有中间层，直接用 curl 带最简单的最小请求体去打网关，把中间层的影响降到最低。如果最小请求也报 400 或 404，那就是网关或上游的问题；如果最小请求通了，再逐步把脚本里的参数加回去，很快就能定位到是哪几个参数闯的祸。这个思路后面每一节都会用到，先记在这里。

2. 模型 ID、真值表与路由机制

2.1 真值表不等于“一定能调用”

先解开第一个迷惑：为什么真值表里有这个 ID，却调不通？

这里有个概念必须搞清楚——平台提供的模型真值表，本质上是一个“模型可见性名单”，它只代表这些模型在当前版本、当前账号权限下是存在的、被支持的。但它不包含任何关于“当前网关是否已配置对应渠道”的信息，也不包含“当前分组下是否有可用渠道”的信息。

打个比方，真值表就像餐厅的菜单。菜单上有“红烧肉”这道菜，但你点单时服务员告诉你做不了，因为后厨今天没进货。你说这不合理？从消费者的角度看确实不合理，但从餐厅的角度看，菜单是总部统一的，后厨备货是门店自己决定的，两者不同步太正常了。

在这个场景里，kimi-k3 在真值表里存在，只能说明平台知道有这个模型。但你的网关可能还没来得及配置它、或者配置了但没挂到当前这个分组下、又或者它只对特定渠道开放。这些都会导致明明“存在”的模型，调用时却 404。

2.2 模型 ID 命名的门道

很多人会在这里踩第二个坑：想当然地用网页版看到的模型名称去猜 API 模型 ID。比如网页版叫“Kimi K2.7 高速代码版”，API 里就写成 kimi-k2.7-code-highspeed？不一定。

模型 ID 是模型在 API 系统中的唯一标识，它受命名规范、部署版本、网关映射三层因素影响。命名规范决定了 ID 的格式，比如小写、连字符、版本号；部署版本决定了同一个模型可能有多个 ID，比如 kimi-k2.7 和 kimi-k2.7-code-highspeed 可能是同一个基础模型的不同部署形态；网关映射则决定了你配置的 ID 最终会被翻译成哪个上游模型名。

这里就引出了一个非常关键的操作要点：别凭记忆写模型 ID，直接从真值表里复制粘贴。 我当时特意确认过，自己用的两个 ID 确实跟真值表完全一致。既然 ID 本身没错，那 404 的锅就不在拼写上，得继续往路由和渠道层面查。

2.3 网关如何把请求路由到正确的上游

网关的路由逻辑，本质上是一张映射表加一套匹配规则。你发来一个请求，网关会提取其中的 model 字段，然后拿这个值去匹配映射表。

匹配过程大致是：

1. 检查模型 ID 是否在全局模型列表里；
2. 检查这个模型当前分组下是否有可用渠道；
3. 按渠道的权重、优先级、健康状态选择一个上游；
4. 将请求转发给上游，并向上游传递模型 ID（可能经过一次重写）。

这个过程中，任何一个环节不满足都会导致请求失败。常见的失败表现有：

• 模型 ID 不在全局列表 → 直接 404；
• 模型 ID 在全局列表，但当前分组下没有渠道 → 可能是 404，也可能是 503；
• 渠道存在但上游不识别这个模型名 → 可能是 400，也可能是 404。

结合我这次的场景，kimi-k3 返回 404，大概率就是卡在了“模型 ID 在全局列表，但当前分组下没有可用渠道”或者“网关根本还没来得及把 kimi-k3 加入路由表”这两条里。

2.4 400 和 404 到底发生在哪一层

总结一下这两个状态码在网关链路里的典型出现位置。

虽然网关和上游都可能产生这两个状态码，但在大多数实现里，网关会尽量把上游的错误原样透传。所以我看到 400 时，第一反应是请求体里某个字段有问题；看到 404 时，第一反应是路由表里没这个模型或没渠道。具体怎么验证，就进入了下一节的实操了。

3. 拆解 400：为什么 kimi-k2.7-code-highspeed 被拒

3.1 400 的典型原因清单

既然 404 的问题出在“找不到”，那 400 的问题就出在“请求不被接受”。根据我这些年的经验，模型接口返回 400 的常见原因有这几类。

第一类是参数格式错误。字段类型不对、必填字段缺失、枚举值不合法，这些问题通常在开发阶段就能发现。比如把 messages 写成了字符串而不是数组、temperature 传了一个字符串类型、role 字段写了个 systemm 这种错别字。

第二类是参数取值范围越界。常见的坑是 max_tokens。我见过有人给推理模型传 max_tokens=64000，结果上游直接返回 400: 'max_tokens' 64000 is out of supported range (0, 4096]。不同模型的上下文窗口和最大输出 token 数都不一样，不能拿一个模型的参数套到另一个模型上。

第三类是功能参数不被上游支持。比如给不支持 function calling 的模型传 tools、给不支持 JSON 输出的模型传 response_format={"type": "json_object"}。这时候网关虽然能识别模型，但模型背后的服务不一定实现了这些功能。

第四类是内容安全校验不通过。模型服务会先对请求内容做一遍安全检测，如果命中风险规则，会直接返回 400 content exists risk。这个一般在调 prompt 时候容易出现，特别是包含特殊字符、注入指令、或者某些被误判的文本时。

第五类是思考模式相关的参数问题。现在很多推理模型都有 thinking 模式，如果你开启了思考模式，但请求或上下文里缺少必要的 reasoning_content，上游会直接拒绝。我就见过一个非常典型的报错：

text复制upstream_status: http 400
cause: the `reasoning_content` in the thinking mode must be passed back to the api.

这是说，在多轮对话里，如果你上一轮开启了思考模式并拿到了模型的思考内容，那么在下一轮请求时，你必须把思考内容原样传回去，否则服务端会认为上下文不完整。这个坑在多轮代码生成任务里尤其容易踩，因为你很可能只保存了最终的回答，而没有保存 reasoning_content 字段。

3.2 流式接口与思考模式：reasoning_content 的坑

这节值得单独拎出来讲，因为我猜很多人踩过这个坑，只是没弄明白原理。现在主流的模型接口同时提供流式（stream）和非流式两种模式。流式模式下，返回的数据是一串 Server-Sent Events（SSE），你需要按行解析 data: 前缀的 JSON。

在公开的非流式响应里，通常长这样：

json复制{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "最终回答",
        "reasoning_content": "模型的思考过程"
      }
    }
  ]
}

重点是，当你把这段响应作为多轮对话的历史再发回给 API 时，有些服务会要求 reasoning_content 必须原样传回。如果你在拼多轮消息的时候只传了 role 和 content，把 reasoning_content 丢了，上游就会报上面那个 400 错误。

我这次批量 40 道编程题，脚本里有个多轮重试的逻辑：第一轮生成代码后，如果编译报错，就把报错信息追加进上下文，让模型自己改。由于我在保存历史消息时做了字段过滤，把 reasoning_content 给滤掉了，结果第二轮请求直接 400。这个错误在日志里是长这个样子的：

json复制{
  "error": {
    "message": "the `reasoning_content` in the thinking mode must be passed back to the api."
  }
}

排查方法很简单：先关掉 thinking 模式，或者先用非多轮请求验证。如果关掉 thinking 模式之后不再报 400，那就锁定是 reasoning_content 传递的问题。

3.3 参数校验：max_tokens、response_format、tools

除了思考模式，这轮 400 还有第三个嫌疑点：参数取值范围。

我这次批量脚本里，给所有模型统一设置了一个比较大的 max_tokens，因为编程题生成的代码通常比较长，我担心默认值不够用。但这个参数在不同模型上的上限不同。有的模型上限是 4096，有的是 8192，有的是 32768。你拿一个很高的值去请求一个上限较低的模型，上游直接给你回 400。

再一个常见问题就是 response_format。我在测试里想让模型稳定输出 JSON 结构，于是给请求加了：

json复制{
  "response_format": { "type": "json_object" }
}

问题在于，并非所有模型都原生支持 JSON mode。如果上游不识别这个参数，它并不会选择“忽略”，而是直接报 400 invalid request parameters。所以对于不支持 JSON mode 的模型，你得把“请以 JSON 格式输出”写进 prompt，而不是靠在接口参数里声明。

tools 参数也是一个高发区。如果你要做 function calling，先确认目标模型在真值表里标注了“支持 tools”。没有标注的不要强行传，传了大概率 400。

3.4 内容安全校验：content exists risk

最后一个 400 原因，是内容安全校验。这个不太好排查，因为它是黑盒的，报错信息只有一句：

json复制{
  "error": {
    "message": "400 content exists risk"
  }
}

这个错误在批量跑代码生成时特别容易误触发。我几次遇到的情况是，prompt 里包含了类似“绕过”“破解”“未授权”这样的字眼，或者代码题目本身涉及了某些敏感主题。虽然从题目设计者的角度看只是正常工程题，但服务端的风险词表可能不理解你的语境，直接一刀切拦下来了。

解决办法是先把 prompt 原文拆成最小片段逐个测试，定位到具体是哪一段内容触发了校验，然后把题目换成同义词描述，或者把场景说得更明确，尽量避开模糊表达。

批量测编程题时，我给自己的一个硬性要求：所有 prompt 先过一遍内容清单，凡是题目里涉及安全边界、危险行为模拟、漏洞利用的，一律不改写直接踢掉。做技术评测没必须平白无故担这个风险。

4. 拆解 404：kimi-k3 为什么“存在但找不到”

4.1 404 的模型路由问题

聊完 400，再来盘 404。kimi-k3 这个 ID 在真值表里存在，但请求返回 404，这种场景我在生产环境里见得非常多，原因基本可以归为以下四类。

第一类是网关的路由表还没更新。平台发了新模型，文档真值表先更新，但网关的配置要人工或定时任务去刷新。如果你配的 ID 是在真值表上线当天就去调用，网关的模型列表里根本没有这个 ID，自然 404。

第二类是模型 ID 的完整版本号不一致。真值表里可能写的是 kimi-k3 的大类名，但实际能用的是带版本后缀的 ID，比如 kimi-k3-0528、kimi-k3-latest。这种不一致在快速迭代的模型里非常常见，网页版和 API 版的命名经常不同步。

第三类是渠道挂载问题。网关里虽然定义了 kimi-k3 这个模型，但没有任何渠道把它映射到上游，或者渠道被禁用了。这就像一个交换机上配好了 VLAN，但这个 VLAN 下没有接任何接口——数据包进来之后根本没有出口。

第四类是上游模型名被重写了。网关在转发请求时，可能把模型 ID 做了映射，但映射的目标在依赖方不存在，就会产生“本地 ID 存在、上游不认”的情况。

4.2 kimi-k3 的发布节奏与命名差异

kimi-k3 这个 ID 的 404，我实际排查下来更倾向于两类原因的组合：一是网关的模型路由表还没来得及同步，二是上游侧对 kimi-k3 这个裸 ID 的处理策略太谨慎。

这里普及一下模型服务方的常见策略。很多模型服务在上线新模型时，会先用一个带后缀的 ID 灰度发布，比如 kimi-k3-xxxx，等稳定运行一段时间后再开放 kimi-k3 这种无后缀别名。如果无后缀的别名还没开放，你直接请求 kimi-k3，上游就会返回模型不存在的 404。

还有一种情况是 AB 版本切换。今天 kimi-k3 可能指向 v1 版本，明天平台把它切换到 v2，但网关侧缓存的模型列表还是旧信息，就会导致请求在新的路由规则下找不到对应处理逻辑。

所以我每次调新模型，都会做个三连操作：第一步看真值表，确认 ID；第二步去 AP I playground 或网页端手动试一次，确认模型真的可用；第三步再看网关配置，确认路由和渠道都到位了。三步全过再写进批量脚本，能省掉很多无效排查时间。

4.3 分组与渠道：模型存在但无可用渠道

还有一个很容易被忽略的因素：分组。我在前面提到过，自己的调用是经过统一网关的，而网关一般有“分组”概念。同一个模型 ID 可能只被挂载到了某个分组下面，而你的 API key 所属的分组不在其中。

这种场景下的报错信息非常典型：

text复制unexpected status 503 service unavailable:
当前分组 default 下对于模型 kimi-k3 无可用渠道

但有些网关实现会把这种“分组下无渠道”的情况统一映射成 404，导致你看到的是 404 Not Found，而不是真正的 503 Service Unavailable。这也是为什么我建议你不要只看状态码，还要检查网关返回的响应体——响应体里往往藏着更具体的错误信息。

排查思路是：先用一个已知可用的模型 ID 测试同一把 API key，确认分组链路是通的，再单独确认目标模型的渠道挂载情况。如果已知模型能通、目标模型不通，那问题范围就能从“全链路”缩小到“目标模型的渠道和相关配置”。

5. 用 40 道编程题正确验证模型能力

5.1 题目设计：从水仙花数到 CDN 选址

等两个模型的问题都定位清楚之后，我重新把 40 道题完整跑了一遍。这里也想说说题目设计的思路，因为很多朋友问我“测模型代码能力到底该用什么样的题”。

我的经验是：不要只出算法题，更不要只出“能不能跑通”这种极端简单的题。一份合格的评测题集，应该覆盖多个能力维度。

基础语法题考的是模型对语言特性的掌握程度，比如 5 位水仙花数、素数输出，这些题虽然简单，但能快速检验模型输出的代码是否“一次性正确”。逻辑思维题考的是模型对复杂逻辑的组织能力，比如递归、回溯、贪心，这类题容易出现隐藏 bug，适合检验模型代码的鲁棒性。工程建模题考的是模型把实际问题抽象成代码的能力，CDN 分发服务器选址这种题目就很典型，它需要模型理解图论里的选址问题，然后转化为可运行的代码。边界与异常处理题则是很多模型翻车的高发区，空数组、极端数值、非法输入这些情况，模型经常意识不到。

40 道题不是随便凑数的，每一道题对应一个考察点，最后我才能根据每道题的通过情况，画出一张模型能力的雷达图。这样测下来，比丢一道“写个贪吃蛇”有意义得多。

5.2 批量请求脚本的关键参数设置

题目准备好之后，批量请求脚本的参数设计就是重头戏了。这里贴出我实际用的最小参数模板：

python复制import requests

payload = {
    "model": "kimi-k2.7-code-highspeed",
    "messages": [
        {"role": "user", "content": "请用 Python 实现：一个 5 位数，其各位数字的五次方之和等于该数本身，输出所有满足条件的数。"}
    ],
    "max_tokens": 4096,
    "temperature": 0.2,
    "stream": False
}

resp = requests.post("http://your-gateway/v1/chat/completions", json=payload, headers={"Authorization": "Bearer YOUR_KEY"})
print(resp.status_code, resp.text)

有四个关键点，逐个说：

第一，先关掉流式。批量测试阶段用非流式，逻辑更简单，错误信息也更完整。流式模式适合交互式场景，不适合跑评测。

第二，temperature 设低一点。代码生成场景我一般用 0 到 0.3，太高会导致模型输出不稳定，明明会做的题因为随机性写错。

第三，max_tokens 要根据模型的实际上限调整。在不确定的情况下，先查文档，或者先用一个较小的值测试，看返回是否正常。我这次的 400 教训就来自这里。

第四，多轮重试时要保留完整的消息历史。如果我让模型自己改 bug，那么第二轮请求必须带上第一轮的完整响应，包括 reasoning_content（如果存在）。代码生成任务里，我通常用一个简化策略：除非必要，不开 thinking 模式，减少参数传递的复杂度。

5.3 结果评估：跑测试用例而不是肉眼看

40 道题跑完之后，结果评估也是一个学问。很多人在网上晒“模型 40 题全对”，我心想你确定是全对？有些看着对的代码，换个输入就崩了。

我评估结果的策略是：每道题除了给模型一个 prompt，还内置了 3 到 5 组测试用例。模型生成的代码会被保存到文件，然后自动执行测试用例，用 stdout 输出比对结果来判断是否通过。这样比肉眼读代码可靠得多。

举个例子，那道“输出 1990 到 2000 之间所有的素数，每个素数之间用 tab 分隔”，我不会只看模型有没有写出素数判断逻辑，而是直接运行程序，检查输出是不是 1993\t1997\t1999（注意，1990到2000之间实际上只有3个素数，如果模型输出的结果里多了1991或1999之外的数字，直接判定失败）。这种运行级验证才能真实反映代码质量。

测试用例设计上尽量覆盖三类：标准输入、边界输入、非法输入。比如水仙花数那题，我会额外测一个不存在水仙花数的范围，保证程序不会死循环或报错。模型生成的代码如果连边界用例都过不了，那在实际工程里就是不可用的。

5.4 我还踩过的两个小坑

批量测试中，我还踩过两个值得提醒的坑。第一个是 API key 暴露在脚本里。因为是本地测试所以我无所谓，但如果你的脚本要提交到仓库，一定要用环境变量或者密钥管理工具，别硬编码。第二个是限流。40 道题并发请求，很容易触发服务端的速率限制。我是用了一个简单的信号量控制并发数，把并发控制在 4，同时加了一个指数退避重试，避免一道题因为限流而误判为失败。

限流重试的伪代码大致是这样：

python复制import time

def request_with_retry(payload, max_retries=3):
    for attempt in range(max_retries):
        resp = requests.post("/v1/chat/completions", json=payload)
        if resp.status_code == 429:
            wait = 2 ** attempt
            time.sleep(wait)
            continue
        return resp
    return resp

别小看这步，批量评测最怕的就是上游 429 被误读成“模型答错”，导致最终统计失真。

6. 错误码排查速查与避坑清单

6.1 状态码速查表

几个常见状态码和排查方向整理成表，方便大家直接抄作业：

其中 400 和 404 最容易混淆，我的判别方法很简单：先看响应体里面的详细错误信息。如果响应体里包含 model not found、no available channel 这类字眼，问题就在路由和渠道层；如果响应体里包含 invalid parameter、out of supported range、content exists risk 这类字眼，问题就在参数和内容层。

6.2 排查顺序与避坑经验

最后总结一套省时省力的排查顺序，这算是我踩了无数次坑之后沉淀下来的套路。

第一步，核对模型 ID。从真值表里复制粘贴，别手输，别用旧文档里的 ID，别用网页版名称猜 API 名。这步 30 秒能完成，能排除掉 80% 的 404。

第二步，用最小请求体测试。只带 model 和 messages，什么都不加。如果最小请求能通，再逐步加 temperature、max_tokens、tools、response_format，每加一个就重新测一次。谁引发的 400 立刻现形。

第三步，检查多轮上下文。如果单轮没问题、多轮报错，优先检查 reasoning_content 是否保留、历史消息是否完整。

第四步，查网关渠道。如果确认模型 ID 无误、参数无误，但仍然 404 或 503，就去查网关里的渠道配置和分组挂载。同时看一眼模型的真实调用文档，确认无后缀别名是否已经开放。

第五步，做一次直连对比。如果条件允许，直接把同一个请求发到上游服务，绕过中间网关。这能帮你区分是网关的问题还是上游的问题。

关于直连，我多说一嘴。在排查阶段，直连是定位问题的最快手段，但生产环境还是建议走统一网关，方便做鉴权、限流和审计。别因为一次排查就把架构推倒重来，先把问题定位清楚再谈方案。

写到最后的一点体会

这次因为 40 道编程题把 kimi-k2.7-code-highspeed 的 400 和 kimi-k3 的 404 翻了个底朝天，虽然过程折腾，但收获其实是正的。现在我调试模型接口反而更顺手了——先核对 ID、再做最小化请求、再逐层加参数，已经成了肌肉记忆。

我个人在实际操作中的体会是，API 报错跟程序 bug 很像，状态码只是入口，藏得最深的往往在响应体、在中间层、在命名映射这些不起眼的地方。你越是觉得“真值表里明明有，怎么会 404”，就越要耐住性子逐层拆。模型迭代越快，这类“ID 存在但不可用”的情况只会越来越多，学会一套系统排查法，比记住某个具体模型的可用状态要值钱得多。

如果后面再出新模型，不妨也准备这么一组从水仙花数到 CDN 选址的题去批量跑一遍。配置虽然要折腾，但拿到手的那张“能力雷达图”，会让你对模型的真实水平心里有底。