團隊接入和個人接入不是一回事

個人接入時，關注點通常只有一個：能不能把 Codex 跑起來。團隊接入時，關注點會變成一組管理問題：權限如何分配、用量如何歸因、配置如何同步、密鑰如何輪換、異常如何定位。只要參與人數超過兩三個人，靠聊天記錄傳 Key、靠口頭說明同步模型名稱，很快就會失控。

靈能API更適合作為統一入口使用，CC Switch 則適合把不同線路保存成清晰的配置卡。一個負責賬號與接口層，一個負責本地切換與復現層。把兩者分工講清楚后，團隊成員不用反復問“地址填哪個”“模型用哪個”“這個 Key 是誰的”，協作會順很多。

• 個人接入追求快速跑通，團隊接入追求長期可維護。
• 個人 Key 可以臨時試驗，團隊 Key 必須有用途、負責人和回收規則。
• 配置說明要能被新人獨立讀懂，而不是依賴某個成員口頭解釋。

? 先畫清楚角色：***、開發者、協作者

在開始配置之前，建議先把團隊角色分清。***負責進入靈能API控制臺、創建憑證、查看賬號狀態和處理權限回收；開發者負責在本地 CC Switch 中配置 Codex；協作者只拿到自己需要的接入說明，不接觸無關項目的密鑰和額度信息。

角色不是為了增加流程，而是為了減少誤操作。比如模型切換權限不一定要給所有人，CI Key 不應該交給臨時協作者，外包成員也不需要看到其他項目的配置。把角色邊界定好，后面創建 Key、寫文檔、排查錯誤時才有明確責任人。

• ***：維護靈能API賬號、憑證、余額和模型權限。
• 開發者：使用 CC Switch 保存本地配置，并按文檔驗證 Codex。
• 協作者：只獲取當前任務所需的最小接入信息。

第一部分：Key 不要共用，至少按場景拆分

團隊最常見的問題是所有人共用一枚 Key。短期看確實省事，長期看會帶來三個麻煩：無法判斷是誰產生了高用量，無法在成員離開后精確回收權限，也無法給不同項目設置不同接入策略。更合理的方式是按成員、項目或自動化場景拆分。

如果團隊規模很小，可以先按“個人開發 Key、項目共享 Key、自動化 Key”三類拆分。個人開發 Key 用于日常本地任務；項目共享 Key 用于固定項目協作；自動化 Key 用于腳本或流水線。每個 Key 都要有名稱、用途、負責人和創建日期。

個人開發：codex-dev-zhangsan-20260903
項目協作：codex-project-a-review-20260903
自動化任務：codex-ci-readonly-20260903
臨時排查：codex-temp-de*ug-20260903

• 不要把完整 Key 寫進項目說明、截圖或聊天記錄。
• 臨時 Key 要有明確過期時間，用完就停用。
• 項目結束時，先回收項目 Key，再歸檔配置說明。

第二部分：把官網入口和控制臺路徑寫成固定說明

團隊接入文檔里，最先應該寫清楚入口：通過 https://www.lnsns.com/ 進入靈能API，然后進入對應控制臺位置查看接入信息。不要只發一個截圖，也不要只寫“去**拿地址”。截圖會過期，口頭描述會丟失，固定入口加步驟說明才可靠。

文檔不需要寫得很花，但要具體。比如“進入控制臺后先確認賬號名稱，再查看接口地址與模型列表”，這比“復制地址即可”更有用。多人協作時，最怕有人在錯誤賬號下復制了配置，表面看字段都對，實際權限和額度完全不是同一套。

• 入口寫完整，避免成員從舊收藏夾進入過期頁面。
• 步驟寫**證動作，例如確認賬號、余額、模型權限。
• 截圖只作為輔助，不能替代文字版路徑說明。

第三部分：CC Switch 配置卡按項目命名

CC Switch 里如果只有一張“默認配置”，團隊成員很容易誤用。建議按項目和用途建卡，例如“靈能API-Codex-項目A-日常開發”“靈能API-Codex-項目A-只讀**”“靈能API-Codex-備用線路”。配置卡名稱要讓人一眼看出它服務哪個項目、適合什么任務、是不是備用。

