最近在整理自己的一套工具流程时我给自己起了个代号叫“caveman”。听起来像在开玩笑但这个词其实概括了我这一年多来最核心的一个感悟数字时代最贵的不是工具订阅费而是被复杂工具绑架的注意力。当你发现打理任务清单本身变成了一种负担笔记软件里躺着几百条从未回看的碎片这时候反而最需要一种“穴居人”式的思维方式——扔掉花哨功能只留下最基础、最可靠、能直接解决问题的原始手段。这篇文章想分享的就是以“caveman”为代号的一套极简个人任务与知识管理方案。它不依赖任何特定商业软件不要求你学习复杂语法核心思路是用纯文本文件、命令行脚本和一个同步盘重新搭建一套完全属于自己、可无限定制、能稳定跑十年的信息处理系统。这套方案非常适合受够了工具折腾的人比如开发者、写作者、研究者或者说任何想要从“工具奴役”里解脱出来的普通用户。1. 项目整体设计与思路拆解1.1 为什么需要“返祖”式的极简管理先说说这个项目到底在解决什么问题。现代人的信息工作流几乎都是这样的任务管理用一个App笔记用一个App文件用一个云盘团队协作再用一个工具。每个工具都有自己的数据格式、同步机制和更新节奏。表面上很高效实际上是一个不断维护的负担。我自己统计过过去五年换过八款任务管理工具每一款都经历了从新鲜到焦虑再到迁移的过程。数据迁移、格式转换、功能重新适应这些隐性成本远高于工具本身的价格。caveman项目的出发点非常朴素把“管理信息”这件事退回最原始的文件系统层面。在电脑里最可靠的基础设施永远是文件系统和文本。它们不依赖某个公司的服务器不绑定某款软件的生死不会因为更新UI而让你重新学一遍。当一切都被降维成“文本文件”和“文件夹结构”之后整个系统的复杂度就被压缩到了最低点。这套方案借鉴了Unix哲学里的“单一职责”原则每个工具只做一件事然后把它们串联起来。文本编辑器负责输入目录结构负责分类命令行脚本负责汇总和统计同步盘负责跨设备传输。没有哪一环是必须依赖特定商业产品的坏了哪一环都可以用别的替换。1.2 方案选型背后的具体取舍逻辑做这套系统的过程中我反复权衡过好几条路线。有人会问用现成的开源笔记软件不香吗比如Obsidian或者Logseq它们也是基于Markdown文件的。这个问题的答案在于自由度。这类软件虽然基于纯文本但仍然会引入插件系统、双链图谱、渲染机制这些东西。而caveman体系的底层哲学是渲染是可选的自动化是必要的。工具只负责存储和检索展示层完全由自己掌控。另一个关键取舍是数据库和纯文本之间的选择。任务数据量达到什么级别时数据库才是必需的按我个人的使用强度——每天记录十条以内的任务、五条左右的笔记——纯文本完全够用甚至可以说纯文本是更优解。因为文本文件可以直接被grep搜索可以用任何编辑器打开可以和Git配合做版本历史也可以在二十年后的任何设备上无障碍阅读。相对地某个App专有的数据库一旦停止维护你所有的积累都可能被锁死。同步方案的取舍也需要说清楚。我用的是常见的网盘文件夹同步方式而不是Git仓库。原因是任务管理和笔记记录有大量琐碎的增量修改Git的每次提交都需要写commit message这个操作负担对于高频记录来说太重了。网盘同步则是自动的我不需要关心版本控制因为文本文件本身已经是最终产物。Git更适用于阶段性的大改动比如月末归档时手动提交一次。2. 核心细节解析与实操要点2.1 目录结构是整套系统的骨架caveman项目最基础的部分是一套按时间轴和项目维度双轴组织的目录结构。这套结构直接决定了后续所有操作的便利性所以值得仔细敲定。我的实际目录布局是这样设计的caveman/ ├── 00_inbox/ # 收集箱所有临时想法、待处理信息 ├── 10_projects/ # 项目区按项目维度存放任务和资料 ├── 20_archive/ # 归档区已完结的项目和过期笔记 ├── 30_areas/ # 领域区长期关注的领域知识 ├── 40_resources/ # 资源库参考资料、文档手册 └── 99_meta/ # 元信息系统本身的配置和脚本为什么这样设计核心逻辑是把“输入”和“输出”分开。00_inbox是唯一的入口用于承接一切碎片信息不需要思考它应该归到哪个项目只需要无脑扔进来。10_projects是主动推进的工作区这里的每个子文件夹对应一个独立事项比如“写年度总结”“装修方案”“学习吉他”。20_archive负责沉淀当一个项目的任务全部完成整个文件夹就移过去。30_areas和40_resources则承载长期的积累。中间的数字前缀不是装饰品它承担了排序和层级的功能。数字小、优先级高的事务靠前显示这条规则在文件管理器里天然生效。相比在笔记软件里打上各种标签这种物理层面的目录排序更直观、更不需要思考成本。2.2 任务文件的格式约定越简单越长久任务管理是整个系统里最容易变得混乱的部分所以我花了很多时间打磨一套接近“万物皆文本”的格式约定。每个项目文件夹里都有一个todo.md文件内容格式固定为三块待办、进行中、已完成。前两项用手工维护列表每一项以方括号开头标记状态。# 待办 - [ ] 联系供应商确认报价 - [ ] 梳理项目时间线 - [ ] 预约周末的场地踩点 # 进行中 - [ ] 撰写方案初稿状态周五前给第一版 # 已完成 - [x] 完成项目立项沟通这套格式没有任何特殊语法就是纯Markdown里最基础的复选框。它可以被GitHub渲染可以被VS Code插件解析也可以被命令行脚本统计。事实上不要小看“已完成列表”这部分。很多人做任务管理只盯着待办看但我实操中发现记录“已完成”的价值至少和记“待办”一样重要。每周回顾时那些打勾的项就是本周产出的证据而且在更新进度时把一条任务从待办挪到已完成动作本身就带来完成感的正反馈。这里有一个实操心得不要试图在任务文本里塞太多元数据比如预算、预估工时、负责人。一旦这些字段出现你就开始需要解析结构需要写查询逻辑最终会走向需要一个真正的数据库。caveman体系的边界就在这里——保持简单宁可多建一个文件夹也别让单条任务变得复杂。2.3 快速捕捉inbox是整套系统的心跳整个caveman系统的运作效率很大程度上取决于“捕捉”这一步是不是足够快。如果记录一个想法需要超过十秒人的大脑就会倾向于不记录然后这个想法就消失了。所以00_inbox的设计目标就是极致简化。我采用的是“短文件名一句话内容”的方案。每次有新想法就在inbox文件夹下新建一个文本文件文件名就是问题或事项的浓缩文件内容可以留空偶尔写一两句补充。举个例子我在开会时听到一个信息点会随手敲一个关于数据备份策略的疑问.txt然后立刻回到会议。这个文件的存在本身就是提示不需要维护复杂的待办列表。这个方案的优势在于它不需要打开任何特定的软件。终端里敲一条vim inbox/xxx.txt或者用系统自带的便签写下后转存甚至用手机上的纯文本App编辑后同步回来——任何能创建文本文件的工具都是入口。相比传统任务管理App里层层嵌套的分类这种方式把捕捉成本降到了最低。2.4 主动清理的节奏比工具本身更重要再好的结构如果不定期维护也会变成新的垃圾场。这套系统的关键运作机制是一周一次和一月一次的清理节奏。每周清理做的是“inbox清空”把零散的文件分类归入对应的项目文件夹或者归档区。这个过程一定程度上类似于邮件处理里的“收件箱清零”核心目的不是整理本身而是一次有意识的回顾——决定每一条碎片信息是继续推进、转存知识库、还是直接丢弃。每月清理则做一次“项目审视”把所有进行中的项目文件夹过一遍检查哪些可以归档、哪些可以合并、哪些其实已经没有推进意义。这个环节往往会带来新一轮的减负体验。我上个月清理时就发现有三个挂着“进行中”的项目其实已经名存实亡超过六十天果断移入归档区之后整个任务列表清爽了非常多。清理的意义不只是整理文件更是逼自己想清楚优先级。3. 实操过程与核心环节实现3.1 从零初始化caveman完整流程如果你是第一次接触这套体系跟着一套流程走一遍最快。整个初始化过程不需要写任何代码需要的只是新建文件夹和一份规划思路。第一步在同步盘里新建名为caveman的根目录在内部创建上面说的六个顶层文件夹。命名里带数字的好处是排序固定不会因为字母顺序打乱层级。第二步在10_projects下建立当前活跃的项目文件夹。这里有一个技巧文件夹名采用“项目名”的直接命名方式比如“搬家计划”而不是“2025-搬家-家里的事”。名字越贴近脑海里的叫法后续找到它的速度越快。第三步为每个项目初始化一个todo.md文件输入固定的三段式模板。第四步在99_meta下建立一个setup.md记录这套系统的结构说明和自己约定的规则。这个文件是给未来的自己看的避免两个月后忘了每条目录的用途。整个流程大约耗时十五分钟但这套目录可以用很长时间。我自己的caveman目录从搭建到现在已经用了二十三个月中间没有推倒重来过只是定期微调了目录名。3.2 用脚本自动生成每日工作日志手写目录结构很灵活但每天记录时如果还要手动建日期文件琐碎感就会积累成阻力。所以我在99_meta下放了一些辅助脚本用最简单的方式自动生成当天的工作日志。这里分享一个bash脚本它做的事情单一且明确在项目目录下生成当天的日志文件文件名带日期模板带基础的时间轴。#!/bin/bash # 文件名: newlog.sh # 用法: ./newlog.sh 项目名 PROJECT_DIR$HOME/caveman/10_projects/$1 TODAY$(date %Y-%m-%d) LOG_FILE$PROJECT_DIR/logs/$TODAY.md mkdir -p $PROJECT_DIR/logs if [ ! -f $LOG_FILE ]; then echo # $TODAY 工作日志 $LOG_FILE echo $LOG_FILE echo ## 计划 $LOG_FILE echo $LOG_FILE echo ## 实际完成 $LOG_FILE echo $LOG_FILE echo ## 问题与想法 $LOG_FILE fi echo 日志已创建: $LOG_FILE这个脚本里有几个值得说明的地方。mkdir -p保证了logs目录存在不会因为目录缺失报错。if [ ! -f ... ]的写法是为了避免重复运行时清空已有内容保证了日志只增不改。文件名用ISO格式的日期可以让文件管理器按名称自然排序这是技术人员常见的习惯对非技术用户也很容易理解。日志模板分成“计划”“实际完成”“问题与想法”三块背后对应一套简单的复盘逻辑先想今天要做什么晚上结束时对比“计划”和“实际完成”落差部分就是反思的起点。“问题与想法”则用来临时捕捉当天冒出来的、不一定和当前任务直接相关的东西。3.3 周回顾脚本从散乱数据里提取有效信息日志和任务清单如果只是躺在那里价值会打折扣。真正让它们有价值的操作是周期性回顾。回顾不一定要看得很仔细但一定要有输出。我写了另一个极简脚本用来汇总一周内所有项目里勾选的项目生成一个临时的周报文件。#!/bin/bash # 文件名: weekly.sh # 用法: ./weekly.sh CAVEMAN_ROOT$HOME/caveman WEEK_START$(date -v-7d %Y-%m-%d 2/dev/null || date -d -7 days %Y-%m-%d) REPORT_FILE$CAVEMAN_ROOT/99_meta/reports/weekly_$(date %Y%m%d).md mkdir -p $CAVEMAN_ROOT/99_meta/reports echo # 本周完成事项汇总 $REPORT_FILE echo $REPORT_FILE grep -r ^- \[x\] $CAVEMAN_ROOT/10_projects $REPORT_FILE || echo 本周还没有完成事项。 $REPORT_FILE echo echo 周报已生成: $REPORT_FILE echo 打开查看本周成果: open $REPORT_FILE这个脚本用到的核心技术点其实是grep -r ^- \[x\]这一行。它的作用是递归搜索所有项目目录下的Markdown文件中匹配“已完成”复选框格式的行并把它们全部汇入周报。这里的引号和转义需要注意方括号在正则里是字符类符号所以要写成\[x\]来匹配字面上的方括号。第一次写这个脚本时我忘了转义结果匹配到了所有复选框行周报里全是未完成任务看上去像一份失败总结。上述脚本在不同环境里日期参数不一样macOS的date命令用-v-7dLinux的date用-d -7 days。我在这段脚本里加了双方式兼容的判断跑不通时会自动回退。这种跨平台兼容对常用双系统的人来说很实用也是踩过坑以后总结出来的。3.4 移动端的低成本接入方案很多人问这套基于桌面端文件系统的体系出门在外怎么办手机上的碎片时间其实才是捕捉信息的高发场景。我的解决方案不依赖任何特定App思路是把“捕捉”这一步拆出来。手机端只需要装一个可以创建文本文件并写入同步盘的App。目前主流的同步盘客户端都支持在App内新建文件只是入口通常藏得比较深。更便捷的方法是把inbox对应的同步文件夹放到手机桌面的快捷入口上。即使没有第三方编辑器直接用系统自带的备忘录功能临时记录每天回来后在电脑端统一转移到caveman系统里。这里有一条铁律需要反复强调不要试图把手机的碎片信息和主系统做实时深度同步。手机端只负责“入”不负责“理”。重要的不是每一条信息都被及时分类而是所有信息最终都汇入同一个入口inbox然后由桌面端的每日或者每周清理过程完成分类。一旦你把“实时整理”的预期加进去这套系统的操作成本就会上升很容易坚持不下去。3.5 版本控制时机只在有意义的节点介入前面提到主要靠同步盘完成版本管理但某些关键节点上Git的介入价值非常大。我采用的方案是每月手动提交一次或者在每次大版本改写时提交一次。具体来说每月末的清理节点对caveman目录执行一次Git提交commit message写成当月的时间区间和主题比如“2025-01归档和清理”。这样做的意义在于阶段性快照。如果某个月的笔记被误删或者同步盘出了故障可以靠Git恢复到一个月前的完整状态。损失最多一个月的数据这在个人知识管理里完全可以接受。日常的高频修改不纳入Git因为大量的大部分修改是零散的临时文件每一次都写message会打断节奏而且同步盘本身已经有实时备份的能力。这个“分区而治”的思路非常关键实时保护靠同步盘阶段性快照靠Git两者各司其职不叠加、不冲突。4. 常见问题与排查技巧实录4.1 多设备同时编辑导致的同步盘文件冲突这套系统在使用中最常见的问题就是桌面端和手机端同时打开同一个文件两边都编辑了然后同步盘生成了一个类似文件名 (冲突的副本).txt的文件。这类冲突文件本身无害不占多少空间但堆积多了会让目录变乱也会干扰搜索。排查思路其实很简单首先判断冲突文件是否包含重要改动。如果只是手机端记录的一条碎片而桌面端进行过大规模整理那冲突文件里的手机端内容大概率已经被包含在inbox里了可以直接删。如果确认冲突文件里有桌面端没有的内容就需要手动合并——通常是把多出来的内容剪切到主文件的末尾。我总结了一套规避策略给不同设备划分明确的“写入边界”。手机端只允许写00_inbox下以m_前缀开头的文件桌面端主要负责其余所有文件的整理和编辑。这种物理上的“隔离”直接把冲突概率降低了九成。同步盘的使用手册里未必会教你这个技巧但实际体验下来极其有效。4.2 文件越堆越多搜索开始变慢怎么办文本文件的好处是几乎不会有性能瓶颈但当你积累到上万个小文件时跨文件搜索的体验还是会变差。我经历过一个阶段每次想找一个半年前的笔记都要在文件管理器里翻很久因为文件名记不完整。解决办法分两层。第一层是最简单的给关键文件做索引在99_meta下维护一个INDEX.md手动登记高频访问的文件路径和用途。这个索引文件本身也是一份笔记维护成本约为每周几秒。第二层是用命令行搜索工具替代文件管理器的内置搜索。系统自带的grep -r就能处理多数场景我更推荐用ripgrep因为它默认忽略隐藏文件和二进制搜索速度明显更快语法还兼容。如果你对命令行不熟也可以直接在目录外部的在线搜索框里直接输入关键词效果比手动翻目录快很多。更深一层的体会是如果经常翻不到某条笔记问题通常不在搜索工具而在分类体系。说明当初归档时没有找到准确的位置或者这条笔记根本就应该删掉。遇到这种情况我会顺手调整一下目录设计而不是死磕搜索技巧。4.3 长期坚持的核心开关降低所有的操作阻力很多初试这类方法的人反馈最多的问题是“坚持不下来”。我觉得核心原因不是方法论有问题而是他们把系统设计得太复杂了。如果每天打开目录就已经花费心思那这个系统迟早会被抛弃。我自己有几个降低阻力的具体手段。一是把最常用的操作做成别名。比如在shell里设置alias inboxcd ~/caveman/00_inbox敲四个字母就能进入收集箱。二是确保任何设备上都有一个全局可见的入口。我把caveman根目录做成了桌面快捷方式桌面上只留这一个文件夹图标其他文档一律归档。三是允许系统变乱但设置一个“不乱底线”inbox里的文件数量一旦超过二十个立即执行一次清理。不要追求每天都清爽追求的是每次清理都能在半小时内完成。4.4 非技术用户的接入姿势不写脚本也能用写脚本确实提升了效率但如果你不会写代码或者不想碰终端这套系统的核心框架依然完全可用。所有脚本扮演的角色都只是“加速”没有脚本手动建文件、手动汇总表格也完全可行。唯一的区别是每周回顾时可能需要花十分钟手工翻目录。我建议非技术用户先不要碰脚本老老实实用目录文本文件的方式跑两周。两周后如果觉得每周汇总太繁琐再照着上面的脚本抄作业。从经验来看大多数人真正无法接受的是“失去图形界面的安全感”一旦适应了文本的简洁直接反而会觉得那些花哨界面才是多余。另一个不写脚本的替代方案是把同步盘的文件夹挂到云服务的网页端在电脑上用网页上传文本文件而不是本地的文字编辑器。所有操作都发生在云端同步盘的目录结构里对系统资源的消耗极低也能规避“命令行恐惧”。5. 扩展方向与进阶玩法5.1 从任务管理延伸到知识输出当任务和日志跑顺之后caveman目录里会沉淀出大量素材。这些素材直接用于创作会非常自然。比如我在日志里记录了每天遇到的问题和解决思路这些内容本身就是文章大纲。每月清理时我会扫一遍当月日志把“问题与想法”段落里写着“这事值得展开写”的内容标记出来它们会进入一个独立的ideas.md文件。这个文件的用途是素材池而不是待办清单。不需要刻意为每条想法设定完成期限只需要确保它在归档时没有丢失。等到某一天需要产出内容时从素材池里挑三到五条互相关联的记录就能拼出一篇有真实案例支撑的文章。这种输出方式相比传统“凭空列大纲”更有底气因为每条想法背后都有对应的实操记录。我自己的大部分工作复盘文章都来自这个渠道。5.2 用纯文本历史生成时间线时间线的概念在知识管理里很容易变成花哨的图表但在caveman体系里你可以用极简的方式实现它——直接利用文件名的日期前缀。假设你的每个项目日志都命名为YYYY-MM-DD.md格式那么你只需要定期执行一次文件夹内全部文件名的遍历就能得到项目的完整时间线。写一个简单命令可以做到ls带排序参数或者find输出文件名列表看起来就像项目日志目录的目录列表。我每季度会做一次这件事把全年按照时间的顺序浏览一遍相当于给自己做了一次“季度回顾的回顾”。这个是真正的数据沉淀不需要额外的数据库或标签系统。因为文件系统的命名规则本身就足够表达时间维度。5.3 和其他工具的协作而不被绑定最后的进阶思路想聊“元能力”——这套体系之所以是可靠的恰恰因为它不绑定特定工具。在caveman框架里任何编辑器、任何搜索工具、任何同步盘的客户端都只是“实现层”。如果一款文本编辑器用起来不顺手你可以换掉它而不影响任何数据如果一个同步盘停止服务你只要把整个目录拷贝到另一个同步盘就行不存在数据迁移问题。我最近就做了一次类似的迁移实验把整套caveman目录从系统自带的云同步切到了自建的同步方案由于底层就是普通文件夹整个迁移过程就是一次复制粘贴耗时不超过五分钟。换作任何专有格式的知识管理软件要实现这种无损迁移至少需要一个下午。这种自由度就是当年选择“返祖”路线时最值回票价的部分。根据我个人的实操体会caveman模式的真正门槛从来不是技术难度而是你是否愿意接受“简单的工具系统”带来的一点笨拙感。它没有炫目的看板视图没有智能提醒没有AI标签。但它给你的是一个可以用二十年的稳定基座以及完全归你自己掌控的信息主权。如果你也厌倦了在各类工具之间反复切换推荐认真尝试一下这套回归原始的方案也许会发现少即是多的老话在数字时代依然管用。 纯文本极简管理：用文件系统和命令行打造个人任务与知识管理体系
最近在整理自己的一套工具流程时我给自己起了个代号叫“caveman”。听起来像在开玩笑但这个词其实概括了我这一年多来最核心的一个感悟数字时代最贵的不是工具订阅费而是被复杂工具绑架的注意力。当你发现打理任务清单本身变成了一种负担笔记软件里躺着几百条从未回看的碎片这时候反而最需要一种“穴居人”式的思维方式——扔掉花哨功能只留下最基础、最可靠、能直接解决问题的原始手段。这篇文章想分享的就是以“caveman”为代号的一套极简个人任务与知识管理方案。它不依赖任何特定商业软件不要求你学习复杂语法核心思路是用纯文本文件、命令行脚本和一个同步盘重新搭建一套完全属于自己、可无限定制、能稳定跑十年的信息处理系统。这套方案非常适合受够了工具折腾的人比如开发者、写作者、研究者或者说任何想要从“工具奴役”里解脱出来的普通用户。1. 项目整体设计与思路拆解1.1 为什么需要“返祖”式的极简管理先说说这个项目到底在解决什么问题。现代人的信息工作流几乎都是这样的任务管理用一个App笔记用一个App文件用一个云盘团队协作再用一个工具。每个工具都有自己的数据格式、同步机制和更新节奏。表面上很高效实际上是一个不断维护的负担。我自己统计过过去五年换过八款任务管理工具每一款都经历了从新鲜到焦虑再到迁移的过程。数据迁移、格式转换、功能重新适应这些隐性成本远高于工具本身的价格。caveman项目的出发点非常朴素把“管理信息”这件事退回最原始的文件系统层面。在电脑里最可靠的基础设施永远是文件系统和文本。它们不依赖某个公司的服务器不绑定某款软件的生死不会因为更新UI而让你重新学一遍。当一切都被降维成“文本文件”和“文件夹结构”之后整个系统的复杂度就被压缩到了最低点。这套方案借鉴了Unix哲学里的“单一职责”原则每个工具只做一件事然后把它们串联起来。文本编辑器负责输入目录结构负责分类命令行脚本负责汇总和统计同步盘负责跨设备传输。没有哪一环是必须依赖特定商业产品的坏了哪一环都可以用别的替换。1.2 方案选型背后的具体取舍逻辑做这套系统的过程中我反复权衡过好几条路线。有人会问用现成的开源笔记软件不香吗比如Obsidian或者Logseq它们也是基于Markdown文件的。这个问题的答案在于自由度。这类软件虽然基于纯文本但仍然会引入插件系统、双链图谱、渲染机制这些东西。而caveman体系的底层哲学是渲染是可选的自动化是必要的。工具只负责存储和检索展示层完全由自己掌控。另一个关键取舍是数据库和纯文本之间的选择。任务数据量达到什么级别时数据库才是必需的按我个人的使用强度——每天记录十条以内的任务、五条左右的笔记——纯文本完全够用甚至可以说纯文本是更优解。因为文本文件可以直接被grep搜索可以用任何编辑器打开可以和Git配合做版本历史也可以在二十年后的任何设备上无障碍阅读。相对地某个App专有的数据库一旦停止维护你所有的积累都可能被锁死。同步方案的取舍也需要说清楚。我用的是常见的网盘文件夹同步方式而不是Git仓库。原因是任务管理和笔记记录有大量琐碎的增量修改Git的每次提交都需要写commit message这个操作负担对于高频记录来说太重了。网盘同步则是自动的我不需要关心版本控制因为文本文件本身已经是最终产物。Git更适用于阶段性的大改动比如月末归档时手动提交一次。2. 核心细节解析与实操要点2.1 目录结构是整套系统的骨架caveman项目最基础的部分是一套按时间轴和项目维度双轴组织的目录结构。这套结构直接决定了后续所有操作的便利性所以值得仔细敲定。我的实际目录布局是这样设计的caveman/ ├── 00_inbox/ # 收集箱所有临时想法、待处理信息 ├── 10_projects/ # 项目区按项目维度存放任务和资料 ├── 20_archive/ # 归档区已完结的项目和过期笔记 ├── 30_areas/ # 领域区长期关注的领域知识 ├── 40_resources/ # 资源库参考资料、文档手册 └── 99_meta/ # 元信息系统本身的配置和脚本为什么这样设计核心逻辑是把“输入”和“输出”分开。00_inbox是唯一的入口用于承接一切碎片信息不需要思考它应该归到哪个项目只需要无脑扔进来。10_projects是主动推进的工作区这里的每个子文件夹对应一个独立事项比如“写年度总结”“装修方案”“学习吉他”。20_archive负责沉淀当一个项目的任务全部完成整个文件夹就移过去。30_areas和40_resources则承载长期的积累。中间的数字前缀不是装饰品它承担了排序和层级的功能。数字小、优先级高的事务靠前显示这条规则在文件管理器里天然生效。相比在笔记软件里打上各种标签这种物理层面的目录排序更直观、更不需要思考成本。2.2 任务文件的格式约定越简单越长久任务管理是整个系统里最容易变得混乱的部分所以我花了很多时间打磨一套接近“万物皆文本”的格式约定。每个项目文件夹里都有一个todo.md文件内容格式固定为三块待办、进行中、已完成。前两项用手工维护列表每一项以方括号开头标记状态。# 待办 - [ ] 联系供应商确认报价 - [ ] 梳理项目时间线 - [ ] 预约周末的场地踩点 # 进行中 - [ ] 撰写方案初稿状态周五前给第一版 # 已完成 - [x] 完成项目立项沟通这套格式没有任何特殊语法就是纯Markdown里最基础的复选框。它可以被GitHub渲染可以被VS Code插件解析也可以被命令行脚本统计。事实上不要小看“已完成列表”这部分。很多人做任务管理只盯着待办看但我实操中发现记录“已完成”的价值至少和记“待办”一样重要。每周回顾时那些打勾的项就是本周产出的证据而且在更新进度时把一条任务从待办挪到已完成动作本身就带来完成感的正反馈。这里有一个实操心得不要试图在任务文本里塞太多元数据比如预算、预估工时、负责人。一旦这些字段出现你就开始需要解析结构需要写查询逻辑最终会走向需要一个真正的数据库。caveman体系的边界就在这里——保持简单宁可多建一个文件夹也别让单条任务变得复杂。2.3 快速捕捉inbox是整套系统的心跳整个caveman系统的运作效率很大程度上取决于“捕捉”这一步是不是足够快。如果记录一个想法需要超过十秒人的大脑就会倾向于不记录然后这个想法就消失了。所以00_inbox的设计目标就是极致简化。我采用的是“短文件名一句话内容”的方案。每次有新想法就在inbox文件夹下新建一个文本文件文件名就是问题或事项的浓缩文件内容可以留空偶尔写一两句补充。举个例子我在开会时听到一个信息点会随手敲一个关于数据备份策略的疑问.txt然后立刻回到会议。这个文件的存在本身就是提示不需要维护复杂的待办列表。这个方案的优势在于它不需要打开任何特定的软件。终端里敲一条vim inbox/xxx.txt或者用系统自带的便签写下后转存甚至用手机上的纯文本App编辑后同步回来——任何能创建文本文件的工具都是入口。相比传统任务管理App里层层嵌套的分类这种方式把捕捉成本降到了最低。2.4 主动清理的节奏比工具本身更重要再好的结构如果不定期维护也会变成新的垃圾场。这套系统的关键运作机制是一周一次和一月一次的清理节奏。每周清理做的是“inbox清空”把零散的文件分类归入对应的项目文件夹或者归档区。这个过程一定程度上类似于邮件处理里的“收件箱清零”核心目的不是整理本身而是一次有意识的回顾——决定每一条碎片信息是继续推进、转存知识库、还是直接丢弃。每月清理则做一次“项目审视”把所有进行中的项目文件夹过一遍检查哪些可以归档、哪些可以合并、哪些其实已经没有推进意义。这个环节往往会带来新一轮的减负体验。我上个月清理时就发现有三个挂着“进行中”的项目其实已经名存实亡超过六十天果断移入归档区之后整个任务列表清爽了非常多。清理的意义不只是整理文件更是逼自己想清楚优先级。3. 实操过程与核心环节实现3.1 从零初始化caveman完整流程如果你是第一次接触这套体系跟着一套流程走一遍最快。整个初始化过程不需要写任何代码需要的只是新建文件夹和一份规划思路。第一步在同步盘里新建名为caveman的根目录在内部创建上面说的六个顶层文件夹。命名里带数字的好处是排序固定不会因为字母顺序打乱层级。第二步在10_projects下建立当前活跃的项目文件夹。这里有一个技巧文件夹名采用“项目名”的直接命名方式比如“搬家计划”而不是“2025-搬家-家里的事”。名字越贴近脑海里的叫法后续找到它的速度越快。第三步为每个项目初始化一个todo.md文件输入固定的三段式模板。第四步在99_meta下建立一个setup.md记录这套系统的结构说明和自己约定的规则。这个文件是给未来的自己看的避免两个月后忘了每条目录的用途。整个流程大约耗时十五分钟但这套目录可以用很长时间。我自己的caveman目录从搭建到现在已经用了二十三个月中间没有推倒重来过只是定期微调了目录名。3.2 用脚本自动生成每日工作日志手写目录结构很灵活但每天记录时如果还要手动建日期文件琐碎感就会积累成阻力。所以我在99_meta下放了一些辅助脚本用最简单的方式自动生成当天的工作日志。这里分享一个bash脚本它做的事情单一且明确在项目目录下生成当天的日志文件文件名带日期模板带基础的时间轴。#!/bin/bash # 文件名: newlog.sh # 用法: ./newlog.sh 项目名 PROJECT_DIR$HOME/caveman/10_projects/$1 TODAY$(date %Y-%m-%d) LOG_FILE$PROJECT_DIR/logs/$TODAY.md mkdir -p $PROJECT_DIR/logs if [ ! -f $LOG_FILE ]; then echo # $TODAY 工作日志 $LOG_FILE echo $LOG_FILE echo ## 计划 $LOG_FILE echo $LOG_FILE echo ## 实际完成 $LOG_FILE echo $LOG_FILE echo ## 问题与想法 $LOG_FILE fi echo 日志已创建: $LOG_FILE这个脚本里有几个值得说明的地方。mkdir -p保证了logs目录存在不会因为目录缺失报错。if [ ! -f ... ]的写法是为了避免重复运行时清空已有内容保证了日志只增不改。文件名用ISO格式的日期可以让文件管理器按名称自然排序这是技术人员常见的习惯对非技术用户也很容易理解。日志模板分成“计划”“实际完成”“问题与想法”三块背后对应一套简单的复盘逻辑先想今天要做什么晚上结束时对比“计划”和“实际完成”落差部分就是反思的起点。“问题与想法”则用来临时捕捉当天冒出来的、不一定和当前任务直接相关的东西。3.3 周回顾脚本从散乱数据里提取有效信息日志和任务清单如果只是躺在那里价值会打折扣。真正让它们有价值的操作是周期性回顾。回顾不一定要看得很仔细但一定要有输出。我写了另一个极简脚本用来汇总一周内所有项目里勾选的项目生成一个临时的周报文件。#!/bin/bash # 文件名: weekly.sh # 用法: ./weekly.sh CAVEMAN_ROOT$HOME/caveman WEEK_START$(date -v-7d %Y-%m-%d 2/dev/null || date -d -7 days %Y-%m-%d) REPORT_FILE$CAVEMAN_ROOT/99_meta/reports/weekly_$(date %Y%m%d).md mkdir -p $CAVEMAN_ROOT/99_meta/reports echo # 本周完成事项汇总 $REPORT_FILE echo $REPORT_FILE grep -r ^- \[x\] $CAVEMAN_ROOT/10_projects $REPORT_FILE || echo 本周还没有完成事项。 $REPORT_FILE echo echo 周报已生成: $REPORT_FILE echo 打开查看本周成果: open $REPORT_FILE这个脚本用到的核心技术点其实是grep -r ^- \[x\]这一行。它的作用是递归搜索所有项目目录下的Markdown文件中匹配“已完成”复选框格式的行并把它们全部汇入周报。这里的引号和转义需要注意方括号在正则里是字符类符号所以要写成\[x\]来匹配字面上的方括号。第一次写这个脚本时我忘了转义结果匹配到了所有复选框行周报里全是未完成任务看上去像一份失败总结。上述脚本在不同环境里日期参数不一样macOS的date命令用-v-7dLinux的date用-d -7 days。我在这段脚本里加了双方式兼容的判断跑不通时会自动回退。这种跨平台兼容对常用双系统的人来说很实用也是踩过坑以后总结出来的。3.4 移动端的低成本接入方案很多人问这套基于桌面端文件系统的体系出门在外怎么办手机上的碎片时间其实才是捕捉信息的高发场景。我的解决方案不依赖任何特定App思路是把“捕捉”这一步拆出来。手机端只需要装一个可以创建文本文件并写入同步盘的App。目前主流的同步盘客户端都支持在App内新建文件只是入口通常藏得比较深。更便捷的方法是把inbox对应的同步文件夹放到手机桌面的快捷入口上。即使没有第三方编辑器直接用系统自带的备忘录功能临时记录每天回来后在电脑端统一转移到caveman系统里。这里有一条铁律需要反复强调不要试图把手机的碎片信息和主系统做实时深度同步。手机端只负责“入”不负责“理”。重要的不是每一条信息都被及时分类而是所有信息最终都汇入同一个入口inbox然后由桌面端的每日或者每周清理过程完成分类。一旦你把“实时整理”的预期加进去这套系统的操作成本就会上升很容易坚持不下去。3.5 版本控制时机只在有意义的节点介入前面提到主要靠同步盘完成版本管理但某些关键节点上Git的介入价值非常大。我采用的方案是每月手动提交一次或者在每次大版本改写时提交一次。具体来说每月末的清理节点对caveman目录执行一次Git提交commit message写成当月的时间区间和主题比如“2025-01归档和清理”。这样做的意义在于阶段性快照。如果某个月的笔记被误删或者同步盘出了故障可以靠Git恢复到一个月前的完整状态。损失最多一个月的数据这在个人知识管理里完全可以接受。日常的高频修改不纳入Git因为大量的大部分修改是零散的临时文件每一次都写message会打断节奏而且同步盘本身已经有实时备份的能力。这个“分区而治”的思路非常关键实时保护靠同步盘阶段性快照靠Git两者各司其职不叠加、不冲突。4. 常见问题与排查技巧实录4.1 多设备同时编辑导致的同步盘文件冲突这套系统在使用中最常见的问题就是桌面端和手机端同时打开同一个文件两边都编辑了然后同步盘生成了一个类似文件名 (冲突的副本).txt的文件。这类冲突文件本身无害不占多少空间但堆积多了会让目录变乱也会干扰搜索。排查思路其实很简单首先判断冲突文件是否包含重要改动。如果只是手机端记录的一条碎片而桌面端进行过大规模整理那冲突文件里的手机端内容大概率已经被包含在inbox里了可以直接删。如果确认冲突文件里有桌面端没有的内容就需要手动合并——通常是把多出来的内容剪切到主文件的末尾。我总结了一套规避策略给不同设备划分明确的“写入边界”。手机端只允许写00_inbox下以m_前缀开头的文件桌面端主要负责其余所有文件的整理和编辑。这种物理上的“隔离”直接把冲突概率降低了九成。同步盘的使用手册里未必会教你这个技巧但实际体验下来极其有效。4.2 文件越堆越多搜索开始变慢怎么办文本文件的好处是几乎不会有性能瓶颈但当你积累到上万个小文件时跨文件搜索的体验还是会变差。我经历过一个阶段每次想找一个半年前的笔记都要在文件管理器里翻很久因为文件名记不完整。解决办法分两层。第一层是最简单的给关键文件做索引在99_meta下维护一个INDEX.md手动登记高频访问的文件路径和用途。这个索引文件本身也是一份笔记维护成本约为每周几秒。第二层是用命令行搜索工具替代文件管理器的内置搜索。系统自带的grep -r就能处理多数场景我更推荐用ripgrep因为它默认忽略隐藏文件和二进制搜索速度明显更快语法还兼容。如果你对命令行不熟也可以直接在目录外部的在线搜索框里直接输入关键词效果比手动翻目录快很多。更深一层的体会是如果经常翻不到某条笔记问题通常不在搜索工具而在分类体系。说明当初归档时没有找到准确的位置或者这条笔记根本就应该删掉。遇到这种情况我会顺手调整一下目录设计而不是死磕搜索技巧。4.3 长期坚持的核心开关降低所有的操作阻力很多初试这类方法的人反馈最多的问题是“坚持不下来”。我觉得核心原因不是方法论有问题而是他们把系统设计得太复杂了。如果每天打开目录就已经花费心思那这个系统迟早会被抛弃。我自己有几个降低阻力的具体手段。一是把最常用的操作做成别名。比如在shell里设置alias inboxcd ~/caveman/00_inbox敲四个字母就能进入收集箱。二是确保任何设备上都有一个全局可见的入口。我把caveman根目录做成了桌面快捷方式桌面上只留这一个文件夹图标其他文档一律归档。三是允许系统变乱但设置一个“不乱底线”inbox里的文件数量一旦超过二十个立即执行一次清理。不要追求每天都清爽追求的是每次清理都能在半小时内完成。4.4 非技术用户的接入姿势不写脚本也能用写脚本确实提升了效率但如果你不会写代码或者不想碰终端这套系统的核心框架依然完全可用。所有脚本扮演的角色都只是“加速”没有脚本手动建文件、手动汇总表格也完全可行。唯一的区别是每周回顾时可能需要花十分钟手工翻目录。我建议非技术用户先不要碰脚本老老实实用目录文本文件的方式跑两周。两周后如果觉得每周汇总太繁琐再照着上面的脚本抄作业。从经验来看大多数人真正无法接受的是“失去图形界面的安全感”一旦适应了文本的简洁直接反而会觉得那些花哨界面才是多余。另一个不写脚本的替代方案是把同步盘的文件夹挂到云服务的网页端在电脑上用网页上传文本文件而不是本地的文字编辑器。所有操作都发生在云端同步盘的目录结构里对系统资源的消耗极低也能规避“命令行恐惧”。5. 扩展方向与进阶玩法5.1 从任务管理延伸到知识输出当任务和日志跑顺之后caveman目录里会沉淀出大量素材。这些素材直接用于创作会非常自然。比如我在日志里记录了每天遇到的问题和解决思路这些内容本身就是文章大纲。每月清理时我会扫一遍当月日志把“问题与想法”段落里写着“这事值得展开写”的内容标记出来它们会进入一个独立的ideas.md文件。这个文件的用途是素材池而不是待办清单。不需要刻意为每条想法设定完成期限只需要确保它在归档时没有丢失。等到某一天需要产出内容时从素材池里挑三到五条互相关联的记录就能拼出一篇有真实案例支撑的文章。这种输出方式相比传统“凭空列大纲”更有底气因为每条想法背后都有对应的实操记录。我自己的大部分工作复盘文章都来自这个渠道。5.2 用纯文本历史生成时间线时间线的概念在知识管理里很容易变成花哨的图表但在caveman体系里你可以用极简的方式实现它——直接利用文件名的日期前缀。假设你的每个项目日志都命名为YYYY-MM-DD.md格式那么你只需要定期执行一次文件夹内全部文件名的遍历就能得到项目的完整时间线。写一个简单命令可以做到ls带排序参数或者find输出文件名列表看起来就像项目日志目录的目录列表。我每季度会做一次这件事把全年按照时间的顺序浏览一遍相当于给自己做了一次“季度回顾的回顾”。这个是真正的数据沉淀不需要额外的数据库或标签系统。因为文件系统的命名规则本身就足够表达时间维度。5.3 和其他工具的协作而不被绑定最后的进阶思路想聊“元能力”——这套体系之所以是可靠的恰恰因为它不绑定特定工具。在caveman框架里任何编辑器、任何搜索工具、任何同步盘的客户端都只是“实现层”。如果一款文本编辑器用起来不顺手你可以换掉它而不影响任何数据如果一个同步盘停止服务你只要把整个目录拷贝到另一个同步盘就行不存在数据迁移问题。我最近就做了一次类似的迁移实验把整套caveman目录从系统自带的云同步切到了自建的同步方案由于底层就是普通文件夹整个迁移过程就是一次复制粘贴耗时不超过五分钟。换作任何专有格式的知识管理软件要实现这种无损迁移至少需要一个下午。这种自由度就是当年选择“返祖”路线时最值回票价的部分。根据我个人的实操体会caveman模式的真正门槛从来不是技术难度而是你是否愿意接受“简单的工具系统”带来的一点笨拙感。它没有炫目的看板视图没有智能提醒没有AI标签。但它给你的是一个可以用二十年的稳定基座以及完全归你自己掌控的信息主权。如果你也厌倦了在各类工具之间反复切换推荐认真尝试一下这套回归原始的方案也许会发现少即是多的老话在数字时代依然管用。