Matrix 首页推荐 

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。

文章代表作者个人观点，少数派仅对标题和排版略作修改。

在上篇构建可持续发展的个人工作流 01：认识篇中，我们讨论了「重器轻用」vs「All-in-One」这种二分法的问题，并强调重点应该放在​构建以输出为导向的稳定工作流​上。为了实现这一目标，首先探讨了如何认清自己和工具，因为只有认清这两者，才能定义最适合自己的工具流。

正所谓「知之真切笃实处即是行，行之明觉精察处即是知」，要想深刻地理解，​不仅需要思考，更要持续的实践和反思​​。

近来不时能看到类似「差生文具多」「一顿折腾猛如虎，输出一看原地杵」的调侃，诚然，我们要警惕过度折腾，但折腾在一定程度上是难以避免的。事实上，​只有经历过一段时间的折腾，我们才能更加明确自己的能力边界和需求所在​。这个系列的目标就是帮助更多人尽可能地降低折腾的成本。

接下来，我将按照「实践 → 系统 → 需求 → 工具 → 实践」的循环来介绍每个环节中的基本思维方式，展示可供选择的光谱，希望这种讨论能帮大家帮助理解工具的逻辑，更有效地构建适合自己的工作流。

1. 实践 → 系统：用系统性思维看待工作流

如果你曾与这样的同事合作过——他们将自己的工作视为孤立的任务，仅仅完成分配给自己的工作而不考虑上下游的配合，那么你一定能理解​系统性思维​的重要性。万事万物都是相互联系的。很多时候通过提升视角，拔高层次，以「整体」的视角从更高的维度审视问题，就能够发现更优的解决方案。

1.1. 工具应该作为系统的一环

在工具的使用上，我们同样需要培养一种系统意识：​工具不应被视为孤立存在，而应成为某个系统的一部分​。唐纳德·A. 诺曼在《设计心理学》中写道：

解决服务的复杂性的唯一方法是，将它们当做系统，把全部体验作为一个整体来设计。如果每个部分都被孤立地来设计，最终结果就是各个独立的部分不能够很好地配合在一起。

之所以需要有工具的系统意识，是因为​真实的使用场景是灵活多变的​。例如：

• 在收集资料时，经常需要记录突然的灵光一闪。
• 在回顾过程中，往往要对部分片段精细加工，并进一步进行检索和收集。
• 写作也并非一个线性过程，通常要在不同的任务间不断切换：可能在阅读时，需要快速记录在脑海中形成的句子；或者注意到一个脚注，然后检索相关信息；或是为了深入理解某段文字，搜索释义、与 LLM 对话沟通。在这一过程中，阅读、笔记、写作是一个圆融的整体，而非孤立的任务。

因此，理想状况下，​流程之间不应该是孤立的，而是融合在一起，根据具体情况提供必要的协助​。这种组合工具的使用，是更高维度的「服务」，也是我们所期望构建的输出导向的个人工作流。

1.2. 如何培养工具的系统意识

那么，我们应该如何培养工具的系统意识呢？我的思路是「结构化」和「流程化」。

• 结构化​：所谓的系统，就是由相互联系、相互作用的​要素​组成的具有一定​结构和功能​的有机整体。这会在接下来的「系统 → 需求」一节会有进一步的解释。
• 流程化​：一个完整的工作流最好​同时包括输入和输出​​，输入强化输出，输出倒逼输入，二者相互促进，形成一个自我强化的闭环。对于知识管理来说，输入 + 输出 ≈ 阅读 + 写作。而更通用的思考框架则是 GTD 系统的工作流「计划 - 收集 - 处理 - 执行 - 回顾」。把阅读作为方法：从选书到笔记的经验分享一文中，我的阅读系统的构建就是采用了这个框架。根据具体情况不同，实际的工作流不必严格遵循每个步骤。如果工作流出现问题，很有可能是​输入和输出之间失衡​​。如果输入过少，则输出很难持久。如果输入过多而输出过少，也会反过来会影响输入的动力和能力。某种程度上，这也可以理解为是​思考与行动之间的平衡​​。此外，某些情况下，​处理的顺序​至关重要。我的 PDF 制作三件套：压缩、目录和页码中就介绍了如果在处理 PDF 文件时不注重顺序，往往会导致 PDF 数据丢失甚至文件损坏。因此设计合理的处理顺序至关重要。

