企业官网建设流程全解析

1. 从“openrig”说起：一个把 Claude Code 和 Codex 装进同一台机器的实战思路

第一次看到 “openrig” 这个词，我脑子里蹦出来的不是某个具体软件，而是一种“搭台子”的感觉——rig 在英文里本来就有“装配、搭建设备”的意思，open 则暗示这套东西是开放的、可拆解的、能自己动手改的。结合最近被反复搜索的那几个词：Claude Code、Codex、Node.js、tmux，我基本能判断出，openrig 想解决的是一个非常具体、也非常折磨人的问题：怎么在一台开发机上，把 Claude Code 和 Codex 这两个命令行 AI 编程工具同时跑起来，还能互不打架、随时切换、稳定干活。

我自己是从 Claude Code 刚开放命令行那阵子就开始折腾的，中间踩过的坑包括但不限于：Node.js 版本不对导致安装脚本直接报错、Codex 登录之后提示组织设置被禁用、VS Code 里接 Claude Code 结果终端环境变量读不到、tmux 会话里跑长任务结果 SSH 一断全没了。这些问题单看都不大，但凑在一起就非常消耗耐心。openrig 的价值就在于，它把这些零散的经验收拢成一套可复用的“装配方案”。

这篇文章适合三类人看：第一类是刚听说 Claude Code 或 Codex，想在自己电脑上装一个试试，但被 Node.js、环境变量、登录这些前置步骤劝退的；第二类是已经装了其中一个，想再装另一个，结果发现两个工具互相干扰、配置冲突的；第三类是靠命令行 AI 工具吃饭，需要长时间跑任务、需要多会话管理、需要把本地模型也接进来的进阶用户。我会从整体设计思路讲到具体操作，再到常见报错怎么排查，尽量把每一步“为什么这么做”讲清楚，而不是只丢一堆命令让你抄。

提示：本文提到的所有工具安装、配置，都建议在你自己有权限的机器上操作。公司电脑如果装了统一管控软件，先确认是否允许安装开发工具，避免白折腾。

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

2.1 核心需求：两个 AI 编程工具共存，而不是二选一

很多人一开始的想法是“我先装 Claude Code，用腻了再换 Codex”。但实际用下来你会发现，这两个工具的定位有微妙差别：Claude Code 在理解大段上下文、按自然语言改多文件方面手感很好；Codex 在补全、按注释生成代码块、快速试错方面更轻快。真正高效的用法不是二选一，而是根据任务类型切换。比如重构一个模块，我会用 Claude Code 让它先读整个目录再动手；写一个独立的小函数，我直接 Codex 里敲注释让它补。

这就带来第一个设计约束：两个工具必须能装在同一台机器上，且各自的配置、缓存、登录态不能互相覆盖。Claude Code 和 Codex 都是基于 Node.js 生态的命令行工具，默认会把配置写到用户目录下的隐藏文件夹里。如果你不注意，两个工具的配置文件路径可能撞车，或者一个工具升级把另一个的依赖顶掉。openrig 思路的第一步，就是在安装层面就把它们隔离开。

2.2 为什么 Node.js 版本是第一个坎

热搜里有一条特别扎眼：“error installing 24.21.0: node.js v24.21.0 is not yet released or is not available”。这个报错我见过太多次了，本质原因是安装脚本或者某个包管理器去拉一个还不存在的 Node.js 版本。Node.js 的版本号是分奇数偶数、分 LTS 和 Current 的，很多 AI 命令行工具官方推荐的是 LTS 版本，比如 20.x 或 22.x，而不是最新的 Current。

我的建议很直接：不要追最新版，装 LTS。原因有三个。第一，LTS 经过更长时间测试，和 npm 生态里各种包的兼容性更好；第二，很多 AI 工具的安装脚本里写死了对 Node 版本的判断逻辑，Current 版本可能触发误判；第三，LTS 的生命周期长，你半年后回来重新装，版本还在维护，不会遇到“这个版本已经 EOL 了”的尴尬。

具体操作上，我强烈建议用版本管理工具而不是直接装系统级 Node。Windows 上用 nvm-windows，macOS 和 Linux 上用 nvm。这样你可以随时nvm use 20或nvm use 22切换，不会因为一个工具要求 Node 18、另一个要求 Node 20 而打架。安装完 nvm 之后，先nvm install --lts，再nvm use --lts，然后node -v确认版本。这一步看起来简单，但它是后面所有操作的地基。

2.3 tmux 的角色：让长任务不再怕断线

