如果你在搜索引擎里敲下 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 c="cd ~/cave" alias t="bash ~/cave/bin/tasks.sh" alias n="vim ~/cave/notes/daily.md" # 朴素的提示符：用户 + 当前目录 PS1='[\u@\h \W]\$ '编辑器我选了 Vim，不是因为它最好，而是因为它所有 Unix 系统都自带，学一次受用终身。配置我只加了几条，核心目标是减少手指移动，而不是把它变成 IDE：
" 显示行号，但保持界面清爽 set number " 缩进统一用四个空格 set expandtab shiftwidth=4 tabstop=4 " 输入时实时搜索 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(encoding="utf-8") body = markdown.markdown(src, extensions=["extra", "codehilite"]) html = f"""<!DOCTYPE html><html lang="zh"><head> <meta charset="utf-8"><title>{pathlib.Path(sys.argv[1]).stem}</title> <style>body {{ max-width: 60rem; margin: 4rem auto; padding: 0 1rem; line-height: 1.8; }}</style> </head><body>{body}</body></html>""" pathlib.Path(sys.argv[1]).with_suffix(".html").write_text(html, encoding="utf-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 我最大的收获
顺着这个项目，我最大的变化不是效率提升了多少，而是我和工具之间的关系变了。以前我是软件的租客，住在别人设计的房间里，按照别人的习惯摆放家具；现在我是自己数字世界的开发者，每一块材料和每一个接口都亲手装过。遇到问题时，我的第一反应从"去搜一下哪个软件能解决"变成了"先看看这个问题到底是什么，能不能自己处理"。
这让我在写代码、写文章、做日常记录时都多了一份踏实。工具还是那些简单的命令，文件还是那些普通的文本，但使用它们的姿势完全不同了。
如果你也想试一把，我的建议是别搞大动作，先选定一个小场景——比如只用纯文本记一周的随手笔记，或者只用终端管理一周的任务。撑过最初几天的不习惯，你大概率会回来跟我说：原来工具这件事，真的不是越大越好。
