Matrix 首頁推薦
文章代表作者個人觀點，少數派僅對標題和排版略作修改。
前言
使用了企業微信之後，我發現雖然已經沒有微信那樣的不堪，勉強能夠勝任日常的工作溝通與交流，但我仍覺得似乎被什麼東西束縛住了，尤其對於我這種喜歡折騰的人來說少了點自由的 氣息，比如在所謂的「自動化」方面。
自動化（Automation）一詞其實是一個很大的概念，但顧名思義其實就是將需要人為、機械且重複的行為，透過軟體或編碼的方式來實現同樣的效果，這個過程就是自動化。具體來說就是：每小時給我傳送當前的天氣預報、每天早晨準時給我傳送少數派早報的標題內容、每個周定時備份我 XXX 專案下的所有檔案等等。
因為企業微信面向的主要還是像公司這樣的集體組織，無法提供適應個人層面的自動化服務或介面，如果需要進行相關內部的應用開發必須要由公司企業微信的管理員去操作。
直到我遇上了飛書。它在滿足了日常工作協作的需要的同時，還留有讓喜歡折騰的數字玩家們進一步探索的地方，比如：Webhook。
建立自定義機器人
飛書允許使用者在群組中建立一個自定義機器人，將其他渠道的訊息透過 Webhook 的方式推送至該群組中。
Webhook 顧名思義即網路鉤子，也稱為使用者自定義 HTTP 回撥函式（user-defined HTTP callbacks），通常用於監聽某些行為事件，當事件觸發時會向用戶指定的目標地址傳送資訊。
這段話對於大多數沒有計算機基礎知識的讀者來說可能難以理解，但卻無關緊要，因為我們只需要可以將其理解為「中間人」即可：
張三
到百貨商場買東西，
店員
告知他要買的東西暫時沒貨了，可以先登記一下他的聯絡方式，補貨後第一時間通知他過來購買。
過了一段時間
進貨
之後，店員根據留下的
聯絡方式
聯絡了張三，告知其到貨了可以過來購買了。
這是我們在日常生活中很常見的一種場景，也和整個 Webhook 的運作流程類似：
張三：即飛書群
店員：即 Webhook，用以監聽是否進貨，並且根據登記的聯絡方式進行通知
是否進貨：觸發條件（Trigger）
聯絡方式：目標地址（URL）
因此，飛書的自定義機器人本質上也就是提供了這樣
「監聽-通知」
的行為邏輯，讓使用者能夠將訊息轉發到飛書上。
建立一個自定義機器人的方式很簡單，你只需要在飛書介面進行「點選加號-建立群組-設定-群機器人」幾步操作。
然後再點選「新增機器人」按鈕進入到新增介面，選擇第一位的「自定義機器人即可」。
新增完成之後我們只需要預設下一步即可。
定製訊息型別
建立自定義機器人僅表明我們搭起了一箇中轉的「驛站」，但我們還需要能夠向這個驛站傳送相關的訊息才能讓其幫我們實現轉發。
飛書目前支援的訊息型別主要有如文字、富文字、互動式卡片等，不同的訊息型別對應著不同格式的 JSON 資料。
什麼是 JSON？
JSON（JavaScript Object Notation，即 JavaScript 物件表示法），是目前在 Web 領域裡被廣泛用於資料傳遞與交換的檔案格式之一。JSON 通常由鍵值對構成，就像這樣：
而我們的訊息也是需要以這種格式來發送，當中包含的是關於該訊息的型別、內容、其他引數等資訊。
普通文字
在飛書所支援的幾種訊息型別裡，最簡單的莫過於普通文字。其對應的 JSON 格式比較簡單：
最後呈現的效果也是我們在日常使用微信溝通時看到的那種樣式。
富文字
如果你需要給訊息內容增添一些樣式，如連結、圖片等，那麼你可以選擇富文字訊息型別。
富文字主要就類似於 Markdown 的語法，同樣具備所見即所得的特點，能夠很好地渲染成 HTML 元素。但飛書支援的富文字元素主要就四種：
：普通文字
：超連結
： 符號
：圖片
因為 標籤需要獲取到目標使用者的 ID 引數而 需要事先將圖片上傳到其他介面，所以會相對複雜一些，有需要的朋友可以自己探索。
相比於普通文字樣式來說，富文字樣的 JSON 樣式相對複雜一些：
由於飛書支援 i18n（internationalization）國際化顯示，所以需要將內容填寫在對應語言下面，比如上述的。但如果我們沒有翻譯成其他語言的需要，那就只需要在例子中的 的部分填寫內容即可：
表示標題
表示所有內容，每一行內容是包含了若干元素標籤的陣列
最後就可以呈現出如下樣式：
訊息卡片
訊息型別裡最為複雜的是互動式訊息卡片。
因為訊息卡片的規範較多，以至於飛書官方專門用了一定篇幅的文件來告知開發者如何去設計訊息卡片。
簡單來說，訊息卡片主要由兩部分構成：
訊息頭
和
訊息主體內容
。
基本的訊息卡片結構所對應的 JSON 樣式為：
訊息頭主要就是帶有色塊的標題，用以增強資訊的視覺錨點1，對應 部分的內容。通常我們只需要填寫當中的 的標題內容以及 標題主題顏色即可定下訊息卡片的標題展示效果。
讓訊息卡片變得複雜的原因是在於訊息主體內容，因為主體內容從形式上就像是 HTML 元素，可以進行多種組合，所以這一部分主要都在 中進行填寫。
但在實際的使用過程中我們不會手動去編寫對應的訊息內容，而是透過飛書的卡片搭建工具來幫助我們做出想要的樣式。
在這個設計工具中，我們可以在「模組元件」中去搭建適合自己需要的訊息卡片；同時，我們也可以在「卡片模板」中選擇飛書為我們已經內建好的卡片模板，根據自己的需要去對模板進行調整。
但無論你是打算用哪種方式，最後只需要能在預覽中顯示無誤，就可以直接將右側的程式碼預覽中的內容複製貼上到前面基礎結構 JSON 中的 部分即可。
這裡我就基於前面已選擇的模板進行簡單調整，然後實現一個少數派社群文章推薦的訊息卡片樣式：
最後將右側的程式碼直接複製複製，然後經由程式推送至 Webhook 後再轉發到飛書上。
為你的訊息機器人加上安全設定
由於只要我們透過向 Webhook 地址傳送網路請求就能夠將訊息推送至飛書，因此倘若不經意間 Webhook 地址被洩露在網際網路上，那麼很有可能會接收到許多垃圾訊息，也容易埋下未知的資訊保安隱患。這就好比你出門時卻不鎖門一樣讓人惴惴不安。
因此在使用飛書 Webhook 推送訊息的基礎上，最好是加上相關的安全策略或設定以提升安全性。在飛書的官方文件裡飛書提供了三種安全策略，並且三種方式可以
疊加設定
。安全等級由低到高依次是：
自定義關鍵詞
：只推送包含特定關鍵詞的訊息
IP 白名單
：只推送由白名單 IP 傳送的訊息
安全金鑰
：只推送帶有指定金鑰資訊的訊息
其中，前兩種方式比較簡單，我們只需要勾選之後就可以直接設定，但新增的數量最大限制都為 10 個。
最後一種方式需要我們能夠生成金鑰，並在推送訊息的 HTTP 請求中攜帶上關於金鑰的資訊引數。生成金鑰最快捷的方式就是透過程式碼來實現，因為飛書開發者文件中給出了不同程式語言的示例 Demo，雖然可能不一定覆蓋到所有程式語言，但其生成金鑰的方式都是大同小異的：
將當前時間戳和簽名校驗碼透過換行符 拼接在一起作為金鑰字串簽名
使用HMAC-SHA256 演算法對該字串簽名進行加密
最後使用Base64 編碼對加密後的字串簽名進行編碼，便於作為引數傳遞
經過以上三步生成金鑰之後，我們就可以在傳送訊息推送時帶上安全金鑰以便飛書伺服器校驗。這裡我基於飛書官方的 Python 示例進行簡單修改，僅供參考：
有了校驗之後即便 Webhook 地址洩露了，但只要沒有拿到我們的簽名校驗就無法生成金鑰，也就無法往我們的訊息機器人推送訊息了，這就使得安全性得到進一步保障。
但以上生成金鑰的過程都是在程式中完成，如果你是想要在開啟簽名校驗的安全設定情況下，使用其他 APP 將訊息轉發至飛書，那麼需要對應的 APP 支援金鑰生成的同時，還需要能定製對應的 JSON 請求體。
應用
飛書群組裡的自定義機器人的功能可能沒有像 Telegram Bot 那樣豐富，其主要用途還是作為一個
訊息推送
的中心，將其他來源的資訊或訊息經過 Webhook 轉發到飛書群組裡，所以像今日運勢、流量監控、異常警告等場景就非常適合使用飛書自定義機器人來實現自動化。
實現自動化的途徑可以透過程式碼、APP 或是其他第三方服務，根據個人需要去選擇、嘗試。
自動推送訊息
作為一個每週五下班都不帶電腦回家的開發 boy 來說，為了避免有時需要改 Bug 或是訪問公司伺服器資源時我需要用到公司電腦的情況發生，我通常都會使用公司的 VPN 和微軟的遠端桌面工具連線到我在公司所使用的 Windows 膝上型電腦，這樣我就只需要遠端操作即可。
但實現遠端操作的前提是：我必須知道我所使用的那臺筆記本的內網 IP 地址是什麼。
所以我就根據飛書的開發文件用 Python 編寫了一個指令碼，接著配合微軟的任務計劃程式，在每週五下午 19 點時執行並獲取電腦當前的內網 IP 地址，並透過自定義機器人推送到飛書。
這裡我基於前面安全設定部分的程式碼進行了一些改動，將其封裝了進了一個名為 的類中，所以這個類包含前面所涉及的安全校驗和訊息傳送兩部分功能：
由於我是用程式碼來實現，所以建立金鑰會相對方便，因此開啟簽名校驗的同時，在建立 的例項化物件的過程中攜帶上安全校驗的字串程式碼，否則會丟擲異常；
其次，在前面一部分章節示例中的 函式程式碼都被封裝到了 方法裡，於是我們只需要建立好 物件後再呼叫該方法並傳入一個想要傳送的內容字串，就可以將訊息推送至飛書：
當中的 部分是可替換的，你可以替換成符合你需要的內容，比如今日運勢、頭條文章、熱搜 TOP10 等等，只要你能獲取得到相關內容或資料，並轉換成字串即可。但因為我是需要獲取到工位上的電腦 IP，所以上面部分就改成了：
這裡我透過呼叫 Windows 上檢視網路內容的 命令獲取到輸出的內容後，再透過正則表示式去將包含特定 IP 的那一串文字中的數字部分抓出來，並推送。
之後我將整個指令碼儲存成一個 程式碼檔案後，透過定時任務新增計劃，當達到觸發時限，則會透過指定的 Python 直譯器可執行程式來執行該指令碼。
Webhook 轉發 Webhook
在少數派的作（鴿）者（子）群中曾看到了我派編輯部「六個漢堡」代言人路中南想要透過
通知濾盒（Android）
這一 APP 將群裡的一些訊息轉發至飛書的想法，也這是飛書自定義機器人一個不錯的適用場景。
因為通知濾盒在 2。0 版本之後有了添加了 Webhook 的功能（需要付費訂閱或買斷高階版），所以本質上也是和飛書類似，將過濾的訊息進行轉發。
需要說明的是：由於通知濾盒的 Webhook 功能
仍處於開放測試階段
，尚有不少的 BUG，僅能傳送 POST 請求，而無法傳送 GET 請求；並且目前也無法在通知濾盒裡直接定製傳送的請求體內容，因此只能使用飛書舊版的自定義機器人來實現訊息轉發。
當我們進入到通知濾盒後，點選左下角的規則，並選擇「增強-Webhook」建立一個新的配置。在填寫配置資訊的過程中，可以根據你自己的實際需要來指定特定特定的 APP、內容和時間，以及手機處於何種狀態時才會轉發的條件，還有最後要轉發的目標 Webhook 地址。
因為是轉發微信的相關訊息，所以這裡我將 APP 設定為包含微信，然後內容設定為一串測試的正則表示式。
儲存之後我們只要每次接收到了相關訊息，通知濾盒就會直接將訊息轉發到飛書上了。
除了訊息濾盒，你還可以將其替換成
任意支援 Webhook
的 APP 或是服務，比如 QQ、IFTTT、Github 等，實現 Webhook 轉 Webhook 最終將訊息傳送至飛書的「套娃玩法」。
結尾
長久以來我一直覺得國內的軟體或平臺在自動化和 API 開放化上做得比國外的差：
一方面，廠商都不願將成本投入到這隻屬於「少數玩家」的需求開發。畢竟有自動化需求的往往只是一小撮人，而這部分功能無論是開發還是維護卻都是有著不小的成本開銷，收益不成正比；
另一方面，就是想要實現「生態壟斷」。無論是連結跳轉還是下載 APP，處處表露著廠商想要獲取流量並構造自己生態（或服務）壁壘的封閉行徑，而開放就意味著會造成使用者流失。
所以有的時候我很喜歡 Telegram、Slack、Todolist、Toggl 等軟體有著很好開放性，在能夠整合很多第三方軟體的同時，又放開 API 並有著豐富的文件供喜歡折騰的玩家們去自由發揮。
而飛書是國內為數不多具有開放性的工具或平臺之一。
相比於微信、企業微信來說盡管它可能還只是個勇於挑戰「老大哥」的「黃毛小子」，但在使用的過程中不難發現它確實解決掉了一些我們在使用「壟斷式」即時通訊軟體的痛點，也滿足了「少數派玩家」們折騰的心願。
因此無論是像公司這樣的集體組織，還是像我們一樣的獨立個人使用者，都能在日常使用飛書的過程中受益。