不必堆砌一个又一个追求新鲜感的效率工具我越来越觉得把自己活成一个“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 cavrg -n --no-heading -i $1 ~/cave用法很简单cav docker网络 cav 部署脚本 cav 2025-01原理上是调用了ripgreprg在~/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无限膨胀。为了更顺手我把它做成两个aliasalias tbash ~/cave/tasks/task.sh today alias tdonebash ~/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^(?Pdate\d{4}-\d{2}-\d{2})\s r(?Pstart\d{2}:\d{2})-(?Pend\d{2}:\d{2})\s r(?Psummary.?)(?:\s(?Plocation.))?$ ) 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, encodingutf-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(fDTSTART:{to_ics_dt(start)}) ics_lines.append(fDTEND:{to_ics_dt(end)}) ics_lines.append(fSUMMARY:{summary}) if location: ics_lines.append(fLOCATION:{location}) ics_lines.append(END:VEVENT) ics_lines.append(END:VCALENDAR) with open(calendar.ics, w, encodingutf-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;TZIDAsia/Shanghai:20250212T140000 DTEND;TZIDAsia/Shanghai:20250212T150000二是在生成脚本里统一先转成UTC时间再写ICS然后在导入时让日历App选“转换为本地时间”。我个人习惯用第一种简单直观。坑二换行符。早期这个脚本在Windows上生成ICS后日历App一直报“文件格式错误”。排查后才发现是换行符问题——有的解析器对\r\n和\n很挑剔。目前业界建议统一使用\r\n作为行结束符。你可以在写文件时这样处理with open(calendar.ics, w, encodingutf-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/ userremote-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文件而已。