从全家桶到两百行脚本：caveman极简主义的技术选型与自动化实践

从折腾一堆自动化工具到最后只剩一个几百字节的脚本，我才真正理解了 "caveman" 这三个字母的分量。它不是一个项目，甚至不是一套完整的方法论，而是一种态度：像穴居人一样，手里只有火种和石斧，但足够活下去。这篇文章不讲什么高深架构，我想把这几年围绕 "caveman" 总结出的极简做事方式、一条条可以抄走的清单，以及一次真实的项目瘦身过程，完整写出来。不管你是被各种全家桶折腾到疲惫的开发者，还是想给生活做减法的普通用户，这东西多少能给你一点参考。

1. 从一行命令到全家桶，再回到一行命令：caveman 项目的由来

大概三年前，我的个人服务器上跑着一个自己搭的"自动工作流"。它由一个 Node.js 服务、一个 Redis 数据库、三个 Webhook 转发器，外加上一套基于 Docker Compose 的编排组成。听起来很专业对吧？实际效果是，我平均每两周就要为它折腾一次：不是某个容器内存溢出了，就是某个依赖库悄悄升级后接口变了。

有一次服务器重启，整个链路起不来了。我花了一个多小时排查，最后发现原因简单得可笑——写错了一个环境变量名。那一刻我盯着满屏的容器日志，脑子里突然闪过以前见过的一个工具名字：caveman。

极客圈里确实有不少叫 Caveman 的开源项目，它们的功能八竿子打不着，但气质一致：没有花哨依赖、不做过度设计、一个文件能解决的事绝不拆成三个模块。我对这个名字印象很深，是因为它直接点破了一个行业里大家都不愿意承认的事实——我们常常为了显得专业，把简单的事情搞得无比复杂。

后来我开始刻意做减法，把这套工作流一层层拆掉。先关掉不需要的 Webhook，再把 Redis 换成本地 JSON 文件，最后干脆把 Node.js 服务替换成了一个大概两百行的 bash 脚本。运行结果反而更稳定，排障时间从两小时降到了十分钟。

这个经历让我养成了一个习惯：做一个决定之前，先问自己一句"如果这就是我的全部工具，我还能完成任务吗"。真实答案往往是"能，而且能得挺好"。这就是我要聊的 caveman 式做事方法的起点——它不是什么新奇发明，只是把"少即是多"这句话真正落到每一个技术选型里。

聊到这里，你可能会问；那是不是以后我们就该全部退回命令行、彻底不用现代工具了？当然不是。下文我会把我总结的原则、清单和边界问题全部展开，你会发现 caveman 真正反对的从来不是工具的复杂性，而是那种无法解释、无法掌控却还在无限膨胀的复杂性。

2. 我提炼出来的四条 caveman 原则与一份可直接照抄的落地清单

这一章是整篇文章的核心。我从多次"先复杂后极简"的反复实践中，提炼出四条原则。每条原则后面，我会配一个真实的例子，以及一份可以直接带走自检的清单。

2.1 原则一：一个任务只交给一个工具

这句话听起来像废话，但很多人做反了。以一个简短的文本转写需求为例，常见的做法是"Python 脚本 + requests 库 + 第三方 API + 消息队列重试 + 结果入库"。五样东西，五个环节，任何一个出问题都会导致整个链路中断，排查还得沿链路一个个找。

caveman 的做法是"bash + curl + cron"。调用一次 API，把返回结果写到本地文件，加一个 if 判断失败后简单重试，完事。任务和工具是一一对应的：它就做一个转写，不顺便做日志分析，不顺便做用户管理，不顺便做数据可视化。这种"单工具"思维，极大压缩了问题半径。

在生活场景里也一样。记账就找一个顺手本子或用最简单的记账 App，拍照修图就修图，不要同一个 App 又修图又写日记又带社区。每加一个功能，等于给自己加了一个习惯负担。工具的边界清晰，你的注意力才清晰。

2.2 原则二：配置必须能写进一张 A4 纸

判断一套系统是否过度复杂，我有一个土办法：把它所有的配置项、启动命令和常规排障路径写在一张 A4 纸上。如果能写清楚，这套系统基本可控；如果写不下，说明复杂度已经超出了你的心智带宽，未来它一定会莫名其妙地出问题。

拿我常给别人推荐的静态博客方案举例：一个 GitHub 仓库，两个分支，三个命令（add/commit/push）。部署时在服务器上挂一次 webhook 或者用纯静态托管，一天管完。所有配置加起来不到二十行，一张纸完全写得下。对比之下，那种需要数据库、后台管理界面、定时任务组合的博客系统，光初始化配置就得写满两页纸。

