企业官网建设流程全解析

我最近把自己的开发机彻底重装了一遍，导火索是 Claude Code、Codex、OpenCode 这三个AI编程助手在一台机器上互相打架。Claude Code 要 Node 18 以上，Codex 的某些版本对 Node 版本特别敏感，OpenCode 自己又带一套运行环境，再加上系统原本的 Python、全局 npm 包和一堆历史遗留的 PATH 配置，打开终端就是一团乱麻。有一次我只是顺手升级了全局 Node，Claude Code 直接罢工，Codex 又冒出一串依赖错误，OpenCode 倒是活着，但它的配置目录和另外两个工具的文件被我自己改得乱七八糟，彻底分不清谁是谁了。

这个标题里的核心诉求，说白了就是：把这三个工具全部装进 Docker 容器，宿主机只留一个 Docker Desktop，所有脏环境、版本冲突、密钥文件都在容器里解决。这篇文章我会把完整的搭建过程、docker-compose 配置、常见报错的排查链路都写出来，适合那些不想让 AI 编程助手污染本机环境、又想同时体验三个工具的开发者。无论你是刚接触这些 CLI 的新手，还是已经在用其中某一个、想补全另两个的老手，照着抄都能少踩不少坑。

1. 三个助手一台机，乱到我决定用Docker收拾残局

1.1 它们各自是什么，性格如何

先说清楚三个工具的分工，不然很多人根本不知道为什么要在一台机器上同时装它们。

Claude Code 是 Anthropic 官方的终端编程助手，交互式命令行界面，特点是上下文理解能力强、适合长时间对话式重构，可以直接在终端里帮你执行命令、改文件。现在很多人把它接到 VSCode 里，配合官方插件在编辑器里对话，体验更顺。这个工具我主要用来做大型文件的重构和代码解释。

Codex 是 OpenAI 的编程代理，严格来说它不只是一个补全工具，而是一个能操作文件、跑命令的 agent。它和 Claude Code 的定位很像，但工程化做得更稳，尤其是多文件修改时的任务拆分逻辑。而且 Codex 现在允许通过配置文件接入第三方模型，比如把 DeepSeek 的兼容接口挂进去，直接用 deepseek 的模型来跑 Codex 的流程，这一点后面我会展开讲。

OpenCode 是另一个很火的终端 AI 编程助手，核心卖点是多模型聚合，一个 TUI 界面里可以切换 OpenAI、Anthropic、DeepSeek、本地模型等多家供应商。它自带 Node 和 Go 组件，安装方式比较特殊，官方推荐一条 curl 安装脚本。OpenCode 有官网控制台的免费额度，也有 Go 套餐，问题在于免费额度的使用边界很严，后面报错章节我会专门说。

这三个工具的定位有重叠，但又各有侧重，组合起来确实能覆盖大部分日常编程场景。可问题就在，它们都依赖各自的运行时和配置目录，硬塞在一台机器里，迟早出事。

1.2 本地直装的典型事故现场

我最初是老老实实一个一个装的，结果遇到的坑可以列一长串。

首先是 Node 版本地狱。Claude Code 是 npm 全局包，建议用 Node 18+，但某些 Codex 版本在 Node 20 以下的兼容性很怪，OpenCode 则对 Node 版本没有那么挑剔，但它内部还会调用 Go 的二进制文件。三个工具对运行时要求不完全一致，导致我想用一个 nvm 切来切去，切完这个那个又出问题，很折磨人。

其次是配置目录的互相污染。Claude Code 的配置在~/.claude，Codex 的配置在~/.codex，OpenCode 在~/.config/opencode，表面看互不干涉，可一旦你用了配套的切换工具（比如 cc-switch），它会把三者的配置统一管理。这时候只要版本不匹配，很容易出现 A 工具写坏了 B 工具的配置，错误信息还指向 B 工具自己的 bug，排查起来非常费劲。

