Grok Bot 產品最佳實踐：用一支 Bot 團隊完成研究、PRD、設計與交付
整理版優先睇
Grok Bot 將「管理一支 Bot 團隊」產品化，令產品經理可以同時指揮跨職能 AI 同事完成研究、PRD、設計與交付。
呢篇文章係 SpaceXAI 產品團隊嘅 Kevin Neilson 同 Roshan Sadanani 喺一個工作坊嘅分享，主題係 Grok Bot 嘅產品最佳實踐。佢哋想解決嘅問題好實際：產品經理成日要做跨職能協調，但一個人根本冇辦法同時 handle 研究、PRD、設計、技術執行咁多條線。佢哋開場引用咗 DHH 嘅講法，指出軟件開發已經慢慢變成產品管理，『應該做乜、點樣做、做成點、優先度係乜』變成每個人都要回答嘅問題，Grok Bot 正正係為咗呢種工作方式而設計。
整體結論係：Grok Bot 唔係另一個更強嘅聊天助手，而係將『管理一支團隊』本身產品化。佢哋提出嘅核心設計原則是將 Agent 當同事——每個同事有自己嘅電腦、長期記憶、可以獨立工作、用即時消息溝通。喺實際配置上，佢哋建立咗一個包含 Chief of Staff、工程經理、工程師、數據分析師、產品經理、設計師同招聘嘅 Bot 團隊，所有 Bot 共享同一台雲端電腦，但各自有獨立屏幕、記憶同例程。咁樣做可以並行工作、角色清晰，同時符合現實組織結構。
工作坊示範咗四個核心工作流，包括注意力清單、例程、研究到 PRD、同埋交付。最值得注意嘅係『注意力清單』呢種新原語：從你實際行為推斷你嘅注意力，而唔係靠你手動寫優先級。另外，Bot 之間可以互相協作，例如 PM Pete 寫好 PRD 之後，工程經理 Emily 會自動拆解任務並分派俾工程師 Bot 執…
- Grok Bot 核心係將 Agent 當同事，每個 Bot 有自己嘅電腦、記憶同例程，並共享同一台雲端電腦基礎設施。
- 多 Bot 團隊比單一全能 Agent 優勝喺四點：可指認性、並行、作用域記憶、對應現實組織。
- 『注意力清單』係新工作原語：由你實際行為推斷你嘅注意力，可做消息過濾器或者同你講嘅優先級做 diff。
- 工作流示範咗 Bot 可以互相協作：PM 寫好 PRD，工程經理拆解分派，工程師 Bot 用 Cloud Agents 編碼，人只做審批。
- 快速復刻方法：將任何一個 Bot 指向 Kevin 嘅 X 帖子，佢會自動搭出同樣嘅團隊並詢問你嘅工作習慣。
設置注意力清單嘅 prompt
每小時看郵件、Slack、Granola、日曆，生成一份我正在關注的項目、當前狀態和下一步。
Grok Bot For Product Best Practices 工作坊影片
Kevin Neilson 同 Roshan Sadanani 喺 SpaceXAI 分享完整演示。
將 Agent 當同事：Grok Bot 嘅設計哲學
Kevin 同 Roshan 喺工作坊開場引用 DHH 嘅觀察：軟件開發正在變成產品管理，『該做什麼、怎麼做、長什麼樣、優先級是什麼』變成每個人都要回答嘅問題。Grok Bot 就係為咗呢種『人人都是產品經理』嘅工作方式而設。
佢哋歸納咗三個設計動機，解釋點解普通 chat 介面唔夠用。
- 聊天框適合問答，但 PM 嘅工作係跨職能、面向結果嘅協調，超出 Q&A 形態。
- 早期經驗話佢哋知，俾 Agent 有自己嘅環境去驗證產出，質量會大幅提升，所以自然延伸就係俾每個 Agent 一台自己嘅電腦。
- 人冇辦法同時盯住幾十個 Agent 線程，好多工程師要自己搭『協調者 Agent』，但呢種做法從未被產品化成一等公民。
將 Agent 當同事，而唔係當軟件。
同事嘅四個特徵——把工具串起來產出結果、有長期記憶、能獨立工作、用即時消息溝通——直接映射為產品功能。
呢個設計令 Agent 唔再淨係被動答問題，而係可以主動產出成果。
一支向 PM 匯報嘅 Bot 團隊
佢哋實際配置咗一支由多個角色組成嘅 Bot 團隊，每個角色對應現實部門。
- Kora（Chief of Staff）：唯一嘅通才，管日曆、Slack、收件箱；維護『注意力清單』；冇變化時保持安靜。
- Emily（工程經理）：被明確訓練成唔寫代碼，負責拆解 PRD、分派任務俾工程師 Bot、按目標驗收。
- 5 名工程師 Bot：接 Emily 任務，底層調用 Cloud Agents 編碼，互相協調、彼此驗證。
- Ashley（數據分析師）：接數據湖同用戶研究庫，每日早上睇 dashboard，識用團隊鍾意嘅圖表風格回答。
- PM Pete：寫 RFC/PRD、做研究、彙總反饋、跨 Bot 協調。
- Pixel（設計師）：接 Figma 同設計系統，靈感來自 Lenny 通訊入面設計師發佈嘅設計體系。
- Rey（招聘）：揾人才、推進面試流程。
點解要用多個 Bot 而唔係一個全能 Bot？佢哋俾咗四條理由。
- 1 可指認性：知道數據問題揾 Ashley，設計問題揾 Pixel。Roshan 話『只用一個 Agent 時我個腦處理唔嚟』。
- 2 並行：多個 Bot 可以同時做唔同任務。
- 3 作用域記憶：每個 Bot 喺自己領域邊做邊學，唔會撈亂。
- 4 對應現實組織：真實公司本來就係由專才組成。
關鍵機制：所有 Bot 共享同一台雲端電腦（文件、瀏覽器會話、應用登錄共享），但每個 Bot 有獨立屏幕、記憶、上下文同例程。
咁樣交接時唔需要重複配置，但一次登錄對所有 Bot 可見——安全邊界喺賬號級，唔係 Bot 級。
Chief of Staff 唔應該去調試評測，評測 Bot 亦唔應該去歸檔郵件，因為作用域記憶要先分清楚。
四個核心工作流：由注意力到交付
工作坊示範咗四個核心工作流，全部圍繞『將管理團隊產品化』呢個目標。
- 1 注意力清單（Attention List）：一種新嘅工作原語。
- 2 例程（Routines）：令 Bot 從被動變主動。
- 3 研究到 PRD：Bot 之間並行協作產出文件。
- 4 交付：用羣聊 + Cloud Agents 完成真實任務。
先講最搶眼嘅注意力清單。佢唔係你事先寫嘅優先級或待辦，而係由你實際行為湧現出來——Bot 觀察你喺 Slack 回覆咗乜、處理咗邊啲郵件、改過 Notion 邊度，然後反推你嘅注意力而家喺邊。
注意力清單有兩個用法：做訊息過濾器，或者同你口頭講嘅優先級做 diff，睇嚇有冇偏離。
每小時看郵件、Slack、Granola、日曆，生成一份我正在關注的項目、當前狀態和下一步。例程令 Bot 可以主動。你一句『每小時幫我清理收件箱』，Kora 就自動創建定時任務；Bot 睇到你重複做某件事時，仲會主動建議或者幫你整例程。
例程保留對所有已連接工具嘅訪問權，所以唔使每次重新授權。
Bot 可以透過觀看你喺佢電腦上嘅操作示範嚟學會流程，之後將成個流程固化做例程。
研究到 PRD 嘅示範用『雙向語音模式』做例子：PM Pete 由 Reddit、X、內部 Slack 攞需求，同時查語音轉語音 benchmark；Ashley 並行計 TAM/SAM 同周活滲透率；之後 Pete 用 PRD 模板寫入 Notion RFC，仲叫 Pixel 出設計圖，直接填返入 RFC。
最後交付部分：Pete 同 Emily 入羣聊，一句『Pete 寫好 PRD，你哋對一下，Emily 開始建』，就觸發成串行動——Emily 確認範圍、拆工單、分派俾工程師 Bot，工程師各自用 Cloud Agents 寫代碼。需要登錄或審批時，Emily 會暫停並 @ 人類。
呢種任務分派加審核嘅模式唔係現場指令，係 Emily 喺過去工作中學到嘅行為。
人做最後一公里：審核、精煉同下一步
分享者對人同 Bot 嘅邊界定得好清：卸載俾 Bot 嘅係苦活同低複雜度工作，例如收集、彙總、初稿、分派。人保留最後一公里嘅審核同精煉。
人仍然負責研究結論嘅判斷、PRD 嘅戰略層面、代碼審查，同任何對外發送嘅郵件。
文檔仲提到一個細節：人要親自發消息同改文檔，一來係為咗『去 AI 味』，二來係因為收信人想確認發信人真係思考過。
Roshan 總結佢嘅體驗。
問答環節有幾個關鍵補充。
- 上下文管理：目標係『你永遠唔需要擔心上下文』。Bot 超長運行，近期嘅事記得好清楚，好耐冇提嘅自然淡出。
- 學習方式：除文字糾正外，可以錄製你喺佢電腦上嘅操作去學；『讀我過去嘅 Slack，寫一份我嘅寫作風格指南』被認為係槓桿最高嘅指令。
- 內部採用：最早喺 GTM 團隊（銷售、財務、售後）揾到產品市場契合；產品同工程團隊嘅高用量係意外驚喜。
- 路線圖：擴展接觸面同能力，例如 Android 版啱啱發佈。多賬號支持『喺考慮，暫無承諾』。
快速復刻：將任何一個 Bot 指向 Kevin 嘅 X 帖子，佢會自動搭出同樣嘅團隊並問你嘅工作習慣。
一句話總結：呢個工作坊展示嘅唔係更強嘅聊天助手，而係將『管理一支團隊』產品化——PM 核心技能由親手做變成定義目標、配置團隊、審核結果。
SpaceXAI 產品團隊入面嘅 Kevin Neilson 同 Roshan Sadanani 搞咗一場工作坊，專講 Grok Bot 產品最佳實踐。透過 45 分鐘嘅分享，展示咗一種新嘅產品團隊組織方式：PM 第一次擁有一支真正「向自己匯報」嘅團隊——不過成員全部係 Bot。
Grok Bot For Product Best Practices
https://www.youtube.com/watch?v=x5OawRpQxII
開頭引用咗 DHH 嘅觀點做背景：軟件開發本身而家正在變成產品管理——「應該做啲乜、點樣做、出嚟會係點、邊樣應該優先」變成咗人人都要答嘅問題。Grok Bot 就係為咗呢種「人人都係產品經理」嘅工作方式而設計嘅。
點解要做 Grok Bot（設計動機）
佢哋歸納咗內部使用同客戶反饋入面浮現出嚟嘅三個痛點：
聊天框唔適合用嚟「做嘢」嘅 Agent。聊天框適合答問題，但 PM 嘅工作係跨職能、以結果為目標嘅協調工作，超出咗 Q&A 嗰種形態。 Agent 需要自己有嘅工作環境。早期 Cloud Agents 嘅經驗話咗畀我哋知：如果俾 Agent 可以驗證自己嘅產出，成果質素會大幅提升；所以自然延伸就係畀每個 Agent 一部自己嘅電腦。 人冇辦法同時盯住幾十個 Agent 線程。好多工程師自己搭咗個「協調者 Agent」去管其他 Agent，但從來冇俾人產品化成為一個正式產品。
由呢度就得出咗設計綱領：要將 Agent 當做同事，而唔係當做軟件同事嘅四個特徵——將工具串埋一齊嚟做出結果、有長期記憶、可以獨立工作、用即時訊息溝通——呢啲全部都直接變成產品功能。
一句話嚟定義：Grok Bot = 一個自己有部電腦嘅 Agent + 一隊可以交到真實工作嘅 AI 同事團隊特點係傾向主動行動、邊做邊學、做完先返嚟、卡住咗先至揾你。
佢哋嘅 Bot 團隊配置
| 受過明確訓練，係唔寫代碼嘅。 | ||
點解要用多個 Bot，而唔係用一個全能嘅 Bot呢度有四條理由：
可指認性：知道有數據問題應該揾邊個、設計問題應該揾邊個（Roshan 話：「得一個 Agent 嗰陣，我個大腦處理唔曬。」） 並行：多個 Bot 可以同時做唔同嘅嘢。 作用域記憶：每個 Bot 會喺自己嘅範圍入面邊做邊學，Chief of Staff 唔應該走去 debug 評測，負責評測嘅 Bot 都唔應該去歸檔電郵。 對應現實組織：公司本身就係由專才組成嘅。
再補充一個關鍵機制：所有 Bot 會共用同一部雲端電腦（文件、瀏覽器工作階段、應用登入資訊都係共享），但每個 Bot 都有自己獨立嘅屏幕、記憶、上下文同例行程序。咁樣交接嗰陣唔使再重複設定，同時都表示登入一次之後，所有 Bot 都睇得到（即係安全邊界係喺帳户層面，而唔係 Bot 層面）。
四個核心工作流程（示範部分）
1. 注意力清單（Attention List）—— 一種新嘅工作原語
呢個係成個場合最值得關注嘅概念。同優先次序清單或者待辦清單唔同，佢並唔係你預先寫低嘅，而係由你實際嘅行為入面湧現出嚟嘅Bot 會睇你喺 Slack 覆咗啲乜、處理咗啲乜郵件、喺 Notion 改咗啲乜，然後反推「你嘅注意力而家係邊度」。
有兩種用法：
作為一個過濾器：每日成千條訊息入面，只會將同你而家關注緊嘅項目相關嗰啲推俾你，其餘嘅自動歸檔。 作為一個參照：將「我話嘅優先順序」同「我實際花時間做緊嘅嘢」做 diff，睇出有咩偏離。
設定方法非常簡單，用一句自然語言就得：「每個鐘睇一次郵件、Slack、Granola、日曆，然後整一份我而家關注緊嘅項目、當前狀態同埋下一步出嚟。」
2. 例行程序（Routines）—— 令 Bot 由被動變成主動
喺示範入面，一句「每個鐘幫我清嚇收件匣」就令 Kora 自動建立咗一個定時任務。重點如下：
如果 Bot 見到你不斷重複做同一件事，佢會主動建議或者建立例行程序。 例行程序會保留訪問所有已連接工具嘅權限。 Bot 仲可以透過睇你喺佢部電腦上面做一次操作示範，嚟學識成個流程，再將佢固化成為例行程序。 典型用例：X MCP 上線之後，叫 Ashley 每個鐘推送一次安裝量脈搏，取代咗以前「開住儀錶板不停刷新」嘅做法。
3. 由研究寫到 PRD —— 並行、引用、Bot 之間互相協作
佢哋當場以「雙向語音模式」做例子（呢個係觀眾即場投票揀出嚟嘅需求），完整咁行咗一次流程：
PM Pete 去 Reddit、X、內部 Slack 反饋頻道同用戶研究庫收集資料，整合需求。 同一時間，Pete 又去查語音轉語音模型嘅 benchmark，確定技術揀邊款。 Ashley 就並行計算市場規模（TAM／SAM）同埋現有語音功能嘅每週活躍滲透率，輸出返品牌風格嘅圖表。 Pete 用團隊嘅 PRD 模板將呢啲全部寫入去 Notion RFC（包括機會、用戶痛點、方案、TLDR、範圍以外嘅事項）。 用戶同 Pete 講「順手叫埋 Pixel 做設計」，Pete 就自己將上下文（種子文案、視覺簡報）打包發俾 Pixel；Pixel 喺 Figma 出完圖之後交返轉頭，直接填入 RFC 嘅 mock 佔位位置。
有兩個喺示範入面不斷被強調嘅實作細節：要對 Bot 提出引用來源嘅要求咁樣方便核查；另外就係「Agent 好擅長寫 prompt 俾其他 Agent」，所以人類唔使手動搬嚟搬去上下文。
4. 交付 —— 羣組對話 + Cloud Agents
將 Pete 同 Emily 拉入同一個羣組對話，講一句「Pete 寫好咗 PRD，你哋對一對，Emily 就開始起」，之後：
Emily 同 Pete 確認需求來源同 V1／MVP 嘅範圍。 Emily 將 PRD 拆做一張張工單，分派俾工程師 Bot（Eileen、Larry 等會自動俾人拉埋入嚟）。 工程師 Bot 各自啟動 Cloud Agents 去寫代碼（Cloud Agents 個環境已經預裝好代碼庫、依賴、密鑰同測試能力）。 遇到要登入或者要審批嘅情況，Emily 就會暫停，再 @ 人類嚟解鎖。
呢套「任務分派＋審核」嘅模式，唔係現場俾嘅指令，而係 Emily 喺過去工作入面學返嚟嘅行為。演講者提到，公司內部有雙位數百分比嘅合併 PR 而家係由 Grok Bot 開動嘅 Cloud Agents 所產生。
人喺呢個運作裏面佔咩位置？
佢哋對邊界劃得好清楚：
交俾 Bot 做嘅係苦悶同低複雜度嘅嘢（收集、整合、起稿、派單）。 人類就保留最後一公里嘅審核同精煉：研究結論要點判斷、PRD 嘅戰略層面、代碼審查、任何要對外寄出嘅電郵、採購，以至一啲刪除類嘅操作。 文檔入面仲有兩點值得留意：仍然由真人親自發出訊息同改文檔。一嚟係為咗「去 AI 味」，二嚟係因為「收信人想知發信嗰個人係真係諗過先至寫出嚟」。
Roshan 總結：「我能夠發起嘅工作量同管理到嘅工作量，都比以前多好多；所以反而有更多時間擺喺審核同諗下一步上面——呢啲正正就係做產品嘅人應該花時間嘅地方。」
問答環節嘅關鍵資訊
上下文管理：目標就係「你永遠唔需要擔心上下文」。Bot 係超長時間運行嘅（同 Chief of Staff 嘅對話已經持續咗幾個月），啱發生過嘅事記得清清楚楚，好耐冇提過嘅事就會自然淡出，唔再打擾你。已經有嘅 Agent 上下文體系同 skills 都可以直接遷移。 學習方式：除咗靠文字糾正，仲可以錄低你喺佢部電腦上面嘅操作，等佢學。「讀我過去嘅 Slack，寫一份我嘅寫作風格指南」呢條指令被認為槓桿最高。 內部採用：最早喺 GTM 團隊（銷售、財務、售後服務）出現產品市場契合；產品同工程團隊嘅高用量，係一個意外驚喜。Linear 入面好多工單都係由 Bot 開出嚟。 路線圖：有兩個方向——擴展接觸面（嗰日啱啱推出 Android 版），同埋擴展能力（加更多連接器同工具）。多帳號支援方面，「有考慮緊，但暫時未有承諾」。 快速復刻：只要將任何一個 Bot 指去 Kevin 嗰篇 X 帖文，佢就會自動砌返一支一樣嘅團隊出嚟，同時問清楚你嘅工作習慣。
用一句話總結呢場工作坊：佢展示嘅唔再係另外一個更加勁嘅聊天助手，而係將「管理一支團隊」呢件事本身產品化——PM 嘅核心技能，由親手做變成訂目標、配置團隊、審核結果。
SpaceXAI 產品團隊 Kevin Neilson 和 Roshan Sadanani 做了一場工作坊，主講 Grok Bot 產品最佳實踐。通過 45 分鐘分享，展示一種新的產品團隊組織方式：PM 第一次擁有一支真正"向自己彙報"的團隊——只不過成員是 Bot。
Grok Bot For Product Best Practices
https://www.youtube.com/watch?v=x5OawRpQxII
開場引用 DHH 的觀點作為背景：軟件開發正在變成產品管理——"該做什麼、怎麼做、長什麼樣、優先級是什麼"成了每個人都要回答的問題。Grok Bot 就是為這種"人人都是產品經理"的工作方式設計的。
為什麼要做 Grok Bot（設計動機）
歸納了內部使用和客戶反饋中浮現的三個痛點：
聊天框不適合"幹活"的 Agent。聊天框適合問答，但 PM 的工作是跨職能、面向結果的協調，超出了 Q&A 形態。 Agent 需要自己的工作環境。早期 Cloud Agents 的經驗表明：讓 Agent 能驗證自己的產出，結果質量會大幅提升；自然延伸就是給每個 Agent 一台自己的電腦。 人無法同時盯着幾十個 Agent 線程。很多工程師自己搭了"協調者 Agent"去管其他 Agent，但從未被產品化成一等公民。
由此得出的設計綱領：把 Agent 當同事，而不是當軟件。同事的四個特徵——把工具串起來產出結果、有長期記憶、能獨立工作、用即時消息溝通——直接映射為產品功能。
一句話定義：Grok Bot = 一個有自己電腦的 Agent + 一支可以交付真實工作的 AI 同事團隊。特點是有行動傾向、邊幹邊學、做完才回來、卡住時才找你。
他們的 Bot 團隊配置
| 被明確訓練成不寫代碼 | ||
為什麼是多個 Bot 而不是一個全能 Bot，給出了四條理由：
可指認性：知道數據問題找誰、設計問題找誰（Roshan 說"只用一個 Agent 時我的大腦處理不過來"） 並行：多個 Bot 同時幹不同的事 作用域記憶：每個 Bot 在自己的領域裏邊幹邊學，Chief of Staff 不該去調試評測，評測 Bot 也不該去歸檔郵件 對應現實組織：公司本來就是由專才構成的
補充一個關鍵機制：所有 Bot 共享同一台雲端電腦（文件、瀏覽器會話、應用登錄共享），但每個 Bot 有獨立的屏幕、記憶、上下文和例程。這既讓交接不需重複配置，也意味着一次登錄對所有 Bot 可見（安全邊界在賬號級而非 Bot 級）。
四個核心工作流（演示部分）
1. 注意力清單（Attention List）—— 一種新的工作原語
這是全場最值得關注的概念。區別於優先級清單或待辦清單，它不是你事先寫的，是從你的實際行為中湧現的：Bot 觀察你在 Slack 回了什麼、郵件處理了什麼、Notion 改了什麼，反推"你的注意力此刻在哪裏"。
兩種用法：
作為過濾器：每天上千條消息中，只把與當前關注項相關的推給你，其餘自動歸檔 作為對照：把"我說的優先級"與"我實際在花時間的事"做 diff，發現偏離
設置方式非常簡單，一句自然語言："每小時看郵件、Slack、Granola、日曆，生成一份我正在關注的項目、當前狀態和下一步。"
2. 例程（Routines）—— 讓 Bot 從被動變主動
演示中一句"每小時幫我清理收件箱"就讓 Kora 自動創建了一個定時任務。要點：
Bot 看到你反覆做同一件事時會主動建議或創建例程 例程保留對所有已連接工具的訪問權 Bot 還可以通過觀看你在它電腦上的一次操作演示來學會流程並固化為例程 典型用例：X MCP 上線後，讓 Ashley 每小時推送安裝量脈搏，取代了"開着 dashboard 反覆刷新"
3. 研究到 PRD —— 並行、引用、Bot 之間互相協作
現場以"雙向語音模式"為例（觀眾實時投票選出的需求），完整走了一遍：
PM Pete 抓 Reddit、X、內部 Slack 反饋頻道、用戶研究庫，彙總需求 Pete 同時去查語音轉語音的模型 benchmark，確定技術選型 Ashley 並行計算市場規模（TAM/SAM）和現有語音功能的周活滲透率，輸出品牌風格的圖表 Pete 用團隊的 PRD 模板把這些寫進 Notion RFC（含機會、用戶痛點、方案、TLDR、範圍外事項） 用戶對 Pete 說"順便叫上 Pixel 做設計"，Pete 自己把上下文（種子文案、視覺簡報）打包發給 Pixel，Pixel 在 Figma 出圖後交回，直接填進 RFC 的 mock 佔位區
兩個被反覆強調的實踐細節：要求 Bot 附帶引用來源以便核查；以及"Agent 非常擅長給其他 Agent 寫提示"，人不需要手動搬運上下文。
4. 交付 —— 羣聊 + Cloud Agents
把 Pete 和 Emily 拉進一個羣聊，一句"Pete 寫好了 PRD，你們對一下，Emily 開始建"。隨後：
Emily 與 Pete 確認需求源頭和 V1/MVP 範圍 Emily 把 PRD 拆成工單，分派給工程師 Bot（Eileen、Larry 等自動被拉入） 工程師 Bot 各自啓動 Cloud Agents 編碼（Cloud Agents 環境預裝了代碼庫、依賴、密鑰、測試能力） 遇到需要登錄或審批時，Emily 會暫停並 @ 人類來解鎖
這套"任務分派 + 審核"的模式不是現場指令，是 Emily 在過去的工作中學到的行為。演講者提到內部兩位數百分比的合併 PR 現在來自 Grok Bot 發起的 Cloud Agents。
人的位置在哪裏
對邊界的表述很清晰：
卸載給 Bot 的是苦活和低複雜度的工作（收集、彙總、初稿、分派） 人保留最後一公里的審核與精煉：研究結論的判斷、PRD 的戰略層面、代碼審查、任何對外發送的郵件、採購、刪除類操作 文檔裏另有兩點值得注意：仍由人親自發消息和改文檔，一是為了"去 AI 味"，二是因為"收信人想知道發信人真的思考過"
Roshan 的總結："我能發起的工作量、能管理的工作量都比以前多得多，因此我反而有更多時間花在審核和思考下一步上——這正是產品人該花時間的地方。"
問答環節的關鍵信息
上下文管理：目標是"你永遠不需要擔心上下文"。Bot 是超長運行的（與 Chief of Staff 的對話已持續數月），最近的事記得清，很久沒提的事會自然淡出，不再打擾你。已有的 Agent 上下文體系和 skills 可直接遷移。 學習方式：除了文字糾正，還能錄製你在它電腦上的操作讓它學；"讀我過去的 Slack，寫一份我的寫作風格指南"被認為是槓桿最高的一條指令。 內部採用：最早在 GTM 團隊（銷售、財務、售後）出現產品市場契合；產品和工程團隊的高度採用是意外之喜。Linear 工單很多由 Bot 發起。 路線圖：兩個方向——擴展接觸面（當天剛發佈 Android 版）和擴展能力（更多連接器和工具）。多賬號支持"在考慮，暫無承諾"。 快速復刻：把任何一個 Bot 指向 Kevin 那篇 X 帖子，它會自動搭出同樣的團隊並詢問你的工作習慣。
一句話概括這場工作坊：它展示的不再又一個更強的聊天助手，是把"管理一支團隊"這件事本身產品化——PM 的核心技能從親手做變成了定義目標、配置團隊、審核結果。