正所谓「知之真切笃实处即是行，行之明觉精察处即是知」，要想深刻地理解，不仅需要思考，更要持续的实践和反思。
接下来，我将按照「实践→系统→需求→工具→实践」的循环来介绍每个环节中的基本思维方式，展示可供选择的光谱，希望这种讨论能帮大家帮助理解工具的逻辑，更有效地构建适合自己的工作流。
如果你曾与这样的同事合作过——他们将自己的工作视为孤立的任务，仅仅完成分配给自己的工作而不考虑上下游的配合，那么你一定能理解系统性思维的重要性。万事万物都是相互联系的。很多时候通过提升视角，拔高层次，以「整体」的视角从更高的维度审视问题，就能够发现更优的解决方案。
在工具的使用上，我们同样需要培养一种系统意识：工具不应被视为孤立存在，而应成为某个系统的一部分。唐纳德·A.诺曼在《设计心理学》中写道：
解决服务的复杂性的唯一方法是，将它们当做系统，把全部体验作为一个整体来设计。如果每个部分都被孤立地来设计，最终结果就是各个独立的部分不能够很好地配合在一起。
之所以需要有工具的系统意识，是因为真实的使用场景是灵活多变的。例如：
因此，理想状况下，流程之间不应该是孤立的，而是融合在一起，根据具体情况提供必要的协助。这种组合工具的使用，是更高维度的「服务」，也是我们所期望构建的输出导向的个人工作流。
那么，我们应该如何培养工具的系统意识呢？我的思路是「结构化」和「流程化」。
通过结构化和流程化构建的工作流，未来可以进一步进行标准化和自动化，并循序渐进地进行迭代，使其更加契合个人习惯。
尝试新的工具、设计新的工作流本身就能给人带来快乐，特别是与之对照，需要用工具完成的工作往往痛苦得多。但是，我们的最终目标始终是输出，因此不要为了工具而工具，有时需要自我克制这种折腾工具的欲望，只进行必要优化。
我会建议遵循奥卡姆剃刀原则「如无必要，勿增实体」，具体来说，有两点值得考虑：
就像项目需要拆解成任务来执行，工作流的构建也无法一蹴而就。那么工作流应该如何拆解呢？既然工作流是由要素组成的具有一定结构的系统，可以把它想象成是乐高积木组装的建筑，我们先顺着结合不那么紧密的地方，拆解为一个个更独立的模块，再根据个人需求，组装成更适合自己的工具。
在从工作流中拆解出不同的需求之后，我们可以很清晰地看到，不同需求所对应的工具，不管是软件的逻辑，还是选择的侧重点都有差异。而且就像层次步速理论（PaceLayeringTheory）所言，建筑中的每个层次、社会中的各个领域都有自己的变化频率，不同类型工具的使用周期也是不同的。我们应该对那些核心的、基石般的工具事前精打细算、事后物尽其用，不要轻易大改，为整个工作流提供稳定性；而另外一些服务可以不用过分货比三家，只要满足当下需求就算物有所值，未来如果发现不合适，也可以快速找到替代或升级方案，在现有基础上优化。
基于上述目标，我采用计算机领域经典的二分法：关于「数据」的需求和关于「程序」的需求。更通俗地讲，也可以说是关于「文件」的需求和关于「流程」的需求。
或许程序类的需求相对小众，但只要是数码用户，肯定都有数据类的需求。我把以下三者都归到数据类的需求：
浏览和编辑毋庸赘述，我们来看看最核心的管理功能。文件管理功能是如此基础，以至于所有的操作系统都会自带文件管理器；用户的文件管理需求又如此多样，因此很多人都有过寻找系统文件管理器之外、更强大的文件管理器的经历。就个人而言，尽管换成macOS多年，我依然没有发现一个能够完全满足自身需求的文件管理器，结果还是开着ParallelDesktop运行TotalCommander来管理macOS中的文件。
随着系统的更新换代，文件管理工具也在不断迭代升级，但是再怎么优化，也无法解决系统层面的局限：文件只能放在单一目录，而现实世界的分类往往需要多个维度。此外，不同媒介类型的文件管理有其独特性，很难被通用的文件管理工具满足。这些限制催生了库管理工具的发展。它在传统文件管理基础之上，加入了元数据管理，使得文件的组织和检索更加灵活，大大提升了效率。下篇还会进一步讨论不同的管理方式：除了传统的文件管理和库管理，二者之间还有一个选择的光谱；二者也并非全然对立，还存在一些兼容不同管理方式的解决方案。此处不再展开。
为了帮助大家更好地理解三类文件需求的区别，在此简单列出不同媒介类型的典型管理、编辑和浏览工具：
IFTTT的名字「IfThisThenTriggerThat」，就是理解程序类需求的绝妙范式：
不同程序类工具的区别主要在于「what」和「how」的支持范围和配置方式的不同。对于专门针对某一模块的设置工具，how一般内置在工具的逻辑中，不需要用户自行配置，用户只要设置what就好。例如设置鼠标行为的工具默认在有鼠标操作时触发，安卓上的各种启动器默认在返回主屏幕时触发。而通用自动化工具需要用户自行配置what和how。
IFTTT可谓是最简单的通用自动化工具了，从工具支持的服务范围中，手动选择相应的how和what就好。
更高阶的需求就需要对what进行手动组装，需要how支持多个触发条件了。下图的两个自动化工具（n8n和KeyboardMaestro）虽然看上去差别很大，但这只是交互和呈现逻辑的区别，本质是相同的。只要把握了工具的内在逻辑，很容易进行迁移。
再高阶的需求难免要写代码。大部分情况下是what使用代码实现，在工具中手动配置对应的代码文件路径来实现how，例如LaunchBar中：
这个json文件会被macOS上的Ubersicht访问、展示在桌面。同时会同步到安卓平板，被一言工具访问、展示在桌面。
现实中，程序和数据之间的关系暧昧不清。一方面，哥德尔在证明不完全性定理时，把数论命题转化为编码，与「程序即数据」的思想相呼应；另一方面，把数学理解为计算，例如把PI的计算过程和计算结果区分开来，导致了计算中心这一20世纪科学界最大的思想转向。
在工具中，我们也可以看到上述分类并非泾渭分明：
因此，进行程序和数据的区分并非由于真有这么一道明晰的边界，而是因为这种分类可以成为我们理解应用逻辑的思考工具。了解所属的类别后，我们可以更好地：