caveman极简工作流：从终端编辑器到专注力回归

“caveman”这个词，我第一次看到时以为说的是游戏里的穴居人，直到我试用了一个也叫这个名的终端文本编辑器，才意识到它真正代表的是那种“回到最简单状态”的设计取向：界面近乎空白，功能全靠快捷键调用，没有图标，没有菜单，没有花哨动画。这几年我越来越认同这个方向，因为被各类重型软件反复折磨之后，你会发现真正稀缺的不是功能，而是专注力。这篇内容不是单纯给你安利某个工具，而是想把我用“caveman”这套极简思路重建个人项目工作流的过程和教训完整讲出来，适合那些觉得工具太重、想精简流程、又不想牺牲效率的朋友参考。

1. 为什么“原始”反而成了最聪明的选择：caveman 理念的底层逻辑

1.1 信息过载与工具疲劳：现代人的时间都去哪了

先做一个简单的回顾。你打开电脑，计划写一篇文章或者跑一个脚本，实际发生的顺序往往是这样：先看到桌面上一堆图标，犹豫了一下打开哪个；然后某个软件自动弹出更新提示，你顺手点了“稍后”；接着发现某工具昨天还能用，今天连不上服务了；最后真正要干活的时候，已经过去二十分钟，你甚至想不起来自己最初要做什么。

工具疲劳不是错觉。当你的工作环境里堆积了大量“看起来有用”的软件时，每一个都在消耗你的注意力——后台进程消耗内存，图标抢占视觉焦点，弹窗打断思路，更新包频繁打断操作。我们以为自己在“用工具”，实际上是在花时间“维护工具”。caveman 理念的出发点就是：把这种隐性消耗降到最低，让工具退回到背景里，让任务走到前台来。

我在实际体验中感受最深的一点是：当界面上只剩下待编辑的文本和几个必要的状态信息时，大脑反而更容易进入深度状态。这跟“少即是多”的哲学无关，纯粹是认知资源的分配问题——人的注意力是有限预算，多一分分给界面，就少一分留给内容。

1.2 极简主义不是简陋，而是精确：caveman 的三大核心原则

很多人误解极简主义，觉得就是把东西全删光、退回到一个功能贫瘠的状态。但真正有效的极简从来不是“少”，而是“精确”。caveman 风格的实践，我总结下来有三条核心原则：

第一，低依赖。一个工具尽量少依赖外部环境。你想用的编辑器，最好打开就能用，不用配一堆运行库、插件框架、主题引擎。低依赖意味着低故障率，也意味着将来换任何一台机器，你都能快速进入工作状态。

第二，高回报。每一项保留的功能都应该直击日常工作的高频需求。比如在终端编辑器里，你要的不是缩略图、拼写检查、AI 助手，而是快速定位、批量替换、多文件跳转，这些天天用的能力必须做到极致。

第三，可迁移。caveman 式的工作习惯不绑定特定平台、特定品牌或特定图形界面。你用一套快捷键和配置思路，换什么环境都能立即适配。这就像是练了一套基础拳法，而不是记住了一堆复杂的连招。

这三条原则放在一起其实就回答了一个问题：为什么要用原始的方式做现代的事？因为原始的部分往往经过了长时间验证，适应性最强，在大部分场景下都不会掉链子。

1.3 从工具到哲学：同名软件背后的设计风向

以那个叫 caveman 的终端文本编辑器作为一个具象案例来看，它把极简理念执行到了几乎苛刻的程度：没有图形按钮，没有鼠标交互界面，甚至没有默认的插件集。你打开它就是一个纯文本界面，配合快捷键完成几乎所有操作。要改配置？用命令或者改配置文件，不像某些大型编辑器那样弹出一个五层深的设置面板。

一开始你可能觉得这太不方便了，但用上一段时间后你会发现，这种体验有神奇的“聚焦感”。因为你不去管窗口怎么分、主题怎么换、插件怎么排，你眼里就只有一件事：正在写的那段内容。这也正是近几年越来越多终端工具受欢迎的原因——并不是开发者想返祖，而是重型图形界面的边际效益在下降，大家开始追求工具链的“轻量化纯度”。

