Grok Bot Galaxy 第三天（第 10/40 段）

🧑‍🏫 這段是 Grok 團隊一邊直播、一邊讓自己做的小遊戲正式上線的過程。最值得看的是兩件事：他們怎麼把 bot 當成數據分析師，隨時產出上線報告；還有產品經理說明新產品剛上線時該盯哪些數字。中間也穿插了一段工程問題，講的是怎麼避免前後端的資料格式對不上。

• 106:50 團隊一邊修 logo，一邊讓 bot 建 dashboard，用來追蹤這次上線的狀況
  ↳ 團隊一邊修網站 logo，一邊叫 bot（會自動幫你做事的 AI 助手）建 dashboard。dashboard 就是把各種數字集中成圖表的儀表板，讓人一眼看出上線狀況。
• 106:50 排行榜上 Roshan 暫居第一，他說自己過去 24 小時一直是第二名
  ↳ 遊戲裡有排行榜，Roshan 暫時排第一。他說過去一整天都卡在第二名，這次終於衝上去，現場就像大家一起在比賽。
• 107:22 講者（Roshan）說 xAI 內部每次上線都會用 bot 跑例行工作：讓 bot 扮演掌握所有數據脈絡的 data scientist，產生「launch pulse」
  ↳ Roshan 說 xAI 每次上線，都會讓 bot 扮演 data scientist（專門分析數據的人），因為它掌握所有數據脈絡。bot 會產出「launch pulse」，也就是上線狀況的定期健康檢查。
• 107:22 這次請 bot 做 15 分鐘一次的 pulse，每 15 分鐘送來一批 dashboard，看上線進度
  ↳ 這次設定每 15 分鐘做一次 pulse。bot 會自動送來一批新圖表，團隊不用自己去撈數字，就像每 15 分鐘收到一份最新戰報。
• 107:52 要追的指標：新註冊數、練習局數，以及從練習帳號轉成正式帳號的轉換漏斗（conversion funnel）
  ↳ 要盯三件事：多少人新註冊、玩了幾場練習、多少練習玩家轉成正式帳號。conversion funnel（轉換漏斗）就是追蹤人一步步往下走，看是在哪一步掉的。
• 108:25 Lauren 掉到第三名；Ben Jay Bush 1046 分，Roshan 1047 分，差距只有 1 分
  ↳ 排名很膠著：Lauren 掉到第三，Ben Jay Bush 1046 分、Roshan 1047 分，只差 1 分，第一名隨時可能換人。
• 108:25 有人提議把排行榜改成大約每分鐘更新一次；目前是手動重新整理
  ↳ 排行榜現在要手動重新整理才會更新。有人提議改成大約每分鐘自動更新，讓大家看到的名次更即時。
• 108:25 X 上的追蹤者已達 225 人
  ↳ 遊戲在 X（以前叫 Twitter 的社群平台）上的帳號已經有 225 位追蹤者，算是上線初期看人氣的一個指標。
• 109:01 想顯示同時在線的使用者數；講者很訝異 app 到現在還沒掛掉
  ↳ 他們想在畫面上顯示「現在有多少人同時在玩」。講者也老實說，他很意外 app 到現在都還沒被人潮擠垮。
• 109:01 Ben Jay Bush 登上第一名；團隊提到之後可能會給排行榜上的玩家獎品
  ↳ Ben Jay Bush 衝上第一名。團隊順口提到之後可能會發獎品給排行榜上的玩家，但這只是想法，還不是確定的活動。
• 109:35 前一晚 PR 都是自動 merge，講者完全沒看程式碼，只用 potato mode 和 p-stack，叫 bot 把效能做好，撐得住 X 上的大量玩家
  ↳ PR 是改好程式後申請併進主程式的請求，merge 就是合併。前一晚的 PR 都自動合併，講者沒看程式碼，只靠 potato mode 和 p-stack（影片沒解釋）叫 bot 把效能顧好。
• 110:07 展示 commit 紀錄：因為沒要求 bot 認真寫 commit 標題，所以標題很隨便；Roshan 最後一小時送了很多 commit
  ↳ commit 是每次改程式留下的一筆紀錄，會附一行標題說明改了什麼。因為沒要求 bot 認真寫，標題都很隨便；Roshan 光最後一小時就送了一大堆。
• 110:07 做過的修正包括修 migrations，還有修一個 bug
  ↳ 修過的東西包括 migrations 和一個 bug（程式錯誤）。影片沒多解釋 migrations，一般是指調整資料庫結構的步驟。