再就是密钥文件的管理混乱。三个工具都支持 API key 或 OAuth 登录，但密钥文件散落在不同的目录，备份时漏一个，重装系统后就全没了。我上次就是重装后忘了备份~/.codex里的登录态，结果要重新登录一遍，还要重新配置第三方模型。

最后是系统本身的脆弱性。我在宿主机上还跑着 MySQL 和 Redis 的本地服务，为了给 AI 助手腾端口，还要改各种配置文件。真到了这一步，我已经不是在用工具，而是在伺候工具了。

1.3 Docker方案到底解决了什么问题

用 Docker 之后，这些问题全部被隔离在容器内部。

核心思路是构建一个"AI 编程助手开发容器"，里面装好 Node、Git、三个 CLI 工具，通过 docker-compose 管理。宿主机上只需要安装一个 Docker Desktop，再用 VSCode 的 Dev Containers 插件附着到容器里写代码，所有终端命令都跑在容器内。

这样做的好处有三个。第一是环境可复现，Dockerfile 写清楚每一步，任何一台机器上拉下来 build 就能用，不存在"我这台能跑你那台跑不了"的问题。第二是干净，宿主机不会被污染，升级 Node、装新工具都只在容器里发生。第三是回滚容易，容器坏了直接删掉重建，登录态和数据用数据卷保留，也不会丢。

当然，这个方案也有代价：多了一层 Docker 抽象，初次配置有一定学习成本，运行时占用的内存也会更多。但对经常被 AI 编程助手环境折腾的人来说，这个代价完全值得。

2. 宿主机先过Docker这一关：Desktop安装与启动失败的完整链路

既然要用 Docker，宿主机上第一步就是把 Docker 跑起来。这一步看着简单，实际上是很多人第一次卡住的地方，尤其是 Windows 平台上，热搜词里那句 "virtualization support not detected" 我见得太多。

2.1 装之前，按这个清单检查

我建议安装 Docker Desktop 之前，先花五分钟过一遍清单，免得装完启动才发现问题。

• Windows 系统：确认 CPU 虚拟化已经在 BIOS 里开启，VT-x 或 AMD-V 必须打开；Windows 功能里"虚拟机平台"和"Hyper-V"两个选项要勾上。如果不想用 Hyper-V，可以只用 WSL2 后端，但"虚拟机平台"仍然需要。
• macOS 系统：Apple Silicon 芯片直接装最新版 Docker Desktop 就行；Intel 芯片的老机器要确认 macOS 版本在官方支持列表里，否则跑不起来。
• Linux 系统：直接安装 docker engine 和 docker compose 插件，不需要 Desktop。安装完成后把当前用户加进 docker 组，否则每条命令都要 sudo，非常影响体验。

很多人以为 Docker Desktop 装完就能用，其实它依赖 Windows 的虚拟化功能。如果系统里装了 VMware、VirtualBox 之类的虚拟机软件，还可能抢占虚拟化资源，导致 Docker Desktop 启动时检测不到虚拟化支持。

2.2 Virtualization support not detected 的正确排查顺序

Docker Desktop 启动失败并提示 virtualisation support wasn't detected 时，不要急着重装，按下面的顺序排查。

先用系统自带的工具确认虚拟化到底开没开。Windows 下可以打开命令提示符，执行systeminfo，看输出里有没有 "Hyper-V 要求" 这一段，如果显示 "检测到虚拟机监控程序" 或者列出了虚拟化固件，说明 BIOS 层没问题。如果显示 "未检测到" 但有 "虚拟化已启用" 字样，那大概率是 Hyper-V 组件没开，去"启用或关闭 Windows 功能"里勾选"虚拟机平台"和"Hyper-V"，重启再试。

BIOS 层面如果确认没开虚拟化，就需要重启进 BIOS，找到 Intel Virtualization Technology 或 AMD SVM Mode，设置为 Enabled。这一步在笔记本上容易被忽略，因为很多电脑默认是关的。

