先定规则：团队接入不能只靠口头约定

个人开发时，配置写在哪里、Key 给谁用、模型怎么切换，往往可以靠自己记住。但团队项目不一样，一旦多人同时使用 Codex，就会出现配置来源不一致、Key 混用、额度难追踪、模型切换没有记录等问题。

团队接入的核心不是让每个人都随便复制一份配置，而是先确定一套分工：灵能API负责统一服务入口，CC Switch负责配置卡管理，项目负责人负责权限边界，开发成员只使用自己被授权的配置。

• *****：负责灵能API账号、Key、额度和模型权限。
• 项目负责人：负责项目级配置卡、预算规则和使用范围。
• 开发成员：只使用分配给自己的 Key 或配置卡，不私自转发。
• 排查负责人：记录错误码、复测结果和变更历史。

第一步：统一从灵能API确认服务侧信息

团队协作最怕每个人拿到的信息不一致。开始前先由***打开灵能API官网 https://www.lnsns.com/，统一确认账号状态、模型列表、可用额度和 Key 管理策略。不要让成员各自从聊天记录、旧文档或截图里找配置。

这一轮确认后，建议把非敏感信息写成团队接入说明：品牌、官网入口、*ase **L、模型选择原则、负责人和排查方式。完整 API Key 不写进说明文档。

• 统一确认当前可用模型，避免成员使用旧 Model ID。
• 统一确认额度和预算，避免测试阶段就消耗异常。
• 统一确认 Key 命名规范，方便后续追踪调用来源。
• 统一确认 *ase **L，避免不同成员填入不同入口。

第二步：按角色拆分 API Key，而不是全员共用

多人项目里最不推荐的做法，是所有成员共用同一条 Key。短期看省事，长期看问题很多：不知道是谁触发了高消耗请求，也不知道某个 Key 泄露后影响范围有多大。更合理的做法是按角色或项目拆分 Key。

推荐 Key 分组：
project-alpha-dev：项目 A 日常开发
project-alpha-test：项目 A 测试验证
project-alpha-admin：负责人排查和临时切换
personal-codex-check：个人短请求验证
server-codex-ci：远程服务器或自动任务专用

灵能API 的 Key 分工越清楚，后续成本追踪和安全处置越简单。不要等出问题以后才开始回忆“这条 Key 到底给过谁”。

• 个人开发 Key 和团队项目 Key 分开。
• 临时测试 Key 和长期工作 Key 分开。
• 远程服务器 Key 和本机终端 Key 分开。
• 离职、换项目或设备丢失时，能快速撤销对应 Key。

第三步：在 CC Switch 建立团队配置卡命名规范

CC Switch 适合管理多张配置卡，但如果命名随意，很快就会变成一堆“默认配置”“测试配置”“新配置”。团队接入时，先规定配置卡命名方式，让每个人一眼看出用途、项目和环境。

配置卡命名格式：
灵能API-Codex-项目名-环境-用途

示例：
灵能API-Codex-Alpha-Dev-日常开发
灵能API-Codex-Alpha-****-测试验证
灵能API-Codex-Alpha-De*ug-问题排查
灵能API-Codex-******-SSH-远程终端

命名规范看起来像小事，但它能减少大量沟通成本。成员截图给你看时，你只要看到卡片名，就知道它是不是当前项目应该使用的配置。

• 项目名用于区分不同业务。
• 环境用于区分本机、测试、远程服务器或容器。
• 用途用于区分日常开发、排查、迁移和备用模型。

️ **步：给每张团队卡填写一致字段

每张 CC Switch 团队配置卡，都应该遵循同样的字段规则：*ase **L 来自统一入口，Model ID 来自灵能API当前模型列表，API Key 来自对应角色或项目分组。不要让成员自己凭记忆填写。

团队字段模板：
*ase **L：https://www.lnsns.com/v1
Model ID：由***从灵能API当前模型列表确认
API Key：按项目或角色分配
备注：项目、环境、负责人、创建日期
禁止：完整 Key 出现在公开文档或群聊截图

团队字段一致，排查时就不会出现“你那里能用，我这里不能用，但我们都说自己配置正确”的情况。

• *ase **L 不由成员自行改写。
• Model ID 更新时，由负责人统一通知。
• API Key 分发只***安全渠道。
• 配置卡备注写清负责人，方便报错时快速找人。

第五步：每个成员都要做本机短请求验证

配置卡准备好以后，不要直接进入项目开发。每个成员先在自己的本机空目录里***短请求验证，确认当前终端、CC Switch配置卡和灵能API中转链路已经连通。

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

请只回复：团队 Codex API 中转站配置已生效。

短请求验证最好形成固定动作。团队里每次新增成员、换设备、换模型、换 Key，都先跑这条验证，再进入真实开发。