从我的个人项目经验来看，这种设计风向已经辐射到了笔记、任务管理、甚至写作排版领域。很多人开始刻意选择文本格式而非专有格式，选择快捷键而非菜单，选择本地文件而非云端绑定。背后的心理动因都是同一个：不想让工具成为负担，想重新拿回对自己时间和注意力的掌控权。

2. 用“caveman”思路筛选工具：我留下的 5 类和扔掉的 10 类

2.1 工具筛选的四个标尺

我清理过一次自己的电脑和线上服务，过程挺痛苦的，但也特别清醒。当时我给自己定了四个标尺，任何一个工具必须同时满足至少三条，否则就进“待淘汰区”。

标尺一，学习成本是否足够低。这个低不是说“打开就会用”，而是“成长曲线值得”。像终端编辑器这种工具，初期要记快捷键，表面上学习成本高，但一周后效率曲线直线上升，属于典型的低总成本。反过来有些图形工具看起来很友好，但深层功能要记菜单路径、记图标位置，实际总学习成本反而更高。

标尺二，维护成本是否可控。工具是否频繁更新、频繁破坏配置？是否需要你不断处理兼容问题？如果一款软件每两周自动更新一次、每次更新都改界面布局，那么无论它功能多强，长期持有成本都很高。我用过某笔记软件，更新一次丢一次排版，后来彻底弃用。

标尺三，数据是否可迁移。你存在这个工具里的数据，能不能轻松导出成通用格式（纯文本、Markdown、CSV）？如果数据被锁死在私有格式里，迁移成本就会高到让你一辈子被绑定。这是我很早就学会的教训：极简不等于闭关，反而意味着你必须给自己留好退路。

标尺四，是否解决单点问题。工具是否有一个明确不可替代的核心用途？比如终端编辑器解决“本地大量文本的高效处理”，闹钟 App 解决“准点提醒”，如果一款工具什么都能做一点但什么都不精，它在工作流里的存在感就会模糊，最后沦为注意力黑洞。

这四个标尺我现在仍然在用。每次想装新工具，先过一遍这四项，能避免八成以上的“工具收藏癖”。

2.2 精简后的工具清单与淘汰清单

我最终留下的核心工具其实就五类，列表如下：

再看被淘汰的名单：自带移动端却不自重的“综合办公套件”、以画布为卖点的“灵感白板”、号称智能但需联网的“AI 笔记”、社交属性过重的“团队协作聊天工具”、每季度更新界面的“设计协作软件”、框架重一次的“本地文档系统”、必须登录账号才能打开本地文件的“云编辑器”、自带广告推送的“免费压缩工具”、内置一堆用不上的“影视剪辑入门版”，以及最后一个——那些“为了管理工具而下载的工具管理软件”。

淘汰它们的理由高度一致：工作中实际用到的功能占比不足两成，但维护它们消耗的时间超过半数。

2.3 为什么把图形界面换成命令行反而更快了：效率错觉的真相

很多人觉得命令行反直觉、不够直观，但“直观”这个词本身就有误导性。图形界面的直观体现在“看到就知道能点什么”，命令行思维的直观体现在“想到什么就直接执行”。后者在任务明确时，速度快到前者无法比。

举个实际例子：我要把某个目录下所有.tmp文件删除，并且把剩余文件按文件名前缀分组，图形界面处理可能要新建文件夹、框选、拖动，操作步骤多得吓人。在命令行里一句话就完了。这不是炫技，这是把“意图直接转化成动作”，中间不经手眼协调的多重切换。

我在实践 cafeman 风格的工作流之后发现，效率的提升最明显的其实不是编辑本身，而是“切换任务”的速度。图形界面里切换窗口、翻菜单、点按钮，每一次要花三五秒，看似不多，但每天几十次累积下来就是十几分钟被吃掉。而终端工作流里的切换几乎零成本，大脑无需重新适应。

