先确认 base_url 到底指向哪里
base_url 决定客户端把请求发到哪个 API 服务。不同客户端的输入框不完全一样：有些要求填完整 OpenAI-compatible 地址，有些会自动补路径，有些需要把接口版本写进去。最常见的错误，是把多个教程里的写法混在一起，导致域名、路径和版本号重复或缺失。
配置 APIToken 时，先从 教程中心 找当前客户端对应的说明，再按页面给出的字段逐项填写。不要只复制旧截图，也不要把别的服务商地址、旧项目地址和当前客户端模板混用。本站完整网址是 https://APIToken.Company。
网页登录成功不等于 API key 可用
很多人会把“能登录网页控制台”和“API key 可调用模型”混为一谈。网页登录只说明账号会话存在；真实模型调用看的是 API key 是否存在、是否启用、是否有额度、是否过期、是否有目标分组权限，以及客户端有没有读取到最新配置。
建议按用途创建独立 key：本地代码助手一个、图片测试一个、自动化脚本一个。这样既方便在 API 密钥 页面停用异常 key，也方便之后复盘是哪一个项目产生了消耗。不要把真实 key 写进截图、文档、聊天窗口或公开仓库。
模型名要以当前模型广场为准
model name 是实际调用哪个模型。模型名不是营销名称，也不是客户端下拉框里随手猜的名称。上游会增删模型，站点也会按分组权限、成本和稳定性调整可见模型。几个月前能用的名称，今天未必还在同一个分组里。
正式配置前，先打开 模型广场，确认模型当前可见、支持的端点类型和可用分组。若模型广场能看到模型，但调用仍失败，就继续检查 key 权限、余额、端点类型和客户端请求格式；不要把“模型列表可见”直接当作“真实调用已经成功”。
配置失败时按这个顺序排查
排查顺序建议固定下来，不要每次随机改参数。第一步看 base_url 是否匹配当前客户端要求；第二步确认 API key 是否复制完整且仍然启用；第三步看 model name 是否在当前模型广场可见；第四步看 key 所在分组是否允许调用该模型；第五步看账户余额、用量限制和状态页。
如果 渠道状态 显示对应分组异常，就先不要反复重试大任务；如果状态正常，再回到本地客户端检查字段。这样可以避免把服务侧波动误判成本地配置错误，也能避免在本地配置错误时反复消耗额度。
最小真实调用比只看模型列表更可靠
很多 OpenAI-compatible 服务的模型列表接口只能证明 key 被识别、模型对当前账号可见；它不能证明真实对话、图片生成或长上下文任务都能跑通。接入前更稳妥的方式，是先做一次低成本、最小化的真实调用，再逐步放大到正式工作流。
对于团队内部教程，可以把验证步骤写成固定清单：填写 base_url、填写 key、选择模型、做最小调用、检查状态页、记录失败信息。后续换客户端、换模型或换项目时，仍然按同一套清单走，而不是靠记忆补参数。
https://APIToken.Company。
同步发布记录
目前已确认知乎专栏公开链接。小红书仅返回创作服务平台发布成功页，未拿到公开笔记 URL，因此不写入已同步外链；搜狐号、一点号、网易号、头条号若后续取得公开 URL，会再补入本站记录。