iOS自动化的3.0时代

相信很多少数派的读者都和我一样，当 WWDC 舞台上出现了 Shortcuts 时，瞬间两眼放光：“咦？这不是 Workflow 吗？”

Workflow 是一款 iOS 上的自动化应用，可以将多个 App 里的功能串起来，让它们自动运行，形成一个工作流。比如我们可以让 Workflow 获取相册里的最后一张截图进行标注，然后进行自动裁剪，接下来选择分享到社交网络，最后自动删除这张截图。

Workflow 的魔力就在于，直接拆散了 iOS 的大部分功能，然后由我们来自由组装。这既可以缩减跳转应用的步骤，也能让很多之前完全不相关的功能串到一起。很多人评价 Workflow 都会提到这句话：“模块化编程的思维”。我们不要被“编程”这两个字吓到，Workflow 的大部分功能都跟代码无关，我们只需要调一调开关就行了，这句话想说的是它们的思维方式很像——零件都帮你准备好了，就看你怎么组装它们。

2017 年 3 月，这款充满魅力的应用被苹果收购，应用本身以及四位开发者都加入了苹果。此后 Workflow 有过几次更新，但都算不上大变化。外界一直在猜想 Workflow 将会以怎样的方式融入 iOS，会带给这个生态怎样的变化。

直到今年 WWDC，我们终于见到了脱胎换骨的 Workflow——捷径（英文名：Shortcuts）。捷径很明显是 Workflow 在 iOS 中整合后的成果，两款应用的界面极其相似，包括模块化的功能、拖拽的交互方式、通知中心小部件、以及提供下载的捷径中心。

捷径应用的界面

继承了 Workflow 的捷径

捷径基本上继承 Workflow 的主要特点，包括了应用的组成结构，以及使用方法。不过由于苹果官方对待捷径的叫法实在容易让人产生疑惑，在不同语境下也会造成不必要的误解（苹果的叫法是：捷径应用、捷径、操作，对应英文：Shortcuts App、Shortcut、Action），所以我们先来明确一下几个名词的意思：

捷径应用/App：苹果推出的独立应用（相当于以前的 Workflow 应用），通过 App Store 下载；

捷径应用

捷径动作：捷径应用中每个可以运行的动作（相当于 Workflow 应用中的 Workflow 动作），比如前文提到的处理图片的整个流程，就是一个捷径动作；

捷径动作

捷径模块：每个捷径动作由一个或多个捷径模块组成，可以说捷径模块就是捷径动作的零件。

捷径模块，（注：以上所有的“捷径”都可以替换成英文名称“Shortcuts”，比如“Shortcuts 应用”“Shortcuts 动作”“Shortcuts 模块”。）

除了继承 Workflow 应用的主要特点，捷径应用最主要的变化是融入了 Siri，这是一种新的运行捷径动作的方式。在以前，运行 Workflow 动作只有 Workflow 应用本身、通知中心小组件、和分享菜单三种方式。现在，我们可以通过 Siri 自定义短语来运行捷径动作。当你使用自定义短语——也就是 Siri 语音运行捷径动作时，它被称为 Siri 捷径。

因此，我们可以简单把捷径分成两个部分：继承了 Workflow 运行方式的捷径应用，和使用 Siri 自定义短语运行的 Siri 捷径。

Siri 捷径

我们先来说一说 Siri 捷径。Siri 捷径是怎么来的？

首先，iOS 系统本身就自带了一些 Siri 捷径，比如打开备忘录、拨打联系人电话、发短信等。你可以通过“设置 – Siri 与搜索 – Siri 捷径”找到它们，然后设置自定义短语。

设置 – Siri 与搜索 – Siri 捷径

此外，第三方开发者也可以使用苹果提供的捷径 API，为自己的 App 设计 Siri 捷径。捷径 API 有两种：

第一种叫 NSUserActivity，可以实现比较简单的操作，比如直接打开 App 里面的某个界面，或者打开已经在 Spotlight 里可以索引的、已经提供给 Handoff 的功能。（注：部分应用因为之前适配过 Spotlight 索引和 Handoff 功能，所以当升级到 iOS 12 之后，即使这些应用没有特地去适配捷径，也能自动支持 Siri 捷径。此处需要感谢在意空气的开发者张斌解答了我的疑惑。）Drafts 开发者就利用 NSUserActivity 实现了直接打开应用的语音转文字功能。