tmux 这个词出现在热搜里，说明很多人已经意识到一个问题：AI 编程工具跑起来之后，经常是长时间任务。比如让 Claude Code 读一个大型仓库、生成一份重构方案，可能要跑好几分钟甚至更久。如果你是在 SSH 连着的远程机器上操作，网络一抖，终端一断，任务就没了。tmux 解决的就是这个：它让你在一个“会话”里跑任务，即使你断开 SSH，会话还在后台活着，下次连上来tmux attach就能接着看。

在 openrig 这套思路里，tmux 不只是“防断线”工具，它还是多任务并行的管理器。你可以开一个窗口跑 Claude Code 的重构任务，另一个窗口跑 Codex 的补全测试，第三个窗口专门用来看日志。每个窗口互不干扰，切换用快捷键就行。这比开一堆终端标签页要清爽得多，尤其是在远程服务器上。

2.4 方案选型对比：为什么不直接用 VS Code 插件

有人会问，既然 VS Code 里有 Claude Code 的插件，为什么还要折腾命令行？我的实测感受是：插件适合“边写边问”的轻量场景，但遇到需要批量改文件、需要跑终端命令、需要长时间后台任务的时候，命令行版本的控制力更强。而且命令行版本和 tmux 结合之后，可以做到“我下班前丢一个任务进去，第二天来看结果”，插件做不到这一点。

所以 openrig 的整体设计思路可以概括成一句话：用 nvm 管好 Node.js 版本，用 npm 全局安装两个工具并隔离配置，用 tmux 管理长时间运行的会话，最后按任务类型在 Claude Code 和 Codex 之间切换。下面我把每个环节拆开讲。

3. 核心细节解析与实操要点：安装、配置、隔离

3.1 Node.js 安装：nvm 的正确打开方式

先说 Windows。去 nvm-windows 的发布页下载安装包，装完之后一定要用管理员权限打开一个新的终端，否则 nvm 的命令可能不生效。然后依次执行：

nvm install 20.18.0 nvm use 20.18.0 node -v npm -v

这里我特意写了一个具体的 LTS 版本号，而不是--lts，原因是有些环境下--lts会去拉最新的 LTS，而最新 LTS 可能刚发布不久，生态还没跟上。写死一个经过验证的版本，复现性更好。macOS 和 Linux 上，用官方的 nvm 脚本安装，然后在 shell 配置文件里加上初始化代码，重开终端后同样执行上面的命令。

注意：如果你之前用系统包管理器装过 Node.js，比如 apt 或 brew，建议先卸载干净，否则 nvm 切换的版本可能被系统版本覆盖。用which node确认当前用的是 nvm 管理的路径，而不是/usr/bin/node。

安装完 Node.js 之后，建议把 npm 的全局目录也检查一下。执行npm config get prefix，确认它指向的是 nvm 目录下的路径。如果不是，全局安装的工具可能会跑到系统目录里，后面升级或卸载都很麻烦。

3.2 Claude Code 安装：全局装还是项目装

Claude Code 官方推荐的方式是全局安装，命令大概是npm install -g @anthropic-ai/claude-code这种形式（具体包名以官方文档为准）。全局安装的好处是任何目录下都能直接敲claude启动，坏处是如果 Node 版本切换了，全局包可能失效，需要重装。

我的做法是：在确定长期使用的 Node 版本下全局安装，并且记录下这个版本号。比如我固定用 20.18.0，那所有全局工具都装在这个版本下。如果哪天需要临时切到别的版本做实验，实验完切回来，工具还在。这比每个项目单独装要省心，因为 AI 编程工具本身不依赖项目代码，它是独立进程。

安装完成后，第一次运行claude会引导你登录。这里有个常见坑：如果你在公司网络环境下，登录回调可能会失败。我的经验是，先在个人网络环境下完成一次登录，把凭证缓存下来，之后再换网络通常还能用。如果登录时提示“your organization has disabled claude subscription access”，那基本是账号权限问题，需要确认你用的账号是否被管理员限制了相关功能。

3.3 Codex 安装：注意配置文件的“不识别”警告

Codex 的安装同样走 npm 全局安装。装完之后第一次运行，可能会看到这样的提示：“codex is ignoring 1 unrecognized configuration setting. check for typos or d...”。这个警告的意思是，你的配置文件里有一项它不认识，可能是拼写错误，也可能是版本不匹配。不要忽略这个警告，因为它往往意味着你期望的某个行为没有生效。

