Grok Bot Galaxy 直播：第 1 天（第 22/44 段） ☕ Buy me a coffee

🧑‍🏫 這段是 Grok 官方直播的其中一段。講者分享他怎麼讓 Grok bot 每天幫團隊做事，像是半夜清理程式、處理公司內部的小雜事、系統出錯時自動修。他也分享怎麼像帶團隊一樣分工管理好幾個 bot。最後現場示範讓舊 bot 教新 bot 上手，可以看到 AI 從「一問一答」變成「會自己跑的同事」。

• 250:39 bot 很「好說話」，預設可能什麼都接受。所以要替它設邊界：講清楚為什麼要這樣做、哪些事不該做，並附上理由
  ↳ bot（能自動幫你做事的 AI 機器人）預設很配合，你叫它做什麼，它幾乎都照做。所以要先講好哪些事不能做，而且附上理由。遇到規則沒寫到的狀況，它才有判斷依據。
• 250:39 bot 有 memory system，會記住你講過的話，用在之後的決策。像「這個太複雜，要簡化」這種話，不用一講再講
  ↳ memory system（記憶系統）指 bot 會記住你交代過的偏好。像你說過一次「太複雜了，簡化一點」，它之後做事都會照這個原則，你不必每次重講。
• 251:09 流程中有很多 authentication 步驟，bot 容易被卡住。要讓人類能順利幫 bot 解除卡關，這一點很重要
  ↳ authentication（身分驗證）是登入、輸入驗證碼這類確認身分的關卡。bot 很常卡在這裡，所以流程要設計成人類能很快幫它過關，否則整件事會停住。
• 251:09 用法一：nightly code cleanup（夜間程式碼清理）。marketplace 上也找得到這個 bot
  ↳ 第一個用法是 nightly code cleanup（夜間程式碼清理），也就是趁晚上自動整理程式碼。marketplace（下載現成 bot 的地方）上已經有做這件事的 bot，可以直接拿來用。
• 251:39 過去一年大家可能交出了一些 sloppy code，又很難要求每個 agent 都遵守同一套規則，所以改成趁夜間把這些爛程式碼清掉
  ↳ 這一年大家用 AI agent（會自己動手寫程式的 AI 助手）交了不少 sloppy code（草率、品質差的程式碼）。與其要求每個 agent 都守規矩，不如每晚統一收拾。
• 251:39 夜間沒有人在交程式碼，比較不會發生衝突；清的大多是 sloppy code，風險也低
  ↳ 白天很多人同時改程式，容易改到同一個地方而互相衝突。半夜沒人在改，清理就不會撞到。清的多半又是本來就寫得差的部分，改壞的風險也小。
• 252:10 清理內容例如：把程式碼濃縮成較小的 module、刪掉冗長又惹人厭的註解
  ↳ module（模組）是把程式拆成功能獨立的小塊。清理就是把鬆散、重複的程式收成精簡的模組，再刪掉又長又囉嗦的註解（寫在程式裡、給人看的說明文字）。
• 252:10 可以讓 cursor cloud agents 依你設的條件自動 merge PR，例如附上清楚的 end-to-end 證明就能 merge
  ↳ PR（pull request）是「請把我的修改併進去」的申請，merge 就是正式併入。cursor cloud agents（在雲端跑的 AI 寫程式助手）可以照你定的條件自動併入，例如附上完整實測通過的證明。
• 252:10 講者的設定：每天凌晨 3:00，bot 會啟動 research cloud agents，檢查整個 monorepo
  ↳ 講者設定每天凌晨 3 點，bot 自動派出負責研究的 cloud agents，把整個 monorepo（公司所有專案放在一起的大程式碼庫）從頭檢查一遍。
• 252:43 檢查項目：程式碼品質不佳、該模組化卻沒有好好模組化、註解沒有精簡到必要的程度，以及防止東西被偷的 security audit
  ↳ 檢查重點有四個：程式寫得好不好、該拆成模組的有沒有拆、註解是否精簡到剛好，還有 security audit（資安檢查），也就是找出可能讓資料或程式被偷的漏洞。
• 253:14 講者早上醒來時，就已經有一批 PR 在等著
  ↳ 結果是講者睡覺時 bot 在工作，他早上起床就有一批改好的 PR 等著他看，再決定要不要併入。
