CodexSwitch

Appearance

CodexSwitch 配置切换模型 ​

更新时间：2026-04-01 作用：把 CodexSwitch 的主心智固定成“配置文件切换器”，避免后续继续摇摆

一句话 ​

CodexSwitch 应该像 hosts 切换工具一样工作：

  • 保存多套配置文件
  • 激活前预览
  • 激活时备份
  • 激活后记录当前状态
  • 支持回滚

官网和中转的关系 ​

对用户来说：

  • 官网不是特殊逻辑
  • 中转也不是特殊逻辑

它们都只是：

  • 一套 profile
  • 一组目标文件

区别只在于模板变量不同。

例如 Codex：

  • 官网 profile
    • config.toml
    • auth.json
  • 中转 profile
    • config.toml
    • auth.json

它们的差别通常只有：

  • base_url
  • wire_api
  • model
  • OPENAI_API_KEY

推荐的本地存储结构 ​

text
~/.codex-switch/
├── profiles/
│   ├── codex/
│   │   ├── openai-official/
│   │   │   ├── profile.json
│   │   │   ├── config.toml.tmpl
│   │   │   └── auth.json.tmpl
│   │   └── aimizy-relay/
│   │       ├── profile.json
│   │       ├── config.toml.tmpl
│   │       └── auth.json.tmpl
│   └── claude/
│       └── anthropic-official/
│           ├── profile.json
│           └── ...
├── state.json
└── backups/

这个结构的好处是：

  • 官网、中转、第三方一视同仁
  • 配置和元数据能一起保存
  • GUI 和 CLI 都能共用

不是所有文件都应该整文件替换 ​

这个点非常关键。

产品心智可以是“切换一套配置文件”，但实现上不能盲目整文件覆盖。

例如 Codex 当前的目标文件里：

  • ~/.codex/auth.json
    • 更适合整文件替换
  • ~/.codex/config.toml
    • 很可能需要保留本机状态

因为 config.toml 里通常还会混入：

  • 项目信任记录
  • notice 配置
  • features 开关

所以更合理的规则是：

  1. 纯配置文件
    • 用 full replace
  2. 混合文件
    • 用 managed patch
    • 只改 profile 负责的字段
    • 其余区块原样保留

激活流程 ​

text
选择 profile
→ 渲染模板
→ 预览目标文件和差异
→ 备份当前目标文件
→ 按策略写入新文件
→ 更新 state.json

其中“按策略写入”可能是：

  • full replace
  • managed patch

GUI 应该怎么长 ​

主界面应该围绕这个流程来设计：

  1. 左侧：profile 列表
  2. 中间：profile 编辑器
  3. 右侧：目标文件预览 / 差异 / 备份信息

关键不是“表单有几个输入框”，而是：

  • 这个 profile 会改哪些文件
  • 当前激活的是哪一套
  • 切换后能否回滚

第三方预设应该怎么做 ​

第三方兼容端不应该只是：

  • 给个空 base_url

而应该提供：

  • 默认模板
  • 兼容协议说明
  • 必填字段
  • 推荐模型
  • 目标文件说明

这样用户新建时更容易理解，也更容易保存。

运行时覆盖的地位 ​

Runtime Override 不是要删掉，但应该降级为：

  • 没有稳定文件模型时的兼容路径
  • 启动器集成时的补充路径

它不应该反过来变成产品主心智。