我的处理方式是：找到 Codex 的配置文件，通常在用户目录下的隐藏文件夹里，把不认识的那一项先注释掉，重启工具确认警告消失，再逐项加回来测试。这样能定位到底是哪一项配置有问题。另外，Codex 登录时如果提示“codex无法加载组织设置”，通常是账号层面的问题，和本地安装无关，需要去账号后台确认。

3.4 配置隔离：让两个工具各用各的目录

这是 openrig 思路里最关键的一步。Claude Code 和 Codex 默认都会在用户目录下写配置和缓存。如果它们的目录名很接近，或者都读同一个环境变量，就可能互相干扰。我的做法是：

• 给每个工具单独设置配置目录的环境变量，比如CLAUDE_CONFIG_DIR和CODEX_CONFIG_DIR，指向不同的路径。
• 在 shell 配置文件里用 alias 区分启动命令，比如alias cc='CLAUDE_CONFIG_DIR=~/.config/claude-rig claude'，alias cx='CODEX_CONFIG_DIR=~/.config/codex-rig codex'。
• 定期备份这两个目录，因为登录态和自定义配置都在里面，重装系统时能省很多事。

这样做的额外好处是，你可以为不同的项目或不同的模型配置准备多套目录。比如一套接官方服务，一套接本地模型，切换时改一下 alias 就行，不用反复登录登出。

3.5 tmux 基础配置：让会话管理更顺手

tmux 默认的快捷键是 Ctrl+b 前缀，用久了其实挺顺手，但有几个配置我建议一开始就加上。在~/.tmux.conf里写：

set -g mouse on set -g history-limit 10000 set -g base-index 1 setw -g pane-base-index 1

mouse on让你可以用鼠标滚轮翻历史、点选窗口，对新手非常友好。history-limit调大之后，AI 工具输出的长日志不会被截断。base-index从 1 开始，符合大多数人的直觉，按 Ctrl+b 1 就是第一个窗口。

启动会话的方式是tmux new -s work，其中 work 是会话名。之后断开用 Ctrl+b d，重新连接用tmux attach -t work。查看所有会话用tmux ls。这几个命令记住就够日常用了。

4. 实操过程与核心环节实现：从零搭起一套 openrig

4.1 完整安装流程与验证清单

我把整个流程按顺序列出来，你可以照着做，每做完一步就验证一下，避免错误累积到最后难以定位。

1. 安装 nvm，重开终端，确认nvm -v有输出。
2. nvm install 20.18.0，然后nvm use 20.18.0，确认node -v显示 v20.18.0。
3. npm install -g npm@latest升级 npm 本身，避免旧版 npm 的安装 bug。
4. 全局安装 Claude Code，运行claude --version确认安装成功。
5. 全局安装 Codex，运行codex --version确认安装成功。
6. 分别设置两个工具的配置目录环境变量，写入 shell 配置文件。
7. 安装 tmux，写入基础配置，新建一个测试会话。
8. 在 tmux 会话里分别启动两个工具，完成登录，确认都能正常对话。

这个清单看起来长，但实际操作下来，网络正常的话二十分钟以内能搞定。关键是每一步都验证，不要跳步。

4.2 参数选择背后的计算：为什么是 20.18.0

你可能会问，为什么我反复强调 20.18.0 这个具体版本，而不是笼统说“LTS”。这里有个实际考量：Node.js 的每个大版本里，不同小版本对某些原生模块的支持程度不一样。AI 命令行工具通常会依赖一些需要编译的包，比如终端 UI 渲染库、加密库。这些包在 Node 20 的早期小版本上可能有兼容问题，在后期小版本上修复了。20.18.0 是我实测下来比较稳的一个点，既不是太早期的版本，也不是刚发布还没经过社区验证的版本。

如果你不想记具体版本号，那就用nvm install --lts，然后node -v看一下装的是哪个，把这个版本号记下来，后面所有操作都用这个版本。核心原则是保持一致性，不要今天用 20，明天用 22，那样全局包会反复失效。

4.3 在 tmux 里跑长任务的实操记录

我拿一个真实场景举例：让 Claude Code 读一个中型前端项目，生成一份组件依赖关系说明。这个任务大概要跑三到五分钟。

首先tmux new -s refactor新建会话，然后在会话里cd到项目目录，启动claude。把任务描述写清楚，比如“请阅读 src 目录下所有组件，输出一份组件之间的依赖关系列表，标注哪些组件被多处引用”。回车之后，任务开始跑。

这时候我可以按 Ctrl+b d 断开，去干别的事。过几分钟回来tmux attach -t refactor，就能看到结果。如果任务还没跑完，输出会继续滚动。这个过程中即使我的 SSH 断了，tmux 会话依然在服务器上活着，任务不受影响。

