把项目命名为caveman是因为我受够了那些动辄要数据库、要云端协同、要插件生态的信息管理工具。caveman的意思就是回到穴居人时代不需要复杂的火种技术也能把日子过明白。我做的不是某个花哨APP而是一套基于纯文本文件、Git和命令行工具的本地知识管理方案整套东西就叫caveman。它解决的问题很具体笔记越记越乱、工具越用越重、内容被平台绑架。如果你受够了Notion的卡顿、印象笔记的层级混乱又不想一上来就折腾自建Wiki这篇文章应该对你有用。我会把设计思路、目录结构、同步方案、踩坑记录全部摊开讲保证你照着做也能搭出自己的版本。1. 为什么我要用“穴居人”的思路做信息管理1.1 工具变重内容反而越来越难找先说个很现实的现象市面上的主流笔记工具功能一个比一个多数据库、看板、白板、插件市场、协同编辑恨不得把整个办公室塞进一个侧边栏里。但真正用起来的时候我发现自己80%的操作仍然只是“记一条想法”和“找回一条旧记录”而已。Notion打开要转圈页面嵌套五六层每次想找一个半年前的项目笔记得先回忆当初把它放在哪个Workspace、哪个Page、哪个Database里。这种成本已经超过了工具带来的收益。caveman的思路正好反过来不提供任何花哨结构只用文件夹、文件名、纯文本。你不需要学习数据库关系不需要理解权限模型甚至连Markdown语法都可以只用最基础的几个符号。它就是个“洞穴”里面有墙目录有壁画文本文件你要做的就是把信息刻上去然后能随时找到它。1.2 数据只归自己永远不会被“迁移”绑架用在线工具最让我不安的一件事是导出。今天在某个平台里写了三千条笔记明天平台改了收费政策或者某天服务停止运营你就会发现自己花几年积累的内容变成了一堆无法直接带走的格式。就算能导出也往往是JSON、HTML这种需要二次处理的产物。caveman从头到尾就是纯文本目录本身就是内容文件本身就是记录。想备份就复制文件夹想换工具就打开文件夹不需要任何转换。有人会问纯文本是不是太简陋了但反过来想人类能稳定读几千年的东西永远是写在石头上的、纸上的、纯文字的东西。复杂格式也许好看但只有最简单、最公开的格式才最可能长期存在。我个人备份caveman目录已经三年从没出现过打不开或者损坏的情况原因很简单它没有私有格式。1.3 学习成本几乎为零5分钟就能开始别被“命令行走天下”这类标签吓到。虽然caveman推荐用Git和命令行工具但核心规则用Windows自带的记事本也能跑通。我先说结论你需要学的只有三个动作——新建文件夹、新建文本文件、给文件取个好名字。剩下的Git、fzf、同步策略都是优化体验的附加项不是必需品。这也是它叫“caveman”的另一个原因哪怕你没有任何技术背景也能像一个穴居人管理洞穴壁画一样管理自己的数字信息。2. caveman的核心设计一张洞穴壁画胜过一套ERP2.1 目录结构按主题分别按时间分caveman的目录结构很老派和几十年前个人电脑时代的“文件夹管理”没什么本质区别但关键点在于“顶层分类”必须足够克制。我现在的顶层目录长这样caveman/ ├── 00_inbox/ # 临时收集还没归类的所有内容 ├── 10_projects/ # 有明确起止时间的项目 ├── 20_areas/ # 长期持续关注的领域 ├── 30_resources/ # 参考资料、文章摘录、工具文档 ├── 40_archive/ # 不再活跃但可能回看的旧内容 └── README.md # 整个系统的使用说明和索引数字前缀是我强烈建议保留的它有两个作用第一让目录按你的思考优先级排序而不是按字母排序第二给分类一个固定的“编号锚点”以后在笔记里引用时可以直接写见 10_projects/docker迁移方案.md不用粘贴完整路径。我特意没有按年份分类。试过的人应该都有体会按年份建目录找旧资料得先回忆是哪一年想不起来就只能全盘搜索。按主题分类则会稳定很多因为领域不会变项目名不会变只有时间在变。归档例外40_archive里面可以按年份再二级分因为归档层的核心目标就是“沉到最底下”年份作为检索线索在这里反而合适。2.2 一张卡片一条命原子化笔记原则caveman的一条核心方法论是“一个主题一个文件”。不是把十几条想法堆在一个叫“生活随笔”的文档里而是每一条值得记录的内容都单独建一个文件文件名写清楚主题内容只围绕这一个主题展开。这个习惯来自卡片盒笔记法的启发。为什么原子化有效因为文件越小越容易被检索命中也越容易被重新组织。拿写作举例我写一篇技术文章时会参考几十条笔记如果所有素材都堆在一个大文件里引用时就得不断滚动翻页最后大概率因为找不到而放弃使用。而原子化之后每个素材都是一个独立文件用fzf输入关键词一秒就能定位到准确的那张卡片。大文件的诱惑很难抵抗因为把东西全放在一处会给人一种安全感。但实际操作下来超过500行的大文档基本会沦为墓地内容还在你永远不愿意打开它。caveman鼓励的是“写短文件”如果一个文件写完了超过200行就要考虑拆分成多个卡。2.3 文件名就是检索入口原子化笔记配合了一套可预测的文件命名格式这是caveman里我花时间最多的地方。目前使用的格式是YYYY-MM-DD_主题关键词_备注.md举例2025-04-12_用ollama跑本地大模型.md 2025-04-12_docker备份策略_不包含镜像缓存.md 2025-04-11_syncthing同步失败排查.md日期放在最前面解决的是时间轴检索问题主题关键词放在中间解决的是语义检索问题备注字段用于区分同一天、同主题下的不同笔记。这样排序后同一天的笔记会挨在一起同一个主题的笔记也会因为关键词相近而被搜索到。不用UUID之类的随机文件名因为可读性太差。caveman本身就崇尚简单文件名就是要给人看的不是给数据库用的。2.4 内容格式的克制正文格式我建议只保留五样东西标题、列表、链接、代码块和引用块。表格能不用就不用图片尽量丢到assets/目录里用相对路径引用别往正文里塞base64。为什么这么克制因为纯文本文件最大的优势是任何环境都能打开一旦内容里嵌入大量HTML、内联图片、复杂表格插件就又开始依赖特定渲染器等于变相抛弃了纯文本的普适性。我见过有人用Markdown写了一个带高亮、流程图、图标的“豪华笔记”结果换一个编辑器打开时排版全崩。这个系统叫caveman不是“史前艺术馆”能传递核心信息就够了。3. 实操记录从零搭一个属于自己的caveman3.1 初始化目录和忽略规则搭建过程其实非常短先创建目录结构mkdir -p caveman/{00_inbox,10_projects,20_areas,30_resources,40_archive,assets} cd caveman git init如果你用macOS或Linux把上面这段直接跑起来就有底子了。Windows用户打开PowerShell也能执行或者干脆手动建几个文件夹。注意assets目录我放在了caveman根目录下用来统一存图片、PDF等二进制文件因为Git对文本文件友好对二进制文件不友好单独放方便以后用.gitignore或Git LFS控制同步范围。.gitignore文件建议在第一次提交前就写好.DS_Store Thumbs.db *.tmp .obsidian/ .idea/ .vscode/现在很多人会用Obsidian打开caveman目录但Obsidian会在目录里生成自己的配置文件。这些配置只对本地有效放进Git里只会制造噪音所以直接忽略掉。3.2 用Git做版本管理和自动备份caveman最让我安心的部分是Git版本管理。每次修改完笔记后执行两次命令就能留下一个快照git add -A git commit -m 更新日志如果你连这个都嫌麻烦可以写个简单脚本save.sh#!/bin/bash cd $(dirname $0) git add -A git commit -m $(date %Y-%m-%d %H:%M) 自动备份然后用cron或系统的定时任务每30分钟执行一次等于给自己配了一个自动存档点。回到Gitea、GitHub、GitLab都支持定时拉取也可以把这个脚本挂在NAS里跑。版本管理的最大价值不是“防硬盘损坏”而是给你犯错的勇气。以前用在线文档时代我敢随手写随手删是因为知道云上有历史版本。现在caveman给了我同样的能力而且历史版本存在本地Git库里不依赖任何云服务。一次误删文件直接git checkout -- 文件路径就能恢复。3.3 多设备同步的两种路线先说结论不要用网盘同步caveman目录。网盘一般不做冲突合并两台设备同时修改同一个文件最后会生成一堆“xxx冲突副本.md”比不同步还乱。我试过各种方案后留下了两种相对顺手的同步路线。路线一私有Git仓库。如果你有一台常开的服务器或NAS在它上面建一个裸仓库然后本地仓库把这个仓库设为remote。这样手机、电脑和平板都能通过Git拉取和提交。好处是保留完整历史缺点是移动端提交没那么顺手需要App支持。路线二Syncthing。这是一个点对点同步工具不需要中央服务器两台设备直接相互传文件。Syncthing的优势是实时同步移动端也有App适合快速记录场景。代价是它不做版本管理配合Git使用更稳也就是“同步靠Syncthing历史靠Git”。我个人现在是这个组合电脑和手机之间用Syncthing实时同步服务器上有一个Git裸仓库负责保存历史版本和冲突兜底。这套组合跑了一年多没有出现一次数据丢失很值得推荐。3.4 移动端怎么配合移动端的定位是“快速捕捉”而不是“深度编辑”。我用的是Android手机装了Syncthing和Markdown编辑器解锁后直接把语音转文字或手打的想法丢进00_inbox/等回到电脑前再统一整理。如果你用iPhone思路也一样找一个支持按文件夹打开本地Markdown文件的App不需要它自带同步把文件夹关联到Syncthing的本地路径就行。千万别在移动端安装一堆全套笔记软件那样又回到工具越用越重的老路。caveman的原则永远是移动端负责“抓”桌面端负责“理”。4. 真实踩过的坑与排查速查表4.1 文件多了之后fzf变慢caveman用了半年后文件数量超过两三千个这时候启动fzf会出现明显卡顿尤其当目录里有大量.node_modules或构建产物时慢得让人怀疑人生。排查后发现不是文件太多而是fzf没有排除那些根本不该搜索的目录。解决方案很简单在fzf配置里指定搜索路径和排除规则export FZF_DEFAULT_COMMANDrg --files --hidden --glob !.git --glob !node_modules --glob !assets/*.pdf如果你用的是ripgreprg这一条命令就能让搜索性能提升数倍。另外建议把40_archive/也列入排除规则归档的内容大多数时候知道具体名字不需要全局模糊搜索。4.2 中英文混合内容的检索问题我一开始用fzf默认算法发现对中文关键词匹配做得还行但对“中英混排”的文件名会出现漏匹配。比如文件名是用Ollama跑本地模型.md搜“ollama”能命中但搜“本地大模型”可能会因为分词不准而漏掉。后来我改成fzf的模糊匹配并启用--algov2同时养成一个习惯文件名里同时写中文关键词和英文专有名词。搜索时用英文命中阅读时靠中文理解两者互为补充。对于纯中文的搜索需求fzf配合rg其实已经够用不需要额外搞搜索数据库。4.3 图片和附件到底怎么放这是我最开始踩得最惨的坑。最早我把图片直接放进Markdown文件对应的子目录里结果同一张图被两篇笔记引用时只好复制两份副本后续想改图又要改两个地方。最终的统一规范是所有附件都放caveman根目录的assets/下面按照内容类型继续分子目录比如assets/images/、assets/pdfs/、assets/videos/。正文里使用相对路径引用注意相对路径是从当前笔记文件出发计算的不是从caveman根目录。所以建议每层笔记目录的层级深度保持一致比如都固定在10_projects/xxx/下减少路径计算的麻烦。这个规范看起来简单但如果一开始不定好后面改起来会累死。4.4 敏感内容的加密处理caveman整体是纯文本纯文本有一个天然问题一旦设备丢失或同步泄露内容等于裸奔。我的做法是最敏感的信息不直接进caveman比如密码、密钥、证件号这些统一交给专门的密码管理器。如果只是“有点敏感但不太重要的内容”可以用GPG对单个文件加密gpg -c --cipher-algo AES256 2025-04-12_银行相关记录.md执行后会生成一个.gpg文件原来的纯文本文件可以删除。需要查看时再解密到临时文件看完后立刻删除。这套流程不复杂但对防止同步过程中的泄露已经足够了。记住不要在caveman的明文里写密码即使有加密方案明文本身就是风险。下面把我遇到的高频问题整理成速查表方便你以后对照排查。问题现象可能原因处理建议同步后出现“xxx冲突副本.md”两台设备同时修改同一文件用Git进行手动合并保留修改较完整的一方fzf搜索变慢搜索范围包含了依赖目录或归档区用rg glob排除归档区从默认搜索中移除Windows下打开文件乱码文件不是UTF-8编码或带了BOM全部统一为UTF-8无BOM旧文件用编辑器转换引用图片显示不出来相对路径写错确认当前笔记在哪一层目录按实际层级计算../../Git提交历史出现大量垃圾配置忽略了.obsidian/.idea等目录把工具配置目录全部加入.gitignore移动端编辑后内容丢失没有等Syncthing完成同步就关后台编辑后稍等几秒确认同步完成再切换设备5. 关于caveman这套做法的边界和延伸5.1 哪些场景真的不适合caveman不是万能方案有些场景用它就是自找麻烦。比如需要大量结构化查询的数据库型内容类似图书管理系统、客户台账、库存记录这种数据天生该用表格、数据库或专门的App硬塞进纯文本只能收获痛苦。再比如多人实时协同编辑纯文本文件加Git确实能做版本合并但对非技术背景的协作者来说学习成本偏高还不如用成熟的在线文档。此外如果你是一个重度多媒体内容创作者每天要处理大量照片、视频素材caveman的纯文本目录管理思路可以借鉴但没有必要把多媒体文件全部塞进来。资产目录单独存放笔记里只保留引用这才是合理的分工。5.2 能做的轻量扩展caveman最好的一点是扩展性完全掌握在你手里。我用它做过的延伸包括用todo.txt格式维护一个20_areas/40_待办事项.md配合简单的模板脚本生成每日清单。写一个Python脚本定时扫描00_inbox/里的文件根据文件名关键词自动移动到对应顶层目录。用pandoc把某个项目下的所有Markdown笔记拼接输出为HTML或PDF生成一个简单的项目报告。把整个caveman目录用静态站点生成器比如MkDocs渲染成一个本地Wiki方便在浏览器里阅读。这些扩展都不会破坏核心结构因为它们只是在纯文本的基础上做“读取”和“转换”不会把内容绑死在特定工具上。这也是最初选择“穴居人”思路的原因给自己留一条永远可以退回去的简单路。最后再多说一句caveman这套东西真正改变的其实不是技术而是我面对信息的态度。过去我花了很多时间整理工具整理模板整理插件最后真正读进去的知识却没多少。换成纯文本目录之后我每天只做三件事丢进收件箱定期整理需要时搜索。没有排行榜没有视图切换没有未读红点。内容回到它本来该有的样子写在墙上的字落在地上的石头。这个项目很小但它让我重新拿回了对信息的控制权。如果你也想摆脱“工具当主人”的状态建议从今天开始建一个caveman目录丢第一条笔记进去试试。