UNTAG 付费栏目上新：《独辟蹊径：Shortcuts 设计之道》

Shortcuts 动作是一个人有可能设计并亲手建造的最小建筑。比起 Keyboard Maestro 这样的大型自动化工具乃至成熟的编程语言，Shortcuts 少了一分大宗房地产的味道，更像是暂供歇息的伐木小屋甚至道边长亭。这是普通人的机会，也是高手展现精湛自动化技艺的舞台。

建筑师亚历山大在《建筑模式语言》记载了禅宗的一则故事。

曾经有一位僧人，隐居在高山之巅的一间小石屋里。从山顶上可以远眺美丽的大海。但从僧人的石屋里和通往石屋的路上都无法看到海景。不过，在石屋前面有一个庭院，院子的四周是一道厚实的石墙。当有人去僧人的石屋时，他穿过石墙的门洞就进人这个庭院，然后斜穿过去，到达石屋的大门。在庭院的较远一侧，石墙上有一条裂缝，它很窄小，斜对着石屋大门。当有人穿过庭院，走到跟院墙上的这条缝隙对准的一个地方，刹那间，他看见了大海，但此景稍纵即逝，接着他走进石屋。

石墙、裂缝和远处的海景，几个元素的简单组合，却迸发出任何一者都不可能具有的美。中国文人山水中的“一线天”，与之或有共鸣。

这就是模式（pattern）的力量。

如果把自动化比喻成建筑活动，那么 Shortcuts 就是乐高积木（LEGO），看似简单、人人可以上手，但更加考验玩家的悟性。多数人玩积木，可能拼出一个十公分的小机器人就颇有成就感，少数人废寝忘食，也可能造出彩色塑料版的万里长城，但真正的高手则不满足于单纯堆积、拼接积木，他们甚至可以用乐高做出实用的机械计算机乃至生物 3D 打印机。

在 Shortcuts 的世界里，也有类似的金字塔状玩家分布：大部分玩家满足于只有几步的动作，例如打开购物软件的签到攒积分页面；一部分更有追求的玩家贡献了那些步骤达到数百个之巨的动作，他们的功绩在于吸引了普通人关注 Shortcuts，但是其发布的动作通常难以维护，并且除了设计者本人——如果不是包括他们在内的话——别人往往也无法理解其复杂结构。只有凤毛麟角的一小批玩家致力于优化动作结构，试图摸索出基础模块构成的特殊模式，以期四两拨千斤，用几个步骤就能制作功能强大的动作，而不是盲目堆积。

设计是解决问题的方法，模式是对问题的回答。发现并分享美丽的 Shortcuts 设计模式，正是我撰写本作的初衷。

模式视角下的 Shortcuts

参与效率方法讨论者，大约可以分为道、术、器几个流派，一如架空世界武学中的不同门派，各自关注某个方面。视角的不同，会带来无法调和的矛盾，例如主张原理与方法者就容易轻视工具，滑向工具虚无主义；而太拘泥于器物之辈，也往往不见舆薪，看不穿工具背后的通用思路。

如果有一条横亘在道、术、器之间的巨链，那么模式就是同时存在于每一环节的特殊元素，最有希望调停各家之间的矛盾。好的模式应当易落地、可移植且有启发，这些品质以一种逆序分别对应了三家：

第一，易落地：模式必须能够在当前讨论的工具中实现。这是一个模式的最低要求¹——一张不能或很难据以建造房屋的蓝图，是没有意义的。作为一个反例，尽管全局变量（Global Variable）是个好模式，但 Shortcuts 天生缺乏这一机制，通常要外挂备忘录、云盘文件或者第三方软件，本作并不鼓励此类“外挂解决一切”的做法。这反过来要求寻觅更通用的模式，使用更基础的模块，摆脱对外挂黑箱子的依赖。

第二，可移植。虽然本作是关于 Shortcuts 的，但如果我所介绍的模式只能用在其中，那么整个作品就会变成玩具说明书，圈地自萌，固步自封。盖乐意钻研 Shortcuts 的人，很可能同时还在、或将来可能使用其他自动化工具——例如 Keyboard Maestro、LaunchBar 或 Alfred——甚至还接触正经的编程语言。对于这一批（准）身怀多门技艺的读者而言——这些读者是作者所设想的重点对象之一——理想的阅读体验应该是正向迁移。

具体言之：

