企业官网建设流程全解析

1. 从“openrig”说起：一个把 Claude Code 和 Codex 装进统一工作台的想法

第一次看到openrig这个词，我脑子里蹦出来的不是某个具体软件，而是一种“把散落的工具收进一个机架”的直觉。rig 在英文里有“装配、搭建、成套设备”的意思，open 则点明了它的开放属性。结合热搜里高频出现的 Claude Code、Codex、Node.js、tmux 这几个词，我基本能判断出：这是一个围绕命令行 AI 编程助手做统一编排、统一接入、统一管理的开源工具或配置方案。它要解决的问题很具体——当你同时用着 Claude Code 和 Codex 两套 CLI，又想让它们共用本地模型、共用终端会话、共用一套配置习惯时，手动切来切去实在太累了。

我自己在过去大半年里，主力工作流就是终端里跑 AI 编程助手。最开始只用一套，后来因为不同模型在代码补全、长上下文推理、重构建议上的表现差异明显，就变成了两套甚至三套并行。结果就是：配置文件散落在不同目录，环境变量互相打架，tmux 窗口开了一堆，切换一次要敲好几条命令。openrig这个标题之所以吸引我，是因为它暗示了一种“机架式”的思路——把 Claude Code、Codex 这些工具当成可插拔的模块，统一挂载、统一供电、统一散热。这篇文章我就按这个思路，把从环境准备到多工具协同的完整链路拆开讲，适合已经上手过至少一个 CLI 助手、想进一步做工程化整合的读者。

需要先说明的是，openrig目前并不是一个我能在官方渠道查到的成熟产品名，它更像是一个社区里流传的项目代号或配置集合的统称。所以下文我会基于“一个合格的终端 AI 工作台应该长什么样”这个合理推断来展开，所有具体配置都标注清楚是常见实践，你可以直接抄，也可以按自己环境改。核心目标只有一个：让你在同一台机器上，把 Claude Code 和 Codex 跑得稳、切得快、管得住。

2. 整体设计与思路拆解：为什么是 Node.js + tmux 这套组合

2.1 核心需求拆解：多 CLI 助手并行的三个痛点

在动手之前，先把需求想清楚。我总结下来，同时使用 Claude Code 和 Codex 这类工具的人，绕不开三个痛点。

第一个痛点是运行时依赖冲突。Claude Code 和 Codex 的 CLI 大多基于 Node.js 生态分发，通过 npm 全局安装。但不同工具对 Node.js 版本的要求并不总是一致，有的要求 LTS，有的在新版本上才修掉某个 bug。如果全局只有一个 Node 版本，升级一个工具可能弄坏另一个。热搜里那条error installing 24.21.0: node.js v24.21.0 is not yet released就是典型的版本管理翻车现场——你照着某个教程敲了安装命令，结果那个版本号根本不存在，或者还没正式发布。

第二个痛点是会话状态难以保持。CLI 助手跑起来之后，往往需要保持一个长驻的交互会话，中途你去查个文档、改个文件，回来发现会话断了，上下文丢了。tmux 在这里的价值就体现出来了：它把会话和终端窗口解耦，你可以随时 detach，过一小时再 attach 回来，AI 助手还在原地等你。热搜里claude code如何直接执行终端命令这类问题，本质上也是在问“怎么让助手和我的终端环境无缝配合”，而 tmux 正是那个粘合层。

第三个痛点是模型接入的碎片化。有人用官方订阅，有人接第三方 API，有人想调本地模型。热搜里claude code 调用lmstudio的本地模型、codex接入deepseek、使用cc switch 接入 deepseek v4, qwen, glm等模型这些词，全都指向同一个诉求：我希望用同一套界面，背后想换哪个模型就换哪个模型。openrig式的思路，就是把这些接入方式抽象成配置，而不是每次手动改环境变量。

2.2 方案选型：为什么不是 Docker，而是原生 + tmux

有人会问，既然要隔离环境，为什么不用 Docker 给每个工具一个容器？我试过，结论是：对于交互式 CLI 助手，Docker 的摩擦成本太高。容器里的文件系统和你宿主机的项目目录之间要挂载，AI 助手读写代码时路径映射容易出问题；而且容器内的终端交互体验，尤其是复制粘贴和快捷键，总是不如原生顺滑。

