CCSwitch 团队共享配置怎么命名才不乱？
团队共享 CCSwitch 配置时，应把环境、用途、模型接口、权限等级和有效期写进 profile 命名与备注，避免误用生产 Key 或过期备用项。
真实问题
CCSwitch 配置一开始通常只有两三个 profile，团队扩张后很快会变成一串看不懂的名称：test、new-api、backup、fast、prod2。新人不知道哪个能用于生产，老成员也可能在排查时临时切错模型。一次客服摘要工具故障中，测试 profile 被误用于线上，输出质量和限流表现都变了，排查半天才发现不是代码问题，而是 profile 名称没有环境和权限标识。
永沃云枢在 https://ai.jn83.com 处理 AI API 接入和 Codex 接入咨询时，会把命名规范当作模型调用管理的一部分。命名不是形式主义，它决定了出错时能不能快速判断影响范围。
适用场景
适用于多人共用 CCSwitch 配置、同一项目接入多个 AI 模型接口、开发测试生产环境分离、备用供应商切换和临时压测。也适用于使用“GPT 中转”这类新手搜索词找到教程的用户：更规范的说法是 AI 模型接口接入与调用管理，核心是把用途、环境和权限写清楚。
如果团队会让 Codex 修改配置文件、生成 profile 或检查调用日志，更需要统一命名。否则 Codex 只能看到一堆模糊名称，很难判断哪些配置可以改、哪些只能读。
操作步骤
第一步，设计命名格式，例如 env-purpose-model-permission-expiry，可写成 prod-support-fast-readonly-202609 或 dev-batch-longctx-write-202608。第二步，在备注里补充 base_url 类别、可用模型、额度来源、负责人、使用场景和禁用场景。第三步，把生产 profile、测试 profile、备用 profile 分组存放，不要混在同一段列表里。第四步，给临时 profile 加有效期，到期前检查是否删除或续期。第五步，团队新增配置时必须经过双人复核，至少确认环境、权限、模型名和限流策略。
对于已经混乱的配置，不要一次性全改。先导出备份，再做映射表：旧名称、新名称、用途、是否仍在使用、迁移负责人。可以让 Codex 根据映射表生成重命名建议，但执行前要人工核对 Key 和 base_url，避免把可用配置改坏。
排错路径
如果线上突然出现模型行为变化，先查最近使用的 profile 名称和修改时间。如果名称里没有环境标识，就去调用日志里找 base_url、模型名和账户来源。如果备用 profile 切换失败，检查是否过期、额度是否不足、权限是否只读。如果成员说“我以为这个是测试”，说明命名没有表达清楚，应该补环境前缀和风险等级。
命名规范还要配合权限边界。不要把生产写权限 Key 放进“demo”或“test”名称里，也不要把只读用途的 profile 用于批量写入任务。AI 自动化办公场景里，批量生成、批量发送和批量入库最好使用不同权限等级。
常见问题 / 避坑
问：名称很长会不会不好用？可以长一点，但要稳定，短名看似方便，出错时成本更高。问：是否要在名称里放供应商全名？不一定，可以放接口类别和模型族，敏感账号信息放备注或受控文档。问：临时压测 profile 能不能不登记？不建议，临时项最容易遗留。问：Codex 能否自动清理过期配置？可以生成清单和建议，不应直接删除生产配置。
检查清单
检查 profile 名称包含环境、用途、模型或接口类别、权限和有效期；检查备注包含负责人和禁用场景；检查生产、测试、备用分组清楚；检查临时项有到期处理；检查调用日志能反查 profile；检查 Codex 可写范围不包含敏感 Key；检查团队成员能根据名称判断是否可用于线上。完成后，再把规范写进项目 README 或运维手册。
验收与复盘
命名规范落地后，可以抽三名团队成员做一次盲测：只看 profile 名称和备注，让他们判断是否能用于生产、是否可写、到期时间和负责人是谁。如果有人判断错误，就说明名称或备注仍不够清楚。复盘时要把误用场景写进规范，例如“临时压测项不得进入默认列表”“生产写权限不得使用 demo 名称”“备用项必须每周跑一次样本请求”。这些规则看似琐碎，但能减少 AI API 接入和模型调用管理中的人为误切换。后续让 Codex 检查配置时，也能根据命名规则给出更明确的风险提示。
规范发布后，还要安排一次旧配置清理窗口，把无人负责、无法确认用途、超过有效期的 profile 标为待删除，而不是继续留在默认列表里。清理前先导出备份，清理后跑一组样本请求，确认常用 AI API 接入、Codex 接入和自动化办公任务仍能按预期选择模型。