3. 实操案例：从零搭建一套“caveman 式”个人项目工作流

3.1 环境准备：先明确边界，再动手

搭建之前，第一件事不是安装各种工具，而是划定使用边界。我当时问了自己三个问题：我在什么场景下使用这套工作流？我最高频的输入输出是什么？我愿意投入多少时间去学习配置？

我给的答案是：日常写作、轻量脚本开发、读书笔记整理。最高频动作是“打开文件→编辑→保存→查看结果”。愿意投入的时间是初次三个下午，后续随用随调。这些边界条件决定了我不需要复杂的编译环境，也不需要图形界面的项目面板，更不需要在线协作功能。

划定边界之后，我开始搭建目录结构。这个步骤特别重要，很多人的目录一团乱就是因为一开始没定规矩。我用的是一套极简目录规则：notes/放所有文字类内容，按年份和主题建子目录；projects/放所有代码项目和工程文件；archive/放已完成或不再使用的旧内容。目录命名一律小写加短横线，坚决不用空格和中文目录名——这不是崇洋媚外，是为了在命令行和脚本处理时少踩坑。

3.2 核心步骤：建立输入输出闭环

我按照“输入→处理→输出→归档→回顾”五个环节来搭流程，每个环节只用一到两个工具，目的是让内容像流水线一样自己流动。

输入环节，灵感、待办、想法全部先落在一个统一收件箱文件里。这个文件就是一个纯文本笔记，用固定的格式记录日期、标签和内容。为什么要统一落在一个文件里？因为如果灵感落在不同的软件里，整理的时候就要满世界找。集中到一个地方，收集本身零成本。

处理环节，我每天早晚各花十五分钟，把收件箱里的内容分类：能立即执行的排进待办清单，需要深入思考的转到笔记或写作文件，没用的直接删除。这个“定期清空收件箱”的习惯是整个工作流的润滑剂，如果不是每天清，积累三天后你就会开始逃避它。

输出环节，写文章、写代码或者整理内容，全部在终端编辑器里完成。这一步的关键是形成肌肉记忆的快捷键组合，比如快速保存、快速查找、快速跳转。不用贪多，刚开始记住五到八个就够了，后面按需再加。

归档和回顾环节，每周日花半小时，把已经完成的项目文件移动到archive/里，同时扫一眼这一周的笔记，标注重点内容。归档的意义不只是整洁，更重要的是让当前工作区始终轻盈，打开projects/目录看到的都是进行中的事，大脑的思路也会更清晰。

3.3 自动化与脚本化：把重复劳动压缩到一行

搭建最原始的骨架之后，我开始琢磨哪些环节可以用脚本批量处理。这里说的脚本不是什么高深技术，就是一些能自动做“复制、移动、整理、重命名”之类重复操作的小工具。

举一个我经常要用的场景：我从网页或者别的地方复制了一段文字到本地剪贴板，但终端编辑器默认不支持直接粘贴富文本，会带一堆格式符号。我写了一个简单脚本，专门做“剪贴板文本清洗”，把多余的空行、制表符、HTML 残留符号全部清掉，再以纯文本形式插入到当前光标位置。这个脚本改变了我的写作体验，因为它让“从别处拿内容进来”这件事变得丝滑了。

另一个高频操作是批量创建新文件。我写了一个小脚本，接受“日期、类型、标题”这三个参数，自动在对应目录生成带标准头部信息的新文件，并按日期命名。这样我写一篇新文章或者新笔记时，不用手动建文件、填日期，运行一个命令就直接进入编辑状态。

做自动化的原则是：只在“重复出现且完全一致”的操作上脚本化。如果一个任务每次的流程都不太一样，脚本反而会变成限制。先手动做十次，如果第十一次你还在复制同样的命令，那才值得脚本化。

3.4 参数选择的思路：以配置一个可复用的极简环境为例

