企业官网建设流程全解析

1. 从零认识 openrig：它到底解决什么问题

第一次看到 openrig 这个名字，很多人会以为是某个硬件支架或者开源机械臂项目。实际上，结合它周边的关键词——Claude Code、Codex、Node.js、tmux——可以判断出，openrig 是一套面向 AI 编程助手（尤其是 Claude Code 和 Codex 这类 CLI 工具）的运行环境编排方案。它的核心价值在于：把散落在各处的命令行 AI 工具、本地模型服务、终端会话管理整合成一套可复用、可切换、可远程保持的工作台。

我自己在折腾 Claude Code 和 Codex 的过程中，最头疼的从来不是工具本身好不好用，而是环境问题。Node.js 版本不对、终端一关会话就断、本地模型和云端模型切换要改一堆配置、不同项目要用不同的 API 端点……这些琐事加起来，消耗的精力比写代码还多。openrig 这类方案要解决的，正是这些“脏活累活”。

它适合谁？三类人最需要：一是刚接触 Claude Code 或 Codex、被安装配置卡住的新手；二是同时使用多个 AI 编程工具、需要频繁切换模型和端点的进阶用户；三是在服务器或远程环境里跑 AI 助手、希望会话能持久保持的开发者。哪怕你只是想在本地把 Claude Code 接上 LM Studio 的本地模型，openrig 的思路也能帮你理清整个链路。

需要说明的是，openrig 目前并不是一个官方标准化的产品，更多是一种“环境编排实践”的统称。所以下面我会结合 Claude Code、Codex、Node.js、tmux 这几个核心组件，把一套可落地的方案完整拆开讲。你完全可以照着搭一套属于自己的 openrig。

2. 环境底座：Node.js 安装与版本管理的关键决策

2.1 为什么 Node.js 版本是第一个坑

Claude Code 和 Codex 的 CLI 版本基本都是基于 Node.js 生态分发的，这意味着 Node.js 的版本直接决定了工具能不能装、能不能跑。热搜词里出现“error installing 24.21.0: node.js v24.21.0 is not yet released”这种报错，本质上是版本号写错了或者源里还没有这个版本。Node.js 的版本发布有严格的节奏，奇数版本是过渡版，偶数版本才是长期支持版（LTS）。生产环境或者日常开发，认准 LTS 就对了。

我个人的建议很明确：不要用系统自带的 Node.js。Ubuntu 的 apt 源里的 Node.js 往往版本偏旧，装 Claude Code 时经常提示引擎不兼容。正确做法是用版本管理工具，或者至少从官方渠道装一个较新的 LTS。

2.2 Ubuntu 下安装 Node.js 20+ 的稳妥路径

在 Ubuntu 上，我试过三种方式，各有适用场景：

第一种是 NodeSource 源安装，适合想要系统级全局 Node.js 的场景。命令大致是这样：

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs

装完用node -v确认版本。这种方式的好处是全局可用，坏处是切换版本麻烦。

第二种是 nvm（Node Version Manager），我个人最推荐。它把 Node.js 装在用户目录下，切换版本一条命令搞定：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 nvm alias default 20

第三种是直接下载官方二进制包解压，适合没有网络包管理权限的环境。从 Node.js 官网下载 LTS 的 Linux 二进制压缩包，解压后把 bin 目录加到 PATH 里即可。

注意：无论哪种方式，装完后一定要确认node -v和npm -v都能正常输出。很多“安装 Claude Code 失败”的问题，根源就是 npm 全局路径没配好。

2.3 npm 全局目录与权限处理

用 npm 装全局 CLI 工具时，最常见的报错是 EACCES 权限错误。原因是 npm 默认往系统目录写，普通用户没权限。解决办法有两种：一是用 nvm 管理 Node.js，全局包会装在用户目录下，天然没这个问题；二是手动改 npm 的全局前缀：

mkdir -p ~/.npm-global npm config set prefix '~/.npm-global' echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc source ~/.bashrc

这一步做完，后面装 Claude Code、Codex 都会顺畅很多。我踩过的坑是：改完 prefix 后忘了把 bin 目录加进 PATH，结果装完了命令找不到，白白排查半天。

3. Claude Code 与 Codex 的安装配置实战

3.1 Claude Code 安装与首次配置

Claude Code 的安装本身不复杂，通过 npm 全局安装即可：

npm install -g @anthropic-ai/claude-code

