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

🧑‍🏫 這段是 Grok 團隊的開發直播實況：他們一邊請 AI 機器人幫忙建立「自己測試 app」的能力，一邊改版網站首頁、接上候補名單，還討論了一個辦快閃活動的平台該有哪些功能。想知道專業團隊實際上怎麼分工給 AI、怎麼從零做出一個產品，很值得一看。

• 286:28 構想：把 X 上使用者回報的內容自動收進一個頻道，打造一條「工廠」流程，自動開 PR、分類並修正 bug
  ↳ 他們希望 X（前 Twitter）上的使用者抱怨能自動收進一個頻道，再交給 AI 自動分類（triage），修好程式後開 PR（送給團隊審核的修改申請）。整條流程像工廠流水線。
• 286:28 目前還沒有真正的 app 可以回報 bug，所以先架一個很基本的版本起步
  ↳ 但現在連一個讓人回報 bug（程式錯誤）的 app 都還沒有，所以先做個最陽春的版本，讓流程先跑起來，之後再慢慢補強。
• 287:00 講者認為 verification 是使用 bot 很重要的一環：讓 bot 能自己執行應用程式、抓 trace、做 heap snapshot、debug
  ↳ verification（驗證）skill 是一套讓 bot（會自己動手做事的 AI 機器人）自己驗收的能力：它能自己開 app、抓 trace（執行過程紀錄）、拍 heap snapshot（記憶體快照）來找問題。
• 287:32 沒有 verification skill，bot 會一直請人去執行 app、點點看、回報結果，來回溝通很慢；有了它，agent 就不必卡在人身上
  ↳ 沒有這套能力的話，AI 改完就要叫你去點點看再回報，來回很慢。有了它，agent（能自己連續執行任務的 AI）可以自己測，不用一直等人。
• 287:32 做法：請 Steve 用 Pstack 執行名為 create verification skill 的 skill，Steve 再把工作委派給 Tater bot
  ↳ 講者請 Steve 用 Pstack 這套工具執行「create verification skill」，也就是建立驗證能力的指令。Steve 再把這件事轉交給另一個叫 Tater 的 bot 去做。
• 289:36 這個 skill 會啟動一個 cloud agent 來幫忙建立 skill，來源是 Pstack plugin
  ↳ 這個 skill 來自 Pstack 的 plugin（外掛套件）。執行後會開一個 cloud agent（在雲端伺服器上跑的 AI），由它負責把驗證 skill 做出來。
• 290:08 講者的經驗是，verification skill 大致分兩部分，第一部分是 CLI、script 或工具，讓 bot/agent 可靠又確定地（deterministically）操作應用程式
  ↳ 驗證 skill 的第一部分是 CLI（打指令操作的工具）或 script（寫好的自動化小程式），讓 AI 每次都用同樣方式操作 app，結果穩定可預期，也就是 deterministically 的意思。
• 290:39 agent 雖然能當場寫 script，但很耗 token，而且每個 bot 各寫各的、無法重現，所以不如給它一套標準工具
  ↳ AI 其實可以臨時寫程式來測，但很耗 token（AI 處理文字的計量單位，用越多越貴），而且每個 bot 寫法都不同，結果沒辦法重現。給它一套固定工具，又省錢又一致。
• 290:39 create verification skill 會產生上述 CLI，另外也會產生一份 feature map
  ↳ 所以 create verification skill 跑完會產出兩樣東西：一是前面說的那套操作工具（CLI），二是一份 feature map。
• 291:09 feature map 是給 agent/bot 的地圖，讓它們了解 app 有哪些功能、怎麼進到那些功能、有哪些快捷鍵等；目前功能還不多，所以暫時不太重要
  ↳ feature map 是 app 的導覽地圖，告訴 AI 有哪些功能、要從哪裡點進去、有哪些快捷鍵。現在 app 功能還很少，所以這份地圖暫時沒那麼重要。
• 288:34 Lander（登陸頁）已經接好，也有一個正在做原型的網域，接下來要打磨設計
  ↳ lander 是 landing page，也就是訪客第一眼看到的介紹網頁。它已經接好，也有一個網域（網址）用來放原型（試作版），下一步是把設計做好看。
• 289:06 讓 bot 處理設計時會搭配一些 skill，例如「make interfaces feel better」；講者偏好極簡風格，打算先從極簡著手，再處理品牌
  ↳ 讓 bot 做設計時，會加掛專門的 skill，例如「make interfaces feel better」（讓介面用起來更舒服）。講者喜歡簡潔，所以先做極簡版，品牌風格之後再說。