這里有一個實用習慣：每次調整 *ase **L、模型 ID 或接口類型后，在配置卡備注里記錄日期和原因。比如“2026-09-03 調整為項目 A 默認模型，用于代碼解釋和只讀**”。以后出了問題，不需要翻聊天記錄就能知道最近改過哪里。

• 配置卡名稱不要只寫 test、new、default 這類模糊詞。
• 同一項目的開發、**、自動化任務最好分成不同卡片。
• 更改配置后必須***短任務驗證，再通知團隊更新。

**部分：用權限分層減少誤用

不是每個人都需要同樣權限。日常開發成員通常只需要能調用模型完成代碼解釋、排錯和文檔整理；項目負責人可能需要查看用量和管理項目 Key；***才需要創建、停用和輪換憑證。把權限都放給所有人，只會讓問題出現時很難定位。

使用靈能API做統一接入時，可以把權限策略寫進團隊手冊：誰有權創建 Key，誰有權調整模型，誰負責處理余額，誰負責停用離職成員的訪問。哪怕平臺界面很直觀，這些責任也應該落在文檔里，因為問題通常發生在人員變化和項目交接時。

***：創建、停用、輪換 Key，維護賬號狀態
項目負責人：確認模型選擇、查看項目用量、審批新增成員
開發成員：使用已分配配置，不私自傳播 Key
臨時協作者：只獲取當前任務所需的最小權限

• 權限越高，操作記錄越要清楚。
• 臨時協作者默認不接觸團隊主 Key。
• 模型切換和額度調整最好由項目負責人確認。

第五部分：新人接入先跑空目錄驗證

新成員拿到配置后，不要馬上在真實項目里運行 Codex。第一步應該進入一個空目錄，確認 CC Switch 當前配置卡、*ase **L、模型 ID 和 Key 都能正常工作。空目錄驗證的好處是風險低，失敗時也不會影響項目文件。

mkdir codex-team-on*oarding-check
cd codex-team-on*oarding-check
codex "請只說明當前目錄為空，不要創建、修改或刪除文件。"

如果這個短任務成功，再進入真實倉庫做只讀檢查，例如讓 Codex 解釋 README、項目結構或最近一次提交摘要。不要一上來就要求它改代碼、跑腳本或生成大文件。新人接入階段的目標是確認鏈路和習慣，而不是馬上完成復雜任務。

• 空目錄驗證通過后，再進入真實項目。
• 第一次真實項目任務建議只讀，不做寫入。
• 新人驗證結果要回填到團隊接入記錄中。

第六部分：團隊文檔要寫“字段來源”

很多接入文檔只寫“把這些字段填進去”，但沒有寫字段從哪里來。等三個月后需要維護時，沒人知道 *ase **L 是從哪一版說明復制的，模型 ID 是誰定的，Key 是個人的還是項目的。字段來源比字段本身更重要。

建議每個字段都寫四列：字段名、來源、用途、是否敏感。來源可以寫“靈能API控制臺接入說明”“項目負責人確認”“CI Secret 注入”“CC Switch 配置卡復制”。這樣新人知道去哪看，***也知道哪一項變更會影響團隊。

字段名：*ase **L
來源：靈能API控制臺接入說明
用途：API 中轉站請求入口
敏感性：非密字段，可寫示例

字段名：API Key
來源：***創建并分配
用途：請求鑒權
敏感性：敏感字段，只能安全保存

字段名：Model ID
來源：項目負責人確認
用途：指定 Codex 默認模型
敏感性：非密字段，但需要版本記錄

• 字段來源清楚，后續維護才不會靠猜。
• 敏感字段和非敏感字段要分開管理。
• 文檔中可以寫示例值，但不要**實密鑰。

第七部分：按項目做用量歸因

