「捷徑」解讀：iOS 自動化的 3.0 時代
相信很多少數派的讀者都和我一樣，當 WWDC 舞臺上出現了 Shortcuts 時，瞬間兩眼放光：「咦？這不是 Workflow 嗎？」
Workflow 是一款 iOS 上的自動化應用，可以將多個 App 裡的功能串起來，讓它們自動執行，形成一個工作流。比如我們可以讓 Workflow 獲取相簿裡的最後一張截圖進行標註，然後進行自動裁剪，接下來選擇分享到社交網路，最後自動刪除這張截圖。
Workflow 的魔力就在於，直接拆散了 iOS 的大部分功能，然後由我們來自由組裝。這既可以縮減跳轉應用的步驟，也能讓很多之前完全不相關的功能串到一起。很多人評價 Workflow 都會提到這句話：「 模組化程式設計的思維 」。我們不要被「程式設計」這兩個字嚇到，Workflow 的大部分功能都跟程式碼無關，我們只需要調一調開關就行了，這句話想說的是它們的思維方式很像——零件都幫你準備好了，就看你怎麼組裝它們。
2017 年 3 月，這款充滿魅力的應用被蘋果收購，應用本身以及四位開發者都加入了蘋果。此後 Workflow 有過幾次更新，但都算不上大變化。外界一直在猜想 Workflow 將會以怎樣的方式融入 iOS，會帶給這個生態怎樣的變化。
直到今年 WWDC，我們終於見到了脫胎換骨的 Workflow—— ofollow,noindex">捷徑 （英文名：Shortcuts）。捷徑很明顯是 Workflow 在 iOS 中整合後的成果，兩款應用的介面極其相似，包括模組化的功能、拖拽的互動方式、通知中心小部件、以及提供下載的捷徑中心。
繼承了 Workflow 的捷徑
捷徑基本上繼承 Workflow 的主要特點，包括了應用的組成結構，以及使用方法。不過由於蘋果官方對待捷徑的叫法實在容易讓人產生疑惑，在不同語境下也會造成不必要的誤解 360036">1 ，所以我們先來明確一下幾個名詞的意思：
-
捷徑應用/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 捷徑」找到它們，然後設定自定義短語。
此外，第三方開發者也可以使用蘋果提供的捷徑 API，為自己的 App 設計 Siri 捷徑。捷徑 API 有兩種：
-
第一種叫 NSUserActivity，可以實現比較簡單的操作，比如直接開啟 App 裡面的某個介面，或者開啟已經在 Spotlight 裡可以索引的、已經提供給 Handoff 的功能 2 。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。 3 我有特別注意到，他們兩位都隸屬 Siri 部門，這就更加說明了蘋果收購 Workflow 的目的——奔著融入 Siri 去的，兩位都直接加入了 Siri 部門。
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」這種簡短直接的短語。
甚至，你還可以設定更短的短語。比如，Hum 曾經在 Power+ 的 Slack 群中分享過一個在 iPad 上用鍵盤就能快速翻譯網頁的 Workflow 動作（ 點此下載 ）。因為我的 iPad Pro 長時間連著外接鍵盤，因此開啟了Type to Siri 功能，所以我就把這個動作的 Siri 捷徑短語設定為 GT 。每當我需要翻譯網頁時，只需先複製網頁連結，然後長按 Home 鍵喚出 Type to Siri，再輸入 GT ，就能自動執行 Google 翻譯的 Workflow 動作，比之前的步驟要簡單一些。
用 Siri 捷徑執行 Google 翻譯網頁的 Workflow 動作
這種操作的好處是不用思考和選擇，長按 Home 鍵後，直接輸入關鍵詞（甚至是無意義的關鍵詞），然後回車，一氣呵成。
有了 Siri 捷徑的幫助，反而讓我開始覺得 Siri 有戲。當然 Siri 在自然語言識別、搜尋結果整合等方面還是要繼續提高，但能夠使用自定義短語這一點就足夠讓我感到興奮。因為自定義短語與智慧無關，而是一種有標準答案的互動方式，它雖然簡單粗暴，但足夠實用，而且還可以配合 HomePod 使用，做到很多之前實現不了的操作。
我在 HomePod 測評裡曾提到，在 HomePod 上使用第三方音樂媒體服務只能執行一些簡單的語音指令，比如「暫停、快進快退、切歌、調整音量」這些，而像下面這些更復雜的語音指令，第三方音樂媒體服務就無法做到：
- 當你剛回到家時，無法直接對 HomePod 喊一句「播放 Spotify 裡的歌曲」；
- 無法挑選專輯、歌手、歌單、電臺等內容；
- 無法執行儲存至音樂庫、將歌曲新增至歌單等操作；
- 無法對歌曲執行「喜歡、不喜歡」操作。
而現在藉助 Siri 捷徑，就能用 HomePod 來實現這些操作。比如 Overcast 5.0 已經支援了 Siri 捷徑，在手機裡設定完 Siri 捷徑後，Siri 捷徑會自動同步到 HomePod 上。此時我可以直接對著 HomePod 喊一句「Play podcast」 4 ，HomePod 就會自動播放 Overcast 裡的播客。更有趣的是，就算我當前手機正在播放著其它音樂，喊完語音指令後，音源也會切換到 HomePod 上。期待其它音樂媒體服務也能早日支援 Siri 捷徑。
除了音樂媒體服務，目前我最期待的是 IFTTT 和 Zapier 快點適配 Siri 捷徑，這樣就相當於 Siri 成了一個發射網路訊號的中心，隨時能指揮網際網路上的各種服務。
所以與其說是 Siri 強化了 iOS 的自動化能力，不如說是 Siri 捷徑強化了 Siri。
通過 Siri 建議來執行 Siri 捷徑
Siri 捷徑的執行方式除了自定義短語，還有 Siri 建議 。
當手機檢測到合適的時間、地點或者運動狀態時，就會在鎖屏介面、Spotlight、或者 watchOS 的 Siri 錶盤中進行提醒，讓你可以點選後直接執行 Siri 捷徑。
蘋果在 Introduction to Siri Shortcuts 這場 WWDC Session 上舉了這麼一個例子：如果你經常在午餐時間點一份番茄湯加麵包塊，那麼到了週五午餐時間，外賣應用就會自動建議你是否仍然點一份番茄湯加麵包塊。
這裡監測到的引數有午餐時間、番茄湯、加麵包塊。但由於使用者的行為很複雜，我們可能會在操作中加入其它的因素，比如有些 iOS 應用還會檢測我們滾動螢幕的位置，用於將當前頁面 Handoff 至其它裝置。這個引數就可能會對前面的例子造成困擾，因為滾動螢幕的位置通常沒有規律，就會導致外賣應用最後給不出具體的建議。對此， 開發者可以選擇忽略一些選項 ，比如忽略掉滾動螢幕的位置， 從而提升 Siri 建議的精度 。
Siri 捷徑也可以作為捷徑模組
前面我們提到，模組是組成動作的基本零件。在以前，模組都是由 Workflow 自己生產的，第三方 App 無法直接新增或修改模組。而現在，通過 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、OmniFocus、Things、Bear、Evernote、Trello 等捷徑模組，都是從 Workflow 時代留下的產物，第三方開發者沒有辦法提供這種既能輸入和輸出資料，還有豐富的引數可以調整的模組。
不過目前有一個比較取巧的方法，開發者們可以 利用剪貼簿來輸入和輸出資料 。比如計算器應用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 一次性念出來。
結語
我使用 Workflow，以及使用捷徑的心路歷程，其實和一些 Power+ 的讀者很像。剛開始在看到這些工具時，不一定能立刻想出適合自己的使用場景。但是當自己真正遇到相關的問題時，才想起 Workflow / 捷徑這麼一個解決問題的利器。
捷徑其實和 Workflow 一樣，應用本身沒什麼功能，都是一些拆散的模組，就看我們怎麼去利用和拼裝它們。
如果說 URL Schemes 是 iOS 自動化的 1.0 時代，讓多個 App 串聯到一起成為了可能；那麼 Workflow 就是 iOS 自動化的 2.0 時代，融入了模組化程式設計的思想，讓不懂程式碼的使用者也能輕鬆做出屬於自己的工作流；或許以後，捷徑將會是 iOS 自動化的 3.0 時代，打破 App 的邊界，把 iOS 自動化提升到了一個新的高度。