所以我的选择是：Node.js 版本管理用 nvm 或 fnm，会话隔离用 tmux，工具本身原生安装。这套组合的好处是轻、快、透明。nvm 让你在同一个用户下切换 Node 版本，nvm use 20和nvm use 22之间切换只要一秒；tmux 让你在一个终端窗口里开多个 pane，每个 pane 跑一个助手，互不干扰。热搜里node.js是干什么的、node.js安装、node.js lts下载这些基础问题，恰恰说明很多人卡在第一步，而 nvm 能把这一步的试错成本降到最低。

提示：如果你在 Windows 上，nvm 的原生体验一般，建议用 fnm 或者直接在 WSL2 里操作。热搜里claude code windows、codex安装 windows桌面版说明 Windows 用户不少，但 CLI 生态在类 Unix 环境下确实更顺。

2.3 目录结构设计：让配置有地方安放

一个清晰的目录结构，是后续所有操作不混乱的前提。我习惯这样组织：

~/ai-rig/ ├── envs/ # 各工具的独立环境配置 │ ├── claude.env │ └── codex.env ├── scripts/ # 启动、切换、健康检查脚本 │ ├── start-claude.sh │ ├── start-codex.sh │ └── switch-model.sh ├── logs/ # 会话日志，方便回溯 └── tmux/ # tmux 会话配置 └── ai-workbench.conf

这个结构的关键在于环境变量与工具解耦。claude.env里只放 Claude Code 需要的变量，codex.env里只放 Codex 需要的。启动脚本负责 source 对应的 env 文件，再拉起工具。这样你想换模型，只改 env 文件，不动启动逻辑。热搜里codex配置、claude code官方文档链接这类需求，落到实操上就是“配置放哪、怎么生效”，这个结构直接回答了。

3. 核心细节解析与实操要点：Node.js、tmux 与工具安装

3.1 Node.js 版本管理：别再用系统自带的那个

系统自带的 Node.js 版本往往偏旧，而且你用包管理器升级它，可能影响系统里其他依赖 Node 的服务。正确做法是用版本管理器。我推荐 fnm，因为它启动快、跨平台、配置简单。安装 fnm 之后，装两个 LTS 版本备用：

# 安装 fnm 后，安装两个 LTS 版本 fnm install 20 fnm install 22 # 设置默认版本 fnm default 22 fnm use 20

为什么要装两个？因为 Claude Code 和 Codex 对 Node 版本的兼容窗口不一定重合。我实测下来，把 Claude Code 固定在 Node 20，Codex 固定在 Node 22，两边都稳。热搜里node.js lts下载、安装node.js是最高频的基础问题，但很少有人告诉你“装一个不够，要装两个”。这就是经验。

注意：error installing 24.21.0: node.js v24.21.0 is not yet released这个报错，通常是因为你抄了一个不存在的版本号。去 Node.js 官网确认当前 LTS 的实际版本号，别信教程里的固定数字。

3.2 tmux 会话管理：让 AI 助手永不掉线

tmux 的核心概念是 session、window、pane 三层。我的用法是：一个 session 叫ai，里面开三个 window，分别叫claude、codex、shell。每个 window 里跑对应的工具。这样我tmux attach -t ai之后，按Ctrl-b加数字就能在工具间跳。

# 创建名为 ai 的会话 tmux new -s ai # 在会话内重命名当前 window # Ctrl-b , 然后输入 claude # 新建 window # Ctrl-b c，然后重命名为 codex # 分离会话 # Ctrl-b d # 重新连接 tmux attach -t ai

这套操作看起来简单，但有一个关键细节：tmux 里的环境变量继承。如果你在 tmux 启动之后才 source 了新的 env 文件，tmux 里已有的 pane 不会自动更新。所以我的习惯是，所有 env 文件在启动 tmux 之前就准备好，或者用tmux send-keys在 pane 里手动 source。热搜里claude code如何直接执行终端命令其实也涉及这个——助手要执行命令，得先确保它所在的 shell 环境是对的。