第二种叫 Intents，可以实现不打开 App，在当前界面运行结果，并且开发者还可以自定义 UI 和回复内容。比如 JSBox 的开发者钟颖就做了这么一个动作：当他喊出“回家”短语后，JSBox 会自动抓取实时的公交数据，并以他设计好的 UI 返回到 Siri 页面上。

当开发者定义过 Siri 捷径之后，它们就会自动出现在系统设置里。

第一种实现的效果和 URL Schemes 差不多，只能做很简单的操作，第二种的玩法就相对多一些。不过两者都比 URL Scheme 好懂，因为都是开发者帮我们包装好的，并且一些 App 会为 Siri 捷径提供直观的添加方式，在系统设置内也可以随时找到它们。另外更重要的是，因为有了苹果官方光环的加持，开发者也更愿意去适配它。

Siri 捷径能拯救 Siri 吗？

从今年的 WWDC 发布会上其实可以看得出来：苹果很重视 Siri。

捷径应用的所有功能展示，几乎都是围绕着 Siri 的使用场景展开的。在 WWDC 主会之外，有两场 Sessions 的演讲者都是原 Workflow 团队的开发者，一位是 Ari Weinstein，另一位是 Ayaka Nonaka。（Workflow 原团队一共四位成员，另外两位是 Conrad Kramer 和 Nick Frey。）我有特别注意到，他们两位都隶属 Siri 部门，这就更加说明了苹果收购 Workflow 的目的——奔着融入 Siri 去的，两位都直接加入了 Siri 部门。

Ari Weinstein 和 Ayaka Nonaka 在 WWDC Sessions 上

Siri 作为智能语音助手的角色，一直以来走的都是自然语言处理的路子，也就是分析用户说的每句话的语法结构，每个词每个字是什么意思，并且尝试去理解同一句话的不同表达方式。而亚马逊的 Alexa 走的则是另一个路子，它非常开放，允许第三方应用定义命令，并且用户也可以借助 IFTTT 自定义短语。

换句话说，很多时候 Alexa 并没有听懂你说了什么，它只是识别到你说了一句提前设定好的短语，然后根据设定去执行而已，如果你换个表达方式，它就会执行失败。

在前年的 The Talk Show Live From WWDC 2016 上，苹果软件高级副总裁 Craig Federighi 谈到他们努力让 Siri 明白用户的多种表述方式，以及他们会自己完善开发 Siri 在各个领域的语言处理能力，然后再由开发者接入进来，而不是直接把理解用户命令的任务丢给开发者。Craig 甚至还有些不齿这样的做法，他说如果仅凭关键词（Trigger Word）来触发命令的话，那其实对于苹果公司来说非常简单。

It would have been really super easy for us to say, “Hey, just tell us a trigger word, or the name of your app, and we’ll hand you a string.——Craig Federighi

但他们没有选择这么做的原因是，这会让 Siri 的体验非常不统一。苹果营销高级副总裁 Phil Schiller 还说到，他们对 Siri 的愿景是：对所有事情同等地聪明。

We need Siri to be equally smart at all the things we do. ——Phil Schiller

但现实是什么呢，Amazon Alexa 在市场上获得了大量的好评，而 Siri 则是普遍地不看好，甚至不看好到产生偏见。比如每次少数派首页上发布了一篇 Siri 相关的文章，底下评论中一定会有“可是 Siri 就是个智障”式的抖机灵，并且附和的人还不少，完全不顾文章中的技巧是否真的有用。

最后苹果还是动摇了。这次 WWDC 之后，你可以看出 Siri 的发展路线除了自然语言处理，还新增了让用户自定义短语的 Siri 捷径。自定义短语虽然并不像苹果公司理解的那种“智能”，但它至少能解决实际问题，因为一旦设定好了，它就不容易出错。