通过结构化和流程化构建的工作流，未来可以进一步进行​标准化​和​自动化​​，并循序渐进地进行​迭代​，使其更加契合个人习惯。

1.3. 在设计新系统之前……

尝试新的工具、设计新的工作流本身就能给人带来快乐，特别是与之对照，需要用工具完成的工作往往痛苦得多。但是，我们的最终目标始终是输出，因此不要为了工具而工具，有时需要自我克制这种折腾工具的欲望，只进行必要优化。

我会建议遵循奥卡姆剃刀原则「​如无必要，勿增实体​」，具体来说，有两点值得考虑：

1. 是不是可以让别人来做？ 以前我在参观博物馆，想要拍摄展品时，曾经花费不少时间尝试拍出无反光的清晰照片。有次看到「中国历代绘画大系」展览的介绍，藏品照片都是由专业团队拍摄，我意识到专业的工作应该交给专业的人来做。虽然拍摄一个画面只需要千分之一秒，但是，这些专业团队的拍照前期准备工作平均要耗时 2~5 小时。更别提后续的校色等环节还需经过数十道步骤的调整。与其自己花这个时间拍照，简单的记录展品的名称、作者等元数据，以便未来检索，复用专业资源不是更好？这也是「不要重复造轮子」的实践吧。
2. 如果需要自己来做，​是不是可以在已有系统上加工​​，而非从头设计一个全新的工作流？例如，事务管理系统是除了知识管理系统之外，很多人都希望构建的工作流。然而私以为，对于大部分人来说，待办事项的量级完全不值当用一个专门的事务管理系统来管理，简单记录每日的核心任务已足够。即便我在作为项目负责人，需要跟十余个隶属产品、研发、教研、设计等多种岗位的同事沟通和协作时，也没有使用专门的事务管理工具，而是选择在已有的笔记管理系统上进行迭代。我很赞同我们究竟需要怎样的时间管理工具一文的观点，​事务管理的难点在于思考​：拆解目标，不断过滤淘汰，反复创造设计，帮助我们一步一步推进目标。专门的事务管理工具大都过于结构化，反倒是笔记工具不仅能够记录松散的原始信息，还能有效支持信息的结构化，进而转化为可执行的任务。这使得​笔记工具成为思考过程中的理想工具​​。通过使用像 org-jira 这样的插件，我能够将结构化的思考成果从我的笔记系统，同步到专业的项目管理工具 jira 中，与团队成员进行协作。而且这种方式天然地把个人思考路径保留在了笔记库，加之我会把项目的具体行动和执行结果记录到笔记库，这样在复盘时，就能快速定位当时的行动和思考，​更好地积累经验​。

2. 系统 → 需求：在工作流中，有不同类型的需求

接下来，我们要在自己的真实使用场景中发现内生的需求，这点在认识篇的「认清自己的需求」一节已有详细讨论。

就像项目需要拆解成任务来执行，工作流的构建也无法一蹴而就。那么工作流应该如何拆解呢？既然工作流是由​要素​组成的具有一定​结构​的系统，可以把它想象成是乐高积木组装的建筑，我们先顺着结合不那么紧密的地方，拆解为一个个更独立的模块，再根据个人需求，组装成更适合自己的工具。

用这样的方式，我们很自然地就构建了一个​高内聚、低耦合的工作流​——每个模块内部的功能紧密相关，就像每一块积木，有着特定功能和形状，这是高内聚；各模块又可以独立于其他部分进行调整改进，就像积木之间因为有通用的连接点，可以互相替换，这是低耦合。一个高内聚、低耦合的工作流，正是我们期望的​能够适应个人需求变化而改进的工作流​​。相比「一出现当下工具无法达成的新需求，就准备迁移到新工具」，这种方式可以让我们在现有的工作流中找到合适的接口，加上新的积木；或者定位需要升级的模块，用新的积木替代它。如此这般，无疑更有助于个人的积淀，避免在各种软件之间换来换去，最后所得甚少的窘境。

