最近我把用了好几年的开发环境配置翻出来重新整理了一遍顺手给它起了个名字叫openrig。这名字听着挺唬人其实就是一套开放的、可复现的个人工作装备的统称——从终端主题、shell 配置、编辑器插件到常用的命令行工具、AI 辅助工作流全部用声明式配置文件管起来放进 Git 仓库。任何一台新电脑只要 clone 下来跑一个脚本就能复刻出我熟悉到肌肉记忆的整台工作机。说实话最早搞这套东西纯粹是懒。每次换电脑或者重装系统光是装工具、调终端、配环境变量、改编辑器设置就能耗掉大半天而且永远记不住自己当初到底改了哪些配置、装了哪些奇奇怪怪的插件。后来看了不少国外开发者分享的 dotfiles 项目留意到处处流行的dev rig概念才慢慢意识到一件事这些东西完全可以当成一个产品来维护而不只是零散文件的堆积。openrig 这个名字就是那时候定下来的。这篇文章把我总结的思路、模块拆分和实操细节全部摊开来讲包括我踩过的坑和现在每天在用的流程。如果你也是一个对开发环境有要求的人或者正被换电脑 灾难困扰这文章应该能给你一套可以直接抄作业的方案。1. openrig 整体思路为什么把开发环境当成装备来管理1.1 先想清楚 rig 到底在解决什么问题rig这个词在技术圈子里其实出现过很多次。3D 动画那边叫骨骼绑定音频圈叫设备链路到了开发者这里它通常指一套组装好的工具系统。就像摄影师不会每次拍照都重新买相机程序员也没道理每次换机器都把环境重搭一遍。openrig 的核心思路就是把环境配置从一次性手工活变成可版本化的资产。我见过太多人的电脑是黑箱能跑但谁也说不清里面装了什么。某天项目突然挂了排查半天发现是全局装了一个错误版本的依赖把环境配置发给同事对方跑起来又是另一套东西。这种环境漂移问题本质上是没有把环境当作代码去管理。把配置版本化之后每一次改动都有记录每一次部署都是可重复的环境从薛定谔的状态变成了确定的产物。1.2 三条设计原则声明式、幂等、模块化openrig 的整个设计围绕三个原则展开缺一个后期都会很难受。第一声明式优于命令式。我不用一长串执行这个安装命令、再执行那个配置命令来描述环境而是用我要装这些包、我要这些配置文件存在来描述。比如 Homebrew 的Brewfile写好依赖清单机器上缺什么就装什么而不是从头到尾重新执行一遍安装指令。声明式的最大好处是天然幂等重复执行同一套配置结果是一样的不会因为重复运行而出错。第二幂等是底线。安装脚本跑三次和跑一次结果必须一致。这要求所有操作都写成检测 — 判断 — 动作的模式检测目标文件是否已存在判断是否跳过或覆盖再决定是否执行改动。没有幂等性的脚本本质上是赌运气。第三模块化分层。我不会把所有配置塞进一个巨大的install.sh而是按 shell、编辑器、Git、包管理、AI 工具链五个模块分开。这样某个模块出问题只需要修那一个模块也不会影响其他部分。模块之间通过统一的目录结构和入口脚本串联起来既保持独立又能整体调用。1.3 方案选型dotfiles bootstrap 脚本而不是容器或镜像做可复现环境其实有四条路线纯 dotfiles 脚本、DevContainer、虚拟机镜像、容器化开发环境。我最后选了 dotfiles bootstrap 脚本的轻量方案。原因很简单我的使用场景横跨个人电脑、远程服务器和临时环境需要一套轻量、快速、不挑系统的配置而容器和虚拟机在个人日常操作里太重了。DevContainer 很适合团队协作的规范化开发但前提是项目本身已经容器化不是每个人都会把日常工作流完全搬进容器虚拟机镜像适合做完全隔离的环境但日常使用成本太高没法作为默认方案。dotfiles 方案最大的优势是低侵入它不改变你用什么系统不强制你用容器只是把你常用的工具和配置统一管理起来在任何机器上都能快速部署。另外我也给它留了扩展位配置本身是文本文件将来如果某个项目确实需要 DevContainer可以直接在 openrig 生成的脚手架里初始化一份.devcontainer配置两者不冲突。2. 核心模块拆分openrig 的都包含哪些关键组件2.1 目录结构设计一眼能看懂的配置仓库一个成功的配置仓库首先要做到一眼能看懂。我的 openrig 目录结构长这样openrig/ ├── install.sh # 一键安装入口 ├── bootstrap/ │ ├── macos.sh # macOS 环境初始化 │ └── linux.sh # Linux/Debian 系环境初始化 ├── dotfiles/ │ ├── shell/ │ │ ├── .zshrc │ │ ├── .bashrc │ │ └── .aliases │ ├── editor/ │ │ ├── .vimrc │ │ └── init.lua # Neovim 配置入口 │ ├── git/ │ │ └── .gitconfig │ └── ai/ │ ├── rules.md # AI 工作规则 │ └── prompts.md # 模板化提示词 ├── apps/ │ ├── Brewfile # macOS 包清单 │ └── packages.txt # Linux 包清单 └── scripts/ ├── link.sh # 软链接管理 └── backup.sh # 备份与恢复看到这个目录任何人都能快速定位shell 相关的配置在dotfiles/shell包清单在apps装环境跑install.sh。不要把配置文件散落在各个角落这是 openrig 提升可维护性的第一步。2.2 shell 配置zsh 还是 bash其实不必纠结我在dotfiles/shell里同时放了.zshrc和.bashrc因为两台主力机器一个用 zsh 一个用 bash实际使用中发现关键不是选哪个 shell而是把公共配置抽出来。所有 shell 通用的 aliases、环境变量和函数写进.aliases再由.zshrc和.bashrc分别 source 这个公共文件。这样只维护一份逻辑两个 shell 都能用。比如我常用的几个 aliases# 通用 aliases alias gsgit status alias glgit log --oneline --graph --decorate alias gdgit diff alias pypython3 alias cclear alias ..cd .. alias ...cd ../..配置里还有一个非常容易忽略的点启动提示符不要太依赖特定插件。曾经我在 zsh 里用了某个提示符主题插件换到 Linux 服务器上没有那个插件结果每次打开终端都报错。现在提示符只依赖 shell 内置功能保证任何机器上都能跑这才是真正开放的 rig。2.3 包管理清单一份可重复执行的依赖声明包管理模块是整个 openrig 里最爽的部分。macOS 上用 Homebrew 的BrewfileLinux 上用一份纯文本包清单各自描述我需要哪些工具。Homebrew 的brew bundle dump可以直接导出当前装的所有包但那个清单很杂乱不适合直接作为 openrig 的依赖声明。我更推荐手写一份精简的Brewfile只包含真正高频使用的工具并注释每个工具的用途# Brewfile —— macOS 包清单 brew git # 版本控制 brew zsh # shell brew tmux # 终端复用 brew fzf # 模糊查找 brew ripgrep # 快速搜索 brew jq # JSON 处理 brew tree # 目录树 brew ollama # 本地 AI 模型运行 brew imagemagick # 图片处理 cask raycast # 效率工具 cask iterm2 # 终端模拟器 cask visual-studio-code # 编辑器Linux 那边同理写一份packages.txt每行一个包名脚本负责读取并批量安装。这里有一个关键细节不要直接把brew bundle dump的结果提交进仓库那个文件包含大量一次性依赖装起来又慢又没有意义。手写清单虽然费点时间但换来的是一份干净、简洁、可控的依赖声明。2.4 AI 工作流配置给 AI 助手建立统一规则这是 openrig 里比较新也很有意思的模块。AI 辅助编程已经是我日常开发的一部分但如果没有统一规则每个项目用 AI 的方式都不同上下文一换效果就飘忽不定。我在dotfiles/ai里维护了两份文件一份是rules.md规定 AI 助手在处理代码时应该遵循的基本规范一份是prompts.md沉淀各种常用的提示词模板。rules.md的内容类似# AI 协作规范 - shell 脚本必须包含 set -euo pipefail禁止静默失败 - 提交信息遵循 Conventional Commits 规范 - 涉及密钥或敏感信息的操作一律通过环境变量注入不得硬编码 - 需要修改配置类文件时先说明影响范围再动手prompts.md则积累了代码评审、写单元测试、重构函数、排查报错等场景的提示词模板。这样做的好处是AI 的行为模式不再依赖每次对话时手打一大段背景说明而是有一套可版本化的操作手册。整个 AI 工作流也就变成了环境的一部分而不是孤立地散落在浏览器的对话记录里。3. openrig 实操全流程从空仓库到一台新电脑完成部署3.1 初始化仓库给配置一个家搭建 openrig 的第一步是把配置仓库建立在代码托管平台上。仓库名就叫openrig权限设为私有——虽然叫open但个人配置里难免有些私人信息私有仓库在安全上稳妥得多。如果你想让别人也能参考可以额外维护一个脱敏后的公开版但别拿自己日常用的一版直接公开。初始化后先建立目录骨架、生成.gitignore把常见敏感文件排除掉#!/usr/bin/env bash mkdir -p bootstrap dotfiles/shell dotfiles/editor dotfiles/git dotfiles/ai apps scripts touch install.sh bootstrap/macos.sh bootstrap/linux.sh scripts/link.sh.gitignore里至少要包含这些# 敏感信息 .env *.pem *.key secrets/ # 系统自动生成 .DS_Store *.log这一步看似简单但目录分类直接决定后续使用体验。我的建议是宁可多花十分钟想清楚模块边界也不要等文件多了再重构。3.2 软链接管理脚本配置文件的挂载点配置文件和真实生效位置之间我选择用软链接关联而不是直接复制。因为软链接能保证仓库里的文件始终是最新版本改一处所有机器同步更新。核心脚本link.sh长这样#!/usr/bin/env bash # 将 dotfiles 下的配置文件链接到 home 目录 set -euo pipefail DOTFILES_DIR$(cd $(dirname ${BASH_SOURCE[0]})/.. pwd) link_file() { local src$1 local target$2 if [ -h $target ]; then echo 已存在软链接: $target rm -f $target ln -s $src $target elif [ -e $target ]; then echo 目标已被占用跳过: $target else ln -s $src $target echo 已链接: $target - $src fi } link_file $DOTFILES_DIR/dotfiles/shell/.aliases $HOME/.aliases link_file $DOTFILES_DIR/dotfiles/shell/.zshrc $HOME/.zshrc link_file $DOTFILES_DIR/dotfiles/shell/.bashrc $HOME/.bashrc link_file $DOTFILES_DIR/dotfiles/git/.gitconfig $HOME/.gitconfig link_file $DOTFILES_DIR/dotfiles/editor/.vimrc $HOME/.vimrc这段脚本特意做了三层判断已占用则跳过避免覆盖电脑上已有的重要配置已存在软链接则重建确保指向新仓库位置不存在则直接创建。这个安全和更新兼顾的策略避免了很多意外覆盖问题。执行完link.sh后配置就装好了换台机器也一样只要仓库 clone 下来就能立刻关联。3.3 一键安装脚本全流程的总控台install.sh是整个 openrig 的入口新机器上的安装顺序是这样设计的#!/usr/bin/env bash set -euo pipefail echo 1/4 初始化系统环境 BIN_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) case $(uname -s) in Darwin) bash $BIN_DIR/bootstrap/macos.sh ;; Linux) bash $BIN_DIR/bootstrap/linux.sh ;; *) echo 暂不支持的系统: $(uname -s) exit 1 ;; esac echo 2/4 安装常用工具 # macOS 使用 brew bundle 安装 if [ $(uname -s) Darwin ]; then brew bundle --file$BIN_DIR/apps/Brewfile else xargs -a $BIN_DIR/apps/packages.txt sudo apt-get install -y fi echo 3/4 关联配置文件 bash $BIN_DIR/scripts/link.sh echo 4/4 检查 AI 工作流规则是否已生效 if [ -f $HOME/.openrig/ai/rules.md ]; then echo openrig: AI 规则已就绪 else echo openrig: 需要手动将 dotfiles/ai 接入 AI 工具 fi echo openrig 部署完成顺序上有个很关键的设计先装系统工具再关联配置。如果先关联配置再装工具配置引用了尚不存在的命令某些 shell 初始化逻辑可能会报错。包安装部分macOS 用brew bundle直接读 BrewfileLinux 用xargs逐行读取包清单两套代码虽逻辑不同但都保持声明式 可重复执行的特点。3.4 密钥与隐私管理绝不把秘密提交进仓库openrig 里最容易踩雷的就是敏感信息。Git 配置里可能含有邮箱、用户名甚至某些 CI 的 tokenAI 规则文件里也可能写入内部服务的地址。我在整个方案里只用两招就避免了绝大部分风险。第一招是外部引用。凡涉及密钥的地方一律不写真实值而是写从环境变量读取或从指定路径引入。比如.zshrc里会有这样一段# 加载本地密钥不提交仓库 if [ -f $HOME/.openrig_secrets ]; then source $HOME/.openrig_secrets fi这样仓库里只有一份模板真实密钥留在各台机器的独立文件里永远不进 Git。第二招是模板占位。dotfiles里放的是.env.example、config.example.yaml这样的模板新机器部署后复制成正式文件再填入真实值。这套做法既保证了配置的可复现性又保证了安全边界足够清晰。3.5 新机器部署实测从裸机到完整环境这套 openrig 的实际部署过程我最近在一台刚装好系统的 Linux 机器上完整跑了一遍。实测流程如下安装好基础系统后先装 Git 用来 clone 仓库sudo apt-get update sudo apt-get install -y git git clone https://my.git.host/openrig.git ~/openrig接着执行cd ~/openrig bash install.sh整个安装过程耗时约 18 分钟取决于网速和需要下载的包数量结束后重新打开终端熟悉的提示符、aliases、编辑器配置全部就位。再手动配置一下密钥文件一台全新的工作机就恢复到和旧电脑一致的体验。对于曾经需要一整天才能完成的环境搭建这个效率提升是非常直观的。部署完成后我还会跑一遍自检which git、which fzf、echo $SHELL确认安装到位ls ~/.zshrc确认软链接指向 openrig 仓库再打开 Neovim 确认插件加载无报错。这套自检清单虽然简单但能把大部分部署问题拦在项目开始之前。4. 常见问题与排查技巧实录4.1 高频问题速查表这里整理了我实际使用 openrig 过程中遇到的典型问题以及对应的排查方法问题现象根本原因解决方式新机器上zshrc报错找不到命令配置先于工具安装被加载先跑包安装再执行link.sh关联配置某个文件已存在软链接创建失败link.sh的安全机制在起作用手动备份原文件后重跑脚本或在脚本中确认无需保留两个系统下 Git 配置不通用用户名、邮箱在不同机器上有差异用条件判断区分机器或把差异项抽到本地密钥文件brew bundle安装中断网络波动或 cask 包版本冲突直接重跑brew bundle本身具备幂等性AI 规则在某个工具里不生效AI 工具没有读取rules.md按工具的手动导入方式把规则文件接入常见于新装工具服务器上找不到openrig/scripts修改过目录内容但未拉取最新先git pull再执行相关脚本每次在表格里记下一个新问题我都会顺手在脚本里补上防呆逻辑。比如 link.sh 的目标已占用则跳过就是被第一个问题逼出来的改进。4.2 我最想强调的两条避坑经验第一别把brew bundle dump的输出直接当依赖声明。这个命令导出的清单很全但也包含你某天临时装来试一下的包、甚至是某个软件的传递依赖。用它做 openrig 的包清单只会让安装时间越来越长、维护成本越来越高。花十分钟手工整理一份真正的常用清单才是长久之计。我现在每季度做一次精简看看清单里哪些包在过去三个月没用过直接删掉。第二跨平台脚本一定要写set -euo pipefail。没有它脚本里某条命令失败后会静默继续装到一半你都不知道漏了什么。加了之后任何一步失败都会立刻中断并提示部署问题当场暴露。很多看起来玄学的环境问题其实都是脚本没有 fail fast 造成的。4.3 给新手的扩展建议openrig 是个可以不断扩展的基础设施。我现在正计划加两个能力一个是给配置加CI 冒烟测试在每次 push 后用 Docker 启动一个干净的 Linux 容器完整跑一遍install.sh确保所有脚本在干净环境下都能正常工作另一个是把 AI 模块单独拆出去做成一个可单独引用的子仓库让其他项目也能直接复用那套 AI 规则和提示词模板而不必依赖整个 openrig 环境。此外还有一个很实用的小技巧定时备份 openrig 仓库到第二个远端。配置仓库本身也有丢失风险丢了多年的积累更难受。我把 openrig 同时 push 到两个不同平台的私有仓库任何一端出问题都还有备用副本。根据我的实际维护经验openrig 这类东西最好的状态是日常无感换机显灵。它不会天天刷存在感但每次当你需要重建环境、新开服务器、加入新工具时它都能稳稳地给你托底。我自己从原来换电脑痛苦一整天到现在新机器 20 分钟进入状态这个变化足以说明一切。如果你也想迈出第一步不需要一开始就面面俱到先把git、zshrc、Brewfile三个最基本的部分管起来剩下的模块会随着你的使用习惯慢慢生长出来。