团队共用 CCSwitch 配置怎么交接？
CCSwitch 配置能在一个人电脑上跑通，不代表团队换人后还能稳定使用。最容易出问题的不是安装步骤，而是 API 地址来源、Key 权限、默认模型、用途说明和配置文件版本没有交接清楚。交接做细，Codex 接入才不会变成口口相传。
适用场景：从个人可用到团队可维护
如果还没有完成首次配置，先看 注册后如何配置 CCSwitch。本文讨论的是另一类问题：新人接手项目时不知道哪个模型适合写代码，运营同事误用了高成本模型，测试环境和正式环境 API Key 混在一起，或者某人离职后没人知道配置文件放在哪里。
团队共用不等于所有人复制同一份 Key。更合理的做法是把配置拆成“可公开说明”和“敏感凭证”两部分。模型用途、默认项、适用任务、限制说明可以写进交接文档；Key、余额、权限和调用日志则由负责人管理。这样既能减少重复配置，也能避免权限失控。
操作步骤：把配置交接成一张表
1. 记录每个配置档的用途
先给配置档命名，例如“dev-codex-code”“ops-summary”“low-cost-test”。每个配置档写清 API 地址、模型名、适合任务、禁止任务、默认模型和负责人。不要只写“默认”或“备用”，因为三周后没人记得默认代表什么。多模型环境可以参考 CCSwitch 多模型配置自检，但交接文档要更偏向日常使用语言。
2. 分离 Key 和说明文档
说明文档可以放在团队知识库，Key 不要放进截图、群消息或公开仓库。如果需要让 Codex 辅助检查配置，先隐藏 Key 的中间部分，只保留前后几位用于核对。开发者 AI 调用涉及日志和权限时，可以结合 多人共用 AI 模型接口的权限和日志，把个人测试、项目测试和正式调用分开。
3. 用固定提示词验收交接
交接不是把文件发出去就结束。让接手人新开终端或重启工具，用三条固定提示词测试：短问答、代码解释、长文本总结。每条记录模型名、响应时间和失败表现。若 Codex 仍调用旧模型，可以按 CCSwitch 改配置但 Codex 仍用旧模型 的顺序检查保存状态、默认项、缓存和重启。
常见问题和避坑
第一，不要把“能用”的截图当交接文档。截图看不到环境变量、默认项和权限边界。第二，不要把所有成员都设成同一权限。新成员可以先用低额度或测试 Key，确认工作方式后再提升权限。第三，不要把模型名翻译成随意昵称，最好保留真实 ID，并在旁边写中文用途说明。
如果团队正在接手旧仓库，建议把 Codex 环境说明放进项目 onboarding 文档。相关思路可以参考 接手旧项目时怎么让 Codex 读懂仓库。CCSwitch 交接解决的是“模型调用入口一致”，项目上下文解决的是“让 AI 理解要改什么”。两件事都清楚，AI 自动化办公和代码协作才更稳。
检查清单：交接完成前逐项确认
- 每个配置档都有名称、用途、默认模型、负责人和适用任务。
- API Key 没有写入公开文档、截图、仓库或聊天记录。
- 测试 Key、项目 Key、正式 Key 的权限和额度不同，不混用。
- 新成员能独立完成保存、切换、重启和固定提示词测试。
- 调用日志能追踪到配置档、模型名、成员或项目，方便事后排查。
验收标准不是“大家都装好了”，而是任意一位新成员按文档能在 15 分钟内跑通测试，并能说清楚该用哪个模型、不能把 Key 放在哪里、调用失败时先查哪几项。达到这个标准后，团队再扩展 Codex 接入、AI API 接入和模型调用管理，返工会少很多。
交接演练：让新成员独立跑一遍
真正有效的交接，最好安排一次 20 分钟演练。负责人只提供文档和必要权限，不口头提醒，让新成员从安装、导入配置、选择模型、启动 Codex 到发送固定提示词完整走一遍。过程中记录卡点：找不到配置文件、模型名不知道选哪个、Key 权限不足、终端没有重启、旧默认项没清掉。卡点越具体，文档越容易补齐。
演练结束后，把结果写回交接表：通过的配置档、失败原因、修复动作、是否需要负责人授权。不要把这一步当作形式，因为团队扩员或项目交接时，最容易浪费时间的就是“我以为你知道”。把这些隐性经验写成明文，后面做开发者 AI 调用、AI 自动化办公或接口成本管理时，沟通成本会低很多。
权限变更和离职交接
人员变动时要检查两件事：旧成员是否还有不必要的 Key 权限，新成员是否拿到了正确的测试入口。不要只改群文档，还要在后台或管理记录里确认权限已经更新。若某个配置档长期没人负责，应先降级为只读说明，等负责人确认后再恢复使用。这样做看起来麻烦，但比后续追查异常调用更省时间。