为什么手动计时用得越久，反而越觉得累？

刚开始用一个计时 App 的时候，是它这辈子最好用的时候。三四个分类，一个开始键，一个结束键，两下就点完了，什么都不用想。半年后，同样的两下操作却变慢了，你会觉得这个 App 变"重"了，其实它什么都没变。变的是你要点进去的那份列表：以前上面只有四项，现在有二十项，选对哪一项本身，变成了每天要重复好几次的一件小事。

分类列表只会越长越长

没有人一开始就想搞出一份长长的分类表，它是一次次"合理的决定"堆出来的。"工作"这两个字，等你有了两个客户之后就不够用了，于是拆成客户 A 和客户 B。客户 A 的数字等你发现里面一半是开会一半是真正干活之后，又不够用了，于是再拆一次。某个只做了一个月的项目，会单独给它开一个分类，因为塞进"工作"里会搅乱你那个月正想看清楚的一个数字——项目结束了，分类却没跟着结束，因为删掉它，之前记在它名下的那些条目就没了着落。

单独看，每一次拆分都没做错。问题在于，计时类 App 从来没有"让一个分类体面退休"这回事，它唯一会的操作就是往上加。一年下来，你面对的是二十几个选项，像沉积岩一样一层层叠出来的——每一层单看都没问题，可它们全都还在那儿。

每加一个新分类，之前的记录都要重新问一遍

容易被忽略的一点是：列表变长，代价不是线性增加的。三个分类，意味着"这段时间该算哪类"有三种可能的答案；二十个分类，就有二十种可能，而且其中好几个现在还互相重叠——这一个小时算"客户 A"，还是更细的"客户 A：开会"？一个效率不高的下午，算"杂事"，还是新拆出来的"杂事：客户 A"？分类一拆开，以后每一条记录都要对着一张更细的网去挑选，而之前那些记在粗分类下的旧记录，也悄悄过时了——它们被归在一个你后来才决定要区分开的类别里。

这不会以一个戏剧性的时刻出现，它体现在每一次点击前那半秒钟的犹豫上——这种犹豫在第一个月是不存在的。计时器在一天里好几次，要你重新决定一套自己都还没搭建完的分类体系。

到最后，你维护的是这套系统，不是这一天

到了某个阶段，这份列表本身就需要打理了：合并两个后来发现意思其实一样的分类，给一个名不副实的分类改名，把三个属于春天那个已经结束的项目的分类归档，或者在意识到自己拆早了、拆晚了之后，把一整周的记录重新分类。这是实打实的工作，做在工具上，为了这个工具，出来的结果你以后也不会再翻看——它唯一的作用，是不让总数继续偏下去。一套本该帮你看清时间去哪儿的系统，在谁都没有刻意决定的情况下，开始悄悄吃掉一部分你的时间。

日志不会背上这种负担，因为它本来就不用凑总数

写下来的一行字没有这个问题，因为它从来不打算把什么东西不重不漏地分完。给一条记录选的颜色，只是贴在一句话上的一个松散标签，不是这句话必须塞进去、否则总数就不对的格子——你完全可以把六种不同的工作连着叫一年"工作"，什么都不会出问题，因为没有谁在把它们加总起来去开发票。以后要是想知道某一周具体做的是哪种工作，靠的是回头把那句话重新读一遍，而不是十一个月前就先猜对该归到哪个格子里。精确的是那句话本身，颜色只是帮你以后更快找到它。

这就是为什么日志写到第四十条，和写第四条一样，都只是一行字；写到第四百条，也和第四十条一样。你和"写下来"之间，从来没有一份越长越长的列表挡着——因为日志本来就没打算维护一份列表。

关于 TimeMap

这是 TimeMap 的一个刻意的限制：一条记录只有一行字加一个颜色，颜色是装饰，不是账目。没有一棵必须一年到头保持一致的分类树，没有什么东西会随着你生活重新洗牌而需要合并或改名，也没有哪条旧记录会因为后来的一次拆分，悄悄变得"归错类了"。同样几个颜色可以用上好几年，也可以随时心血来潮加一个新的——不管哪种选择，都不会要求你回头去动已经写好的那些记录。

计时器变得越用越累，不是你的问题。它变重，是因为它底下那份只会往上加、不会往下减的列表，正在按照自己被设计出来的样子运转，而它被设计出来要做的事，就是不断累积。一份从一开始就没被要求维护列表的记录，不管是第一天还是第一千天，都不会背上这份重量。