多項目并行時，最容易爭議的是用量。項目 A 做長上下文分析，項目 * 只是偶爾問幾句，如果共用同一枚 Key，就很難判斷成本來自哪里。按項目拆分 Key 和配置卡，可以讓用量歸因自然清楚。

用量歸因不一定要做得很復雜。小團隊可以每周看一次靈能API賬號狀態，把異常增長對應到項目、成員或自動化任務。大團隊可以在接入記錄里增加“成本中心”或“項目編號”。關鍵是不要等到賬單異常時才回頭補記錄。

• 項目 Key 用項目名命名，方便定位來源。
• 長任務要先說明用途，避免自動化重復觸發。
• 每周固定一次用量復盤，比月底集中排查更輕松。

第八部分：異常處理要有負責人

當 Codex 調用失敗時，團隊里如果沒有負責人，大家會同時改配置，最后很難判斷到底是哪一步修好的。建議把異常處理分成“接入問題、權限問題、用量問題、工具問題”四類，并為每類指定默認處理人。

例如 401 通常先由拿到 Key 的成員自查是否復制完整；403 由***確認靈能API賬號權限、余額和模型授權；404 由配置維護者檢查 *ase **L 和模型 ID；timeout 由項目負責人判斷是網絡、任務太長還是并發過高。分工清楚，處理速度會快很多。

401：使用者先檢查 Key 是否為空、過期或復制不完整
403：***檢查賬號權限、余額和模型授權
404：配置維護者檢查 *ase **L、路徑和模型 ID
timeout：項目負責人檢查任務長度、網絡和并發策略

• 同一時間只安排一個人調整配置，避免多人同時修改。
• 修復后要寫明改動點，而不是只說“好了”。
• 涉及憑證的問題，優先停用可疑 Key，再創建新 Key 驗證。

第九部分：離職、換設備和項目結束的回收流程

團隊協作里，最容易被忽略的是權限回收。成員離開項目、電腦丟失、外包交付結束、CI 平臺遷移，這些情況都應該觸發檢查。不要默認“沒人會再用”，也不要只刪除本地配置卡。真正需要處理的是憑證本身和文檔里的訪問范圍。

建議回收流程分三步：先確認這個成員或項目使用過哪些 Key；再在靈能API控制臺停用對應憑證；最后更新團隊文檔和 CC Switch 模板說明。如果停用后擔心影響其他人，說明當初 Key 拆分還不夠細，應該趁這次回收重新梳理。

• 離職：停用個人 Key，保留項目共享 Key。
• 換設備：舊設備配置清除后，再在新設備驗證。
• 項目結束：停用項目 Key，歸檔接入說明和用量記錄。
• 外包結束：停用臨時 Key，確認交付資料不含密鑰。

第十部分：建議保留一份接入清單

為了讓接入過程更穩定，可以把下面這份清單放進團隊知識庫。每次新增成員、新增項目或更換 Key 時，都按清單走一遍。清單不是為了增加負擔，而是為了讓常見錯誤提前暴露。

• 是否確認通過 https://www.lnsns.com/ 進入靈能API當前控制臺。
• 是否確認賬號、余額、模型權限和接口說明。
• 是否為當前成員或項目創建了獨立 Key。
• 是否在 CC Switch 中選擇了正確項目配置卡。
• 是否完成空目錄短任務驗證。
• 是否完成真實項目只讀驗證。
• 是否記錄負責人、用途、創建日期和回收條件。

? 收尾：把接入變成可交接的協作資產

Codex 接入 Claude中轉站或 API 中轉站，真正的價值不只是讓某臺電腦能跑起來，而是讓團隊能穩定、可控、可交接地使用。靈能API負責統一入口和憑證管理，CC Switch負責配置卡沉淀，團隊手冊負責把角色、字段、權限和異常處理講清楚。

如果你正在從個人試用過渡到團隊協作，可以先做四件事：拆分 Key、規范配置卡命名、寫字段來源、建立回收清單。把這四件事完成，后續無論是新人接入、項目遷移，還是模型切換，都會少很多臨時溝通和反復排查。