为什么要把‘能用’和‘可管理’分开

临时把一个 API Key 填进客户端，通常几分钟就能完成；但当电脑更换、项目增加或团队成员加入后，问题会逐渐出现：不知道哪张卡片正在使用、旧令牌还被哪些设备保存、配置改错后无法恢复。

把这三件事分开，既能减少误操作，也能让 Codex 的工作环境更容易复现。

• 使用配置：当前客户端真正启用的线路。
• 管理配置：名称、用途、创建时间和负责人。
• 恢复配置：脱敏模板、版本记录和撤销流程。

第一步：建立一张清晰的线路信息卡

进入灵能API的服务入口，先记录项目真正需要的接口地址、模型标识和权限范围。记录的是配置元数据，不是完整令牌。建议给每条线路增加用途，例如‘个人开发’‘测试项目’或‘团队只读’。

灵能API入口：https://www.lnsns.com/。实际令牌只保存在受控位置，不放入信息卡、截图和项目仓库。

• 用途：这张卡片给哪个项目或场景使用。
• 模型：使用当前列表中的精确 Model ID。
• 地址：记录 *ase **L 和客户端固定路径的关系。
• 权限：标记只读、开发或测试用途。

️ 第二步：在 CC Switch 中统一卡片命名

配置卡名称应该让使用者一眼看懂，而不是只写‘默认’‘新建’或‘测试’。推荐使用‘用途-项目-环境’的顺序，例如‘开发-文档工具-本地’。如果模型或权限不同，再补充简短后缀。

卡片越多，越要依靠用途和状态管理，而不是依靠记忆。

• 同一用途只保留一张主卡，旧卡片明确标记停用。
• 不要在卡片名称中写入完整 Key 或其他秘密。
• 把个人卡、项目卡和临时测试卡分开。

第三步：只把必要字段放进配置

一张可复用配置卡只需要包含客户端真正使用的字段。多余的自定义请求头、旧模型参数和临时调试项会增加冲突概率，尤其是在复制卡片时，旧值可能被带到新项目。

完成填写后，先保存，再关闭并重新打开卡片检查一次。编辑页面显示的内容，必须和启用状态一致。

• 保留：*ase **L、Model ID、API Key 和必要的兼容设置。
• 谨慎复制：自定义 Header、**和超时参数。
• 不要复制：临时调试值、旧项目路径和个人备注。

**步：建立脱敏备份模板

备份的目的不是把完整配置复制到聊天工具，而是在设备损坏或卡片误删后，能够快速恢复结构。模板只保存字段名、用途和占位符，完整令牌在恢复时从安全位置重新填写。

name: dev-project-local
*ase_url: <从当前接口说明复制>
model: <当前可用 Model ID>
api_key: <从安全位置重新填写>
owner: <负责人>
status: active

• 模板可以进入**文档或受控仓库。
• 完整令牌不要进入模板、提交记录和自动化日志。
• 恢复后先用最小请求测试，再进入真实项目。

第五步：配置修改采用‘复制、验证、替换’

需要更换模型、地址或令牌时，不要直接覆盖唯一可用卡片。先复制一张新卡，修改一个变量，完成验证后再将新卡设为主卡。这样即使修改失败，也能立即切回旧卡。

旧卡：dev-project-local
新卡：dev-project-local-2026-08-06
变更：只更新 Model ID
验证：空目录最小请求   项目只读请求

验证通过后，记录变更原因和时间，再决定是否停用旧卡。不要在没有测试记录的情况下批量替换所有项目。

第六步：团队协作时按权限分发

团队成员不一定需要同一权限。开发、测试、演示和自动化任务应尽量使用不同用途的令牌或配置卡。这样某个项目出现泄露或异常调用时，影响范围更容易控制。

共享的是配置结构和操作步骤，不是把同一个完整 Key 复制给所有人。

• 只读任务：使用范围最小的访问权限。
• 开发任务：只授予必要模型和额度。
• 自动化任务：单独创建，并设置更明确的调用范围。
• 临时演示：使用短期令牌，结束后立即撤销。

第七步：发现异常时先撤销，再查日志

如果出现陌生调用、额度异常或令牌可能暴露，第一动作应该是撤销或禁用风险令牌，而不是继续测试。完成止损后，再用时间、设备、配置卡名称和错误码定位原因。

• 立即停用疑似泄露的 Key。
• 删除本地配置中的旧值，并检查环境变量。
• 生成新 Key，更新专用卡片。
• 用最小请求确认新卡可用。
• 检查仓库、日志、截图和临时文件是否留下旧值。

✅ 第八步：***完整的恢复演练

很多备份只有在真正需要时才被验证，结果常常缺少字段或指向旧地址。可以在空目录中模拟一次卡片丢失：按照脱敏模板重新创建配置，填写新令牌，完成连接测试，再读取一个无敏感内容的项目文件。

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

演练完成后，把缺失步骤补回模板；不要把完整令牌写进演练记录。

• 恢复模板能否让新成员独立完成配置。
• 新配置是否只包含必要字段。
• 恢复后的卡片是否有清晰名称和负责人。

日常维护清单

灵能API与 CC Switch 的组合真正发挥作用，依赖的是清晰的配置边界和可恢复流程。把令牌管理、卡片命名和回滚习惯建立起来，后续接入新项目会更稳定。

• 每张卡片都有用途、负责人和状态。
• 停用卡片已明确标记，旧令牌已撤销。
• 备份模板不包含完整 API Key。
• 模型和接口地址来自当前说明，不依赖旧笔记。
• 配置修改保留旧卡和变更记录。
• 恢复流程至少演练过一次。
• 日志、截图和仓库中没有敏感值。