这篇教程适合什么场景

如果你希望在 Codex 中使用不止一条模型线路，或者希望在快速问答、代码修改和长任务之间切换不同模型，那么把配置集中放在 CC Switch 中会更容易管理。本文不依赖某一张默认卡片，而是从命名、字段、测试和回退四个方面建立可复用流程。

先完成一条稳定线路，再增加第二条和第三条，不要第一次就同时配置大量模型。

• 已有 Codex，但需要接入 API 线路。
• 同时使用多个模型，需要快速切换。
• 希望遇到故障时能切回上一条可用配置。

接入前准备与文件安全

准备工作主要包括 Codex、CC Switch、灵能API账户和一个空目录。配置过程中会出现 API Key，这类内容不要写进 README、截图、Git 提交或共享文档。首次测试也不要直接进入包含客户资料或生产密钥的项目。

• Codex 可以正常启动。
• CC Switch 能进入 Codex 配置菜单。
• 拥有可用额度和可撤销的测试令牌。
• 准备一个不含敏感内容的测试目录。

第一步：先确认灵能API的当前模型

先打开灵能API服务入口，查看当前模型列表和接口说明。模型名称、版本后缀和支持能力可能随时间变化，所以不要直接使用旧配置中的 Model ID。对于 Codex，优先选择当前说明中明确支持客户端请求的模型。

灵能API入口：https://www.lnsns.com/。先确认信息，再进入令牌创建和客户端配置。

• 记录 *ase **L，但不把完整令牌写在笔记里。
• 复制精确 Model ID，保留大小写和分隔符。
• 根据任务选择适合的模型，不盲目追求数量。

第二步：为不同用途创建令牌

建议至少区分日常开发和临时测试两类令牌。日常开发令牌用于稳定工作，临时测试令牌用于验证新模型或新地址。这样即使测试配置被误分享，也不会影响长期使用的主线路。

令牌只在本机安全位置保存。文章、截图和团队说明里只保留字段名称与脱敏示例。

• 名称写用途，例如 codex-dev 或 codex-test。
• 分组按照当前服务说明和项目权限选择。
• 不使用时及时禁用临时令牌。
• 出现泄露可能时直接撤销，不继续观察。

第三步：用任务而不是价格选择模型

模型配置不要只按价格排序。快速解释一个函数、**安全问题、处理长上下文和执行多文件改动，关注点都不同。可以把模型分成快速卡、**卡和长任务卡，先用短任务测试输出质量和稳定性。

查看输入、输出和倍率时，要结合真实任务估算，不要把单一折扣数字当成最终成本。

• 快速卡：短上下文、快速反馈、适合小修改。
• **卡：关注证据、风险和结构化输出。
• 长任务卡：关注上下文处理和连续工作稳定性。

️ **步：在 CC Switch 中创建第一张卡

打开 CC Switch 的 Codex 页面，点击加号或新增渠道。供应商名称建议包含灵能API、用途和模型类型，例如‘灵能API-Codex-开发’。名称清楚后，多个渠道同时存在时不容易选错。

保存前再次确认卡片名称、地址和 Key 属于同一用途，避免把一个项目的令牌配到另一个项目。

• API Key 粘贴测试令牌，检查是否带有空格。
• API 请求地址填写当前 *ase **L。
• 不确定的高级字段先保持默认。

第五步：获取模型并建立第二张卡

点击获取模型列表。如果能返回列表，说明基础地址和鉴权大概率已经通过。选择一个用于短任务的模型保存第一张卡，然后复制这张卡创建第二张卡，只修改 Model ID，保留其他字段不变。

灵能API-Codex-开发-快速
灵能API-Codex-开发-深度
共同字段：*ase **L、权限范围
对比字段：Model ID

一次只修改一个字段，后续测试才知道速度和输出变化究竟来自模型，还是来自地址、权限或其他参数。

第六步：切换配置的正确顺序

新增渠道后，点击启用或切换到目标卡片。然后完全退出正在运行的 Codex，再重新打开。桌面窗口、终端进程和**任务都可能继续使用旧配置，只切换界面状态并不能保证请求已经更新。

启用目标卡片
关闭旧 Codex 进程
重新启动 Codex
进入空目录发送短请求
记录返回模型或结果

切换后仍返回旧结果时，检查旧进程、系统环境变量和项目配置是否覆盖了 CC Switch 的值。

第七步：先做三次小测试

新卡片不要直接用于大型重构。建议连续做三次小测试：确认工作目录、解释一段短文本、读取一个无敏感内容的文件。三次都正常后，再进入真实项目。

New-Item -ItemType Directory codex-model-check
Set-Location codex-model-check
codex

• 测试一：确认当前目录和运行状态。
• 测试二：让模型回答一个固定问题。
• 测试三：只读一个简单文件并给出摘要。

第八步：进入项目后使用分阶段提示

接入成功只是起点。进入真实项目后，先让 Codex 读取目录和项目说明，再给出任务计划。确认范围后才修改文件，修改完成后检查 diff 并运行针对性测试。

先读取项目结构，不修改文件。
说明与本任务相关的文件。
给出执行计划和可能风险。
等待确认后再修改。
完成后展示 diff 和测试结果。

• 不要让模型默认扫描整个仓库。
• 不要把配置、令牌和业务秘密放进提示词。
• 不要跳过 Git 状态和变更检查。

第九步：出错时先回到稳定卡

新模型或新配置出现问题时，先切回已经验证过的稳定卡，再判断是模型、地址、权限还是客户端缓存。不要在一张失败卡片上连续修改多个字段。

排错记录只保存时间、卡片名称、错误码和脱敏后的配置，不保存完整令牌。

• 401：核对 Key 是否完整和仍然有效。
• 403：检查额度、分组和模型权限。
• 404：检查 *ase **L 的路径拼接。
• 超时：缩短上下文，降低并发，检查网络。
• 切换不生效：退出旧进程并重新启动。

✅ 多模型接入完成清单

按照这套顺序，灵能API不仅可以完成一次接入，还能让 Codex 在不同任务之间保持清晰、可控的模型切换。

• 第一张灵能API渠道可以完成最小请求。
• 第二张渠道只修改了明确的对比字段。
• 卡片名称包含项目、环境或用途。
• 切换后已重启 Codex 并通过短任务测试。
• 稳定卡仍然保留，可以随时回退。
• 真实项目采用只读、计划、修改、测试的顺序。
• API Key 未进入截图、仓库和共享文档。