Grok Bot Galaxy 直播：第 1 天（第 24/44 段）

🧑‍🏫 這段出自 Grok 直播第一天。講者先分享他怎麼用 bot（能自己接任務、自己執行的 AI 助手）指揮一群 AI 同時寫程式，整理出三個實用心得。接著團隊現場開工，準備在舊金山辦快閃餐廳，示範怎麼把審查修改、整理問題回報這類雜事交給自動化處理。想讓 AI 幫你分工做事的人，可以直接參考他的做法。

• 274:32 Bot 跟人一樣可以同時處理幾件事，但任務一多就會開始失去 context
  ↳ context 是 bot 當下能記住的內容，容量有限。就像人同時被交代太多事會忘東忘西，bot 手上的任務一多，前面講過的細節也會開始漏掉。
• 274:32 講者的 engineer bot 可以從 marketplace 取得，內建一個 Notion database，裡面列出每個任務和它目前的階段
  ↳ marketplace 是大家分享、下載 bot 的地方。講者的 engineer bot 可以在那裡找到，它附一個 Notion database（Notion 裡的表格資料庫），記錄每個任務做到哪一步。
• 275:03 就算一個 bot 管 20 個 cloud agents，也不必把資訊全塞進有限的 context，要接下一個任務時回頭查這個 DB 就好
  ↳ cloud agents 是在雲端幫你執行任務的 AI 工人。bot 不用把 20 個任務都記在腦中，就像主管看進度表，要接下一件事時回頭查表就好，不會記到爆掉。
• 275:34 bug bots 能找出 agent 產生的問題；security comment 功能能監控洩漏、session management 等潛在安全問題
  ↳ bug 就是程式錯誤，bug bots 專門抓 AI 寫出來的錯。security comment 則負責盯安全風險，例如資料外洩，或 session management（管理登入狀態，像多久自動登出）出問題。
• 276:05 講者的 workflow：進 PR 審查後 merge；cloud agent 會回傳截圖，說明做了哪些事
  ↳ PR 是「我改好了，請審」的修改申請，merge 是審過後把修改正式併進去。講者的 workflow（工作流程）是：看 PR、合併；agent 做完會附上截圖，說明改了什麼。
• 276:35 給 cloud agents 的 prompt 現在都由講者的 agents 撰寫，他只需要決定哪些事要做、哪些要砍掉
  ↳ prompt 是給 AI 的指令文字。現在連這些指令都交給他的 agents 寫，他只負責做決定：哪件要做、哪件砍掉，不必自己一個字一個字交代。
• 276:35 看到任務回傳的截圖，就有信心直接 merge
  ↳ 截圖讓他直接看到成果長什麼樣子，不用每行程式都看懂。畫面對了就敢按合併，等於是看結果來驗收，而不是逐項檢查過程。
• 277:05 收穫一：把 bot 當實習生。溝通卡住時別把它當 agent 看或硬叫 skills，改用傳訊息的方式聊
  ↳ skills 是預先寫好、讓 bot 照步驟執行的能力包。跟 bot 溝通卡住時，別一直硬叫這些功能，改成像傳訊息給同事那樣，用平常講話的方式把事情聊清楚。
• 277:37 像對待有才華的實習生：一開始不知道要做什麼，但交代清楚後就能很能幹
  ↳ 實習生剛到不知道要做什麼很正常，問題通常出在交代不清楚。把目標和背景講明白，bot 就能做得很好。
• 277:37 收穫二：往前多想一層，不要只是修眼前的問題，也就是減少重複
  ↳ 意思是遇到問題別只修眼前這一次，要想想它會不會一再發生，從根本把重複的工作省掉。
• 278:07 同一個 prompt 要打或複製貼上給 agent 10 次很浪費時間，應該抽出成 playbook，或交給另一個 bot 在對的時機提醒 bot
  ↳ playbook 是寫好的固定做法手冊。同一段指令貼十次很浪費時間，應該整理成手冊讓 agent 照著做，或另外派一個 bot 在該提醒的時候自動提醒。
• 278:07 收穫三：用 Cursor cloud agents 做工程時，要有完整的 feedback loop
  ↳ Cursor 是用 AI 寫程式的工具，它的 cloud agents 能在雲端自己改程式。feedback loop 是讓 agent 做完後知道結果對不對的回饋機制，一定要做完整。
• 278:39 不論哪種工程任務，都需要 feedback loop 讓 agent 知道成功或失敗；Grockbot 也靠它判斷要繼續提醒，還是停下來讓 PR merge
  ↳ 沒有回饋，agent 就不知道自己做對沒有。Grockbot 也是看這個訊號來決定：還沒成功就繼續催，成功了就停下來，讓 PR 合併。
• 278:39 例子：讓 agent 透過 computer use 操作網站，講者認為這是最簡單的 feedback loop
  ↳ computer use 是讓 AI 像人一樣看螢幕、點滑鼠。讓 agent 自己打開網站點點看，畫面正不正常馬上就知道，講者認為這是最容易做到的回饋方式。
