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

🧑‍🏫 這段影片示範：怎麼讓一群 AI 機器人（bot，能自己在電腦上做事的 AI 助手）遇到急件時都照同一套規矩處理，而不是每個都要重新交代一次。講者用 Grok Bot（影片中示範的 Grok 機器人助手）設了一套「最高緊急」流程，寫進團隊共用的作業手冊，所有 bot 就會自動照做。如果你手上同時有好幾個 AI 在幫忙，常常要一再重複同樣的交代，這段值得看。

• 262:38 Bot 正在瀏覽網站，確認使用者回報的 issue 是否屬實；講者可以從電腦上即時監看它的操作
  ↳ 講者派 bot 到網站上實際點點看，確認使用者回報的 issue（問題回報，例如「某頁打不開」）是不是真的。bot 操作的每一步，講者都能在自己電腦上即時看到。
• 262:38 講者說 bot 在網頁上幾乎什麼都能做，所以大部分工作流程都可以交給它處理，不必自己卡著
  ↳ 意思是：只要是在網頁上點、填、查的工作，bot 幾乎都能代勞。所以很多日常流程可以直接丟給它，人不用守在旁邊一步一步做。
• 263:16 問題：跟 agent 說「urgent」，它可能會跳過步驟或開始猜測，只求趕快交出結果；講者不要 agent 猜，要的是 deterministic（確定、可重現）的結果
  ↳ agent（能自己規劃、動手做事的 AI 助手）一聽到「urgent（很急）」，可能為了快而跳步驟、亂猜。講者要的是 deterministic：每次走一樣的步驟，結果可預期、查得回來。
• 263:48 以前每次都要重講「我很急、該做什麼、不該做什麼」；Grok Bot／自主寫程式的重點，就是不必每次重複同樣的指示
  ↳ 以前每次開始新任務，都要重講一遍「很急、該做什麼、別做什麼」。Grok Bot 的重點是講一次它就記住，不用一直重複同樣的叮嚀。
• 263:48 講者請 chief of staff 幫團隊加入新成員 Jenny，擔任 head of operations
  ↳ chief of staff 是講者身邊的「總管」bot。講者請它幫團隊再加一個叫 Jenny 的 bot，職位是 head of operations（營運主管），專門管流程。
• 264:18 Jenny 負責管理並擁有工程團隊的 playbook，其他工程師 bot 不能修改
  ↳ playbook 是團隊的作業手冊，寫明遇到什麼狀況該怎麼做。這本手冊歸 Jenny 管、只有她能改，其他寫程式的 bot 只能照著用，避免大家各改各的。
• 264:53 Jenny 在 Notion 建立 playbook，依講者交代的「什麼時候該做什麼」更新內容，讓其他工程師都套用同一份 playbook
  ↳ Jenny 把 playbook 放在 Notion（常見的線上筆記和文件工具），照講者交代的規則更新。所有工程師 bot 讀的是同一份，做法自然一致。
• 264:53 chief of staff 和 Jenny 之間用 agent-to-agent chat 互相 handshake，講者只要跟 chief of staff 對話，不必直接交代 Jenny
  ↳ agent-to-agent chat 就是 bot 之間直接傳訊息；handshake 是它們互相確認「誰負責什麼」。講者只要跟 chief of staff 說，它會自己去跟 Jenny 交接。
• 265:23 Steve 根據內建指示，在講者沒有額外對話的情況下，自己研究 codebase 有哪些地方可以改善
  ↳ Steve 是另一個工程師 bot。它照一開始設好的指示，自己去翻 codebase（整個專案的程式碼）找可以改進的地方，講者沒有再另外叫它。
• 265:53 Steve 已經開了一批 cloud agents，看起來都跑完了；它正在把成果整理成改善程式的 PR
  ↳ cloud agents 是在雲端分頭做事的 agent。Steve 派出一批，現在看起來都做完了，它正把成果整理成 PR（交給人審核的程式修改申請）。
• 265:53 Craig 確認 issue 屬實：/trips 只是個 stub（空殼頁面），導覽列仍然連到那裡，但目前沒辦法查看之前訂過的航班
  ↳ Craig 是另一個工程師 bot，它確認問題屬實：/trips 頁只是 stub（先佔位置、沒有內容的空殼頁）。選單點得進去，但看不到以前訂過的航班。
