这次解决的不是‘能不能连上’，而是‘能不能稳定切换’

单次接入成功，只能说明当前电脑、当前密钥和当前模型暂时可用。真正开始长期使用后，通常还会遇到三类需求：换一台电脑继续工作、给不同任务选择不同模型、主线路异常时快速切回备用线路。若没有提前分层管理，最后往往只能重新摸索。

本文把配置拆成四层：账户层负责密钥和额度，服务层负责 *ase **L 与模型列表，客户端层由 CC Switch 保存并启用，项目层负责在真实目录中验证。换机时只迁移必要信息，切换时只改一层，排错会更快。

• 账户层：账户、额度、API Key 的生命周期。
• 服务层：官网信息、*ase **L、可用模型和接口协议。
• 客户端层：CC Switch 中的配置卡与当前启用状态。
• 项目层：Codex 在空目录和真实项目中的实际表现。

换机前先做清单：哪些可以迁移，哪些不能直接复制

准备换电脑时，不要把整个用户目录或不明来源的配置文件直接打包带走。更稳妥的方式是建立一份不含密钥的参数清单，在新电脑上重新安装客户端，再逐项创建配置。这样能避免旧路径、旧**和旧环境变量被一起带过去。

建议把参数清单保存为本地**笔记，Key 只放在密码管理器中。新电脑首次使用时，先完成本地工具检查，再在 CC Switch 中重建线路。

• 可以记录：配置卡名称、用途备注、*ase **L、模型 ID、协议类型。
• 需要重新确认：API Key 是否仍有效、账户额度是否足够、模型是否仍在列表中。
• 不要直接分享：完整 API Key、包含密钥的环境文件、终端历史记录。

第一步：用灵能API页面核对三项服务信息

换机或新建备用线路前，先通过灵能API的公开入口确认服务信息。重点不是记住网页布局，而是核对三项实际配置依据：当前可用模型、模型的接口 ID、以及客户端需要使用的请求地址。页面展示名称与接口字段可能不是同一个字符串。

官网入口：https://www.lnsns.com/。实际价格、模型和服务说明可能更新，配置时以控制台当天显示为准。

如果准备同时保留主模型和轻量模型，不要把它们写成一张卡片里的模糊备注。最好让每个模型都对应一张清晰的配置卡，名称中同时写出用途，例如‘灵能API-Codex-快速问答’和‘灵能API-Codex-项目分析’。

• 模型是否仍处于可用状态。
• 模型 ID 是否包含版本后缀或特殊连字符。
• 接口地址是否需要使用 /v1 版本路径。

️ 第二步：新电脑先恢复本地环境，再恢复线路

在新电脑上，先安装 Node.js LTS 和 CC Switch，再安装 Codex。不要在还没有确认命令可用时就粘贴旧配置，因为后续每一步都需要知道问题来自软件安装，还是来自服务参数。

node -v
npm -v
where.exe node
where.exe npm
npm install -g @openai/codex
codex --version

如果版本命令全部有输出，说明本地基础环境已经具备。接下来重新打开 CC Switch，先确认 Codex 页面能正常加载，再创建新的供应商卡片。不要假设旧电脑的安装路径和新电脑相同，也不要把旧电脑的 PATH 值手工复制过来。

换机验证的第一个目标不是让复杂项目跑起来，而是让 CC Switch 能保存一张干净、可识别、可启用的配置卡。

️ 第三步：建立主线路、轻量线路和备用线路

多模型使用时，最容易出现的问题是所有配置都叫‘默认’，切换之后却不知道当前到底使用了哪一套参数。建议至少建立三种角色：主线路用于日常开发，轻量线路用于快速问答和短任务，备用线路用于主线路故障时回退。

三张卡片可以使用同一个服务入口，但模型 ID 和备注要明确。若服务支持模型列表获取功能，优先使用获取列表来减少手动输入；如果列表获取失败，再根据控制台信息手动填写，并单独记录这次验证结果。

• 主线路：上下文和代码理解能力优先，作为日常默认。
• 轻量线路：响应速度和成本优先，用于短问题与配置检查。
• 备用线路：参数独立保存，不与主线路共用需要频繁修改的字段。

**步：迁移时逐字段核对，别一次覆盖全部配置

在新卡片中按照固定顺序填写：名称与备注、协议、*ase **L、模型 ID、API Key。先填不会泄露的字段，最后处理密钥，完成后再保存。固定顺序的好处是每次迁移都有一致的排查路径。

