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

🧑‍🏫 這段是 Grok 團隊直播做一款 bot 卡牌對戰遊戲的第三天。內容從上線前的安全準備開始，接著講他們怎麼讓 bot 自動抓 bug、修 bug，最後現場第一次試玩。值得看的是，它讓你看到 AI 平常怎麼幫忙維護一個真的產品，不只是寫程式那一段。

• 83:06 要上 production，得先強化 app：資料庫控管、ingress/egress 控管、收緊安全性，還有 Clerk 驗證和 DNS 設定。這些都還在進行中
  ↳ production（真正上線給人用的環境）上線前要先補強：資料庫權限、資料進出管制（ingress/egress）、安全性，還有登入服務 Clerk 和網址設定 DNS。這些都還在做。
• 83:06 網域名稱已經有了，但要等產品上線才會公布名稱
  ↳ 網址已經買好了，但遊戲名稱要等正式上線才公布，現在先保密。
• 83:06 資料庫供應商是 PlanetScale，已經設好一系列資料庫來處理核心遊戲資料
  ↳ PlanetScale 是一家提供雲端資料庫的公司。團隊用它開了好幾個資料庫，專門存遊戲最核心的資料。
• 83:41 昨晚對資料庫跑了一批負載測試，今天早上在做 production hardening
  ↳ load test（負載測試）是故意送進大量請求，看資料庫撐不撐得住。昨晚先測完，今天早上接著做 production hardening，也就是第 1 點那些上線前的補強。
• 83:41 公司有一整套營運工具：Slack team 裡有 bug reports channel，直播時就看到 bug 回報陸續進來
  ↳ 除了寫程式，公司還有一套日常營運工具。例如在 Slack（公司聊天軟體）開一個專收 bug（程式錯誤）回報的頻道，直播當下就有回報一直進來。
• 84:12 bot 能像人一樣使用其他工具，而且通常比人快很多
  ↳ 這裡的 bot 是指能自己動手做事的 AI 程式。它可以像人一樣去操作別的軟體、查資料，而且通常比人快很多。
• 84:12 xAI 內部常見的流程：產品有 feedback 和 issues channel，有人貼 issue 時，由 triage bots 檢查能否重現，並去翻內部 log
  ↳ xAI 內部的每個產品都有回報問題的頻道。有人貼問題後，triage bot（分流機器人）會先試著照步驟重現問題，再去翻 log（系統自動留下的運作紀錄）找線索。
• 84:45 triage bot 會判斷這個問題需不需要修、該不該 tag 能幫忙的人
  ↳ triage 原本是急診的「檢傷分類」。bot 也在做一樣的事：判斷這個問題值不值得修，要不要 tag（標記通知）最能處理的人來接手。
• 84:45 好處是縮短從回報到修好的時間，也常省下工程師手動翻大量 log 的工作
  ↳ 好處是從有人回報到修好的時間縮短很多，工程師也不用自己在一大堆 log 裡大海撈針。
• 85:15 這個 app 想做到同樣的事：一有 issue 就自動派 bot 查證、看 log，最後直接交出 PR，而不只是給一份調查報告或 dashboard
  ↳ 這款遊戲也想做到：一有問題就自動派 bot 查證、看 log，最後直接交出 PR（改好的程式碼，等人審核後併入），而不只是交一份報告或 dashboard（數據看板）。
• 85:15 這就是 software factory 的實際樣貌：一個自動化的軟體開發循環，對已上線的 production app 特別重要，因為沒有軟體是完美的
  ↳ software factory（軟體工廠）是指回報、分流、修復像產線一樣自動運轉。已上線的產品特別需要這個，因為沒有軟體是完美的，問題一定會一直冒出來。
• 85:48 工程團隊很大一部分的工作是看進來的 issue、做 triage、修掉，同時持續改進產品
  ↳ 工程師的日常不只是寫新功能，有很大一塊是處理進來的問題：分輕重、修好，同時繼續把產品做得更好。這正是 bot 能分擔的部分。
• 85:48 團隊正在做 UI rewrite，也剛重做了 authentication
  ↳ 團隊正在重做 UI（使用者看得到、點得到的畫面），也剛重做了 authentication（確認「你是誰」的登入驗證機制）。