• 266:23 講者說，coding agent 有時候會跑非常 long horizon（很長時間）的任務，這是大家普遍知道的問題，但講者需要的是趕快處理
  ↳ long horizon 是指 agent 一個任務跑很久、步驟很多。這是大家都知道的毛病，平常還能接受，但講者現在遇到的是急件，等不起。
• 266:55 一種解法是自己盯 thinking traces 和工具呼叫，在 agent 偏離時 nudge 或 steer 它；但這需要守在電腦前，而且不會想每秒都看細節
  ↳ thinking traces 是 agent 的思考紀錄，工具呼叫是它實際執行的動作。可以盯著看，走偏就 nudge／steer（推一下、拉回正軌），但人得一直守著，很累。
• 267:25 講者的作法：跟 bot 約好一套 P0 escalation 工作流程
  ↳ 講者的解法是事先跟 bot 講好一套 P0 escalation 流程。P0 是軟體團隊常用的最高優先等級，escalation 是「升級處理」，也就是遇到急件就切換成特別模式。
• 267:25 P0 的定義：Grok Bot 每五分鐘檢查一次 cloud agents 的進度，看它們目前在做什麼
  ↳ 在這裡，P0 的意思是：Grok Bot 每五分鐘巡一次 cloud agents，看它們現在在做什麼。等於有人定時來查進度。
• 267:55 舉例：cloud agent 為了等在另一個 shell 非同步執行的測試，會下 sleep 300；如果測試一分鐘內就跑完，就白白浪費了四分鐘
  ↳ 例子：agent 要等另一個 shell（下指令的視窗）裡的測試跑完，就下 sleep 300，也就是「先睡 300 秒」。測試一分鐘就跑完的話，剩下四分鐘都白等。
• 267:55 Grok Bot 如果發現 agent 在跑沒必要又很花時間的工具呼叫，可以馬上中斷，並依當下狀況下新的 prompt，完全不需要講者介入
  ↳ Grok Bot 巡的時候，如果看到這種沒必要又拖時間的動作，可以直接喊停，照當下狀況重新下 prompt（給 AI 的指令），整個過程不用講者出手。
• 268:25 講者唯一寫的就是 P0 定義：設一個 routine，每五分鐘檢查 cloud agent 有沒有偏離，例如跑 sleep 300 這種長 sleep、偏離目標或太保守
  ↳ 講者真正動手寫的，只有這段 P0 定義：設一個 routine（固定排程），每五分鐘檢查一次 agent 有沒有長時間 sleep、偏離目標，或做得太保守。
• 268:56 這只是一個很粗略的 prompt，可以隨著跟 bot 的互動慢慢改進；發現某種作法比較好，直接跟它說就行
  ↳ 這段指令一開始寫得很粗也沒關係。之後邊用邊調，發現哪種做法比較好，直接跟 bot 講一聲，它就照新的做。
• 269:27 不用再寫成 skill，也不用每次寫長 prompt，用平常訊息講一次就好，就像跟隊友說某件事很急一樣
  ↳ skill 是把指示包成可以重複套用的固定模組。講者說現在不用這麼麻煩，也不用每次寫長指令，像跟同事說「這件很急」一樣講一次就好。
• 269:59 講者點 reply 引用那則 issue 訊息，讓 bot 有上下文，再指示「fix this issue urgently, treat as a P0」
  ↳ 講者用 reply 引用那則問題回報，bot 就知道在講哪件事，接著下指令：「緊急修好，當 P0 處理」。就像在群組裡回覆特定訊息，對方就不會搞錯。
• 269:59 目前只有 Craig 知道 P0 是什麼；如果把定義一個個複製貼到每個工程師 bot，有 10、15、20 個 bot 時就沒辦法 scale
  ↳ 問題是 P0 的定義只有 Craig 知道。如果要一個個複製貼給每個工程師 bot，數量到 10、20 個就顧不來了，也就是沒辦法 scale（隨規模擴大）。
