去年年初我给自己下了个狠心把所有日常使用的数字工具全部换成一套代号为“caveman”的原始人级别配置。这名字听着有点行为艺术实际上是一个很认真的实验——我想知道如果断网、没有云服务、不能随时随地装新软件我的生产环境还能不能继续工作。结果这一试就是大半年收获比预期多很多。这篇文章就把caveman项目的来龙去脉、选型逻辑、搭建过程和踩坑记录完整摊开给那些也受够了臃肿工具链的朋友做个参考。1. 为什么会启动caveman我的工具链失控之路1.1 从“装工具”到“维护工具”的恶性循环2024年初我统计过自己电脑里的开发工具和效率软件结果有点吓人终端模拟器装了4个编辑器配了3套笔记软件从印象笔记、Notion一路换到了Obsidian同步方案至少折腾过5轮。每个工具刚装上的时候都觉得自己“生产力暴涨”但用不了两个月就开始出问题——插件冲突、配置漂移、版本不兼容、同步失败最后大把时间都花在维护工具上真正干活的反而没多少。这就是典型的“工具吞噬工作效率”。我身边很多朋友也这样聊起来都苦笑每天打开电脑第一件事不是写代码而是先把各种依赖更新一遍。某次我为了修一个编辑器插件从上午折腾到下午最后发现是插件作者删了仓库那一刻真的想砸电脑。caveman项目就是在这个背景下发起的。我给它的定义是一套尽量贴近计算机早期使用方式的、离线优先、单点依赖、十年不坏的个人工作环境。目标不是追求效率最大化而是追求“在最恶劣条件下依然能正常开工”。1.2 成本账每个“便利工具”都在收维护税启动项目前我先算了一笔时间账。当时我的工作流大概是这样打开电脑启动系统更新等3分钟打开IDE等插件索引构建再等2分钟打开同步盘处理不同步冲突about 10分钟写代码时随手装了某个新工具配环境20分钟一周下来光处理工具跑路、配置失效、网络不同步的问题保守估计6到8个小时。这笔账一算就明白了每个看似便利的工具都会以“维护税”的形式持续抽走时间。越复杂的工具链抽得越狠。而caveman的初衷就是把维护税压到几乎为零——代价是牺牲一部分现代工具提供的便捷性和花哨体验。1.3 当时定下的三条实验规则实验开始前我给自己立了三条规则整个项目的所有决策都围绕它们展开断网可开工所有核心操作不依赖云服务、不依赖在线资源。就算整个网络瘫痪我依然能写文档、改代码、查本地资料。故障可自愈任何环节出问题必须能在单台机器上、用一条命令或一个脚本恢复不需要复杂的部署手册。纯文本优先所有数据以纯文本、结构化文档、脚本形式存在不搞私有格式不为任何商业软件的数据格式当人质。这三条规则直接决定了后面每一步的选型。很多选项是被规则直接淘汰的——比如笔记必须用Markdown纯文本文件同步必须用rsync这类基础命令备份必须能离线完成。2. caveman的选型哲学每个工具都要回答三个问题2.1 三问筛选法还修得了吗断网能用吗核心功能一行命令说清吗启动caveman后我对手头所有工具做了一次“审判”。审判标准就是三个问题回答不上来或者答案不硬的直接淘汰。第一问它在原始条件下还修得了吗如果一个工具坏了是不是只能靠它的开发团队修复如果是这个工具就是不可靠的。caveman要求工具坏了我自己能修——哪怕是翻源码也能翻明白。那些黑盒、闭源、单点服务的东西基本都在这一轮被淘汰。第二问断网能用吗有些工具号称“本地优先”但启动都要强制登录账号、云端同步配置文件这种在我这里算作弊。真正合格的工具是拔了网线、关了路由器以后打开依然是一个完整可用的东西。第三问核心功能能用一行命令说清吗如果一个工具的介绍页需要说“通过强大的集成生态支持灵活可扩展的XX平台”这种话那它的可控性和复杂度已经超了。符合caveman气质的是这样的解释vim是编辑器rsync是同步tar是打包cron是定时——一句话讲完没有任何营销话术。这批筛完留下的工具少得可怜bash、tmux、vim、rsync、tar、git、crontab、Markdown纯文本。这就是caveman的全部家当。2.2 终端环境实测bashtmuxvim为什么比全家桶更扛造说实话我自己以前是重度IDE用户写代码离不开可视化的调试器、自动补全和代码导航。caveman实验初期最没底的就是编辑器环节——vim看着像上个世纪的东西真的能用吗经历了一段适应期后发现现代IDE提供的很多“便利”在远古工具里有完全对应的解决方式只是入口不一样文件跳转IDE靠侧边栏点来点去vim用ctrlp风格的文件搜索插件或者fzf实际上更直接自动补全不用LSP那套重型方案用一个轻量的词补全插件配合tags文件代码的常用符号补全基本够用多任务并行IDE开多窗口终端里用tmux切面板一个窗口里同时跑编辑、编译、日志效率一点不差版本管理IDE里看到的是图形化的diff视图命令行git diff加vim的diff模式能看清楚每一次变更。扛造才是核心优势。IDE全家桶相当依赖网络、依赖插件市场、依赖某个包管理源任何一个环节断了都很麻烦。vim加bash这套东西只要机器能开机就一定能打开工作环境。我用caveman配置在系统崩溃恢复后半小时内就回到了可用状态这是以前用IDE无法想象的。2.3 数据存储Markdownrsync纯文本的降级方案caveman对数据的要求是永不锁死、永不消失、永不依赖特定软件才能读取。全盘MARKDOWN化是我的核心决策。以前我的笔记散布在Notion、印象笔记、各种云文档里想导出一次信息要费老鼻子劲。现在全部改成纯文本Markdown文件按日期和项目分目录存放。效果非常明显——任何一台电脑上用记事本都能打开我的所有笔记。这个降级方案带来的安全感远远超过了同步软件提供的便利。同步方案直接用rsync加cron定时任务。以前我折腾过各种同步盘每次冲突处理都让人血压升高。rsync的做法不搞云端冲突合并那一套单一主副本手动或定时推送到另一块硬盘/另一台机器。没有冲突因为根本没有多向同步逻辑简单到不可能出错。配合一个简单的shell脚本每天自动备份两次重要文件手动备份前再执行一遍。这套东西我在断网状态下跑得稳稳当当。2.4 一张选型对照表现代工具 vs caveman替代我把实验过程中替换的主要工具拉了一张对照表方便直观感受这个项目的“原始程度”现代工具链原有痛点caveman替代方案替换后效果IDEVS Code全家桶插件市场依赖、索引慢、配置膨胀vimtmuxbashtags冷启动零等待功能基本覆盖Notion/笔记软件私有格式、导出困难、网络依赖纯Markdown文件目录管理任何编辑器可读永不锁死云同步盘冲突、限速、隐私顾虑rsync脚本cron定时任务本地主副本逻辑单一稳定图形化终端/工具每台机器都要重装配置一套dotfiles两年没动过配置换机器一条命令恢复环境复杂项目管理软件开会比干活还多纯文本文档todo列表所有计划一眼看完这套配置看起来原始但正是这种原始保证了“确定性”——所有环节都在我掌控内不会莫名其妙出问题。3. 搭建过程实录从空目录到“原始人工作台”3.1 第一步dotfiles仓库与基础目录规划caveman的底座是一套dotfiles仓库所有配置文件集中管理这样换机器的时候一条命令就能恢复整个环境。我建议目录按这个思路规划~/caveman/ ├── dotfiles/ # 所有以点开头的配置文件 │ ├── bashrc │ ├── vimrc │ ├── tmux.conf │ └── gitconfig ├── bin/ # 自己写的脚本统一放这里 ├── docs/ # Markdown笔记和文档 ├── backup_hook.sh # 备份脚本入口 └── restore.sh # 环境恢复脚本restore.sh核心逻辑非常简单就是创建软链接。这个设计我第一次写的时候就确定配置文件不复制、不覆盖全部软链到dotfiles仓库。好处是有任何改动git diff立刻能看到恢复时也不用担心覆盖已有文件。#!/bin/bash # restore.sh —— caveman环境恢复脚本 ln -sf ~/caveman/dotfiles/bashrc ~/.bashrc ln -sf ~/caveman/dotfiles/vimrc ~/.vimrc ln -sf ~/caveman/dotfiles/tmux.conf ~/.tmux.conf ln -sf ~/caveman/dotfiles/gitconfig ~/.gitconfig echo caveman environment restored.3.2 第二步最小可用的bash环境配置bashrc配置遵循“少即是多”的原则每加一行都要经过三问筛选。经过大半年打磨最终留下来的核心配置并不多# 极简但够用的bashrc export EDITORvim alias ..cd .. alias gsgit status alias cclear alias upsource ~/.bashrc # 快速进入常用目录 export PROJECTS$HOME/projects alias projcd $PROJECTS # 防止rm误操作 alias rmrm -i # 设置历史记录条数 export HISTSIZE5000 export HISTFILESIZE10000核心心得是alias不要过度添加只加那些每天都用、且能明显缩短输入的。如果alias本身比原命令还难记这个alias就是负资产迟早要删。3.3 第三步tmux会话管理与vim插件精简tmux在caveman里承担的是“窗口管理”和“会话恢复”两个任务配置同样保持极简# tmux.conf的caveman版本不到20行 set -g prefix C-a # 前缀键改成Ctrla比默认的Ctrlb更顺手 unbind C-b bind r source-file ~/.tmux.conf # 改配置后按prefixr生效 bind | split-window -h # 水平分屏 bind - split-window -v # 垂直分屏 # 开启鼠标支持这个确实是现代便利我留下了 set -g mouse onvim插件我在caveman里做了极限精简。以前配了20多个插件最后删到只剩这几类它们确实是不可替代的vim-plug插件管理器负责安装和更新fzf.vim文件模糊搜索效率刚需vim-airline状态栏增强纯粹看信息方便vim-go或者对应语言插件语法高亮补全按需安装。关键心得是vim的精简不是牺牲效率而是把每一个按键和插件都变成必要的。多余的插件只是给别人看的真正干活只需要那几个。3.4 第四步本地优先的备份与同步脚本备份逻辑是整个caveman最核心的部分。我写了一个脚本完成本地备份、异地备份、日志记录三步配合cron定时触发#!/bin/bash # backup_hook.sh —— caveman备份脚本 BACKUP_SRC$HOME/projects $HOME/caveman/docs BACKUP_DST$HOME/caveman_backup DATE$(date %Y%m%d) # 1. 先对核心数据做快照备份 tar czf $BACKUP_DST/core_$DATE.tar.gz $BACKUP_SRC # 2. 用rsync同步到备份盘 rsync -avz --delete $BACKUP_SRC $BACKUP_DST/sync # 3. 清理超过30天的快照 find $BACKUP_DST -name core_*.tar.gz -mtime 30 -delete # 4. 写日志 echo $(date %Y-%m-%d %H:%M:%S) backup completed $HOME/caveman/backup.logcron定时任务这样加每天中午12点和晚上8点各备份一次0 12 * * * /bin/bash $HOME/caveman/backup_hook.sh 0 20 * * * /bin/bash $HOME/caveman/backup_hook.sh这里有个血泪教训tar快照和rsync同步一定要分开做。快照用于“特定时间点的完整状态”恢复rsync用于“日常文件同步”。如果只做rsync一个文件意外损坏也会被同步成损坏的版本如果只做tar想找几天前的某个小改动就得翻大包。两者互补才稳。3.5 第五步离线急救包与快速恢复演练caveman最后一步也是最容易忽略的一步——准备一个离线急救包。我的做法是在本地和U盘里各存一份所有核心配置的档案、常用安装包、依赖库源码、文档手册的离线副本。急救包结构大概是~/caveman/survival_kit/ ├── config_backup.tar.gz # 所有配置文件的完整归档 ├── installers/ # 常用软件离线安装包 ├── docs/ # 关键工具的离线手册 └── scripts/ # 一键恢复脚本一个重要的实操建议不要只做离线包要定期做恢复演练。我每季度强制自己在一台干净系统上执行一遍restore.sh用急救包恢复环境。第一次演练就发现了两个依赖缺失问题如果没有演练真到用的时候才发现就晚了。4. 实测三十天的结果与翻车记录4.1 数据工具数量、开机速度、维护时长的前后对比caveman跑满一个月后我拉了一组数据对比效果非常直观指标改造前改造后日常必装工具数量27个12个开机到进入工作状态约8分钟约2分钟每周维护工具耗时6到8小时半小不超过1小时断网可用功能占比约40%约95%系统崩溃后恢复速度半天起跳一条命令恢复这个结果让我确信极简路线在个人工作场景下不仅可行还能显著提高稳定性和安全感。4.2 翻车现场一vim配置精简过度导致编辑效率倒退第一次精简vim时我下手太狠把所有“看起来不必要”的插件全删了结果写代码时自动补全失灵、语法高亮丢失、文件搜索要手动翻目录。那种感觉就像把冰箱里所有东西都扔掉然后说“极简生活”结果是连调料都没了。后来我悟了极简不是删到最少而是删到“剩下的都不可替代”。我把自动补全、文件搜索、语法高亮这些真正提高效率的插件加了回来同时砍掉了状态栏主题美化、标签页增强这类“好看但没用”的插件。这次调整之后才真正理解了极简和简陋的区别。4.3 翻车现场二rsync软链接陷阱有段时间我发现同步到备份盘的数据莫名其妙翻倍了排查半天才明白rsync加上-a参数后会保留软链接本身而不是链接指向的内容。我目录里有些软链指向了本机其他目录备份时把链接复制过去了。恢复数据时软链变成了“死链接”目标根本不存在。解决方案是给备份脚本加上-L参数让rsync跟随软链接同步实际内容。这个参数对普通用户或许无所谓但在caveman这种多目录软链环境下不设置就会造成静默数据丢失。这种错误没有日志报错是那种等真正恢复数据时才发现的定时炸弹。4.4 翻车现场三离线急救包里的依赖版本问题第一次演练恢复时我从急救包里装vim装上后发现插件管理器无法安装插件——因为插件的Git仓库需要联网。当时整个人是崩溃的明明做了离线包为什么还缺东西后来意识到急救包只“离线”了主程序没有“离线”插件的全部依赖。插件源码和依赖体积通常很小几十兆而已但缺了它们主程序装了也是残废。这就是急救包必须连“所有可能需要的源码、插件、依赖”一起存的原因。我把vim常用插件仓库全部clone到本地插件的安装地址改为本地路径才真正解决了离线问题。另一个依赖坑是版本匹配。离线包里的东西要定期更新半年更新一次否则等你哪天需要它的时候会发现里面的软件版本过于陈旧连当前系统的库都不兼容。5. caveman的适用边界与我的最终取舍5.1 极简不是目的抗风险才是经历了大半年的caveman实验我最大的认知转变是极简只是一个手段核心目标是抗风险。现代软件工具链最大的问题不是功能不够多而是单点依赖太强。一旦某个服务掉线、某个公司改政策、某个插件作者删库整个工作流就可能瘫痪。caveman的不懈追求就是让每一个环节都具备“可自己修复”的能力哪怕修复方式是笨拙的、原始的。这套理念在面对“机器突然坏了”“系统升级导致环境崩溃”“项目交接需要转交全部配置”的场景时价值会被完全放大。以前我的项目环境是一团乱麻现在是一套清晰的文件和脚本任何人拿到都能快速理解、快速恢复。5.2 哪些场景我坚持“原始方案”截至现在下面几个场景我是彻底地留在了caveman这边没有再回去过文档和笔记坚持纯Markdown文件不用任何云端笔记。隐私、稳定、可迁移三重大山全部解决。本地定时备份坚持rsync脚本。同步盘会冲突、会限速、会关停rsync不会。远程服务器管理坚持ssh加命令行操作。图形化面板能做的终端命令肯定能做而且更可控。版本管理坚持git命令行。无论现在图形化工具多好终端的git才是最全、最稳的。常用开发环境坚持vim加tmux的轻量组合。不是歧视IDE而是这个组合在资源紧张、网络不畅时永远可用。5.3 哪些场景我认怂回到现代工具链caveman不是万能的有几个场景我确实认了怂回到了现代工具的怀抱。大型前端项目的调试现代浏览器的DevTools、SourceMap、全面补全带来的效率提升是vim纯命令行难以复刻的。这类场景我用回了IDE。与同事协作的需求团队用的项目管理工具、协同文档不能因为自己追求极简就拖累团队。协作工具由团队统一决定个人风格退到第二位。需要图形化审阅的场景设计稿审阅、PPT制作、PDF标注这些方面硬用命令行就是和自己的时间过不去。所以最终状态不是“全盘回到原始”而是让caveman成为一种底层的、保底的工作台当现代工具好用、稳定、在线时就大方享受便利一旦这些条件不成立caveman永远是最后一道防线。这种双轨制比绝对地选边站要实用得多。5.4 个人心得做完整个实验后我的体会是大多数人缺的不是更好的工具而是一个能逼自己砍掉冗余的框架。caveman这个项目哪怕你只借鉴其中一部分——比如把笔记迁到Markdown、把备份换成rsync脚本、把配置收进dotfiles仓库——都能明显减少日常维护成本。它不需要你抛弃所有现代工具但它值得让你重新想一想我每天维护的那些东西到底是在服务我还是我在服务它们