配置卡：灵能API-Codex-主线路
协议：按 CC Switch 当前可选项选择兼容协议
*ase **L：https://www.lnsns.com/v1
Model ID：从当天模型列表复制
API Key：新电脑上重新粘贴并隐藏保存

最常见的地址问题有三个：把官网地址当成 API 地址，把完整接口路径填进 *ase **L，或者重复添加 /v1。配置完成后，先把地址读一遍，确认协议、域名和版本路径都符合页面或客户端提示。

如果是从旧电脑迁移，尤其要重新检查环境变量是否覆盖了 CC Switch 的配置。一个简单办法是：关闭旧终端，暂时只启用新卡片，在空目录启动 Codex；若结果正确，再逐步恢复其他开发工具。

第五步：切换模型时，先区分‘默认’和‘临时’

不同任务不一定需要同一模型。日常代码阅读、长上下文分析、快速命令解释和小范围修改，关注点不同。建议把默认模型留给最常用场景，临时任务通过切换另一张卡片完成，不要频繁修改默认卡片的核心字段。

每次切换后都要做三件事：确认卡片名称和启用状态，关闭旧 Codex 终端，发送一条轻量只读任务。不要只看 CC Switch 的界面状态，因为当前运行的进程可能还没有刷新。

• 代码阅读：关注上下文长度、响应稳定性和解释完整度。
• 快速问答：优先关注响应速度和简单任务的成功率。
• 项目修改：先确认模型可读取项目上下文，再允许写入文件。
• 故障回退：切换备用卡片，不要在主卡片上临时覆盖多个字段。

✅ 第六步：做一套‘三分钟验收’

配置迁移完成后，可以用固定的三分钟验收代替凭感觉判断。第一分钟检查命令和卡片状态，第二分钟做空目录只读请求，第三分钟在真实项目中只做一个小范围读取任务。

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

空目录中的第一条任务可以写成：请确认当前目录是否为空，并说明你下一步会如何检查一个代码项目，不要创建或修改任何文件。它能验证当前进程是否启动、接口是否返回、模型是否能理解指令。

如果空目录测试通过，再进入一个非关键项目目录，让 Codex 只读取一个指定文件并解释其职责。确认返回稳定后，才允许它提出修改方案。验收期间不要同时打开多个不同线路的 Codex 窗口，否则出现结果差异时很难判断是哪张卡片生效。

迁移和切换最常见的八种异常

排错时只改变一个变量。比如先切换回已知可用卡片，若恢复，再比较两张卡片的地址、模型与 Key 状态；不要同时升级软件、换模型、改**和重装客户端。

• 新电脑命令不存在：Node.js 或 Codex 尚未正确安装，先处理本地 PATH。
• 401：Key 不完整、已撤销，或当前启用的不是刚刚修改的卡片。
• 403：账户额度、模型权限或访问策略不满足当前请求。
• 404：*ase **L 层级错误，重点检查是否重复 /v1。
• model not found：模型 ID 过期、拼写不一致，或把网页展示名称当成接口 ID。
• 切换后仍显示旧结果：旧终端或旧**进程没有关闭。
• CC Switch 测试成功但 Codex 失败：检查 Codex 是否读取了另一份环境变量或本地配置。
• 请求超时：缩短任务、减少上下文，先确认网络和**，再判断服务状态。

配置维护：让换机和回退都不再慌

把配置当成一项长期资产管理，会比临时复制粘贴可靠得多。每次新增线路都写清用途，每次换模型都留一个可回退版本，每次密钥变更都撤销旧 Key。这样即使某条线路突然异常，也只需要切换卡片，而不是从头搭建环境。

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

• 配置卡名称包含服务、客户端和用途。
• 模型 ID 和 *ase **L 记录在**笔记，不记录完整 Key。
• 主线路、轻量线路、备用线路分别测试，不共用模糊备注。
• 升级 CC Switch 或 Codex 后重新***空目录验收。

最终检查：换机、切换、回退各过一遍

完成这组检查后，配置就具备了迁移、切换和回退能力。后续新增模型时，只需复制同样的验收路径，不必重新猜测每个字段的含义。

• 新电脑可以正常运行 node、npm 和 codex。
• 每张配置卡都有明确用途，当前启用状态清晰。
• *ase **L、模型 ID 和协议字段来自当前服务信息。
• API Key 没有出现在截图、仓库和排错记录中。
• 主线路和备用线路都能在空目录完成只读测试。
• 切换卡片后关闭旧终端，再重新启动 Codex。
• 进入真实项目前，先检查版本控制状态并限制首次任务范围。