AI 應用 · Multi-Agent
一個人怎麼帶 22 個 AI 員工？｜Grok Bot Galaxy 直播 Day 1 完整整理
從第一隻 bot 怎麼建，到官方員工的五到六隻分工，再到一個人用 22 隻 bot 經營 7 個事業。Day 1 四場工作坊與主直播的完整整理。
發佈 2026-09-17 ｜ 最後更新 2026-09-22
從第一隻 bot 怎麼建，到官方員工的五到六隻分工，再到一個人用 22 隻 bot 經營 7 個事業。Day 1 四場工作坊與主直播的完整整理。
Grok Bot 官方在舊金山連播三天，現場用他們自己的 AI bot 從零做一門生意。這篇整理第一天的全部場次：官方入門場、工程場、產品經理場、創辦人場，以及中間的主直播建置時段。
整條線剛好是從最淺走到最深。入門場講第一隻 bot 怎麼建，工程場與產品經理場是官方員工把自己每天在用的五到七隻 bot 攤開講，創辦人場則是一位用 22 隻 bot 經營 7 個事業的來賓分享。你可以從自己現在的位置接進去。
這場直播的設定很直接：團隊在舊金山，用三天時間，靠 Grok Bot 從零開始做一門生意，邊做邊直播。
Day 1 的最後一場是給創辦人的場次，主講人是 Shub Gaur，分成兩段。前段是他回答現場觀眾的提問，問題幾乎都跟「bot 開多了之後怎麼管」有關。後段連線一位來賓，她同時經營 7 個事業，手上有 22 個 Grok bot，直播團隊請她幫忙看他們正在規劃的快閃活動。
以下照主題整理，不照直播的時間順序。
Day 1 的第一場是官方入門場，講者 Roman Ugarte 先講了他們怎麼看 AI 工具這幾年的變化：一開始是聊天，接著是你把任務交出去，旁邊有個副駕駛協助你把它完成，現在他們想做的是讓 AI 更像一個同事。
他用「同事」這個詞來對照「任務」。過去的用法是你想到一件任務就開一個對話，用完就丟。他們想做的是你有一個固定的對象，它記得你教過它的事，你可以持續跟它合作。
官方講了三個他們刻意做的產品決定：
| 決定 | 他們的說法 |
|---|---|
| 介面做成聊天 | 讓它用起來像在跟同事傳訊息，不是在操作一個工具 |
| 給它一台自己的電腦 | 不只靠接口串工具，它可以像人一樣操作電腦，看影片、聽播客、操作九零年代那種老舊的政府系統 |
| 全部跑在雲端 | 不佔用你的電腦 |
建立的動作很簡單，輸入一個名字就建好了。系統會依名字猜這隻 bot 可能的用途，給你幾個選項。
比較實用的是那個切入點的建議。講者說，決定第一個 bot 要做什麼的時候，問自己一句話：我這一天當中最煩、最不想做的是哪一件事。
另一個實用建議是在 bot 的描述欄寫清楚指令。示範的那隻簡報 bot，描述欄裡寫了字型、顏色、改完要截圖回報這類具體要求。講者說寫得越明確，它每次做出來的東西越一致。
入門場示範了一個叫「教它一個任務」的功能。
操作方式是：你進到 bot 的電腦裡，親手把流程做一遍。講者特別說明，這一段是人在控制 bot 的電腦，不是 bot 自己在做。做完停止錄製，bot 會把這段錄影變成一項技能存起來。
之後你只要說「上次我教你的那個動畫，套到這一段」，它就會做。
例行任務就是排程。示範的寫法大概是這樣：
有人問把 bot 放進群組，跟讓它們私下互相傳訊息有什麼差別。講者的回答是：差在你看得見。
群組裡的協作示範是，你在群組裡說要做一張新投影片，簡報 bot 去做圖表，寄信 bot 等它做完才發信，每一隻都回報給主要的那一隻。
至於把真人也加進 bot 群組，官方說還在做，目前類似的機制是在通訊軟體裡標記 bot。
記憶是長期保存的，你每一次糾正、引導它，都會寫進記憶裡。你也可以自己修改。
三件要知道的事：
每隻 bot 的執行環境是彼此隔離的，一隻 bot 不能直接進到另一隻的電腦操作。底層是輕量的 Linux 虛擬機。創辦人場另外提到，這些環境之間有共用的檔案區，bot 讀得到彼此的檔案，但各自的對話記憶是分開的。
講者提到一個他自己的用法：在飛機上網路很差的時候，他把要用電腦做的事全部外包給 bot，因為運算跑在雲端，他這邊只要能傳訊息就好。
企業環境也可以設定，把 bot 的電腦鎖得很緊或開得很寬，甚至讓它進到公司的內網。
速度是已知的弱項，官方說會持續改善。
這四條是入門場裡最可以直接套用的部分。
先講你要的結果，讓它自己反推步驟。 講者說他每次都從「我要產出什麼」開始講，而不是從第一步開始交代。
它做錯的時候，要講清楚錯在哪。 常見的錯誤是只跟它說「這樣不對」，卻沒有給足夠細節，它就學不到東西。講者的做法是說明哪裡出錯、要怎麼修，做對的時候也告訴它。
它拒絕你或一直反問，代表你該教它東西了。 講者說這是訊號，不是故障。
在描述欄交代它可以轉給誰。 想走總管制的話，直接在 bot 的描述裡交代它可以委派給哪些 bot。
Day 1 的工程場講者是 Lingxi Li，他說自己用這套工作流兩個月了。
| bot | 負責什麼 |
|---|---|
| 總管 bot | 統籌調度，其他 bot 的入口 |
| 介面工程 bot | 前端畫面 |
| 開發者體驗 bot | 後來也接手每晚的程式碼健檢 |
| 基礎設施 bot | 系統底層 |
| 維運主管 bot | 管團隊的規則手冊，負責擋住緊急件規則亂擴散 |
他為什麼要拆這麼多隻？他的說法是：單一 bot 塞太多任務會撞到脈絡的上限，而且難以管理它底下那一堆雲端代理。拆開之後，講給某一隻聽的事情就留在那一隻的記憶裡。
這是工程場講得最細的一套設定。
他讓 bot 每天凌晨 3 點啟動雲端代理，把整個程式庫掃一遍做健檢。等他早上起床，已經有一批準備好的程式修改在等他審。
另外兩個設定也值得抄：
這個做法省掉很多重複交代。他從市集下載了一隻每晚健檢的 bot 進團隊，沒有自己重新交代一次規則，而是跟既有的 bot 說：團隊來了一個新成員，把它改名，然後告訴它我們的工程流程是怎麼跑的。
規則的管理也是同一個思路。他不把常態規則複製貼上給每一隻 bot，因為十幾二十隻的時候這樣不會有效率。他的做法是把規則寫成一份定義，交給維運主管 bot，由它統一發布到團隊的規則手冊。
他還提到一個小技巧：用回覆或引用的方式下指令，這樣 bot 直接帶到你引用的那段脈絡。
| 限制 | 直播中的說法 |
|---|---|
| bot 太好講話 | 預設什麼都接受，所以邊界要自己劃，還得教它怎麼說不 |
| 逼太緊會失去脈絡 | 催得太急、任務塞太多，它會開始掉脈絡 |
| 寫程式的代理常跑很久 | 他說這是業界公認的問題，跟急件需求直接衝突 |
| 猜測不可接受 | 他明講不要 agent 用猜的，要的是每次都一樣的結果 |
| 交付缺證據要回頭催 | 修改沒附截圖或效能數字，他得再催一次，他自己說這件事很煩 |
他的判斷準則是不看過程、看證據。截圖、效能對比這類東西拿出來，他才審。
Day 1 的產品經理場講者是 Kevin Niparko。這場的設定比工程場更像一間公司：六隻各司其職，其中工程主管那隻底下還帶著五隻工程 bot。
| bot | 負責什麼 |
|---|---|
| 總管 bot | 管信箱、日曆、監看通訊軟體 |
| 工程主管 bot | 底下帶五隻工程 bot，它自己被訓練成不寫程式，只管人 |
| 資料分析 bot | 接上資料倉儲，跑查詢、出圖 |
| 產品經理 bot | 寫需求文件與規格 |
| 設計 bot | 事先餵了品牌設計系統與規則 |
| 招募 bot | 找人 |
工程主管底下那五隻各有名字，這場示範的重點就是它們怎麼串起來。
這場的主要示範就是這條鏈，走法如下：
講者說，要不要人進來審、審到多細，可以照風險高低自己決定。現場示範選設計方案的時候，他讓觀眾投票決定用 A 還是 B。
他讓資料 bot 每天早上 6 點送一份摘要過來，當作他一天在這個系統裡看的第一件事。重大改版上線的期間，他會改成每小時報一次。
另一個設定是降噪：他告訴 bot，沒有重要或緊急的事就不用來找他。他的信箱由 bot 先梳理過，只有最重要的才會告訴他。
這比反覆複製貼上順很多。他直接在文件工具裡留評論，標記某一隻 bot，bot 讀得到評論，就在那邊來回修改。
同一場也提到 bot 之間互相標記交接，以及那個「錄下操作教它一遍」的功能，他說特別適合那種流程很複雜的老系統。
這是產品經理場的核心心法。
講者的說法是：agent 其實很會下提示詞，常常比我們自己更清楚它需要什麼脈絡。所以與其把每一步都寫死，不如把脈絡給足，讓它自己判斷要什麼。
記憶的架構他也講了：每一隻 bot 有自己的記憶，另外有一個共享的記憶池，bot 可以選擇性地把東西寫進去。
產品經理場講者提到，在他們內部，Grok Bot 產出的程式修改佔已合併總量的兩位數百分比。他沒有給更精確的數字。
同一場還有一個生態的數字：有位員工把自己的工程工作流打包成開源外掛放上市集，上個月靠它產出了兩千五百件程式修改，換算下來一天八十三件。 ---
工作坊之外，三個人在鏡頭前真的從零開始做生意
工作坊之外的時段，三個人在鏡頭前真的從零開始做生意。第一天的主直播最值得看的是他們做決定的過程，成果反而其次。
開播的時候他們手上什麼都沒有。前一天在社群上問大家「我們該做什麼生意」，收到數千則回覆。
第一件事是開一隻市場研究 bot，把那幾千則回覆讀完、彙整出主題。這隻 bot 的名字是聊天室投票決定的。
主持人自己訂了時限：三天，而且開播沒多久就說時間已經在浪費了。
第一位連線來賓做了十幾年產品經理，現在自己經營內容事業。他給的判斷框架只有三個問題：客戶是誰、他的痛點是什麼、你提供的價值是什麼。
他還講了幾句對一人公司很實在的話：
他自己在用 bot 的方式是讓它們更主動：設排程定期回報，要求用編號清單呈現方便一條一條回覆，每週固定一次簽核。
收斂之後他們選了快閃店。理由是想做有實體、有在地元素的東西，而且三天內看得到成果。
做法是兩層：自己先實際辦一場快閃店，把過程中做出來的軟體變成可以賣給別人的產品。
這段是第一天的關鍵轉折。
原本要做餐廳快閃店。開始查執照之後發現，餐飲加酒牌的流程太複雜，還要找廚師與人力。當場他們把概念改成藝術展快閃店，理由很現實：省掉食品與酒類的執照，只要場地保險。
新的構想是徵集在地藝術家、開放社群投稿、線上有畫廊可以逛、線下辦實體展、賣作品印刷品。
場地的部分也查出具體數字：政府場地的初審要四到十五個工作天，可能拖到數週，所以他們改找倉庫型的空間。
| bot | 負責什麼 |
|---|---|
| 市場研究 bot | 讀社群上數千則回覆，彙整主題 |
| 幕僚長 bot | 其中一位主持人的主要窗口，彙整指令轉發給其他 bot，也負責部署網頁 |
| 造 bot 的 bot | 可以查看並修改其他所有 bot |
| 原型 bot | 用純網頁語法做低保真原型，直接在對話裡渲染，不用部署 |
| 工程 bot | 決定正式技術架構，後來被指示改用雲端代理處理長期專案 |
| 程式審查 bot | 專門審工程 bot 送出的修改 |
| 開發客戶 bot | 找餐飲業者與潛在客戶 |
| 行銷、創意總監、營運 bot | 想品牌與網域名稱、寫公司營運文件 |
| 找場地 bot | 查場地與許可證，結果直接存進文件工具 |
| 知識庫管理 bot | 每五分鐘去問所有活躍中的 bot，萃取重點寫進文件 |
那隻知識庫管理 bot 他們自己下的比喻是版本紀錄：只留重點，不要洗版。
開麥克風口述兩三分鐘，最後請它覆述。 其中一位主持人的原話是：打開麥克風講幾分鐘，講完加一句「用你自己的話把我剛剛講的重述一次，讓我知道你聽懂了」。
在訊息上按愛心。 對某一則訊息按愛心，bot 會知道你認可這個方向。
寫一份最精簡的公司說明，餵給所有 bot。 他們用文件工具存一份創始文件當唯一真相來源，所有 bot 都以它為準。理由是給的資訊越多，它越會依賴那些資訊，所以垃圾進去就是垃圾出來。
先用手做一次，再決定要不要自動化。 其中一位主持人說他要先親自打幾通電話訂場地，看看實際上有多難，那會告訴他哪些地方需要自動化。
不要為了測試另外接一個假資料庫。 他們的判斷是測試用的東西之後要整個拔掉重做，不如一開始就接真的。
不要過度打磨。 原話是還在新創階段，目標是活到明天，做基本的、之後可以延伸的就好。
不要重造輪子。 搜尋功能直接用現成的地圖接口，他們只在上面加一層自己的篩選條件。
用比對來做初步檢查。 講者的做法是，bot 獨立研究出來的結論如果跟他自己想的一樣，他就當作這套設定目前是可用的。
第二位連線來賓經營一個買賣公司的平台，社群上有一千五百萬追蹤者。她講的東西跟前一位的角度很不一樣。
先賣給三個人，再決定要不要做。 她說在你決定做什麼生意之前，先看能不能賣給三個人。她也提醒兩千間公司裡只有兩間拿得到創投，小生意本來就拿不到。
分發比產品更該優先。 她自己的例子是發一則有爭議的貼文，帶來五百七十萬次觀看、兩千個註冊。廣告要等有機成長驗證過之後再加碼。
學框架，不要抄文字。 她的具體做法是把表現最好的那些貼文餵給 bot，叫它拉出前十五則的框架來學。她強調要學的是框架本身，原本的字句不要照抄。
她點名最糟的一句建議是「找到 A 咖然後放手不管」。 她說自己照這句話做，差點把現金燒光。她把這個道理直接套到 bot 上：不能放養，要持續盯著、持續修正。
建一個證據庫。 把所有人講過你產品的好話、推薦、影片、截圖全部分類存起來，之後募資與宣傳都用得上。她提醒現在就開始截圖記錄成長曲線。
要幫小商家導入 AI，先反過來問。 她引用一句話說要反過來想：不要問怎麼賣 AI 給小商家，要問怎麼幫小商家賺到現金。理由是小商家平均利潤率只有百分之十五左右，跟營收沒有直接關係的東西賣不動。
她最後那句話是：做出來不代表就會有人來。
Day 1 最後一場：台上問答，加上一位用 22 隻 bot 經營 7 個事業的來賓
創辦人場除了下面整理的問答，還有幾條偏操作面的建議：
現場第一個問題是：講者說設定 bot 要花一到兩個小時，那到底要怎麼開始？
講者的回答分成兩步。第一步是盤點，把你需要做的每一件事都列出來。列完之後才能分組。
第二步是把相近的事分成一組，每一組交給一個專家 bot，例如財務 bot、客服 bot、行銷 bot。他習慣讓 bot 先專精一個領域，等他問它的問題超出原本範圍，再讓它慢慢擴大負責的事。
分組之後會遇到下一個選擇：要讓你直接跟每個專家 bot 對話，還是設一個總管 bot 去管其他 bot？
講者自己偏好專家制。好幾個專家 bot，你自己下去管細節，一個一個訓練。他說適合喜歡掌控細節的人。
總管制是設一個「幕僚長」bot 管其他 bot，你只跟這一個窗口講話。講者說如果你只想把工作整包交出去、只跟一個對象溝通，這種方式也很好。
他的結論是看個人偏好，沒有標準答案。有意思的是，後段的來賓用的正好是總管制。
來賓的背景是創投、全職創作者，經營自己的媒體事業，最近又成立了一間幫主管經營個人品牌的代理商，家裡還有一個剛出生的寶寶。她說 22 個 Grok bot 讓她可以同時處理這些事。
她的分工大致是這樣：
| bot | 負責的事 |
|---|---|
| 總管 bot | 督導所有事業，從出租房產的房客與住客、代理商業務，到品牌合作邀約 |
| 收件匣 bot | 只負責盯信箱 |
| 會議紀錄 bot | 接每一場會議的紀錄，把裡面的待辦分派給其他 bot |
| 財務 bot 組 | 記帳、財務、收據 |
平常每個 bot 各做一件核心的事。遇到大專案時，總管 bot 會把相關的 bot 拉進來，一起在對話裡把事情啟動。
她提到的 7 個事業，直播中明確講到的有房地產、創投基金、媒體事業與代理商，其餘沒有逐一說明。
有人問：開了一群 bot，怎麼讓它們不要過度溝通，又能控制 token 花費（token 是 AI 計算用量與費用的單位）？
講者說 Grok Bot 有一個功能，可以把好幾個 bot 放進同一個群組對話。好處是很複雜、需要大家一起參與的任務，它們可以一起做。
壞處是它們都很積極，放在一起就會開始搶著講話。講者的原話是它們「都很愛講話」，做得很認真，但越做越多，費用也越來越高。
他的建議是暫時少用群組。很多時候你只需要讓一個 bot 標記另外兩個 bot 一次，各自分開處理，比看著一整群 bot 連續回覆划算。
企業用戶問：有沒有辦法讓 bot 的決定都照一套固定規則走，確保安全？
講者先直接承認，模型本身每次跑出來的結果就是不一樣。
他給的做法是讓模型去寫程式，因為程式每次跑的結果都一樣。具體來說：讓它把決策規則寫成一段程式或一張決策樹，然後規定「只要遇到這類決定，每一次都去跑這段程式，照結果執行」。只要背後有一段可以驗證的程式，決策就能照規則執行、事後也查得到；講者的說法是讓 AI「扮演」有固定規則的樣子，模型本身仍不保證每次一致。
他也提到另一種做法，讓 bot 在做決定前先去問另一個 bot 取得許可，但他認為給規則、讓它跑程式比較好。
來賓幫直播團隊規劃快閃活動時，建議他們開一個專門查法規的 bot。她上一次辦研討會，申請了十幾種不同的許可。直播中也提到各個城市的規定不一樣，所以讓 bot 先查清楚這場活動需要申請哪些許可。
直播團隊接著提到，這類 bot 也可以幫忙看合約。來賓補充她律師朋友的說法：把 AI 當成法學院二年級的學生。條文讀得懂，但不一定懂這個城市、這個產業實際上怎麼運作、行情是多少。所以合約的第一輪審閱可以交給它，最後還是要有經驗的人把關。
直播快結束時，團隊問來賓：今晚睡覺前，應該讓哪些 bot 先跑起來？
來賓建議讓場地搜尋 bot 整晚找符合條件的場地，把詢價信先寫好，早上他們審過要寄給誰，再按送出。她說這是她最常用的方式：讓 bot 整晚把信寫好，早上她只需要看過、按送出。
要 bot 幫忙談價，先給它預算範圍。她舉自己的例子：有一個 bot 正在幾個二手衣物平台上幫她賣衣服、跟買家議價，她事先給了議價的框架。所以直播團隊的第一步是先讓活動企劃 bot 列出預算，再拿預算去詢價。
她在直播中口述、團隊當場輸入的預算 bot 指令，整理在文末的提示詞區。
有觀眾抱怨：要讓 bot 連上各種工具，一直被要求設定金鑰和驗證，很挫折。
講者的建議是少一點硬性指定。他舉自己的例子：他最後選用 Granola 當會議紀錄工具，原因是這個工具最方便 Grok Bot 抓逐字稿、整理出他要的重點，跟他喜不喜歡這個工具沒有關係。他也說，之後如果出現更直接的官方整合，他那個專門優化其他 bot 的 bot 可能會自己發現並換過去。
另一位觀眾問怎麼把原本在其他工具的設定搬進來。講者說他們正在做讓這件事更簡單的 bot。他的做法是把你原本分散在各個工具的 MCP 與 API 連線集中成單一來源（MCP 和 API 都是讓 AI 連接外部工具的接口）。他也提到兩種整合方式：用 1Password 匯入帳密後透過它的 MCP 讓 bot 使用，以及把瀏覽器的 cookies 匯入，讓 bot 沿用你已登入的狀態。
提醒一下：匯入 cookies 或帳密，等於讓 bot 拿你的登入身分去操作那些網站，它能做的事跟你本人登入一樣多。只匯入這個 bot 真的用得到的網站；如果是客戶或公司的帳號，先確認對方同意、講好它可以做到哪裡。
講者也坦白，驗證這塊還在處理中，而且有些公司明確表示不希望 bot 進到他們的平台。
有觀眾問：很多舊系統沒有 API，或 API 比網頁操作貴很多，bot 走網頁操作什麼時候能跟 API 一樣快？
講者給兩個方向。第一是盡量用無頭瀏覽器（沒有畫面、由程式直接操作的瀏覽器），直接下指令點網頁上的元素，省掉「截圖、判斷、再點」的來回。第二是官方持續加快模型操作電腦的速度。
他也坦白說，要比 API 還快很難，因為多一層就會慢一點，官方的目標是盡量接近。
直播提到 Grok Bot 與 Cursor 有直接整合。Grok Bot 可以啟動 Cursor 的雲端代理，只把相關的脈絡交過去，讓雲端代理獨立作業。做完之後，只要 Grok Bot 有那個環境的存取權，就能回頭測試、檢查做出來的東西，甚至直接處理送出的 PR（程式修改要合併進正式版本前的申請）。
什麼時候交給 Cursor 雲端代理？講者的判斷是：任務複雜、要上線、想自己決定用哪個模型、想自己進去改東西的時候。其他情況用 Grok Bot 就好。他建議實際多開幾次，自然會抓到分寸，只要講一次，Grok Bot 就能把工作交出去。
模型選擇也可以自己指定。在 Cursor 或 Grok Build 的雲端代理裡設定，或直接跟模型說「這類任務每次都用某個模型」。
叫 bot 忘掉某件事。 講者說很多人不知道，你可以直接傳訊息叫 bot 忘記某些事。如果發現它一直引用某段舊脈絡，就跟它說「忘掉所有關於某件事的內容」，它會把相關記憶清掉，也能省 token。
bot 之間共用檔案，不共用記憶。 每個 bot 的電腦其實是同一台虛擬機裡的不同實例，就像你電腦上的不同桌面。它們可以讀彼此的檔案，需要時會主動去讀，但各自的對話記憶是分開的。
想讓 bot 操作你自己的電腦，要到設定開啟本機執行。 開了之後 bot 可以從你的電腦發訊息、操作你的瀏覽器。講者說官方偏向把工作放在 bot 自己的電腦上，因為本機執行有兩個麻煩：部分應用程式會在你工作時跳出視窗，讓你沒辦法同時做別的事；而且會佔用你電腦的資源。
有人問怎麼判斷 bot 市集裡的範本好不好用。
講者說官方市集目前都經過人工審查，他們從大量範本中挑出最有價值的，取得同意後再優化上架。審查除了人工，也有 bot 審 bot。
判斷一個 bot 好不好，最簡單是自己試。多數 bot 你可以先問它：「你做什麼、怎麼做？」不用讓它把整個流程跑完，就能先篩掉不適合的。
這場問答中，講者講明還沒做到或正在改善的事，整理如下：
| 項目 | 直播中的說法 |
|---|---|
| 同一套 bot 跨多台電腦 | 一週前 bot 在多台電腦之間容易混亂，官方正在投入改善，講者說現在應該好很多 |
| 不同人、不同帳號的 bot 互相對話 | 目前還不支援，正在研究適合的形式 |
| 從其他工具匯入設定 | 正在做讓匯入更簡單的 bot |
| 部分平台不歡迎 bot | 官方表示要當好生態系的一員，這是整個產業都會遇到的問題 |
| 網頁操作速度 | 目標是接近 API，講者說要超過 API 很難 |
來賓最後講了她能用很精簡的預算撐起整間代理商的原因：先想如果由人來做，團隊會怎麼分工，照人類的做法把架構建出來，再反推成 bot。
她幫直播團隊規劃快閃活動時，就是這樣拆的。辦活動在人類世界有活動企劃，底下有協調人員與工作人員，所以 bot 也照這個架構：活動企劃 bot 在上層，底下接場地搜尋、預算、法規許可這些專門的 bot。
她也提醒，就算 bot 可以處理大部分工作，報到與安全這類現場工作還是需要真人。
提示詞一：盤點與分組（依講者在直播中說明的步驟整理）
```text 我想開始用好幾個 AI 助理分工。請你幫我做三件事：
最後問我：我比較想自己跟每個助理直接對話，還是只跟一個總管助理對話。 ```
提示詞二：活動預算 bot（直播中來賓口述、團隊當場輸入的內容，翻成中文）
``text 你是舊金山的資深活動企劃，要替一場 100 到 200 人的快閃活動建立預算。 預算要包含：場地、餐飲、人力（有些場地附工作人員，有些沒有）、基本音響設備（至少要有麥克風和喇叭，讓我們可以對現場說話）。 行銷預算先不算。 ``
來賓的提醒：把這場活動的條件寫得越具體，bot 越快找到結果。直播中她追問的條件包括時間（下個月左右）、會不會提供酒類（先不要，許可比較單純）、要熱食還是外帶式餐點、需不需要場地有廚房、要不要用場地指定的外燴商。