团队接入和个人接入不是一回事

个人接入时，关注点通常只有一个：能不能把 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、规范配置卡命名、写字段来源、建立回收清单。把这四件事完成，后续无论是新人接入、项目迁移，还是模型切换，都会少很多临时沟通和反复排查。