Grok Bot 把產品工作拆給一群具名 Bot：研究員整理市場與使用者訊號、PM 寫 PRD、設計師補上 Figma mockup、工程經理再把工作交給 Cloud Agents。 單一 agent 不再包辦全場；角色、記憶、工具和交接對象都有明確分工。
速度只是表面變化。當 Bot 能一路跑到可交付成果，PM 的工作會往上移：決定目標、配置存取權、檢查引用、縮小 V1 範圍，並在登入、對外動作和程式碼合併前接手。
先看結論：這套流程實際做了什麼
Cursor 官方頻道在 2026 年 9 月 3 日上架一場 53 分 56 秒的工作坊。兩位講者自我介紹為 SpaceXAI 產品團隊的 Kevin Niparko 與 Roshan，現場示範一支 Grok Bot 團隊如何處理四段工作：注意力清單、定時 routine、研究到 PRD 與設計，以及 PRD 到 Cloud Agents 的交付。
這場示範最有用的地方，在於它把多 agent 協作裡最容易含糊的三件事攤開來：
- 誰負責什麼：一個 Bot 有一份主要職責，不靠萬用助理記住所有事情。
- 交接物是什麼：研究、引用、PRD、mockup、ticket 和測試結果都要成為可檢查的產物。
- 人在哪裡接手：登入、權限核可、策略修訂、code review 與正式環境變更仍由人負責。
這套系統不等於多開幾個聊天視窗
工作坊先解釋了為什麼要做 Grok Bot。聊天介面適合問答，卻不適合需要跨 Slack、Gmail、Notion、資料倉儲、Figma 與程式碼環境的結果型工作。agent 還需要自己的執行環境來驗證產出；當工程師一天同時盯著數十條甚至更多 agent thread，人也很快成為協調瓶頸。
因此，Grok Bot 把基本單位從一次對話改成有名字、職責、記憶、工具和持續狀態的隊友。官方文件列出四個多 Bot 的理由：專業分工、清楚的責任歸屬、平行執行，以及各自聚焦的記憶。
這支示範團隊一共包含 11 個 Bot：
| Bot | 主要責任 | 不該做的事 |
|---|---|---|
| Kora（Chief of Staff） | 讀取行事曆、Slack、收件匣，維護注意力清單 | 沒有變動時不要製造通知 |
| Emily（Engineering Manager） | 拆工作、派給工程 Bot、對照目標檢查產出 | 工作坊刻意教她不要自己寫程式碼 |
| 五個工程 Bot | 呼叫 Cloud Agents、測試與協調實作 | 不自行決定產品方向 |
| Ashley（Data Analyst） | 查詢資料、做圖表、回答產品數據問題 | 不把沒有來源的推測寫成結論 |
| PM Pete | 做研究、整理回饋、寫 RFC 與 PRD | 不越過 PM 的策略修訂 |
| Pixel（Designer） | 使用設計系統與 Figma 補上 mockup | 不自行改變需求範圍 |
| Rey（Recruiter） | 找人才、協助招募流程 | 不替人做最終錄用決定 |
工作流一：注意力清單不同於待辦清單
Kora 的第一個任務，是每小時讀取 Gmail、Slack、行事曆、Notion 與會議紀錄，整理 Kevin 當下實際把時間花在哪裡。它不複製週初訂好的優先清單；回信、參與的 thread、會議和文件異動，才是推回目前注意力的線索。
這份清單有兩種用途。一是過濾噪音，只把與當前工作相關的訊息送到人面前；二是把「我說重要的事」和「我真的花時間的事」放在一起比較。
但這裡也有明顯風險。能推測注意力的 Bot，必須讀到非常廣的工作足跡。導入時至少要先回答三個問題：哪些信箱與頻道能讀、保留多久、清單能不能觸發封存或回覆等動作。觀察和執行最好分兩階段開放。
工作流二：先把一次任務跑順，再排成 routine
工作坊把已經重複執行的工作變成 routine，例如每小時整理收件匣、追蹤新功能發布後的安裝量。官方文件也支援從示範學習：你做一次跨應用程式流程，Bot 將路徑保存下來，之後可按需或定時重跑。
順序很重要。第一次就排程，只會把模糊需求放大。比較穩的做法是：先跑一次真實任務，檢查輸入、產物和停止條件；第二次確認修正能保留；第三次才開排程。每次執行都要留下來源、變更紀錄與需要人處理的例外。
工作流三：研究、PRD 與設計在同一條證據鏈上
示範選了一個雙向語音功能。PM Pete 先從 Reddit、X、內部 Slack、使用者訪談資料庫與產品回饋找需求，再請 Ashley 查語音模型 benchmark、競爭產品與市場規模。研究不能只交一段摘要；講者要求保留引用，讓 PM 能回頭檢查。
接著，Pete 按團隊既有的 Notion 模板寫 PRD，納入使用者洞察、產業背景、V1、MVP 與明確不做的範圍。Pete 再直接叫 Pixel 進場，Pixel 根據設計系統在 Figma 製作 mockup，最後把設計交回 Pete，放進同一份 RFC。
這段流程的關鍵，在於交接時能不能保留一條可追查的證據鏈：
原始訊號 → 有引用的研究摘要 → PRD 主張 → V1 範圍 → 設計 mockup → 驗收條件
任何一段如果找不到上一段的依據，就不該繼續往下跑。
工作流四：工程經理 Bot 管 Cloud Agents，但不替人合併
有了 PRD 和 mockup，PM Pete 把 Emily 拉進群組。Emily 先切出 V1 與 ticket，再交給五個工程 Bot；工程 Bot 底下又能啟動 Cloud Agents，在有 codebase、依賴套件、測試環境與必要 secrets 的環境裡實作和驗證。
示範期間，有 agent 遇到登入或權限問題就停下來要求人接手。講者也反覆把人的角色放在最後一哩：修訂研究、校正產品策略、做 code review，確認成果能不能進正式環境。
Kevin 在官方 PM 指南寫得更直接：Grok Bot 發起的工作，已占內部合併 PR 的兩位數百分比。這是團隊自述的內部採用數據，未經獨立 benchmark 驗證。它能證明這套流程已進入真實開發工作，不能直接推導出每家公司都會得到相同產能。
真正的瓶頸：所有 Bot 共用同一台電腦
Grok Bot 官方文件明確說明，同一帳號下的 Bot 共用一台持續存在的雲端電腦，也共用檔案、瀏覽器工作階段與應用程式登入。每個 Bot 都有自己的畫面，但沒有各自獨立的安全邊界。
這使交接很順，也把風險集中在帳號層。某個 Bot 登入 Figma、Notion 或內部工具後，其他 Bot 可能沿用同一工作階段。團隊不能只靠「你是設計師」「你是研究員」這種角色提示來限制存取。
至少要把這五類動作留在人類核可之後：
- 對外寄信、發文或送出表單。
- 採購、訂閱、退款或任何會花錢的操作。
- 刪除、覆寫或大量移動資料。
- 修改正式環境、部署或合併程式碼。
- 輸入密碼、一次性驗證碼或提高權限。
可以照著做的七步導入法
不要先複製 Kevin 的整張 Bot 組織圖。先挑一條你已經做得懂、可以復原、也容易驗收的流程。
- 定義一個結果：例如把一組有來源的使用者訊號整理成 RFC 草稿，避免使用「幫我做產品」這類模糊任務。
- 建立一個負責人：先讓 PM Bot 端到端負責，確定真的需要資料或設計專才後再加 Bot。
- 寫交接契約：輸入從哪裡來、輸出放哪裡、一定要附哪些引用、誰能退件。
- 分開讀取與寫入權限：研究 Bot 可以讀回饋，不代表它可以回覆客戶或改文件。
- 放入人類閘門：登入、對外動作、付費、刪除、部署和合併都要停下來。
- 跑一次真實工作：用真的題目和真的工具驗證，不要只用範例資料。
- 量測後才排程：追蹤被接受的產物比例、退件原因、人工修訂時間、權限例外與回復成本。
可以用下面這份簡短契約啟動第一個 PM Bot：
目標：把本週的使用者回饋整理成一份 RFC 草稿。
輸入：指定的 Slack 頻道、訪談資料庫與產品數據看板，只讀。
輸出：Notion 草稿，包含問題、引用、影響範圍、V1、不做的範圍與驗收條件。
交接：需要介面設計時標記設計 Bot；需要數據時標記分析 Bot。
停止條件：來源互相矛盾、需要登入新工具、準備對外發送、會花錢、會刪除資料，或要改正式環境時，立刻停下來請人核可。
禁止：不得捏造引用、不得自行發布、不得合併程式碼。
方案、裝置與還沒承諾的功能
官方產品頁目前列出 Cursor 每月 20 美元、Grok 每月 30 美元、Cursor Teams 每席每月 40 美元，並說明符合資格的 Cursor、SuperGrok 或 Teams 方案已包含 Grok Bot。幣別保留官方使用的美元，實際資格仍應以登入後的方案頁為準。
工作坊現場也宣布 Android 應用程式在當天推出；官方頁目前已提供 Google Play 連結。至於多帳號切換，團隊只說正在考慮，沒有日期或承諾。這類資訊很容易變動，導入前要回官方頁再確認。
這場示範沒有證明什麼
它沒有證明全自動產品團隊已經成熟，也沒有提供外部可重現的速度、成本或品質比較。現場使用的是團隊自己的資料、工具、設計系統與 Cloud Agents，且講者知道流程會怎麼走。
它能證明的範圍很明確：多 agent 工作流已經可以跨研究、文件、設計與程式碼環境產生可交接的成果。接下來最難的問題，會是組織願不願意把來源、權限、驗收與責任寫清楚。
常見問題
Grok Bot 和一般 AI 聊天有什麼差別？
一般聊天以單次問答為主。Grok Bot 是具名、持續存在的隊友，能保留記憶、檔案、瀏覽器工作階段與偏好，並在自己的工作畫面操作工具、和其他 Bot 交接。
為什麼不用一個萬用 Bot？
多個 Bot 能提供清楚的責任歸屬、平行執行與各自聚焦的記憶。資料問題找 Ashley、PRD 找 Pete、工程拆解找 Emily，比讓一個 agent 同時扮演所有角色更容易檢查和修正。
人類一定要保留哪些工作？
目標與優先順序、策略修訂、權限提升、對外溝通、付費與刪除、code review、部署與程式碼合併。Bot 可以準備產物，但高風險或不可逆的動作應停在核可之前。
官方真的說 Grok Bot 占兩位數比例的內部合併 PR 嗎？
是，Kevin Niparko 在官方 PM 指南寫下這項內部數據。它屬於產品團隊自述，沒有經過第三方評測，因此適合用來判斷內部採用程度，不適合當成普遍生產力保證。
最適合先自動化哪一段？
先從可逆、可驗收、已有明確來源的研究整理開始，例如把固定幾個回饋管道整理成有引用的 RFC 草稿。等人工退件率和修訂時間穩定後，再加入設計、ticket 與 Cloud Agents。
權威引用
- xAI — Grok Bot 官方產品頁
- SpaceXAI Docs — Grok Bot Overview
- Kevin Niparko — Grok Bot for PMs
- Cursor — Grok Bot For Product Best Practices
Author Insight
這套示範最值得抄的，是 Emily 被明確教成「不要寫程式碼」的工程經理；整支 11 個 Bot 的名單反而其次。好的角色定義同時要寫能力與禁區。只列「你能做什麼」，沒有寫「何時停下來」，最後還是會把所有例外推回給人收拾。
如果只能先做一件事，我會先寫交接契約，再建 Bot。名稱、頭像和組織圖都很容易；來源、驗收條件與停止點才決定這支隊伍能不能進入真實工作。
術語表
- Attention list（注意力清單）：從實際回信、會議、文件與對話推測目前注意力，不等同預先排好的待辦清單。
- Routine：經過驗證、可按需或定時重跑的工作流程。
- Cloud Agent：在準備好的程式碼環境裡執行實作、測試與驗證的 agent。
- Scoped memory（聚焦記憶）：各 Bot 只累積與自身職責相關的回饋與脈絡。
- Human gate（人類閘門）：在高風險或不可逆動作前，強制停下來等待人類核可。
