#35 工具的半衰期

2026-07-01

最近在整理手头的工具栈，突然意识到一件事——我正在用的工具里，有些已经活了三十年以上，有些三年前还不存在，有些三年前存在但现在已经死了。

Emacs，1976 年至今。Vim，1991 年至今。Unix 管道的设计，1973 年至今。它们不但没有消失，反而在五十年后比以前更有活力。

另一边，Google Reader，死了。Evernote，半死不活。无数创业公司的「革命性」协作工具，来了又走了。

.

.

.

为什么有些工具能跨越几十年，有些却活不过一个产品周期？

我观察到的规律是——活得久的工具往往有几个共同点：

■ 它是离线优先的，不依赖某个公司的服务器
■ 它的数据格式是开放的，或者干脆就是纯文本
■ 它给用户控制权，而不是把用户锁在里面
■ 它解决的是一个不会变的底层需求

反过来说，那些死掉的工具往往是：数据存在别人的云上、格式是私有的、一旦公司倒了或者改了方向，用户就什么都带不走。

.

.

.

这不是在说云服务不好。云有云的价值——协作、同步、免维护。但这些便利是有代价的。

代价就是：你和工具之间有了一个第三方。这个第三方可能涨价、可能被收购、可能改变产品方向、可能直接关停。你对自己数据的控制权，取决于一家公司的商业决策。

而那些「老工具」之所以能活到今天，恰恰是因为它们从一开始就不依赖任何第三方。Emacs 不需要服务器。org-mode 的文件就是一个纯文本。Git 仓库完整地活在我自己的硬盘上。

.

.

.

我最近在选择工具的时候，开始有意识地问自己一个问题：

十年后这个东西还在吗？

如果答案不确定，那我就要想清楚——我愿意在里面投入多少时间和数据？如果有一天它消失了，我能带走什么？

不是每个工具都需要活三十年。有些东西用来应急的、过渡的、尝鲜的，用完就走也无所谓。但那些承载我核心工作流的、存放我长期积累的东西——笔记、写作、代码、知识库——我需要它们建立在经得起时间考验的基础上。

.

.

.

工具的半衰期不是什么神秘的东西。判断标准其实很朴素：

它是不是足够简单？它依赖的东西是不是尽可能少？它的数据是不是我能读懂、能带走的？

符合这些标准的工具，往往能活很久。因为简单的东西不容易坏，不依赖别人的东西不会因为别人的决定而消失。

Unix 哲学说「做一件事，做好它」。活得久的工具几乎都遵循这个原则。

.

.

.

所以与其追逐下一个「生产力革命」，不如回头看看那些已经安静地活了几十年的东西。

它们不光彩、不性感、不会出现在 Product Hunt 的首页。但十年后打开电脑，它们还在那里。

而那些今天排在 trending 第一的工具——谁知道呢。