不论是在过去的命令行、桌面端，还是现在的移动端，使用的工具一直在不断的变动。但在使用软件时，我一直习惯于遵从一个原则，那就是 Unix 哲学。
尽管几十年来，软件的形态交互变化很大，但是我的核心使用模式都不会变，也就是 Unix 哲学的内容：
这个原则非常古老而经典，指导着 Unix、Linux、macOS 等操作系统上基本软件的设计原则。
作为前言，介绍一些命令行时代一些经典的联动使用方式。如果感到比较抽象可以直接跳到末尾的结论。
(为了方便解释，第一行的中文解释了指令的含义，第二行写下了指令实际内容。「指令」其实是一个小的程序，来做一段专门的操作。)
按照文件名查找文件夹里的一个文件
列出 目录名称 | 搜索 字符串
ls dir | grep text
查找文件内的内容
输出内容 文件 | 搜索 字符串
cat filename | grep text
这里的「|」是 Unix 中的「管道」，可以理解为，文本流的传递。管道前部的「输出」可以作为后部的「输入」，第一步的操作获得一个结果，第二部操作把第一步的结果作为输入，直接处理上一步的结果。当更多的「管道」连接到一起，就相当于将单步操作连接到了一起，完成复杂工作。
虽然这个已经有四十年的历史了，但是核心思想就和现在流行的 Workflow 一样。
这里的「搜索」就是利用着软件 grep。可以看到，grep 就是专门用于搜索，它不会在乎搜索的来源到底是什么。它仅仅将这一切看作文本流即可，而只需要做好搜索功能。
同样的道理，读出文件内容的软件不需要搜索功能，列出目录的软件也不需要搜索功能，只需要做好各自的本职工作。只需要对外输出文本流，将职责之外的工作交给专业的工具即可。
而整个流程，关注的一个重点在于「文本流」的传递。就像它的字面意思一样，文本最初从上游输入，到最终的下游需要的输出。为了达到目的经过了若干环节的操作。在 Unix 设计思想的指导下，每个环节操作偏向于原子性，拆分到专注唯一功能，但是功能做到极致。某种程度上，像是 iOS 上的 Workflow。每一步的指令相当于一个动作，联动在一起，做到复杂的工作。
桌面工具领先了命令行一个维度，做到了丰富功能。比如，不再有人像最初那样，纯文本以及几个简单标记就写了整个文档，而是更加偏向于一个全才的软件，例如 Microsoft Word，实现全部的输入、排版、输出。这时候，一个工作的流程就是一个步骤，
打开 Word (然后编辑/然后排版/然后打印)但，看起来的完善并不是我想要的结果，因为有些单独任务没有达到我想要的极致。我不需要一个大而全的工具，而是各个方面足够专才的工具。还有重要的一点，我需要一个套信息交互的文档流传递，来让各个工具协作使用。我会按照基本元素，拆分开我的工作，然后去找在各个部分最完美的方式来处理。
例如，现在的任务是需要一个 Markdown 编辑器。我不会喜欢一个 Markdown 编辑器成品这个概念，而是把需要的工作拆分开来实现这个工作。首先声明一下，我并不是激进地在此否定现有 Markdown 编辑器的成果，也不是某种 Unix 哲学的原教旨主义，也不是对于集成品的排斥。我试用过市面上大部分的 Markdown 编辑器，各有优势，但是都有不能满足我的地方。
那么放在实际行动，我将普遍的使用 Markdown 编辑器的工作拆分成这样的几个工作。
输入 - 预览 - 输入输入，一个编辑功能发挥到极致的编辑器
Unix 中推荐编辑器概念，也就是一个纯粹用来编辑的程序。把所有的编辑功能单独拆分，推荐每个人使用自己最喜欢、最习惯的编辑器，来接管一切文档的编辑。可以把自己的编辑器偏好写在一个环境变量里面，所有的编辑相关工作，例如改一个配置文件、修改一个文档，都会根据配置，自动调用你最喜欢的编辑器。
在桌面时代，我更喜欢用自己喜欢的编辑器，比如 Sublime Text，来完成我所有的文字输入工作。在我使用习惯当中，它会比其他的更加有效率。我对于快捷键、模式化编辑充满了极致地追求，SublimeText 给予我的，其他完全无法做到。
我追求更加复杂的移动。我的手在输入过程中不会离开键盘。因此我需要移动操作完全在键盘上，并且高效运作。
A 左边的 Caps Lock 被我改成了 Ctrl，因为我需要频繁使用。传统类 Unix 系统上的 ^P，^N，^B，^F 实现上下左右是我需要的。另外的常用 ^A，^E 跳动行首行尾，^K 来删除光标之后所有。此外还需要 Alt 加方向键实现词级别的跳转，中文会分词，英文在空格之内。
曾经习惯于命令行时代的 Vim，我需要编辑器的模式化来增强编辑能力，比如以上的移动键加上 Shift，就变成了「移动并选择」。每个操作都是有意义，而且操作的组合变成了意义上的模式操作。
我还十分依仗 Sublime Text 许多对于编辑效率极致追求。选择一词、一句、一行、一段。上下文选择同一个符号。分词跳转时候算不算上分割号、算不算上引号...整行的上下移动、整行的复制…跳到行首、跳到行首第一个不是空白的地方…它的操作充满了各种细节，细致入微，熟练使用后很大的使用效率，就好像不凭借鼠标，键盘的一顿花哨的敲击就变得指哪打哪。
Word 不能达到这样的效果，也不可能这样做。它的复杂性不允许它在编辑操作占用这么多快捷键，也不允许仅仅将编辑放置于这么高的优先级。但是我追求纯键盘的高效输入时候，必须鼠标辅助的指指点点对我来讲变得累赘。
在 Markdown 工作流中，为了编辑效率，我会倾向于用它来编辑 Markdown 文件。经历过了一定的学习曲线，我已经具备了习惯于用它快速编辑的效果。而大多数成品的 Markdown 编辑器可能不会特别在意长期去打磨一套优秀的快捷键，来达到足够高的编辑效率。
作为编辑功能达到极致的编辑器，就算是 Sublime Text 有不符合习惯的地方，可以很容易进行定制。比如，可以很轻松的配置为，Command+1 变成，行首加上「#」，也就是 Heading 1 的快捷键；Command+B 变成，选择的内容前后加上「*」，成为 Bold 样式。并且这些可以配置成为「仅仅在打开 md 文件时候生效」。
预览，纯粹而专注的工具
曾经流行过一些追求双屏同时编辑和预览的Markdown编辑器，有些获得很好的口碑，甚至一度成为流行趋势。但是，我个人认为，那些工具的预览部分功能，没有像Marked那样做到极致。
首先科普一下为何预览编辑同步是可行的。文件本身被打开多次都是可行的，只有多个软件进行编辑，共同「写」这个操作可能造成一定的不一致问题。Marked对于一份文件只读，编辑器对于一份文件读写，两者共用内容是安全的。同一个文件的文本流，对于两者是共享的。
当分屏打开 Marked 和编辑器啥时候，工作的拆分没有让人觉得让事情变得糟糕，效果是一致的。(当然了，目前介绍的软件组合，还没有实现「同步滚动预览」。但是这个并不是不可能实现，可能只是各个开发者还没这方面开发的意向)
但是Marked可能更加像是一个专注于预览本身的工具，有时候做到十分完备。
比如，不用再考虑「Markdown 编辑器是否支持 LaTeX 公式」。不管使用什么软件来编辑，预览时候 Marked 就可以配置 MathJax 来解析。
比如，Marked 对于文本编辑的变动可以实时得知，在预览中标示出修改的部分。(需要说明的是，这一点需要编辑文件「保存」，也就是改动写回了文件，而不是仍然存在于编辑器的缓存中。)
比如，Marked 还可以对内容进行拼写检查。
这样而言，额外打开一个 Marked 来预览，可以比某些双窗口编辑器实现更多的功能。
输出，使用瑞士军刀般的强大工具
目前而言最出名的输出软件，可能就是 pandoc。具体 pandoc 多强大，pandoc 官网炫耀般地做了一个示意图。
说明一点的就是，很多成品的宣扬自己可以多种格式转换的 Markdown 编辑器，本身就是集成了开源的 pandoc。很长时间内 pandoc 可能是最强大的选择。如果我有复杂格式由 Markdown 转换的必要，我会推荐用 pandoc 来实现。
当然了，格式转换在很多软件上可能是主打，或者有时候是需要收费的额外功能。但是拆分这个操作，我可以让自己的格式转换输出做到更加专业。
一些额外的 Tips
以上的协作关键在于，文本流的共享。如果各自喜欢封闭，那么协作的基础就没有了。
例如，使用 Ulysses 时候，到底是桌面端编辑器与移动端编辑器利用 iCloud 同步，还是去配置一个外置文件夹，让 Dropbox 同步？我会建议使用 Dropbox 同步，因为这样保证了一个足够的开放的环境让各个软件都有机会介入，而不是各自为自己建立一堵墙。
我是希望软件共享一个编辑的地方，一个直接了当的 /Users/somebody/Dropbox/Note 而不是一个私有的文件目录：
/Users/somebody/Library/Mobile Documents/X5AZV9AG75_OR_OTHER_WEIRD_THINGS~com~soulmen~ulysses3/Documents/Library/AND_OTHER_STRANGE_FILENAME
这样才可以保证软件之间的相互协作。(软件自用的 iCloud 存放于硬盘上，但是逻辑上不会给使用，比如无法在 Finder 中访问这个文件夹)
输入、预览、输出，这三者都是各自功能中的佼佼者，而他们协作，让我实现了自己所需效率的最大化。单一软件的功能堆砌可能不符合我的胃口，但是开放内容，注重共享，给各个软件一个协作的机会，让每个人去打造属于自己喜爱的使用方式，可以有更广泛的前景。
移动应用通常会被互相隔离，文本流的传递交互一度比较麻烦。
iCloud 刚刚推出的时候，我一度认为这是移动文本流交互的新生。但是实际却陷入到了一种困境中。很多的应用将 iCloud 同步仅仅局限于了其移动版和桌面版之间，就像是自己愿意建起一道墙，在文本流可以交互的时代，继续维持工作分割的现状。这样的 iCloud 的使用范围，可能还不如应用自身支持个 Dropbox 之类的网盘来得实在。
当然也有例外。有些应用并不会局限于自家的软件当中。例如，Documents 或者 PDF Expert 的文档库，是可以作为一个打开文件的位置来源，像是从 iCloud Drive 中打开一样，直接访问其内在内容。
一个很好的例子是 Working Copy。Working Copy 是一个移动版本的git端，可以理解为，程序员的代码库文件。它 clone 下来的 repo，也就是说，下载下来的新版本代码，就是可以作为一个打开文件来源的位置。
这就颇具文本流传递的味道，因为内容是跨应用而共享的。任何编辑软件打开位置都可以是这个代码库，编辑不局限于不是十分好用的、Working Copy 自带的编辑器，而是可以用任何自己喜欢的App来编辑代码库。例如，iOS 上很类似于 Sublime Text 编辑感受的 GoCoEdit，高效编辑工具带来更强大的编辑效率。编辑完毕之后，Working Copy 自动检测到了被修改的文件的代码变化。软件工程师就可以在 Working Copy 这里做提交修改等操作。
编辑器做好编辑一件事，而代码库只需要做好了代码管理这样一件事，二者的协作来让整份工作以最佳的方式来实现。
Url Scheme 可以成为另外一个种文档流传递的机制。甚至已经成为了不少工作流软件的实现基础。但是它慢悠悠地转换跳动，也让我很不愿意以这种缓慢方式来强制把工作拆分成工作流，反而去浪费更多额外的时间。比如，一个代表性的操作，桌面端，直接编辑器调用 Python 解释器来执行，计算一下最终结果。而在移动端上，即使可以把 GoCoEdit 编辑的文件传到 Pythonista 上执行看个结果，但是我更愿意忍受一下，只使用 Pythonista 上自带的编辑功能不强的编辑器，而不是拆分每个动作的细节。
但是 Url Scheme 前景看起来十分美好。可以说，软件之间协作更加紧密方便了。我期待着它未来在应用上的继续发展，让繁杂的应用变得专注易用，让每个人的工作流构建更加容易。在移动端的时代，每个应用可以专注做好一件事，文本流的传递来完成复杂的工作。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。