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

🧑‍🏫 這段是 Grok Bot 直播第一天的中場。前半段回顧團隊三天要做的「舊金山餐廳快閃店」專案，還有工程師怎麼讓一群 AI bot 分工寫程式、互相審查。後半段是給工程師的工作坊，講者從頭講 AI 寫程式工具怎麼一路演進，從「幫你補字」走到「自己在雲端 24 小時做事」，再到「讓 AI 管 AI」。想知道 AI 工作流程往哪走的人，看這段很快能抓到全貌。

• 228:43 直播回來先做回顧；距離下一場「Grok Bot for engineering」大約還有五分鐘
  ↳ 直播休息完回來，先整理早上做了哪些事。再過大約五分鐘，就是下一場「Grok Bot for engineering」，專門給工程師看 Grok Bot 怎麼用。
• 228:43 早上在 Twitter 上做市場研究，收集觀眾提出的餐廳點子，並對要做什麼達成共識
  ↳ 早上團隊直接在 Twitter 上問觀眾想要什麼餐廳點子，等於拿社群當免費的市場調查。收完意見後，團隊對要做什麼有了共識。
• 229:13 和 Peter Yang、Cody 聊過，進一步了解 go to market 和要做的東西
  ↳ 團隊也找 Peter Yang、Cody 聊 go to market，意思是東西做出來後，要怎麼推到使用者面前、讓人願意用。影片沒講聊了哪些細節。
• 229:13 接下來重點是動手做，engineering 場次結束後會展示 Lauren 和 Potato 的實作
  ↳ 討論夠了，接下來要真的動手做。工程場次結束後，會讓大家看 Lauren 和 Potato 實際做出來的東西。
• 229:13 確定的點子：在 San Francisco 辦一場餐廳 pop-up（快閃）體驗
  ↳ 點子定案了：在舊金山辦一場餐廳 pop-up。pop-up 就是只開短短幾天的快閃店，跟百貨公司的限時快閃櫃是同一種概念。
• 229:44 目標是把餐廳和想吃東西、想要體驗的人連結起來，並在打造體驗的過程中產出軟體
  ↳ 目的不只是辦一場活動。一方面把餐廳和想來吃、想來體驗的人湊在一起，一方面把辦活動過程中需要的工具寫成軟體。
• 229:44 三天後的理想成果有兩個：一是用來打造這類體驗的作業系統／產品，二是體驗本身
  ↳ 三天後要交出兩樣東西：一套以後能重複拿來辦這類活動的系統（影片稱為作業系統／產品），以及這場快閃體驗本身。
• 229:44 想讓訂位體驗不只是傳統訂位，比較瘋狂的點子留到第二天再談
  ↳ 訂位不想只是「選時間、填人數」那種老流程，想加點新花樣。更大膽的點子留到第二天再講。
• 230:15 Lauren 在建立自己的「potato factory」：新增 reviewer bot「Hash Brown」，負責審查 Tater 開的 PR
  ↳ Lauren 在搭一座 bot 分工的「馬鈴薯工廠」。新加的 Hash Brown 是 reviewer bot（負責審查的 bot），專門檢查 Tater 開的 PR，也就是「我改了這些程式，請審核後併進去」的申請。
• 230:47 Tater 是 Lauren 的 engineering bot，Hash Brown 是 reviewer bot；也想幫 Roshan 和 Matt 建立類似設定
  ↳ Tater 負責寫程式，Hash Brown 負責挑毛病，一個寫一個審，跟人類團隊的分工一樣。Lauren 也想幫同事 Roshan 和 Matt 各配一組。
• 230:47 Lauren 正在把 Pstack 加進 repo
  ↳ Lauren 正把 Pstack 放進 repo。repo 是存放整個專案程式碼的倉庫。影片沒解釋 Pstack 是什麼，只知道主持人平常開發也用它。
• 230:47 Cursor plugin 可以裝在本機，也可以設成 repo plugin；bot 或 agent 能很輕鬆幫你設定好
  ↳ Cursor 是內建 AI 的寫程式軟體。它的 plugin（外掛）可以只裝在自己電腦，也能設在 repo 讓全專案共用。這些設定交給 agent（會自己動手做事的 AI）處理就好。