有朋友问我，你是怎么决定哪些功能要保留、哪些配置项要调优的？我觉得关键是“从使用场景倒推配置参数”。

比如我需要经常查看代码文件的结构，所以开启“代码折叠”和“行号显示”这两个参数。但我不需要自动补全括号这种功能，因为我写文章时经常用到中文标点，自动补全反而碍事。再比如颜色主题，我选的是十六色默认终端配色，而不是花里胡哨的 256 色主题。为什么？因为十六色在几乎所有终端环境里都稳定显示，换到远程主机或者别的电脑，界面不会崩坏。追求炫彩主题，本质上是在给环境切换埋雷。

字体和字号的选择也一样。优先等宽字体，确保中文和英文混排时的对齐不混乱；字号在终端里不用特意调，跟随系统即可。这些细节看着很小，但日积月累，决定了你愿意不愿意天天用它。

配置参数有一个总原则：能不动就不动，动了必须知道为什么。每次调整配置前先问自己，这个调整是为了解决某个真实痛点，还是单纯觉得新鲜、想折腾？如果是后者，那就别动。

4. 实践中踩过的坑：极简主义的 5 个真实误区

4.1 踩过的坑之一：极简不等于反工具

我开始推行 caveman 工作流时，一度走火入魔，觉得所有图形软件都是敌人，恨不得把所有操作都搬进命令行。结果呢？某些 GUI 工具在特定场景下就是更高效。

举个例子，我用终端编辑器处理 Markdown 文档很顺手，但当我需要浏览几百张图片并快速筛选出合格素材时，终端根本不如一个简单的图片浏览器来得直观。非要用 ocaml 写个脚本用输出文件名列表来筛选图片，那是自己给自己上刑。

这个坑的本质是混淆了目的和手段。极简的目的是少消耗注意力和精力，而不是把工具数量降到零。只要那个工具能在一个环节上明显提升效率，它就是合格的工具，用就是了。极简工作流不是戒断工具，而是每个工具都有明确存在的理由。

4.2 踩过的坑之二：为了少装软件而手动重复劳动

有一次我需要批量重命名一组文档，大概九十多个文件。我脑子一热，觉得不该为了这点事去找专门的改名工具，就准备手动一个一个在终端里敲mv命令。敲到第十个的时候我停下来了，意识到自己正在用极度宝贵的时间去交换一个本来就不存在的“洁癖”。

后来我写了个三十行的脚本，两秒就把事情办完了。这个坑给我的教训是：极简省下的是决策成本和维护成本，不是省下自动化工具。能用脚本或现成小工具解决的事情，坚决不要手动做。手动重复劳动看起来“不需要额外工具”，但它的时间消耗是巨大的，而且毫无价值。

4.3 踩过的坑之三：配置地狱

这个坑是几乎所有终端工具使用者都会掉进去的。本来想搭建一个极简编辑环境，结果打开配置文件的瞬间就忘了初衷——调缩进、调高亮、调快捷键、调主题、加插件、换前端渲染方案，一投入就是一个通宵。一天过去了，文章一个字没写，编辑器倒是被调得像一个艺术品。

我用我自己的血泪教训给你两条建议。第一，从默认配置开始用，至少真实使用两周再考虑改动。第二，改配置要带着任务来改，比如“我在写文档时觉得折叠代码不方便”，而不是“我看到别人的配置里有什么新技巧”。带着真实痛点去改配置，每一条改动都是有效的；漫无目的地折腾，只会给自己建一座越来越复杂的配置堡垒。

4.4 踩过的坑之四：与他人协作时的“传教心态”

用上极简工作流后有一段时间，我特别想按头安利给全组同事——这个编辑器多好用啊，那个命令行多快啊！但是实际协作起来发现，别人用的是另一套图形工具，他们的文档模板、评审流程、交付格式都是围绕原有工具建的。我非要坚持用自己的套路，结果就是文档转换成本直线飙升，双方都在迁就对方，效率反而下来了。