同样的方式可以再开一个窗口跑 Codex。在 tmux 里按 Ctrl+b c 新建窗口，启动codex，让它处理另一个独立任务。两个窗口互不干扰，切换用 Ctrl+b 加窗口号。

4.4 接入本地模型的配置思路

热搜里有一条“claude code 调用 lmstudio 的本地模型”，说明很多人想把本地模型接进来。这个思路是可行的，核心是把工具的 API 端点指向本地服务。具体做法通常是在配置里设置一个 base URL，指向本地模型服务监听的地址和端口，然后设置对应的模型名称。

这里要注意两点。第一，本地模型的上下文长度通常比云端小，喂太长的代码可能被截断，需要自己控制输入量。第二，本地模型的响应格式可能和工具期望的不完全一致，遇到解析错误时，先检查本地服务返回的 JSON 结构是否符合预期。我的经验是，先用一个简单的“你好”测试连通性，再逐步加大输入复杂度。

提示：本地模型服务需要单独启动并保持运行，建议也放在 tmux 会话里，避免关掉终端就断了。

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

5.1 安装阶段的高频报错

这个表里的每一行我都实际遇到过。最想强调的是权限问题：很多人遇到 permission denied 就加 sudo，结果装出来的工具归属 root，后面普通用户运行又出问题。正确做法是用 nvm，它把 Node 和全局包都装在用户目录下，根本不需要 sudo。

5.2 登录与账号相关的坑

“your organization has disabled claude subscription access” 和 “codex无法加载组织设置” 这两个报错，本质都是账号权限问题，不是本地环境问题。遇到这类提示，先确认你用的账号类型，再确认管理员是否开启了对应功能的访问权限。如果是个人账号，通常不会有这个限制；如果是团队账号，可能需要管理员在后台调整。

另一个常见情况是登录回调失败。这通常和网络环境有关，可以尝试换一个网络环境完成首次登录，登录态缓存下来之后，日常使用一般不受影响。

5.3 工具之间互相干扰的排查

如果你发现装了 Codex 之后 Claude Code 启动变慢，或者反过来，先检查两件事。第一，它们是不是共用了同一个配置目录，导致读写冲突。第二，它们的 Node 依赖里有没有版本冲突的包。排查方法是分别用npm ls -g --depth=0看全局包列表，确认两个工具的依赖没有互相覆盖。

我的经验是，只要配置目录隔离做好，两个工具同时装基本不会互相干扰。真正容易出问题的是环境变量，比如某个工具读了一个全局的 API 端点变量，另一个工具也读同一个变量，就会串。解决办法就是给每个工具单独设置专属的环境变量名，不要用通用的名字。

5.4 tmux 使用中的小坑

tmux 里跑 AI 工具，偶尔会遇到输出乱码或者颜色显示不正常。这通常是终端类型设置的问题。在 tmux 配置里加上set -g default-terminal "screen-256color"，大多数情况下能解决。如果还是不对，检查一下外层终端的 TERM 变量。

另一个坑是 tmux 会话里的环境变量和外面不一致。比如你在 shell 里设置了配置目录变量，但 tmux 会话是之前开的，读不到新变量。解决办法是重开会话，或者在 tmux 里手动 export 一次。我习惯在 tmux 配置文件里加一行set -g update-environment "CLAUDE_CONFIG_DIR CODEX_CONFIG_DIR"，让新开的窗口能继承这些变量。

6. 我个人的使用节奏与几个压箱底技巧

用久了之后，我形成了一套固定的节奏。早上到工位，先tmux attach看看昨晚跑的任务有没有结果。然后开一个新窗口，用 Claude Code 处理需要读大量上下文的任务，比如理解一个新接手的模块。同时另一个窗口用 Codex 处理零散的补全和试错。两个工具的输出我都习惯重定向到日志文件，方便回溯。

几个压箱底的技巧分享给你。第一，给常用的任务描述写成模板文件，启动工具后直接粘贴，省得每次重新组织语言。第二，定期把配置目录打包备份，换机器时解压就能恢复登录态和自定义配置。第三，tmux 会话名用项目名加日期，比如refactor-0315，过一段时间清理旧会话时一目了然。

这套 openrig 的思路说到底就是一句话：把环境搭稳，把会话管好，把工具用对地方。环境不稳，再好的工具也发挥不出来；会话不管好，长任务就是碰运气；工具用不对地方，等于白装。希望这些踩坑经验能帮你少走点弯路。