• 86:19 authentication 從 development 切到 production 時，有一堆 OAuth 和 callback 設定要重新調整
  ↳ 從 development（開發測試用的環境）切到正式環境時，OAuth（讓你用 Google 等帳號登入的授權機制）和 callback（登入完要跳回的網址）都得重新設定。
• 86:19 心得：做軟體很大一部分是把各種東西接起來，搞清楚 production 和 development 環境的差別，也就是找出中間的「glue」
  ↳ 講者的心得：做軟體很多時間不是在寫新東西，而是把各種服務接起來，搞懂正式環境和開發環境哪裡不一樣。這些負責串接的部分就叫 glue（膠水）。
• 86:19 agent 很擅長做這種事；以前得手動診斷，非常花時間
  ↳ 找出「哪裡沒接好」這種問題，正是 agent（能自己規劃步驟、動手執行的 AI 助手）擅長的。以前得靠人一個一個手動查，非常花時間。
• 86:50 軟體工程和經營事業的技能都還適用。debug 的方法是理解流程每一步，逐一檢查直到找出出錯的點
  ↳ 會用 AI 不代表舊本事就沒用了。debug（找錯、修錯）的方法沒變：先搞懂流程的每一步，再一步步檢查，直到找到壞掉的那一環。經營事業也一樣。
• 86:50 現在可以靠 agent 幫忙，但原則不變：A 點到 B 點之間有 X 個可能出錯的地方
  ↳ 現在可以請 agent 幫忙查，但思考方式沒變：從 A 到 B 之間有幾個可能出錯的點，一個一個排除。工具換了，邏輯沒換。
• 87:24 修檯燈的比喻：先確認燈泡有沒有燒掉、插頭有沒有插上；兩個都正常，問題就在中間。軟體也是一樣
  ↳ 檯燈不亮，先看燈泡有沒有燒掉、插頭有沒有插好。兩個都沒問題，就是中間出了事。軟體也是先確認兩端，再慢慢縮小範圍。
• 88:01 因為有很多 API keys 之類的東西，才會講到這些；經營事業也是同樣道理
  ↳ 會講到這些，是因為這個專案要設定很多 API key（讓程式能使用別家服務的通行密碼），哪一個沒設好都會出錯。經營事業也是這樣：環環相扣，要一段一段查。
• 88:01 Clerk app 已經在 production 上跑起來，dashboard 顯示 1 位 active user（特別要求不要秀在畫面上），dashboard 可能有延遲
  ↳ Clerk 已經在正式環境跑起來了，後台 dashboard 顯示有 1 位 active user（目前活躍的使用者）。講者特別交代不要把這個畫面秀出來，數字也可能有延遲。
• 88:39 從 dev 切到 prod 後，prod instance 有了 active users，後來看到 3 位
  ↳ 從 dev（開發）切到 prod（正式）後，正式版的 instance（一套獨立運作的服務）開始有人登入，後來看到 3 位活躍使用者。
• 88:39 目前已經有使用者驗證和遊戲引擎，接著討論 launch checklist，決定現場開一份 Notion doc 來列
  ↳ 登入驗證和遊戲引擎（負責跑遊戲規則的核心程式）都有了。接下來談 launch checklist（上線前確認清單），決定當場在 Notion（筆記兼資料庫工具）開文件來列。
• 89:17 昨天建了一個任務板給 agents 用，agents 一直把資料記進 Notion database，內容有點亂、需要整理
  ↳ 昨天幫 agent 建了一個任務板，agent 會自己把資料寫進 Notion 的資料庫。問題是寫得有點亂，需要整理。AI 會記，但不一定記得整齊。
• 89:55 Notion 裡還有 working to-do list，以及公司 context，例如 canonical database schema 和遊戲機制的 source of truth
  ↳ Notion 還放了待辦清單和公司背景資料，像 canonical database schema（標準版的資料欄位設計），以及遊戲規則的 source of truth（以它為準的正式版本）。
• 89:55 這些文件讓 bot 能和其他 bot 互動，也能取用公司 context
  ↳ 把這些寫成文件後，bot 之間可以靠它互相配合，也能隨時查公司的背景資料，不用每次重新交代一遍。