3.3 Claude Code 与 Codex 的安装与隔离

安装本身不复杂，关键是隔离。我的做法是：不用全局安装，而是用npx或者项目级安装，配合不同的 Node 版本。

# 在 Node 20 环境下安装 Claude Code fnm use 20 npm install -g @anthropic-ai/claude-code # 在 Node 22 环境下安装 Codex fnm use 22 npm install -g @openai/codex

全局安装的问题是，两个工具会共享同一个 npm 全局目录，切换 Node 版本时全局包不跟着走。更干净的方式是用npm install装到各自的项目目录，然后用npx调用。但这样每次启动要进目录，麻烦。折中方案是：用 fnm 的--use-on-cd功能，进不同目录自动切 Node 版本，全局包也就跟着切了。

提示：热搜里codex is ignoring 1 unrecognized configuration setting这个警告，通常是配置文件里写了工具不认识的字段。别慌，先确认你的工具版本，再去官方文档核对字段名。很多教程抄的是旧版本配置，字段早就改了。

3.4 模型接入的配置抽象

这是openrig思路里最有价值的部分。Claude Code 和 Codex 都支持通过环境变量指定 API 端点和密钥。我把这些抽成 env 文件：

# claude.env export ANTHROPIC_BASE_URL="https://your-endpoint.example.com" export ANTHROPIC_API_KEY="sk-xxxx" export ANTHROPIC_MODEL="claude-sonnet-4-20250514" # codex.env export OPENAI_BASE_URL="https://your-endpoint.example.com/v1" export OPENAI_API_KEY="sk-yyyy" export OPENAI_MODEL="gpt-5-codex"

想换模型，改这两行就行。热搜里codex接入deepseek、claude code 调用lmstudio的本地模型、使用cc switch 接入 deepseek v4, qwen, glm等模型，本质上都是改这几个变量。本地模型的话，把 BASE_URL 指向http://localhost:1234/v1这类本地服务地址即可。注意本地模型的上下文窗口和工具调用能力可能和官方有差异，复杂任务建议先用小项目试。

4. 实操过程与核心环节实现：从零搭起一个 openrig 工作台

4.1 环境准备清单与版本确认

动手前，先把清单列出来，逐项确认。我踩过的坑是：以为装好了，结果某个工具的依赖没装全，跑起来报错，排查半天。

确认完版本，再检查 shell 配置。fnm 需要在.bashrc或.zshrc里加初始化脚本，否则新开的终端不认。tmux 的配置文件放在~/.tmux.conf，我建议至少加这几行：

# ~/.tmux.conf set -g mouse on set -g history-limit 50000 set -g base-index 1 setw -g pane-base-index 1

mouse on让你能用鼠标选 pane、调大小，对新手友好。history-limit调大，方便回溯 AI 助手的输出。base-index从 1 开始，符合直觉。

4.2 启动脚本的编写与参数计算

启动脚本的核心是：切 Node 版本、source env、拉起工具、记录日志。以 Claude Code 为例：

#!/usr/bin/env bash # scripts/start-claude.sh set -euo pipefail # 切到 Node 20 eval "$(fnm env --use-on-cd)" fnm use 20 # 加载环境变量 source ~/ai-rig/envs/claude.env # 记录启动时间 echo "[$(date '+%Y-%m-%d %H:%M:%S')] starting claude" >> ~/ai-rig/logs/claude.log # 拉起工具，日志同时输出到文件 claude 2>&1 | tee -a ~/ai-rig/logs/claude.log

这里有个细节：set -euo pipefail让脚本遇到错误就退出，避免半死不活的状态。tee -a让输出既显示在终端又写进日志。日志文件按工具分开，排查问题时不会混。

Codex 的脚本类似，只是切 Node 22、sourcecodex.env。两个脚本都放在scripts/下，加执行权限：

