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

🧑‍🏫 這段是 Grok 團隊直播的其中一段，主角是 Grokbot 新推出的語音模式：用說的就能叫 AI 查進度、合併程式、派任務。後半段在聊他們平常怎麼大量用 AI 寫程式，也講到怎麼防止 AI 交出「看起來能動，其實只是貼 OK 繃」的東西。這些做法不寫程式的人也能參考。

• 403:33 累積圖表顯示遊戲數與頁面瀏覽量持續成長；mobile 與 web 流量大約各占一半
  ↳ 他們秀出累積圖表，遊戲場數和頁面被看的次數一路往上。用手機（mobile）來的人和用電腦瀏覽器（web）來的人，大約各占一半。
• 403:33 常見造訪頁面有登入、sponsor 頁、feedback 頁；多數流量來自 X 與 X 連結，也有一些直接造訪
  ↳ 最常被點開的是登入頁、贊助頁（sponsor）和意見回饋頁（feedback）。大部分人是在 X（原本的 Twitter）上點連結進來，也有人直接打網址進來。
• 403:33 有 8 個人是從 Bing 找到網站的
  ↳ 有 8 個人是在微軟的搜尋引擎 Bing 上搜到這個網站。人數很少，但表示已經開始有人靠搜尋找到它。
• 404:08 也有少數流量來自 Android app
  ↳ 另外有少數人是從 Android app 進來的，也就是從安卓手機上的應用程式點進網站。
• 404:08 當天宣布 Grokbot 推出 voice mode：Grokbot 有聲音了，可以直接和你對話
  ↳ 當天的重點新功能是 voice mode（語音模式）。Grokbot 現在能開口講話，也聽得懂你說的話，不用打字，直接用講的就能交代事情。
• 404:43 現場示範：用語音和名為 bake 的 bot（founding engineer）對話，詢問自己有哪些 PR 還開著、是否被卡住
  ↳ 講者用說的問一個叫 bake 的 bot（角色設定是創始工程師）：我還有哪些 PR 沒結案？有沒有卡住？PR（pull request）就是「我改了程式，請審核後併進去」的申請。
• 405:13 bot 回報：PR 269（re-roll softlock fix）CI 是綠燈、沒有阻礙；PR 220 還是 draft，而且有 merge conflicts
  ↳ bot 回報：PR 269 修的是重抽時卡死的問題，CI 綠燈，CI 是自動跑的檢查，綠燈代表全部通過。PR 220 還是 draft（草稿），而且有 merge conflicts，也就是跟別人改到同一段程式、互相打架。
• 405:13 用語音指示 bot 合併 PR 269，並派一個 agent 去解決 PR 220 的 merge conflicts，bot 答應稍後回報進度
  ↳ 講者用說的叫 bot 把 269 合併（merge），也就是把改動正式併進主程式。接著派一個 agent 去處理 220 的衝突，agent 是能自己接任務、動手做事的 AI。bot 答應晚點回報進度。
• 405:47 講者形容這種用法就像和隊友開 huddle 一樣
  ↳ huddle 是團隊聊天軟體 Slack 裡隨手開的語音小會議。講者的意思是：跟 bot 講話就像跟同事開個快會，交代完大家各自去做。
• 405:47 voice mode 當天才推出，接下來幾天會陸續開放到各帳號；講者感謝 xAI 團隊
  ↳ 語音功能當天才上線，接下來幾天會分批開放給各個帳號，所以你現在還看不到是正常的。講者也謝謝 xAI（開發 Grok 的公司）團隊。
• 405:47 團隊成員近況：一位持續修 UI 細節和 bug；bug 回報會記錄在 Slack，由他的「bot factory」負責重現、修正、合併
  ↳ 一位成員在修 UI（畫面上看得到、按得到的部分）的小細節和 bug（程式錯誤）。使用者回報的 bug 記在 Slack，由他的一群 bot 自己重現、修好、合併，像工廠生產線。
