我有过一个让人羡慕的笔记系统。
双链、每日笔记、图谱视图、十几个插件、层层嵌套的模板。我可以告诉你我 2024 年 3 月的某个周二和哪个概念产生了链接,可以在图谱上欣赏自己思想的"星系"。这个系统如此精致,以至于我维护它的时间,渐渐超过了用它思考的时间。
后来有一天,系统崩溃在一个插件更新上。修复它的那个下午,我突然意识到:我不是在哀悼失去笔记,而是在哀悼失去那个"系统维护者"的身份。工具变成了工作本身。
极简之后,剩下什么
现在我所有的写作都是 Git 仓库里的一堆 .md 文件。加上一个编辑器、一个静态生成器,就是全部家当。
失去的东西,老实说,几乎没有:
- 搜索?
grep比任何内置搜索都快。 - 双链? 我发现在文件里写一句"参见 [[design-tokens]]",然后用 ripgrep 查反向引用,体验和图谱视图差不多——而且不会诱导我"为了连接而连接"。
- 同步?
git push。有历史、有备份、能在任何设备上继续写。 - 发布? 推送即部署。从写完到上线,一次 commit。
而得到的东西很实际:再也没有"今晚要不要重构一下标签体系"这种内耗了。文件就在那儿,十年后的文本编辑器依然能打开。
复杂系统的隐性税
复杂工具收取的税不在明处。它体现在:
- 开始的摩擦力。打开重型笔记软件,要先等索引加载、插件初始化。想记的那句话,经常死在加载进度条上。而打开一个文本文件,是即时的。
- 格式的诱惑。当工具提供五十种块类型,你会忍不住给每句话找一个"合适的容器"。Markdown 只提供一种:段落。这迫使注意力回到文字本身。
- 迁移的 dread。每次想换工具,都要面对"我那几千条笔记怎么办"。纯文本没有这个问题——它们在任何地方都是一等公民。
不是所有复杂都是坏的
公平地说,Markdown 不是万能的。需要协作、需要结构化数据、需要多人同时编辑的场景,富文本和数据库是更好的答案。我反对的不是复杂工具,而是默认选择复杂的惯性:在没有被问题真正击中之前,就先为自己配齐了全套装备。
加缪说过一句被引用滥了的话,但放在这里意外地合适:冬天到了,我才发现自己心里有个不可战胜的夏天。系统崩溃的那个下午我也发现:剥离了所有工作流之后,写作的渴望还在——它从来不在工具里。