现在我的原则是：个人工作流内部保持 caveman 式的极简，但对外接口保持最大程度的兼容。也就是说，我内部怎么写、怎么管，那是我的事；但提交给别人的成果，必须按照对方熟悉的格式来。工具是私事，交付是公事，两者要分开。

4.5 踩过的坑之五：把极简本身当成新的负担

好工具是用出来的，不是调出来的，也是“为极简而极简”最容易翻车的地方。我曾经花时间研究“如何减少花在工具上的时间”，听起来很讽刺，对吧？但这个坑真的存在。

当你开始迷恋最小化方案本身，你会不断否定现有方案去找更小的替代品，光是找本身就已经在消耗时间了。我建议大家把工作流当成一个家来经营：家具不用频繁换，位置不用天天挪，只有当家里出现了明显的“不好用”的别扭感，才值得动手调整。稳定下来之后，这种稳定本身就是效率。

5. 遇到问题如何快速排查与调整

5.1 一个基于实际体验的排查清单

新搭好的极简工作流，头一个月问题肯定不少。我整理了一份自己常用的排查清单，每次卡住了就按这个顺序走一遍。

第一，检查是否偏离了高频场景。如果某个操作你每周用不到一次，却配置了一大堆提升它效率的东西，那纯属浪费。删掉这些配置不会心疼的。

第二，检查是否出现了“单点故障”。如果你全部工作流都依赖某一个工具，而这个工具一有问题，整个世界就瘫痪了，那说明你需要一个简单的替代方案。不一定是二倍工具，但至少有一个兜底手段。

第三，检查命令和快捷键的实际记忆度。我给自己的要求是：如果连续三周没有使用某个快捷键，我就把它删掉，因为说明它不是高频动作，留着只会增加记忆负担。我的编辑器配置因此一直很精简，每个键绑定都有熟悉感。

第四，检查数据流动是否顺畅。内容从收集到处理再到归档的路径上，有没有一个环节总是卡住？卡住的环节才是需要优化的地方，不卡的地方千万别动。

第五，问自己：当前的问题是配置的问题，还是习惯的问题？很多时候配置半天没用，真正的问题是操作顺序不对或者自己没有养成固定频率。配置解决不了习惯问题，只能在习惯先建立起来之后再加码。

5.2 快速调整的三条原则

排查出问题后，调整要果断，但要遵循三条原则。

原则一，每次只改一处。一次改十处，出了问题根本不知道是哪里引起的。每次只调整一个环节，用几天时间看效果，体验好了再动下一处。这个方法在搭建环境时尤其管用。

原则二，调整必须可回退。大的改动前先备份配置文件或记录当前状态。这个习惯救了我很多次，尤其是修改编辑器配置时，改坏了直接回滚，不用浪费时间重头研究。

原则三，砍掉比新增更重要。调整时优先考虑“是不是可以去掉某一步”，而不是“是不是可以再加一个辅助工具”。这符合极简的核心逻辑——工作流里每一步都应该是必要的，而不是充分的。这字面听起来像绕口令，但做起来很实际：你犹豫一个功能该不该加，那就先不加；你犹豫一个环节该不该砍，那就先砍掉试试。

写在最后的个人体会

用 caveman 这套思路重建工作流，对我影响最大的其实不是节省了多少时间，而是重新建立了一种“我在掌控工具，而不是被工具掌控”的感觉。以前每次打开电脑，面对一屏花花绿绿的图标，总觉得被什么推着走；现在打开终端，只有光标在等我输入，这种安静感本身就让人更容易进入状态。我知道不是所有人都愿意或者适合走到这么极端的程度，但哪怕你只是减少一两个无关工具、把数据格式换成纯文本、养成每天清理收件箱的习惯，你的工作体验也会明显改变。极简不是目标，它只是一个让你离真正重要的事更近一点的手段。希望这篇内容能给你一些参考，帮你找到属于自己的那种轻盈感。