chmod +x ~/ai-rig/scripts/*.sh

4.3 tmux 工作台的一键拉起

手动开 tmux、开 window、跑脚本，还是麻烦。写一个总启动脚本，一键搞定：

#!/usr/bin/env bash # scripts/start-workbench.sh set -euo pipefail SESSION="ai" # 如果会话已存在，直接 attach if tmux has-session -t "$SESSION" 2>/dev/null; then tmux attach -t "$SESSION" exit 0 fi # 创建会话，第一个 window 跑 claude tmux new-session -d -s "$SESSION" -n claude tmux send-keys -t "$SESSION:claude" "~/ai-rig/scripts/start-claude.sh" C-m # 第二个 window 跑 codex tmux new-window -t "$SESSION" -n codex tmux send-keys -t "$SESSION:codex" "~/ai-rig/scripts/start-codex.sh" C-m # 第三个 window 留作普通 shell tmux new-window -t "$SESSION" -n shell # attach 到会话 tmux attach -t "$SESSION"

这个脚本的逻辑是：先检查会话是否存在，存在就直接进，不存在就建。建的时候用-d让会话在后台创建，然后用send-keys把启动命令“敲”进对应的 window。这样你 attach 进去的时候，两个助手已经在跑了。热搜里claude code使用、codex使用教程讲的多是单工具怎么用，而这里解决的是“两个一起用怎么不打架”。

4.4 模型切换的实操记录

假设我原本用官方模型，现在想切到本地模型做实验。操作步骤：

1. 编辑~/ai-rig/envs/claude.env，把ANTHROPIC_BASE_URL改成http://localhost:1234/v1，ANTHROPIC_API_KEY随便填一个非空值（本地服务通常不校验）。
2. 在 tmux 的 claude window 里，按Ctrl-c退出当前会话。
3. 重新运行~/ai-rig/scripts/start-claude.sh。
4. 用一句简单的话测试，比如“列出当前目录的文件”。

实测下来，本地模型在简单任务上响应很快，但涉及多文件重构时，工具调用能力可能不如官方模型。我的经验是：本地模型适合做代码解释、单文件修改、写测试；复杂重构还是用官方或大参数模型。热搜里claude code 调用lmstudio的本地模型热度高，说明很多人想省成本，但省成本的前提是任务匹配。

注意：切换模型后，如果工具报cc switch local proxy failed while handling codex endpoint /responses这类错误，先检查 BASE_URL 的路径对不对。很多本地服务的 OpenAI 兼容端点是/v1，而工具可能默认拼了/responses，路径对不上就 404。

5. 常见问题与排查技巧实录

5.1 安装阶段的典型报错与解决

安装阶段的问题，八成出在 Node 版本和网络。我整理了一张速查表：

EACCES这个坑我踩过。早期用系统 Node，npm install -g要 sudo，装完的文件属主是 root，后面升级又出问题。换成 fnm 之后，全局包装在用户目录下，再没遇到过权限问题。热搜里安装node.js、node.js下载是入门问题，但入门问题往往最影响后续体验。

5.2 运行阶段的会话与网络问题

运行阶段最常见的是会话断连和网络超时。会话断连用 tmux 解决，前面讲过了。网络超时则要看具体接入方式。如果是第三方 API，先确认端点可达：

curl -sS -o /dev/null -w "%{http_code}\n" https://your-endpoint.example.com/v1/models

返回 200 说明通，返回 401 说明密钥有问题，返回 404 说明路径不对。这个命令比在工具里瞎试快得多。

另一个高频问题是codex无法加载组织设置。这通常和账号的团队配置有关，个人账号一般不会遇到。如果你用的是团队账号，联系管理员确认权限。热搜里codex登录、codex安装热度高，说明很多人在登录环节卡住，我的建议是：先用最简单的官方接入跑通，再折腾第三方和本地模型，别一上来就搞复杂配置。

5.3 多工具协同的避坑经验

同时跑 Claude Code 和 Codex，有几个坑我踩过，分享出来。

第一个坑是端口冲突。如果你给两个工具都配了本地代理，注意它们监听的端口别撞。我习惯给 Claude Code 用 8080，Codex 用 8081。

第二个坑是日志混淆。两个工具的日志如果写同一个文件，排查时根本分不清谁是谁。所以前面强调日志按工具分开。

第三个坑是快捷键冲突。tmux 的前缀键默认是Ctrl-b，而某些终端或编辑器也用这个组合。如果冲突，改 tmux 前缀键：

# ~/.tmux.conf set -g prefix C-a bind C-a send-prefix

改成Ctrl-a之后，和大多数工具的冲突就少了。

第四个坑是上下文串味。你在 Claude Code 里讨论的方案，切到 Codex 时它不知道。我的做法是，重要上下文写进项目里的一个CONTEXT.md，两个工具都让它先读这个文件。这样切换工具时，上下文能接上。

5.4 性能与资源占用的观察

两个 CLI 助手同时跑，内存占用不容忽视。我实测下来，每个助手进程大概占 200MB 到 500MB 内存，取决于上下文长度。如果你机器内存紧张，建议一次只跑一个，另一个用 tmux 挂着但不活跃。

CPU 占用主要在模型推理时，本地模型尤其明显。如果你用本地模型，跑大任务时机器会卡，这是正常的。我的经验是：本地模型跑在独立窗口，别和你的编辑器抢资源；官方 API 则几乎不占本地 CPU。

提示：热搜里node.js是干什么的这类基础问题，其实反映了一个现实——很多人是被“必须装 Node”这件事挡在门外的。但只要你用 fnm 把 Node 管起来，后面所有工具的安装都是npm install一句话的事，门槛比想象中低。

6. 工具选型与扩展：openrig 思路还能怎么用

6.1 除了 Claude Code 和 Codex，还能挂什么

openrig的“机架”思路是通用的。任何基于命令行的 AI 工具，都可以用同样的方式挂进来。比如代码审查工具、文档生成工具、甚至自定义的脚本。关键是统一 env 管理、统一 tmux 会话、统一日志。

我现在的ai会话里有四个 window：claude、codex、shell、logs。logs window 里跑tail -f看两个工具的日志，排查问题时不用切来切去。

6.2 配置的版本化管理

~/ai-rig/这个目录，我建议用 git 管起来。env 文件里的密钥不要提交，用.gitignore排除，然后提供一个envs/*.env.example模板。这样换机器时，clone 下来、填密钥、跑启动脚本，十分钟就能恢复工作环境。

# .gitignore envs/*.env logs/

这个习惯看起来小，但换电脑或重装系统时，价值巨大。热搜里claude code安装、codex安装教程反复出现，说明很多人每次都在重新配环境。版本化管理能让你一次配好，到处复用。

6.3 从单机到多机的延伸

如果你有多台机器，比如一台台式机跑本地模型，一台笔记本做日常开发，openrig的思路也能延伸。把 env 文件和脚本放在同步目录里，两台机器用同一套配置。本地模型那台把 BASE_URL 指向局域网地址，笔记本就能远程调用。这样笔记本不用扛大模型，也能享受本地推理的低延迟。

这个延伸的关键是网络可达性和密钥管理。局域网内调用，注意防火墙放行对应端口；密钥别硬编码在脚本里，用环境变量或密钥管理工具。

7. 我个人的实操体会

这套工作台我用了几个月，最大的感受是：工具的价值不在于多，而在于切换成本低。以前我因为切换麻烦，常常一个工具用到黑，哪怕它不适合当前任务。现在 tmux 里Ctrl-b加数字就能切，env 文件改一行就能换模型，我变得更愿意根据任务选工具了。写测试用响应快的，做重构用上下文长的，查文档用能联网的。

另一个体会是，日志比想象中重要。AI 助手的输出有时候很长，当时没细看，事后想回溯，没有日志就抓瞎。现在两个工具的日志都留着，偶尔翻一翻，能发现不少当时忽略的细节。

最后分享一个小技巧：给 tmux 的每个 window 设一个明显的名字，并且在.tmux.conf里打开pane-border-status，这样你一眼就知道当前在哪个工具里，不会敲错命令。

# ~/.tmux.conf set -g pane-border-status top set -g pane-border-format "#{pane_title}"

这个配置加上之后，每个 pane 顶部会显示标题，多窗口操作时不容易迷路。