• 89:55 Lauren 週二開場時提到：對 coding agent 來說，code base 通常就是最好的 context 和 memory
  ↳ Lauren 週二開場時說過：對 coding agent（專門寫程式的 AI）來說，最好的背景資料和記憶通常就是 code base（專案的全部程式碼）本身。
• 90:28 但營運相關的事情，寫文件會很有幫助
  ↳ 但營運的事情光看程式碼看不出來，這時候寫成文件給 AI 參考就很有幫助。
• 90:28 現場建 launch checklist：authentication 已經可以用，打勾完成
  ↳ 現場開始列上線清單。第一項 authentication 已經可以用了，直接打勾。
• 90:28 討論要不要等 UI rewrite 完成再上線，看法是不一定需要
  ↳ 接著討論要不要等畫面重做完才上線。他們的看法是不一定要等，不必做到完美才讓人玩。
• 91:01 可以先設好期待：這是第一次 play test，UI 還不精緻，而且很可能會壞掉
  ↳ 重點是先講清楚：這是第一次 play test（找真人試玩、抓問題），畫面還很陽春，而且很可能會壞。先打好預防針。
• 91:32 作法：先隱藏 URL、關掉螢幕分享自己試玩，覺得可以就把 URL 分享到聊天室，進行第一次 play test
  ↳ 作法很謹慎：先把網址藏起來、關掉螢幕分享，自己玩一輪。覺得可以了，再把網址貼到直播聊天室，開始第一次試玩。
• 92:07 還得先完成改名；畫面放大可能造成排版問題，所以先用預設檢視
  ↳ 還得先把名字改好。畫面放大可能會讓版面跑掉，所以先用預設大小來看。
• 92:39 遊戲新增了 practice mode；團隊認為還需要加一個 tutorial
  ↳ 遊戲加了 practice mode（練習模式），但團隊覺得還不夠，應該再加一個 tutorial（新手教學），帶新玩家搞懂怎麼玩。
• 92:39 遊戲是 auto-battler 風格，卡牌預先載入，由 Grokbot templates 生成；牌組的能力取自 Grokbot marketplace
  ↳ 這是 auto-battler（自走棋類遊戲，排好陣容後自動開打）。卡牌事先載入，由 Grokbot 範本生成，能力取自 Grokbot marketplace（bot 市集）。
• 93:12 卡牌例子有 office ops desk、writing bot、dial bot
  ↳ 卡牌例子有 office ops desk、writing bot、dial bot，名字都是一個個不同用途的 bot。
• 93:12 每張卡有兩個關鍵數值：attack 和 health（HP），另外各有一個專屬 minted 的能力，會改變玩法
  ↳ 每張卡有兩個關鍵數字：attack（攻擊力）和 health（HP，生命值）。另外每張卡還有一個 minted（專門為它生成）的能力，會改變玩法。
• 93:12 玩法：一局共三回合，每回合排好自己的 bot 陣容，和另一位也排好陣容的玩家對戰
  ↳ 一局共三回合。每回合先排好自己的 bot 陣容，再跟另一位也排好陣容的玩家對戰。
• 93:44 每回合有一筆金幣可以花；示範第一回合買了三個 bot。因為字太小，改用 pinch zoom 放大
  ↳ 每回合有一筆金幣可以花，示範時第一回合買了三個 bot。因為畫面上的字太小，改用 pinch zoom（兩指撐開放大）來看。
• 93:44 office ops desk 排在陣容第一位，能力叫 hold the line
  ↳ office ops desk 排在陣容第一位，也就是最前面，它的能力叫 hold the line（守住防線）。
• 94:16 hold the line：從隊伍前方受傷時回復 1 HP，當成一個小坦克
  ↳ hold the line 的效果是：從隊伍前方受傷時回 1 點 HP。所以它適合放在前排當小坦克（負責擋傷害的角色）。
• 94:16 基本卡每張 3 金，起始有 10 金，買一張後剩 7 金
  ↳ 基本卡一張 3 金幣，開局有 10 金幣，買一張剩 7 金。買三張就花掉 9 金，只剩 1 金。
• 94:16 直播中發現 bug：卡名突然變成 unknown bot，需要修
  ↳ 直播中就抓到一個 bug：卡名突然變成「unknown bot」（未知的 bot），得修。剛好應驗前面說的，上線後問題會一直冒出來。

示範時，玩家起始有多少金幣？基本卡一張多少金幣？