企业官网建设流程全解析

1. 从“openrig”这个名字说起：它到底想解决什么问题

第一次看到“openrig”这个词，我脑子里蹦出来的不是某个具体软件，而是一种“开放式工作台”的意象。rig 在英文里本意是“装配、搭建”，在工程语境里常指一套成套的设备或支架，比如采矿用的钻井平台就叫 rig，舞台灯光架也叫 rig。前面加个 open，意思就很明确了——这是一套开放的、可自由拼装的工具台。结合热搜词里高频出现的 Claude Code、Codex、Node.js、tmux 这几个关键词，我基本能判断出 openrig 的定位：它大概率是一个围绕 AI 编程助手（Claude Code、Codex CLI 这类终端智能体）搭建的本地运行环境或编排框架，把 Node.js 运行时、tmux 会话管理、模型接入配置这些东西打包成一套可复用的“工作台”。

为什么我会有这个判断？因为热搜词里几乎全是围绕“怎么把 AI 编程工具跑起来”这个痛点展开的：claude code 安装、codex 安装教程、node.js 安装、ubuntu 配置 claude code、vscode 配置 claude code、codex 接入 deepseek、claude code 调用 lmstudio 的本地模型……这些词拼在一起，就是一幅典型的“我想用 AI 帮我写代码，但环境配置把我卡死了”的众生相。openrig 要做的，就是把这堆零散的配置动作收敛成一个统一的入口。

这篇文章适合谁看？三类人。第一类是被 Node.js 版本、npm 全局安装、PATH 环境变量折腾到怀疑人生的新手，你想用 Claude Code 或 Codex，但连第一步都没迈过去；第二类是想把 AI 编程助手接入本地模型或第三方 API 的进阶用户，你已经在用 CLI 工具，但想让它们更听话、更省钱、更可控；第三类是喜欢折腾终端工作流的老手，你想知道 tmux 和这些 AI 工具怎么配合才能发挥最大价值。我会从环境搭建讲到模型接入，再讲到 tmux 会话编排，最后聊聊实际用下来踩过的坑。

需要先说明一点：openrig 这个项目本身在公开渠道能查到的完整文档并不多，所以下文里涉及具体实现的部分，我会基于“一个合格从业者在搭建这类 AI 编程工作台时最可能采用的合理方案”来补全，并明确标注哪些是通用实践、哪些是我的个人推断。这样你读的时候心里有数，不会把推断当成官方文档。

2. Node.js 环境：所有 AI 编程 CLI 工具的地基

2.1 为什么这些工具都绕不开 Node.js

Claude Code、Codex CLI 这类工具，本质上是用 JavaScript/TypeScript 写的命令行程序，通过 npm 分发。npm 是 Node.js 的包管理器，所以你想装它们，第一步必然是装 Node.js。这就像你想用 Python 的 pip 装包，得先有 Python 解释器一样，没有捷径。

热搜词里有一条特别扎眼：“error installing 24.21.0: node.js v24.21.0 is not yet released or is not available”。这个报错我太熟了，它通常出现在你用 nvm（Node Version Manager）或者某个版本管理工具去装一个还不存在的版本号时。Node.js 的版本号是有严格发布节奏的，偶数版本是 LTS（长期支持版），奇数版本是 Current（尝鲜版），而且大版本号不是随便跳的。有人看到别人说“用 24 版本”，就照着敲nvm install 24.21.0，结果这个具体的小版本根本还没发布，自然报错。

正确的做法是：先查当前 LTS 版本。截至我写这篇内容的时候，Node.js 的 LTS 主线在 20.x 和 22.x 之间，具体小版本号会随时间变化。你可以直接去 Node.js 官网看首页那个大按钮上写的版本号，那就是官方推荐的 LTS。或者用命令查：

nvm ls-remote --lts | tail -5

这条命令会列出远程所有 LTS 版本，取最后一个就是最新的 LTS。装的时候只写大版本号，让 nvm 自己选最新的小版本：

