不必堆砌一个又一个追求新鲜感的效率工具，我越来越觉得，把自己活成一个“caveman”——一个坚持用纯文本、命令行和最朴素文件来管理信息的现代穴居人，反而是长期最省心的方案。
这篇文章源头特别简单：半年前我翻自己两千多条书签的收藏夹，想找一个当时存过的部署脚本，结果在浏览器收藏夹、几个笔记App、Read-it-Later工具里来回切换搜索，浪费了二十多分钟都没找到。而坐在我旁边的同事，一个只用一个按日期命名的文件夹加一堆txt文档的“老派”程序员，三十秒就靠一条grep命令把类似的内容翻出来递给了我。
那次之后我开始认真审视自己这套“现代数字生活”的复杂度，也花了大概三个月时间把个人工作流整体做了减法。如果你也受够了工具碎片化带来的“管理成本比工作本身还高”的体验，这篇文章里的思路、具体配置和踩过的坑，你可以直接抄。
1. 为什么我选择“穴居人”式的工作流
先说清楚，这里的caveman不是叫你回到石器时代不用电脑，而是指一种信息管理的建筑策略：把最需要长期沉淀的信息，保存在最简单、可读性最强、几乎不存在“供应商锁定”风险的格式里，也就是纯文本和结构化文件。听起来很原始，但它的核心优势恰恰是这种原始带来的。
1.1 现代工具的隐形成本：数据孤岛与迁移恐惧
市面上优秀的笔记软件、任务管理工具和书签服务各有各的好，但用一段时间后你会发现一个共性问题：每一个工具都在制造一个独立的数据孤岛。Notion里有一份知识库，浏览器收藏夹里有几百条链接，Stick Notes上有临时想法，某个TODO App里有项目排期——信息之间完全没有任何联动。
更隐蔽的问题在你需要搬家时会暴露出来。你积累了两年的笔记，导出格式可能是JSON也可能是HTML，带不带附件完全是另一回事；你的任务历史可能根本导不出结构化数据。每次工具改版、收费调整或团队协作变动，耗时迁移都是一种隐形损耗。我身边不止一个朋友因为这些工具忽然调整政策，被迫花整个周末去处理几百篇笔记的导出问题。
而纯文本文件几乎没有这个烦恼。一个xxx.md或者xxx.txt，任何设备、任何系统、任何文本编辑器都能打开。它不会因为某个公司停止运营而消失，也不存在格式版本兼容问题。这种稳定感在你积累的信息量越来越大时，价值是成倍增加的。
1.2 纯文本的长期价值：可搜索、可脚本化、永不过期
纯文本有三个现代GUI工具很难同时具备的特性。
第一，可搜索。系统级的全文搜索已经很成熟，再加上grep或ripgrep这类工具，哪怕你有几十万个纯文本文件，定位内容也就是一瞬间的事。这远比在图形界面里按文件夹一个个点进去找要快得多。
第二，可脚本化。文本文件天生就能被程序处理。你想统计过去一年里记录了哪些类型的任务、想批量把某类tag提取出来、想定时归档过期条目——写一个几十行的Python脚本或者简单的Shell管道命令就能搞定。图形化工具里的数据，想做类似的自动化就要等官方API，或者靠各种不稳定的小插件。
第三，永不过期。我2015年写过的一些Markdown笔记，今天打开看依然内容完整、排版清晰。而我同期存在某些在线笔记平台里的内容，有相当一部分经历了格式渲染变化，甚至因为平台改版变得难以阅读。格式稳定本身就是一种长期主义。
1.3 理念边界：不是反工具，而是把合适的任务分给合适的工具
必须强调，这条工作流的理念不是说所有现代工具都是垃圾，然后你要把生活彻底原始化。我的真实做法是分层的：
- 值得长期沉淀的知识、想法、计划——极简纯文本文件。
- 需要实时协作、复杂格式、富媒体展示的内容——仍然留在现代工具里，比如团队的知识库或在线文档。
- 需要跨设备同步的最新状态——用同步工具把纯文本文件夹同步到各设备，而不是去记好几套系统。
也就是说，把“记忆”和“记录”分开。记忆依赖外部工具，一旦工具出问题就全丢；记录放在自己完全可控的纯文本里，工具出问题最多影响一点阅读体验，数据和信息本身永远是自己的。
2. 搭建信息中枢：一份txt文件搞定所有书签与速记
如果你只有三分钟，只看这一节就够了，因为这是我的整套“穴居人”工作流的最核心部分：用一个纯文本文件作为所有书签、语录、灵感和速记信息的中枢。
2.1 我用了一个极简的文件目录结构
先看我的整体信息文件架构，非常简单，你在任意目录下都可以照搬：
~/cave/ ├── _inbox.txt ├── notes/ │ ├── 2025-01-15-部署记录.md │ ├── 2025-01-20-读《重构》笔记.md │ └── ... ├── bookmarks/ │ ├── 技术.md │ ├── 灵感.md │ ├── 工具.md │ └── 生活.md └── tasks/ ├── todo.md ├── doing.md └── done/2025-01.md几个关键文件的作用：
_inbox.txt：像实体收件箱一样，任何临时想法、看到的好内容、随手记录，先无脑丢进这里。每天或每周集中整理一次。注意这里需要换行，我自己就是按"一行一条内容"的规则来写的，格式越简单越容易坚持。
notes/日期-主题.md：需要长期保存的完整笔记，按日期前缀排序，用文件名做快速索引，方便搜索也有天然时间线。
bookmarks/分类.md：书签类内容不再扔给浏览器收藏夹，而是手动按分类整理到特定文件里。
tasks/状态.md：任务管理单独一类，下一节详细展开。
2.2 为什么书签必须离开浏览器，自己管
浏览器自带的收藏夹，最大的问题是你只是在“存”，并没有在“整理”。存进去几百条之后，没有tag能力、搜索也很原始，更可怕的是很多浏览器收藏夹的同步偶尔会冲突甚至丢失。我自己就把收藏夹里的链接导出来过一次，导出的HTML格式乱七八糟，之后决定彻底改用文本文件管理。
现在我的书签管理方式是这样的，拿技术.md举个例子：
# 技术书签 ## 部署与运维 - https://example.com/linux-performance - Linux性能排查必备命令合集 - https://example.com/docker-network - Docker网络模式图文详解 ## 编程语言 - https://example.com/golang-slice - Go Slice底层实现分析给每个链接加一句话说明，这是关键的长期收益。光秃秃的URL过三个月再看，你可能完全想不起当时为什么收藏它。带一句话描述，这条书签就有了上下文。配合下面的搜索方法，你能在一秒内从所有历史书签里捞回想看的内容。
2.3 一条命令让所有文本飞起来：ripgrep搜索技巧
文件多了之后，最怕的就是记不清内容存在哪个文件里面。我的应对是统一入口命令，建议你在Shell配置（~/.bashrc或~/.zshrc）里加一行：
alias cav='rg -n --no-heading -i "$1" ~/cave'用法很简单：
cav docker网络 cav 部署脚本 cav 2025-01原理上是调用了ripgrep（rg），在~/cave目录里做全文本搜索，-n显示行号，-i忽略大小写。只要你的信息都以纯文本存放在同一根目录下，这就是一套通用、快速、不依赖任何应用的数据检索方案。
我这里再补充几条搜索技巧，都属于日常的高频操作：
- 搜索并只看文件列表：
rg -l "关键词" ~/cave，只输出包含关键词的文件名。 - 按标题快速过滤：
rg "关键词" ~/cave --glob "*.md"，限定只搜索Markdown文件。 - 搜索时要带上下文：
rg -C 2 "关键词" ~/cave，显示关键词前后两行，方便快速确认内容是否命中。
2.4 踩过的坑：文件名命名规范的教训
刚开始用这套方案时，我踩过一个看起来很小但实际很影响的坑：笔记文件命名不统一。有时候写部署记录.md，有时候写20250115-deploy.md，还有一次直接叫随便记一下.txt。结果就是~/cave里的文件越来越多，但每次想找内容都只能靠全文搜索，文件名完全成不了索引。
后来我给自己定了三条硬性命名规范，才彻底解决：
- 笔记类文件使用日期前缀：
YYYY-MM-DD-主题.md，同一天多篇就追加-1、-2后缀。 - 书签和任务类文件拒绝日期前缀，因为它们按主题分类更合适。
- 临时文件统一进
_inbox.txt，不允许在根目录乱建新文件。
规范这东西，越早定越好。一两条简单的规则能让你在信息量膨胀后还能保持目录整洁，不会变成一个新的“垃圾堆”。
3. 任务管理：用shell脚本把待办清单变成“活的”系统
信息管理搞定后，下一步是任务管理。这部分同样用最简单的文本文件——配合一个几十行的Shell脚本，让它拥有自动归档、排期提醒等能力，不再是一个死板的清单。
3.1 为什么要用文件做待办，而不是待办App
待办类App最大的问题，是录入成本太高。你有一个念头“别忘了下周三给客户发报价”，在App里你需要打开应用、新建任务、填标题、选截止日期、选分类、选优先级……这一套动作下来最少几十秒，之后还很容易彻底忘记去看这个App。而我用文本任务系统的真实体验是，写下来的动作成本只要三秒：
# todo.md - [ ] 下周三给客户发报价 @2025-02-12 @工作 - [ ] 预约牙医 @2025-02-15 @生活 - [ ] 整理上季度复盘件 @大任务每一行就是一条任务，[ ]表示未完成，@后是日期和分类标签。你可以用任何编辑器打开这个文件修改，也可以直接命令行操作，不管哪种方式，都比大多数待办软件灵活得多。
3.2 一套可抄的Shell任务管理器
纯写文件当然还不够“活”，我在上面加了一个简单的处理脚本，让它实现两个实际功能：每天帮你找出今天到期和过期的任务，以及把完成的任务自动归档。
写一个~/cave/tasks/task.sh，内容大致如下：
#!/bin/bash # 简易文本任务管理器 TASK_DIR="$HOME/cave/tasks" TODAY=$(date +%F) show_today() { echo "==== $(date '+%Y-%m-%d %A') 到期/过期任务 ====" grep -n "@$TODAY\|@[0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\}" "$TASK_DIR/todo.md" | \ while IFS= read -r line; do due=$(echo "$line" | grep -o '@[0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\}' | head -1 | cut -c2-) if [[ -n "$due" && "$due" < "$TODAY" ]]; then echo "[过期] $line" elif [[ "$due" == "$TODAY" ]]; then echo "[今天] $line" else echo "[未来] $line" fi done } archive_done() { # 把以 [x] 开头的已完成任务移入 done 目录 grep -n '^\- \[x\]' "$TASK_DIR/todo.md" >> "$TASK_DIR/done/$(date +%F).md" sed -i '/^\- \[x\]/d' "$TASK_DIR/todo.md" echo "已完成任务已归档至 done/$(date +%F).md" } case "$1" in today) show_today ;; done) archive_done ;; *) echo "用法: task.sh [today|done]" ;; esac这段脚本不算精巧，但足够日常使用。核心是：
task.sh today输出所有到期、过期任务，方便你每天在终端里跑一次。task.sh done自动把标记为[x]的任务移入历史归档文件，不让todo.md无限膨胀。
为了更顺手，我把它做成两个alias：
alias t='bash ~/cave/tasks/task.sh today' alias tdone='bash ~/cave/tasks/task.sh done'然后我在自己的Shell启动文件里增加了这样的逻辑：每次打开终端自动执行一次t，等于每天开机第一件事就是看到今天该干什么。
3.3 和日历提醒配合的方案
这里必须诚实一点：纯文本任务系统在“主动提醒”这个维度上，确实不如原生日历App。我的处理方式是做一次“分层配合”：
- 纯文本系统负责任务清单的全量管理和长期记录。
- 重要的、强时效性的日程（比如和客户开会、交报告截止日），在里面单独加一行
@日期，然后我把这些少数关键日期手动输入手机日历的提醒。
别小看“手动输入”这几个字，因为经过纯文本系统筛选后，真正需要进日历的往往一周也没几件，手动录入成本很低。这样既保留了文本系统的简洁，又补上了时不我待的提醒短板。
3.4 踩过的坑：先把“大而全”塞进文本，再被打脸
我最初也试图把复杂项目管理、多级任务依赖、看板视图全塞进这个文本系统里，结果是灾难。文本文件是很适合线性列表和简单标签的，但不适合树形结构和跨任务依赖。当任务达到几十条且互相有前后关系时，纯文本维护起来反而比专业工具更吃力。
所以再次强调边界：这个文件任务管系统适合个人待办、轻量计划和短期排期，不适合团队协作和复杂项目跟进。复杂的项目管理，你就老老实实用Jira或Notion这类专业工具，别硬凑。
4. 从笔记到日历：把文本数据回流到现代工具
“caveman工作流”不是把数据和现代工具完全隔绝。很多时候，文本记录最舒服，但最终消费这些数据的场景可能在手机日历、在共享文档、在某个聊天群里。那就要解决一个问题：如何把纯文本里的结构化信息，自动“翻译”成现代工具能用的格式。
4.1 用Python脚本把纯文本会议记录转成ICS日历文件
举个例子。我习惯在_inbox.txt或专门的notes/日程.md里记这么一行：
2025-02-12 14:00-15:00 客户需求评审会议 @线上/腾讯会议 2025-02-14 10:00-11:30 团队周会这些行天然可解析：日期、起止时间、事件标题、地点（可选）。我写了一个小Python脚本，读取这个文件，把每一行解析成一个日历事件，生成标准ICS文件：
#!/usr/bin/env python3 # 简易生成 .ics 日历文件 import re from datetime import datetime, timedelta EVENT_RE = re.compile( r'^(?P<date>\d{4}-\d{2}-\d{2})\s+' r'(?P<start>\d{2}:\d{2})-(?P<end>\d{2}:\d{2})\s+' r'(?P<summary>.+?)(?:\s+@(?P<location>.+))?$' ) def to_ics_dt(dt_str): return datetime.strptime(dt_str, '%Y-%m-%d %H:%M').strftime('%Y%m%dT%H%M%S') with open('notes/日程.md', 'r', encoding='utf-8') as f: events = [] for line in f: line = line.strip() m = EVENT_RE.match(line) if not m: continue start = f"{m.group('date')} {m.group('start')}" end = f"{m.group('date')} {m.group('end')}" events.append((start, end, m.group('summary'), m.group('location'))) ics_lines = [ 'BEGIN:VCALENDAR', 'VERSION:2.0', 'PRODID:-//caveman//日历生成//CN' ] for start, end, summary, location in events: ics_lines.append('BEGIN:VEVENT') ics_lines.append(f'DTSTART:{to_ics_dt(start)}') ics_lines.append(f'DTEND:{to_ics_dt(end)}') ics_lines.append(f'SUMMARY:{summary}') if location: ics_lines.append(f'LOCATION:{location}') ics_lines.append('END:VEVENT') ics_lines.append('END:VCALENDAR') with open('calendar.ics', 'w', encoding='utf-8') as f: f.write('\n'.join(ics_lines)) print(f'已生成 {len(events)} 个事件 -> calendar.ics')执行后得到一个calendar.ics。这个文件可以直接导入Google Calendar、Apple日历或Outlook，也可以放到你的WebDAV服务器上，手机日历订阅这个链接，等于你用几行文本实现了全端日历同步。
4.2 踩过的坑：时区与换行符问题
这里必须提醒几个容易出问题的细节，不然你可能会白折腾半天。
坑一：时区。如果你直接用本地时间生成ICS，而没有指定时区信息，某些日历客户端会按自己预设时区理解，导致事件时间和原始记录差几个小时。解决办法有两条：一是在BEGIN:VCALENDAR之后加上X-WR-TIMEZONE:Asia/Shanghai，并在每个VEVENT里显式加入TZID，类似：
DTSTART;TZID=Asia/Shanghai:20250212T140000 DTEND;TZID=Asia/Shanghai:20250212T150000二是在生成脚本里统一先转成UTC时间再写ICS，然后在导入时让日历App选“转换为本地时间”。我个人习惯用第一种，简单直观。
坑二：换行符。早期这个脚本在Windows上生成ICS后，日历App一直报“文件格式错误”。排查后才发现是换行符问题——有的解析器对\r\n和\n很挑剔。目前业界建议统一使用\r\n作为行结束符。你可以在写文件时这样处理：
with open('calendar.ics', 'w', encoding='utf-8', newline='\r\n') as f: f.write('\r\n'.join(ics_lines))坑三：中文编码。ICS文件通常建议UTF-8编码，但某些老版本日历软件对非ASCII字符识别不佳。解决方法是把中文标题做一下转义或Base64编码，但多数现代客户端直接UTF-8就够用了。
4.3 轻量同步方案：Syncthing与纯文本的绝配
当你这套纯文本工作流真正用起来之后，一定会有一个需求：在手机、工作电脑、个人电脑之间无缝访问这些文件。商业网盘可以把整个~/cave文件夹同步到云端，但作为“caveman”，我更推荐用Syncthing——一款开源、点对点同步工具，不需要任何云服务器中转。
原理上，Syncthing在所有安装了它的设备之间直接建立加密通道，把指定文件夹保持多端一致。现实效果就是你在地铁上用手机改一条任务，到家打开电脑文件已经同步好了，而且是秒级的事。
安全无敏感数据泄露问题，因为文件没有经过第三方服务器。我自己配置了三端同步：台式机、笔记本、手机。手机上我用的是iOS端的Syncthing客户端（也有Android版），配合纯文本编辑器（iOS可以选1Writer或Taio这类应用），整个闭环就打通了。
但同步不等于备份，这必须单独强调，否则某台设备异常清空或文件误删，同步会把错误状态直接传播到所有设备。所以紧接着是备份策略。
5. 数据安全第一：一套朴素但可靠的备份策略
使用文本作为核心数据存储的最大好处之一是备份极其容易——不需要专用软件，不需要云服务，几条命令就搞定。但越简单的方案越要落实，很多人恰恰输在“懒得做”上。
5.1 我的“三个一”备份实践
个人实际经验下来，一套稳妥的方案由三部分组成，我称之为“三个一”：
- 一份本地备份：每天自动打一个tar包到另一块硬盘或分区。
- 一份异地备份：每周把压缩包推送到另一台设备（家里的NAS，或者开通了SSH 的VPS）。
- 一份快照备份：每月导出一次整目录的当前状态，保留长期版本。
“三个一”不是为了炫技，而是分别对应三个不同的故障场景：硬件损坏、设备丢失、误删后需要回退到很久以前的版本。
具体命令可以这样写。先在/etc/cron.daily/cave-backup建一个脚本：
#!/bin/bash BACKUP_DIR="/mnt/backup/cave" DATE=$(date +%F) tar czf "$BACKUP_DIR/cave-$DATE.tar.gz" -C "$HOME" cave find "$BACKUP_DIR" -name "cave-*.tar.gz" -mtime +30 -delete第一行打日期命名压缩包，第二行保留最近30天的备份。本地备份完成之后，每周异地推送用一行rsync或scp就行：
rsync -avz /mnt/backup/cave/ user@remote-host:/backup/cave/5.2 踩过的坑：备份脚本写了半年，从没演练过恢复
这个坑我付出了代价，分享出来希望你别重复。有段时间备份脚本一直在按计划跑，我一直以为数据是安全的。直到有一次硬盘故障需要恢复，我才发现压缩包打开后结构混乱，部分文件名乱码，根本没法干净地还原目录结构。原因很简单：备份策略没有配合“恢复演练”。
从那以后，我给自己定了一个规则：每个季度至少做一次完整恢复演练，选定一个干净目录，解压备份，然后逐一检查里面的关键文件是否能正常打开。这不仅验证备份有效，还能早早发现脚本里的问题。现在我每季度挑个周末，找一台空闲机器恢复一次，整个流程大概二十分钟。
5.3 版本管理的额外建议
虽然是纯文本，同一份笔记也难免经历多次修改，你可能希望回退到某个特定的旧版本，而普通备份的粒度又太粗。这时候最轻量的方案是用git管理~/cave目录，不需要私有仓库，本地仓库就够了：
cd ~/cave git init git add . git commit -m "日常更新"在你觉得有必要保留版本快照时，手动提交一个commit；再配合git log和git checkout，想回退到任何历史版本都极其方便。如果哪天你想做自动化，加一条cron任务定时git add -A && git commit -m "auto backup"也不错，但这会丢失很多中间状态，所以我更偏向手动关键节点提交。
6. “穴居人”工作流的适用边界，以及我的实际体会
写到这里，肯定有读者会问：这套方案适合所有人吗？答案是不一定。想清楚边界，才能做出对自己真正有效的选择。
自己的实际感受中，有几个维度可以帮助你判断自己是否适合：
6.1 适合的人群特征
用了半年多，我觉得以下特征的人会特别受益：
- 信息量大且分散：每天都会接触大量链接、想法、笔记，需要一个统一、可搜索的中枢。
- 重度命令行使用者：已经习惯终端操作，希望所有信息都能用命令触达，而不是切换到各种GUI应用。
- 追求长期主义和隐私：不愿意把自己的思想沉淀锁在某个商业产品里，希望数据永远属于自己、随时可导出。
- 跨设备使用频繁：需要在不同电脑、手机上无缝衔接同一批文件，但又不想依赖特定厂商的云同步。
如果你属于这类人，这套纯文本工作流能带来的最直接的改变，就是你不再需要记“这个内容在哪个App里”。所有东西都在~/cave，一个命令全库搜索，管理成本陡降。
6.2 不太适合的人群或场景
反过来，下面这些情况里，这套方案不仅帮不到你，还可能拖后腿：
- 重度协作场景：需要多人实时编辑、评论、复杂权限、审计日志，纯文本方案做起来很吃力，专业协同工具明显更合适。
- 富媒体知识库：你的笔记里有大量截图、手绘图、复杂表格、音视频文件，纯文本会丢失太多表达能力，建议留在Notion、Obsidian甚至专用的数字笔记本里。
- 特别追求自动化提醒的用户：如果你希望每件事都有强提醒、App推送、到期提醒弹窗，纯文本的“主动提醒”能力确实天然弱，需要配备日历或提醒App弥补。
- 完全没有命令行习惯的普通用户：学习曲线会让维护成本很高，暂时的“原始感”容易变成长期的负担。
6.3 我走过弯路后的最终体会
最后分享一点个人感悟吧。
最初开始转型的时候，很容易陷入“工具本身变成目的”的误区——用纯文本还是用App，重点不是你用了什么工具，而是围绕你真实的信息习惯设计一套低摩擦、可持续的系统。有人用Notion也能把生活整理得井井有条，也有人把纯文本系统整得像盖一座新概念大楼，几天就熄火了。工具永远是工具，方法好不好，最终看你能不能长期稳定地用下去。
对我自己而言，回到“caveman”这套思路最大的收获并不是“逼格”或者“极客感”，而是三件事：找东西变快了，记录变轻了，迁移不再恐惧了。遇到好文先丢进_inbox.txt；任务完成打一个[x]；换电脑就是把整个~/cave拷过去。这些东西朴素得没有一句值得炫耀，但恰恰因为朴素，它们才真正可靠。
如果你准备动手试试，我的建议是别一次性把所有系统都迁过来。先从书签开始，把浏览器收藏夹整理成两个md文件，用一周时间感受一下“一条grep命令格式化检索所有链接”的效率。好用就继续往笔记和任务扩展，不好用也没什么损失——毕竟,不过就是几个txt文件而已。