在 Building for Voice with Siri Shortcuts 这场 WWDC Session 上，苹果对自定义短语的建议是使用简短的、容易记住的短语。他们举了一个例子，当你想用 Siri 捷径订一份海鲜汤外卖时，既不应该用“Hey Siri, please place an order, thank you.”这种指向不明的句子，也不应该用“Order a clam chowder to my office.”这种稍显冗长的句子，而是应该用“Chowder time”这种简短直接的短语。

Siri 捷径的自定义短语应该尽量简短直接

甚至，你还可以设置更短的短语。比如，Hum 曾经在 Power+ 的 Slack 群中分享过一个在 iPad 上用键盘就能快速翻译网页的 Workflow 动作。因为我的 iPad Pro 长时间连着外接键盘，因此开启了 Type to Siri 功能，所以我就把这个动作的 Siri 捷径短语设置为 GT。每当我需要翻译网页时，只需先复制网页链接，然后长按 Home 键唤出 Type to Siri，再输入 GT，就能自动运行 Google 翻译的 Workflow 动作，比之前的步骤要简单一些。

这种操作的好处是不用思考和选择，长按 Home 键后，直接输入关键词（甚至是无意义的关键词），然后回车，一气呵成。

有了 Siri 捷径的帮助，反而让我开始觉得 Siri 有戏。当然 Siri 在自然语言识别、搜索结果整合等方面还是要继续提高，但能够使用自定义短语这一点就足够让我感到兴奋。因为自定义短语与智能无关，而是一种有标准答案的交互方式，它虽然简单粗暴，但足够实用，而且还可以配合 HomePod 使用，做到很多之前实现不了的操作。

我在 HomePod 测评里曾提到，在 HomePod 上使用第三方音乐媒体服务只能执行一些简单的语音指令，比如“暂停、快进快退、切歌、调整音量”这些，而像下面这些更复杂的语音指令，第三方音乐媒体服务就无法做到：

• 当你刚回到家时，无法直接对 HomePod 喊一句“播放 Spotify 里的歌曲”；

• 无法挑选专辑、歌手、歌单、电台等内容；

• 无法执行保存至音乐库、将歌曲添加至歌单等操作；

• 无法对歌曲执行“喜欢、不喜欢”操作。

而现在借助 Siri 捷径，就能用 HomePod 来实现这些操作。比如 Overcast 5.0 已经支持了 Siri 捷径，在手机里设置完 Siri 捷径后，Siri 捷径会自动同步到 HomePod 上。此时我可以直接对着 HomePod 喊一句“Play podcast”（由于目前 HomePod 只支持英文 Siri，所以手机上的 Siri 也需要对应设成英文），HomePod 就会自动播放 Overcast 里的播客。更有趣的是，就算我当前手机正在播放着其它音乐，喊完语音指令后，音源也会切换到 HomePod 上。期待其它音乐媒体服务也能早日支持 Siri 捷径。

将 Overcast 添加到 Siri 捷径

除了音乐媒体服务，目前我最期待的是 IFTTT 和 Zapier 快点适配 Siri 捷径，这样就相当于 Siri 成了一个发射网络信号的中心，随时能指挥互联网上的各种服务。

所以与其说是 Siri 强化了 iOS 的自动化能力，不如说是 Siri 捷径强化了 Siri。

通过 Siri 建议来运行 Siri 捷径

Siri 捷径的运行方式除了自定义短语，还有 Siri 建议。

当手机检测到合适的时间、地点或者运动状态时，就会在锁屏界面、Spotlight、或者 watchOS 的 Siri 表盘中进行提醒，让你可以点击后直接运行 Siri 捷径。

通过 Siri 建议来运行 Siri 捷径

苹果在 Introduction to Siri Shortcuts 这场 WWDC Session 上举了这么一个例子：如果你经常在午餐时间点一份番茄汤加面包块，那么到了周五午餐时间，外卖应用就会自动建议你是否仍然点一份番茄汤加面包块。

Siri 捷径会预测你下次使用的时间

这里监测到的参数有午餐时间、番茄汤、加面包块。但由于用户的行为很复杂，我们可能会在操作中加入其它的因素，比如有些 iOS 应用还会检测我们滚动屏幕的位置，用于将当前页面 Handoff 至其它设备。这个参数就可能会对前面的例子造成困扰，因为滚动屏幕的位置通常没有规律，就会导致外卖应用最后给不出具体的建议。对此，开发者可以选择忽略一些选项，比如忽略掉滚动屏幕的位置，从而提升 Siri 建议的精度。

