用 OpenClaw 建置 Slack 每日摘要機器人
手把手教你用 OpenClaw 建置 Slack 每日摘要工作流：自動收集頻道訊息、AI 智慧總結、定時推送，讓團隊不再錯過重要資訊。
最後更新: 2026-03-31
所需 Skills
你將建置什麼
一套自動化的每日摘要系統：
- 收集訊息 — 全天自動採集 Slack 頻道中的對話
- AI 智慧總結 — 擷取關鍵要點、決策和待辦事項
- 定時推送摘要 — 在你設定的時間準時送達
- 全自動運作 — 透過 Cron 排程，設好就不用管了
適合團隊負責人、遠端工作者，或者任何需要掌握全局又不想逐條刷訊息的人。
為什麼需要每日摘要
Slack 的即時通知是一把雙面刃。每一條訊息推送都會打斷你的專注狀態，研究顯示被打斷後平均需要 23 分鐘才能完全恢復專注力。算下來，一天的碎片化時間損失相當驚人。
每日摘要的本質是批次處理溝通資訊。不是每條訊息到了就反應，而是在你選擇的時間，一次性收到結構化的總結。這消除了「訊息焦慮」——那種看到側邊欄一堆未讀頻道時的壓迫感——取而代之的是平靜、可預期的資訊流。
掃 10 個頻道的 150 條獨立訊息，需要持續的腦力投入：過濾雜訊、追蹤討論、記住上下文。而一份結構良好的摘要把這些壓縮成 2 分鐘的閱讀量，按重要性排序。你能完全掌握決策、阻塞點和待辦事項，卻不會被塞滿的側邊欄所焦慮。
這種方式特別適合管理者、高階主管和跨職能協作者——需要對多個頻道保持感知，但不需要即時參與每一場對話。
前置條件
- OpenClaw 已安裝並設定好
- Slack 工作區，有管理員或應用程式安裝權限
- Slack Bot Token，需包含
channels:history、channels:read和chat:write權限 - Node.js 18+
第 1 步：安裝所需 Skills
# 1. Slack 整合 npx clawhub@latest install slack # 2. AI 摘要產生 npx clawhub@latest install summarize # 3. 定時排程 npx clawhub@latest install cron
第 2 步：設定 Slack 整合
建立 Slack 應用程式
- 前往 api.slack.com/apps，建立新應用程式
- 在 OAuth & Permissions 中新增以下 Bot Token Scopes：
channels:history— 讀取頻道訊息channels:read— 列出頻道chat:write— 傳送摘要訊息
- 將應用程式安裝到你的工作區
- 複製 Bot User OAuth Token（以
xoxb-開頭）
設定 Skill
在 OpenClaw 中設定 Slack Token：
# Skill 首次使用時會提示輸入設定 clawhub inspect slack
第 3 步：設定摘要產生器
Summarize Skill 可以處理任何文字輸入。對於每日摘要情境，建議設定：
- 輸出格式：帶分節的結構化要點
- 關注領域：決策、待辦事項、公告、問題
- 篇幅：精煉（每個頻道 200-400 字）
第 4 步：設定 Cron 定時任務
建立每日 Cron 任務執行摘要工作流：
# 每個工作日下午 6 點推送 # Cron Creator 支援自然語言輸入
Cron 任務會依序：
- 從設定的頻道取得訊息（過去 24 小時）
- 交給 Summarize Skill 處理
- 格式化為結構化摘要
- 推送到指定的摘要頻道
第 5 步：測試摘要
在依賴 Cron 排程之前，先手動執行一次驗證：
- 檢查 Slack 連線是否正常
- 確認訊息擷取回傳了預期內容
- 檢驗摘要產生的品質
- 驗證摘要傳送到了正確的頻道
自訂選項
多頻道摘要
監控多個頻道並按頻道分組彙總：
#engineering— 技術討論和決策#product— 功能需求和路線圖更新#incidents— 線上問題和解決方案#general— 全公司公告
優先順序篩選
讓摘要器重點標注：
- 帶表情回覆的訊息（👀、✅、🚨）
- 提到特定關鍵字的訊息
- 回覆數較多的討論串
- 特定人員的訊息（主管層、值班人員）
多時段摘要
針對不同需求設定不同推送時間：
- 晨報（上午 8:00）— 隔夜活動摘要
- 日終總結（下午 6:00）— 全天摘要
- 週報（週五下午 4:00）— 一週回顧
進階：條件觸發摘要
不是每天都需要摘要。你可以設定智慧觸發條件，只在有意義的時候傳送。
跳過週末和假日
將 Cron 設為僅工作日執行，並維護一份假日清單。Cron Skill 支援類似 0 18 * * 1-5 的表達式，只在工作日執行。對於假日，在工作流開頭加一個日期檢查，符合假日就提前結束。
緊急偵測
設定關鍵字告警，繞過每日排程直接推送。如果訊息中包含「故障」、「P0」、「安全事件」、「回滾」等關鍵字，系統會立即傳送一條精簡摘要，不用等到定時時間。這樣兩全其美：常規更新批次處理，關鍵事件即時告警。
活躍度門檻
設定最低訊息數門檻。如果某個頻道在 24 小時內訊息不到 3 條，摘要價值不大。工作流可以先檢查訊息量，在活躍度低於門檻時跳過該頻道甚至整份摘要。
關鍵字分類
定義關鍵字群組來分類呈現特定主題。例如把提到「部署」、「發布」、「上線」的訊息歸入「發布」板塊，把提到「bug」、「當機」、「報錯」的訊息歸入「問題」板塊。在 AI 摘要基礎上增加了一層智慧分類。
不同角色的摘要範本
不同角色需要從相同頻道取得不同資訊。你可以建立多套摘要設定，分別面向不同受眾。
技術負責人
🔧 技術摘要 — 2026年3月31日 阻塞問題 (2) • 認證服務在 staging 環境觸發限流 — @chen 排查中，需要 DevOps 支援 • CI 流水線整合測試失敗 — 支付模組的不穩定測試 Pull Request (5 已合併, 3 待審) • 已合併：行動端 API 的 GraphQL 遷移 (#1842)、快取失效修復 (#1839) • 待審查：資料庫索引最佳化 (#1845) — 已開放 2 天 部署 • 正式環境部署 v2.3.12 於下午 2:30 — 成功，無回滾 • Staging 部署 v2.4.0-beta.3 於下午 4:00 — 2 個冒煙測試失敗 技術決策 • 已核准：PostgreSQL 切換到連線池方案 (RFC-0047) • 討論中：採用 OpenTelemetry 做分散式鏈路追蹤
產品經理
📦 產品摘要 — 2026年3月31日 功能討論 • 行動端引導流程重新設計 — 3 個方案已分享，團隊傾向方案 B • 企業級 SSO — Acme 客戶意見回饋已整合到需求文件 • API 限流 — 開發者社群要求提高免費版額度 使用者回饋 (來自 #support 和 #feedback) • 4 條請求：報表儀表板增加 CSV 匯出功能 • 2 個企業客戶對新搜尋篩選器給予好評 • Bug 回報：日期選擇器在 Safari 上無法運作（工單已建立） 已做決策 • v2.4 功能凍結確認為 4 月 3 日 • Q2 OKR 草稿截止 4 月 7 日 — 各 PM 請提交 近期安排 • 設計審查定在 4 月 2 日上午 10:00
高階主管
📊 高階簡報 — 2026年3月31日 關鍵指標 • 活躍使用者：12,847（週環比成長 3.2%） • API 可用性：99.97%（SLA 目標：99.9%） • 待處理工單：23（較昨日 31 個減少） 事故 • 一起已解決事故：資料庫連線池耗盡（停機 45 分鐘） • 根因已定位，修復已部署 — 未影響客戶資料 策略決策 • 工程團隊核准 PostgreSQL 連線池遷移 • v2.4 功能凍結定在 4 月 3 日 — 按計畫 4 月 15 日發布 需要關注 • 企業定價方案需要財務部意見 — 阻塞 2 個業務對話 • Q2 招募計畫：3 個工程職位已獲批，職位描述待撰寫
摘要輸出範例
一份典型的每日摘要長這樣：
📋 每日摘要 — 2026年3月31日 🔧 #engineering (12 則訊息) • 決策：行動端 API 從 REST 遷移到 GraphQL（@sarah 已核准） • 待辦：@mike 在週四前更新 API 文件 • 討論：新快取層的效能基準測試 — 結果待出 📦 #product (8 則訊息) • 公告：v2.4 功能凍結從 4 月 3 日開始 • 需求：3 個新功能需求已標記進 Q2 規劃 • 問題：企業版定價方案 — 需要 @finance 給意見 🚨 #incidents (2 則訊息) • 已解決：資料庫連線池耗盡（10:30 - 11:15） • 目前無活躍事故
週報格式
適合週末回顧的宏觀視角：
📋 週報 — 2026年3月25日-31日 本週亮點 • GraphQL 遷移獲批並啟動實作 • v2.3.12 發布，快取層改善帶來 40% API 回應提速 • 2 個新企業客戶完成上線 數據概覽 • 4 個頻道共 87 則訊息 • 6 項決策已做出，12 項待辦已建立 • 3 起事故（全部解決，平均處理時間 38 分鐘） 下週待追蹤 • 企業定價方案 — 等待財務部審核 • OpenTelemetry RFC — 還需 2 人核准 • 行動端引導流程重設計 — 週二最終設計審查
專案維度摘要
當你需要圍繞某個具體專案看進展：
📋 專案摘要：行動應用 v3.0 — 2026年3月31日 進展 • 認證流程開發完成（PR #1842 已合併） • 推播通知服務 — 完成 80%，整合測試通過 • 離線模式 — 設計方案已核准，4 月 2 日開始開發 阻塞 • 第三方 SDK 與 iOS 18 相容性問題 — 已聯繫供應商 • 引導頁設計素材延遲到 4 月 3 日 團隊動態 • @alex 4 月 1-3 日休假 — @jordan 接手推播通知 • Sprint 審查移至 4 月 4 日下午 2:00
事故專項摘要
面向值班團隊和關注穩定性的相關方：
🚨 事故摘要 — 2026年3月31日 活躍事故：0 今日已解決：1 • INC-2847：資料庫連線池耗盡 - 持續時間：10:30 – 11:15（45 分鐘） - 影響：12% 的 API 請求回傳 503 錯誤 - 根因：新批次處理任務中的連線洩漏 - 修復：連線池上限已調整，洩漏已在 PR #1840 中修復 - 後續：新增連線池監控告警（截止 4 月 2 日） 7 日趨勢 • 事故總數：3（較上週 5 起減少） • 平均解決時間：38 分鐘 • SLA 達標率：99.97%
常見問題排查
訊息擷取失敗
- 確認 Bot Token 包含
channels:history權限 - 確保 Bot 已加入你要監控的頻道
- 檢查頻道 ID 是否正確（可用
channels:read列出）
摘要品質不理想
- 增加訊息取得的上下文視窗
- 在摘要器設定中新增關注指令
- 在摘要前過濾掉 Bot 訊息和自動化通知
Cron 任務未觸發
- 確認 OpenClaw 實例正在執行
- 檢查 Cron 任務狀態：
clawhub list - 確認系統時區與你預期的一致
常見問題
可以。工作流的核心邏輯與平台無關。把 Slack Skill 替換為 Discord Skill（執行 `clawhub install discord`），Summarize 和 Cron Creator Skill 的使用方式完全不變。你只需提供 Discord Bot Token（需要 `Read Message History`、`Send Messages` 權限），並設定 Discord 伺服器的頻道 ID。
免費版 Slack 限制訊息歷史為 90 天，付費版無限制。每日摘要只回看 24 小時的訊息，所以免費版完全夠用。如果你要做週報或月度彙總，需要注意 90 天的限制。免費版團隊如果需要更長期的總結，可以將摘要單獨存檔作為替代方案。
Cron 任務在 OpenClaw 所在機器上本機執行。如果那台機器在預定時間關機或休眠，任務不會執行，也沒有內建的重試機制。要實現可靠的 7×24 運作，建議把 OpenClaw 部署在伺服器、VPS 或雲端實例上。一台每月幾美元的 VPS 或者一個閒置的 Raspberry Pi 就能勝任。
預設情況下摘要傳送到 Slack 頻道，但你有多個選擇。可以利用 Slack 自帶的 Email 通知功能把摘要頻道的訊息轉寄到信箱。或者在工作流中加入 Email Skill（`clawhub install email`），透過 SMTP 直接寄送。後者還能把摘要寄給不在 Slack 工作區的人，比如外部合作方或偏好 Email 的高階主管。
在摘要器中設定正規表達式，自動脫敏 API 金鑰、密碼、Token 和個人身分資訊。除了脫敏，還要控制哪些頻道被納入摘要——完全排除 `#hr-confidential` 或 `#legal` 等頻道。為了增強安全性，把摘要傳送到權限受控的私人頻道，而不是公開頻道。
為不同時區設定多個 Cron 排程，讓各地區在方便的當地時間收到摘要。例如一個在東八區下午 6 點，一個在 CET 下午 6 點。每個排程可以涵蓋相同的頻道，但推送到各自地區的摘要頻道。或者選一個所有人工作時間都有交集的統一時間（例如 UTC 上午 10 點），讓團隊成員上班後自行查看。
當然可以。最簡單的方式是用工作日專用的 Cron 表達式，如 `0 18 * * 1-5`，只在週一到週五執行。對於公司假日，在工作流設定中維護一份日期清單，工作流執行前先檢查目前日期，命中就提前結束。如果團隊分布在多個國家，還可以接入公共假日 API。
可以。摘要傳送到 Slack 頻道後，自動可以透過 Slack 搜尋找到。如果需要更結構化的存檔，可以在工作流中加一步，將每份摘要儲存為 Markdown 或 JSON 檔案，存到指定目錄或雲端儲存。隨著時間累積，這就形成了一個可搜尋的團隊活動檔案庫。有些團隊會把摘要同步到 Notion、Confluence 或 Google Drive 作為長期參考。
可以。在工作流中接入行事曆 API（Google Calendar、Outlook），執行前檢查特定行程。例如全員大會那天跳過摘要（反正大家都同步了），或者團隊外出日跳過。在工作流開頭加一個行事曆檢查步驟，尋找標記了特定關鍵字（如「no-digest」）的行程。這樣你可以靈活控制哪些日子不發摘要，而不用改 Cron 表達式。
摘要傳送到 Slack 頻道，所以頻道成員就是受眾。建立一個專門的頻道如 `#daily-digest`，只邀請需要收到的人。要更精細的控制，可以設定多個摘要頻道——一個給技術負責人、一個給產品經理、一個給高階主管——每個頻道有自己的範本和資料來源。成員還可以利用 Slack 的頻道通知偏好，在不需要的日子靜音摘要頻道，而不用退出。