1. 有的读者，或许并无太多编程经验，Shortcuts 对他们而言是入门工具，以后还会接触其他利器。如果在最艰难的入门阶段碰得头破血流，好不容易掌握的知识到其他地方却武功全废，那么这种体验无疑糟糕透顶。²本作将引入 Switch\Case、迭代、Break 等编程中的概念以及二级菜单等界面设计中的元素，借此将上百步、几百步的传统动作精简为短短十几步，而运行效果甚至更佳。如果你有幸继续在自动化设计之路上前进，这些概念将会成为良师益友。
2. 另一部分读者，可能原本就会编程或熟练摆弄其他自动化工具³，希望把已经学到手的编程技巧灵活运用在 Shortcuts 中。如果你学过 Python 或 Javascript 等主流语言的完整课程，可能惊喜——或害怕——地发现，这部作品至少有一半的目录和编程教材进阶部分如出一辙。对于预先知道高级模式的读者来说，问题其实就成了“如何用 Shortcuts 实现某某模式”，不过我仍然推荐阅读一下至下而上的摸索思路，看看如何从简陋的模块中生长出各类进阶模式。

最后一个要求是有启发。在最为抽象的层面上，一个优秀的模式应当给制作者启发，而不是规定用法，也不会拒绝使用者修改模式本身，毕竟模式不等于模板⁴，不会因为你不用原设计就有一群生产商和经销商哭得死去活来。对 Shortcuts 设计本身而言，模式鼓励修改和变化，例言之，我在本作中将介绍复杂条件判断的几个变体，它们可以覆盖从多格式图片处理到律师费计算的各种场景，如果你实际情况与我提供的案例有异，当然可以更换功能更全或步骤更简的模式。站在 Shortcuts 之外看，模式其实是一种处理问题的通用方法，尤其是涉及批量处理和先后顺序的模式，不仅可用于其他软件，甚至可用诸真实世界。

关于第三方软件

难以回避这样的质疑：第三方 Shortcuts 增强工具俯拾皆是，为什么还要自己编写复杂模式呢？

首先，链条的强度拒绝于最薄弱的一环，而一套解决方案所涉及的工具越多，就越有可能留下漏洞。Shortcuts 其实非常小众，为其开发插件的作者很可能连饭都吃不饱，绝大多数 Shortcuts 配套工具都没有坚持下来，你可以去 App Store 搜一下，看看发现它们最后更新日期是在什么时候（往往是好几年前）。而且，塞了外挂的动作也不适合分享给朋友，至少就我自己来说，尽管我对自己的耐心颇有信心，但好像接受我帮助的人反倒没有那个耐心去折腾那么多工具。

另一方面，就像建筑设计中的模式一样，任何一个自动化模式，如果被打包成黑箱，使用者就失去了对它的控制，很难加以改良。很多优秀的建筑或工业设计往往毁在模板化，想想那些令人倒胃口的民宿必备北欧风格椅子，谁能想到它们最初来自著名设计师 Eames 夫妇呢？⁵当原本鲜活的设计风格，被打包成科林斯式、爱奥尼亚式、北欧式或新中式，让那些毫无品位可怜的包工头往你耗尽三代积蓄才买来的水泥盒子里哐当一放，原本的艺术气息和审美品位都荡然无存。

倘若是大型机械或者建筑集群这种程度的复杂构造，那么委托给别人也无可奈何，可是像 Shortcuts 那么轻巧的结构，如果使用者从不介入设计和制造阶段，某种程度上甚至是对自己的失职。

困难与挑战

模式或许是介绍 Shortcuts 最好的角度，但难度也最大：缺少真实案例。如果你想介绍一个自带模块，那很容易找到一批现成动作，即便是自己从零开始，问题也不大。但是，如果想为几种模块组成的模式找到好例子，那概率就低很多——寻找几个模块交集的概率肯定远远小于寻找他们的并集，也小于单个模块——或许正式这个原因，即便一些玩家零星捕捉到了一两个好模式，也很难将他们组织成文章，遑论整部作品了。

而鄙人在过去几年里制作了几百个 Shortcuts 动作（部分在这里），也撰写了上百篇文章，当我想介绍某一模式时，可以从自己的作品中随手抓出一把例子，其中既有相对实用、生活化的小工具（比如个性化图片批注以及视频封面编辑），也有非常专业、极其严肃的实例（比如诉讼费计算器和专利检索工具）。

或许只有我这样的闲人，才会也才敢把制作 Shortcuts 动作视作建造建筑，并从模式角度介绍快捷指令的作品吧！

🛍付费内容链接