首页/配置/API Key
API Key 设置

在模式、工具和高级功能之前,API Key 设置往往就是决定 CodeWhale 能不能跑通的第一道关

二进制能启动以后,真正的下一道硬边界通常就是 provider 认证。很多 API Key 错误表面像安装或运行时问题,实际上只是凭据位置、提供方选择或变量来源不一致。

本页是站内详情页设置 CodeWhale 的 API Key(DeepSeek TUI 指南)配置

这页能直接回答的问题

  • API Key 应该放在配置文件、环境变量还是 provider 配置块里?
  • 怎样区分“没填 key”和“provider 选错了”?
  • 哪些检查能证明失败层真的在认证,而不是别的地方?

做完后该核对什么

  • 确认当前 key 确实属于你在 CodeWhale 里配置的那个 provider。
  • 检查拼写、空值和 shell profile 漂移。
  • 如果认证已经成功但行为仍异常,再转去 provider 设置或配置文件排查。

最常见的误区

  • 给 A provider 配了 key,但当前 config 指向的却是 B provider。
  • 不同 shell 里残留了不同的导出凭据。
  • 把认证错误误判成二进制安装坏了。

推荐阅读顺序

先按当前问题走,再决定要不要切去相邻详情页或 hub。

步骤 1

先确认 provider

动 key 之前先确认当前配置真正期待的是哪个 provider 路线。

步骤 2

先保留一个可信来源

优先让凭据只来自一个清晰来源,避免文件和环境变量互相打架。

步骤 3

用最小请求路径验证

先用最简单的请求去验证,再叠加模式、MCP 或其他高级行为。

直接可用的示例

先拿可执行例子,再回头做更细的调整。

先走环境变量认证验证

第一轮先只保留一个清楚的凭据来源,这样最容易判断失败是不是卡在认证层。

export DEEPSEEK_API_KEY="your-key-here"
deepseek

先别急着怪 key

动更多配置文件之前,先确认当前 shell 里真的有你以为的那个值。

echo "$DEEPSEEK_API_KEY"
codewhale --version

常见失败分支

先判断你卡在哪一层,再去对应分支,不要把所有问题都混成一个。

程序能打开,但第一条请求失败

通常不是安装坏了,而是凭据缺失、空值,或者 provider 路线不匹配。先去核对 provider 设置。

一个 shell 里能用,另一个 shell 里失败

大概率是不同 shell 的导出值不一致,或者旧 profile 还在生效。先比环境变量。

什么时候该离开这页

当你已经确认当前路线没问题,就不要继续停留在这页。安装线应转去配置,配置线应转去 provider 或排错,MCP 和模式线则应该转回真实工作流页。详情页的价值是把问题缩窄,而不是长期停留在解释层。