在从工作流中拆解出不同的需求之后，我们可以很清晰地看到，​不同需求所对应的工具，不管是软件的逻辑，还是选择的侧重点都有差异​。而且就像层次步速理论（Pace Layering Theory）所言，建筑中的每个层次、社会中的各个领域都有自己的变化频率，​不同类型工具的使用周期也是不同的​。我们应该对那些核心的、基石般的工具事前精打细算、事后物尽其用，不要轻易大改，为整个工作流提供稳定性；而另外一些服务可以不用过分货比三家，只要满足当下需求就算物有所值，未来如果发现不合适，也可以快速找到替代或升级方案，在现有基础上优化。

基于上述目标，我采用计算机领域经典的二分法：关于「​数据​」的需求和关于「​程序​」的需求。更通俗地讲，也可以说是关于「​文件​」的需求和关于「​流程​」的需求。

2.1. 数据/文件类的需求

或许程序类的需求相对小众，但只要是数码用户，肯定都有数据类的需求。我把以下三者都归到数据类的需求：

1. 管理​：提供恰当的视图来浏览文件列表，提供文件的组织和检索功能。
2. 浏览​：对单一文件的浏览。
3. 编辑​：对单一文件的创建或修改。

浏览和编辑毋庸赘述，我们来看看最核心的管理功能。文件管理功能是如此基础，以至于所有的操作系统都会自带文件管理器；用户的文件管理需求又如此多样，因此很多人都有过寻找系统文件管理器之外、更强大的文件管理器的经历。就个人而言，尽管换成 macOS 多年，我依然没有发现一个能够完全满足自身需求的文件管理器，结果还是开着 Parallel Desktop 运行 Total Commander 来管理 macOS 中的文件。

随着系统的更新换代，​文件管理工具​也在不断迭代升级，但是再怎么优化，也无法解决系统层面的局限：文件只能放在单一目录，而现实世界的分类往往需要多个维度。此外，不同媒介类型的文件管理有其独特性，很难被通用的文件管理工具满足。这些限制催生了​库管理工具​的发展。它​在传统文件管理基础之上，加入了元数据管理​​，使得文件的组织和检索更加灵活，大大提升了效率。下篇还会进一步讨论不同的管理方式：除了传统的文件管理和库管理，二者之间还有一个选择的光谱；二者也并非全然对立，还存在一些兼容不同管理方式的解决方案。此处不再展开。

为了帮助大家更好地理解三类文件需求的区别，在此简单列出不同媒介类型的典型管理、编辑和浏览工具：

2.2. 程序/流程类的需求

程序/流程类的需求通常是面向高阶用户，所有程序类需求都是​「what」（实现哪些功能）和「how」（如何调用这些功能）的结合​​。有的工具​只关注 what​​，例如脚本编辑器，提供了创建和编辑脚本的功能，但是脚本的调用需要在系统设置中配置；有的工具​只关注 how​​，例如 crontab 命令，专注于任务的调度和执行时间。更多的工具是​把二者结合起来，提供整合的解决方案​​，例如 Tasker、n8n、Keyboard Maestro 等各种通用自动化工具，以及专门针对某一模块的设置工具（macOS 上设置鼠标和触控板行为的工具，安卓上的各种启动器等）。

IFTTT 的名字「If This Then Trigger That」，就是理解程序类需求的绝妙范式：

• 「what」对应于 That 部分，定义了要实现的功能
• 「how」对应于 This 部分，指明了功能触发的条件。

不同程序类工具的区别主要在于「what」和「how」的​支持范围和配置方式​的不同。对于专门针对某一模块的设置工具，how 一般内置在工具的逻辑中，不需要用户自行配置，用户只要设置 what 就好。例如设置鼠标行为的工具默认在有鼠标操作时触发，安卓上的各种启动器默认在返回主屏幕时触发。而通用自动化工具需要用户自行配置 what 和 how。

IFTTT 可谓是最简单的通用自动化工具了，从工具支持的服务范围中，​手动选择​相应的 how 和 what 就好。