• 253:14 用法二：internal tooling。例子是用 email 把人加進 TestFlight，而不是發連結
  ↳ 第二個用法是 internal tooling（公司內部自用的小工具）。例子是 TestFlight（蘋果讓人搶先試用 iPhone App 的平台），直接用 email 把同事加進去，不用發邀請連結。
• 253:14 傳統做法是寫內部 dashboard，加上 authentication 和 database，部署到登入牆後面再發給員工。有 agent 寫程式，大概一兩個小時就能完成
  ↳ 傳統做法要做一個 dashboard（內部操作網頁），加上登入驗證和 database（存資料的資料庫），放在只有員工能登入的地方。現在有 AI 寫程式，大約一兩小時就能完成。
• 253:45 Grok bot 的彈性在於：可以透過更簡單的介面執行邏輯，例如一則 Slack 訊息
  ↳ 用 Grok bot 的話，連這個網頁都不用做。同一件事只要在 Slack（公司常用的聊天軟體）發一則訊息就能觸發，操作簡單很多。
• 254:16 大家在 Slack mention bot 並附上 email，bot 就會透過 routine 或 Slack 的 webhook 訊號，執行加人進 TestFlight 的流程
  ↳ 同事在 Slack 上 @ bot 並附上 email，webhook（某件事發生時自動通知另一個系統的機制）就會通知 bot。bot 接著跑 routine（事先設定好的固定流程），把人加進 TestFlight。
• 254:16 講者只需要確保 bot 能安全存取 TestFlight，再給它一個 prompt 說明要做什麼，這個內部工具就能用了
  ↳ 講者只做了兩件事：讓 bot 能安全登入 TestFlight，再寫一段 prompt（給 AI 的文字指示）說明要做什麼。這個內部工具就能用了。
• 254:46 用法三：autofix everything。以前 CI 變紅時通常是 ping on call 的人，現在只有真的必要才會找 on call
  ↳ 第三個用法是 autofix everything（什麼壞了都自動修）。CI（程式一改動就自動跑的測試檢查）變紅代表有東西壞了。以前會直接找 on call（輪班待命處理故障的工程師），現在不一定要。
• 255:16 CI 變紅時，bot 會自動檢查哪裡壞掉，接著 spin up 一個 cloud agent 去修，並依照指示判斷該不該 merge
  ↳ CI 一變紅，bot 先查出哪裡壞，再 spin up（臨時開一個）cloud agent 去修。修完後，它照你事先給的規則判斷能不能直接併入。
• 255:16 這樣需要人類來看、讓人在任務之間切換情境的情況就非常少了
  ↳ 工程師最怕做到一半被叫去救火，回來還要重新進入狀況。現在需要人出手的情況少很多，大家比較能專心做手上的事。
• 255:47 不只 CI，deployment errors、CI flakiness，或內部 pipeline 裡任何有 signal、alert 的任務，都能接到 Grok bot 上
  ↳ 不只 CI，deployment errors（上線部署失敗）、CI flakiness（測試時好時壞、結果不穩定），或內部 pipeline（自動化作業流程）裡任何會發警示的地方，都能先交給 bot 處理。
• 255:47 大約 10 分鐘還沒解決才 ping on call；多數情況下，bot 10 分鐘內就能處理完
  ↳ 規則是讓 bot 先處理大約 10 分鐘，還沒解決才找 on call 的人。講者說多數問題 bot 在 10 分鐘內就搞定了。
• 256:18 管理 bot 的方式：現在介於「只需要一個 bot」和「需要一整個 fleet」之間
  ↳ 接著談怎麼管 bot。講者說現在剛好在中間：只用一個 bot 不太夠，但也還不需要一整個 fleet（一大群 bot 組成的隊伍）。
• 256:18 講者的配置：chief of staff 是 Ling Shishi；Craig 負責 UI engineering、Steve 負責 DevX、Hogan Wan 負責 infra
  ↳ Ling Shishi 是 chief of staff（幕僚長，負責統籌分派）。Craig 管 UI engineering（畫面介面開發），Steve 管 DevX（開發者工具），Hogan Wan 管 infra（伺服器等基礎設施）。
• 256:49 這些 bot 都跑同一個模型，任何任務都做得來；分成三個工程 bot 是為了 context 跟 fleet 管理
  ↳ 這幾個 bot 用的是同一個 AI 模型，能力一樣，誰都能做任何事。分成三個工程 bot 不是因為專長不同，而是方便管理各自的 context（它手上記著的資訊）和整個隊伍。
