為什么要把‘能用’和‘可管理’分開

臨時把一個 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。
• 模型和接口地址來自當前說明，不依賴舊筆記。
• 配置修改保留舊卡和變更記錄。
• 恢復流程至少演練過一次。
• 日志、截圖和倉庫中沒有敏感值。