先理解：配置不生效通常不是玄学

很多人接入 Codex 中转站后，会遇到一种很像玄学的问题：CC Switch 里明明已经填了灵能API线路，Codex 仍然像在走旧服务；Key 已经换了，错误码却没变；模型已经切换，输出风格却像旧模型。

这些问题通常不是工具随机失灵，而是配置优先级和终端会话没有对齐。配置卡保存是一件事，当前启用是一件事，旧终端是否重新读取又是另一件事。接入时只要把这些层级拆开，问题就会清楚很多。

• 服务层：灵能API账户、模型、Key 和额度。
• 配置层：CC Switch 当前保存和启用的卡片。
• 终端层：PowerShell、VS Code、WSL 或容器是否重新读取。
• 项目层：项目目录和任务提示词是否带入额外变量。

第一步：先确认灵能API服务信息

排查配置优先级前，先进入灵能API入口，确认账户、模型、额度和 Key 状态。入口：https://www.lnsns.com/

如果服务侧已经异常，本地怎么改都不会稳定。先确认灵能API这层正常，再进入 CC Switch 和终端排查。

• 账户可以正常登录，避免把账户问题误判为本地配置问题。
• Model ID 来自当前模型列表，不使用旧笔记。
• API Key 仍然有效，没有被撤销或复制错误。
• 额度可以支撑空目录和真实项目两轮验证。

第二步：凭证只保留一条主线

配置优先级混乱时，最常见的源头是多处保存了凭证：CC Switch 里一枚 Key，项目 .env 里一枚旧 Key，终端环境变量里又残留一枚。新手接入时，建议先把凭证来源收敛到一条主线。

推荐策略：
主要凭证位置：CC Switch 配置卡
记录内容：Key 用途、创建日期、负责人
禁止位置：README、公开日志、截图、仓库、聊天记录
排错记录：只写 Key 用途名称，不写完整明文

灵能API负责提供凭证入口，CC Switch负责本地线路管理。凭证来源越少，排错越容易。

• 不要把完整 Key 写进项目仓库。
• 不要在多个终端配置不同 Key 后忘记清理。
• Key 泄露后直接撤销，不继续使用。

第三步：在 CC Switch 建立基准配置卡

为了排查配置优先级，建议先建立一张基准配置卡，例如“灵能API-Codex-Env*ase”。这张卡只保留必要字段，不放复杂高级参数，用来判断 Codex 是否能读取当前启用线路。

基准卡不是日常复杂任务卡。它的价值是简单、干净、可复现，方便和其他项目卡、备用模型卡做对照。

• 卡片名称要能看出这是基准线路。
• 模型选择稳定、响应快的基础模型。
• 高级参数先保持默认，减少变量。
• 只用于接入验证和生效排查。

**步：填写字段并记录对照

基准卡里填写 *ase **L、Model ID 和 API Key。这里建议同时写一份非敏感对照记录，后续排错时能快速确认当前应该读取哪一组字段。

服务名称：灵能API-Codex-Env*ase
*ase **L：https://www.lnsns.com/v1
Model ID：从灵能API当前模型列表复制
API Key：Codex 专用 Key，不记录明文

对照记录里可以写灵能API、*ase **L 和模型名称，但不要写完整 Key。

• *ase **L 不要重复 /v1。
• Model ID 不要使用页面展示名或旧截图。
• API Key 粘贴后检查首尾空格。

⚙️ 第五步：保存、启用、重开终端三步都要做

配置生效排查中，最容易漏掉的就是“重开终端”。保存配置只是写入字段，启用配置只是告诉 CC Switch 当前要用哪张卡，重开终端才是让 Codex 重新读取新状态。

如果你在 VS Code、PowerShell、WSL、容器里来回切换，每个环境都要单独重开和验证。

• 保存：确认字段没有被清空或回退。
• 启用：确认当前卡片就是灵能API-Codex-Env*ase。
• 重开：关闭旧 Codex 会话，打开新终端。
• 验证：用固定短提示词测试，不直接进项目。

