先建立日常工作流，而不是只保存一张配置卡

配置卡保存成功只是起点。日常使用中，模型会切换，项目会切换，网络和账户状态也可能变化。如果每次都直接修改同一张卡片，出了问题很难知道是哪一项变了。更稳妥的方式是把配置分成主线路、轻量线路和备用线路，每次切换都留下清晰的名称和验证记录。

整套流程可以归纳为：选择卡片、确认模型、重启终端、发送只读请求、再进入项目。少掉其中任何一步，都可能出现‘界面已切换，但实际请求仍走旧配置’的情况。

• 主线路：用于日常代码阅读和常规开发。
• 轻量线路：用于短问答、配置检查和快速验证。
• 备用线路：主线路异常时快速回退，不临时覆盖主卡片。

先读懂 CC Switch 页面：哪些内容会影响请求

打开 CC Switch 的 Codex 配置区域后，可以先把页面分成两部分。上方的服务名称、备注和官网链接主要用于本地识别；下方的 API Key、API 请求地址和模型名称才是发送请求时真正需要的参数。

不要因为服务名称填写正确，就认为接口已经配置完成。服务名称写错通常只影响识别，*ase **L 或 Model ID 写错则会直接导致 404、鉴权失败或模型不可用。日常排错时，优先查看请求字段。

• 管理信息：服务名称、备注、官网链接。
• 请求信息：协议、API Key、*ase **L、Model ID。
• 运行状态：是否保存、是否启用、终端是否已重启。

第一步：每天开始工作前核对模型信息

如果你长时间没有使用 Codex，建议开始工作前通过灵能API页面快速核对模型信息。重点查看模型是否仍在可用列表中，接口 ID 是否发生变化，以及当前账户状态是否适合本次任务。不要把几周前保存的模型名当成永久不变的配置。

官网入口：https://www.lnsns.com/。实际模型、价格和服务说明以当天页面为准。

建议将模型按任务分组，而不是单纯按版本号记忆。快速问答、代码解释、长上下文分析和项目修改，关注点并不相同。用清晰的卡片名称表达用途，比每次打开配置后猜模型更可靠。

• 快速任务：优先响应速度和稳定性。
• 代码理解：优先上下文处理和解释完整度。
• 项目修改：先只读，再确认后写入。

️ 第二步：用命名规则管理多条线路

配置卡多起来后，命名规则会直接影响排错速度。推荐使用‘服务 客户端 用途 状态’的结构，例如“灵能API-Codex-主线路”或“灵能API-Codex-轻量测试”。不要让多张卡片都叫默认配置。

每张卡片只承担一个明确角色。想测试新模型时，复制主卡片创建实验卡；测试成功后再决定是否将它设为默认。这样可以保留原本稳定的线路，不会因为一次试验影响日常工作。

• 主线路：保持稳定，少做临时修改。
• 实验线路：用于新模型、新参数或新**。
• 备用线路：只在主线路异常时启用。

✍️ 第三步：切换前后都要核对四个字段

切换线路时，最容易忽略的是‘卡片名称变了，但字段没有按预期更新’。保存前后都建议快速核对协议、*ase **L、Model ID 和 API Key 状态。特别是复制卡片后，旧的模型 ID 可能仍然保留在新卡里。

当前卡片：灵能API-Codex-主线路
*ase **L：https://www.lnsns.com/v1
Model ID：以当前模型列表为准
API Key：对应当前卡片用途的专用密钥

*ase **L 通常填写到版本路径即可，不要误填官网首页，也不要把完整的接口路径继续拼接进去。若出现 404，先检查是否重复添加 /v1；若出现 model not found，重新从模型列表复制 ID。

API Key 不要为了方便而多张卡片共用。不同用途使用独立密钥，发生异常时可以单独停用，也能更清楚地查看调用记录。

**步：完成切换后重新启动 Codex

CC Switch 显示某张卡片已启用，并不代表已经打开的 Codex 进程会自动刷新。完成切换后，关闭旧的 Codex、PowerShell 和相关**进程，再开一个新的终端窗口。这个动作是日常切换中最容易漏掉的一步。

codex --version
mkdir codex-switch-check
cd codex-switch-check
codex

进入后先发送一条只读任务：请确认当前目录是否为空，并说明你会如何开始检查项目，不要修改任何文件。如果这个任务能稳定返回，说明新进程大概率已经读取到当前配置。

不要同时打开多个线路的 Codex 窗口进行对比。若必须对比，分别使用不同测试目录，并在每个窗口记录卡片名称和启动时间，避免把结果混在一起。

✅ 第五步：用连接测试和真实任务做两次验收

如果 CC Switch 提供连接测试或模型获取功能，可以先执行轻量测试；但界面测试通过后，还需要用 Codex 真实启动一次。两者分别验证不同环节：前者更接近字段和接口，后者会验证本地进程是否读取了配置。

进入真实项目时，先检查版本控制状态，再限制任务范围。推荐顺序是：读取一个文件，解释依赖关系，提出修改方案，最后才执行一个小改动。任何涉及批量修改的任务，都应该先确认备份或提交状态。

• 测试一：空目录只读任务。
• 测试二：真实项目读取单个文件。
• 测试三：经过确认后执行单文件小改动。

日常排错：从现象反推配置层

排错时保留卡片名称、错误码、模型 ID 和时间，不要记录完整 API Key。一次只修改一个变量，才能知道哪项变更真正解决了问题。

• 启动前就报命令不存在：检查 Node.js、npm、Codex 和 PATH。
• 401：检查当前卡片的 API Key 是否完整、有效，是否与服务账户对应。
• 403：检查额度、模型权限和账户状态。
• 404：检查 *ase **L 是否写错，尤其是重复 /v1。
• model not found：重新复制当前 Model ID，不要使用旧卡片里的名称。
• 切换后仍然走旧线路：关闭旧终端和进程，重新打开 Codex。
• 项目任务超时：先缩短上下文和读取范围，再检查网络和**。

第六步：给日常使用设定安全规则

长期使用中，密钥管理和配置管理同样重要。建议每个设备或用途使用独立 API Key，定期查看用量，发现异常时先撤销可疑密钥，再重新创建新的主线路卡片。

需要查看当前模型、余额和服务信息时，可以通过可点击的灵能API官网入口进入：https://www.lnsns.com/。实际页面信息优先于旧截图和旧笔记。

• 不要把完整密钥截图或提交到 Git。
• 实验线路使用单独卡片，不覆盖稳定主线路。
• 更换密钥后先测试新 Key，再撤销旧 Key。
• 升级 CC Switch 或 Codex 后重新做空目录验收。

日常使用检查表：每天只需几十秒

把这份检查表固定下来，日常切换就会从‘凭感觉’变成‘按步骤确认’。当线路出现异常时，也能迅速回退到已知可用配置。

• 今天使用的卡片名称是否正确。
• 模型 ID 是否仍在当前列表中。
• *ase **L 是否没有重复版本路径。
• 切换后是否关闭旧终端并重新启动。
• 进入重要项目之前是否先做只读任务。
• API Key 是否没有出现在截图、仓库或日志中。