• 231:18 同時讓 bot 設定 Cursor automation，可以把它想成一種「對事件做出反應」的機制
  ↳ 同時請 bot 設好 Cursor automation：事先定好「發生某件事，就自動做某件事」。例如設定成一有新 PR 出現，就自動開始檢查。
• 231:18 想要的流程：開 PR → 自動貼到 Slack 頻道 → automation 接手審查，甚至可能幫忙 merge
  ↳ 想要的流程是：bot 一開 PR，就自動貼到 Slack（工作用的聊天軟體）頻道，automation 接著審查，甚至直接 merge，也就是把修改正式併進主程式。
• 231:48 理想狀態：各自的 bot 把 PR 丟進 Slack 頻道，reviewer bot 去審，審過就 merge
  ↳ 理想中人幾乎不用插手。每個人的 bot 把 PR 丟進同一個頻道，reviewer bot 負責審，審過就合併，像一條自動生產線。
• 231:48 也打算讓 codebase 變得很容易貢獻
  ↳ 也要把 codebase（專案的全部程式碼）整理好，讓別人或別的 bot 都能輕鬆加入、送修改。
• 232:18 要搭的 scaffolding 很多，也包括給 agent 用的 skills
  ↳ 開工前要先搭很多 scaffolding，也就是撐起整個工作的基礎設定。其中包括給 agent 用的 skills：事先寫好的操作說明，讓 AI 知道某類工作該怎麼做。
• 232:18 不想 overcook：新創的目標是活到明天，先做基本、不花俏但之後能擴充的版本
  ↳ 不想 overcook（過度打磨）。新創最重要的是先活下去，所以先做簡單能用、以後能擴充的版本，不追求一開始就完美。
• 232:50 這套流程和 Lauren 在 SpaceX 用的 factory 很像，但這次要從頭來，也是重新思考原本做法的機會
  ↳ 這套 bot 工廠跟 Lauren 在 SpaceX 用的做法很像，但這次從零開始，正好趁機檢討原本的做法有哪裡可以改。
• 232:50 主持人會負責 lander，思考視覺設計
  ↳ 主持人負責 lander，也就是 landing page：使用者點進來第一眼看到的網頁。主持人也負責想畫面要長什麼樣子。
• 233:20 主持人平常用 Pstack 開發，流程是先用 Grok Bot 發想點子，再交給 Cursor Cloud agents 實際打造
  ↳ 主持人的習慣是先跟 Grok Bot 討論，把點子想清楚，再交給 Cursor Cloud agents（在雲端電腦上跑的 AI agent）真的做出來。想和做分開處理。
• 233:20 下一場是從 San Francisco 的 Dreamforce 現場連線的 Grok Bot for engineering，由團隊成員示範這些工作流程
  ↳ 下一場從舊金山的 Dreamforce 大會現場連線，由團隊成員實際示範剛才講的這些工作流程。
• 233:51 講者 Lingshi 是 SpaceX AI 的軟體工程師，這場工作坊主題是 Grok Bot for engineers
  ↳ 講者 Lingshi 是 SpaceX AI 的軟體工程師。這場工作坊要教工程師怎麼用 Grok Bot 做事。
• 234:22 講者加入 Cursor（現在是 SpaceX AI）後已推出兩個產品，之前做過 Cursor 3 的 agent window，現在在做 Grok Bot
  ↳ 講者加入 Cursor（現在改叫 SpaceX AI）後推出了兩個產品。之前做的是 Cursor 3 的 agent window，就是操作 AI agent 的視窗；現在在做 Grok Bot。
• 234:22 過去兩個月只用 Grok Bot 做工程工作，三週內獨自做出 Grok Bot mobile 的第一版
  ↳ 過去兩個月，講者的工程工作全靠 Grok Bot，還自己一個人花三週做出 Grok Bot 手機版的第一版。
• 234:22 因為 Grok Bot，學習速度變快，能參與 Grok Bot 的各種面向，也能從第一原理去嘗試以前沒試過的做法
  ↳ 有 Grok Bot 幫忙，學新東西變快，不熟的領域也能參與。還能從第一原理出發（回到問題最基本的事實重新想），試以前沒試過的做法。
• 234:54 這段工程演進大約從 2024 年初開始；在那之前只有以語法為基礎的 autocomplete
  ↳ 接著講 AI 寫程式工具的演進，大約從 2024 年初算起。在那之前只有 autocomplete：照程式語法幫你補完字詞，像手機輸入法的選字。
