Grok Bot 的 Routine 是指派給單一 Bot 的定期或事件觸發任務，Skill 則是可跨 Bot 重用的操作說明。結論先講：企業要讓 Grok Bot 穩定接手例行工作，關鍵不在提示詞寫得多漂亮，而在四件事：先把任務定義到可驗收、用示範而不是描述來教它、用測試帳號跑過一輪、上線後保留核准點與執行紀錄。本文用三個台灣中小企業常見的場景示範這套流程。
若你還不確定 Grok Bot 是什麼、與 @grok 或 Grok Build 的差異，先閱讀Grok Bot 是什麼？2026 完整解析。
先弄懂三個物件：Bot、Skill、Routine
Grok Bot 的設計以「持久的 Bot 名冊」取代用完即丟的聊天視窗。三個物件的關係如下：
- Bot：一個有名字、有記憶、有自己雲端電腦的工作者。建議依職能命名，例如「營運日報 Bot」「招募助理 Bot」「客服分流 Bot」。
- Skill：一份可重用的操作說明，記錄步驟、決策規則、預期輸出與安全邊界。可在 Settings → Plugins 找到，於對話中用
/呼叫；私有 Skill 需逐一為 Bot 啟用。 - Routine：綁定單一 Bot 的執行排程，可依時間或事件觸發。在 Bot 對話詳情的 Routines 分頁可啟用、暫停、測試、編輯與查看歷史。
實務順序是：先確定要哪個 Bot 負責，再建立或教會它 Skill，最後用 Routine 排程。
場景一：每日營運日報彙整
需求：每天早上 8:30，從蝦皮賣家中心、官網後台與 Google 試算表抓取昨日訂單數、退貨數與客訴數，整理成固定格式的日報，放到指定的共用資料夾，並在群組通知負責人。
為什麼適合當第一個任務：每天固定發生、輸入來源明確、輸出格式固定、出錯只需重跑，沒有對外發送的動作。
核准點：日報產出後由營運主管看過再轉發；Bot 只負責產出與內部通知。
場景二：面試提醒與候選人資料整理
需求：面試前一天 14:00 與當天 09:00，各提醒面試官一次，附上候選人履歷摘要、應徵職缺、面試官名單與會議室資訊；資料來自人資系統與行事曆。
為什麼適合：時間觸發明確，輸出是內部訊息，不涉及對候選人的外部溝通。
核准點：對候選人的任何訊息（改期、確認、結果）不由 Bot 發送，只產生草稿。
場景三：客服信件分流與回覆草稿
需求：每 30 分鐘檢查客服信箱，把來信分成詢價、客訴、一般詢問與待人工判斷四類，依類別套用已核准的回覆模板產生草稿，並更新到客服看板。
為什麼要放最後：涉及客戶資料與對外回覆，應等前兩個場景穩定後再啟用。
核准點：所有回覆由客服人員確認後才送出；Bot 不得執行刪信、封存以外的任何郵件操作。
從定義到上線的四個步驟
以下步驟以場景一為例，其餘場景照同樣流程。
步驟 1：把任務定義到可驗收
官方文件建議在建立 Routine 前先確認六件事。用一張表把它們寫清楚，之後直接貼給 Bot：
| 項目 | 場景一的答案 |
|---|---|
| 負責 Bot | 營運日報 Bot |
| 排程與時區 | 每日 08:30，Asia/Taipei |
| 輸入來源 | 蝦皮賣家中心訂單頁、官網後台報表、指定 Google 試算表 |
| 預期輸出 | 固定欄位的日報（訂單數、退貨數、客訴數、異常備註），存到共用資料夾 |
| 核准邊界 | 只產出與內部通知；不對外發送、不修改來源資料 |
| 來源缺失時的處理 | 任一來源無法讀取，標示「資料不完整」並通知負責人，不補數字 |
「來源缺失時的處理」常被忽略。沒有這條，Bot 可能在平台改版當天產出一份看起來正常但數字是舊的日報。
步驟 2：用示範教會它 Skill
在與該 Bot 的一對一對話中選擇「Teach a task」，說明預期結果，然後親自操作一次完整流程（最長 10 分鐘）。Bot 會產生 Skill 草稿。
草稿通常只有步驟，缺少決策規則。請手動補上：
- 哪些畫面元素代表「昨日」的資料範圍。
- 退貨與客訴的判斷規則，例如客訴只計入標記為「投訴」的工單。
- 什麼情況要停下來，例如登入失敗、頁面找不到報表按鈕、數字為空。
補完後再把 Skill 啟用給這個 Bot。若同一套流程要給多個 Bot 用，Skill 可跨 Bot 共用，但每個 Bot 仍需要對應的連接器或登入。
步驟 3：用測試帳號執行 Test run
在 Routines 分頁建立排程後，先按 Test run，不要直接啟用。
測試執行會做真實工作：它會登入、瀏覽、寫檔案、呼叫已連接的工具。因此：
- 使用專為 Bot 建立的獨立帳號，權限只到「讀取報表」與「寫入指定資料夾」。
- 輸出先指向測試資料夾，確認格式與數字正確後再改成正式路徑。
- 至少跑三次：正常日、一個來源無法讀取的日子、假日沒有訂單的日子。
- 比對 Bot 產出與人工計算的數字，記錄差異與原因。
三次都通過再啟用。若失敗率明顯，回到步驟 2 補規則，而不是在 Routine 描述裡加更多形容詞。
步驟 4：上線、保留核准點與定期檢視
啟用後的第一週，每天由負責人核對日報再轉發。系統保留每個 Routine 最近 20 筆執行紀錄，請在每週例會抽查一次。
官方建議在來源系統改版時暫停 Routine。實務上可以把「平台公告改版」加入負責人的檢查清單；Bot 長期無人關注時也可能被系統自動暫停，需要人工確認才恢復。
進階：讓多個 Bot 在群組裡分工
當單一 Routine 需要多個角色，例如「整理資料」與「起草週報」與「檢查格式」，可以把三個 Bot 拉進同一個群組聊天。群組共享專案脈絡，每個 Bot 保有自己的專業記憶與 Skill。
設計建議：
- 一個 Bot 只負責一種產出，避免一個 Bot 什麼都做導致記憶混雜。
- 在群組中明確指定「誰是最後確認的人」，通常是人，不是 Bot。
- 事件觸發（Slack 訊息、GitHub 通知）要定義窄的比對規則，例如只回應含特定標籤的訊息；寬泛的監聽會製造雜訊，也擴大誤用風險。
上線前檢查清單
- 任務定義表六個項目都已填寫，包含來源缺失時的處理。
- Skill 已補上決策規則與停下來的條件，不只是操作步驟。
- Bot 使用獨立帳號，權限為最小必要。
- Test run 至少三次，涵蓋正常、來源缺失與空資料情境。
- 對外發送、發布、刪除、付款的動作全部保留人工核准。
- 重試設計為可重複執行（idempotent），不會產生重複的檔案或通知。
- 企業版已開啟稽核日誌與 Action Recording；個人方案已安排每週抽查執行紀錄。
- 已指定負責人，並把「來源平台改版即暫停」納入其檢查清單。
結論
Grok Bot 讓「指派工作給 AI」變得像指派給新同事：講清楚任務、示範一次、看它做幾次、再放手。差別在於新同事會問問題，Bot 只在你設定的核准點會停。把核准點與失敗處理設計好，Routine 才會成為穩定的資產，而不是每天要修的新工作。
需要協助設計第一個 Routine 或把既有 SOP 轉成 Skill，可閱讀流程自動化主題指南，或預約諮詢。
資料來源
- xAI Docs, Skills and routines
- xAI Docs, Grok Bot for teams and enterprises
- xAI, Designing Grok Bot（2026-09-03）
相關推薦與延伸閱讀
- 5 個行政自動化場景：會議、郵件、排程與報表驗收：從會議摘要、郵件草稿、社群排程到費用及定期報表，整理行政自動化的輸入、人工覆核與驗收方式，不把工具設定完成當成效益保證。
- ego-lite 瀏覽器教學：為 AI Agent 與人類協同打造的無干擾自動化神器：深入解析 ego-lite（ego-browser）如何透過獨立 Task Space、登入狀態（Session）無縫繼承、雙向 Control Handoff
- 企業 AI Agent 上線前，FDE 必須先設計執行合約：企業 AI Agent 正走向多供應商、多工具協作。本文整理 FDE 如何用執行軌跡、權限邊界與政策治理，把 Agent 推進到可驗收的工作流。