更高阶的需求就需要对 what 进行​手动组装​​，需要 how 支持​多个触发条件​了。下图的两个自动化工具（n8n 和 Keyboard Maestro）虽然看上去差别很大，但这只是交互和呈现逻辑的区别，本质是相同的。只要把握了工具的内在逻辑，很容易进行迁移。

再高阶的需求难免要​写代码​。大部分情况下是 what 使用代码实现，在工具中手动配置对应的代码文件路径来实现 how，例如 LaunchBar 中：

最自由、最强大的方式是 what 和 how 都由代码逻辑实现。例如 Emacs 中的 what 部分对应一个 elisp 函数，而 how 可以是绑定到快捷键、点击一个按钮、选择一个菜单项、在工具空闲时自动运行，或是添加到 hook 变量以便在特定事件发生时执行。这些都是使用代码来实现的。在掌握基本的 elisp 后，非常个性化的小需求可以轻松用几十行代码解决。例如，我习惯把对自己有启发的句子保存到一个名为 epigram.org 的单独笔记文件中。虽然平时在记笔记、写文章时，也会搜索这些格言并引用，但还是希望日常能更高频率地看到它们。放在 anki 这样的工具进行记忆对我来说太重了，放在桌面上随机展示更适合这个场景。加之我原本就更习惯搜索，不会在桌面上放文件或应用的图标。因此，我写了一个简单的 elisp 函数，每当我保存 epigram.org 文件（how），就会把其中的格言、作者信息结构化地提取到另一个 json 文件（what）：

这个 json 文件会被 macOS 上的 Ubersicht 访问、展示在桌面。同时会同步到安卓平板，被一言工具访问、展示在桌面。

2.3. 分类是为了辅助思考，而非为了设置边界

现实中，​程序和数据之间的关系暧昧不清​。一方面，哥德尔在证明不完全性定理时，把数论命题转化为编码，与「程序即数据」的思想相呼应；另一方面，把数学理解为计算，例如把 PI 的计算过程和计算结果区分开来，导致了计算中心这一20世纪科学界最大的思想转向。

在工具中，我们也可以看到​上述分类并非泾渭分明​：

• 文件管理工具大都会整合文件浏览​，在浏览文件列表时，提供对单一文件的预览。想象一下，一个没有图片预览功能的图片管理工具会有多难用，在浏览资料列表时可以直接预览资料而不需打开会有多方便。
• 一些​浏览工具也会加入简单的编辑功能​，例如在图片浏览器中旋转和裁切、在PDF浏览器中编辑目录。
• 还有一些编辑功能非常结构化，没必要一一打开文件，进行个殊化处理。这种​适合批处理的编辑功能更适合整合进管理工具​。例如在 calibre 把书籍文件批量转化为阅读器支持的格式；
• 一些强大的软件甚至会​打破数据和程序的区分​。上节展示了 Emacs 在程序类需求的高度灵活，而之所以需要实现这些需求是因为我还会用 Emacs 来管理我的笔记、代码项目等等。很多文件管理工具都支持插件扩展，对工具自身程序进行高度定制，以便适应用户多样的个性化需求。

这种情况的出现正是因为工具为了应对认识篇中所说的「随着工具数量的增加，使用的摩擦也会增加」的问题。哪些功能整合到工具内（做加法），哪些功能超出了工具的边界（做减法），有赖于产品的把控。一个专业的产品（这点在上一篇的「如何判断一个软件未来发展态势」也有讨论）可以同时满足工具内部的功能性和外部的兼容性，找到最佳平衡点，而非一味地做加法来迎合用户需求，或者做减法来满足个人审美。

因此，​进行程序和数据的区分并非由于真有这么一道明晰的边界，而是因为这种分类可以成为我们理解应用逻辑的思考工具​。了解所属的类别后，我们可以更好地：