表格做出来会更直观：

注意，我反对的不是数据库或后台管理本身，而是"为了发文章这种低并发、低实时性需求去背负一套动态运行环境"这件事。如果你的需求真的需要实时交互、复杂权限，那自然该用对应的工具，但一个个人博客大概率不需要。

2.3 原则三：能用定时任务解决，就别常驻后台

这是我踩坑最多的一条。早期做任何小功能，我都习惯"起一个服务、监听端口、保持运行"，好像不常驻就显示不出技术含量。结果就是：进程一挂，服务全崩，还得靠监控软件去拉活，拉不活就只能等待用户报障。

caveman 的思维方式相反：先问一句"这个需求是实时的吗？"如果用户晚五分钟看到结果没有区别，为什么要常驻？直接丢进 crontab，每晚固定时间跑一次，跑完就退出。没有常驻进程，就没有内存泄漏；没有端口监听，就没用被攻破的表面；输出写进文件，检查文件时间戳就知道最近跑没跑成功。

我举一个实际例子。以前我写了一个 RSS 聚合推送服务，常驻监听，还要配 supervisor 做进程守护。后来我把它改成每小时运行一次的 cron 任务，脚本里读一次 RSS 源、比对去重、写入日志，然后退出。体积从"一个服务"变成"一次性的短命进程"，稳定性反而提升了好几倍。我甚至不需要监控它，只需要每天扫一眼日志文件的大小和末尾时间。

2.4 原则四：任何输出都要保持人能直接读懂

最后一条原则针对的是数据格式。很多工具喜欢把状态扔进数据库，或者吐出一大坨 JSON，里面嵌套四层，字段命名还用缩写。JSON 机器读起来方便，但对人极不友好：你没法直接 diff，没法用 grep 搜，没法在命令行里一眼看出异常。

caveman 式输出尽量用纯文本、CSV 或结构简单的日志。例如我设计的待办同步脚本，最终产物就是一个每行一条事项的 txt 文件，时间戳用人类习惯的"2024-06-01 09:30" 而不用时间错。好处是用cat、less、grep、tail就完全能掌握全局，出了问题打开文件一眼就能定位，连"去数据库里查一下"这一步都省了。

以下是我现在一直贴在终端上方的清单，也是给我的自媒体写作任务准备的，你可以直接抄走当自检测试：

• 我准备引入的依赖或工具，它解决了哪个独占性问题？其他工具完全替代不了它吗？
• 把它换成 shell 三件套（grep、awk、sed）或者一个文本文件，能否实现 80% 的效果？
• 这个系统未来三个月会不会需要强制升级？升级后我是否还能完全掌握它？
• 它是否引入了常驻进程或开放了网络端口？如果用 cron 一次性运行能否替代？
• 它产生的中间数据和最终数据，我是否能用记事本打开且看懂每一行含义？
• 如果它明天被删除，我能否在半小时内用其他方式完全恢复原有功能？

如果一个问题你答不上来，那你大概率正在为复杂度买单。这条清单我现在每个周五会过一遍。过完你会发现，有些工具根本不是必需品，就像厨房里积灰的面包机，想象很美好，打开就是麻烦。

3. 一次真实的 caveman 式重写：个人待办同步脚本的瘦身记录

光讲原则不够过瘾，我下面拆一个真实的项目，展示"从全家桶到 caveman"的完整过程。这是我个人的待办同步工具，因为涉及跨设备同步，我最初把它做成了一个"准工业级"系统。

3.1 之前的架构：过度设计长什么样

最初的方案是：手机端的快捷指令把新待办通过 Webhook 发到一个 Node.js 服务，服务收到请求后写入 Redis 队列，另一个 worker 进程异步处理，把最终结果同步到 Dropbox 里的一个 JSON 文件，同时给我发一封通知邮件。

看着还挺合理的对吧？真实麻烦在于：手机快捷指令偶尔超时，Node 服务内存一涨就崩，Redis 数据持久化配置没做好重启就丢，Dropbox 同步冲突会让 JSON 文件整个坏掉，通知邮件偶尔被扔进垃圾箱。我有时候一天要在五个工具之间来回排查，单纯为了记一个"买洗衣液"，付出的维护成本比洗衣液本身还贵。

