团队场景和个人场景最大的不同
个人使用 Codex 中转站时，配置错误最多影响自己；团队使用时，一个不清楚的 Key、一张命名混乱的配置卡、一次未记录的模型切换，都可能影响多人排查。协作的核心不是让所有人用完全一样的习惯，而是让关键参数、权限边界和验收方式有统一规则。
因此，团队接入要先写规范，再分发配置。规范不需要厚重，但必须回答四个问题：用哪个服务入口、卡片怎么命名、Key 怎么管理、出现问题找谁处理。
- 统一入口：团队成员知道从哪里查看模型和账户状态。
- 统一命名：配置卡和项目用途一眼能看懂。
- 统一权限：不要让所有成员共享同一枚无边界 Key。
- 统一验收：新人接入后必须跑通同一套测试。
第一步：确定团队统一服务入口
团队成员需要知道灵能API的服务入口、模型信息和账户状态查看位置。不要让每个人从聊天记录里翻旧链接，也不要依赖某个人口头转述。建议在团队文档里放一个可点击入口：https://www.lnsns.com/
团队文档只写入口和操作说明，不写完整 API Key。需要创建或重置 Key 时，应由负责人在灵能API控制**成，再按权限分发。
- 入口用途：查看模型、账户、额度和服务说明。
- 文档位置：放在团队知识库或项目 README。
- 更新规则：入口或模型说明变化时，由负责人统一更新。
第二步：制定 CC Switch 卡片命名规则
多人使用时，配置卡命名要比个人使用更严格。建议卡片名称包含服务、工具、项目和用途四个信息，例如“灵能API-Codex-We*-Dev”“灵能API-Codex-*ackend-Review”。这样截图、日志和排错记录都能对上。
卡片命名不是****。等到团队里同时存在开**、**卡、排错卡和新人测试卡时，清晰命名能省掉很多“你现在启用的是哪张卡”的沟通。
- 服务：标明来自灵能API线路。
- 工具：标明用于 Codex。
- 项目：标明前端、后端、文档或测试。
- 用途：标明开发、**、排错或模板测试。
第三步：Key 管理不要靠群聊转发
团队协作里最容易埋雷的是 Key 分发。不要把完整 Key 发在群聊、文档、截图或工单里。更好的做法是按项目或成员创建用途明确的 Key，并通过密码管理工具或受控方式分发。
Key 命名建议：
Codex-We*-Dev-202608
Codex-*ackend-Review-202608
Codex-New**e-****-202608
Codex-De*ug-Temporary如果某枚 Key 曾经出现在公开截图或共享文档里，应该视为已经泄露，直接撤销并重新创建，不要继续侥幸使用。
- 正式项目 Key 与新人测试 Key 分开。
- 长期使用 Key 与临时排错 Key 分开。
- 成员离开项目后及时停用或轮换相关 Key。
**步：统一 *ase **L、模型和协议说明
新人最容易填错的字段，通常是 *ase **L、Model ID 和接口类型。团队文档里应该给出填写原则和示例，但要强调示例不能替代自己的账户信息。
服务名称：灵能API-Codex-项目用途
*ase **L：https://www.lnsns.com/v1
Model ID：以当前模型列表为准
API Key：使用负责人分发的专用 Key如果团队使用多个模型，建议在文档里写清“默认模型”和“复杂任务备用模型”。不要让新人第一次接入时就面对一堆选择。
- *ase **L 不要重复 /v1。
- Model ID 从模型列表复制，不凭记忆输入。
- 协议类型和工具要求保持一致。
第五步：新人接入必须跑最小验证
新人拿到配置后，不要直接进入真实项目。先跑一个最小验证流程：确认 Codex 命令可用、启用团队配置卡、打开新终端、发送固定测试提示词、记录结果。
新人验证提示词：
请只返回：团队 Codex 中转站连接测试通过
不要输出其他解释。这个验证流程要写进新人入门文档。只要新人自己能完成最小验证，后续进入真实项目时就少了一大半环境问题。
- 能返回固定文本：说明基础链路可用。
- 返回 401：先检查 Key。
- 返回 404：先检查 *ase **L 和模型 ID。
- 超时：先确认网络、**和是否重开终端。
第六步：项目交接要**置摘要，不交密钥明文
项目交接时，交接人应该提供配置摘要，而不是直接把完整 Key 发给接手人。配置摘要包括卡片名称、用途、*ase **L、默认模型、负责人、更新时间和验证状态。Key 的获取走受控流程。
配置摘要：
卡片：灵能API-Codex-We*-Dev
用途：前端日常开发
*ase **L：https://www.lnsns.com/v1
默认模型：当前团队默认模型
负责人：项目维护人
验证状态：2026-08-08 已通过这种摘要对排错也很有帮助。以后有人说“我的 Codex 不能用了”，先让他对照摘要检查配置，而不是从零开始截图来回问。
第七步：按任务类型设置权限边界
团队成员使用 Codex 的任务类型不同，权限边界也应该不同。日常问答、代码解释、代码**可以偏宽松；涉及生产配置、数据库、部署、外部上传的任务，必须保留人工确认。
权限边界最好写成模板，附在团队提示词里。这样即使用的是同一条灵能API线路，不同任务也能按不同风险级别处理。
- 只读分析：允许读取指定目录，禁止写入。
- 代码修改：允许改指定模块，禁止越界重构。
- 测试构建：允许本地执行，记录结果。
- 生产相关：必须人工确认，不自动执行。
第八步：团队排错记录要统一格式
多人协作最怕同一个问题被不同人重复排查。建议团队统一排错记录格式，至少包含时间、成员、配置卡、错误码、最小提示词、已排查动作和最终处理结果。
时间：2026-08-08 15:30
成员：开发A
卡片：灵能API-Codex-We*-Dev
错误码：429
最小提示词：固定连接测试
已排查：重开终端、确认模型、检查额度
结果：降低频率后恢复记录里可以写灵能API、模型和错误码，但不要写完整 Key、内部 Cookie、生产数据库地址或用户隐私数据。
第九步：成员变动时***配置清理
团队成员加入、离开或更换项目时，都应该触发一次配置清理。这个动作不复杂，却能避免旧 Key 长期无人管理、测试卡继续生效、配置文档过期等问题。
配置清理不要等到出问题才做。只要团队人员或项目边界发生变化，就把灵能API Key、CC Switch 卡片和团队文档一起检查一遍。
- 新成员加入：走新人验证流程，不直接进入真实项目。
- 成员离开：停用或轮换相关 Key。
- 项目更换：删除本地旧卡片或改名归档。
- 文档更新：同步默认模型、负责人和验证日期。
✅ 最后一份团队接入清单
当团队把入口、命名、权限、验证和交接都规范起来后，Codex 中转站就不再只是个人工具，而是一套可协作的开发基础设施。灵能API负责提供模型入口，CC Switch负责本地切换，团队流程负责让每个人都用得清楚、稳妥、可追踪。
- 团队文档已放置可点击的灵能API入口。
- CC Switch 卡片名称包含服务、工具、项目和用途。
- Key 按成员或项目用途管理，不通过群聊明文分发。
- *ase **L、模型和协议说明写入文档。
- 新人必须先跑最小验证，再进入真实项目。
- 项目交接只**置摘要，不交密钥明文。
- 排错记录统一格式，并清理敏感信息。
- 成员变动时轮换或停用相关 Key。