• 256:49 每個 bot 依工作內容，pipeline 略有不同，也各有 context limit；分開放可以避免一個 bot 切換太多任務而超出 context limit
  ↳ context limit 是 bot 一次能記住的資訊上限，塞太多就會開始忘記前面的事。每個 bot 的工作流程不太一樣，分開負責，就不會因為一直換任務而超過上限。
• 257:19 跟 Hogan 講過的指示會保存在 Hogan 的 memory 裡，新任務能直接接著用既有的 context，不必重抓指示，整個 fleet 跑得更快
  ↳ 例如跟 Hogan 交代過的做法會留在它的記憶裡。下次遇到同類任務，它直接接著做，不用重新說明或重查資料，整個隊伍因此跑得更快。
• 257:49 平常主要跟 chief of staff 對話，由它把需求分派給各個工程 bot，除非必要不用直接找個別的 bot
  ↳ 講者平常只跟幕僚長 bot 說話，由它轉派給對的工程 bot。就像跟主管交代事情一樣，不必自己去找每個組員。
• 257:49 chief of staff 知道誰在做什麼，又不必記住所有工程流程，可以省下自己的 context
  ↳ 幕僚長只要知道誰負責什麼、做到哪裡，不用記每個工程細節。這樣它自己的 context 不會被塞滿，能專心協調。
• 258:21 現場 demo：講者先前已從 marketplace 下載一個 engineer bot，設定好要負責的 repository，也連上了 Notion
  ↳ 現場 demo（實際示範）：講者之前已經從 marketplace 下載一個工程師 bot，指定它負責的 repository（某個專案的程式碼庫），也連上了 Notion（筆記與任務管理工具）。
• 258:21 接著從 marketplace 的 Grok bot team 那一區下載 nightly audit engineer，它會自己開始跑 onboarding 任務
  ↳ 接著他從 marketplace 的 Grok bot team 專區，下載一個 nightly audit engineer（專做夜間檢查的工程師 bot）。它一裝好就自己開始跑新人上手的流程。
• 258:51 新 bot 不了解現有的工程流程，所以講者不自己教，而是請既有的 engineer bot 幫新成員 onboard，並把新 bot 改名為 Steve
  ↳ 新 bot 還不懂團隊的做事方式。講者沒有自己教，而是請已經在工作的工程師 bot 帶它 onboard（讓新人熟悉環境和流程），還把新 bot 取名為 Steve。
• 259:54 Craig 用純文字傳訊息給 Steve，內容包括 Notion board 的做法、「clean」的定義，以及流程各階段怎麼推進；Steve 確認後存進 memory
  ↳ Craig 用一般文字訊息教 Steve：Notion 看板怎麼用、怎樣才算「clean」（清理完成）、任務在各階段怎麼往下推。Steve 確認後存進自己的記憶。
• 260:26 bot 之間可以直接對話，不必在 bot 之間複製貼上。講者也不用自己跟 Steve 談，Craig 會回報一切已確認
  ↳ 重點是 bot 之間能直接溝通，人不用當傳話筒在兩邊複製貼上。講者全程沒跟 Steve 說話，最後是 Craig 回報「都交代好了」。
• 260:26 Steve 現在有了 nightly audit skills。平常是凌晨 4 點跑，為了 demo 現場先啟動
  ↳ Steve 現在會做夜間檢查了。正式排程是每天凌晨 4 點跑，為了現場示範，講者先讓它馬上開始。
• 261:28 等 Steve 做研究的同時，示範怎麼跟 agent 平行工作：請 bot 確認 flyair.com 的使用者是否真的無法查看已訂的航班
  ↳ Steve 在做研究的同時，講者又交代另一件事，示範怎麼讓好幾個 agent 同時工作：請 bot 確認 flyair.com 的使用者是不是真的看不到自己訂的航班。
• 262:01 bot 能在自己的電腦上瀏覽網站、點擊操作，再回報情況
  ↳ bot 有自己的一台電腦，可以真的打開網站、點按鈕、操作畫面，像真人一樣實際試用，再回報它看到的狀況。
• 262:01 很多工程師的工作流程沒辦法透過 MCP 完成；需要照指示或在特定時間點按按鈕時，可以請 bot 用它的電腦去做
  ↳ MCP 是讓 AI 連接其他工具的標準接法，但很多工程工作沒有這種接法可以用。這時可以讓 bot 直接用它的電腦，照步驟操作，或在指定時間去按按鈕。

講者說 autofix 的設定是：bot 大約多久還沒解決問題，才會 ping on call？