这个项目的复杂度已经明显超过了问题的复杂度。问题的本质就两件事：把新条目加到文件里；把这个文件同步到另一台设备。两个需求，根本不需要常驻服务。

3.2 重写之后：两百行 bash 加一个 cron

重写后的版本，总代码量不足原来的十分之一，但完成了 95% 的功能。核心思路是：文本文件当数据库，git 当同步通道，crontab 当触发器，全都运行在本地，只在必要时触碰网络。

先定义要同步的待办文件。为了保证全平台可读，我用纯文本，格式是这样：

# 2024-06-01 - 买洗衣液 - 修复博客图片链接 # 2024-06-02 - 给奶奶打电话

采集端就放在手机自带备忘录里，手机和电脑都装了第三方同步工具，文件到了本地就算完成"入站"。剩下的交给脚本。

脚本本身，我先写一个"增补待办"函数。它检查参数里有没有新内容，有就直接追加到今天日期的分区下，没参数就打印当前全部待办：

#!/bin/bash TODO_FILE="$HOME/todo/todo.txt" add_todo() { local line="$1" local today today=$(date +%F) if ! grep -q "^# $today" "$TODO_FILE"; then printf "\n# %s\n" "$today" >> "$TODO_FILE" fi printf -- "- %s\n" "$line" >> "$TODO_FILE" echo "added: $line" } if [ -n "$1" ]; then add_todo "$*" else cat "$TODO_FILE" fi

同步端更简单，每天凌晨跑一次git pull && git add . && git commit -m "daily sync" && git push，完成跨设备同步。没有常驻进程，没有端口，没有任何对外网络服务。如果当天没变化，commit 会被跳过，也不会报错。我甚至还加了乐观锁机制，超时自动重试两次：

SYNC_ATTEMPTS=3 sync_todo() { cd "$HOME/todo" || exit 1 for i in $(seq 1 $SYNC_ATTEMPTS); do if git pull --rebase >/dev/null 2>&1 && git push >/dev/null 2>&1; then break fi sleep 5 done }

3.3 重写后避过的几个坑

这个过程不是一帆风顺的，踩了几个值得写下来的坑。

一是 git 冲突。因为两台设备可能离线各加了几条，pull时会有冲突。第一次冲突时，git 会中止 rebase，脚本直接退出了。要处理这个，我给整个脚本在开头加了锁文件机制，避免多实例同时改待办文件。用文件锁还有一个好处，重启后锁文件会自动消失，不会出现"孤儿进程卡死资源"的问题：

LOCK_FILE="$HOME/todo/.lock" if [ -f "$LOCK_FILE" ]; then echo "Another instance is running, exit" exit 0 fi trap 'rm -f "$LOCK_FILE"' EXIT touch "$LOCK_FILE"

二是中文编码。这个问题在 macOS 和 Windows 间文件处理时特别常见。系统主题是 UTF-8，但某些同步工具会把中文输出转成别的不标准形式，导致 git diff 显示乱码。解决方式是让同步链路统一走git默认的 UTF-8 通道，并在脚本里强制设置export LANG=C.UTF-8，让文件读取和输出保持一致。

三是日期边界问题。凌晨 00:01 跑同步，如果设备时区不同，date +%F可能算出昨天的日期，导致待办分到错误的分区。我最终采取的方案是：不在脚本里硬编码时区，而是读取设备本机设置，但会在待办文件头部用# 2024-06-01标注，这样你一眼就能看出哪一条是"今天"的，即使因为时区问题分错了，手动改一行也很快。这本身也符合 caveman 的"让人能看懂"原则——所有数据都能被人类检查、修正。

3.4 新旧方案的结果对比

做了个对比表，数据来自我两个多月的实际使用记录：

这次重写给我留下的最大体会是：当你把方案砍到只剩 "文件 + 定时任务 + git" 这三个普通人也能理解的东西时，它反而拥有了旧方案没有的韧性。因为任何一环坏了，你都知道它坏在哪里、如何修，根本不需要什么"全链路可观测系统"来帮你观察。

同步这件事本身就是有频率、有失败重试、有最后一致性的，一批数据晚个几分钟到另一台设备完全不是问题。定时任务天然匹配这种需求，你却偏要引入一个实时监听体系，这就是当初复杂度爆炸的根源。

4. caveman 的边界：什么时候不该恋旧，以及我与复杂工具相处的方式

写到这里，你可能觉得我是在鼓吹"所有东西都退回脚本时代"。完全不是。caveman 是一种思维模式，不是万能锤。工具的世界里，复杂模式之所以存在，是因为有些需求确实天生复杂。重要是分清什么时候可以用简单的锤子，什么时候必须上机床。