还有一种情况是 WSL2 后端异常。Docker Desktop 设置里如果选了 WSL2，而 WSL 本身没有安装或内核版本太旧，也会报类似错误。处理办法：先用管理员权限打开 PowerShell，执行wsl --update更新 WSL 内核，再执行wsl --status确认默认版本是 2。如果还是没有，可以wsl --shutdown重启 WSL 服务。

实测下来，90% 的启动失败都能通过"BIOS 开启虚拟化 + 启用 Windows 虚拟机平台 + 更新 WSL"这条链路解决。只有极少数是 Docker Desktop 安装包损坏导致的，那种情况才需要卸载重装。

2.3 顺手把镜像源和基础工具配好

Docker Desktop 能正常启动之后，我建议先把镜像源配置了。直接拉官方镜像在某些网络环境下会比较慢，可以打开 Docker Desktop 的 Settings，切到 Docker Engine 标签，在配置 JSON 里加上 registry-mirrors 字段，填入可用的镜像加速地址，保存后 Docker 会自动重启。

这一步不是必须的，但如果拉镜像很慢，它能让后面的流程顺畅很多。配置 JSON 大概长这样：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com" ] }

注意，镜像源只影响 Docker Hub 的镜像拉取速度，不影响容器内联网。容器内部的网络请求（比如 AI 助手的 API 调用）走的是宿主机网络，这是两码事，别混在一起。

基础工具方面，我建议宿主机上装好 Git 和 VSCode。VSCode 要装两个扩展：Dev Containers 和 Docker，这两个是后面附着到容器里用的关键。其他乱七八糟的依赖都不用装，全部留给容器。

3. 用一份Dockerfile装下三个AI助手

宿主机搞定了，接下来是重头戏：把 Claude Code、Codex、OpenCode 装进同一个容器。

3.1 基础镜像与安装脚本设计

我选的基础镜像是node:20-slim。原因很简单：Claude Code 和 Codex 都是 npm 包，装它们必须有 Node；OpenCode 官方安装脚本也会自动处理 Node 依赖，所以直接用一个带 Node 20 的 Debian 精简镜像最省事。如果你后面想跑更多系统工具，可以换ubuntu:22.04再手动装 Node，但没必要，slim 版本已经够用。

Dockerfile 里要装的基础工具包括 git、curl、unzip、ca-certificates，这些是安装脚本和日常使用都少不了的。然后依次装三个助手：