nvm install --lts nvm use --lts nvm alias default lts/*

最后一行是把 LTS 设为默认版本，这样你新开终端不用每次手动nvm use。

2.2 Windows、macOS、Ubuntu 三平台的安装差异

热搜词里同时出现了“node.js下载”“node.js官网下载”“安装node.js”“node.js lts下载”“ubuntu 安装claude code”“claude code windows”，说明跨平台是刚需。我把三个平台的关键差异列一下，这些都是实测下来最容易卡住的地方。

Windows 用户特别注意：如果你用 .msi 安装，安装向导里有一个“Add to PATH”的选项，默认是勾上的，但如果你之前装过又卸载过，注册表里可能残留，导致新装的 node 没进 PATH。验证方法是开一个新的 PowerShell 窗口，敲node -v，如果提示“不是内部或外部命令”，就是 PATH 没配好。手动加 PATH 的路径通常是C:\Program Files\nodejs\。

Ubuntu 用户注意：sudo apt install nodejs装出来的版本往往很老，因为 Ubuntu 的软件源更新滞后。我见过有人用 apt 装了 Node 12，然后去装 Claude Code，直接报引擎不兼容。正确做法是用 nvm，或者加 NodeSource 的源：

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

但说实话，我更推荐 nvm，因为它不污染系统环境，切换版本也方便，卸载的时候删掉~/.nvm目录就干净了。

2.3 npm 全局安装的权限问题与解决方案

装完 Node.js，下一步就是npm install -g装 Claude Code 或 Codex。这里有一个经典报错：EACCES: permission denied。原因是 npm 默认把全局包装到系统目录（比如/usr/local/lib/node_modules），普通用户没写权限。

网上流传的解决方案是sudo npm install -g，我强烈不建议这么做。用 sudo 装全局包，会把包的所有者变成 root，后续升级、卸载都可能出权限问题，而且有安全风险。正确的做法有两种：

第一种，用 nvm 管理 Node.js。nvm 会把全局包装在用户目录下（~/.nvm/versions/node/vXX/lib/node_modules），天然没有权限问题。这也是我推荐 nvm 的另一个理由。

第二种，如果你坚持用系统 Node.js，就改 npm 的全局目录到用户目录：

mkdir -p ~/.npm-global npm config set prefix '~/.npm-global'

然后把~/.npm-global/bin加到 PATH 里。在~/.bashrc或~/.zshrc里加一行：

export PATH=~/.npm-global/bin:$PATH

改完记得source ~/.bashrc或者重开终端。

提示：如果你已经用 sudo 装过全局包，先卸载干净再改配置，否则残留的 root 权限文件会继续捣乱。卸载命令是sudo npm uninstall -g <包名>。

3. Claude Code 与 Codex 的安装配置：两条路线怎么选

3.1 Claude Code 的安装与首次登录

Claude Code 的安装命令很简单：

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

装完之后，在终端敲claude就能启动。首次启动会引导你登录，通常是打开浏览器完成 OAuth 授权。热搜词里有一条“your organization has disabled claude subscription access for claude code”，这个报错的意思是：你所在的组织（企业账号）的管理员关闭了 Claude Code 的订阅访问权限。如果你用的是个人账号，一般不会遇到；如果是公司统一采购的账号，就得找管理员开通。

还有一条“note: claude code might not be available in your country”，这是地区可用性提示。遇到这个，说明当前网络环境或账号地区不在支持范围内，这个我没法展开讲，你懂的，合规使用就好。

登录完成后，Claude Code 会在你的项目目录下工作。它的核心能力是：读取你当前目录的文件，理解代码上下文，然后根据你的自然语言指令修改代码、执行命令。热搜词里“claude code如何直接执行终端命令”这个问题，答案是它在获得你授权后可以直接跑 shell 命令，比如让它“跑一下测试”，它会执行npm test并把结果读回来分析。

3.2 Codex CLI 的安装与配置要点

Codex CLI 的安装通常是：

npm install -g @openai/codex

或者通过其他包名，具体以官方文档为准。装完后敲codex启动。热搜词里“codex登录”“codex配置”“codex安装 windows桌面版”“codex cli”都指向同一个需求：把它跑起来并配好。

Codex 的配置一般放在用户目录下的配置文件里，比如~/.codex/config.toml或类似路径。热搜词里有一条“codex is ignoring 1 unrecognized configuration setting. check for typos or d”，这是配置文件里写了它不认识的字段。遇到这个，先检查拼写，再对照官方文档确认这个字段在当前版本是否还存在。AI 工具迭代快，配置文件格式经常变，旧教程里的字段可能已经废弃了。

还有一条“codex无法加载组织设置”，这通常和账号权限或网络请求有关。如果是企业账号，可能是组织策略限制了某些功能；如果是个人账号，检查一下配置文件里的 API 端点是否正确。

3.3 两条路线的选型对比

Claude Code 和 Codex 不是非此即彼的关系，很多人两个都装。我把它们的差异整理成表，方便你按需选择。

我的个人经验是：Claude Code 在理解大型项目、跨文件重构上更稳，Codex 在单文件快速生成和命令行脚本上更利索。两个都装，按任务切换，是最实用的策略。

4. 接入本地模型与第三方 API：省钱和可控的关键

4.1 为什么要接入本地模型

热搜词里“claude code 调用 lmstudio 的本地模型”“codex接入deepseek”“使用cc switch 接入 deepseek v4, qwen, glm等模型”这几条，指向一个共同需求：不想只用官方云端模型，想接入本地跑的模型或者第三方 API。

动机无非三个。第一是成本，官方 API 按 token 计费，用量大了肉疼，本地模型跑在自己的机器上，电费而已。第二是隐私，有些代码不方便发到云端，本地模型全程不出机器。第三是灵活性，不同模型擅长不同任务，DeepSeek 写代码强，Qwen 中文理解好，GLM 在某些场景有优势，能切换就多一种选择。

LM Studio 是一个可以在本地跑大模型的桌面应用，它启动后会暴露一个兼容 OpenAI 格式的 API 端点，通常是http://localhost:1234/v1。Claude Code 和 Codex 如果支持自定义 API 端点，就能指向这个地址，从而用上本地模型。

4.2 配置本地模型端点的通用思路

虽然 Claude Code 和 Codex 的具体配置字段不同，但思路是一致的：找到配置文件里设置 API Base URL 和 API Key 的地方，改成你本地或第三方的地址。

以接入 LM Studio 为例，通用步骤是：

1. 启动 LM Studio，加载一个模型（比如 Qwen 或 DeepSeek 的量化版），开启本地服务器，记下端口号。
2. 找到 AI 工具的配置文件，把 base URL 改成http://localhost:1234/v1。
3. API Key 随便填一个非空字符串，因为本地服务通常不校验。
4. 把模型名称改成 LM Studio 里加载的模型标识。

这里有个坑：不是所有模型都支持工具调用（function calling）。Claude Code 和 Codex 这类工具高度依赖模型返回结构化的工具调用指令，如果本地模型不支持，它就没法执行终端命令或读写文件，只能聊天。所以选本地模型时，优先选官方明确支持 tool use 的，比如 Qwen 系列的某些版本、DeepSeek 的某些版本。

4.3 cc switch 这类切换工具的价值

热搜词里“使用cc switch 接入 deepseek v4, qwen, glm等模型”提到的 cc switch，我理解是一个配置切换工具，让你在不同模型供应商之间快速切换，不用手动改配置文件。这类工具的价值在于：你可能有多个 API Key，分别对应 DeepSeek、Qwen、GLM，每次切换都要改 base URL、API Key、模型名，很烦。有了切换工具，一条命令搞定。

如果你不想用第三方切换工具，也可以自己写个简单的 shell 脚本，用环境变量控制：

#!/bin/bash # switch-model.sh case "$1" in deepseek) export OPENAI_BASE_URL="https://api.deepseek.com/v1" export OPENAI_API_KEY="你的deepseek key" export OPENAI_MODEL="deepseek-chat" ;; qwen) export OPENAI_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1" export OPENAI_API_KEY="你的qwen key" export OPENAI_MODEL="qwen-max" ;; local) export OPENAI_BASE_URL="http://localhost:1234/v1" export OPENAI_API_KEY="local" export OPENAI_MODEL="local-model" ;; esac echo "已切换到 $1"

然后source switch-model.sh deepseek就能切换。前提是 AI 工具支持从环境变量读取这些配置，大部分 CLI 工具都支持。

注意：第三方 API 的兼容性参差不齐。有些供应商声称兼容 OpenAI 格式，但工具调用、流式输出、多轮对话的细节实现有差异，可能导致 AI 工具行为异常。接入前先用 curl 测一下基本的 chat completions 接口通不通。

5. tmux：让 AI 编程助手在后台稳定干活

5.1 tmux 解决的核心痛点

热搜词里出现 tmux，不是偶然。AI 编程助手跑任务往往耗时较长，比如让它重构一个模块、跑一遍完整测试、生成一批文件，可能几分钟到几十分钟。如果你直接在终端前台跑，一旦网络波动、SSH 断开、或者你不小心关了窗口，任务就中断了，前面的进度可能白费。

tmux 是一个终端复用器，它让你在一个终端窗口里开多个会话，会话可以脱离窗口在后台持续运行。你 SSH 连上服务器，开一个 tmux 会话，在里面跑 Claude Code，然后 detach（分离），关掉 SSH，任务继续跑。下次连上来 attach（附着）回去，接着看结果。这就是 tmux 对 AI 编程工作流最大的价值：任务不中断。

5.2 一套实用的 tmux 工作流

我平时用 tmux 配合 AI 工具的习惯是这样的：

# 新建一个名为 ai-work 的会话 tmux new -s ai-work # 在会话里启动 claude 或 codex claude # 按 Ctrl+b 然后按 d，分离会话，任务继续在后台跑 # 下次连上来，重新附着 tmux attach -t ai-work # 查看所有会话 tmux ls # 杀掉某个会话 tmux kill-session -t ai-work

如果你想让 tmux 里开多个窗格，一个跑 AI 工具，一个看日志，一个跑测试，可以这样：

# 在 tmux 会话里，按 Ctrl+b 然后按 % 垂直分屏 # 按 Ctrl+b 然后按 " 水平分屏 # 按 Ctrl+b 然后按方向键切换窗格

这样你让 Claude Code 在左边改代码，右边窗格实时看npm run dev的输出，效率比来回切窗口高很多。

5.3 tmux 与 AI 工具配合的进阶技巧

一个很实用的技巧是：用 tmux 的send-keys命令给后台运行的 AI 工具发指令。比如你有一个长时间跑的 Codex 会话，想让它中途执行某个命令，可以：

tmux send-keys -t ai-work "请检查一下刚才生成的代码有没有语法错误" Enter

这条命令会把文字发到 ai-work 会话的当前窗格，并模拟回车。这样你可以在脚本里编排 AI 工具的行为，实现半自动化。

另一个技巧是日志留存。tmux 默认的滚动缓冲区有限，AI 工具输出长了会滚掉。你可以在 tmux 配置里加大历史行数：

# ~/.tmux.conf set-option -g history-limit 50000

这样往上翻能看更多历史输出。或者更彻底一点，用tmux pipe-pane把窗格输出实时写到文件：

tmux pipe-pane -t ai-work -o 'cat >> ~/ai-work.log'

这样 AI 工具的所有输出都会追加到~/ai-work.log，方便事后复盘。

6. 编辑器集成：VS Code 里怎么用这些工具

6.1 VS Code 集成 Claude Code 的两种方式

热搜词里“vscode配置claude code”“claude code for vs code”“vscode接入claude code”出现多次，说明很多人不满足于纯终端，想在编辑器里用。

第一种方式是 VS Code 内置终端。Claude Code 本身是 CLI 工具，你在 VS Code 里按Ctrl+`打开集成终端，直接敲claude就能用。这种方式最简单，零配置，而且 VS Code 的终端支持分屏，你可以一边看代码一边和 AI 对话。

第二种方式是装扩展。如果官方或社区有 Claude Code 的 VS Code 扩展，装完后可以在侧边栏或命令面板里直接调用。扩展的好处是能和编辑器深度集成，比如选中一段代码直接让 AI 解释、修改。但扩展的更新往往滞后于 CLI，功能可能不全。我的建议是：主力用 CLI，扩展作为补充。

6.2 在 VS Code 里管理多个 AI 会话

如果你同时用 Claude Code 和 Codex，可以在 VS Code 里开多个终端标签，一个跑 Claude，一个跑 Codex。VS Code 的终端标签可以重命名，右键标签选“Rename”，改成“Claude”和“Codex”，一目了然。

更进一步，你可以用 VS Code 的 Task 功能，把启动 AI 工具配置成任务。在.vscode/tasks.json里加：

{ "version": "2.0.0", "tasks": [ { "label": "Start Claude Code", "type": "shell", "command": "claude", "presentation": { "panel": "dedicated", "reveal": "always" } }, { "label": "Start Codex", "type": "shell", "command": "codex", "presentation": { "panel": "dedicated", "reveal": "always" } } ] }

然后按Ctrl+Shift+P，输入“Run Task”，选对应的任务就能启动。这样比每次手敲命令快。

6.3 编辑器集成的常见坑

一个常见的坑是：VS Code 集成终端的环境变量和系统终端不一致。比如你在~/.zshrc里配了 API Key，但 VS Code 的终端用的是 bash，读的是~/.bashrc，结果 AI 工具找不到 Key。解决办法是确认 VS Code 默认终端是哪个 shell，在设置里搜“terminal integrated default profile”，选对你配置了环境变量的那个。

另一个坑是路径问题。VS Code 打开的项目目录和终端的工作目录可能不一致。Claude Code 默认读取当前工作目录的文件，如果目录不对，它就读不到你的代码。启动前先pwd确认一下，或者用cd切到项目根目录再启动。

7. 实际使用中踩过的坑与排查思路

7.1 安装阶段的典型报错

“error installing 24.21.0”这个报错我在前面解释过了，是版本号不存在。还有一个变体是“npm ERR! code EBADENGINE”，意思是当前 Node.js 版本不满足包的引擎要求。比如某个 AI 工具要求 Node >= 18，你用的是 16，就会报这个。解决办法就是升级 Node.js 到 LTS。

“codex is ignoring 1 unrecognized configuration setting”这个报错，是配置文件里有它不认识的字段。排查步骤：先看报错里有没有提示具体是哪个字段，有的话对照官方文档确认；没有的话，把配置文件里最近加的字段逐个注释掉，二分法定位。

7.2 登录与权限阶段的报错

“your organization has disabled claude subscription access”是企业账号权限问题，找管理员。“codex无法加载组织设置”可能是网络请求失败或账号配置问题，先检查网络，再检查账号是否有对应权限。

“note: claude code might not be available in your country”是地区限制提示，这个不展开。

7.3 运行阶段的异常行为

AI 工具跑起来后，最常见的异常是“它不执行命令”或“它读不到文件”。原因通常是模型不支持工具调用，或者工作目录不对。排查顺序：先确认当前目录是不是项目根目录，再确认用的模型是否支持 function calling，最后看工具的日志输出有没有报错。

还有一个坑是 API 超时。第三方 API 或本地模型响应慢，AI 工具等不及就报超时。解决办法是找工具配置里的超时设置，调大一点。本地模型如果跑在性能一般的机器上，首 token 延迟可能十几秒，超时设太短就会频繁失败。

7.4 我的排查工具箱

遇到问题，我通常按这个顺序排查：

1. node -v和npm -v确认基础环境。
2. which claude或which codex确认工具装在哪、PATH 对不对。
3. 看工具的日志文件，通常在~/.claude/或~/.codex/目录下。
4. 用 curl 直接测 API 端点通不通。
5. 换一个最简单的任务测试，排除是任务本身太复杂导致的失败。

这套流程能解决八成以上的问题。剩下的两成，通常是版本兼容性或供应商 API 的细节差异，只能查文档或社区 issue。

8. 把 openrig 当成一套可复用的工作台来搭

回到 openrig 这个名字。我理解它的野心不是做一个新工具，而是把 Node.js、Claude Code、Codex、tmux、本地模型接入这些零散的东西，整合成一套开箱即用的工作台。你不需要每次从零配环境，而是有一套脚本或配置模板，clone 下来改几个参数就能跑。

如果你要自己搭这么一套东西，我的建议是分三层：底层是 Node.js 版本管理（nvm），中间层是 AI 工具的安装和配置（npm 全局包 + 配置文件模板），上层是会话编排（tmux 脚本 + 模型切换脚本）。三层解耦，哪层出问题换哪层，不会牵一发动全身。

具体落地时，我会在项目根目录放一个setup.sh，内容大致是：检查 nvm 是否存在，不存在就装；用 nvm 装 LTS Node.js；npm 全局装 Claude Code 和 Codex；把配置文件模板复制到用户目录；最后打印一段使用说明。这样新机器上跑一遍脚本，五分钟就能进入干活状态。

配置文件模板这块，我习惯把 API Key 抽成环境变量，配置文件里只写$OPENAI_API_KEY这样的占位符，避免把密钥提交到仓库。模型切换用前面说的 shell 脚本，或者用 direnv 这类工具按目录自动加载环境变量。

最后分享一个我自己的小习惯：给每个长期跑的 AI 会话起有意义的名字，比如refactor-auth、gen-tests，而不是默认的0、1。tmux 会话名支持这些，tmux new -s refactor-auth就行。这样tmux ls的时候一眼能看出哪个会话在干什么，不用一个个 attach 进去看。这个习惯在同时跑三四个 AI 任务的时候特别有用，省下的切换时间积少成多。