iOS自動化的3.0時代

相信很多少數派的讀者都和我一樣，當 WWDC 舞台上出現了 Shortcuts 時，瞬間兩眼放光：“咦？這不是 Workflow 嗎？”

Workflow 是一款 iOS 上的自動化應用，可以將多個 App 裡的功能串起來，讓它們自動運行，形成一個工作流。 比如我們可以讓 Workflow 獲取相冊裡的最後一張截圖進行標註，然後進行自動裁剪，接下來選擇分享到社交網絡，最後自動刪除這張截圖。

Workflow 的魔力就在於，直接拆散了 iOS 的大部分功能，然後由我們來自由組裝。 這既可以縮減跳轉應用的步驟，也能讓很多之前完全不相關的功能串到一起。 很多人評價 Workflow 都會提到這句話：“模塊化編程的思維”。 我們不要被“編程”這兩個字嚇到，Workflow 的大部分功能都跟代碼無關，我們只需要調一調開關就行了，這句話想說的是它們的思維方式很像——零件都 幫你準備好了，就看你怎麼組裝它們。

2017 年 3 月，這款充滿魅力的應用被蘋果收購，應用本身以及四位開發者都加入了蘋果。 此後 Workflow 有過幾次更新，但都算不上大變化。 外界一直在猜想 Workflow 將會以怎樣的方式融入 iOS，會帶給這個生態怎樣的變化。

直到今年 WWDC，我們終於見到了脫胎換骨的 Workflow——捷徑。 捷徑很明顯是 Workflow 在 iOS 中整合後的成果，兩款應用的界面極其相似，包括模塊化的功能、拖拽的交互方式、通知中心小部件、以及提供下載的捷徑中心。

繼承了 Workflow 的捷徑

捷徑基本上繼承 Workflow 的主要特點，包括了應用的組成結構，以及使用方法。 不過由於蘋果官方對待捷徑的叫法實在容易讓人產生疑惑，在不同語境下也會造成不必要的誤解，所以我們先來明確一下幾個名詞的意思：

捷徑應用/App： 蘋果推出的獨立應用，通過 App Store 下載；

捷徑動作： 捷徑應用中每個可以運行的動作，比如前文提到的處理圖片的整個流程，就是一個捷徑動作；

捷徑模塊： 每個捷徑動作由一個或多個捷徑模塊組成，可以說捷徑模塊就是捷徑動作的零件。

（注：以上所有的“捷徑 ” 都可以替換成英文名稱 “ 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 的功能。 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。 我有特別注意到，他們兩位都隸屬 Siri 部門，這就更加說明了蘋果收購 Workflow 的目的——奔著融入 Siri 去的，兩位都直接加入了 Siri 部門。

Siri 作為智能語音助手的角色，一直以來走的都是 自然語言處理 的路子，也就是分析用戶說的每句話的語法結構，每個詞每個字是什麼意思，並且嘗試去理解同一句話的不同表達方式。 而亞馬遜的 Alexa 走的則是另一個路子，它非常開放，允許第三方應用定義命令，並且用戶也可以藉助 IFTTT 自定義短語。

換句話說，很多時候Alexa 並沒有聽懂你說了什麼，它只是識別到你說了一句提前設定好的短語，然後根據設定去執行而已，如果你換個表達方式，它就會執行失敗 。

在前年的  The Talk Show Live From WWDC 2016  上，蘋果軟件高級副總裁Craig Federighi 談到他們努力讓Siri 明白用戶的多種表述方式，以及他們會自己完善開發Siri 在各個領域的語言處理能力，然後再由開發者接入進來，而不是直接 把理解用戶命令的任務丟給開發者。 Craig 甚至還有些不齒這樣的做法，他說如果僅憑關鍵詞來觸發命令的話，那其實對於蘋果公司來說非常簡單。

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 上使用第三方音樂媒體服務只能執行一些簡單的語音指令，比如“暫停、快進快退、切歌、調整音量”這些，而像下面這些更複雜 的語音指令，第三方音樂媒體服務就無法做到：

而現在藉助 Siri 捷徑，就能用 HomePod 來實現這些操作。 比如 Overcast 5.0 已經支持了 Siri 捷徑，在手機裡設置完 Siri 捷徑後，Siri 捷徑會自動同步到 HomePod 上。 此時我可以直接對著 HomePod 喊一句“Play podcast”，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. “顯示結果 ”模塊

“顯示結果”是一個可以跟 Siri 配合使用的模塊，它其實有點像於以前的“顯示提醒”用於在屏幕上顯示自定義文本。 不同是的，“顯示結果”可以用於 Siri 界面，並且在顯示的時候也能通過 Siri 讀出來。

比如我們可以先獲取今天的待辦事項以及日曆，然後通過“顯示結果”讓 Siri 一次性念出來。

結語

我使用 Workflow，以及使用捷徑的心路歷程，其實和一些 Power+ 的讀者很像。 剛開始在看到這些工具時，不一定能立刻想出適合自己的使用場景。 但是當自己真正遇到相關的問題時，才想起 Workflow / 捷徑這麼一個解決問題的利器。

捷徑其實和 Workflow 一樣，應用本身沒什麼功能，都是一些拆散的模塊，就看我們怎麼去利用和拼裝它們。

如果說URL Schemes 是iOS 自動化的1.0 時代，讓多個App 串聯到一起成為了可能；那麼Workflow 就是iOS 自動化的2.0 時代，融入了模塊化編程的思想，讓不懂代碼的用戶也能輕鬆做出 屬於自己的工作流；或許以後，捷徑將會是iOS 自動化的3.0 時代，打破App 的邊界，把iOS 自動化提升到了一個新的高度。