• 289:06 分工：一人把原型改得更專業，Lauren 處理後端服務，之後再接上候補名單（waitlist）註冊
  ↳ 分工是這樣：一個人負責把原型網頁修得更專業，Lauren 負責後端（使用者看不到的伺服器和資料處理），之後再把候補名單的報名功能接上去。
• 291:40 候補名單只需要讓人送出 email 並記錄下來；可用的平台有 Loops 和 Resend，講者先選簡單、agent 也很擅長的 Resend
  ↳ waitlist（候補名單）只要能收 email、存起來就夠了。Loops 和 Resend 都是處理 email 的服務，講者先選比較簡單、AI 也用得很順手的 Resend。
• 292:11 他們發現已經有現成的相關 plugin 可以用
  ↳ 他們發現已經有現成的相關 plugin，直接裝來用就好，不必從零開始串接。
• 292:11 網域已經上線並完成連接
  ↳ 網域已經正式上線，也跟網站接好了，打網址就看得到。
• 292:42 表單已經接上資料庫，資料要到 planet scale 後台查看
  ↳ 表單送出的資料已經會存進資料庫。要查看資料，得登入 planet scale（一種雲端資料庫服務）的管理後台。
• 293:14 目前表單是 vibe coded 的臨時原型，蒐集的資訊不一定有用，請觀眾先別送出；之後要思考需要哪些資訊、目標受眾是誰
  ↳ vibe coded 是指跟 AI 聊一聊、憑感覺快速做出來的程式。這張表單就是這樣的臨時版，欄位不一定對，所以請觀眾先別填。之後要想清楚該收哪些資料、給誰用。
• 293:14 用 founding edge bot 口述需求：UI 改得更極簡，並以蒐集賓客（reservations）報名為主
  ↳ 講者對 founding edge bot 直接用講的提需求：UI（使用者看到的畫面）要改得更簡潔，重點放在收賓客報名。
• 293:45 規劃：想參加快閃（popup）的人用 email 註冊並記進資料庫；右上角放一個按鈕，給餐廳老闆等願意幫忙的人提出協助申請
  ↳ popup 就是快閃活動。規劃是：想參加的人留 email，資料就記進資料庫；右上角另外放一顆按鈕，讓願意幫忙的餐廳老闆等人提出協助申請。
• 294:15 之後要寄大量 email，並用 Grockbot 做市場調查，研究怎麼把活動辦成
  ↳ 之後會寄出大量 email，也會用 Grockbot 做市場調查，研究這種活動要怎麼辦才辦得起來。
• 294:15 講者把這段口述轉成文字（transcription）交給 engineering bot，讓它去改版網站
  ↳ 他把剛才口述的內容轉成文字（transcription，也就是逐字稿），丟給負責寫程式的 engineering bot，讓它照著改網站。
• 294:46 等 verification skill 跑完的同時，透過 cloud agent 做 admin 功能的原型
  ↳ 驗證 skill 還在跑的時候，他順便請 cloud agent 做 admin（管理員後台）的原型，讓好幾件事同時進行，不用乾等。
• 295:17 平台需要的功能：註冊頁、登入畫面；辦 popup 首先要有名稱、日期時間
  ↳ 平台最基本要有註冊頁和登入畫面。要辦一場 popup，至少得先有活動名稱和日期時間。
• 295:47 平台核心是「event」，event 底下有多張相關資料表，例如收集報名（邀請）、管理工具
  ↳ 整個平台的核心是 event（活動）。其他資料都掛在 event 底下，例如報名／邀請名單、管理工具，各自用一張資料表來存。
• 295:47 event 需要 staff 與權限，角色可分為 owners、hosts、attendees，也可以在整個平台設定固定的帳號類型來區分
  ↳ 每場 event 都需要 staff（工作人員）和權限設定。角色可以分成 owners（主辦方）、hosts（現場招待）、attendees（參加者），也可以在整個平台設定固定的帳號類型。
• 296:18 他們覺得需要白板來畫出要做的東西，提議用 teal draw 畫
  ↳ 要做的東西越來越多，光用講的容易講不清楚，所以他們想用白板畫出來，提議用 teal draw 這個線上白板工具。
• 296:50 請 bot 幫忙做功能原型並一起腦力激盪：使用者可自建 event，event 包含日期、時間、場地（venue）、報名、staff
  ↳ 他請 bot 一起腦力激盪、做功能原型：讓使用者能自己建立 event，裡面要有日期、時間、venue（場地）、報名和工作人員。
• 297:54 最後提到還需要整合許多其他東西（字幕在此中斷）
  ↳ 最後提到還有很多其他東西要整合進來，不過這段字幕到這裡就中斷了，後面的內容不在這一段。

講者認為，比起讓 agent 當場自己寫 script 做驗證，為什麼提供一套標準 CLI 工具比較好？