Siri 捷径也可以作为捷径模块

前面我们提到，模块是组成动作的基本零件。在以前，模块都是由 Workflow 自己生产的，第三方 App 无法直接添加或修改模块。而现在，通过 Siri 捷径，第三方应用也可以为捷径应用提供模块。实现的方式是，当第三方应用适配 Siri 捷径后，Siri 捷径会作为模块自动出现在捷径应用中。

在“Siri 建议”分类里，会推荐我们最近用过的 Siri 捷径；在底部的所有应用分类里，则会出现所有 Siri 捷径。

“Siri 建议”分类和“应用”分类里会出现 Siri 捷径

这也是我们接下来要谈的话题，当第三方应用可以为捷径应用提供捷径模块后，捷径应用本身有哪些提升？

捷径应用

捷径应用几乎继承了 Workflow 的所有功能，Workflow 能做到的事，捷径应用都能做。而且在这个基础之上，还改变了 Workflow 应用的运作模式，以及带来了一些功能提升。

每一个应用都可以为捷径应用提供模块

前面提到，Siri 捷径也可以作为捷径模块，这对 Workflow 原本的运作模式带来的改变是非常大的。

Workflow 原本的模式是：除了需要将 iOS 系统提供的 API 封装成一个个的模块，还需要主动去适配第三方应用的 API 和 URL Schemes，把第三方应用的功能也封装成一个个模块，最后再让用户自己拼装成完整的动作。

主动适配第三方其实是劳动量很大的工作，因此在 Workflow 应用中你也看得到，支持的第三方应用并不多，大部分都是国外比较知名的效率应用，而且有些支持的功能并不算丰富，其它类型的应用就更少了。

现在，当 Workflow 进化为捷径之后，不再需要主动去适配第三方应用，而是由第三方应用主动来适配捷径。也就是说，每一个应用都可以为捷径应用提供模块。

最初我和 Hum 讨论到这一点时，他提到了一个大胆的猜想：苹果想将软件功能模块化。因为这就像把所有 App 的功能都打碎了，然后放到捷径里，有一点打破了沙盒的感觉，App 和 App 之间可以互相使用对方的功能。但其实整个程序还是在沙盒的保护之中，因为所有的操作都是需要经过你的允许并且由你主动组装和运行的。

顺着这个猜想继续往下延展，也许日后我们可以自己“做 App”，用不同 App 提供的捷径模块拼装成一个“新的 App”，比如我们可以做一个“每日小报”的捷径动作。运行之后，会展示今天的日历安排、还剩哪些待办事项、天气如何、今天有哪些大新闻、支付宝里购买的基金涨赔、汇率变动等信息。

在这之前，要把这些信息全都汇总到一起，其实是比较麻烦的，甚至有可能实现不了，因为有些 App 内部的信息你是无法获取的，此外你多少也得懂点 API 的用法。捷径推出之后，以后可能都会有开发者替你把这些事情做好，我们只需要简单地进行组装就行了。也许再过一段时间，对捷径支持的完善程度，以及功能模块拆得是否够散，也会变成好 App 的新标杆。

不过随着捷径应用的正式发布，我们的猜想落空了一半。因为我们发现，第三方提供的捷径模块不能输入和输出数据。

什么意思呢，比如 Twitter 官方客户端有一个“发推”的捷径模块，这个模块只能打开发推的页面。就算我们在前面接一个输入文本的模块，文本内容也无法传递到这个“发推”的模块里。

测试文本没有被输入到“发推”模块中

又比如 Todoist 有一个展示今日待办事项的模块，我们也没办法把展示的任务内容抓取出来，发送给其它应用。你可以尝试在 Todoist 模块后面接一个“显示内容图”的模块，就会发现 Todoist 传递的数据空空如也。

Todoist 任务没有被输出到“显示内容图”模块中

