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

🧑‍🏫 這段用一家虛構的航空公司 Fly Low 當例子，示範好幾個 Grok Bot 像一個團隊一樣分工：先查數據找問題，再寫產品規格，最後交給工程和設計。值得看的地方是它把「AI 助理」從一問一答，變成會互相交接工作的團隊成員，也提醒你人在哪些地方還是要把關。

• 370:02 可以把 bot 分組：例如 pod 裡的工程團隊開 standup、EPD（工程、產品、設計）三個角色一組，或開 war room 讓一群 bot 分流問題、處理事故
  ↳ bot 可以像真人團隊一樣分組，pod 就是一個小組。standup 是快速報進度的短會；EPD 指工程、產品、設計三種角色；war room 是出事時的緊急應變小組，讓一群 bot 分頭查問題。
• 370:32 示範用的 bot：Kora 是 chief of staff（幕僚長），PM Pete 是產品助理，Ashley 是資料科學助理
  ↳ 每個 bot 都有固定職位。chief of staff（幕僚長）幫主管統籌大小事；PM 是產品經理，Pete 是協助產品工作的 bot；Ashley 專門處理數據分析。
• 370:32 畫面上看到的內容都接到一個示範環境，這個環境是為一家虛構的航空公司 Fly Low Airlines 建的
  ↳ 示範裡的公司和數據都是假的。Fly Low Airlines 是為了展示而特地建的虛擬航空公司，畫面上的數字不代表任何真實企業。
• 371:03 實際示範：問 Ashley「昨天有多少人買票？手機和網頁各多少？」
  ↳ 第一個任務很日常：直接用聊天的方式問 Ashley 昨天賣了多少票，還要按手機、網頁拆開看，就像問同事一樣，不用自己去翻報表。
• 371:34 Ashley 背後接到資料層和 data warehouse（例如 Databricks、Snowflake），會自己寫 query、到外部資料庫執行，再回報結果
  ↳ data warehouse（資料倉儲）是公司集中存放大量營運資料的地方，Databricks、Snowflake 都是常見產品。query 是向資料庫查資料的指令，Ashley 會自己寫、自己跑，再把答案告訴你。
• 372:05 結果：昨天賣出約 1,400 張票，約 58% 在網頁買、42% 在手機買
  ↳ Ashley 回報：昨天大約賣出 1,400 張票，58% 在網頁買、42% 在手機買。這樣一拆，就看得出兩個購票管道各占多少。
• 372:05 接著請 Ashley 算有多少家庭搭機，並畫成圖表；講者特別提到打錯字也沒關係
  ↳ 接著追問搭機的家庭有多少，並要她直接畫成圖。講者特別提到打錯字也沒關係，bot 看得懂你的意思，不必字斟句酌。
• 372:35 講者說，身為產品人，他每天最常用 Grok Bot 做的事之一就是隨時要數據查詢和圖表
  ↳ 對做產品的人來說，隨時要數字、要圖表是天天都有的需求。講者說這是他最常叫 Grok Bot 做的事之一，不用自己寫查詢，也不用等別人幫忙。
• 372:35 可以替 bot 設定 routine（例行任務）：不用每天早上自己開瀏覽器看 dashboard，資料會直接推送給你
  ↳ routine 是例行任務，讓 bot 定時自動做事。dashboard（儀表板）是把各種數據集中顯示的網頁；設好 routine 之後，不用每天自己打開來看，資料會主動送到你面前。
• 373:05 遇到重大產品上線時，他們會要 bot 每小時回報一次資料，隨時掌握上線進度，看出使用者卡在哪裡
  ↳ 重大功能上線時，他們讓 bot 每小時回報一次數據，隨時看得到上線進度和使用者卡在哪一步，問題一冒出來就能發現。
• 373:38 Ashley 畫出的圖表把乘客分成單人、情侶、家庭、團體四類；家庭約占 25%
  ↳ Ashley 畫的圖把乘客分成單人、情侶、家庭、團體四類，家庭大約占四分之一。
