控制台总览

API 负责把请求发出去，控制台负责让接入过程可管理、执行状态可追踪、资源消耗可核对。

先建立一个判断： 接口报错不一定只查代码。鉴权、模型可用性、异步任务状态和额度问题，往往需要回到控制台确认真实状态。

一套完整的运营视图

控制台如何支撑一次稳定接入

接入准备凭证与模型确认谁能访问、可以调用什么

业务执行请求与任务观察调用是否收到、执行和完成

持续运营用量与账单核对消耗、额度和费用记录

这三层不是彼此独立的页面。一次请求使用某把 Key 和某个模型；如果它是异步能力，会形成任务状态；执行后又会产生用量和费用记录。排查时把这些信息按时间和调用来源串起来，通常比只盯着一条错误消息更有效。

确认名称能说明应用和环境，并检查它没有过期、禁用或触达单 Key 额度。若仍未创建凭证，先完成 API Key 创建。

不要只从示例代码中猜模型名。调用前应确认账号当前能看到并使用该模型，复制时保留准确拼写。

用独立 Key 和已确认的模型完成一次真实请求。最短验证流程见 5 分钟完成第一次请求。

请求完成后，按大致时间查看用量变化；如果使用异步能力，再在任务中心核对状态和结果。这样可以确认调用链路与控制台记录能够对应。

至少记录生产 Key 的用途与负责人、核心模型名称、正常请求耗时范围，以及日常查看用量的位置。后续出现波动时，这些信息就是对照基线。

读完后，你应该知道某个问题首先属于哪一层：访问凭证、模型资源、任务执行，还是用量与账单；也知道出现异常后应该带着时间范围、Key、模型或任务标识进入对应页面，而不是盲目重试。