这是捷径在开放性上做得不够完善的地方，第三方开发者提供的捷径模块还是无法和官方提供的相比。比如 Todoist、OmniFocus、Things、Bear、Evernote、Trello 等捷径模块，都是从 Workflow 时代留下的产物，第三方开发者没有办法提供这种既能输入和输出数据，还有丰富的参数可以调整的模块。

从 Workflow 时代留下来的 Todoist、Bear、Trello 模块

不过目前有一个比较取巧的方法，开发者们可以利用剪贴板来输入和输出数据。比如计算器应用 PCalc 提供的捷径模块，就很聪明地读取了我们剪贴板的数据，等换算完成后（比如换算汇率），再把新的数据替换到剪贴板上，完成了数据的输出。

通过反复调用剪贴板来传递数据

不过这种方法仍然是权宜之计，且不说剪贴板一来一回地获取和拷贝设置起来很麻烦；更重要的是，剪贴板支持的格式很有限。比如日历不仅仅是简单的文本，它还包含日期、地点等原数据，这是剪贴板所无法承载的。

因此，捷径其实并没有那么开放，可以说仅是打开了开放的半扇大门，另外半扇还关着。毕竟从以前的 Workflow 小团队到现在苹果公司，做事不能像以前那么随心所欲，考虑问题的时候也会更谨慎一些。

捷径应用有哪些提升？

此前 Workflow 被苹果收购时，Hum 在《深度解读：Workflow 被苹果收购，意味着什么》里的预测，基本都实现了。

Workflow 没有被苹果荒废，而是重新以闪耀的姿态回到大家眼前。从最近社交网络上的讨论热度，以及 Shortcuts Gallery 的受欢迎程度，就可以看出大家有多么关注捷径了。

回归后的捷径应用也获得了更高的权限，可以调用 HomeKit 设备，可以调用 Wi-Fi、勿扰模式、低电量模式等系统功能。

此外，我认为还有几个比较值得一提的变化：

1. 支持中文汉化

中文汉化的问题可以说是呼声已久，终于来了。不过我自己在使用时却遇到了一点问题。因为我以前一直在使用 Workflow，并没有因为 Workflow 不支持中文就不用它，所以当我切换到汉化后的捷径应用时，发现常常找不到模块。

即使我用原来的英文单词去搜，也发现搜不到，比如你不能用“repeat”搜到“重复”。而中英文互搜在 iOS 的 Spotlight 里是支持的。

2. 支持运行 JavaScript

捷径应用中新增了一个“在网页上运行 JavaScript”的模块，可以让我们运行 JavaScript 脚本，比如我们可以用它来替换当前网页的字体、获取当前网页元素。

不过这个模块只能在 Safari View Controller 中运行，使用场景比较局限。如果你想要更原生的 JavaScript 体验，我更推荐使用 JSBox，它可以调用更丰富的 iOS 原生接口，能做到的事情也更多，同时还有更舒适的代码编写环境。

3. “显示结果（Show Result）”模块

“显示结果”是一个可以跟 Siri 配合使用的模块，它其实有点像于以前的“显示提醒（Show Alert）”用于在屏幕上显示自定义文本。不同是的，“显示结果”可以用于 Siri 界面，并且在显示的时候也能通过 Siri 读出来。

比如我们可以先获取今天的待办事项以及日历，然后通过“显示结果”让 Siri 一次性念出来。

用“显示结果”让 Siri 帮我们念出多种内容

结语

我使用 Workflow，以及使用捷径的心路历程，其实和一些 Power+ 的读者很像。刚开始在看到这些工具时，不一定能立刻想出适合自己的使用场景。但是当自己真正遇到相关的问题时，才想起 Workflow / 捷径这么一个解决问题的利器。

捷径其实和 Workflow 一样，应用本身没什么功能，都是一些拆散的模块，就看我们怎么去利用和拼装它们。

如果说 URL Schemes 是 iOS 自动化的 1.0 时代，让多个 App 串联到一起成为了可能；那么 Workflow 就是 iOS 自动化的 2.0 时代，融入了模块化编程的思想，让不懂代码的用户也能轻松做出属于自己的工作流；或许以后，捷径将会是 iOS 自动化的 3.0 时代，打破 App 的边界，把 iOS 自动化提升到了一个新的高度。