• 406:22 另一位在建置 ads marketplace，目前需要做 blob storage 的整合，正在處理 environment variable
  ↳ 另一位在做廣告交易平台（ads marketplace），要接上 blob storage，也就是存圖片、影片這類大檔案的雲端倉庫。他正在設定 environment variable，就是放金鑰、連線設定的參數。
• 406:53 新加入的 Eric 正在熟悉 code base，打算打磨對戰體驗，例如卡牌遊戲的動畫與閃光效果
  ↳ 新加入的 Eric 還在熟悉 code base（整個專案的程式碼）。他想讓對戰玩起來更有感，例如卡牌遊戲出牌時的動畫和閃光特效。
• 406:53 大家開玩笑提議「pay for clout」（付費登上排行榜頂端）和自動發文到 Twitter
  ↳ 大家開玩笑說可以讓人付錢買名氣（pay for clout），花錢直接登上排行榜第一；或讓系統自動幫你發文到 Twitter 炫耀。這是閒聊，不是正式計畫。
• 407:31 新增分享功能：對戰結束後可以分享勝場或敗場，產生 share card，貼到 X 或其他地方
  ↳ 新功能：對戰結束後，不管贏或輸，都能產生一張 share card（戰績小卡圖片），貼到 X 或其他社群分享。
• 407:31 示範時跳出 macOS 系統的分享視窗，因為會顯示最近聯絡人，所以沒有在直播畫面上展示
  ↳ 示範時跳出 Mac 電腦（macOS）內建的分享視窗，裡面會列出最近聯絡過的人。為了保護隱私，就沒有放在直播畫面上。
• 408:05 排行榜使用 elo 系統依表現給每位玩家評分；講者掉到第 51 名，目前有 5 位 diamond 玩家
  ↳ 排行榜用 elo 制度：贏了強的對手加分多，輸給弱的對手扣分多，西洋棋也用這套。講者掉到第 51 名，目前最高段的 diamond（鑽石）玩家有 5 位。
• 408:05 前三名有些人已經玩了將近 40 場以上，勝負比很高
  ↳ 排名前三的玩家，有的已經打了將近 40 場以上，而且贏多輸少，是真的常玩又很會打。
• 408:41 目前還沒有替排行榜產生 OJ image（分享連結用的預覽圖）；有人提議在右側顯示前三名與名字，也有人提到 top 10 的做法
  ↳ OJ image 是在 X 或 LINE 貼連結時自動跑出來的預覽圖（一般多叫 OG image）。排行榜目前還沒有這張圖，有人提議在右邊放前三名和名字，也有人提到放前十名的做法。
• 409:13 他們的 OJ image 服務用 Takumi：和 Satori 類似但用 Rust 寫，能把 JSX 轉成圖片
  ↳ 他們用 Takumi 產生預覽圖。它和另一個工具 Satori 很像，但是用 Rust（一種執行速度快的程式語言）寫的，能把 JSX（寫網頁畫面的語法）直接轉成一張圖片。
• 409:50 講者也推薦開源專案 FumaDocs；他幾乎每個專案都用 Takumi 產生動態 OJ image
  ↳ 講者推薦開源專案 FumaDocs，開源就是程式碼公開、大家都能免費使用。他幾乎每個專案都用 Takumi 做「動態」預覽圖，圖的內容會跟著頁面自動變。
• 409:50 有成員做了一個叫 Grind 的 bot，會幫他登入 ThursdayArena 自動玩遊戲、衝排行榜
  ↳ 有成員自己做了一個叫 Grind 的 bot，會幫他登入 ThursdayArena 自動玩遊戲、衝排名，等於請 AI 幫忙代打。
• 410:25 有人提議讓遊戲相容 Grokbot，讓 bot 之間可以互相對戰，並提到可以用類似 MCP 的方式
  ↳ 有人提議讓遊戲支援 Grokbot，讓 bot 和 bot 互相對戰，可以用類似 MCP 的方式。MCP 是讓 AI 連接外部工具和服務的一套共通規格，像萬用插頭。