FROM node:20-slim RUN apt-get update && apt-get install -y git curl unzip ca-certificates \ && rm -rf /var/lib/apt/lists/* # Claude Code RUN npm install -g @anthropic-ai/claude-code # Codex RUN npm install -g @openai/codex # OpenCode，官方推荐 curl 脚本安装 RUN curl -fsSL https://opencode.ai/install | bash ENV PATH="/root/.opencode/bin:$PATH" WORKDIR /workspace CMD ["/bin/bash"]

这里有个容易踩的坑：OpenCode 的官方安装脚本会把二进制装到~/.opencode/bin，如果不用 ENV 把路径加进 PATH，容器里敲opencode会提示命令不存在。我一开始就漏了这一步，折腾了半天才发现。

另外，npm 全局安装默认路径在/usr/local/bin，所以 Claude Code 和 Codex 不需要额外配 PATH，OpenCode 单独处理即可。

3.2 Claude Code：装、升级、登录这一套

Claude Code 的安装最没悬念，npm 全局装完就能用。需要留意的是版本升级问题，Claude Code 更新很频繁，有时候你昨天装的版本今天就提示有新版本。在容器里别用npm update -g去升，官方提供了内置命令，实测在容器内执行claude update最省心，它会自动处理。

首次运行需要登录，流程是终端里直接执行claude，它会打印一个授权链接，在浏览器里登录后回填授权码。容器内没有浏览器，所以这个流程要稍微绕一下，但 Docker 容器有个好处，只要你不是用docker run --rm一次性启动，登录态会写在容器文件系统里。配合数据卷挂载，容器重建后登录态还能保住，后面我会说具体挂载方案。

如果你用的是 API key 而不是 OAuth 登录，那就更简单，在容器环境变量里设置ANTHROPIC_API_KEY即可。我个人的习惯是两种方式都留着：日常开发用 OAuth 登录，CI 或脚本里用 API key 环境变量。

Claude Code 的配置目录在/root/.claude，里面存了配置文件、登录凭证和历史命令记录。如果需要精细控制模型，可以在~/.claude/settings.json里指定 model、system prompt 等字段。我一般会配一个permissions字段，允许它自动执行一些无风险的终端命令，减少交互确认。

3.3 Codex：配置第三方模型（以DeepSeek为例）

Codex 官方默认是绑定 ChatGPT 账号的，但很多人更关心的是怎么把第三方模型接进去。Codex 的配置目录在~/.codex，核心文件是config.toml。配置文件里可以声明多个model_providers，每个 provider 指定base_url和env_key，然后在model字段里选用。

这里以 DeepSeek 为例，先到 DeepSeek 开放平台申请一个 API key，然后这样配置：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY"

配置好之后，在容器环境变量里加上DEEPSEEK_API_KEY=你的key，执行codex就能走 DeepSeek 的接口了。这个配置的意义在于，Codex 的外层工程能力（文件操作、命令执行、任务拆解）没有变，只是底层模型换成了自己有额度且用得起的那一个。

需要注意，Codex 对不同模型的协议兼容程度不一样。实测下来，DeepSeek 的接口对 OpenAI 兼容做得比较好，接入成功率很高。但如果你接的模型不完全兼容 OpenAI 的 message 协议，Codex 可能会在某些步骤上报错，这时候优先确认 base_url 的路径后缀是不是/v1，以及模型名是否真实存在。热搜词里那个 "gpt-5.6-sol not supported" 的报错，就是配置里填了一个不存在的模型名导致的，后面排查章节我会细讲。

3.4 OpenCode：安装、免费额度边界与Go套餐

OpenCode 的安装方式刚才已经写了，curl 脚本装完会带一个 TUI 界面。它的特色是配置面板很直观，可以交互式地添加多个模型供应商。执行opencode后，它会弹出一个列表，选择对应的供应商，然后粘贴 API key 即可。所有配置会存在~/.config/opencode。

OpenCode 有一个官方控制台的免费额度，很多人被热搜里那句 "opencode's free tier can only be used from within opencode" 吓到过。这句报错的意思是：官方免费额度只对从 OpenCode 官方客户端/控制台内部发起的请求生效。如果你在外部脚本里，用 OpenCode 的 API 或 SDK 去调用它，服务端会直接拒绝。所以免费额度只能在 OpenCode 自己的界面里用，想在外面接就要配自己的 API key。

OpenCode 的 Go 套餐是按模型分开计算额度的，不是充一个总额度然后随便用。具体来说，不同模型供应商各自有配额，比如 Anthropic 模型和 OpenAI 模型是独立计费的，互不抵扣。这一点我特意去核实过，因为网上说法很混乱。如果你重度使用多个模型，建议直接买 Go 套餐，比单独买各家 API 便宜，省心。

4. 宿主机与容器如何协作：VSCode、数据卷与配套中间件

镜像构建好了，容器也算装好了，但距离"好用"还差一步：怎么舒服地在这个容器里写代码。

4.1 用Dev Containers把终端塞回容器里

直接在终端里docker exec -it进容器，用 vim 写代码不是不行，但体验太差。我推荐用 VSCode 的 Dev Containers 插件，把整个开发环境搬进容器。

做法是在项目根目录写一个.devcontainer/devcontainer.json，告诉 VSCode 用哪个 Dockerfile 构建环境，再写一个docker-compose.yml管理多个服务。配置好了之后，VSCode 左下角会有一个远程连接按钮，点击它会自动构建镜像并附着到容器，然后在 VSCode 内部打开终端，直接敲claude、codex、opencode，和在本机用完全一样。

这样做最大的好处是，VSCode 的文件树、Git 集成、调试功能都在容器内生效，宿主机上不需要装任何项目依赖。我用这套方案写过几个项目，宿主机干干净净，容器里要啥有啥。

4.2 密钥与登录态怎么持久化

这是很容易被忽视的问题。如果你直接docker run一个临时容器，在里面登录了 Claude Code，然后容器删掉重建，登录态就没了，还得重新授权。

解决方法是把关键配置目录挂载成卷。在 docker-compose 里这样写：

volumes: - claude-config:/root/.claude - codex-config:/root/.codex - opencode-config:/root/.config/opencode - project-data:/workspace

这样容器重建、镜像升级，登录态和项目文件都在。我实际用的卷名是 claude-config、codex-config、opencode-config，Docker 会把它们存在宿主机的一块托管空间里，docker compose down不会删，只有显式docker volume rm才会删。

密钥方面，不要在 Dockerfile 里写死任何 API key。我见过有人为了省事，把 key 直接 COPY 进镜像，结果镜像推到别人的机器上，key 也跟着泄露了。正确做法是容器运行时通过环境变量传入，或者用一个.env文件配合 compose 的env_file字段加载。

4.3 同一套compose里补上MySQL 8.0和Redis主从

既然已经用 Docker 了，我索性把开发和日常跑的服务也一起管起来。最先补的是 MySQL 8.0。很多人问"Docker 安装 MySQL 失败"，核心原因无非三个：端口冲突、认证插件不兼容、数据没持久化。

MySQL 8.0 默认认证插件是caching_sha2_password，老版本的客户端和很多可视化工具连不上，报错 "Authentication plugin 'caching_sha2_password' can't be loaded"。解决办法是用mysql_native_password创建用户，或者升级客户端。compose 里我一般这样起：

mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpass ports: - "3306:3306" volumes: - mysql-data:/var/lib/mysql - ./mysql-init:/docker-entrypoint-initdb.d

端口一定要映射到宿主机，否则容器外访问不到。宿主机上执行docker exec -it mysql mysql -p能进，但宿主机用客户端连 127.0.0.1:3306 连不上，十有八九是ports没写。

Redis 主从也顺手用 compose 搭了。原理很简单：主节点打开 appendonly，从节点配置replicaof 主节点地址 6379。在两个 Redis 容器之间建一个自定义网络，从节点直接通过服务名连接主节点。这个方案我跑了一年多，稳定得很，日常开发足够用了。

5. 四类高频报错，我把排查过程完整走了一遍

这一章写下来，是因为热搜词里出现的几个报错我都现场踩过，每次排查都得花不少时间。把完整链路写出来，你再碰到就不用从头开始了。

5.1 cc-switch切换配置时报local proxy failed

先解释一下 cc-switch 是什么。它是社区里常用的 AI 编程助手配置切换工具，用来快速切换 Claude Code 和 Codex 的多套供应商配置。报错原文是 "cc switch local proxy failed while handling codex endpoint /responses"，意思是在处理 Codex 的 /responses 请求时，cc-switch 指向的本地转发服务不可达。

我第一次看到这个报错，第一反应是 Codex 本身坏了，重装了一遍没用，后来才发现问题出在 cc-switch 的配置上。cc-switch 会把 Codex 的请求转发到一个本地地址，如果这个地址填的是某个未启动的服务端口，或者配置里写错了端口号，Codex 就等于拿到了一个根本连不通的端点。

排查链路是这样的：先打开 cc-switch 的配置界面，看它给当前供应商配置的本地转发地址是什么，确认这个地址对应的进程是否在监听。Linux 下可以用ss -tlnp查看端口，Windows 下用netstat -ano。如果地址没问题但依然报错，就看 cc-switch 版本和 Codex 版本是否兼容，旧版 cc-switch 支持不了新版 Codex 的请求格式，需要升级 cc-switch。

这个报错里 "local proxy" 指的就是 cc-switch 配置选项中的本地转发端点，很多人看到 "proxy" 就往复杂了想，其实大多数情况下就是地址写错了或者服务没起来。

5.2 OpenCode的free tier只能在一个地方用

这句报错完整版是 "opencode's free tier can only be used from within opencode"，我第一次是在一个外部脚本里通过 OpenCode 的 API 调用时看到的。

先说结论：OpenCode 官方控制台提供的免费套餐，只对从 OpenCode 官方客户端内部发起的请求生效。你在它的 TUI 界面里聊天、跑任务，没问题；一旦绕过客户端，用自定义脚本、VSCode 插件或者别的工具去请求它的 API，服务端会直接拒绝，提示这个错误。

这个设计其实是为了防止免费额度被脚本薅羊毛。所以如果你打算集成到自己的流程里，不要指望免费额度，老老实实配自己的 API key，或者开通 Go 套餐再通过官方 API 调用。Go 套餐的额度是每种模型分开计的，这一点我在前面已经说过，充值时留意一下，别以为一个套餐能通用所有模型。

5.3 Codex接入第三方模型时提示gpt-5.6-sol not supported

这个报错我也碰到过。当时我图省事，在 Codex 的config.toml里写了一个自定义的模型名gpt-5.6-sol，结果 Codex 启动后直接拒绝，提示该模型不受支持。

根因是 Codex 内置了模型白名单，不是任何字符串都能当模型名。你填了一个不存在的模型，它不会傻乎乎地把请求发出去，而是先做本地校验，校验不过就报错。解决办法很简单：把配置里model字段改成真实存在的模型名。比如接 DeepSeek 就填deepseek-chat，接 OpenAI 就填gpt-5之类的官方模型名。

更深一层的坑是，有些第三方模型的官方文档给的模型名是别名，比如deepseek-reasoner，但 Codex 的某些版本对推理模型的支持不完整，可能会报别的错。这种情况建议先升级 Codex 到最新版，如果还不行，就换一个 Codex 官方已经收录的模型名，或者用 OpenCode 来接这个模型。别在一个不兼容的组合上死磕。

5.4 容器MySQL连不上的三个层次

"Docker 安装 MySQL 失败" 和 "访问 docker 容器内的 mysql 失败" 是两码事，但经常被混为一谈。我把它们拆成三个层次说。

第一个层次是容器起不来。这通常是端口冲突，宿主机 3306 已经被另一个 MySQL 占了，compose 里映射 3306:3306 时就报错。解决方法：把宿主机端口改成 3307 之类的空闲端口，或者先停掉宿主机自带的 MySQL。

第二个层次是容器起来了但连不上。先在容器内测：docker exec -it mysql mysql -uroot -p，能进说明 MySQL 本身正常；然后在宿主机用客户端连 127.0.0.1:3306，连不上多半是端口没映射出去，或者 MySQL 绑定了 127.0.0.1 而不是 0.0.0.0。compose 里默认ports: - "3306:3306"是映射到所有网卡的，一般不会是绑定问题，重点检查有没有映射、防火墙有没有放行。

第三个层次是认证插件不兼容。老客户端连 MySQL 8.0 报 caching_sha2_password 相关错误，解决办法是创建用户时指定IDENTIFIED WITH mysql_native_password BY '密码'，或者直接用支持 MySQL 8 的新客户端。我个人的选择是后者，因为mysql_native_password在 MySQL 9 里已经要被移除了，绕路不如提前适应。

6. 完整docker-compose落地与我的使用习惯

前面把各个部件都说清楚了，这一节给一份可以直接抄的完整配置，再分享一些实际使用的习惯。

6.1 一份可以直接抄的docker-compose.yml

services: ai-dev: build: . image: ai-dev:latest container_name: ai-dev working_dir: /workspace tty: true stdin_open: true env_file: - .env environment: - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY} - DEEPSEEK_API_KEY=${DEEPSEEK_API_KEY} - OPENAI_API_KEY=${OPENAI_API_KEY} volumes: - ./project:/workspace - claude-config:/root/.claude - codex-config:/root/.codex - opencode-config:/root/.config/opencode - bash-history:/root/.bash_history networks: - dev-net mysql: image: mysql:8.0 container_name: ai-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: app ports: - "3306:3306" volumes: - mysql-data:/var/lib/mysql networks: - dev-net redis-master: image: redis:7 container_name: ai-redis-master command: redis-server --appendonly yes ports: - "6379:6379" volumes: - redis-master-data:/data networks: - dev-net redis-slave: image: redis:7 container_name: ai-redis-slave command: redis-server --replicaof redis-master 6379 depends_on: - redis-master networks: - dev-net volumes: claude-config: codex-config: opencode-config: bash-history: mysql-data: redis-master-data: networks: dev-net:

.env文件里放各种 key，格式是这样的：

ANTHROPIC_API_KEY=sk-xxxx DEEPSEEK_API_KEY=sk-xxxx OPENAI_API_KEY=sk-xxxx MYSQL_ROOT_PASSWORD=your_password

这套配置里，ai-dev服务负责跑三个 AI 助手，MySQL 和 Redis 负责应用服务，三个容器都在同一个 dev-net 网络里，可以互相通过服务名访问。日常开发时，我直接在 VSCode 里连接到 ai-dev 容器，写代码、跑命令、调数据库，一套搞定。

6.2 运行时我想多说几句的注意点

有几个细节是用了很久才摸索出来的，值得单说。

第一，AI 助手的配置里尽量把模型名写成变量。Claude Code 的 settings.json、Codex 的 config.toml、OpenCode 的配置文件里都有模型名，如果你把它们写死，升级工具后模型名可能失效，又要手改。我现在都是在环境变量里存模型名，配置文件里引用环境变量，升级基本无痛。

第二，容器内的时间同步和时区问题。Docker 容器默认用 UTC 时区，AI 助手的日志时间会少 8 小时。我习惯在 Dockerfile 里加一句ENV TZ=Asia/Shanghai，或者启动时挂载宿主机的时间文件，这样日志时间才正常，排查问题不会对不上号。

第三，不要随便删卷。很多人习惯docker compose down -v清理所有东西，这个命令会把 claude-config、codex-config 这些卷一起删掉，登录态、历史配置全部清空。我吃过一次亏之后，现在清理环境只用docker compose down，不带-v，除非我真的想从零开始。

6.3 目前的日常节奏

这套环境搭好之后，我现在的工作节奏是这样的：早上打开电脑，启动 Docker Desktop，VSCode 自动附着到 ai-dev 容器，打开昨天的项目。需要写新功能，先让 Claude Code 分析一下现有代码结构；涉及多文件改动，交给 Codex 执行具体任务；需要快速对比不同模型的回答时，在 OpenCode 的 TUI 里切来切去。数据库和缓存服务我基本不用管，它们作为 compose 里的常驻服务一直在跑。

偶尔遇到某个助手抽风，我也很淡定。先看错误信息是不是配置问题，再查对应的配置文件是不是被 cc-switch 之类的工具改过，最后才考虑是不是要升级版本。大多数情况下，把配置目录里的缓存清一下、重新登录就恢复了。过程虽然还是有点折腾，但比之前在本机乱成一锅粥要好太多了。

说句实话，这套方案并不是什么高深技术，它只是在"用 Docker 隔离开发环境"这个老思路上，把 AI 编程助手的场景做得更完整了一些。但对我这种同时用三个工具的人来说，这半年省下的时间和精力真的非常可观。如果你也在为 AI 助手的本地环境头疼，不妨照着我这套配置试一遍，大概率能解决你一大半的烦恼。