Grok Bot Galaxy 直播：第 1 天（第 27/44 段） ☕ Buy me a coffee

🧑‍🏫 這段是 Grok 直播第一天的中段。團隊同時開了好幾個 AI bot，一邊寫網站，一邊找場地、做宣傳，要在舊金山辦一場快閃餐飲活動。值得看的是他們怎麼分配：哪些交給 bot，哪些先由人自己做，哪些乾脆先不做。

• 310:21 已經有一份擅長料理的外燴短名單可以打電話聯絡；bot 同時在找實際的場地，也在串接 email
  ↳ 他們手上已經有一份很會做菜的外燴名單，外燴就是到場供餐的廠商，可以直接打電話問。同時，bot（自動幫忙做事的 AI 助手）在找實體場地，也在接上 email 功能。
• 310:21 想在 UI 顯示地點資訊，所以需要 Google Maps key
  ↳ 他們想在 UI（使用者看到、操作的網站畫面）上顯示地點和地圖，所以要先申請 Google Maps key。這組通行碼讓網站有權使用 Google 地圖服務。
• 310:53 他們認為籌辦活動時地點是最重要的事之一，希望能在平台上快速找到好地點，這樣就能跟其他各個部分串在一起
  ↳ 對辦活動來說，場地幾乎決定成敗。他們希望在自己的平台上就能很快挑到好地點，之後外燴、報名、宣傳都可以跟著這個地點串起來。
• 311:25 提議用 OpenStreetMap 當免費替代方案，key 比較容易取得，可以先用它，之後再換
  ↳ OpenStreetMap 是大家一起編的免費開放地圖。它的 key 比較好拿，所以先用它，之後需要再換成 Google Maps，不用卡在申請流程上。
• 311:25 點子：建立 places directory，收錄適合辦快閃活動的已知地點；在某地辦過活動後可以評分，之後再慢慢做
  ↳ places directory 就是一份快閃場地清單：把適合辦活動的地點收進來，辦過活動後打分數，下次挑場地就有根據。這件事先記著，以後再做。
• 311:55 軟體還在開發時，先用人工方式找地點、打電話聯絡
  ↳ 軟體還沒做好，事情也不用停。他們先用最基本的方法，由人自己找場地、自己打電話，讓活動籌備和軟體開發同時進行。
• 312:30 想把 admin dashboard 鎖起來，只讓 Matt 能存取
  ↳ admin dashboard 是管理後台，可以看資料、改設定。這種頁面不能讓外人進來，所以要鎖起來，只讓 Matt 一個人使用。
• 312:30 他們先不寫軟體，改走「bot 路線」：讓 bot 找 20 家商家並取得 email 和電話，再由人工聯絡
  ↳ 他們不先寫程式做自動化，而是直接叫 bot 上網找 20 家商家，整理出 email 和電話，再由人一家一家聯絡。先拿到結果，系統以後再說。
• 312:30 他們判斷，找一個月後有空的外燴應該可行，找場地可能比較難
  ↳ 他們判斷，一個月後的外燴檔期應該約得到。合適的場地比較搶手、條件也多，可能才是真正卡住的地方。
• 313:00 正在設定 email，讓網站可以接上簡單的報名功能
  ↳ 他們正在設定寄信功能，讓網站能收報名。有人填了資料，系統就能寄確認信或通知，最基本的報名流程就能運作。
• 313:00 登入方案討論：WorkOS、GitHub 登入；不是每個人都有 GitHub，可改用 Google 登入；不自己寫 OAuth 管理，改用 Clerk 這類服務
  ↳ 登入方式比較了 WorkOS（另一家登入服務）和 GitHub 登入。但不是每個人都有 GitHub 帳號，Google 比較普及。OAuth 是「用某個帳號登入」背後的授權機制，他們不自己寫，交給 Clerk 這類服務處理。
• 313:30 Clerk 有不錯的 hobby tier，決定先用 Clerk 開發，需要時再調整；只有他們三人應該能登入
  ↳ Clerk 是專門代管登入的服務。它的 hobby tier（給小專案用的入門方案）很夠用，所以先用它開發，不合適再換。目前只開放他們三個人登入。
• 314:03 Vercel 也有簡單的驗證功能，可以讓團隊成員透過 identity provider 登入
  ↳ Vercel 是常用的網站架設平台，本身也有簡單的驗證功能。團隊成員可以透過 identity provider 登入，identity provider 是幫你證明「你是誰」的帳號服務。
• 314:33 原型先求能用（scrappy），不確定原型好不好，不想過度開發；最後決定原型先用 Vercel deployment protection
  ↳ scrappy 指的是簡陋但能用。原型好不好還不知道，不值得花力氣做完整登入。所以先用 Vercel deployment protection 把整個測試網站鎖起來，只有團隊進得去。
• 315:06 開一個 bot 找舊金山最常見的 50 個街角來打廣告，再請 design bot 做傳單，進行 guerrilla marketing
  ↳ 另外開一個 bot 找舊金山人最多的 50 個街角，再請設計 bot 做傳單去發、去貼。這叫 guerrilla marketing（游擊式行銷），花小錢、靠街頭曝光。
• 315:36 landing page 還在修飾；建立了很多 API key，這屬於環境設定工作
  ↳ landing page（也叫 lander）是訪客第一眼看到的活動主頁，還在修。另外建了很多 API key，也就是讓程式能呼叫各家服務的通行碼，這是事前的環境設定。