第六步：空目录验证当前配置是否生效

空目录验证可以排除项目配置、依赖、上下文和文件权限干扰。新开终端后，进入空目录，只发送固定短提示词。

New-Item -ItemType Directory codex-env-priority-check
Set-Location codex-env-priority-check
codex

请只返回：当前中转 API 配置已生效

如果返回成功，说明基准卡和当前终端已经连通。如果仍然失败，先不要进入项目，继续检查 Key、*ase **L、Model ID 和终端环境。

第七步：判断是否被旧环境变量覆盖

如果 CC Switch 配置正确，但 Codex 仍然表现异常，可以检查是否存在旧环境变量或项目配置覆盖。尤其是曾经手动配置过中转 API 的电脑，旧变量可能还在。

Get-ChildItem Env: | Where-O*ject { $_.Name -**tch 'OPENAI|API|CODEX|*ASE|KEY' }

不同工具对环境变量和配置文件的优先级可能不同。新手阶段不要同时维护太多入口，先让 CC Switch 作为主配置来源更清楚。

• 只检查变量名称和来源，不要在共享记录里贴完整值。
• 发现旧 Key 或旧 *ase **L 时，先记录用途，再决定是否清理。
• 清理后要重新打开终端，再做空目录验证。

第八步：项目配置不要和全局配置打架

真实项目里可能也有 .env、配置文件、脚本参数或启动命令。如果项目里残留旧接口地址，Codex 的表现可能和空目录不同。进入项目后，第一轮只做只读分析，不要马上修改。

请只读分析当前项目，不要修改文件。
允许读取：README.md、src、tests
禁止读取：.env、secrets、生产配置、数据库备份
输出：项目结构、可能影响 API 配置的文件、下一步建议

如果项目里确实有旧配置引用，先让 Codex 说明影响范围，再由你确认是否修改。不要让它直接批量替换所有配置文件。

第九步：切换模型或卡片后重新验证

接入跑通后，你可能会切换到备用模型、项目卡或排错卡。每次切换后都要重开终端并重新验证，不要把上一个会话的结果当成新配置结果。

切换后验证顺序：
1. 确认 CC Switch 当前启用卡片
2. 关闭旧 Codex 会话
3. 打开新终端
4. 空目录固定短提示词测试
5. 记录卡片名称、模型和结果

这**作有点啰嗦，但非常有效。它能把“配置到底有没有生效”变成**证的步骤。

• 切换模型后先短请求，不直接跑长任务。
• 切换项目卡后确认当前目录。
• 切换排错卡后记录错误码和结果。

配置优先级常见问题速查

排错时一次只改一个变量。改完之后重开终端，用同一个固定提示词复测，结果才有可比性。

• 配置保存了但不生效：确认卡片已启用，并重开终端。
• 空目录成功、项目失败：检查项目配置、目录范围和任务体量。
• 模型像旧模型：确认当前启用卡片和新终端会话。
• 401：检查 API Key 是否来自当前灵能API账户。
• 404：检查 *ase **L 和 Model ID 是否来自当前配置。
• timeout：先短请求复测，再看网络、**和任务范围。

✅ 最后一份生效排查清单

把环境变量、配置优先级和终端会话拆开之后，Codex 中转 API 接入会清楚很多。灵能API负责提供中转入口和模型服务，CC Switch负责配置切换，而固定验证流程负责确认当前配置真的生效。

• 灵能API入口、账户、模型和额度已确认。
• API Key 来源已收敛，未散落在项目或终端脚本里。
• CC Switch 已创建灵能API-Codex-Env*ase 基准卡。
• *ase **L、Model ID、API Key 已逐项核对。
• 配置卡已保存、启用，并重新打开终端。
• 空目录固定提示词验证通过。
• 旧环境变量和项目配置已检查，没有覆盖新线路。
• 切换模型或配置卡后会重新验证。