1. 从openrig这个名字说起它到底想解决什么问题第一次看到openrig这个词我脑子里蹦出来的不是某个具体产品而是一种开放式工作台的直觉。rig在英文里本意是装配、搭建一套设备在开发圈里常被用来指代一套可复用的工具链组合。把open和rig拼在一起字面意思就是开放式的工具装配台。结合热搜词里高频出现的Claude Code、Codex、Node.js、tmux这几个关键词我基本能判断出这个方向的核心诉求把当下主流的AI编程助手Claude Code、Codex CLI这类终端智能体和本地开发环境Node.js运行时、tmux会话管理整合成一套可迁移、可复现、不绑定单一平台的开发工作流。为什么这件事值得单独拿出来讲因为现在绝大多数人用AI编程工具的方式是装一个、用一阵、换一个、重装一遍。Claude Code装完配一遍环境变量Codex CLI装完再配一遍换台机器或者换个系统又得从头来。更麻烦的是这些工具大多以CLI形式运行一旦终端会话断开正在跑的长任务就没了。tmux在这里的价值就体现出来了——它让AI智能体的会话可以脱离终端窗口独立存活你关掉笔记本盖子再打开任务还在跑。所以openrig这类思路真正解决的是三个层面的问题环境一致性不同机器上Node.js版本、全局包、配置文件怎么统一、会话持久性长任务不因终端断开而中断、多工具协同Claude Code和Codex怎么在同一个工作目录下各司其职而不是互相打架。这三件事听起来简单但真正落地时会遇到一堆细节问题比如Node.js版本不对导致CLI直接报错、全局安装权限不足、tmux里环境变量丢失、两个工具抢同一个配置文件等等。这篇文章适合谁看如果你已经在用或者打算用Claude Code、Codex这类终端AI编程工具并且希望把这套东西整理成一套稳定、可复制的工作环境那接下来的内容应该能帮你少走不少弯路。如果你只是听说过这些工具但还没上手也可以把它当成一份从零搭建AI编程工作台的参考路线。我不会只给命令还会解释每条命令背后的意图以及我在实际配置中踩过的坑。2. Node.js是整个工具链的地基版本选错后面全白搭2.1 为什么这些CLI工具都绕不开Node.jsClaude Code和Codex CLI这类工具本质上是通过npm分发的命令行程序。npm是Node.js自带的包管理器所以你机器上必须先有一个可用的Node.js运行时才能通过npm install -g把工具装到全局。这就意味着Node.js的版本直接决定了这些工具能不能装、能不能跑。热搜词里有一条特别扎眼error installing 24.21.0: node.js v24.21.0 is not yet released or is not available。这个报错我见过太多次了原因通常是有人照着某个教程里的版本号去下载但那个版本要么还没正式发布要么对应的镜像源还没同步。Node.js的版本号是有严格规则的偶数版本是LTS长期支持版奇数版本是Current尝鲜版。生产环境和工作流搭建我一律建议用LTS版本因为LTS有更长的维护周期和更稳定的依赖兼容性。截至我写这篇内容时Node.js 20.x和22.x都是比较稳妥的LTS选择。不要盲目追最新的Current版本很多CLI工具的原生依赖比如某些需要编译的模块在最新版Node上可能还没适配装到一半报编译错误排查起来非常费劲。2.2 安装Node.js的几种方式与取舍安装Node.js常见的有三条路官网下载安装包、用系统包管理器apt/brew、用版本管理工具nvm/fnm。这三条路我分别说一下适用场景。官网下载安装包最直观适合完全新手双击下一步就行。但缺点是版本切换麻烦想换版本得卸载重装。系统包管理器Ubuntu上用aptmacOS上用brew装起来也快但系统源里的Node版本往往偏旧而且升级时容易和系统其他依赖产生冲突。我个人的首选是版本管理工具Linux和macOS上用nvmWindows上可以用nvm-windows或者fnm。版本管理工具的好处是可以在多个Node版本之间秒切这对同时维护多个项目的开发者来说是刚需。以nvm为例安装完成后切换版本的命令很直接# 查看当前可用的LTS版本 nvm ls-remote --lts # 安装指定LTS版本 nvm install 22 # 设为默认版本 nvm alias default 22 # 验证 node -v npm -v这里有个细节值得说nvm alias default这一步很多人会漏掉。如果不设默认版本新开一个终端窗口时nvm可能不会自动加载任何Node版本导致你明明装好了Node新终端里敲node -v却提示command not found。这个坑我在tmux里踩得最惨——tmux新建的会话默认不加载nvm的初始化脚本所以即使你在普通终端里Node好好的进了tmux就找不到Node了。2.3 tmux会话里Node找不到的根因与修复这个问题的本质是shell初始化文件的加载顺序。nvm的安装脚本通常写在~/.bashrc或~/.zshrc里而tmux默认启动的是非登录shell某些配置下不会完整加载这些文件。解决办法有两个一是确保nvm的初始化代码写在会被tmux加载的文件里二是在tmux配置里显式指定使用登录shell。我通常的做法是在~/.tmux.conf里加一行让tmux用登录shell启动set-option -g default-command bash -l或者更彻底一点把nvm的加载逻辑同时写进~/.bash_profile和~/.bashrc确保无论登录shell还是非登录shell都能加载到。验证方法很简单在普通终端里node -v能出版本号然后tmux new -s test进tmux再敲一次node -v如果两边一致就说明配置没问题。提示如果你用的是zsh对应的文件是~/.zshrc和~/.zprofile逻辑是一样的。别只改一个文件就以为万事大吉tmux的shell加载行为和你日常用的终端可能不一样。3. Claude Code与Codex的安装配置两条路线同一套底层逻辑3.1 安装前的环境自检清单在动手装Claude Code或Codex之前我习惯先跑一遍自检确认地基没问题。这份清单不长但能省掉后面一大堆莫名其妙的报错Node.js版本是否为LTSnode -v和npm -v都能正常输出版本号npm全局安装目录是否有写权限npm config get prefix看一下路径如果是系统目录比如/usr/local普通用户可能没权限写入网络能否正常访问npm registrynpm ping可以快速验证终端是否支持交互式输入某些精简版终端可能缺少必要的TTY支持关于npm全局权限这里展开说一下。Linux和macOS上如果npm config get prefix指向的是/usr/local或/usr直接npm install -g大概率会报EACCES权限错误。网上有些教程会让你用sudo npm install -g我强烈不建议这么做因为sudo安装的全局包属于root用户后续升级、卸载都会遇到权限混乱。正确的做法是把npm的全局目录改到用户主目录下# 创建用户级全局目录 mkdir -p ~/.npm-global # 配置npm使用该目录 npm config set prefix ~/.npm-global # 把该目录加入PATH写进~/.bashrc或~/.zshrc export PATH~/.npm-global/bin:$PATH # 重新加载配置 source ~/.bashrc改完之后再npm install -g就不需要sudo了后续管理也清爽很多。3.2 Claude Code的安装与首次配置Claude Code通过npm全局安装命令本身很简单npm install -g anthropic-ai/claude-code装完之后在项目目录下直接敲claude就能启动。首次启动会引导你完成认证配置。这里有个热搜词提到your organization has disabled claude subscription access for claude code这个报错通常出现在企业账号环境下说明组织管理员在后台关闭了Claude Code的访问权限。遇到这种情况要么找管理员开通要么换用个人账号。这不是技术问题是账号策略问题排查方向别搞错了。另一个高频问题是claude code might not be available in your country这属于服务可用性层面的限制不在本文讨论范围内遇到时以官方文档说明为准。配置层面Claude Code支持通过环境变量或配置文件指定模型、API端点等参数。如果你要接入本地模型比如通过LM Studio跑的本地模型需要配置对应的API base URL。热搜词里claude code 调用lmstudio的本地模型就是这个场景。LM Studio默认在本地的1234端口提供OpenAI兼容接口配置时把API base指向http://localhost:1234/v1即可。具体配置项名称以你所用版本的官方文档为准因为这类工具的配置字段偶尔会调整。3.3 Codex CLI的安装与常见报错处理Codex CLI同样是npm分发的npm install -g openai/codex装完后敲codex启动。热搜词里有一条codex is ignoring 1 unrecognized configuration setting. check for typos or d这是配置文件里有拼写错误或不被识别的字段。Codex的配置文件通常是TOML格式放在~/.codex/config.toml。遇到这个警告第一件事是打开配置文件逐行检查字段名拼写特别注意大小写和下划线。TOML对格式比较敏感少一个引号或者多一个空格都可能触发解析问题。还有一条codex无法加载组织设置这个和Claude Code的组织权限问题类似属于账号层面的策略限制。另外codex接入deepseek这个需求也很常见思路和接入本地模型一样都是通过配置自定义API端点来实现。DeepSeek提供OpenAI兼容的API接口所以在Codex里配置对应的base URL和API key就能用。3.4 两个工具共存时的配置隔离Claude Code和Codex各自有独立的配置目录和配置文件正常情况下不会互相干扰。但有一个场景需要注意如果你在同一个项目目录下同时用两个工具它们可能会各自生成一些缓存文件或会话记录。我的建议是给每个工具明确分工比如Claude Code负责代码审查和重构建议Codex负责快速生成和补全避免两个工具同时对同一批文件做写操作。另外如果你用cc switch这类工具来切换不同的模型后端热搜词里提到使用cc switch 接入 deepseek v4, qwen, glm等模型要注意切换后环境变量和配置文件的同步问题。切换工具本质上是在改API端点和密钥切换完成后最好新开一个终端会话验证一下避免旧的环境变量残留导致请求发到了错误的后端。4. tmux才是让AI编程助手真正干活的关键一环4.1 为什么CLI型AI工具特别依赖tmuxClaude Code和Codex都是交互式CLI程序你给它一个任务它可能要跑几分钟甚至更久——读文件、分析代码、生成修改、执行测试。如果你直接在普通终端里跑一旦网络波动导致SSH断开或者你不小心关了终端窗口整个会话就没了之前跑的进度也白费。tmux解决的就是这个问题。它创建一个独立于终端窗口的会话你把AI工具跑在tmux会话里终端断开后会话继续在后台运行重新连接后用tmux attach就能回到原来的界面任务进度完好无损。对于需要长时间运行的代码生成、批量重构、测试执行这类任务tmux几乎是必备的。4.2 一套实用的tmux工作流配置我日常用的tmux配置不复杂但几个关键项能显著提升体验。首先是前缀键默认是Ctrlb我习惯改成Ctrla因为手更顺手。其次是开启鼠标支持方便滚动和选择窗格。再就是设置更大的回滚缓冲区AI工具输出内容多默认的回滚行数经常不够用。# ~/.tmux.conf 核心配置 set -g prefix C-a unbind C-b bind C-a send-prefix set -g mouse on set -g history-limit 50000 # 窗格切换用vim风格 bind h select-pane -L bind j select-pane -D bind k select-pane -U bind l select-pane -R # 新窗口和窗格从当前路径开始 bind c new-window -c #{pane_current_path} bind % split-window -h -c #{pane_current_path} bind split-window -v -c #{pane_current_path}history-limit这一项特别值得调大。默认2000行AI工具一次输出几百行代码分析结果很常见几下就滚没了。设成50000之后基本不用担心历史输出丢失。4.3 为AI编程任务设计tmux会话布局我的习惯是给每个项目建一个独立的tmux会话会话名用项目名方便识别。会话内部通常分三个窗格左边大窗格跑AI工具Claude Code或Codex右上角跑一个shell用于手动执行命令和查看文件右下角跑测试或日志监控。创建这样的布局可以用一条命令搞定# 创建名为myproject的会话第一个窗口跑claude tmux new -s myproject -n ai # 在会话内水平分割 tmux split-window -h # 右侧再垂直分割 tmux split-window -v # 调整窗格大小左侧占70% tmux resize-pane -t 0 -x 70%这样布局的好处是AI工具在左边生成代码或分析结果时我可以在右边实时查看文件变化、手动跑命令验证不用来回切换窗口。测试日志在右下角持续输出一眼就能看到有没有报错。4.4 tmux会话的持久化与恢复tmux本身在系统重启后会话会丢失如果你希望重启后还能恢复之前的会话布局可以配合tmux-resurrect或tmux-continuum这类插件。安装方式是通过tmux的插件管理器TPM# 安装TPM git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm # 在~/.tmux.conf末尾添加 set -g plugin tmux-plugins/tpm set -g plugin tmux-plugins/tmux-resurrect set -g plugin tmux-plugins/tmux-continuum # 设置自动恢复 set -g continuum-restore on # 重新加载配置后按 prefix I 安装插件装好之后prefix Ctrls手动保存会话prefix Ctrlr恢复。开启continuum的自动恢复后系统重启tmux会自动还原上次的会话布局。这个功能对于需要长期维护多个AI编程会话的人来说非常实用。注意tmux-resurrect恢复的是会话布局和运行的程序但程序内部的状态比如AI工具正在处理的上下文不一定能完整恢复。所以关键任务还是建议在完成一个阶段后手动保存进度别完全依赖自动恢复。5. 把工具串起来一套可复现的AI编程工作台搭建流程5.1 从裸机到可用环境的完整步骤前面几章分别讲了Node.js、Claude Code/Codex、tmux现在把它们串成一条完整的搭建流程。以下步骤以Ubuntu为例macOS和WindowsWSL环境逻辑类似只是包管理命令不同。第一步安装基础依赖。Ubuntu上先确保有curl和gitsudo apt update sudo apt install -y curl git build-essentialbuild-essential这一项很多人会漏但某些npm包的native模块编译需要它缺了会在安装时报gyp编译错误。第二步安装nvm和Node.js LTScurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 22 nvm alias default 22第三步配置npm全局目录到用户空间前面3.1节讲过然后安装Claude Code和Codexnpm install -g anthropic-ai/claude-code npm install -g openai/codex第四步安装并配置tmuxsudo apt install -y tmux # 然后写入前面4.2节的~/.tmux.conf配置第五步验证整条链路。新开一个tmux会话在会话里分别敲node -v、claude --version、codex --version三个都能正常输出版本号说明环境打通了。5.2 环境变量与配置文件的统一管理这套工作台涉及的环境变量和配置文件不少Node路径、npm全局目录、API密钥、各工具的配置文件。我的做法是建一个~/.ai-workstation/目录把所有相关配置集中放然后在shell初始化文件里统一source。比如API密钥这类敏感信息不要直接写在.bashrc里明文暴露可以单独放一个~/.ai-workstation/env.sh权限设为600然后在.bashrc里source它# ~/.ai-workstation/env.sh export ANTHROPIC_API_KEYyour-key-here export OPENAI_API_KEYyour-key-here # 其他工具的环境变量# ~/.bashrc 末尾 [ -f ~/.ai-workstation/env.sh ] source ~/.ai-workstation/env.sh这样换机器时只需要把~/.ai-workstation/目录拷过去再在新机器的.bashrc里加一行source环境就迁移过来了。比逐个重新配置省事得多。5.3 多机器同步与版本锁定如果你在多台机器上用这套工作台版本不一致会导致各种诡异问题。我的做法是在~/.ai-workstation/里放一个versions.txt记录当前验证过的各组件版本node: 22.x LTS npm: 10.x claude-code: 记录你验证过的版本 codex: 记录你验证过的版本 tmux: 3.x新机器搭建时照着这个版本清单装能最大程度避免在我机器上好好的换台机器就报错的情况。npm全局包可以用npm list -g --depth0查看当前安装的版本升级前先记录出问题可以回退。5.4 常见故障的快速排查路径搭好之后日常使用中难免遇到问题我整理了一份快速排查路径按从底层到上层的顺序检查现象优先检查项常见原因命令找不到PATH配置、nvm是否加载新终端未加载nvm或全局bin目录不在PATH安装时报EACCESnpm全局目录权限prefix指向系统目录需改到用户目录tmux里Node找不到shell初始化文件加载tmux未用登录shellnvm脚本未加载CLI启动报配置错误配置文件语法TOML/YAML格式错误字段拼写问题请求发到错误后端环境变量残留切换模型后旧变量未清除长任务中断是否在tmux中运行直接在普通终端跑终端断开导致中断排查时遵循一个原则先确认底层Node、PATH没问题再看工具层CLI安装、配置最后看会话层tmux、网络。很多看起来是工具报的错根因其实在Node版本或PATH配置上。6. 我在实际搭建中踩过的几个坑第一个坑是nvm和tmux的加载顺序问题前面提过但值得再强调一次。我当时在普通终端里一切正常进了tmux就报claude: command not found排查了半小时才发现是tmux没加载nvm脚本。修复方法就是4.2节说的让tmux用登录shell启动或者把nvm加载逻辑写进所有shell都会读的文件。第二个坑是npm全局目录权限。早期我图省事用sudo npm install -g结果后来升级工具时各种权限报错最后不得不手动清理/usr/local/lib/node_modules下的残留文件。改到用户级全局目录后这类问题再没出现过。这个改动一次到位后面省心很多。第三个坑是配置文件格式。Codex的TOML配置对格式很严格我有次手写配置时把一个布尔值写成了字符串true写成了true工具启动时只给了一个模糊的警告排查了好一会儿才定位到。后来我养成了改完配置文件先用工具自带的校验命令如果有或者在线TOML校验器过一遍的习惯。第四个坑是关于长任务的。有次我让AI工具跑一个大批量重构没放tmux里结果中途网络抖了一下SSH断了任务直接没了只能重来。从那以后凡是预计超过一分钟的任务我一律先开tmux再跑。这个习惯养成后再没丢过任务进度。最后一个体会是关于工具选择的。Claude Code和Codex各有擅长没必要非此即彼。我的用法是让它们在不同阶段发挥作用配合tmux的窗格布局一个跑着的时候另一个可以待命。关键是底层环境要统一、稳定这样上层工具怎么换都不影响工作流的连续性。把Node.js版本、npm全局目录、tmux会话管理这三件事做扎实后面无论再出什么新的AI编程CLI工具接入成本都会低很多。