如果你手上同时有 Codex、Claude Code 和 OpenCode 这些终端里的 AI 编程工具大概能体会我过去半年的状态每个工具都要独立的 API Key有的还带自建网关地址模型一更新配置就得全部翻一遍。尤其是 Codex 这种订阅制付费的 AI 编程软件配错一个参数整条链路直接断掉排查了半天发现根本不是代码问题而是某个配置文件里多了一段路径。我被这个问题折磨了快两个月后来靠 cc-switch 和 sdcb/chats 两个开源项目把手头的 AI 编程入口收敛成了一整套可以统一配置、统一切换、统一对话的基础设施。这篇就是把整套搭建过程、关键配置和踩坑记录完整写下来给想自建 AI 编程基础设施的人做一个参考。1. 为什么我需要这样一套 AI 编程基础设施1.1 我的日常 AI 编程工具链先说下环境。我日常使用的 AI 编程工具主要有三个Codex订阅制的 AI 编程软件负责主要的代码生成和 review质量稳定但配置最严格稍微不对就被 401 拦下。Claude Code终端下的重构利器适合跨文件改动、解释老项目逻辑。OpenCode开源、可定制我经常拿它跑自定义 agent 流程配合脚本能玩出不少花样。这三个工具各有各的配置文件有的在~/.codex/下有的读环境变量还有的在项目目录里塞一份.env。API Key 管理方式完全不在一个体系里导致我每周都要花不少时间处理切配置这件事。1.2 我需要的不是更多工具而是一层统一调度我想要的其实很简单密钥统一管理不要散落在十几个配置文件里。想切换模型或者服务商时一条命令就能完成。有一个独立的对话窗口能把所有模型拉进来对比而不是每次都在终端里来回试。团队协作时其他人不用再找我拿 key也不应该看到明文密钥。这些需求拼在一起就是一套 AI 编程基础设施底层是各家模型的 API中间层是配置切换管理和网关上层是一个统一的交互入口。1.3 选型对比后的结论我考虑过自己写切换脚本也试过一些在线聚合平台最后还是定了 cc-switch sdcb/chats 的组合。cc-switch 专注做配置切换不碰模型请求不拖一个沉重的服务。sdcb/chats 提供了一套自托管的聊天界面支持 OpenAI 兼容接口部署成本低。两个工具都没锁死在某个云厂商后续换模型或者接本地模型都很方便。下面按两层来展开先说 cc-switch 这层配置切换再说 sdcb/chats 这层统一入口。2. cc-switch配置切换层挑大梁的部分2.1 cc-switch 到底帮你管理什么cc-switch 从名字就能看出来核心动作是切换配置。它本质上是一个面向 AI 编程工具的配置管理器。目前的 AI 编程工具无论终端版还是 IDE 插件版最终需要的配置无非这几项providerOpenAI、Anthropic还是本地网关。api_key对应服务商的密钥。model具体模型名比如 gpt-4o、claude-sonnet-4。base_url请求地址自建网关时尤其关键。cc-switch 把这些东西抽象成一个档案每个服务商对应一份档案。你执行切换的时候它会把指定档案的内容写入目标工具的配置文件下次目标工具启动时读取到的就是新配置。2.2 安装与初始化我使用的是命令行版本。安装不复杂把它放到PATH里然后做一次初始化cc-switch init --config-dir ~/.config/cc-switchinit 会创建配置目录和一个空的主配置。接着就可以添加服务商了cc-switch provider add openai \ --api-key sk-xxxx \ --base-url https://api.openai.com \ --model gpt-4o cc-switch provider add internal \ --api-key sk-local \ --base-url http://127.0.0.1:4000 \ --model qwen2.5-coder:32b命令执行完cc-switch 会把这些档案保存在自己的配置目录里。查看已添加的服务商cc-switch provider list这里有个很重要的细节--base-url建议填服务商提供的根地址不要填带/v1的完整路径。绝大多数工具会自动拼上/v1/chat/completions你多填一段反而会导致 404。这个我后面踩坑的时候还会提。2.3 从档案切到工具cc-switch 的切换动作是写入目标工具的配置。以 Codex 为例它的配置通常落在~/.codex/config.toml或类似位置。执行cc-switch use internal之后 cc-switch 会把 internal 这个档案的 provider、api_key、base_url、model 写进 Codex 的配置文件。这时候 Codex 就会走内部网关使用 qwen2.5-coder 模型。如果你想临时看一眼当前档案的环境变量可以导出source (cc-switch env internal)这个命令在集成里很有用后面我会讲怎么用它把 sdcb/chats 也串起来。除了 Codexcc-switch 对 OpenCode 这类开源终端工具同样有效。OpenCode 通常在项目目录维护自己的配置执行切换后cc-switch 也会更新对应的配置写入位置。这样我跑自定义 agent 流程时用的就是当前选定的服务商不会出现 Codex 走新配置、OpenCode 还停在旧配置上这种割裂状态。2.4 GUI 版本和命令行怎么选cc-switch 也维护了一个图形界面里面是列表式的服务商管理点击一下就能切。上手门槛极低适合不想记命令的中度用户。我选择命令行的原因有三个可以脚本化。我把切换命令写进了 shell 别名一条命令就能切到目标服务商。便于排查。命令行生成的文件路径清晰出问题时能快速定位配置内容。便于集成。无论是 CI 里还是本地服务进程重启时都能被脚本调度。如果你只是自己在笔记本上用 CodexGUI 会更友好。团队协作的场景我还是推荐命令行方便统一管理和审计。3. sdcb/chats把模型对话入口统一起来3.1 为什么我需要一个聊天界面AI 编程工具大多跑在终端里输入提示词、等回复、出补丁。缺点很明显它只处理当前任务不会把不同模型聚到一起也没法保留一个持续对话的上下文。sdcb/chats 解决的就是这个入口问题。它本质上是自托管的聊天应用支持 OpenAI 兼容接口可以同时配置多个模型后端。同一个问题发给不同模型答案并排出现在界面里立刻能看出哪个模型更适合当前场景。这个能力在日常写代码时很实用。比如我拿到一段老代码要重构先在 Codex 里做一次再把同一段代码贴到 sdcb/chats 里选 Claude两边的改法对比下来心里就有数了。3.2 Docker 部署与目录规划我用 Docker 部署 sdcb/chats这样不会弄脏本机环境升级也方便。先准备一个数据目录mkdir -p ~/chats/data然后启动容器docker run -d \ --name chats \ --restart unless-stopped \ -p 8080:8080 \ -v ~/chats/data:/app/data \ -e STORAGE_ENGINEsqlite \ -e DEFAULT_MODELSgpt-4o,claude-sonnet-4 \ sdcb/chats:latest启动后浏览器打开http://localhost:8080注册一个管理员账号接着就可以开始添加模型了。数据都放在~/chats/data里使用 sqlite 存储会话记录和模型配置都在本地不会被动同步到第三方。3.3 在 sdcb/chats 里接入不同的模型sdcb/chats 支持 OpenAI 兼容接口这意味着只要你的模型服务商提供了/v1/chat/completions都可以接进来。我在后台维护的三条接入配置模型名称Base URL说明gpt-4ohttp://127.0.0.1:4000/v1通过本地网关访问 OpenAIclaude-sonnethttp://127.0.0.1:4000/v1同样走本地网关但模型名指向 Claudeqwen2.5-coderhttp://127.0.0.1:11434/v1本地 Ollama 服务适合私有代码分析注意表格里的 Base URL 带上了/v1这是 sdcb/chats 的要求。它作为客户端直接调用兼容接口所以需要完整路径。这一点和 cc-switch 里填根地址是两回事别混。3.4 用户与权限管理如果只是自己用单管理员就够了。团队阶段sdcb/chats 也支持多个用户每个用户可以用各自独立的 API Key。这样就不会出现一个人换了 key全队跟着断线的情况。我的建议是管理员负责维护模型列表普通用户只配置自己的 Key。模型列表固定住以后切换模型在界面上点一下就能完成成本低到几乎可以忽略。4. 把 cc-switch 和 sdcb/chats 串成一套基础设施4.1 两条线各司其职但需要一条接口线cc-switch 管的是AI 编程工具侧sdcb/chats 管的是对话入口侧。两者不需要互相调用但可以设计一个统一的接口线让它们共享同一份环境变量。具体做法是cc-switch 里维护所有服务商档案。切换时把当前档案导出成环境变量。sdcb/chats 启动时读取这些环境变量初始化对应的模型连接。在 shell 里我用别名处理整个流程alias switch-to-openaicc-switch use openai source (cc-switch env openai) alias switch-to-internalcc-switch use internal source (cc-switch env internal)这样我切换 Codex 的同时也会准备新的环境变量。如果 sdcb/chats 是本地服务只需要重启容器并传入新环境变量即可。4.2 一个脚本化的切换示例我日常工作流里有一个脚本化任务用来做模型回归测试。流程是# 切到 openai 档案并把环境变量传给 chats cc-switch use openai env $(cc-switch env openai | grep -v ^# | xargs) \ docker run -d --rm -p 8080:8080 sdcb/chats:latest这样每次运行都会用 openai 的配置启动一个临时聊天容器测完即弃。如果你有多套服务商需要批量验证把上面的命令包进 for 循环就可以。4.3 端口、服务与网络规划这类基础设施最容易在端口和服务上出问题。cc-switch 不占用端口它只是写配置文件不存在端口冲突。sdcb/chats 默认监听 8080如果你本机其他服务占了 8080映射外部端口改一下就行。聊天界面尽量别直接暴露到公网。我自己用的时候只监听本地地址跨设备访问时也会限制在可信内网环境内进行而不是把 8080 直接开在有公网 IP 的机器上。如果多人共用一个 sdcb/chats建议前面再加一层反向代理同时开启 HTTPS。这样 API Key 不会以明文形式在网络上飘。5. 真实环境里踩过的坑与排查思路5.1 切换完配置后工具没有生效有一次我执行了cc-switch use internal然后启动 Codex但 Codex 仍然在请求之前的 openai 地址密钥也不对直接报 401。排查顺序很重要。我先看了 cc-switch 生成的配置文件发现内容没问题目标地址、密钥都已经换成 internal 的了。那问题必然出在工具侧。再一查Codex 做了配置缓存读的是缓存而不是最新文件。我把缓存目录清理后重启 Codex才真正读到了新配置。这个坑主要出现在频繁切换服务商的场景里切换后一定要确认工具是否重新加载了配置必要时重启进程或清除缓存。5.2 base_url 多了一段路径导致 404cc-switch 里添加服务商时我一开始填的是--base-url http://127.0.0.1:4000/api/v1Codex 拿到的请求 URL 变成了http://127.0.0.1:4000/api/v1/v1/chat/completions一直 404。后来我把 cc-switch 里的 base_url 改回根地址cc-switch provider update internal --base-url http://127.0.0.1:4000一切恢复正常。这个原则同样适用于大多数终端 AI 编程工具base_url 填根工具自己会拼版本路径。5.3 上下文窗口限制在聊天界面里才暴露cc-switch 切换模型时工具层面通常不会检查上下文窗口大小但在 sdcb/chats 里你会发现模型一换之前的对话历史和上下文的 token 数就会发生变化超出窗口就直接截断。原因是不同模型支持的上下文长度不一样某些本地模型只有 8K 上下文而 gpt-4o 可能有 128K。我的做法是在 sdcb/chats 的模型配置里设置一个相对保守的 max_tokens并且大段代码不进聊天框先让 Codex 做初步处理再把摘要贴给 sdcb/chats 分析。5.4 团队共用时的密钥隔离问题如果直接把一个 key 放到共享的 cc-switch 配置里等于把密钥发给所有人。这相当危险。我的处理方式cc-switch 配置目录设置成只有本用户可读权限 600。key 放在单独的配置文件中不入 git。sdcb/chats 让团队成员各自配自己的 API Key管理员只维护模型列表。这样每个成员手里的 key 是自己的泄露范围可控。5.5 常见问题速查表现象大概率原因处理方式401 unauthorizedAPI Key 错误或过期在 cc-switch provider 中更新 key404 not foundbase_url 多拼了 /v1改填根地址一直用的旧模型配置缓存重启工具进程并清理缓存聊天界面里长文本被截断上下文窗口限制降低 max_tokens 或换长上下文模型多人共用一个 key权限设计不合理分散到个人用户6. 这套设施跑起来之后的个人体会搭建完成到现在我最明显的感受是切换成本下来了。之前我总是在配置文件里翻关键字现在只需要cc-switch use xxxx一条命令然后该干嘛干嘛。和模型对话也不再依赖某个工具的终端sdcb/chats 会把所有后端模型的回复放在一个地方对比起来非常直观。如果接下来要扩展我会把更多兼容端点统一接进来再把团队里常用的模型指标做成可视化面板。整体上这套基础设施的价值在于把模型服务商、API Key、对话入口都收敛到一个可控的位置让我可以把注意力放回写代码而不是维护一堆脆弱的配置。这里面每一条都是我实际跑过的路径希望你能少踩几个坑。