4.1 三条红线，碰到就别硬扛

我在长期实践中给自己划了三条红线，只要碰到任一条，就说明这里不适合过度求简，该上专业工具还得上。

第一条红线是安全与权限。如果你的系统处于公网、涉及多用户身份认证、要遵守合规要求，那绝不能只用 bash 脚本硬扛。专业框架提供的能力，比如权限粒度控制、审计日志、密钥轮换，是脚本很难复刻的。这种情况下盲目追求极简，等于拿石斧去处理现代武器等级的安全威胁，出事只是时间问题。

第二条红线是实时性要求。如果业务要求毫秒级响应、持续连接或者事件驱动的推送，那 cron 这类设计就不适用了。这种场景该用队列、事件流、常驻服务，老老实实接受其复杂度，同时做好监控。

第三条红线是数据不可再生。如果这批数据一旦丢失就永远找不回来，或者价值远高于维护成本，就不能拿"文本文件 + 手动 git push"这种方案去赌。你需要备份策略、异地冗余、定期快照，必要时用专业数据库机制来保证可靠性。

其实这三条红线总结起来就是一句话：caveman 适用的对象是"低并发、低风险、实时性要求不高"的领域。个人任务自动化、家庭小工具、个人网站的静态逻辑、内容创作流程，这些都合适。一旦越界，就要果断放弃石斧，上机床。

4.2 我和复杂工具相处的方式

很多人听完极简主张就会走向另一个极端——看到复杂工具就反感，把所有新技术都判死刑。但在我的实践里，复杂工具本身没有问题，问题在于你是否真心理解它、需要它。

举例来说，我写视频剪辑脚本时会用专业的转码工具链，因为它的性能、滤镜质量远超任何自写替代品。同样，我写笔记分享时经常用对象存储，因为它有完善的权限、CDN、审计能力。我接受这些复杂度，是因为我已经清楚知道它们的每一个模块能带给我什么、出现故障时我该去查哪本文档。

判断一个复杂工具是否值得留在系统里，我长期用这样一个经验法则：它是你主动引入的，还是被动堆上去的？主动引入，代表你已经评估过它解决问题的能力，此刻复杂是划算的；被动堆上去，则是"别人都说需要""默认配置就这么架构"，这类复杂度最危险，因为它不在你的心智模型里，出了故障你根本无从下手。

4.3 在工具与生活之间划一条 caveman 式的线

这个思路放到生活里也很好用。我以前手机里装了七十多个 App，每天光刷推荐流就能耗掉两小时。后来我用同样的逻辑做了一次清理：只保留那些"明确解决某类刚需且无法替代"的应用，其余全部卸载。一个月之后，手机日均使用时长降了差不多四十分钟。

工具和生活的复杂度是相通的。你需要的不是一个能解决所有问题的万能平台，而是几个各自把本职工作做到最好、能力边界清晰的小工具。一旦每个工具都像穴居人的火种一样能被完全理解、随时修复，你反而获得了自由。

所以我的建议并不是"抵制复杂"，而是"做复杂的主人，不做复杂的租客"。所谓的主人，就是清楚地知道这个功能为什么会在这里、它服务的场景到底是什么、剥离它之后系统会变成什么样。如果你对着一个工具始终想不明白这三个问题，那它大概率是别人硬塞进你生活的，而不是你真正需要的。

5. 收尾小技巧：每引入一个新工具前，先问自己一个问题

写了这么多，最后分享一个我每天都在用的小技巧。每次要引进一个新工具、新依赖或者新流程之前，我会单独花三分钟做一个模拟实验：

想象这个工具明天就会突然消失，你的所有数据、文档、配置瞬间归零。你能否在 30 分钟内用一个文本编辑器、一套最基础的本机工具，手动恢复核心数据的八成以上？

如果能，那这个工具就属于"锦上添花"，它可以进场，但要有退场预案。如果不能，说明你已经过度依赖某个黑盒，未来的风险已经不可控了。这种时候你首先要做的不是去完善备份，而是重新审视这个黑盒是否真的不可替代。

我在实际应用这个标准的过程中，砍掉了无数看似"省心"实则绑人的服务。每次砍完，短期会有点不适应，但两周后都会庆幸当初的果断。把复杂工具当作随时可以开除的外包员工，而不是永远养在家的祖宗，这种掌控感比任何参数优化都让人踏实。