• 110:46 講者說一開始做得很隨便（scrappy），完全沒看程式碼；等到要做成真正的遊戲，就得開始考慮怎麼維護，例如型別安全
  ↳ 一開始走 scrappy 路線，也就是先求能動、衝了再說，程式碼完全沒看。但要做成能長期經營的遊戲，就得開始顧好不好維護，例如 type safety（型別安全）。
• 110:46 使用者數已接近 500 人
  ↳ 使用者已經快 500 人，人數還在往上爬。
• 111:21 技術架構：後端用 Go，是跑在 Vercel Functions 上的 serverless 後端，資料庫用 PlanetScale
  ↳ 後端是使用者看不到、負責存資料和處理邏輯的那一端，用 Go 語言寫，跑在 Vercel Functions 上。serverless 是指不用自己管伺服器，交給平台代管。資料庫用 PlanetScale。
• 111:21 講者認為 app 撐得住，部分原因是用了這些服務（「站在偉大工程師的肩膀上」）
  ↳ 講者覺得 app 撐得住，有一部分要歸功這些現成服務：流量和機器的麻煩事不用從零自己處理，等於「站在偉大工程師的肩膀上」。
• 111:56 前後端之間用 REST 協定溝通；要解決的問題是怎麼讓後端和前端（client）保持同步
  ↳ 前端（使用者看到的畫面，也叫 client）和後端要一直互傳資料，用的溝通規則叫 REST。難題在於兩邊各自改動時，怎麼確保雙方講的還是同一套格式。
• 111:56 舉例說明型別安全：後端有 bot 型別，欄位包括 display name、avatar、stats；多人一起改 code 時，要避免前後端改動互相衝突
  ↳ 型別安全就是事先講好資料長什麼樣子。例如後端的 bot 資料有顯示名稱、頭像、數據三個欄位；很多人一起改的時候，要防止一邊改了格式，另一邊卻不知道。
• 112:37 衝突的例子：Roshan 重新設計卡片，講者卻刪掉一個欄位，UI 要讀的資料就讀不到了
  ↳ 實際例子：Roshan 正在重新設計卡片畫面，講者卻把某個欄位刪掉了。畫面要讀的資料不見，就會出錯或變成空白。
• 112:37 目前的做法比較基本：前端收到後端回應後，先用 Zod 解析；講者說時間多一點的話可能會換個設計
  ↳ 目前做法很陽春：前端收到後端的資料後，先用 Zod 檢查一遍再用。講者說如果時間多一點，可能會換成更完整的設計。
• 113:13 Zod 是 JavaScript 函式庫，用來解析、處理回應，確保資料都經過驗證而且正確
  ↳ Zod 是 JavaScript（網頁最常用的程式語言）的工具套件，作用像收貨前先驗貨：格式不對就擋下來，確保畫面拿到的資料都是正確的。
• 113:13 畫面上已放了 thursdayruna.com 的 QR code
  ↳ 畫面上放了 thursdayruna.com 的 QR code，觀眾用手機一掃就能連到這個網站。
• 113:44 Roshan 展示 Grokbot 上設定的幾個 bot，其中「founding engineer」bot 還在持續處理進來的 PR
  ↳ Roshan 展示他在 Grokbot 上設好的幾個 bot，各有分工。其中叫「founding engineer」（創始工程師）的那個，還在持續處理新送進來的 PR。
• 113:44 Roshan 在新產品上線時用 Grokbot 產生指標和報告，不用登入 dashboard 網站、點來點去，就能隨時拿到數據
  ↳ Roshan 的習慣是：新產品上線時直接跟 Grokbot 要數據和報告，不用登入 dashboard 網站一頁一頁點，想知道什麼隨時問就有。
• 114:17 用 bot 還有一個好處：當下需要哪種數據切面就直接拿，不必重做 dashboard
  ↳ 另一個好處是有彈性：臨時想換個角度看數據，直接叫 bot 整理那個角度就好，不必重新設計整個 dashboard。
• 114:17 數據（約兩分鐘前）：練習場次超過 600 場；有 38 場練習轉成 sign in with X；共 400 人用 X 登入
  ↳ 大約兩分鐘前的數字：練習超過 600 場，其中 38 場玩完後轉成用 X 帳號登入；用 X 登入的總共有 400 人。
