安装完成以后，provider 设置才是真正的激活步骤。重点不只是填凭据，而是让选中的后端、认证值、模型预期和配置路径都属于同一条路线。
先按当前问题走，再决定要不要切去相邻详情页或 hub。
不要让 provider 保持隐式假设，第一步就明确当前后端是谁。
确保凭据来源和 provider 配置块描述的是同一个后端，而不是两条路线混杂。
先把最简单的一次 provider 请求跑通，再去调模型、模式和 MCP。
先拿可执行例子，再回头做更细的调整。
不要一上来同时配认证、模型默认值和高级功能。先把 provider 路线锁定，再验证最小请求。
codewhale --version
# 在认证完成后再开最小会话验证让 provider 选择、凭据来源和模型预期先在一轮里对齐，再去加 MCP 或更多运行时行为。
export DEEPSEEK_API_KEY="your-key-here"
# 保证环境变量和配置文件指向同一 provider真正值钱的是先让 provider 路线跑通，而不是一开始就改模型默认值。
echo "$DEEPSEEK_API_KEY"
# 确认当前 provider 配置块
# 先跑一次最小请求，再动模型默认值先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
通常是 provider 名字和凭据来源没对齐。先查 API Key 设置和环境变量覆盖。
这更像模型默认值或模式预期的问题，不再是凭据问题。下一步去看 config 和 modes。
先停下来拆层。先把 provider 和认证层锁定，否则你根本不知道是哪一项让会话变好或变坏。
当你已经确认当前路线没问题，就不要继续停留在这页。安装线应转去配置，配置线应转去 provider 或排错，MCP 和模式线则应该转回真实工作流页。详情页的价值是把问题缩窄，而不是长期停留在解释层。