• 373:38 示範把這份分析設成 routine：「每天早上 6 點寄這份更新給我」
  ↳ 只要一句「每天早上 6 點寄這份更新給我」，剛剛那次查詢就變成每天自動送來的報告。
• 374:09 先前請 Ashley 做了手機購票的轉換漏斗，看得出漏斗中有不少人流失
  ↳ funnel（漏斗）是把購票拆成好幾步，例如搜尋、選票、付款，看每一步還剩多少人；轉換漏斗追蹤的是最後真的買單的比例。之前做的手機漏斗顯示，不少人中途就離開了。
• 374:41 一開始以為流失發生在選座位；講者說看到數據洞察後，下一步常是研究產品怎麼改，所以決定寫一份 spec
  ↳ 團隊原本猜人是在選座位時跑掉的。講者說，看到數據找出問題後，下一步通常是研究產品要怎麼改，所以決定寫一份 spec（規格文件），把要改什麼講清楚。
• 374:41 在聊天裡可以開 thread 回覆某則訊息；訊息裡 tag PM Pete，bot 之間就會互相對話
  ↳ thread 是針對某則訊息開的回覆串，討論才不會跟其他訊息混在一起。在訊息裡 tag（標記）Pete，他就會被叫進來，Ashley 和 Pete 會直接互相對話。
• 375:11 Pete 掌握產品脈絡：了解公司業務、客戶，也知道過去做過哪些產品決策，可以解釋漏斗為什麼在這裡流失
  ↳ Pete 不只會寫文件，他還知道公司做什麼生意、客人是誰、以前做過哪些產品決定，所以能解釋人為什麼在這一步流失，而不只是看數字。
• 375:42 Ashley 糾正了人類的解讀：手機購票漏斗真正的流失點是「搜尋 → 票價選擇」，不是選座位
  ↳ Ashley 查完資料後指出人類猜錯了：流失最多的是「搜尋完到選票價」這一步，不是選座位。也就是說，bot 會拿數據推翻你的猜測。
• 376:14 Ashley 把調查得到的洞察和具體需求傳給 PM Pete，兩個 bot 開始協作
  ↳ Ashley 把查到的發現和具體需求交給 Pete，就像資料分析師把報告交給產品經理，後面的工作由兩個 bot 接力完成。
• 376:44 Pete 產出一份 Notion 上的 PRD，列出 P0、P1 等級的需求
  ↳ PRD 是產品需求文件，寫清楚要做什麼功能、為什麼要做。Notion 是常見的線上筆記和文件工具。P0、P1 是優先順序，P0 最急、一定要做，數字越大越可以晚點做。
• 376:44 Pete 的 skill 認為好的 PRD 要求寫得很精準；比起文件能用多久，更重視能不能快速寫成程式和做出原型，因為寫程式的成本越來越低
  ↳ skill 是訓練進 bot 的做事方法。Pete 的寫法很要求精準：現在寫程式越來越便宜，文件的價值在於能快速變成程式和原型，而不是放著用很久。
• 377:15 Pete 的 context 裡有訓練好的 skills，讓他懂公司業務；被要求寫 PRD 時，會列出精準的 P0、P1、P2 需求
  ↳ context 是 bot 做事時可以參考的背景資料。Pete 的 context 裡已經放了訓練好的 skills，所以他懂公司業務，被要求寫 PRD 時會把需求精準分成 P0、P1、P2 三級。
• 377:15 PRD 提出的點子：重新設計手機版票價搜尋結果、更快速的比較區塊、在票價卡片上清楚呈現票價依據
  ↳ PRD 提出三個改法：重新設計手機版的票價搜尋結果、加一個能快速比價的區塊、在票價卡片上講清楚這個價格是怎麼來的，全都針對剛找到的流失點。