• 316:07 有些事還是得手動，例如建立 API key；他們正努力讓這步驟未來不必手動
  ↳ 有些步驟 bot 還做不到，例如到各服務網站申請 API key，目前得靠人自己操作。他們在想辦法讓這一步以後也能自動完成。
• 316:07 verification PR 已經開好，先讀過內容，看起來沒問題
  ↳ PR（pull request）是「我改了這些程式，請檢查後合併」的申請。處理驗證功能的 PR 已經開好，他們先讀過內容，覺得沒問題。
• 317:11 一方的 bot 把資料貼到 Notion，能幫另一方的 bot 取得業務背景；於是討論把 Notion 當作 source of truth
  ↳ Notion 是線上筆記兼資料庫。一個 bot 把資料寫進去，另一個 bot 讀了就懂業務背景。所以他們想讓 Notion 當 source of truth，也就是有疑問時大家都以它為準的那份資料。
• 317:11 新開的 bot 以 10 月 15 日（October 15th）作為活動日期
  ↳ 新開的 bot 用 10 月 15 日當活動日期來規劃。日期這種每個 bot 都會用到的基本資訊，一定要大家一致。
• 317:41 建立 knowledge base manager bot：負責整理 Notion、追蹤進度；會看其他 bot 的對話，但沒被叫到就不行動
  ↳ 他們設了一個 knowledge base manager bot，像專案祕書一樣整理 Notion、追進度。它會看其他 bot 的對話，但沒人叫它就不動手。
• 317:41 knowledge base manager 要選擇性更新 Notion，不把所有資訊都倒進去，更新前先跟使用者確認
  ↳ 它不會把看到的東西全部塞進 Notion，而是挑重要的寫，寫之前還要先問人確認。這樣資料庫才不會越堆越亂，也比較不會混進錯誤資訊。
• 318:11 還沒有確立 design system，目前正在做的版本非常極簡；有很多好用的 component library 可以直接用
  ↳ design system 是一套統一的視覺規則，例如顏色、字體、按鈕樣式。目前還沒定，畫面很簡單。市面上有很多 component library（做好的按鈕、表單等元件包）可以直接套用。
• 318:41 想做傳單時，有 design system 會比較方便；有人提議用 base UI 等方案，但因為還在很早期，先不用擔心外觀
  ↳ 要做傳單時，有統一的設計規則會方便很多，風格也比較一致。有人提議用 Base UI 這類元件庫，但現在還很早期，外觀先不用管。
• 318:41 進度回顧：要在舊金山辦快閃活動，可能是餐飲快閃；多組 bot 同時在做 design system、landing page 和架構
  ↳ 進度整理：要在舊金山辦一場快閃活動，大概是餐飲類。好幾組 bot 同時在做設計規則、活動主頁和整體架構，架構指的是系統怎麼拆、怎麼串。
• 319:12 重點是快速驗證這個方案；另一人和 marketing bot 在做 guerrilla marketing
  ↳ 重點是快，盡快確認這個點子有沒有人買單。同時，另一位成員帶著 marketing bot 負責街頭游擊宣傳。
• 319:42 目標是先讓 landing page（lander）上線，並開始記錄流程；Lauren 負責工程工具，另一人處理臨時雜事
  ↳ 第一個目標是讓活動主頁上線，並開始記錄工作流程。分工上，Lauren 負責工程工具，另一人處理各種臨時雜事。
• 320:12 design system 可以放在 monorepo 裡，讓 repo 當 source of truth
  ↳ repo 是存放程式碼的地方，monorepo 是把多個專案放進同一個 repo。design system 也放進去，repo 就成了設計規則的唯一依據，bot 都照它做。
• 320:12 考慮加 lint rules、開始重視程式碼品質，但因為只是原型而猶豫
  ↳ lint rules 是自動檢查程式碼寫法的規則，有點像文法檢查。他們在想要不要現在就加、開始要求程式品質，但這只是原型，所以還在猶豫。
• 320:44 他們認為之後再加 lint 並重構比較容易；新創常犯的錯是預先過度設計，結果根本用不到，也可能計畫行不通而 pivot
  ↳ 他們覺得之後再加檢查規則、整理程式並不難。新創常犯的錯是一開始就規劃太完整，結果功能沒人用，或計畫行不通要 pivot（轉換方向），前面就白做了。
• 321:15 等 PR 陸續進來（可能明天），就開始 review 程式碼，看 agent 在哪裡犯錯
  ↳ PR 陸續進來後（可能明天），他們會逐一檢查程式碼，看 AI agent 在哪裡出錯。agent 是能自己規劃、動手做事的 AI。
• 321:45 觀念：codebase 是一種記憶；架構設計和技術棧帶來的限制，能讓 agent 預設就更聰明
  ↳ 程式碼本身就是一種記憶，AI 讀了就知道這個專案怎麼做事。架構和 tech stack（用哪些程式語言、框架等技術組合）帶來的限制，能讓 AI 不用特別教，預設就少犯錯。
• 321:45 有人提議乾脆選最嚴格的技術棧（strictest tech stack）
  ↳ 照這個想法，有人乾脆提議選最嚴格的技術組合。規則越嚴，AI 越難寫出亂七八糟的程式，出錯也比較容易早點被發現。

採用「bot 路線」時，他們請 bot 找多少家商家，並取得 email 和電話？