• 235:24 接著出現 tab completion，已經是一大進步
  ↳ 下一步是 tab completion：AI 猜出你接下來要寫的內容，按 Tab 鍵就能直接收下。比只補字詞方便很多。
• 235:24 再來是 ask 和 edit：第一次感受到 agent 的威力，能更快速瀏覽 codebase、處理重複性工作，但還做不了大量任務
  ↳ 再來是 ask 和 edit：可以問 AI 程式在做什麼，或請它改某一段。這時第一次感受到 agent 的威力，但它只適合小事，大量工作還交不出去。
• 235:54 然後是 agentic coding，Cursor 2 和 Cursor 3 的重點都在這裡
  ↳ 接著是 agentic coding：AI 不只回答問題，還會自己規劃、自己動手把寫程式的任務做完。Cursor 2 和 Cursor 3 主打的都是這個。
• 235:54 agentic coding 能操作電腦的滑鼠、鍵盤做 end-to-end 測試，也能用更長遠的角度思考下一步、做規劃
  ↳ 這種 AI 能自己操作滑鼠和鍵盤，把整個功能從頭到尾實際點一遍來測試（叫 end-to-end 測試），也會想到好幾步之後，先訂計畫再做。
• 236:26 /go、/loop 很好用，能讓 agent 把任務從頭做到尾，不用一直 nudge
  ↳ /go、/loop 是兩個指令。下了之後，agent 會自己一路做到完成，不用人在旁邊一直 nudge，也就是提醒它「繼續做」。
• 236:26 限制：當時還是要人去 nudge、寫 prompt，也要從某個介面啟動 agent
  ↳ 但當時還有瓶頸：要靠人寫 prompt（給 AI 的指示）、要人提醒，也得有人打開某個介面，agent 才會開工。
• 236:26 下一階段是跑在 Cursor cloud agent 上的 automations：agent 可以由觸發條件啟動，例如收到 Slack 訊息
  ↳ 下一步是 automations，跑在 Cursor cloud agent 上：先設好觸發條件，例如收到某則 Slack 訊息，agent 就會自己開工，不用人按開始。
• 236:58 agent 能自己啟動，你不在電腦前也能跑，甚至在你睡覺時 24/7 運作
  ↳ 所以人不在電腦前，甚至在睡覺，agent 也能 24 小時不停地做事。
• 236:58 另一個好處是不再受限於本機電腦能跑多少東西
  ↳ 工作都在雲端跑，不再受自己電腦的效能限制，不會因為同時開太多東西就跑不動。
• 237:28 Cursor cloud agents 的概念：在電腦上能做的事都能在雲端跑，可以一次給你 10 台以上的機器平行執行，agent 不會再搶同一個 port
  ↳ Cursor cloud agents 的概念是：你電腦上能做的事，雲端都能做，而且一次能給你十台以上的機器同時跑。agent 之間不會搶同一個 port（程式連線用的通道號碼）而互相卡住。
• 237:28 有了 Cursor cloud agents，Cursor 團隊幾乎每個人的效率都提升 10 倍甚至更多
  ↳ 講者說 Cursor 團隊用了 cloud agents 以後，幾乎每個人的效率都變成原本的 10 倍甚至更多。這是講者自己的觀察。
• 237:58 已經看到小團隊也能推出大產品；下一步的想法是讓 AI agent 幫忙寫 prompt、幫忙 orchestrate
  ↳ 已經看到小團隊做出大產品。下一步是連下指令都交給 AI：讓 agent 幫忙寫 prompt，還有 orchestrate，也就是指揮、調度其他 agent。
• 237:58 講者曾同時管理 15 個 Cursor cloud agents，已經很吃力，得在不同 cloud agent 之間 context switching
  ↳ 講者曾同時管 15 個 cloud agents，光是 context switching（在它們之間切換、記住各自做到哪）就很累，人反而成了瓶頸。
• 238:30 講者希望有另一個 agent 幫忙發起後續任務、把訊息排進佇列，以及 nudge 或中斷 cloud agent
  ↳ 所以講者想要一個「AI 主管」：幫忙派下一個任務、把要交代的事排進佇列，必要時提醒或叫停其他 cloud agent。

講者 Lingshi 提到自己曾經同時管理幾個 Cursor cloud agents，而且覺得已經很多？