https://x.com/i/broadcasts/1AxRnZbVpjaxl
三個人、三天、一個空到不能再空的 GitHub 組織，還有一條規矩：做出來的東西要有人願意付錢，而且錢要真的進到公司帳戶。這是 Grok Bot Galaxy 直播的 Day 1，場景在舊金山 Moscone Center 旁邊的攝影棚，同一週整座城市在辦 Dreamforce，街上多擠進了大約五萬人。
主持人 Matt Palmer 做開發者體驗與使用者教育，Lauren 在 X 上叫 Potato，負責 Grok Bot 的工程跟效能，Roshan 在 SpaceX AI 做產品。開場沒多久他們就承認：要做什麼生意，還沒決定。接下來八個多小時，畫面上同時跑兩條線。一條是三個人在空白的 GitHub 組織裡真的開始蓋東西，另一條是輪番上場的 Grok Bot 課程，從工程、產品一路講到創辦人跟通路。
三天做一間公司，不是再做一個 demo
起始條件乾淨到有點殘忍。全新的 Grok Bot 團隊，裡面零隻 bot；完全空白的 GitHub 組織；沒有題目，還說好要把犯的錯也播出來，不會只剪成功的部分。
成功的定義倒是先講清楚了：東西要有用、要有人想要，要自己敢用，最後要有美金流進銀行帳戶。他們不想再端出一個看起來很炫的軟體 demo，要的是三天結束時真的能動的一間公司，而 Day 1 至少要先長出一個講得出口、撐得住的想法。
GitHub 組織取名叫 Ship by Thursday，網址 github.com/shipbythursday。開播時它「完全空的，你點進去什麼都看不到」，第一個工作用的 repo 先設成 private，怕不小心把半成品推出去。後來 Slack、Notion、Vercel、PlanetScale Postgres、Resend 的網域驗證、Cursor 存取權、shipbythursday.day 陸續接上，公司的骨架先搭起來。直播中間一度有大約八萬人在線上看。
比賽：把 bot 模板交出來，換一趟 Starship
整場直播穿插一個公開比賽。要參加的人，把自己的 bot 模板分享出來，講清楚你是怎麼把 Grok Bot 用進工作裡：在 X 上引用官方貼文，附上 bot 的說明和模板連結，細節看 @Grok 和 @Bot 兩個帳號，或直接去 x.com/grok。
獎品很 SpaceX。最大獎是得主加一位同行的人，一起去 Starbase 看 Starship 發射；二獎是去 Hawthorne 參觀火箭工廠。投稿在 2026 年 9 月 29 日截止。同一週的課程全部免費，時程掛在 x.ai/galaxy，他們在台上講得很白：「沒有要付費的課，你現在看的這個畫面就是課程。」
三位主持人平常怎麼用
Matt 示範的是他自己最常用的一條流程。有一隻 bot 專門盯著他的 X 書籤，看到有趣的套件或新技術，就自己去開一個 Cursor cloud agent，做出小範例，再生成一個預覽部署。隔天早上他收到的訊息長這樣：這是你昨天存的那個技術，這裡有一個已經部署好、可以點的版本。
Roshan 想示範完整的 zero-to-one。先去外面撈資料、看大家在講什麼，找出使用者真正的痛點，安排訪談，做可以丟掉的 prototype，再讓設計、行銷、工程的 bot 一起動起來。他反覆提的一點是，現在寫程式的成本很低，難的是把使用者故事想清楚。
Lauren 平常會用一隻 bot 盯著 X 上所有提到「potato」的訊息並且回覆，因為手動根本回不完。她主業是 Grok Bot 的工程，對效能特別執著。她把自己做嚴格工程的一套 Skill 和工作流整理成開源 plugin「PStack」，放在 Grok Bot Marketplace 上給大家用。上個月（八月），她靠 PStack 送進兩千五百個 PR 到 production，「我不覺得我造成了任何 bug，希望沒有」，換算下來一天大約 83 個 PR，台上還開玩笑說要在直播畫面上放一個 PR 計數器。這次建置她連 PR 都懶得開，直接 merge 進 main；用她的說法，repo 要讓 PM 跟設計師也能貢獻，而且預設就是好的。
Grok Bot 101：bot 是同事，不是一次性任務
課程由 Roman 和 Amrita 開場。他們把 Grok Bot 放在 chat、copilot 之後：不是丟一個任務，而是給你一群有記憶、有責任範圍的隊友。三個核心是 bot 像同事、有自己的電腦、全部跑在雲端。有自己的電腦很關鍵，遇到沒有 MCP、沒有 API 的網站，它照樣能操作，看影片、聽 podcast、填 Google 表單，甚至 1990 年代的政府系統；跑在雲端，流程才不會因為你闔上筆電就不動。他們也解釋為什麼要計較「做完」：以前 agent 衝到 90% 就停下來，剩下 10% 要人接手，現在要的是一路做完、你能放心丟給它。
Amrita 在台上開了一隻新 bot：Data Dan。她用語音要它開一份 Google 表單，問一天喝幾杯咖啡、最喜歡哪家舊金山咖啡店，選項放 Ritual、Fields、Sightglass、Blue Bottle。bot 在自己的 Linux 虛擬機裡操作表單，還生了 QR code；第一版掃了沒反應，因為表單沒公開。Amrita 只跟它說「大家掃不到」，bot 就自己找到分享設定修好。她的重點是：講清楚症狀跟你要的結果，比下指令有用。
第二隻 bot 是 Slide Sonia。Amrita 示範「Teach a Task」：她接管 bot 的電腦，示範一次怎麼在 Google Slides 裡做飛入動畫，那段錄影就變成可以重複使用的 Skill。她還示範 routine：每天早上九點，幫我整理這份跟同事共用的簡報有哪些改動。
第三隻是 Email Ethan，負責對外寄信。它先讀 Amrita 過去的信學語氣，再跟 Data Dan、Slide Sonia 要資料，草擬給外部利害關係人的信，寄出前一定先問；想換口氣就複製幾隻，對高層、對使用者、對內部團隊各一隻。這些 bot 會互相傳訊息，也能進同一個群組聊天；Email Ethan 自己想到去要咖啡資料，再等 Slide Sonia 的大綱。Amrita 另外開了一隻 manager bot，每兩小時跟三位專家要一次進度。
權限上，Grok Bot 用一個自動審核的分類器決定哪些動作要問人，使用者可以加嚴，例如「就算只是在我的桌面開一個新資料夾，也要先問我」；示範時表單那隻 bot 一直在討批准，因為系統會檢查有沒有牽涉個資或健康資訊。企業設定裡，每隻 bot 的電腦彼此隔離，可以用憑證或 VPN 進內部系統，1Password 的整合會用彈窗給憑證，不會把密碼攤在虛擬機上；記憶存在雲端、可以叫它忘掉，複製一隻 bot 則保留人設、記憶清空。真人跟 bot 混在同一個群組聊天還在開發中，Slack 對話串已經做得到。
第一天的生意：從觀眾留言裡挖題目
前一天他們在 X 上問大家「我們該做什麼」，收回來數千則回覆，交給一隻叫 Marky McMarkface 的市場研究 bot 讀完、分類。回饋很集中：不要再做通用的 SaaS demo；做實體、做在地、做給不那麼懂技術的人；幫傳統小生意處理重複的營運雜事。點子從油漆、園藝、餐廳、到府晚餐到懷舊體驗都有，也有人直接說不要碰迷因幣。
Lauren 拿她媽媽當測試標準：這東西要連她媽都看得懂，因為她媽「連自己的 email 都不太會用」。他們喜歡的方向是：客人看到的體驗很簡單，困難的物流跟雜事全部丟給 Grok Bot。餐廳營運助手很快變成領先的候選，例如餐廳經理早上收到一份簡報，裡面有訂位狀況和今天哪些菜沒了；老闆監控並回覆評論；小生意把每週重複的雜事自動化。這個題目同時有實體活動跟一套系統，兩邊都能示範。
Peter Yang 上線時把話說得很直。他建議設計成自己喜歡做的工作，因為為了營收去做討厭的事，創業就失去意義。他最核心的一點是市場訊號要快點拿到：嘴上說好不算數，有人真的掏錢才算。他也提醒，點子很便宜，不要愛上第一個想法，團隊比點子重要；landing page 要真的送到買家面前，直播觀眾不一定有足夠的餐廳老闆；純軟體越來越難收錢，有實體或服務的成分，才比較有付錢的理由。他的 bot 每週五會用編號清單跟他回報。
Lauren 的幕僚長 bot Steve 給的建議最冷靜：現在缺的不是 landing page，「第一個循環是找到場地、找到會做或會賣食物的人，觀眾自然會來」。他們接受了這個順序，先把事情用手做一遍，再從痛苦的地方長出軟體。第一個完整概念因此成形：在舊金山辦一場食物 pop-up，加上一套「pop-up 作業系統」，連起主辦或廚師、場地、客人三種人；形式可能是售票的私廚餐會、限定餐廳、薯條攤，或讓餐廳老闆測試概念的平台。網站先切兩頁，一頁給餐廳跟活動主辦，一頁給自己這場活動的客人。
Lauren 的工程小隊也在這個時候組起來，名字從 Steve、Plaud Note 到 Tater、Hashbrown、Dr. Plaud Note，有幕僚長、有做可丟棄 prototype 的、有寫程式的、有審 PR 的，還有一隻生產其他 bot 的 bot 工廠。可以丟的 prototype 直接在 bot 介面裡 render，認真的工作進 Cursor cloud agent。她開了 Slack 的 PR review channel，讓 Cursor automation 檢查 PR 的正確性、風險跟缺的測試，會用 Playwright；另外規劃 bug report channel，讓回報的問題自動進入診斷跟修復。她也裝了 PStack，開始寫一個可以重複使用的驗證 Skill：agent 要自己去跑應用、收 trace、抓 heap snapshot，把證據附上來，而不是叫人在那邊一格一格點。她也刻意不在一開始就加太多 lint 跟架構，因為生意可能轉向；語言最後選了 TypeScript。
穿插整天的課：工程、產品、創辦人、通路
Ling Shi 講怎麼把多個 Cursor cloud agent 當工班管：她過去兩個月只用 Grok Bot 寫程式，手機版第一版是自己一個人三週做出來的，同時開過 15 個 cloud agent，後來最想要一個 agent 幫她盯其他 agent。她的排程包括凌晨三點掃 repo、CI 紅燈自動開 agent 修、on-call 撐到十分鐘才叫人、P0 每五分鐘檢查一次進度，看到 sleep 300 這種空等就打斷。她的結論是：把 bot 當聰明但沒有組織背景的實習生，重複的指令要變成 playbook 或 routine，每個任務都要有完整的回饋圈。
Kevin DiParco 跟 Roshan 用虛構的航空公司 Flylo 示範產品流程：資料科學家 bot 撈出前一天一千四百筆購票，58% 在網頁、42% 在手機；大家猜手機流失是因為選位，它糾正最大的流失在搜尋到選票價那一段。接著需求文件、兩個 Figma 版本、觀眾投票、工程 bot 開 Cursor cloud agent 準備 PR，整條鏈跑完；他們也提到 Grok Bot 在內部已經占掉兩位數百分比的 merge PR。
Shab 講創辦人版的三隻代表：CloseBot 準備客戶電話、讀完逐字稿學哪些說法有用；ProdBot 每天回報 shipped 了什麼、拿掉了什麼，附截圖跟指標；StockBot 研究競品，用免洗信箱註冊、讀 changelog、看徵才，還會問流失客戶為什麼走。他的原則最實用：能用 API 就別一直開瀏覽器，十五分鐘一次的 routine 等於一天一百次要審，寧願用 webhook 也不要盲輪詢。
Cody Sanchez 講通路：決定要做什麼之前，先試著把這個生意賣給三個人；大部分公司拿不到創投資金，通路才是護城河，而「我看過的 AI 公司活不下來，最常見的原因就是沒有通路」。她說自己曾照著「找 A 級人才，然後不要管他們」做，結果那是一間一百五十人公司差點發不出薪水的唯一原因。她主張從第一天就存「proof vault」，見證、觀看數、截圖、成長紀錄全部留證據，也提醒先做五、六個真的有用的 lead magnet 丟到 X 上測。最後一句：「你把它蓋好，我保證，他們不會自己來。」
Jenny 則是把生活 bot 化：七個生意、二十二隻 Grok Bot，身邊還有一個嬰兒。她的公司 Gemalin Media 做高階主管品牌，Master Chief 是跨生意的幕僚長，下面有 Boxy 盯信箱、Scribe 做會議紀錄，還有一隻在 Poshmark、Depop 上幫她賣二手衣、跟買家談價。她的方法很一致：先自己當人做一次，再反向工程成 bot。
活動規劃的現實檢查
Jenny 做過大型 pitch 比賽，直接拿問題清單對著他們問。要在舊金山辦一場一百到兩百人的 pop-up，事情比想像中多：場地是倉庫還是藝廊、晚上還是白天、要不要賣酒、廚房在現場還是找外燴、很多場地只准用指定外燴、報到跟保全還是要人、至少要有麥克風跟音響。不賣酒能讓許可單純很多，但他們還是想要熱食。她的建議是：先找到一個很讚的場地，再順著場地的限制調整。
他們連預算都還沒編。Jenny 說，先讓 event planner bot 生一份舊金山活動的製作預算，場地、餐飲、人力、製作、音響全部列進去，再去談場地。她提了一組活動 bot：場地 scout、預算 bot、問檔期跟談價的 RFP bot、研究法規的 permit bot、管合約的 policy bot、找名單的 invite bot。她也提醒，AI 看合約大概就是「法律系二年級」的水準，真的要簽還是得找律師。
現實層面，他們看的是容納一百人左右的倉庫型空間，例如 The Pearl、Dogpatch Studios；Fort Mason 這種公共場地要先過審，四到十五個工作天跑不掉。他們先押了 10 月 15 日當暫定日期，但沒有定案，因為許可一個月前才開始跑「有點緊」。食物的麻煩最直接，場地、廚房、外燴、保險、酒牌每一項都是成本；他們一度想改成藝術展，倉庫更好找，找本地創作者一起展，做一個數位加實體的 Grok Bot 主題展，避開餐飲跟酒。這件事也沒有真的定下來。
從食物到周邊：概念一直換，換到收工還是沒定
後來 Eric 上線，把問題拉回產品。他是 Carrot Financial 的共同創辦人兼 CRO，說產品管理就是三件事：決定要做什麼、決定怎麼做、把做的過程協調起來；AI 讓第三件變得很簡單，前兩件還是要靠人。他認為做實體是對的方向，因為軟體跟 AI 內容越好複製，現場體驗反而越值錢。他也點出一個分岔：第一次做 pop-up 的新手，跟已經有店、把 pop-up 當行銷管道的店家是兩種客人，一個通用工具兩邊都服務不好。他們選了前者，拿自己當第一個客戶，題目變成：幫一個科技或 AI 品牌辦一場社群 pop-up，周邊商品就是讓社群願意來現場的理由；最小版本先想三件事：賣什麼、在哪裡賣、怎麼報名或賣票。
周邊清單一路亂聊：帽子跟帽T、馬鈴薯玩偶、Grok Bot 角色玩偶跟壓力球、SpaceX 發射照片、可以收藏的實體票、Build-A-Bear 式的自製 Grok Bot、Grok Bot 版 Tamagotchi，還有一比一的鎢球。其中一個想法是會連線的實體小物，顯示天氣、生意銷售或 Slack 有沒有動靜。這還停留在閒聊階段，Eric 的建議是只挑兩三樣做到極好。
Carrot 自己的路徑可以當參考：一開始只做創作者的銀行跟信用，等可以重用的金融原語出來，才擴到創辦人跟中小企業；pop-up 這個產品也可以先服務他們自己這一場，再把驗證過的部分一般化。對創作者，他建議把 bot 放在可以被驗證的商業流程上，例如找品牌合作、寄開發信、談價、想內容題目，因為結果好不好，比創意好不好容易檢查。
收工前，基礎建設其實都蓋好了：GitHub、Vercel、資料庫、寄信、網域、粗略的 landing page、報名資料的儲存、市場研究跟 outreach bot、工程跟 review bot、PR 跟 bug report 的自動化，還有一套正在長出來的驗證框架。生意本身沒鎖定。概念從餐廳營運助手，換到食物 pop-up，換到藝術展，再換到品牌周邊社群活動。他們在最後幾分鐘自己問了一句：「這是不是我們該解的題目？」在舊金山辦 pop-up 的難度比預期高，那天晚上要收斂到一兩個做得出來的東西，其他的交給過夜的 agent 繼續查。直播最後，他們說明天見，然後訊號就斷了。