• 280:05 Lauren 說明背景：SpaceX AI 的 Slack 有很多自動化，例如自動審 PR、自動分類 bug reports
  ↳ Slack 是很多公司在用的工作聊天軟體。Lauren 說 SpaceX AI 內部的 Slack 有很多自動化，例如自動審查 PR、自動把 bug 回報分類，省掉很多人工。
• 280:35 Lauren 想先建立基本流程：bots 把 PR 貼到 Slack channel 審查，之後 merge，或許再研究自動部署
  ↳ 她想先把基本流程搭起來：bot 把 PR 貼到 Slack 的 channel（討論頻道）給大家審，審完就合併。之後也許再研究自動部署，也就是改好後自動上線。
• 281:44 團隊要做的專案是在 San Francisco 辦實體餐廳快閃店，要召集想參加的人和能讓活動實現的人
  ↳ 專案是在舊金山辦實體的快閃餐廳，要同時找兩種人：想來參加的客人，以及能幫忙把活動辦起來的人。
• 281:44 團隊本身不是餐廳業者，可能要找餐廳、串連人脈、找場地、處理所有後勤
  ↳ 團隊不是開餐廳的，所以找餐廳合作、串人脈、找場地、處理後勤，都得從零開始張羅，要忙的事很多。
• 282:14 打算把為快閃店做的軟體包裝成產品來賣；延伸目標是第三天前開始賺錢
  ↳ 除了辦活動，他們打算把過程中做出來的軟體包裝成產品來賣。更有挑戰性的目標，是在直播第三天之前就開始有收入。
• 282:14 CEO 的畫面在串接 GitHub、設定 repositories，也就是設定 Cursor cloud agents 的權限
  ↳ CEO（執行長，就是講者本人）正在設定：GitHub 是存放程式碼的平台，repositories 是一個個專案資料夾。串接好並選定資料夾，就等於告訴 Cursor 的 agents 可以動哪些程式碼。
• 282:45 CEO 的 workflow 通常從 Grockbot 開始，再轉到 Cursor
  ↳ CEO 的習慣是先從 Grockbot 開始，再轉到 Cursor 讓 agents 去寫程式。
• 282:45 團隊職稱：講者是 CEO；Rashan 是 CPO（chief product officer）；Lauren 是另一個 CPO（chief potato officer），也兼 CTO
  ↳ 職稱帶點玩笑：講者是 CEO；Rashan 是 CPO，也就是產品長；Lauren 也叫 CPO，不過是「首席馬鈴薯長」，同時兼任 CTO（技術長）。
• 283:18 設定 Cursor：先授權組織（ship by Thursday），再選要用的 repositories，主要是兩個
  ↳ 設定 Cursor 分兩步：先授權他們的組織（名稱叫 ship by Thursday），再勾選要讓它存取的程式碼資料夾，主要是兩個。
• 283:48 CEO 建了幾個 bots，例如 prioritizer bot 和 operator research
  ↳ CEO 已經建了幾個各有分工的 bot，例如 prioritizer bot（從名字看是排優先順序用的）和 operator research。
• 283:48 operator research 用來研究辦過類似快閃店的業者，列出餐廳業者和營運者名單，幫忙理解商業計畫
  ↳ operator research 專門研究辦過類似快閃店的業者，整理出餐廳業者和營運者的名單，幫團隊搞懂這門生意怎麼做。
• 284:19 研究到的例子有 Flower and Water、Hakasa Restaurant Group
  ↳ 它找到的例子包括 Flower and Water 和 Hakasa Restaurant Group，團隊可以拿來參考。
• 284:19 建 bot 用的是 Lauren 的 Dr. Eggbot，marketplace 上找得到，是最早的精選 bots 之一，專門用來做更多 bots，算是 bot 工廠
  ↳ 這些 bot 是用 Lauren 的 Dr. Eggbot 做出來的。marketplace 上就找得到，它是最早一批精選 bot，功能是幫你做出更多 bot，像一座 bot 工廠。
• 284:49 Lauren 在 Slack 開了新 channel，包括 PR review channel；她或她的 bots 會把 PR 連結貼在這裡
  ↳ Lauren 在 Slack 開了幾個新頻道，其中一個專門審 PR。她本人或她的 bot 會把 PR 連結貼進去。
• 285:20 Cursor 上剛設好一個自動化，目前很陽春，只有一段 prompt
  ↳ automation 是設好條件後會自動執行的流程。她剛在 Cursor 設好一個，目前很陽春，內容只有一段指令。
• 285:50 這個自動化會審 PR，檢查 correctness、risk、有沒有漏掉測試；channel 每有一篇貼文就會觸發
  ↳ 頻道一有新貼文，它就自動啟動，檢查三件事：correctness（改得對不對）、risk（會不會弄壞別的地方），以及有沒有漏寫測試（用來確認程式正常運作的檢查）。
• 285:50 Lauren 也在建 bug reports channel，會設定類似的自動化，網頁上線後或許再想辦法自動收集 X 上的回饋
  ↳ 她也在開 bug 回報頻道，會設定類似的自動化。等網頁上線後，也許再想辦法自動收集 X（前身是 Twitter）上的使用者回饋。

講者總結時說，跟 bot 溝通卡住、不知道怎麼講時，應該怎麼對待它們？