• 成员 A 成功，不代表成员 * 的本机环境也成功。
• 本机成功，不代表 WSL、SSH 或容器也成功。
• 短请求成功后再进入项目，失败就留在空目录排查。

第六步：真实项目第一轮只读，不直接修改

团队项目里，首次让 Codex 进入真实仓库时，不建议马上要求它改代码。先做只读分析，确认目录、技术栈、测试入口和敏感文件边界。这样可以避免新成员刚接入就误触生产配置。

请只读分析当前项目，不要修改文件。
请输出：
1. 项目技术栈
2. 关键目录结构
3. 测试命令入口
4. 需要避开的敏感文件
5. 适合新成员的第一个小任务

只读分析通过后，再让 Codex 执行局部任务。这样灵能API的中转能力、CC Switch配置和项目权限都经过了最低成本验证。

• 敏感目录包括 .env、secrets、私钥、备份、生产配置。
• 首次任务优先选择文档、测试或小范围修复。
• 不要让新成员第一次就发起全仓库重构。

第七步：建立团队复测记录，别只在群里说“我好了”

团队协作最需要的是可追踪。成员口头说“我这里好了”，对后续排查帮助有限。更好的方式是把环境、配置卡、模型、测试目录和结果写入一份复测记录。

复测记录字段：
成员：张三
环境：Windows PowerShell / WSL / SSH / 容器
配置卡：灵能API-Codex-Alpha-Dev-日常开发
模型：当前 Model ID
短请求：成功 / 失败
项目只读：成功 / 失败
备注：错误码或处理动作，不写完整 Key

这份复测记录可以很简单，但它让团队从“凭感觉排查”变成“按证据排查”。人一多，这点特别重要。

• 记录成功结果，方便确认谁已经完成接入。
• 记录失败结果，方便判断是否是共性问题。
• 记录模型和环境，方便定位不同终端差异。

第八步：多人共用时的常见故障处理

团队接入后的故障，很多不是单机问题，而是多人配置不一致造成的。处理时不要只看一个成员的终端，要把成功和失败的环境并排比较。

排查时优先找“差异”。谁成功、谁失败、环境有什么不同、卡片名是否一致、模型是否一致，这些信息比反复重装工具更有价值。

• 有人能用、有人不能用：检查成员本机终端是否读取了旧环境变量。
• 同一成员本机能用、容器不能用：检查容器内是否同步了必要配置。
• 所有成员同时 401：检查团队 Key 是否被撤销或复制错误。
• 所有成员同时 404：检查 *ase **L 或 Model ID 是否统一变更。
• 部分成员高频 timeout：检查网络出口、**、安全软件和任务体量。

第九步：给成本和模型切换设一条红线

团队使用 Codex API 中转站时，成本控制要提前设计。不是所有任务都需要高规格模型，也不是所有成员都应该随意切换模型。可以在灵能API侧按 Key 控制预算，在 CC Switch侧按配置卡区分用途。

这样做不是限制效率，而是让团队知道每一类任务该走哪张卡、消耗归到哪里。长期项目里，这会让灵能API的使用更可控。

• 日常问答和小修复使用基础稳定模型。
• 复杂重构、长上下文分析再切换高规格模型。
• 排查卡不承担长期开发任务，避免成本混入诊断记录。
• 高成本模型卡只给负责人或授权成员使用。

第十步：成员变更、项目结束和设备更换后的清理

团队配置不是一次性工作。成员离开项目、电脑更换、项目结束、临时服务器下线时，都应该清理对应 Key 和配置卡。否则旧配置会慢慢堆积，未来报错时很难判断哪条还在使用。

清理动作越及时，团队环境越干净。把这件事放进项目收尾清单里，比半年后翻旧配置舒服得多。

• 成员退出项目后，撤销或停用对应 Key。
• 项目结束后，归档 CC Switch 项目配置卡。
• 临时服务器下线后，删除服务器专用 Key。
• 模型策略变更后，统一更新团队说明和配置卡备注。

✅ 最后一份团队接入检查清单

团队接入 Codex API 中转站，真正要解决的是“多人可控地使用同一套能力”。把灵能API、CC Switch、Key 分工、配置卡命名和复测记录放进同一套流程里，团队协作会稳很多，也更适合长期项目使用。

• 已由负责人统一确认灵能API账号、模型、额度和 *ase **L。
• API Key 已按成员、项目、环境或用途拆分，不全员共用。
• CC Switch 配置卡命名已包含品牌、项目、环境和用途。
• 每位成员都完成空目录短请求验证。
• 真实项目第一轮只读扫描通过，没有触碰敏感文件。
• 团队复测记录已保存，错误码和处理动作可追踪。
• 模型切换和高成本任务已有授权规则。
• 成员变更、设备更换和项目结束时有清理流程。