装完后在项目目录里运行claude就能启动。首次使用需要完成认证，按照提示走即可。这里有个细节：Claude Code 会读取当前目录作为工作上下文，所以最好在具体项目根目录下启动，而不是在用户主目录里乱跑。

在 VS Code 里使用 Claude Code，可以装对应的扩展，然后在集成终端里调用。热搜词里“vscode配置claude code”和“vscode接入claude code”问的人很多，核心就是两步：装扩展、在终端里确保claude命令可用。如果 VS Code 的终端找不到命令，多半是 PATH 没继承，重启 VS Code 或者检查 shell 配置即可。

3.2 Codex 安装与登录问题排查

Codex 的安装同样走 npm 路线，具体包名以官方文档为准。安装后运行登录命令，常见问题集中在“codex登录不上”和“codex无法加载组织设置”。前者通常是网络或认证回调问题，后者多半是账号权限或组织策略限制。

热搜里还有一条“codex is ignoring 1 unrecognized configuration setting”，这是配置文件里有拼写错误或者不支持的字段。Codex 的配置文件一般是 JSON 或 TOML 格式，改的时候要严格对照官方文档的字段名。我的经验是：改配置前先备份，改完用工具自带的校验命令过一遍，别直接上生产。

3.3 两个工具共存时的路径与版本隔离

Claude Code 和 Codex 同时装，最容易冲突的地方是全局命令名和配置目录。好在它们的命令名不同，一般不会直接打架。但如果你用 nvm 切换了 Node.js 版本，之前装的全局包在新版本下就不可见了，需要重新安装。这是 nvm 的特性，不是 bug。

我的做法是：固定一个 Node.js LTS 版本作为 AI 工具专用版本，用nvm alias default设好，所有全局 CLI 都装在这个版本下。这样切换项目时不会因为 Node.js 版本变化导致工具消失。

4. tmux：让 AI 编程会话永不掉线的核心

4.1 为什么 AI 编程助手特别需要 tmux

Claude Code 和 Codex 都是交互式 CLI，一次会话可能持续几十分钟甚至更久。如果你在 SSH 远程服务器上跑，网络一抖或者终端一关，会话就没了，之前积累的上下文全部丢失。tmux 的作用就是创建一个持久化的终端会话，即使你断开连接，会话里的进程依然在跑，重新连上后tmux attach就能回到原来的界面。

这跟 openrig 的理念高度契合：把 AI 助手当成一个长期运行的服务来管理，而不是一次性的命令行调用。

4.2 tmux 基础操作与常用配置

tmux 的核心概念是会话（session）、窗口（window）、面板（pane）。最常用的命令：

tmux new -s ai # 新建名为 ai 的会话 tmux ls # 列出所有会话 tmux attach -t ai # 重新接入 ai 会话 tmux kill-session -t ai # 结束会话

在会话内部，默认前缀键是Ctrl+b，然后按d可以脱离（detach），按c新建窗口，按%垂直分屏，按"水平分屏。

我建议改一下配置，把前缀键换成Ctrl+a，更顺手。在~/.tmux.conf里加：

set -g prefix C-a unbind C-b bind C-a send-prefix set -g mouse on

开启鼠标支持后，切换面板、调整大小都能用鼠标操作，对新手友好很多。

4.3 用 tmux 编排 Claude Code 与 Codex 的工作流

我的实际用法是这样的：开一个 tmux 会话叫ai，里面分三个窗口。窗口 1 跑 Claude Code，窗口 2 跑 Codex，窗口 3 用来跑本地模型服务或者看日志。这样我在一个终端里就能管理所有 AI 工具，切换用Ctrl+a加数字键。

更进一步，可以在 tmux 里做面板分屏：左边跑 Claude Code 做代码生成，右边跑一个 shell 用来执行生成的命令和验证结果。这种“左生成右验证”的布局，效率比来回切换终端高得多。

提示：tmux 会话里的环境变量继承自创建会话时的 shell。如果你在创建会话后才改了 PATH 或 API 相关的环境变量，会话里是看不到的。要么重新创建会话，要么在会话内手动 export。

5. 模型接入：本地模型与第三方 API 的切换策略

5.1 Claude Code 调用 LM Studio 本地模型的链路

热搜词里“claude code 调用lmstudio的本地模型”是一个高频需求。核心思路是：LM Studio 在本地起一个兼容 OpenAI 接口的服务，然后通过配置让 Claude Code 把请求指向这个本地端点。