• 理解工具​。不同类型工具的内在范式不同，选择合适的范式能帮助我们更快明确工具的定位，度过新手磨合期。​把不同类型的工具进行比较的讨论往往是低效的，但是这种情况屡见不鲜​。例如「calibre 阅读体验欠佳，又回到 iBooks」这种说法把 calibre 和 iBooks 进行比较，这就像说「Zotero 阅读体验欠佳，所以我选择 PDF Expert」一样，把管理工具（calibre 和 Zotero）和浏览工具（iBooks 和 PDF Expert）进行比较。管理工具的核心功能是对大量文件进行组织和检索，浏览只是方便管理的辅助功能，肯定体验不如专门的浏览工具。如果只需要浏览单个文件，应该去挑选合适的浏览工具，选择管理工具反而会引入额外的复杂性。
• 预估值得为此投入的时间​​。正如前文如说，不同类型工具的使用周期也是不同的，因此不管是前期调研，还是后期学习，工具值得投入的时间也应该不同。​工具的使用周期越长，在工作流中越处于中枢地位，越值得投入更多的时间和精力​​。核心工具的改弦易辙极有可能涉及核心数据迁移等问题，导致工作流的短期失效。我认为最值得关注的中枢工具就两类：​「数据中的管理」和「程序中的通用自动化」​​。其他的文件编辑、浏览，或者针对单独模块的设置工具，相对而言不需投入太多精力，满足当下需求即可，未来如果发现不合适，替换成其他方案对整个工作流的影响也不大。把阅读作为方法：从选书到笔记的经验分享的开篇谈到应该慎重选择核心应用。这里的核心应用其实就是管理工具：书籍管理工具和笔记管理工具。除了工具的使用周期外，​工具的使用频率也是评估学习成本的重要考虑因素​。如果一个工具使用周期长，使用频率也高，那这绝对是一个值得花费时间学习的工具，典型代表就是笔记管理：其他类型的管理工具大都只是个入口，真正的浏览和编辑还是要跳转到对应的工具中进行；而笔记管理工具往往是整合了管理、浏览和编辑的功能，因此很多进行笔记管理的朋友笔记工具会常驻后台，每天累计使用好几个小时；而且我们记笔记不仅为了当下，更期望未来从不断增多的笔记中可以产生复利（例如激发灵感、加速产出、提供决策支持等），因此笔记工具的使用周期理应很长。
• 设计工作流中的工具之间如何协作​。之后我们会介绍为了构建一个可持续的工作流，工具链应该如何拆分和组合，其中很重要的一个参考标准就是工具的类型。
• 理解了工具之后，再结合自身的需求和能力，就能更准确地​判断是否适合自己​。

举例来说，如果我们需要一个自动化工具，那么通过运用「If This Then Trigger That」这个思考框架，了解其所支持「what」（实现哪些功能）和「how」（如何调用这些功能）的情况，就可以很快地了解工具的核心。由于通用自动化属于中枢工具，因此会有心理预期需要花一定时间来学习和配置。自动化工具的配置有三种形式：手动选择、手动组装、写代码。根据自身的需求和能力，从中选择当下最适合的形式。如果未来需求不满足，也可以明确升级优化方向是什么。

3. 接下来……

之后的文章，我们会把构建工作流的重点放在「数据管理」上，因为：

• 「数据管理」在工作流中处于中枢地位，值得花精力去调研、学习、配置。
• 「程序的通用自动化」虽然也处于中枢地位，但是一方面用户大都是有自己方法论的进阶用户，另一方面在 IFTTT 框架之下的讨论个性化太强，难以进行统一抽象的讨论。
• 「针对单一模块的设置工具」同样因为个性化太强，且平台依赖性太强，难以进行有效的方法论层面的讨论。
• 大多数情况下，文件的「编辑」和「浏览」只要选择满足自己当下需求的工具就行。因为文件天然可以作为工作流中的粘合剂，把当下的处理结果保留下来，留待未来再选择合适的「编辑」和「浏览」工具处理。

综上所述，后续文章不再对流程类需求、文件的编辑和浏览需求进行深入讨论，而是聚焦在管理：首先明确管理需求的底层逻辑，包括存储方式、组织方式、数据格式、备份与同步等。再以管理为核心，探讨在实践中，具体可以怎样拆分和组合工具，从而打造适合自己的工具流。

让我们期待下篇的再会。

> 关注 少数派公众号，解锁全新阅读体验 📰

> 实用、好用的 正版软件，少数派为你呈现 🚀