• 114:17 流量曲線呈現 hockey stick（曲棍球桿）型的暴增
  ↳ 流量圖長得像曲棍球桿（hockey stick）：前面一段平平的，然後突然往上急衝，代表人潮一下子湧進來。
• 114:50 漏斗快照能看出使用者在哪一步流失；遊戲和 SaaS 產品很重視留存和回訪，要營利的話，營利合作夥伴也會在意這些指標
  ↳ 從漏斗快照能看出人是在哪一步走掉的。遊戲和 SaaS（線上訂閱制軟體）都很重視 retention（留存，也就是人會不會回來）；要賺錢時，合作夥伴也會看這些數字。
• 114:50 依階段統計用 X 登入的場次（shop、result、battle），因為產品各處都有 sign in with X 按鈕，可以看出在哪裡抓到登入
  ↳ 遊戲裡的商店、結算、對戰頁面都有「用 X 登入」按鈕。分開統計，就能知道哪個位置最能讓人願意登入。
• 115:22 有人問 PM（產品經理）：規劃成長、回應使用者回饋、排優先順序時，最常看哪些數據？
  ↳ 有人問 PM（產品經理，負責決定產品要做什麼、先做什麼的人）：規劃成長、回應使用者回饋、排優先順序時，最常看哪些數據？
• 115:52 回答：要看的指標取決於產品類型。他們是剛上線的 zero to one 產品，app 裡還沒有營利
  ↳ PM 回答：要看哪些指標，得看是什麼產品。他們是 zero to one（從無到有、剛誕生）的產品，app 裡還沒有任何賺錢的機制。
• 115:52 zero to one 階段要跑「經典灣區成長機器」：盡量把人帶進產品、讓他們喜歡；最在乎的是有沒有人玩、玩得開不開心，透過回饋和漏斗來判斷
  ↳ 這個階段就是跑矽谷常見的成長打法：先把人拉進來，讓他們喜歡。最在意的是有沒有人玩、玩得開不開心，靠使用者回饋和漏斗來判斷。
• 116:24 漏斗能看出玩家是一路玩到終局、再開下一局，還是一開始就流失、不再回來
  ↳ 漏斗能分出兩種玩家：一種一路玩到結束、還想再開一局；另一種一開始就離開，之後再也沒回來。後者多，就代表某個環節有問題。
• 116:24 規模化、有營收的產品，營收就是重要指標；週一的來賓（協助小型企業成長）也一再強調營收是企業最在乎的
  ↳ 產品做大、開始有營收後，營收就成了關鍵指標。週一節目的來賓（專門協助小型企業成長）也一再強調，企業最在乎的就是營收。
• 116:55 公司要賺錢，產品才能繼續成長、養工程師；但他們還沒有營收（pre-revenue），所以先專注在參與度、留存等產品指標
  ↳ 公司要有收入，產品才能繼續成長、養得起工程師。但他們現在還是 pre-revenue（還沒有營收），所以先專注在參與度、留存這類產品指標。
• 117:26 可能接受很多人只練習不登入，但可以給登入使用者更好的體驗，例如更有競爭性的排行榜、更多功能或各種福利
  ↳ 他們可能接受很多人只玩練習、不登入。不過會讓登入的人有更好的體驗，例如更有競爭感的排行榜、更多功能或各種福利。
• 117:26 因為做的是遊戲，遊戲機制很重要；團隊愛玩遊戲但沒做過多少遊戲，這次學到很多
  ↳ 因為做的是遊戲，好不好玩取決於遊戲機制（規則怎麼設計）。團隊很愛玩遊戲，但沒做過幾款，這次邊做邊學到很多。
• 118:02 指標也能看遊戲運作狀況；遊戲設計重點：夠不夠多樣、耐不耐玩（replayability）、平衡好不好（不會每次都輸或都贏）、有沒有真正的競爭
  ↳ 數據也能拿來檢查遊戲設計：玩法夠不夠多樣、replayability（會不會想一玩再玩）、平衡好不好（不會老是輸或老是贏）、有沒有真正的競爭。
• 118:02 講者請 bot 撈出勝負範例，看對局的情況
  ↳ 講者請 bot 撈出幾場實際的輸贏對局，直接看每場是怎麼打的，不只看總數。
• 118:32 目前結果偏向輸，敗率 41.8%
  ↳ 目前結果偏向輸，敗率 41.8%。這類數字就是用來檢查上一點講的平衡好不好。

講者說他們用什麼方法，確保前端收到的後端回應型別正確？