LM Studio 启动本地服务器后，默认监听一个本地端口，提供/v1/chat/completions这类接口。Claude Code 本身对端点的支持需要通过环境变量或配置文件指定。具体来说，需要设置 API base URL 指向本地地址，API key 随便填一个非空值（本地服务通常不校验）。

这里的关键难点是接口兼容性。Claude Code 期望的请求格式和 OpenAI 格式可能有差异，所以有时候需要中间加一层转换。如果直接接不通，可以先用 curl 测试本地端点是否正常响应，再排查格式问题。

5.2 用 cc switch 类方案切换 DeepSeek、Qwen、GLM

热搜里“使用cc switch 接入 deepseek v4, qwen, glm等模型”反映了一个真实痛点：不同任务想用不同模型，但每次改配置太麻烦。cc switch 这类工具的思路是维护多套配置，一键切换。

实现方式通常有两种：一是维护多个配置文件，切换时软链接或者复制到生效位置；二是用环境变量控制，启动前 export 不同的 base URL 和 key。我倾向于第二种，写几个 shell 函数放在.bashrc里：

use_deepseek() { export AI_BASE_URL="https://api.deepseek.com" export AI_API_KEY="你的key" } use_qwen() { export AI_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1" export AI_API_KEY="你的key" }

这样在 tmux 会话里切换模型，一条命令搞定。注意不同厂商的接口路径和参数名可能有细微差别，接入前先看官方文档的兼容性说明。

5.3 端点报错与配置校验的通用方法

热搜里“cc switch local proxy failed while handling codex endpoint /responses”这类报错，本质是代理层在转发请求时，目标端点不认这个路径或者请求体格式不对。排查顺序建议是：

1. 确认目标端点是否真的支持该路径。有些服务只支持/v1/chat/completions，不支持/responses。
2. 用 curl 直接打目标端点，排除代理层干扰。
3. 检查请求头里的认证字段名是否正确，不同厂商可能是Authorization或api-key。
4. 看代理日志，确认转发出去的请求体长什么样。

我踩过的坑是：本地代理配置了路径重写，但重写规则写错了，导致所有请求都打到 404。后来养成习惯，代理层改动后先用一个最简单的请求验证链路通不通，再上复杂配置。

6. 常见问题速查与避坑经验

6.1 安装类问题速查表

6.2 登录与认证类问题

Codex 登录不上，先确认网络能正常访问认证服务，再检查系统时间是否准确——时间偏差过大会导致认证令牌校验失败。Claude Code 如果提示组织禁用了订阅访问，那是账号层面的策略限制，需要从账号设置侧解决，不是本地环境问题。

6.3 模型调用类问题

“the 'gpt-5.6-sol' model is not supported”这类报错，说明配置里写的模型名不被当前端点支持。解决方法是查目标端点的模型列表，用实际存在的模型名。模型名是大小写敏感且经常带版本后缀的，别凭记忆写。

6.4 会话管理类问题

tmux 会话里跑 Claude Code，如果发现输出卡住不动，先检查是不是面板处于 copy mode（按q退出）。另外，tmux 里的终端类型可能影响某些 CLI 的彩色输出和交互，必要时在.tmux.conf里设置set -g default-terminal "screen-256color"。

7. 我搭建 openrig 工作流的几点体会

整套环境搭下来，我最大的感受是：AI 编程工具的效率瓶颈往往不在模型本身，而在环境编排。一个稳定的 Node.js 底座、一个持久化的 tmux 会话、一套清晰的模型切换机制，这三样东西带来的体验提升，比换一个更强的模型还明显。

我现在的日常是这样的：服务器上常驻一个 tmux 会话，里面 Claude Code 和 Codex 各占一个窗口，本地模型服务在第三个窗口跑着。需要切换模型时，在对应窗口里执行预定义的 shell 函数。所有配置和脚本都放在一个 git 仓库里管理，换机器时 clone 下来跑个初始化脚本就能恢复整套环境。这套东西没有什么高深技术，但胜在稳定、可复现、不折腾。

如果你刚开始搭，建议先把 Node.js 和 tmux 这两块弄扎实，再往上叠 Claude Code 和 Codex。顺序反了的话，后面排查问题会非常痛苦。另外，所有涉及 API key 的配置都不要硬编码在脚本里，用环境变量或者独立的密钥文件，并且确保这些文件不会被提交到公开仓库。这个习惯，早晚会救你一次。