「站會提醒發了嗎？」「這張假單簽到哪一關了？」「這週輪到誰值班？」這些問題每天在各種群組裡重複出現，答案其實都能寫成清楚的規則，卻常常靠人腦記著、靠人手一則一則發。把規則交給機器人（bot），是團隊遲早會走到的一步。
Atlassian《The State of Teams 2026》的調查裡，87% 的知識工作者自述當所有人都在趕執行時，連協調的時間或餘裕都沒有；而那些協調工作裡，提醒、催辦、轉貼、輪值通知這類規則明確的雜務往往佔了不少。艾瑞特資訊是 Lark 台灣授權代理商，立場自然偏 Lark，因此只做可被檢驗的事：Slack 的說法一律回官方頁面，Lark 的行為一律回站內知識庫，讓 IT 決策者自己判斷哪條路適合團隊。
bot 能自動化的四類工作：通知、收集、查詢、審批
機器人能接手的日常工作，大致落在通知、收集、查詢、審批四類；先分清楚類別，才知道哪一條建立路線划算。這四類的規則長相不同，實作難度也差很多，混在一起談只會愈談愈亂。
| 類別 | 典型場景 | 規則長相 |
|---|---|---|
| 通知 | 站會提醒、狀態變更告知、到期提醒 | 到某個時間、或某欄位變成某個值，就發訊息給某人 |
| 收集 | 請假申請、需求單、每日回報 | 用表單收資料，存成一筆可查詢的記錄 |
| 查詢 | 「今天誰值班」「這張單到哪了」 | 依條件找出符合的記錄，回報給提問的人 |
| 審批 | 請假、報銷、用印 | 依表單內容送到對的人，逐關推進並留痕 |
前三類的共同點是規則死、頻率高，很適合交給機器人；審批則多了「逐關推進」的流程性，單關確認和多階段簽核的難度不在一個量級。認清這點，選型時就不會拿殺雞的刀去砍牛，也不會拿砍牛的刀去殺雞。想更系統地盤點哪些工作值得先自動化，可以先用頻率 × 規則性四象限篩一輪。
Slack bot 怎麼建立：API 開發與 Workflow Builder 兩條路
Slack 要做自動化有兩條路：走 Slack API 自建 app、或用內建的 Workflow Builder，兩者的門檻與彈性差很多，選錯就會白花力氣。搞清楚各自的樣子，比急著動手更重要。
**開發者路線（走 Slack API）**是兩條路裡彈性較大、門檻也較高的一條。依 Slack 官方開發者文件（2026-08-13 查核），建立 app 的建議做法是使用 Slack CLI 與 Bolt 框架：官方原文寫「We recommend using the CLI and the Slack Bolt framework for simplicity in creating an app.」，並要你「run your app locally with the Slack CLI」、到 OAuth & Permissions「install your app to your workspace to generate a token」、把開頭為 xoxb 的 bot token 存進環境變數。換句話說，這條路要寫程式、要讓一個 app 持續運行、要自己處理權限與金鑰。它的回報是幾乎沒有邏輯上限，還能接上 Slack 目錄裡超過 2,600 種應用（例如 Salesforce、Jira），對工程文化強、已經習慣英文工具鏈、手上有開發資源的團隊來說，這是把自動化做到極致的正解。
Workflow Builder 則是 Slack 內建、不用寫程式的自動化工具。官方〈Guide to Slack Workflow Builder〉（2026-08-13 查核）寫它「helps you automate everyday tasks and processes in Slack」，且「Workflows can be as simple or as complex as you’d like, and can even be connected to other apps」；流程可以「start on a schedule」自動開跑，也可以用連結、表情符號、加入頻道等方式觸發，還能加條件分支。它有兩個要先知道的邊界：一是方案分界：依 Slack 定價頁，免費版含功能受限的基礎 Workflow Builder，條件分支、自訂步驟與外部 connectors 等進階功能才需付費方案（實際界線以官方最新公告為準）；二是它以「在 Slack 頻道內跑訊息與表單流程」為主，要接資料庫或外部系統得靠 connectors 外接。以簽核來說，Slack 的 Workflow Builder 可以拼出單步簽核，多階段流程實務上需要外接。對已經在用 Slack 付費方案、流程又集中在頻道內的團隊，Workflow Builder 會是順手的選擇。
Slack 兩條路各自的金額與方案權益，以官方定價頁的最新公告為準。決策者真正要問的不是「Slack 能不能做」，而是「用哪條路做、成本落在哪」：開發者路線的成本在工程人力與後續維運，Workflow Builder 的成本在付費方案與頻道內的場景侷限。
不用寫程式的替代做法：Lark Bot 加 Base 自動化
如果不想自建 app、也不想把自動化綁在單一即時通訊平台的付費方案上，Lark 的做法是用 Base 自動化搭配 Lark 機器人，全程圖形介面、不寫一行程式。這條路的關鍵差別不在「寫不寫程式」（Slack 的 Workflow Builder 同樣不寫程式），而在 Base 本身就是一個資料庫，所以收集與查詢那兩類工作天生不必再外接一套系統。
Lark 的群組機器人分兩種：應用機器人在開發者後台建立、可用於群聊與單聊、能接收並回覆訊息；自訂機器人直接在群組裡建立、走 Webhook、僅推送訊息。前者適合要雙向互動的情境，後者適合把外部系統的通知推進群組，一個群組最多可加 15 個機器人。不過對多數不寫程式的自動化需求來說，真正的主力是 Base 自動化。
Base 自動化的設定邏輯很單純：先選「觸發條件」，再選「執行操作」，多維表格就會依規則自動跑。觸發條件涵蓋新增記錄、修改記錄、滿足條件、到達記錄中的時間、定時、點擊按鈕等；執行操作涵蓋發送 Lark 訊息、新增／修改／查找記錄、發送 HTTP 請求、延遲等。啟用權限限多維表格所有者、或對表有可管理權限且與所有者同企業的成員。這裡有一項一定要先揭露的邊界：自動化執行次數依方案有月配額，標準版與基礎版各 1,000 次、專業版 5 萬次、旗艦版 50 萬次，按整個企業維度計算、到上限後於次月 1 日重新計算，方案權益以官方最新公告為準；規劃大量流程前，先把配額留給高價值的流程。
以下用三個現成範例，把「通知、收集、查詢」對應到具體的 Base 自動化做法，每一個都不需要技術背景。
範例一：每日站會提醒（定時觸發 × 發訊息）
每日站會提醒的規則很單純：到固定時間，機器人自動在專案群組發一則提醒，不必有人記得開口。這類需求規則死、頻率高，適合作為第一條自動化的起點。
做法只有三步。第一步，在自動化流程裡把觸發條件選「定時」，設定每個工作日的固定時間（例如上午九點半），並開啟重複。第二步，執行操作選「發送 Lark 訊息」，對象選專案群組。第三步，儲存並啟用。若只是固定一句話的提醒，其實用訊息裡的定時訊息就能發，不必動用 Base；但只要你希望提醒帶上當日的實際資料，例如自動列出昨天卡關、今天到期的任務，就得靠 Base 自動化去引用記錄欄位，讓提醒不只是空喊「該開站會了」。
有一個容易踩到的細節值得先知道：定時觸發若設在每月 31 日，遇到沒有 31 日的月份會直接跳過、不觸發（二月同理）；設了截止日期時，截止日當天也不會觸發。站會提醒設在每個工作日就沒這個問題，但做月結、季報這類提醒時，這個日期規則要記在心裡。
範例二：表單進度通知（記錄變更 × 卡片按鈕）
表單進度通知解決的是「下游一直來問進度」：資料一變動，該知道的人自動收到一張帶按鈕的卡片。收集與通知在這裡接成一條線，單子從送出到結案，沒有人需要盯著看。
先用 Base 的表單收單，成員填完送出就自動新增一筆記錄；接著建兩條自動化。第一條的觸發條件選「新增記錄時」，執行操作發訊息給承辦人，並在訊息卡片加上交互按鈕，例如「已受理」「退回補件」。第二條的觸發條件選「修改記錄時」、關注「狀態」欄位，當狀態改成「已完成」就發訊息通知原申請人。卡片按鈕的好處是接收人不必打開多維表格，直接在卡片上點選，結果會自動記錄回表，也可以設「僅允許點擊一個按鈕」避免誤按第二次。
這裡也有一條要誠實說清楚的界線：卡片按鈕很適合「單關確認」與任務督辦，但如果流程是要逐關會簽、依金額大小分流給不同層級的主管，那屬於多階段簽核，用 Lark 原生的審批模組來做會比硬拿 Base 自動化拼更穩，也更容易留下合規需要的簽核軌跡。Base 自動化負責通知與單關確認，審批模組負責多關流程，兩者分工而不是互相硬湊。
範例三：值班輪替（查找記錄 × 到達時間）
值班輪替把「今天輪到誰」從靠記憶變成靠資料表：排班表填好，機器人每天自動找出當班的人並通知，交接不再漏人。查詢這一類工作的價值，在值班輪替裡看得特別清楚。
先建一張值班表，至少兩個欄位：值班日期（日期欄位）、值班人（人員欄位）。接著建自動化：觸發條件用「到達記錄中的時間時」指向值班日期欄位，或用「定時」每天早上跑一次；執行操作先用「查找記錄」依條件篩出今天當班的那筆，再「發送 Lark 訊息」給該值班人與值班群組，訊息裡引用日期與交接注意事項。要提醒的是，「到達記錄中的時間時」是一次性觸發、不支援週期，只認日期欄位、建立時間欄位與顯示為日期的公式欄位；固定排班每列各有日期，正好對得上。
固定排班用查找記錄就能無腦跑，但如果你想要系統自動推算「下一位是誰」、遇到請假的人自動往後跳，這就從查詢升級成需要判斷的邏輯，得動用工作流的條件分支與循環節點；再更複雜，就會碰到不寫程式的邊界了。
誠實的邊界：不寫程式能到哪、哪裡仍需開發
不寫程式的自動化有明確的天花板，規劃前先認清楚，才不會把它當萬能而在半路失望。Base 自動化的主場是節點較少（約 2 到 4 步）、不涉及判斷的場景，例如監測記錄新增或變動就自動發通知。
一旦需要條件判斷（if-else）、多分支或循環，就要改用工作流：它是自動化的進階版，畫布式介面、支援邏輯節點，仍然不必寫程式，只是設定較繁；要注意工作流會佔用同一份每月自動化執行次數額度，不是另開一桶配額。再往上，真正複雜的邏輯、或要和外部系統做深度的雙向資料交換，就會碰到工程的門檻：Base 自動化雖有「發送 HTTP 請求」動作可以把資料送出去，但接收與處理的那一端，仍然要有人開發與維運。把這條線兩邊都講清楚，才是負責任的說法。
還有兩項具體限制要放進規劃：一是自動化發送的 Lark 訊息只能發給與多維表格所有者同企業的內部使用者與內部群組，不支援外部使用者或群組；二是月配額，流程一多就要盤點哪些流程值得留。Excel 裡那些手動維護的清單，若打算搬進來當自動化的資料源，搬遷的順序與注意事項可參考從 Excel 到自動化的時間軸。
維運：別讓機器人變成幽靈流程
機器人最尷尬的下場不是壞掉，是沒人記得它還在跑：通知發到已經解散的群組、提醒指向早就離職的人、觸發的欄位改了名字。這種靜默失效比規則壞掉更難察覺，因為收不到通知的人，不知道自己本來該收到。
防治靠三個角色分工，可以是三個人也可以一人兼任，但職責要清楚。盤點者最懂日常流程，負責找出值得自動化的規則；設定者把規則翻成觸發與動作，通常也是有權管理該表的人；維護者負責在流程或人員異動時更新規則。落地的紀律也有三條：把自動化集中在少數幾張表上、別散落各處；每條流程的用途寫在名稱裡（「值班當日通知當班人」而不是「自動化 3」）；每季由維護者用運行日誌掃一輪，把觸發對象、通知對象與現況核對一次，順便看有沒有報錯。
最後一條是通知的禮儀：通知只發給要採取行動的人。把「通知所有人」當安全牌，結果就是群組被機器訊息洗版、大家反而全部靜音，自動化的信任度也一起賠進去。主管的知情需求，用儀表板讓他主動看，而不是每筆變動都推播。
常見問題
以下整理 IT 決策者在評估 Slack bot 與 Lark 不寫程式自動化時，最常提出的幾個問題。
Q1：建 Slack bot 一定要會寫程式嗎？
建 Slack bot 要不要寫程式，取決於走哪一條路。走 Slack API 自建 app 的官方建議路線需要 Slack CLI 與 Bolt 框架、要寫程式並讓 app 持續運行、在 OAuth & Permissions 安裝到工作區取得開頭 xoxb 的 bot token（2026-08-13 官方開發者文件）；若不想寫程式，Slack 內建的 Workflow Builder 可以拼出排程訊息、表單與單步簽核等流程；免費版含功能受限的基礎版，條件分支與外部 connectors 等進階功能才需付費方案（以官方最新公告為準）。
Q2：不寫程式的自動化能做到哪些工作？
不寫程式的自動化涵蓋通知、收集、查詢與單關審批這幾類規則明確的工作。以 Lark Base 自動化為例，全程圖形介面設定觸發條件（新增記錄、修改記錄、到達記錄中的時間、定時等）與執行動作（發訊息、新增／修改／查找記錄等），存檔即生效；需要多分支判斷時改用工作流的邏輯節點，一樣不必寫程式，只是設定較繁。
Q3：Lark Base 自動化有次數或對象的限制嗎？
Lark Base 自動化有兩項限制要先知道。執行次數依方案有月配額，標準版與基礎版各 1,000 次、專業版 5 萬次、旗艦版 50 萬次，按整個企業維度計算、於次月 1 日重新計算；發送的 Lark 訊息只能給與多維表格所有者同企業的內部使用者或群組，不支援外部。方案權益請以官方最新公告為準。
Q4：值班輪替這種要「輪流」的邏輯也能不寫程式嗎？
固定排班的值班輪替可以不寫程式。把日期與值班人填進 Base 排班表，用「到達記錄中的時間時」或定時觸發搭配「查找記錄」找出當班的人再發通知即可。但若要系統自動推算下一位、自動跳過請假者這類動態邏輯，就要動用工作流的條件分支與循環節點；更複雜的規則或要深度串接外部系統，仍需工程開發。
Q5：我們已經在用 Slack，值得為了自動化換平台嗎？
是否換平台不該只看單一功能，要看整體使用場景。Slack 的頻道模式成熟、整合生態豐富，適合工程文化強、已習慣英文工具鏈的團隊；若團隊的自動化多半圍繞表單、資料查詢與審批，又希望不寫程式就把資料庫、通知與簽核串在同一處，Lark 這種把訊息、Base 與審批放進同一產品的做法會省事不少。建議拿團隊實際的兩三個流程各自估一次工，再決定。
想知道團隊有哪些流程可以不寫程式就自動化，找艾瑞特資訊聊聊。身為 Lark 台灣授權代理商，我們可以用你們真實的站會、單據與值班流程，現場示範第一條自動化怎麼設，也把配額與邊界一次講清楚。整體的工具選型思路，可參考 No-Code 平台指南與即時通訊工具對照。