1. 从 openrig 这个名字说起它到底想解决什么问题第一次看到openrig这个词我脑子里蹦出来的不是某个具体工具而是一种把散装零件拼成一台整机的直觉。rig 在英文里本意是装配、搭建在工程语境里常指把多个独立部件组合成一套可运转的系统。而 open 前缀则暗示了它的姿态——开放、可拆解、可替换。把这两个词放在一起再结合热搜词里高频出现的 Claude Code、Codex、Node.js、tmux 这几个关键词我基本能判断出 openrig 的定位它是一套围绕命令行 AI 编程助手CLI Agent搭建的本地工作台方案核心目标是把 Claude Code、Codex 这类终端里的 AI 编码工具和 Node.js 运行时、tmux 会话管理、本地模型服务比如 LM Studio串成一条顺畅的流水线。为什么我敢这么判断因为热搜词里几乎全是安装踩坑和配置失败类的长尾词。cc switch local proxy failed while handling codex endpoint /responses、error installing 24.21.0: node.js v24.21.0 is not yet released、codex is ignoring 1 unrecognized configuration setting、your organization has disabled claude subscription access——这些词条拼在一起勾勒出的是一幅非常真实的画面一个开发者想在本地把 AI 编码助手跑起来结果在 Node.js 版本、代理转发、模型端点、组织权限这四道关卡上反复卡壳。openrig 要做的就是把这些零散的配置动作收敛成一套可复现的装配流程。我自己的判断是openrig 的价值不在于发明了什么新技术而在于它承认了一个事实CLI 类 AI 工具的真正门槛从来不是模型能力而是环境装配。你让一个刚接触的人去装 Claude Code他大概率会经历Node.js 版本不对 → npm 全局路径没配 → tmux 里 TUI 渲染错乱 → 代理端点 404 → 组织权限被禁这一整套连环坑。openrig 这类方案的意义就是把这套坑提前踩完给出一条能走通的路。这篇文章我打算按装配一台机器的思路来写先讲清楚这套工作台的各个部件分别是什么、为什么需要它们再逐个拆解 Node.js、tmux、Claude Code、Codex 的安装与配置细节然后重点讲代理转发和本地模型接入这两个最容易翻车的环节最后给出一套排查方法论。适合已经决定用 CLI 方式做 AI 辅助编码、但被环境问题卡住的开发者也适合想把这套流程固化下来做团队标准化的技术负责人。2. 拆解 openrig 的四大部件为什么是 Node.js、tmux、Claude Code、Codex2.1 Node.js 在这套体系里扮演的是地基角色很多人会疑惑Claude Code 和 Codex 都是 CLI 工具为什么非得依赖 Node.js答案很直接这两者的官方分发形态都是 npm 包。Claude Code 通过npm install -g anthropic-ai/claude-code安装Codex CLI 同样是 npm 生态里的包。npm 是 Node.js 自带的包管理器所以没有 Node.js这两个工具连安装入口都没有。但这里有个容易被忽略的细节Node.js 的版本选择直接决定了后续所有环节的稳定性。热搜词里那条error installing 24.21.0: node.js v24.21.0 is not yet released or is not available就是典型症状——用户照着某个教程去装一个还不存在的版本号或者用了某个版本管理器nvm、fnm去拉一个未发布的版本结果直接报错。我的经验是CLI AI 工具对 Node.js 版本的要求通常落在 LTS 区间也就是 20.x 或 22.x 这两个偶数大版本上。奇数版本21、23虽然能跑但生态兼容性差遇到原生模块编译时容易出问题。为什么强调 LTS因为 npm 包的依赖树里经常藏着需要编译的原生模块比如某些终端渲染库、加密库。LTS 版本的 ABI应用二进制接口稳定预编译产物覆盖全装起来几乎不会触发本地编译。而奇数版本或者刚发布的版本预编译产物往往还没跟上npm 就会退化成从源码编译这时候你机器上如果没有 Python 和 C 构建工具链就会卡在node-gyp报错上。这是我在多个项目里反复验证过的规律。2.2 tmux 解决的是会话持久化这个隐形痛点如果你只是偶尔用一下 Claude Code可能感觉不到 tmux 的必要性。但一旦你开始认真用它写代码问题就来了CLI 类 AI 工具是长驻进程一次对话可能持续几十分钟中间还要执行终端命令、读写文件。如果你用的是普通 SSH 会话或者一个终端窗口网络一抖、窗口一关整个会话就没了之前积累的上下文全部丢失。tmux 在这里的作用是把 AI 会话从终端窗口里解耦出来。它创建一个独立于终端的会话session你可以随时 detach分离再 attach重新接入会话里的进程一直在跑。这对 Claude Code 尤其重要因为它支持直接执行终端命令这个能力——热搜词里就有claude code如何直接执行终端命令。当 AI 在 tmux 会话里执行命令时输出会被完整保留在 pane 的滚动缓冲里你重新 attach 回来还能往上翻看历史。还有一个更实际的理由Claude Code 和 Codex 的 TUI终端用户界面在 tmux 里的表现通常比裸终端更稳定。裸终端下窗口大小变化、光标位置计算容易出 bug而 tmux 提供了统一的终端抽象层TUI 库比如 Ink、Blessed在 tmux 里的渲染一致性更好。我实测下来同样的 Claude Code 版本在 tmux 里跑比在裸 SSH 里跑界面错乱的概率低很多。2.3 Claude Code 与 Codex 是两条并行的执行臂把这两个工具放在一起讲是因为它们定位相似但生态不同。Claude Code 是 Anthropic 官方出的 CLI 编码助手深度绑定 Claude 系列模型Codex CLI 则是围绕 OpenAI 模型体系的命令行工具。热搜词里同时出现了claude code安装、codex安装教程、codex接入deepseek、claude code 调用lmstudio的本地模型说明很多人的真实需求是混用——用 Claude Code 的交互体验接 Codex 的模型端点或者反过来把本地模型塞进这两套工具里。这种混用需求正是 openrig 这类装配方案存在的土壤。因为一旦你要混用就必须处理端点转发、协议适配、配置隔离这三件事。Claude Code 默认打的是 Anthropic 的 API 端点Codex 默认打的是 OpenAI 的端点你想让它们都走本地模型或者第三方兼容端点中间就得加一层转发。热搜词里那个cc switch local proxy failed while handling codex endpoint /responses就是这层转发出问题的典型报错——/responses是 OpenAI 新版的响应式端点路径转发层没正确映射这个路径就会 404 或者 500。2.4 四者组合起来才叫 openrig单独看Node.js 是运行时tmux 是会话容器Claude Code 和 Codex 是应用层。但 openrig 的思路是把它们当成一台机器的四个部件来装配Node.js 提供动力tmux 提供稳定的工作台面两个 CLI 工具是两把不同的工具头而配置文件和转发层是把它们连起来的传动轴。理解了这层关系后面所有的安装和排错就都有了主线——任何一个环节出问题都会沿着这条链路传导下去。3. Node.js 安装版本选择与踩坑规避3.1 为什么我坚持用版本管理器而不是系统包管理器在 Ubuntu 上装 Node.js最省事的做法是apt install nodejs但我强烈不建议这么做。原因有两个一是系统源里的 Node.js 版本通常偏旧可能停在 18.x 甚至更早而 Claude Code 这类新工具往往要求 20二是 apt 装的 Node.js 和 npm 是分离的全局包路径、权限管理容易乱后面装全局 CLI 工具时经常遇到EACCES权限错误。我的标准做法是用版本管理器nvm 或 fnm 都行。fnm 是用 Rust 写的启动更快我最近更倾向它。安装 fnm 之后装 Node.js 就是一行命令的事# 安装 fnm以 Ubuntu 为例 curl -fsSL https://fnm.vercel.app/install | bash # 重新加载 shell 配置 source ~/.bashrc # 安装 Node.js 20 LTS fnm install 20 fnm use 20 fnm default 20这里的关键是明确指定大版本号 20而不是写 20.11.1 这种精确版本。热搜词里那个node.js v24.21.0 is not yet released的错误根源就是有人写了一个不存在的精确版本号。版本管理器会自动帮你解析到该大版本下最新的可用小版本既拿到了安全更新又不会踩到版本不存在的坑。3.2 LTS 与 Current 的取舍别被最新两个字骗了Node.js 官网下载页会同时给出 LTS 和 Current 两个版本。Current 是最新特性版版本号是奇数或刚转正的偶数LTS 是长期支持版只保留偶数大版本。很多人看到最新就下意识选 Current结果装完 Claude Code 发现某个依赖编译失败。我的判断标准很简单只要你的用途是跑现成的 CLI 工具一律选 LTS。因为 CLI 工具的维护者测试环境基本都是 LTS他们不会专门去适配 Current 版本。热搜词里node.js lts下载、node.js官网下载这些词的高频出现也侧面说明大家确实在纠结版本选择。给你一个具体的对照版本类型版本号示例适用场景风险LTS20.x、22.x生产环境、CLI 工具、长期项目特性略旧但极稳Current23.x、24.x尝鲜新特性、实验性项目原生模块编译失败率高过旧版本16.x、18.x遗留项目新工具直接不支持3.3 全局包路径与权限那个绕不开的 EACCES装完 Node.js下一步是装全局 CLI 工具。这时候十有八九会遇到权限问题因为 npm 默认把全局包装到/usr/lib/node_modules这种系统目录普通用户没写权限。解决方案不是加sudo——用 sudo 装全局包是坏习惯会导致后续所有 npm 操作都要提权而且包属主变成 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都装到~/.npm-global不需要 sudo也不会污染系统目录。这个配置我建议在装任何全局 CLI 工具之前就做好能省掉后面一大堆权限相关的报错。提示如果你之前已经用 sudo 装过全局包建议先sudo npm uninstall -g 包名卸掉再用用户级前缀重装避免新旧路径混用导致命令找不到。3.4 验证安装是否真的成功装完之后别急着往下走先做三项验证node -v # 应输出 v20.x.x 或 v22.x.x npm -v # 应输出对应 npm 版本 which node # 应指向版本管理器的路径而非 /usr/bin/nodewhich node这一项最容易被忽略。如果它指向/usr/bin/node说明系统里还有一个 apt 装的旧版本在抢路径后面会出现命令行里 node 是新版但脚本里跑的是旧版这种诡异问题。解决办法是在 shell 配置里确保版本管理器的初始化脚本在 PATH 设置之前执行。4. tmux 配置让 AI 会话真正稳定下来4.1 基础安装与最小可用配置tmux 的安装本身没难度Ubuntu 下sudo apt install tmux即可。难的是配置——默认配置下 tmux 的滚动缓冲只有 2000 行AI 会话跑一会儿就把历史刷没了默认前缀键是Ctrlb和很多终端快捷键冲突鼠标滚动默认不开启翻历史得用键盘。我的最小可用配置放在~/.tmux.conf# 增大滚动缓冲AI 会话输出多2000 行不够用 set-option -g history-limit 50000 # 开启鼠标支持方便滚动和选择 pane set-option -g mouse on # 把前缀键改成 Ctrla减少和终端快捷键冲突 set-option -g prefix C-a unbind C-b bind C-a send-prefix # 窗口和 pane 编号从 1 开始符合直觉 set-option -g base-index 1 set-option -g pane-base-index 1history-limit这一项我要特别强调。Claude Code 在执行终端命令时输出可能非常长比如跑一次测试套件、拉一次依赖日志。默认 2000 行缓冲几轮对话就满了你想往上翻看 AI 之前执行了什么命令发现已经被截断。调到 50000 行基本能覆盖一整天的会话历史。代价是内存占用略增但现代机器完全无感。4.2 为 AI 会话设计专门的窗口布局tmux 的窗口window和窗格pane机制天然适合 AI 编码场景。我习惯给每个项目开一个 tmux 会话会话里分三个窗口窗口 1Claude Code 或 Codex 主会话占满整个窗口窗口 2代码编辑区跑 vim 或 nvim窗口 3终端命令区跑测试、构建、git 操作这样 AI 在窗口 1 里执行命令时我可以切到窗口 3 手动验证同样的命令两边互不干扰。切换用Ctrla加数字键比在多个终端标签页之间跳转快得多。创建这套布局可以用脚本固化下来#!/bin/bash # 创建名为 dev 的会话第一个窗口跑 AI 工具 tmux new-session -d -s dev -n ai # 第二个窗口跑编辑器 tmux new-window -t dev -n edit # 第三个窗口跑命令 tmux new-window -t dev -n shell # 默认选中第一个窗口 tmux select-window -t dev:1 tmux attach -t dev把这段存成~/bin/dev-session.sh并加执行权限以后一条命令就能拉起整套工作台。4.3 tmux 里 TUI 渲染错乱的三个常见原因热搜词里虽然没直接提 tmux 渲染问题但claude code windows、claude code for vs code这些词说明很多人在非标准终端环境里跑 Claude Code。tmux 里的 TUI 错乱我总结下来有三个原因第一是终端类型声明不对。tmux 默认会把TERM设成screen或tmux-256color如果这个 terminfo 条目在你系统里缺失TUI 库就不知道该怎么画界面。解决办法是在~/.tmux.conf里加set -g default-terminal tmux-256color并确保系统装了ncurses-term包。第二是窗口大小变化时没触发重绘。tmux 在窗口 resize 时会给 pane 里的进程发 SIGWINCH 信号但有些 TUI 库处理不及时界面就花了。这时候按Ctrla然后:resize-window -A强制重算或者直接 detach 再 attach通常能恢复。第三是颜色支持不足。默认 tmux 可能只开 8 色或 256 色而现代 TUI 用真彩色。在配置里加set -g default-terminal tmux-256color和set -ga terminal-overrides ,*256col*:Tc开启真彩色支持界面颜色就正常了。5. Claude Code 与 Codex 的安装与端点配置5.1 两个工具的安装路径与验证方式Node.js 和 tmux 就绪后装这两个 CLI 工具就是常规操作# 安装 Claude Code npm install -g anthropic-ai/claude-code # 安装 Codex CLI npm install -g openai/codex # 验证 claude --version codex --version装完之后第一次运行两个工具都会引导你登录或配置 API 密钥。这里有个分叉点如果你用的是官方服务跟着引导走 OAuth 登录即可如果你要接第三方端点或本地模型就得跳过登录直接改配置文件。热搜词里codex登录不上、your organization has disabled claude subscription access这类问题多半是账号权限或网络环境导致的和工具本身无关。5.2 配置文件的位置与结构这两个工具的配置都放在用户目录下的隐藏文件夹里Claude Code~/.claude/目录主配置可能是settings.json或环境变量Codex CLI~/.codex/目录主配置是config.toml或config.jsonCodex 的配置是 TOML 格式结构大致是这样# ~/.codex/config.toml model gpt-5.6-sol model_provider custom [model_providers.custom] name Custom Provider base_url http://localhost:1234/v1 env_key CUSTOM_API_KEY热搜词里那条{detail:the gpt-5.6-sol model is not supported when using codex with a...}就是模型名和端点不匹配导致的。Codex 会把你配置的模型名原样发给端点如果端点不认识这个名字就返回这个错误。解决办法是确认你的端点实际支持的模型名别照抄教程里的示例名。5.3 端点转发的核心逻辑为什么需要中间层这是整个 openrig 装配里最容易翻车的一环。Claude Code 和 Codex 各自有默认的 API 端点你想让它们走本地模型或第三方服务中间就得加一层转发。这层转发要干三件事第一是协议适配。Claude Code 用的是 Anthropic 的消息格式Codex 用的是 OpenAI 的格式两者在请求体结构、字段命名、流式响应格式上都有差异。转发层要把进来的请求翻译成目标端点能懂的格式再把响应翻译回去。第二是路径映射。热搜词里那个cc switch local proxy failed while handling codex endpoint /responses就是路径没映射对。Codex 新版用的是/responses端点而很多本地模型服务比如 LM Studio、Ollama只提供/v1/chat/completions。转发层如果直接把/responses透传过去目标端点当然 404。正确做法是在转发层里把/responses重写成/v1/chat/completions同时把请求体从 Responses API 格式转成 Chat Completions 格式。第三是认证头处理。不同端点的认证方式不同有的是Authorization: Bearer xxx有的是x-api-key: xxx。转发层要统一处理避免把错误的认证头透传过去。一个最小可用的转发配置以 Node.js 写的中间层为例大致是这样// proxy.js - 极简转发示例 import express from express; import fetch from node-fetch; const app express(); app.use(express.json()); app.post(/v1/responses, async (req, res) { // 把 Responses API 格式转成 Chat Completions 格式 const chatBody { model: req.body.model, messages: req.body.input.map(item ({ role: item.role, content: item.content })), stream: req.body.stream || false }; const upstream await fetch(http://localhost:1234/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${process.env.LOCAL_API_KEY || local} }, body: JSON.stringify(chatBody) }); // 把响应转回 Responses API 格式 const data await upstream.json(); res.json({ id: data.id, object: response, output: [{ type: message, role: assistant, content: [{ type: text, text: data.choices[0].message.content }] }] }); }); app.listen(8080, () console.log(Proxy running on :8080));这段代码只是演示转换逻辑实际生产用的话要处理流式响应、错误码映射、超时重试等。但核心思路就是这样进来什么格式出去什么格式中间做翻译。5.4 本地模型接入的实测经验热搜词里claude code 调用lmstudio的本地模型是个高频需求。LM Studio 默认在http://localhost:1234/v1提供 OpenAI 兼容端点。要让 Claude Code 走这个端点你需要设置环境变量export ANTHROPIC_BASE_URLhttp://localhost:8080 export ANTHROPIC_API_KEYlocal-key这里的8080就是你上面那个转发层的地址。Claude Code 会把请求发给转发层转发层再转给 LM Studio。为什么不直接把ANTHROPIC_BASE_URL指向 LM Studio 的 1234 端口因为协议不兼容——Claude Code 发的是 Anthropic 格式LM Studio 只认 OpenAI 格式中间必须有翻译层。我实测下来本地模型跑 Claude Code 的体验和官方模型差距主要在两点一是工具调用tool use能力本地小模型经常调不对格式二是长上下文处理本地模型上下文窗口小几轮对话就爆了。所以本地模型适合做轻量任务比如代码解释、简单重构复杂的多文件编辑还是得用官方模型。6. 排错实战从报错信息反推问题根源6.1 代理转发失败的完整排查链路遇到cc switch local proxy failed while handling codex endpoint /responses这类报错别急着改配置按下面的链路一步步查第一步确认转发层是否在跑。curl http://localhost:8080/health或者直接curl http://localhost:8080/v1/responses看有没有响应。如果连接被拒说明转发层没启动或端口不对。第二步确认目标端点是否可达。curl http://localhost:1234/v1/models看 LM Studio 是否正常返回模型列表。如果这一步失败问题在本地模型服务不在转发层。第三步抓转发层的日志。在转发代码里加请求日志打印出收到的路径、请求体、转发出去的 URL 和响应状态码。这一步能直接定位是路径映射错了还是请求体格式不对。第四步手动模拟请求。用 curl 直接向转发层发一个最小请求看返回什么curl -X POST http://localhost:8080/v1/responses \ -H Content-Type: application/json \ -d {model:local-model,input:[{role:user,content:hi}]}如果这个请求成功说明转发层没问题问题在 Codex 的配置如果失败看报错信息定位转发层内部逻辑。6.2 配置项被忽略的警告怎么处理codex is ignoring 1 unrecognized configuration setting. check for typos or d...这个警告的意思是配置文件里有个字段 Codex 不认识。常见原因是版本升级后配置格式变了或者你抄的教程对应的是旧版本。处理办法是打开 Codex 的官方文档对照当前版本的配置字段列表逐个核对。我一般会把配置文件里所有字段列出来和文档比对把不认识的删掉或改名。这个警告本身不影响运行但被忽略的配置可能正是你需要的功能所以不能放着不管。6.3 组织权限类错误的本质your organization has disabled claude subscription access for claude code这类错误本质是账号层面的权限控制和本地环境无关。如果你用的是公司账号管理员可能禁用了 CLI 访问如果是个人账号可能是订阅类型不支持。这种问题本地怎么折腾都没用只能走账号侧解决或者改用 API 密钥方式认证。6.4 一张表看清常见报错与对应动作报错关键词根本原因处理动作node.js v24.21.0 is not yet released指定了不存在的版本号改用 LTS 大版本号如 20cc switch local proxy failed转发层路径或格式不匹配检查/responses到/v1/chat/completions的映射model is not supported模型名与端点不匹配核对端点实际支持的模型名unrecognized configuration setting配置字段拼写错误或版本不符对照官方文档核对字段organization has disabled账号权限限制走账号侧解决或改用 API 密钥EACCES权限错误npm 全局目录属主问题改 npm prefix 到用户目录7. 把 openrig 固化成可复现的装配流程7.1 一份可执行的初始化脚本把前面所有步骤串起来我写了一份初始化脚本新机器上跑一遍就能把 openrig 的基础环境搭好#!/bin/bash set -e echo 1. 安装 fnm 和 Node.js 20 LTS curl -fsSL https://fnm.vercel.app/install | bash export PATH$HOME/.fnm:$PATH eval $(fnm env) fnm install 20 fnm use 20 fnm default 20 echo 2. 配置 npm 用户级全局目录 mkdir -p ~/.npm-global npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH echo 3. 安装 tmux 并写入基础配置 sudo apt install -y tmux cat ~/.tmux.conf EOF set-option -g history-limit 50000 set-option -g mouse on set-option -g prefix C-a unbind C-b bind C-a send-prefix set-option -g base-index 1 set-option -g pane-base-index 1 set -g default-terminal tmux-256color set -ga terminal-overrides ,*256col*:Tc EOF echo 4. 安装 Claude Code 和 Codex CLI npm install -g anthropic-ai/claude-code npm install -g openai/codex echo 5. 验证 node -v npm -v tmux -V claude --version codex --version echo 完成记得 source ~/.bashrc 让 PATH 生效 这份脚本我建议按需修改尤其是 Node.js 版本和工具包名要跟着官方最新要求走。7.2 配置文件的版本管理~/.claude/和~/.codex/里的配置文件我建议纳入 dotfiles 仓库管理。这样换机器时直接 clone 下来配置就恢复了。但要注意不要把 API 密钥提交到仓库用环境变量或者单独的 secrets 文件并在.gitignore里排除。我的做法是配置文件里只放非敏感的结构性配置端点地址、模型名、超时时间密钥通过环境变量注入。这样配置文件可以放心提交密钥也不会泄露。7.3 团队标准化的几个注意点如果你要把这套流程推广到团队有几个点要提前定好统一 Node.js 版本。在项目根目录放一个.nvmrc或.node-version文件写明20团队成员用版本管理器时自动对齐。版本不一致是团队环境问题的主要来源。统一转发层实现。别让每个人自己写转发脚本而是提供一个团队维护的转发服务大家配置里都指向它。这样端点变更、协议升级只需要改一处。统一 tmux 配置。把~/.tmux.conf作为团队标准配置分发减少在我机器上好好的这类问题。文档化排错流程。把第 6 节那张报错对照表放进团队 wiki新人遇到问题先查表能自己解决大部分常见问题。7.4 我踩过的几个坑供你参考第一个坑是在 tmux 里跑 npm install -g 导致 PATH 不更新。tmux 会话启动时继承的是启动那一刻的环境变量如果你在 tmux 外面改了 PATHtmux 里面的会话不会自动更新。解决办法是改完 PATH 后tmux kill-server重启整个 tmux 服务或者在新会话里手动 source 配置。第二个坑是转发层用了流式响应但没处理 chunk 边界。AI 工具的响应大多是流式的转发层如果简单地把上游的 chunk 直接透传遇到多字节字符被切分在 chunk 边界时会出现乱码。正确做法是用TextDecoder的stream: true模式处理或者用成熟的流处理库。第三个坑是本地模型服务的端口和转发层端口冲突。LM Studio 默认 1234转发层如果也配 1234 就撞了。我习惯把转发层放在 8080本地模型服务保持默认两边错开。第四个坑是Codex 的配置缓存。改了config.toml之后Codex 有时不会立即生效需要删掉~/.codex/下的缓存文件或者重启终端。这个在官方文档里没明说是我反复试出来的。这套 openrig 装配流程我从第一次踩坑到跑通大概花了两天后来整理成脚本和文档新机器上半小时就能搭好。核心体会是CLI AI 工具的难点从来不在 AI 本身而在环境装配的每一个细节。Node.js 版本、npm 权限、tmux 缓冲、端点映射、配置字段任何一环出问题都会让整个链路卡住。把每个环节的原理搞清楚遇到报错能反推根源比死记配置命令有用得多。