Grok Bot 是 xAI 的常駐 AI 隊友，你把一份工作交給一個具名 Bot，它在自己的雲端電腦上登入你的工具、把事情做完，只在需要你核可時回來找你。 官方文件把最關鍵的一句話寫得很清楚：這台電腦綁的是你的帳號，不是個別 Bot。所有 Bot 共用同一組瀏覽器 cookie、登入工作階段、檔案與命令列憑證。所以你怎麼分配工作，就等於在分配權限。
這一篇不談它有多聰明。談的是把一份重複工作交出去之前，你要先把哪些東西定義清楚。
先承認真正的瓶頸在哪
一人公司的日常是一個人做十二份工作。做產品、找客戶、寫內容、回客服、追款項、看數字，然後晚上十一點想起來今天又沒做行銷。
AI 幫得上每一份工作，但過去的用法是：你打開一個對話、解釋一次要幹嘛、給回饋、把答案貼到另一個應用程式，然後全部再來一次。瓶頸從來就在你身上，不在模型。
Grok Bot 想解決的就是這一段。你保留決策，Bot 承接可重複的流程。每個 Bot 有名字、有一份工作、能存取共用的雲端電腦，可以使用真實網站、把工作交給彼此、在你闔上筆電之後繼續跑，並在需要核可時停下來。
最後那一句才是重點。目標從來不在把你從公司裡拿掉，你的判斷、關係和決定本來就是這家公司。目標是讓你不再當那個每次都要親手點幾下的人。
一個 Bot 一份工作
多數人會建一個萬用 Bot，問它各種問題，然後覺得這不就是另一個聊天機器人。
有用的 Bot 只做一件你能講清楚的工作。官方產品頁把這件事直接做成介面：Sales Outbound、Talent Scout、Paid Media、Expense Manager、Product Performance、Bug Reproduction、Account Health、Chief of Staff，一個職務一張卡。
當幾份工作需要協作，就把這些 Bot 放進同一個頻道，給整組一個結果。它們之間可以直接交接，不用你在對話之間複製貼上。
真正要記住的限制在這裡：所有 Bot 共用同一台雲端電腦，也就共用瀏覽器工作階段與登入。官方文件的說法是，這些畫面是分開的工作介面，不是分開的安全邊界，並且明講不該讓其他 Bot 用到的憑證或檔案就不要放上去。
所以發布、寄送訊息、花錢、刪檔案、改動線上系統這幾件事，一律留在核可之後。
第一份工作怎麼挑
不要今天就把整張組織圖建出來。挑一件你每週固定花 30 分鐘以上的事，從那裡開始。
你可以建 50 個 Bot，然後感覺自己很有生產力，維持二十分鐘。不要這樣做。從最小的有用團隊開始，就一個 Bot，給它一個端到端的結果，真的需要了才加下一個。
第一個 Bot 不該是頭銜最酷的那個。挑一件你能驗收的小工作，它要同時滿足五個條件：
- 重複發生：你本來每週就在做。
- 步驟穩定：基本流程大致不變。
- 多個步驟：中間有夠多小任務，交出去才真的省時間。
- 可回復：做錯了你能修，不會傷到客戶或損失金錢。
- 可衡量：你講得出「做得好」和「做完了」長什麼樣。
舉例來說，「每週內容簡報」就是不錯的第一份工作：
內容簡報 Bot 檢查來源、蒐集題目、排出優先順序、補做研究，然後把簡報交給寫作 Bot。
我打開簡報，五分鐘內就知道它做得好不好。
另一個例子是監看競爭對手的定價頁：
每天早上檢查這個頁面。記錄變動的部分。用舊價格、新價格、來源連結和截圖通知我。
不要聯絡任何人，也不要修改任何東西。
輸入清楚、護欄明確，出錯的代價就有限。動手之前先問自己一個問題：
如果它今晚跑壞了，我明天早上會知道發生什麼事嗎？我有辦法復原嗎？
答案是否定的，就把工作範圍再縮小。這比第一天就建一支三十個 Bot 的部隊無聊得多，但這是你最後會信任的那種 AI 團隊。
開始之前要備齊的五件事
- Grok Bot：使用合格的 SuperGrok 或 Cursor 方案，再從
x.ai/bot下載桌面應用程式。 - 一段真實的重複工作：每週 30 分鐘以上、步驟明確，比較容易自動化。
- Skill 檔案：用 Markdown 寫的指示，教 Bot 怎麼執行一份工作、怎麼驗收結果。
- 公司實際在用的工具：有 plugin 就接 plugin；沒有的話，Grok Bot 可以直接用它的瀏覽器。
- 一條核可界線：先決定哪些事一定要你看過才算數。
官方 Pricing 頁列出三張方案卡：Cursor $20/月、Grok $30/月、Cursor Teams $40/席/月，頁面下方註明已經在合格的 Cursor、SuperGrok 或 Teams 方案上就已內含。官方文件的 FAQ 則把合格方案列得更完整：SuperGrok Plus、SuperGrok Heavy、Cursor Pro+、Cursor Ultra，以及 Cursor Teams 的 Standard 與 Premium。
平台方面，官方支援 macOS、Windows、Linux 與 iOS 18 以上；Android 與 iPad 在推出時尚未支援。
步驟一：先把工作和界線寫進 Bot 描述
隨手下的 prompt 不會長出可靠的隊友。你得告訴每個 Bot 它在做哪一份工作，以及哪裡需要你介入。
給它四件事：一份工作、一個「做得好」的定義、它能用的工具與應用程式、以及護欄。
「幫我處理行銷」太模糊。下面這種寫法才可用：
用我們的品牌簡報和成效數據規劃下週內容。把每則貼文的題目、開場鉤子、來源連結和重點交給寫作 Bot。
不要發布任何東西，也不要編造成效數字。
每次都要遵守的規則放進 Bot 的描述，今天的任務放在對話裡。不要把整間公司塞進一份巨大的描述；工作聚焦的 Bot 累積出來的脈絡比較好用，因為每一次修正都落在同一類工作上。
步驟二：接工具，但不要把全部鑰匙交出去
有 plugin 就從 Plugins 接上，Bot 會拿到那項服務的結構化工具。官方文件建議有 connector 就優先用 connector，通常比在網站上一路點下去可靠。
沒有 plugin 的服務，就讓 Bot 在它的雲端瀏覽器裡打開網站。走到登入畫面時你接手，自己輸入密碼或兩步驗證，再把控制權交還。
絕對不要把密碼或一次性驗證碼貼進對話。
再提醒一次共用的問題：發布用的 Bot 登入了某個社群工具之後，你帳號下的其他 Bot 可能沿用同一個瀏覽器工作階段。所以範圍要開得窄。以一個內容團隊為例，內容主管需要品牌與產品脈絡，寫作 Bot 需要核可過的簡報，審查 Bot 需要草稿和評分規則，只有發布 Bot 需要碰發布帳號。
真實的團隊本來就該這樣分。
步驟三：用四個 Bot 承接七個 skill
一份現成的內容工作流大概會拆成七個 skill：brand-brief、content-coach、post-writer、post-grader、post-scheduler、viral-hooks、repurpose。這組 skill 是公開的，放在 https://github.com/Blotato-Inc/blotato-skills，原本是為 Claude 寫的。
為什麼是四個 Bot 而不是七個？因為一個 Bot 一份工作，而 skill 只是教 Bot 怎麼做一份工作的其中一段。就像現實裡的職務會用到多種技能。
| Bot | 承接的 skill | 為什麼放在一起 |
|---|---|---|
| 內容主管 | brand-brief、content-coach | 定義品牌脈絡與本週題目，產出簡報 |
| 寫作 | post-writer、viral-hooks、repurpose | 三者都服務同一個職責：依公司資訊生出高表現內容 |
| 審查 | post-grader | 必須獨立；寫的人審自己的稿一向不準 |
| 發布 | post-scheduler | 對外動作，收到核可過的內容才排程 |
匯入時只需要一個相容性調整：拿掉 Claude 專屬的 allowed-tools 欄位，其餘不摘要、不改寫。可以直接用這段 prompt：
從 https://github.com/Blotato-Inc/blotato-skills 匯入全部 7 個 skill。
保留原本的指示、決策規則、輸出格式、驗證步驟與核可界線。
只移除 Grok Bot 裡不存在的工具名稱。把你做的每一項更動都告訴我。先不要執行 skill。
所有 Bot 都看得到這些 skill，但每個 Bot 只需要跟它的工作有關的那幾個。別給發布 Bot 一份爆紅鉤子清單，它用不到；也別給寫作 Bot 發布權限。這就是分開的意義。
順帶一提，那個 repo 現在列出的是八個 skill，多一個負責影片生成的 generate。上面這組七個是內容工作流實際用到的子集。
步驟四：把團隊放進同一個頻道
建一個頻道，把四個 Bot 都加進去，然後給整組一個結果，而不是給每個人一道指令。交接會變成這樣：內容主管定角度，寫作 Bot 產出文案，審查 Bot 獨立檢查主張、語氣、結構與行動呼籲並評分，不過就退回去修，你在最後核可。
Bot 負責協調，你負責會花錢或碰到客戶的決定。
這套做法會卡在哪
實測下來會順的部分：七個 Claude skill 可以完整轉移；職責聚焦讓權責清楚；審查 Bot 真的會退件，而不是禮貌地全部放行；群組頻道保住了交接與護欄；共用的瀏覽器工作階段讓發布 Bot 能操作真實工具；核可閘門會在 alt text 和時區這種決定之前停下來。
還是卡卡的部分：skill 同時也是 plugin，這件事容易搞混；AI 影像與影片生成要時間，Bot 得反覆確認狀態；產品仍在 beta，一定要從可回復、低風險的工作開始。
步驟五：確定可靠了才變成排程
高階流程其實只有四句話：挑一件你每週已經花 30 分鐘以上、步驟清楚、完成定義清楚的工作；為它建一個 Bot；把你的流程寫成 skill；等到整件事穩定重複之後，才變成 routine。
官方文件對 routine 的定義是把一個工作流指派給一個 Bot，並告訴它什麼時候跑，可以照排程也可以在支援的情況下由事件觸發，而且明確建議先在一次性的真實任務上測過 skill 再排程。它可以在你闔上筆電之後繼續跑；同一個 Bot 一次只能在它的畫面上執行一項電腦操作任務，但多個 Bot 可以同時工作。
幾個排得出來的例子：每天早上，研究 Bot 找出相關的產品發表與受眾提問；每週一，內容主管把題目、鉤子與來源連結交給寫作 Bot；每週五，審查 Bot 稽核下週已排程的內容；每次業務通話之前，業務 Bot 準備客戶研究；月底，財務 Bot 整理收據並標出缺漏。
直接照抄的建置清單
1. 挑一件很吃時間的事。
2. 建一個 Bot，給它一份清楚的工作。
3. 給它事實來源、「做得好」的定義、交接對象與核可界線。
4. 接上這份工作需要的工具。
5. 跑一次有明確完成線的真實任務。
6. 反覆修正，直到它能穩定重複。
7. 把驗證過的流程存成 skill。
8. 有另一件夠大的工作時，才加第二個 Bot。
9. 把多個 Bot 放進同一個群組，讓它們協作。
10. 等到你信任產出，才把整套變成重複執行的 routine。
11. 發布、寄送、花錢、刪除與正式環境的變更，永遠留在核可之後。
你不需要為組織圖上的每一個格子配一個 AI 員工。先挑一件你一直在逃避的工作，給它一個負責人，讓它真的能跑，然後再「聘」下一個 Bot。
常見問題
Grok Bot 和一般的 AI 聊天有什麼不同？
一般聊天每次都要你重新說明背景。Grok Bot 是具名且常駐的隊友，會保留記憶、檔案、瀏覽器工作階段與偏好，在自己的雲端電腦上登入你的工具把工作做完，只在需要核可時回來。
所有 Bot 真的共用同一台電腦嗎？
是。官方文件寫明這台電腦綁定你的帳號而非個別 Bot，瀏覽器 cookie、登入工作階段、檔案與命令列憑證都是共用的，並形容這些畫面是分開的工作介面而不是分開的安全邊界。不該被其他 Bot 使用的憑證或檔案就不要放上去。
需要哪一種方案？
官方文件 FAQ 列出的合格方案是 SuperGrok Plus、SuperGrok Heavy、Cursor Pro+、Cursor Ultra，以及 Cursor Teams 的 Standard 與 Premium。官方 Pricing 頁顯示的價格是 Cursor $20/月、Grok $30/月、Cursor Teams $40/席/月。
遇到登入或兩步驗證怎麼辦？
由你自己完成。官方做法是打開那台電腦、接手控制、只完成被擋住的那一步，然後告訴 Bot 繼續。不要把密碼或一次性驗證碼貼進對話。
應該先建幾個 Bot？
一個。挑一件你每週花 30 分鐘以上、可回復、可驗收的工作，讓一個 Bot 端到端做完，真的需要再加第二個。等到它能穩定重複，才把它變成排程 routine。
權威引用
- SpaceXAI Docs — Grok Bot Overview
- SpaceXAI Docs — Use the computer and apps
- SpaceXAI Docs — Grok Bot FAQ
- xAI — Grok Bot 官方產品頁
- GitHub — Blotato-Inc/blotato-skills
Author Insight
我幫團隊接 AI 工作流時，最常看到的失敗不是模型不夠強，是工作沒被定義成可以交出去的形狀。「幫我做行銷」交給誰都會失敗，交給人也一樣。
Grok Bot 這套設計裡我最在意的是共用電腦。它讓交接變簡單，同時把權限邊界從技術層推回到管理層——你能不能控制風險，取決於你有沒有想清楚哪個 Bot 該碰哪個帳號。這與其說是 AI 問題，比較像分工問題，而分工是你的工作。
我自己會採用的順序，是先寫核可界線，再寫 skill，最後才建 Bot。多數人反過來做，先建了一排 Bot，才發現不知道哪一步該停下來等人。
術語表
- Bot：具名、常駐的 AI 隊友，擁有一份工作、記憶、檔案與瀏覽器工作階段。
- 雲端電腦（cloud computer）：綁定帳號的持續執行環境，含瀏覽器、檔案系統與終端機；同一帳號下所有 Bot 共用。
- Skill：用 Markdown 寫的可重複使用指示，教 Bot 怎麼執行一份工作並驗收結果。
- Plugin / Connector：對特定服務的結構化工具接口，官方建議有 connector 時優先於瀏覽器操作。
- Channel（頻道）：多個 Bot 共同作業的空間，讓它們彼此交接而不需要你轉手。
- Routine（例行任務）：把一個工作流指派給一個 Bot 並設定執行時機，可照排程或由事件觸發。
- 核可界線（approval boundary）：發布、寄送、花錢、刪除與正式環境變更等動作必須先經過人工同意的規則。
