1. 从 openrig 这个标题说起它到底想解决什么问题第一次看到openrig这个词我下意识把它拆成了两半open和rig。rig在工程语境里通常指“装配好的成套设备”或者“一套搭好的工作台”比如矿机叫 mining rig测试台叫 test rig。所以openrig给我的第一直觉是一套开放的、可自由拼装的工作台方案。结合热搜词里密集出现的 Claude Code、Codex、YAML、npm 这些关键词我基本可以判断这个标题背后指向的是一个围绕 AI 编程助手Claude Code、Codex CLI 这类工具搭建本地开发环境、统一配置、打通工作流的开源脚手架或配置集合。为什么我敢这么判断因为热搜词里几乎全是“安装、配置、报错、镜像源、代理失败”这类词。claude code安装、codex安装教程、npm 国内源、npm : 无法加载文件 npm.ps1、cc switch local proxy failed while handling codex endpoint /responses——这些词拼在一起就是一幅非常典型的画面一个开发者想在本机同时用上 Claude Code 和 Codex结果被 npm 环境、PowerShell 执行策略、YAML 配置、本地代理转发这一连串问题卡住了。openrig要做的就是把这些零散的坑一次性填平给出一套开箱即用的装配方案。这篇文章适合谁看如果你正在 Windows 或 Ubuntu 上折腾 Claude Code、Codex CLI被 npm 全局安装、镜像源、YAML 配置文件、本地模型接入这些问题反复折磨那这篇就是写给你的。如果你只是想了解这类 AI 编程工具的工作台该怎么搭也能从里面拿到一套可复制的思路。我会把openrig当作一个“开放装配台”来拆解讲清楚它背后的核心领域、潜在需求、关键技术点和实际落地场景所有步骤都按我实际踩坑的经验来写能直接抄作业。2. openrig 的核心领域与需求拆解2.1 它属于哪个技术领域openrig落在“AI 编程助手本地工作流编排”这个领域里。这个领域最近一年变化极快核心玩家就是 Claude Code、Codex CLI 这类命令行 AI 编程工具。它们的能力不是孤立的而是依赖一整套周边设施Node.js 运行时、npm 包管理、YAML 配置文件、本地模型服务比如 LM Studio、代理转发层、编辑器插件VS Code。openrig的价值就在于把这些设施按一套标准装配起来让用户不用每次从零开始。我把它类比成装机。你买散件自己装CPU、主板、电源、机箱各买各的装完还得调 BIOS、装驱动、跑压力测试。openrig相当于一份“配置单 装机教程 常见故障手册”告诉你哪个件配哪个件、线怎么插、点不亮先查哪里。它不生产零件它负责让零件协同工作。2.2 潜在需求到底有哪些从热搜词能反推出四层需求一层比一层深。第一层是安装需求。claude code安装、codex安装教程、codex安装包、codex官网下载、npm安装这些词说明大量用户卡在“怎么把它装到机器上”这一步。npm 全局安装是最常见的方式但 Windows 上 PowerShell 执行策略一拦npm.ps1直接报“禁止运行脚本”新手当场懵掉。第二层是配置需求。yaml文件、yolov10 yaml文件怎么创建、rstudio的yaml在哪里、vscode配置claude code、ubuntu配置claude code这些词说明用户装完之后不知道怎么配。YAML 是这类工具的核心配置格式模型参数、代理地址、端点路径都写在里面。配错一个缩进整个服务起不来。第三层是网络与镜像需求。npm 国内源、npm镜像源地址、npm 淘宝源、npm环境变量path配置这些词说明国内用户在拉包时遇到速度慢、超时、证书错误。换镜像源是标准解法但换完之后 PATH 没配好又会出现新的报错。第四层是集成与排障需求。claude code 调用lmstudio的本地模型、codex接入deepseek、cc switch local proxy failed while handling codex endpoint /responses、codex无法加载组织设置这些词说明进阶用户想把本地模型或第三方模型接进来结果在代理转发和端点匹配上翻车。/responses这个端点报错本质是代理层没把 Codex 的请求正确转发到目标服务。2.3 为什么需要一个 openrig 式的统一方案零散地搜教程有个致命问题每篇教程的环境假设不一样。A 教程假设你用的是 macOSB 教程假设你 Node 版本是 18C 教程假设你没装过任何全局包。你照着拼拼出来的是一台“四不像”报错信息互相矛盾。openrig式方案的核心思路是先统一环境基线再分层配置。基线包括 Node 版本、npm 镜像源、PowerShell 执行策略、PATH 变量分层包括工具安装层、YAML 配置层、模型接入层、代理转发层。每一层单独验证通过了再进下一层。这样出问题时能快速定位是哪一层挂了而不是面对一锅粥。3. 核心技术点深度解析3.1 npm 安装与 Windows 执行策略的正面冲突npm : 无法加载文件 d:\program files\nodejs\npm.ps1因为在此系统上禁止运行脚本——这个报错我见过太多次了。根因是 Windows PowerShell 默认的执行策略是Restricted不允许运行任何.ps1脚本而 npm 在 Windows 上正是通过npm.ps1这个包装脚本来调用的。Node.js 安装包把 npm 装好了但 PowerShell 不认。解法有两个方向。一是改执行策略用管理员身份打开 PowerShell执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned。RemoteSigned的意思是本地脚本可以跑从网上下载的脚本需要签名。这个设置对个人开发机是安全的比Unrestricted稳妥。二是绕开.ps1直接用npm.cmd或者在 Git Bash、WSL 里操作。我个人的习惯是改执行策略因为改一次一劳永逸后面所有 npm 命令都正常。注意改执行策略时-Scope CurrentUser很关键它只影响当前用户不需要动系统级设置风险最小。改完用Get-ExecutionPolicy -List确认一下各作用域的值。3.2 npm 镜像源与 PATH 环境变量的配合国内拉 npm 包慢换淘宝源现在叫 npmmirror是标准操作npm config set registry https://registry.npmmirror.com。但很多人换完源还是报错问题往往出在 PATH。npm环境变量path配置这个热搜词说明用户装完 Node 后npm命令在某个终端里能用换个终端就找不到。这是因为 Node 的安装路径没进系统 PATH或者进了但顺序不对。正确的做法是确认 Node 安装目录比如C:\Program Files\nodejs\在系统 PATH 里并且排在前面。改完 PATH 必须重开终端才生效很多人改完在当前窗口试发现没用就以为改错了。另外如果你用 nvm 管理 Node 版本PATH 里应该是 nvm 的符号链接目录而不是某个具体版本目录否则切换版本后 PATH 会指向失效路径。3.3 YAML 配置文件的结构与常见坑YAML 是 Claude Code、Codex 这类工具的配置载体。它的语法看着简单实则对缩进极其敏感。yolov10 yaml文件怎么创建和rstudio的yaml在哪里这两个热搜词虽然领域不同但反映的是同一个痛点用户不知道 YAML 文件该放哪、该写什么、缩进用几个空格。YAML 的核心规则就几条用空格缩进绝对不能用 Tab同级键左对齐冒号后面要跟一个空格字符串一般不用引号但含特殊字符时要加。一个典型的模型接入配置大概长这样model: provider: local endpoint: http://127.0.0.1:1234/v1 name: qwen2.5-coder api_key: not-needed proxy: enabled: true target: http://127.0.0.1:8080 timeout: 30这里model和proxy是同级各自下面的键再缩进两个空格。endpoint指向本地模型服务的地址proxy.target是代理转发目标。缩进错一格解析器就报mapping values are not allowed here之类的错。我的经验是写完 YAML 先用在线校验器过一遍或者用python -c import yaml; yaml.safe_load(open(config.yaml))验证别等到工具启动时才排查。3.4 本地代理转发与 /responses 端点报错cc switch local proxy failed while handling codex endpoint /responses这个报错是进阶用户的高频痛点。它的意思是本地代理在处理 Codex 发往/responses端点的请求时失败了。Codex CLI 默认会向某个端点发请求如果你在中间加了一层本地代理比如为了把请求转给 LM Studio 或 DeepSeek代理层必须正确识别并转发这个路径。失败原因通常有三类。一是代理配置里的目标地址写错比如把/v1/responses写成了/responses路径不匹配。二是目标服务不支持这个端点比如某些本地模型服务只实现了/v1/chat/completions没有/v1/responses请求过去直接 404。三是代理层没做路径重写Codex 发的是/responses但目标服务要的是/v1/chat/completions中间需要一层映射。排查顺序我建议这样先用curl直接打目标服务的端点确认它活着且支持你要的路径再检查代理配置的路径重写规则最后看代理日志确认请求到底发到了哪里。codex接入deepseek这类场景DeepSeek 的 API 路径和 Codex 默认路径不一致必须做重写。3.5 Claude Code 与 Codex 的共存配置claude code和codex同时装在一台机器上是很多人的真实需求。两者都依赖 Node 和 npm但配置文件和默认端口可能冲突。openrig式方案的做法是给两者分配独立的配置目录和端口。Claude Code 的配置放~/.claude/Codex 的放~/.codex/代理层用不同端口监听比如 Claude Code 走 8080Codex 走 8081。这样互不干扰出问题也好隔离。vscode配置claude code和claude code for vs code这两个词说明编辑器集成也是刚需。VS Code 里装对应插件后插件会读取配置文件里的端点地址。如果插件连不上先确认配置文件路径对不对再确认端点服务是否在跑。我遇到过插件读的是全局配置但我改的是项目级配置两边不一致导致连不上。统一配置来源能省很多事。4. 实操过程从零搭一套 openrig 工作台4.1 环境基线准备第一步装 Node.js。建议用 LTS 版本比如 20.x。Windows 用户去官网下.msi安装包安装时勾选“Add to PATH”。装完重开终端跑node -v和npm -v确认版本。如果npm -v报npm.ps1无法加载按 3.1 节的方法改执行策略。第二步配 npm 镜像源。执行npm config set registry https://registry.npmmirror.com然后npm config get registry确认生效。如果公司网络有特殊要求可能还需要配npm config set proxy和npm config set https-proxy但这两个参数填错会导致所有请求走错路不确定就别配。第三步确认 PATH。where npmWindows或which npmLinux/macOS应该输出 npm 的完整路径。如果输出多个路径说明有多个 Node 版本需要清理。PATH 里 Node 目录应该只有一处。4.2 安装 Claude Code 与 CodexClaude Code 的安装官方推荐方式是 npm 全局安装npm install -g anthropic-ai/claude-code。装完跑claude --version验证。如果提示命令找不到说明全局 bin 目录没进 PATH。npm 的全局 bin 目录可以用npm config get prefix查到把这个目录加到 PATH 里。Codex 的安装类似具体包名以官方为准装完跑codex --version验证。codex安装 csdn这类搜索词说明很多人找的是第三方教程但第三方教程的包名和版本可能过时建议以官方文档为准。装的时候注意看 npm 的 warningnpm warn eresolve overriding peer dependency这类警告通常是依赖版本冲突多数情况不影响使用但如果工具跑不起来就要回头处理。提示全局安装的包多了之后npm ls -g --depth0能列出所有全局包方便排查冲突。卸载用npm uninstall -g 包名别手动删目录容易留残留。4.3 编写 YAML 配置文件在用户目录下建配置目录比如~/.openrig/里面放config.yaml。配置内容按 3.3 节的结构来把模型端点、代理设置、超时时间都写清楚。写完用 Python 或在线工具校验语法。配置里的端点地址要和你实际跑的服务对上。如果你用 LM Studio默认端口是 1234端点通常是http://127.0.0.1:1234/v1。如果你用 DeepSeek 的云端 API端点就是官方给的地址api_key 填你自己的。claude code 调用lmstudio的本地模型这个场景关键就是把 endpoint 指向 LM Studio并且确认 LM Studio 里已经加载了模型、开启了服务。4.4 启动本地代理并验证转发代理层可以用现成的转发工具也可以用几十行 Node 脚本自己写。核心逻辑是监听一个本地端口收到请求后按规则重写路径再转发到目标服务。启动后先用curl打代理端口确认能通。比如curl http://127.0.0.1:8080/v1/models如果返回模型列表说明代理到目标服务的链路是通的。然后启动 Claude Code 或 Codex让它们把请求发到代理端口。观察代理日志确认请求路径、目标地址、响应状态码。如果出现/responses相关报错按 3.4 节的顺序排查。我实测下来大部分转发失败都是路径没重写对加上重写规则后一次就通。4.5 编辑器集成与最终验证VS Code 里装 Claude Code 插件在设置里把端点指向你的代理地址。插件连上后在编辑器里发一条测试指令看是否正常返回。如果插件报“组织已禁用订阅访问”之类的错误那是账号权限问题和本地配置无关需要检查账号状态。最终验证清单node -v正常、npm -v正常、claude --version正常、codex --version正常、YAML 校验通过、代理 curl 通、编辑器插件能返回结果。七项全过这套 openrig 工作台就算搭好了。5. 常见问题与排查技巧实录5.1 安装类问题速查报错关键词根因解法npm.ps1 禁止运行脚本PowerShell 执行策略限制Set-ExecutionPolicy -Scope CurrentUser RemoteSignednpm 命令找不到全局 bin 目录不在 PATH把npm config get prefix的目录加进 PATH拉包超时或证书错误默认源在国外换 npmmirror 源peer dependency 警告依赖版本冲突多数可忽略工具跑不起来再处理5.2 配置类问题速查YAML 报错九成是缩进。我的习惯是统一用两个空格绝不用 Tab。写完先校验。另一个高频问题是配置文件放错位置工具读的是 A 目录你改的是 B 目录。确认工具文档里写的配置路径别想当然。5.3 代理与端点类问题速查/responses报错先 curl 目标服务确认端点存在。再做路径重写把 Codex 的请求路径映射到目标服务支持的路径。代理日志是关键一定要开日志不然就是盲猜。codex无法加载组织设置这类问题通常是账号或网络层和本地代理无关分开排查。5.4 我踩过的几个坑第一个坑改完 PATH 没重开终端以为没生效反复改了好几遍。第二个坑YAML 里用了 Tab肉眼看不出来校验器一跑就现形。第三个坑代理配了但没开日志请求发出去石沉大海最后靠抓包才定位到路径写错。第四个坑同时装 Claude Code 和 Codex端口撞了两个都起不来后来分开端口就好了。这些坑的共同点是先隔离变量再逐个验证。别一次改一堆配置改一处测一处出问题才知道是谁的锅。6. 关于 openrig 后续可以怎么扩展这套工作台搭好之后扩展空间很大。你可以把配置抽成模板用脚本一键部署到新机器可以把代理层做成可插拔的今天接 LM Studio明天接 DeepSeek改配置不改代码可以把 YAML 配置纳入版本管理换机器时直接拉下来用。我个人在实际操作中的体会是这类工具链的稳定性不取决于单个工具多强而取决于层与层之间的接口是否清晰。接口清晰了换任何一个组件都不影响整体。最后分享一个小技巧把常用的排查命令写成 shell 脚本或 PowerShell 函数出问题时一条命令跑完所有检查比手动一个个试快得多。