• 270:30 所以交給 Jenny 處理；Jenny 擁有 playbook 的編輯權，需要講者做決定時會主動 nudge 講者
  ↳ 所以這件事交給 Jenny。她握有 playbook 的修改權，遇到需要講者拍板的事，會主動來提醒講者，不會自己亂決定。
• 270:30 讓 Craig 跟 Jenny 討論這套 P0 流程並寫進 playbook，再由 Jenny 自動通知所有工程師 bot
  ↳ 流程是：Craig 把剛學到的 P0 做法拿去跟 Jenny 討論、寫進 playbook，再由 Jenny 統一通知所有工程師 bot，不用講者一個個轉達。
• 271:31 好處：同一件事只要想一次；之後有新流程（例如觸發 deployment 前要先做某個步驟），更新 playbook 後所有工程師 bot 就會知道，不必一個個交代
  ↳ 好處是同一件事只要想清楚一次。之後要加新規矩，例如 deployment（把新版程式正式上線）前先做某項檢查，改 playbook 就全員生效。
• 271:31 講者說這很像人類組織的運作方式，只是換成 agent 的規模；agent 有 context 上限，人有時候也有
  ↳ 講者覺得這跟公司管人很像，只是對象換成很多 agent。agent 有 context（一次能記住的內容量）上限，人有時候也記不住，所以都需要共用手冊。
• 272:02 管理人類團隊的方法，有些適用在 bot 上、有些不適用，可以拿自己的工作流程實驗看看有沒有用
  ↳ 管人的方法搬到 bot 身上，有的行得通、有的不行。講者建議拿自己平常的工作流程試試看，有效就留下來。
• 272:02 大部分對話都是 bot 之間直接進行，講者就像 engineering manager，或在帶很優秀的實習生
  ↳ 大部分溝通是 bot 彼此在談。講者比較像 engineering manager（工程團隊主管），或是在帶一群很能幹的實習生，主要負責定方向和把關。
• 272:33 bot 大致知道彼此之間要 handshake 什麼，缺的是組織層面的知識：現在發生什麼事、要遵守哪些流程、什麼算好、什麼算不好
  ↳ bot 本身大概懂怎麼互相協調，缺的是「組織常識」：現在發生什麼事、要照哪些規矩、怎樣算做得好。playbook 補的就是這一塊。
• 272:33 Jenny 已通知所有工程師 bot，也回報 Craig playbook 已更新；「P0 urgent」現在成為常設的作業流程（standing operations）
  ↳ Jenny 已經通知所有工程師 bot，也回報 Craig 手冊改好了。「P0 urgent」從此成為 standing operations（常設作業流程），不用每次重新說明。
• 273:04 講者現在不太看 cloud agents 的過程，只看結果和證明（proof）；PR 沒附證明就得再 nudge 一次，所以想一次設定好，讓之後都自動附上
  ↳ 講者現在不太看 agent 做事的過程，只看結果和證明。PR 沒附證明就得再催一次，所以乾脆一次寫進規則，以後都自動附上。
• 273:36 講者對 Craig（相當於講者現在的 head of engineering）提出 playbook 新規定：每個 PR 都要附證明，UI 改動附截圖，效能改善附 Perf metrics
  ↳ 講者跟 Craig（現在等於工程主管）追加一條規定：每個 PR 都要附證據，改畫面就附截圖，改效能就附 Perf metrics（速度、耗時等效能數據）。
• 274:09 Steve 已經有成果：做了一些 cleanup，PR 也準備好了，可以直接點進去開始 review；另一個任務還在執行中
  ↳ Steve 那邊有成果了：做了一些 cleanup（整理、清掉多餘的程式碼），PR 已經準備好，點進去就能開始 review（審查）。另一個任務還在跑。
• 274:09 講者說 Grok Bot 最好的地方是：就算你在跟它們聊天，它們也能繼續做事（字幕在此中斷）
  ↳ 講者覺得最棒的是：你跟這些 bot 聊天的時候，它們手上的工作不會停，聊天和做事可以同時進行。（字幕在這裡中斷）

講者定義的 P0 流程裡，Grok Bot 要多久檢查一次 cloud agents 的進度？