• 377:45 重點提醒：bot 有很多 context，但不見得什麼都知道，最好加一層人工審查，和 Grok Bot 反覆修改；示範為了方便才一次到位
  ↳ bot 知道很多，但不是什麼都知道。實際使用時最好由人檢查，跟 bot 來回修幾輪。影片為了示範方便才一次就產出成品，實務上別期待一次搞定。
• 378:16 講者常用的修改方式：直接在 Notion 留言，bot 讀得到 Notion 留言，就像跟同事互動；Google Docs 和其他 connector 也適用
  ↳ connector 是讓 bot 連上外部服務的接口。講者習慣直接在 Notion 文件上留言，bot 讀得到留言、會照著改，就跟同事改稿一樣；Google Docs 等服務也能這樣用。
• 378:46 Emily 是工程經理，掌握整個工程團隊的狀況；請 Pete 把 PRD 交給 Emily，由她找工程團隊做原型
  ↳ Emily 是工程經理 bot，清楚整個工程團隊的狀況。請 Pete 把 PRD 交給她，由她找工程團隊做原型，也就是先做出能實際操作的簡易版本來驗證想法。
• 378:46 另外請設計 bot Pixel 加入，為每個 P0 需求做設計
  ↳ 再把設計 bot Pixel 拉進來，替每一個 P0（最優先）的需求做出設計。
• 379:18 Grok Bot 有自己的雲端虛擬機，能上網、登入，並用你的帳密在各種服務上實際完成工作
  ↳ virtual machine（虛擬機）是放在雲端的一台電腦。Grok Bot 有自己的一台，能上網、登入各種網站，用你提供的帳密真的把事情做完，不只是給建議而已。
• 379:49 虛擬機右上角有「teach it a task」功能：你在機器上錄下自己的操作流程，agent 看過後就能照做
  ↳ teach it a task 就像錄一段教學：你在虛擬機上自己操作一遍，agent（能自己動手執行任務的 AI）看過之後，就能照同樣的步驟做。
• 379:49 應用例子：業務和 go-to-market 團隊有很多複雜、需要一再重複的 Salesforce 流程，直接錄給 agent 看，比只用文字或口頭說明有效
  ↳ Salesforce 是常見的客戶管理系統；go-to-market 團隊負責把產品推向市場、賣出去。他們有很多複雜又一再重複的流程，直接錄操作給 agent 看，比用文字或口頭解釋有效。
• 380:20 agent 每次執行學到的任務，都能順便改進這項 skill（前面講過的回饋機制），很適合用在客製化系統上
  ↳ agent 每次執行學來的任務，都會順便修正做法，越做越熟。所以特別適合公司自己客製、外面找不到現成教學的系統。
• 380:51 結果分成兩條交接：Emily 負責做原型，Pixel 負責做設計和 mock
  ↳ 最後工作分兩路交接：Emily 帶工程團隊做原型，Pixel 負責設計和 mock（設計稿，也就是畫面長什麼樣子的示意圖）。
• 380:51 Pixel 受過當好 AI 設計師的訓練，也掌握公司的設計系統；設計系統放在 Figma，Pixel 的 context 裡另有參考檔
  ↳ Pixel 被訓練成稱職的 AI 設計師。design system（設計系統）是公司統一的設計規範，這家公司放在 Figma（常見的線上設計工具）上，Pixel 手上另外還有參考檔。
• 381:22 Pixel 內建的 context 包括偏好的字型、顏色、UI 樣式和禁忌（例如 X 按鈕絕不放左上角），不必每次從零開始，第一次就能大致做對
  ↳ UI 是使用者看到、操作的畫面。Pixel 事先就知道公司偏好的字型、顏色、畫面風格和禁忌，例如 X 按鈕絕不放左上角，所以第一版就大致符合規範，不用每次重教。
• 381:52 Pixel 的設計稿做出來了
  ↳ Pixel 交出了設計稿。從查數據、找出問題、寫規格到做設計，整條流程都由 bot 接力完成，人負責下指令和把關。

示範中，Ashley 糾正了人類對手機購票漏斗的解讀。她指出真正大量流失的地方在哪裡？