• 411:01 團隊說自己不做專案管理，直接 ship 到 production；新創就是混亂中快速前進
  ↳ 團隊說自己不做專案管理，寫好就直接 ship（推出上線）到 production，也就是真實使用者在用的正式環境。新創的節奏就是在混亂中快速往前衝。
• 411:01 他們叫 bot 建了一個 to-do list tracker，結果變成很長的清單，裡面大多是 AI 的筆記
  ↳ 他們叫 bot 做一個待辦清單追蹤工具（to-do list tracker），結果清單越拉越長，而且大多是 AI 自己寫的筆記，不是給人看的任務。
• 411:32 後來找到一個 Kanban board，內容很長，但大多在 done 欄位
  ↳ 後來翻到一個 Kanban board（看板，把工作分成待辦、進行中、完成幾欄來移動）。內容很多，但大部分已經在 done（完成）那一欄。
• 412:04 貢獻者圖表：commit 最多的人有 157 個 commit
  ↳ 看貢獻者圖表，commit 最多的人有 157 個。commit 是每次存下一筆程式改動的紀錄，數字越多代表改得越勤。
• 412:04 PR 總數有人說大約 433，也提到 273；預期一定會超過 300（字幕中數字說法不一）
  ↳ PR 總數字幕裡說法不一，有人說大約 433，也有提到 273。總之大家都覺得一定超過 300 個，量很大。
• 412:45 很多使用者回報一直被配對到 AI 玩家，講者讓 bot 優先修這個 bug
  ↳ 很多使用者抱怨一直被配對到 AI 對手，而不是真人。講者叫 bot 把這個 bug 排在第一優先修。
• 412:45 有 bot 專門監看 Slack 的使用者回饋頻道，彙整回饋後自動重現、修正、驗證
  ↳ 有一個 bot 專門盯著 Slack 裡的使用者回饋頻道，把意見整理好後，自己重現問題、修好，再確認真的修好了。
• 413:24 開發 Grokbot 本身時流程比較嚴謹；ThursdayArena 為了省時間，合併得比較快，講者坦言完全沒讀過它的程式碼
  ↳ 開發 Grokbot 本身時比較謹慎。ThursdayArena 為了省時間合併得很快，講者坦白說他完全沒讀過它的程式碼。
• 413:54 在 Grokbot code base 中，他會實際讀程式碼、深入看 PR，找出 agent 寫的 anti-pattern，再加上 lit rules 來檢查
  ↳ 在 Grokbot 裡，他會真的讀程式碼、細看每個 PR，找出 agent 常犯的 anti-pattern（壞寫法），再加上 lit rules（自動檢查的規則），之後就會自動抓出來。
• 413:54 典型例子：agent 很愛留註解，而且常用註解替 workaround 或 hack 找理由，卻沒有修好根本原因
  ↳ 最典型的例子：agent 很愛留註解，而且常用註解替「先繞過去」的寫法（workaround、hack）找理由，真正的問題卻沒修好。
• 414:24 久了檔案會充滿 band-aid、變得很脆弱，所以他在 Grokbot code base 中禁止註解；ThursdayArena 則沒有這樣做
  ↳ 時間一久，檔案裡到處都是 OK 繃式的臨時補丁，很容易一碰就壞。所以他在 Grokbot 直接禁止寫註解；ThursdayArena 則沒有這樣限制。
• 414:24 potato mode 內建一個叫 no comments 的 skill，會啟動一個「comments sicko」agent 去刪除一堆註解
  ↳ potato mode 內建一個叫 no comments 的 skill（事先寫好、可以重複呼叫的一套指令），會叫出一個「註解狂魔」agent，專門刪掉一大堆註解。
• 414:54 講者認為目前 code base 的註解控制得不錯；最後把話題轉向詢問 Eric 平常的開發 workflow
  ↳ 講者覺得現在程式碼裡的註解量控制得不錯。最後話題轉到 Eric，問他平常的開發 workflow（工作流程）是怎麼進行的。

講者為什麼在 Grokbot code base 中禁止 agent 留註解？