如果你在搜索引擎里敲下 caveman大概率会先看到原始人、穴居人或者某款老游戏的词条。但我今天想聊的 caveman是一个我维护了大半年的个人项目——把现代化开发环境几乎全部推倒回到石器时代去做一套极简工作流只用终端、纯文本和几行 shell 脚本不依赖重型 IDE、不依赖云端、不依赖动不动几个 GB 的框架。这套东西解决的核心问题很简单当工具本身的维护成本开始超过它带来的收益时你怎么把自己的数字生活重新抢回来。这个项目适合三类人被各种全家桶环境搞得焦头烂额的开发者刚入门想在命令行里建立长期习惯的新手以及任何对纯文本生产力有兴趣、想知道少即是多到底能少到什么程度的人。下面我把整个项目的设计思路、实操步骤和踩过的坑都摊开讲照着抄就行。1. Caveman 到底是什么从石器时代借来的开发哲学1.1 一个标题背后的两层含义叫 caveman 不是玩梗它准确描述了这个项目的两个核心动作。第一层是回归原始。现代开发环境的问题不是功能太少而是功能太多。装一个 IDE 要热等几分钟每次升级都会引入新问题插件生态复杂到你需要一个专门的工具来管理工具。caveman 的思路是反过来主动降级用 80 年代就存在的终端、文本文件和命令组成一套跑在当下的工作流。就像原始人不需要智能手机也能活但他们的生存技能一点不比现代人少。第二层是徒手制造工具。caveman 项目里所有东西都是自己攒的编辑器配置自己写任务管理自己用 shell 脚本实现笔记系统就是一堆 Markdown 文件加一个索引脚本。你不用等软件厂商给你造轮子因为你的轮子你自己会造。这种自己动手的掌控感是这个项目最大的隐性收益。1.2 我为什么决定做这件事触发这个项目的直接原因是某天我打开电脑发现光是为了写点东西这个需求我同时开着编辑器、笔记软件、任务管理工具、云同步客户端加起来占了将近 6GB 内存而真正属于我自己的内容可能只有几百 KB。那一刻非常荒诞。更荒诞的是我发现自己越来越依赖某个云服务的网络状态离线的时候连查自己以前写的笔记都费劲。我意识到我的生产力工具正在反向控制我。于是我做了一个决定接下来一个月所有个人项目、随记、日程管理全部用石器时代方案接管只保留浏览器和终端。这篇文章就是那一个月实践的结果。2. 核心设计思路把复杂度砍到只剩骨架2.1 三条必须遵守的原则caveman 项目启动前我给自己定了三条硬规则所有决策都必须过这三道闸。第一条叫文件永远是第一公民。任何数据都必须能以纯文本形式存在能用 Markdown 就不用富文本能用 CSV 就不用数据库能用 JSON 就不用专有格式。这样做最大的好处是数据永远不会被某个软件绑架。哪怕十年后这套工具全没了文件还在内容就还在。第二条叫一个任务一个脚本。不搞大一统的集成工具而是把需求拆成一个个小脚本每个脚本只干一件事干到最好。需要组合的时候用管道和参数把它们串起来。这种 Unix 哲学听着简单实际操作起来会让你对复用有全新的理解。第三条叫能跑就不要换。一旦某个方案跑通了除非它明确阻碍工作否则不折腾升级、不换新技术栈。caveman 的精神内核是稳定压倒一切原始人不会因为隔壁部落发明了新的磨石头方法就立刻扔掉自己手里那块好用的石头。2.2 工具选型一次扎心的对比遵循上述原则我做了几组关键选型每组都和一个主流的现代方案做了正面比较工作场景现代方案Caveman 方案为什么选后者日常写作与笔记云笔记应用带富文本、标签、搜索Vim Markdown 文件 grep 检索文件本地可控检索不依赖网络格式永久任务管理项目管理软件看板、提醒、协作一个tasks.sh脚本 纯文本清单三秒记录无弹窗无需登录代码编辑大型 IDE带调试器、重构、插件市场终端编辑器 命令行编译工具启动快、内存占用低、专注写作本身文件同步云同步网盘Git 仓库 本地备份版本历史清晰冲突可控不信任第三方文档协作在线协作文档Markdown 导出 PDF/HTML所见即所得之外的自由排版与脚本处理当然这个表格不是要说现代工具一无是处。团队协作、大规模调试、复杂项目管理该用重型工具还是得用。caveman 的定位是个人生产力领地不是给整个团队用的操作系统。我自己在写复杂项目时依然会打开完整 IDE但在日常记录和轻量开发上这套原始方案确实稳得让人安心。3. 实操从零搭建一个 Caveman 工作台3.1 目录结构所有内容的第一块基石动手第一步不是装软件而是设计目录。一个清晰的目录结构比任何管理工具都重要因为你的文件就是你的数据库。我在用户主目录下建了一个~/cave作为整个工作的根目录下面分成四个子目录~/cave ├── notes/ # 所有笔记按主题分子目录 ├── tasks/ # 任务清单每月一个纯文本文件 ├── inbox/ # 临时收集箱定期清空归档 └── bin/ # 自己写的所有脚本加入 PATH这个结构看起来简单但它解决了一个大问题让在哪里放东西变成零决策成本。任何新内容进inbox整理时再决定去处。bin目录里的所有脚本都会被加入环境变量让我随时能像使用内置命令一样调用自己写的工具。目录设计的原则是要能一眼看懂。如果三个月后的自己看到这个目录还要思考半天每个文件夹干嘛的说明结构设计失败了。我用了一个很笨的验证方法把目录树打印出来贴在显示器边上看不顺眼就立刻改。3.2 终端与编辑器配置半个小时的耐心活终端我用的是系统自带的 一份精简配置。很多人第一步就走偏去折腾各种 fancy 终端主题和补全插件这违背了 caveman 的本意。我的~/.bashrc里只有三样东西别名、PATH 和一套朴素的提示符。# 三个提升效率的别名 alias ccd ~/cave alias tbash ~/cave/bin/tasks.sh alias nvim ~/cave/notes/daily.md # 朴素的提示符用户 当前目录 PS1[\u\h \W]\$ 编辑器我选了 Vim不是因为它最好而是因为它所有 Unix 系统都自带学一次受用终身。配置我只加了几条核心目标是减少手指移动而不是把它变成 IDE 显示行号但保持界面清爽 set number 缩进统一用四个空格 set expandtab shiftwidth4 tabstop4 输入时实时搜索 set incsearch 记住上次编辑位置 au BufReadPost * if line(\) 0 line(\) line($) | exe normal! g\ | endif我特别想提醒的一点不要一开始就装几十个 Vim 插件。先只用原生功能写两周每次遇到痛点先问自己这个操作有多频繁如果一天用不到一次就忍一忍如果真的频繁到烦躁再去找针对性的方案。这样配出来的编辑器每一行配置你都懂为什么存在。3.3 第一批脚本让重复劳动原地消失caveman 项目中第一个有仪式感的脚本是tasks.sh。它不做花哨的事只支持三个动作列出今天的事、添加新任务、标记完成。#!/usr/bin/env bash # tasks.sh —— 极简任务管理 FILE$HOME/cave/tasks/$(date %Y-%m).txt case $1 in add) echo [ ] $(date %m-%d) $2 $FILE echo 已添加: $2 ;; done) sed -i s/^\[ \] $(date %m-%d) $2/[x] / $FILE echo 已完成: $2 ;; *) echo 今天的事情 grep -E ^\[ \] $(date %m-%d) $FILE || echo 今天没有待办好好休息 ;; esac这个脚本不过二十行但它把记任务这个动作从打开软件、等待加载、新建条目、设置提醒、最后还要忍受一个常驻后台进程压缩成了一秒内完成的终端命令。我实测下来记录任务的心理阻力小了非常多之前是等会再记现在是顺手就记。这类脚本就是 caveman 的核心资产。它们很小、很丑、没有界面但它们只属于你一个人完全按照你的习惯工作这比任何通用工具都符合自己造工具的本意。4. 工作流核心单文件程序与命令式思维4.1 为什么坚持单文件优先在 caveman 项目里我给自己定了一个隐性规则能用单个.py或.sh文件解决的问题绝不建包、不搞工程化。这在现代开发社区听起来像异端但它有一个非常实际的理由单个文件意味着零构建步骤、零依赖安装、零目录结构纠结你把文件拷贝到任何一台机器上能跑就是能跑。举个例子我需要一个把 Markdown 笔记转成 HTML 的小工具用于偶尔分享。现代方案可能是搭一个静态站点生成器配置主题、模板、路由。我的方案是一个 Python 脚本解决#!/usr/bin/env python3 import sys, markdown, pathlib src pathlib.Path(sys.argv[1]).read_text(encodingutf-8) body markdown.markdown(src, extensions[extra, codehilite]) html f!DOCTYPE htmlhtml langzhhead meta charsetutf-8title{pathlib.Path(sys.argv[1]).stem}/title stylebody {{ max-width: 60rem; margin: 4rem auto; padding: 0 1rem; line-height: 1.8; }}/style /headbody{body}/body/html pathlib.Path(sys.argv[1]).with_suffix(.html).write_text(html, encodingutf-8) print(done -, pathlib.Path(sys.argv[1]).with_suffix(.html))这个脚本直接依赖 Python 的 markdown 库装一次之后它就永久躺在~/cave/bin里。没有配置文件、没有版本兼容问题、没有学习成本。当我需要样式变化打开这个文件改三行 CSS 就行。单文件程序的哲学本质是把复杂度装进口袋——你为一个小问题付出的维护成本应该小到像一个口袋那么点而不是要为此修一座宫殿。4.2 命令式思维把点按钮改成写一行caveman 工作流和图形界面最大的区别在于思维模式。图形界面让你在一个个窗口里点来点去每一步都消耗注意力和时间命令行思维则鼓励你直接把操作写成一条命令让机器替你完成中间过程。拿最常用的场景举例我每天的笔记会不断积累时间久了我想看一下这个星期写了多少内容。图形界面下你得记住文件位置打开软件找到统计功能甚至可能根本没有统计功能。命令行下只需要一行wc -w ~/cave/notes/$(date %Y-%m)/*.md | tail -1再比如我想批量给所有笔记加上一个统一的页脚标记for f in ~/cave/notes/*.md; do echo -e \n---\n#devlog $f; done这种把操作变成命令的习惯一旦建立你会发现大量原本需要专门软件的事都可以用几行命令完成。而且命令是透明的你可以看到每一步在做什么出了问题能精确地知道是哪里错了不像黑盒软件报个错你还得猜它内部发生了什么。要做到这一点有两个基本功值得花时间练一是grep/find/sed这几个文本处理命令的常规用法不需要精通但常用参数要滚瓜烂熟二是养成先想命令、再打开软件的条件反射。后者一开始很难坚持但只要强迫自己三十次就会自然形成肌肉记忆。5. 常见问题与排查实录这台石器机器也会翻车5.1 问题速查表任何工具都有翻车的时候极简方案也不例外。把这两个月里最典型的几个问题整理成表每个都是我亲手踩过的坑问题现象原因解决办法笔记搜不到明明记得写过grep 就是没结果文件被放进了 inbox 未归档路径不对定期清理 inbox建立索引脚本用find全局搜任务清单混乱每天打开tasks.sh看到一堆过期任务只添加不清理清单无限膨胀每月新建文件月底归档历史文件靠按月滚动天然清理脚本突然失效一直好用的脚本某天报错环境变量或依赖库版本变化少依赖第三方库把系统内置工具用足必要时读取报错信息对症处理Vim 操作卡顿打开大文件时明显迟滞没有关掉语法高亮等耗性能功能对大文件执行set syntax off只保留核心编辑能力换了电脑配置丢失所有别名和脚本在新机器上都没了没有把配置纳入版本管理把~/.bashrc、~/.vimrc、~/cave/bin全部放进 Git 仓库一键拉取5.2 避坑技巧与心得分享三条这个项目带给我的最实在的经验。第一条是备份要比工具多一层。我在本地之外另放了一份加密备份每周自动跑一次。原因很直白纯文本文件的好处是轻坏处是丢了就没地方哭。极简主义节约的是维护成本不是安全预算。第二条是不要为了极简而极简。有一次我为了省事把压缩图片的工具脚本改成用一串复杂的sed命令去处理二进制文件结果直接弄坏了两张图。后来我老老实实装了一款开源命令行图像工具几行参数解决问题。这件事让我明白caveman 精神反对的是多余的复杂度不是反对合适的技术工具。第三条是给自己留一个后门。我一开始就决定如果某个环节确实阻碍工作超过半天就允许自己临时回到现代工具不做道德绑架。有一次做一份需要严格排版的长文档我直接拿回了桌面排版软件。用熟练的工具把事情解决比用对工具但花三倍时间更符合这套哲学的目的。6. 后续扩展与我的真实体会6.1 还想继续做的扩展方向caveman 项目目前已经很稳定但我觉得还有几个方向值得继续挖。一是给笔记系统加一个全文索引脚本用ripgrep和简单的awk生成关键词映射让检索速度再上一个台阶。二是把任务系统升级成带截止日期的版本在显示清单时自动高亮过期项目。三是给这套系统写一份给两个月后的自己的使用手册放在~/cave/README.md。这听起来奇怪但真的有用——这半年里我多次因为忘了某个脚本的用法而重复造轮子如果有手册至少能少走弯路。打算把每个脚本的用途、参数、示例都写进去让这套系统变成下一个自己最容易上手的东西。6.2 我最大的收获顺着这个项目我最大的变化不是效率提升了多少而是我和工具之间的关系变了。以前我是软件的租客住在别人设计的房间里按照别人的习惯摆放家具现在我是自己数字世界的开发者每一块材料和每一个接口都亲手装过。遇到问题时我的第一反应从去搜一下哪个软件能解决变成了先看看这个问题到底是什么能不能自己处理。这让我在写代码、写文章、做日常记录时都多了一份踏实。工具还是那些简单的命令文件还是那些普通的文本但使用它们的姿势完全不同了。如果你也想试一把我的建议是别搞大动作先选定一个小场景——比如只用纯文本记一周的随手笔记或者只用终端管理一周的任务。撑过最初几天的不习惯你大概率会回来跟我说原来工具这件事真的不是越大越好。