首日長桌九點五小時 從零打造公司的現場全景紀錄

大家早安！我們今天在舊金山現場開播。一些比較需要手動處理的軟體工作，但不僅限於軟體，包括知識工作也是——做簡報、做設計。我認為今天最核心的訊息是：AI 能讓你抽出身來，去做你真正在乎的事情。

所以也許我們可以先輪流自我介紹，我先簡單聊一下我自己、做個簡短介紹和我負責的工作，我也很希望團隊其他成員能分享一下。畢竟如果你正在看直播（SpaceX / xAI Day 1 直播存檔），你接下來 72 小時、也就是三天時間裡，都會跟我們泡在一起，嘗試從零開始打造出一間完整運作的公司。稍後我們也會明確說明，當我們說「公司」時到底是指什麼，對吧？

因為網路上對這件事其實蠻多困惑的，大家會說：「喔，他們要創立一家企業」，我還看到有人說「他們要開新創」、「他們要打造數十億美元帝國」。也許這些我們都能做，不過有人跟我們說應該在三天內打造出第二個 SpaceX。我當時心想：72 小時？我們大家本來就已經在 SpaceX 工作了，火箭與航太工程團隊已經處理得很出色，我們今天想做一些不一樣的嘗試。

再自我介紹一次，我是 Matt Palmer（Matt P / @mattyp），負責開發者體驗（DevEx），有時也稱開發者關係（DevRel）。我有很棒的隊友 Lee、Rob、Eric 和 Milo，非常棒的團隊。我們的工作很大一部分是使用者教育，像是教大家如何使用 Grok Bot、如何使用這些全新誕生的技術與工具，這些基本上以前從未有人使用過。

所以我平常會製作大量的教學內容，但也會做一點工程工作，可能到處貢獻點程式碼、更新我們的技術文件，甚至幫忙架設直播之類的。所以這真的是內容、產品與社群交流的綜合體，在 X 上了解產品如何運作、使用者怎麼使用它等等所有這些事情。今天我會從宏觀的高層次角度協調整體進度。

Roshan，你要不要聊聊你平時負責的工作？但在那之前我其實很好奇，你最近做過最喜歡的 Demo 是什麼？因為你總是做出超讚的展示。

好啊！我昨天其實才剛在 X 上分享了這個工作流。畫面上應該有我們個人的社群標籤，Matt Palmer 在 X 上的帳號是 Matt P（@mattyp），我的帳號是 @roshan_s，大家直接在 X 上搜尋就能找到。

我覺得這個工作流真的蠻酷的：我設定了一個 Grok Bot 來跑自動試用新技術的流程。日常我在滑 X 時，常會把感興趣的技術推文加進書籤，例如「這裡有一個很酷的 npm 套件，可以繪製地圖或建立旋轉的 3D 地球」。但平時工作節奏很快，我們很難抽出完整的半小時坐下來建立專案、安裝相依套件、把 Repo 跑起來並讀懂檔案。

所以我讓 Grok Bot 定時去翻我的 X 書籤。一旦發現新工具，它會自動啟動 Cursor Cloud Agent 開始用該技術建構專案、撰寫程式碼，接著我還用 Grok Bot 設定了 Repo，透過 Cloudflare 之類的服務做預覽部署（Preview Deploy）。

現在每天早上醒來，Grok Bot 就會傳訊息給我：「嘿，這是你書籤裡覺得很酷的技術，這是一個已經部署好的預覽版本！」點擊連結就能直接操作。我在個人的 X 頁面上也放了這套操作流程的完整解說推文，這個自動化流程幫我省下大量摸索時間。

我超喜歡這個，很慶幸我有問！這比我自己用 Grok Bot 做的東西酷多了，你根本是 Grok Bot 大神級別！

好，那換我接棒介紹。我是 Roshan Sadanani（@roshan_s），在 SpaceX AI 負責產品。

我感覺產品經理（PM）的角色在過去幾個月、甚至一年多來有了很大的轉變。端看你信奉哪種工作理念，現在每個人某種程度上都是建造者（Builder）。但我花最多時間思考的，依然是如何為客戶打造正確的產品，以及如何將客戶的回饋、還有大家對 AI 工具的期待，真正落實並融入到產品之中。

在日常工作上，針對 Grok Bot，我們在市集裡建立了大量非常棒的連接器（Connectors），我們正努力將更多連接器上架到位；但同時我們也在思考下一步該打造什麼、下一個突破前沿應該是什麼。

我今天其實非常興奮能投入這件事，因為你平常很少有機會從一張白紙開始做「從 0 到 1」的探索。多數時候你都是在既有的平台上思考下一步要做什麼；但我認為這次最棒的地方，是我們能一起走過很多「從 0 到 1」的過程。比如：我們要怎麼去搜集資料來決定該做什麼？外部大眾對各種點子的評價如何？我們該怎麼做使用者研究、甚至安排一些訪談，完整跑一次整套產品開發手冊。過程中我們也希望能做幾個 Bot：也許做個設計師 Bot 幫我們設計很酷的素材，或做個行銷 Bot 幫忙做宣傳推廣。

好，Lauren 你要接著分享嗎？

沒問題！我是 Lauren Tan，Twitter / X 上的名字是 potato（@poteto）。

我經常拿 Grok Bot 來做一堆超狂、很天馬行空的事情。像是幾週前，我在推特上發了個玩笑推文，我說：「如果你想在 X 上召喚我，只要連喊三聲 potato potato potato，我就會現身回話。」發文後湧入了大量標記，我根本不可能手動一則則回，所以我就是用 Grok Bot 把自動回覆流程完全自動化了。

在團隊裡我也負責很多 Grok Bot 的工程開發。能夠上直播跟大家聊聊並一起協作一定會非常好玩，因為平時我總覺得自己像是被困在「哥布林洞穴（goblin cave）」家裡埋頭寫程式。我在 Grok Bot 團隊中對效能極度執著，所以我總是持續不斷地致力於讓 App 變得更快、更快、更快！抱歉我真的很愛追求極致速度。

我們大家都很感謝你這一點！

另一件我非常喜歡且投入大量時間的事，是架構 Grok Bot 的程式碼庫，讓任何人——不管是 PM 還是設計師——都能輕鬆貢獻程式碼，而且寫出來的品質預設就是優良的。所以我也很期待在這裡建立類似的工作架構，這樣我們三個人就能非常迅速地一起建構和迭代產品。雖然我現在甚至還不知道我們到底要做什麼，但我相信會非常好玩！

我也超期待，因為我超愛 Grok Bot 的開發者體驗。站在外部視角來看，你設計的架構極其清晰易懂。我們有專屬頻道，一旦發生問題，只要貼上問題內容，背後的雲端 Agent 就會接手；而且通常一旦出現 Issue，你現身修復的速度往往快得驚人，我超愛這點。

今天我們在打造時，會使用所有創立一家公司時會用到的同款工具。就像你跟三個朋友坐下來，可能會先找個地方聊天、找個地方做筆記，然後用你們最愛的工具開始建構。在 SpaceX 工作很酷的一點是，我們有 Cursor、有 Grok Bot。我們會用 Cursor 寫程式，但接著我們會使用 Grok Bot 來解決所有繁瑣的手動工作。

比如：我們可能想要銷售某樣東西，所以得先想出 Idea。昨天我們在 X 上向各位觀眾以及 SpaceX 員工徵集想法：「嘿，我們該做什麼？大家有什麼好點子嗎？」我們收到了上千條回覆！第一步大概就是讓 Grok Bot 來梳理這些回饋，先做市場研究，接著決定好我們要打造什麼，然後在今天早上對外公佈。

第一天的目標就是拍板點子。也許現在正好可以聊聊，當我們說「我們要打造一家企業」時，對各位來說代表什麼？

對我而言，最核心的是做出有價值的東西。我總是回到「打造人們真正想要的東西（Build something people want）」這個思維。我們需要做有用、大眾想要、甚至我們自己都會想用的東西。如果那是我們自己想打造且會親自使用的東西，我們在做的時候就會抱持極大的同理心。

我很認同「吃自己的狗糧（Dogfooding）」這一點。因為對我來說，在 Grok Bot 團隊工作最棒的一點，就是我能用它來開發它自己！能夠親自 Dogfood 自己的產品並讓它變得更好，成為自己產品的終極重度使用者，這是一個非常棒的正向循環。

不過談到商業，我認為絕對必須包含「賺到實質營收」。在看到真正的收入進到銀行帳戶之前，都不能算是一家真正的企業！

商業營收、進帳戶、實際建構、親自試用、打造人們想要的東西。如果要補充的話，我認為在大家整天重度掛網的時代很容易忘記一件事：大家在看直播、在 X 上獲取新知，很多人整天泡在網路上，我自己花太多時間在 Twitter/X 上了。

但打造一家企業的本質，歸根結底是「為人類服務」。哪怕是 AI Agent，吩咐 Agent 去做事的終究還是人類。所以歸根究底，這還是一種人類體驗的連結：比如我在網路上買一件 T 恤並寄送到家，這算是一個商業點子，但背後是一套為人類創造價值的完整過程。打造 Grok Bot 也是為了讓人能更自然地與電腦互動。

最核心的本質就是：我們要如何為螢幕前的觀眾創造出你們渴望、感到驚奇、能為生活增添價值的東西？開心到願意掏錢支持你，甚至讓他們的 Agent 來下單！我一直想到這個點子：在 Grok Bot 裡，你可以配發一張信用卡給你的 Bot，綁定 Stripe 或 Link 卡。探索這種很酷的應用場景一定很有趣：我們能做什麼讓真人可以來購買，同時 AI Agent 也能前來購買？

也許正在收看直播的觀眾，如果還沒有帳號可以去註冊一個 Grok Bot 帳號，然後讓你們的 Bot 來買我們的東西，這聽起來太好玩了！

另外是實體維度。我們到底是要做數位產品，還是做個平台讓人能線上買咖啡豆並配送到府？抑或是打造某種線下實體的東西？我們現在人在舊金山，Dreamforce 大會剛好正在舉行，市區現在大概湧入了五萬人，整個街區擠滿了人，到處封路、排隊人潮極長。所以對我來說，如果能將數位世界的東西轉化為實體現實中的存在，甚至讓你們各位觀眾都能親自與之互動，那絕對會是我這週最想達成的目標！

好玩的地方就在於：我們只有三天，說多不多、說少也不少。我們有一堆東西得先架設好：我們需要一個 Slack 頻道供團隊聊天、讓 Bot 也能進來傳訊息；我們需要一個 Notion 工作區。Slack、Notion，我們公司平常用的都是這些神器；可能還需要 Linear 來管理 Ticket。

如果有了 Slack，我們自己使用 App 時遇到問題，是不是直接在頻道回報，然後讓 Bot 自動修復就好了？能直接開 PR 自動修復，何必開 Issue 呢？

我們先從 Slack 開始，開一個專門的 issues 頻道。

那我就可以開始串接我的自動化工廠（Factory），把 Factory 串到 issues 頻道。

而且無論如何，我們都要詳細帶大家看一下這個自動化工廠，因為你可是惡名昭彰的「P-stack」發明人！有些觀眾可能還不知道什麼是 P-stack，P-stack 到底是什麼？

P-stack 是一套價值百萬美元的架構——開玩笑的，完全免費！它是一個開源外掛，將我平常進行高強度嚴謹軟體工程時所累積的技巧全面封裝，並且開源出來，讓任何人都能複用我這一套技能與工作流。我已經反覆打磨最佳化了很長時間，上個月我實際上透過 P-stack 向生產環境（Production）提交並合併了 2,500 個 PR！而且我沒有引發任何 Bug——至少我希望沒有啦！如果你還沒試過 P-stack，可以前往 Grok Bot 市集搜尋體驗。

我剛心算了一下：一個月 2,500 個 PR，相當於一天要發 83 個 PR！我們有三天，乘上三就是 250 個 PR，我覺得你這次能送更多！我們直播畫面上應該放一個「PR 計數器」！

我甚至不打算開 PR 了，我直接強制 Merge 到 main 分支！

那我們就改叫「Commit 計數器」，在畫面上放一個 Commit 計數器。

在程式碼管理與組織層面，Roshan 剛剛在 GitHub 上建立了一個全新的組織，名稱叫做 ship-by-thursday（週四前出貨），代號為 ship-by-thursday。目前裡面完全空白，沒有任何儲存庫。我們使用的 Grok Bot 也是全新開立的乾淨空間。

在組織層面，我們需要招聘虛擬員工。Grok Bot 有一個非常強大的特性：你可以建立 Grok Bot，而 Grok Bot 還能再去建立其他的 Grok Bot！也就是「機器人工廠（Bot Factory）」的概念。我們可以先在 Notion 裡撰寫一份公司新人手冊，說明組織定位、工作流程與品質標準。接著由一隻母體工廠 Bot 負責讀取這份手冊，依需求孕育並設定出負責市場研究、工程實習、日常營運的專職 Bot。所有 Bot 共享同一套知識庫，讓新加入的虛擬員工能隨時同步專案最新進度。

我們現在就來擬定招募計劃。我們會把螢幕畫面切換出來，讓大家完整看見每一個步驟的真實操作。

歡迎來到 Grok Bot 101。回顧 AI 如何重塑個人與組織的工作方式，我們經歷了三個關鍵階段：

第一個階段是純粹的對話問答（Chat）：你提問、AI 回答，這在初期的資料調研與研究中非常實用。 第二個階段是副駕駛（Copilot）：你將特定任務交給 AI，它在旁輔佐你撰寫程式碼或調整投影片。 第三個階段則是我們現在所處的時代——團隊夥伴（Teammate）：AI 開始扮演可以並肩作戰的同事，能對業務成效負責、擁有清晰職責，並在獲得信任後獨立掌管某個業務領域。

現場給出的精準定義是：「An agent with a computer（配備電腦的代理人）」。

為了實現這個願景，我們在產品設計上做出了三項關鍵決策：

第一，以「團隊夥伴」為核心架構，不採單次「臨時聊天室」。在介面左側，你可以看到依職能劃分的專屬 Bot，例如業務拓展或收件匣管家。使用者不需要為每件雜事隨手開新視窗，而是長期與固定的專職 Bot 協作。Bot 會在長期互動中記住你的習慣與風格（例如你偏好的簡報版型），數週後依然精準套用。

第二，配備獨立的虛擬電腦操作權限。市面上許多 AI 工具依賴 API 或 MCP（模型上下文協議），但真實世界的業務往往無法百分之百透過 API 搞定。Grok Bot 擁有專屬的 Linux 虛擬機器，能像真人一樣看影片、聽錄音、點擊操作 90 年代的老舊政府系統軟體。凡是人類能在電腦螢幕前完成的操作，它都能接手，從而跨越了過去「AI 只能做 90%、剩下 10% 仍需手動填補」的斷層，達成端到端的完整交付。

第三，雲端原生全天候運作。所有運算與執行皆在雲端持續運行，不佔用本機硬體資源。傳統依賴本機的工作流，一旦筆電休眠或闔上螢幕，排定在半夜的任務就會中斷；而常駐雲端的 Bot 永不中斷，能在你休息時持續推進專案。

現在，我把主持棒交給 Amrita，由她帶領大家進入實機展示。

謝謝 Roman。今天我會帶著大家與三位數位同事通力協作，分別是負責資料收集的 DataDan、負責投影片製作的 SlideSonia，以及負責對外溝通的 EmailEthan。

我們先從零開始建立 DataDan。在 Grok Bot 中建立 Bot 時，系統會根據名稱自動推測其職能。這裡我直接啟動即將於下週正式推送的雙向即時語音模式（Rock Voice），用說話的方式指派任務：

「請幫我建立一份 Google 表單，包含兩個題目。第一題：你每天喝幾杯咖啡？第二題：你在舊金山最喜歡的咖啡店是哪一家？選項請列出 Ritual、Philz、Sightglass 以及 Blue Bottle。」

系統精準完成了語音辨識與意圖轉換。接著，DataDan 開始執行任務。我們點擊右上角的連線按鈕，切換進 DataDan 專屬的虛擬電腦畫面。大家可以清楚看到，這是一台完全獨立的 Linux 虛擬機器，DataDan 正在後台自行打開瀏覽器、載入 Google 表單頁面，一步步建立題目與選項。

在此同時，我也想說明內建的安全機制。當 DataDan 準備執行特定關鍵操作時，畫面跳出了授權確認請求。這由我們的「自動審查工具（Auto review tool）」在背後把關，它內建了風險分類器，能評估該操作是否安全。使用者也可以在設定中制定自訂規則，例如「嚴禁在未經明確許可前擅自回覆郵件」或「產生簡報可直接放行不必詢問」。

趁著 DataDan 在後台處理表單，我們看看側邊欄的 SlideSonia。

在 SlideSonia 的角色描述欄裡，我預先寫入了詳盡的規範：指定簡報必須使用的字型款式、配色規範，並要求每次修改完成後必須截圖回報。

我還可以為她設定「每日例行排程（Routine）」：每天早上 9 點整，自動彙整這份簡報中所有被修改過的內容，並標註修訂者。此外，Grok Bot 支援示範教學（Teach a task）功能：我可以透過螢幕錄影親自操作示範如何為圖表添加飛入動畫，SlideSonia 觀看並解析這段錄影後，便能將這套操作提煉為一項新技能（Skill），日後隨時套用。

另一位同事 EmailEthan 則負責對外通訊。我讓 EmailEthan 閱讀我過去寄出的真實信件，學習我的用詞習慣與語氣風格。而且，不同 Bot 之間具備自主溝通機制（Bot-to-Bot Protocol）： EmailEthan 會主動傳訊息給 DataDan：「Amrita 請我處理咖啡偏好專案，請問資料準備好了嗎？」 DataDan 則回覆：「我還在整理試算表，稍後回傳。」 EmailEthan 接著轉向 SlideSonia：「請先根據目前大綱產出一份摘要簡報。」

這種跨代理人的自主協同，大幅降低了人工作為傳話筒的負擔，讓我能以經理人與督導者的視角統攬全局。

DataDan 已經把表單轉換成了 QR Code 顯示在畫面上，歡迎現場與線上觀眾拿出手機掃描填答。

（現場觀眾反應：掃描後顯示「沒有存取權限」）

大家看到了，現場出現了權限問題。身為現場工程師（Field Engineer），日常很重要的一部分就是排查問題。我現在直接向 DataDan 發送指令： 「看起來大家無法掃描，請檢查表單連結是否已設為公開存取。」

DataDan 接收到指令後，立刻切換回它的 Linux 虛擬機器，打開 Google 表單的共用設定面板，將權限調整為「任何知道連結的人皆可填答」，並重新取得公開填答連結。在與 Bot 協同除錯時，給予清晰的現象描述與正面回饋，它的修正效率會非常高。

此外，我們也可以把 DataDan、SlideSonia、EmailEthan 通通加入同一個「群組聊天室（Group Chat）」。比起逐一檢查個別 Bot 的私訊視窗，在群聊中，人類能以全景視角（Bird's-eye view）俯瞰所有代理人之間的任務分派與交接脈絡，大幅提升了管理透明度。

當賦予機器人發送信件、處理付款或與外界互動的權限時，通常企業會非常謹慎。這部分如何平衡自主性與安全性？

主要由兩道防線守護：一是底層的自動審查工具（Auto review tool），透過分類器判斷操作風險。例如在剛才建立表單時，它會主動檢查表單是否索取了受保護健康資訊（PHI）或個人身分資訊（PII）；二是自訂規則系統，你可以把邊界設定得極為嚴格。

同時，「記憶機制」扮演了關鍵角色。當 Bot 向你請示一次某類文案是否可行，只要你回覆「文案很好，往後這類郵件直接寄出」，這項偏好就會寫入它的 S3 記憶庫中。信任是隨時間累積的，不需要每次都停下來打斷工作。

未來是否能把真人也加入群聊，實現真人與機器人共同協作？

這項功能正在開發中。目前的一種成熟做法是在 Slack 中標記（@bot），多位人類同事可以在同一討論串中對同一個 Bot 提出不同維度的要求（例如一人要求開發新功能、另一人要求把關 API 效能）。未來 Grok Bot 原生也會推出真人與多 Bot 連線的協同群聊。

企業的虛擬機能否存取內部系統？如何保護憑證？

可以。Bot 運行的虛擬機器可以加入公司內部的 VPN，存取 MongoDB 或專有資料庫。針對機密憑證，我們剛剛推出了 1Password 的深度整合功能：需要輸入敏感 API 金鑰或帳密時，系統會彈出獨立的加密視窗完成驗證，憑證資料會進行嚴格加密，絕不會以明文形式暴露給外部。

總結來說，Grok Bot 具備三大核心支柱： 1. 具備虛擬電腦操作能力，能跨越 MCP 與 API 的邊界，直接駕馭任何軟體工具； 2. 具備長期記憶與示範學習能力，能勝任長期專業角色； 3. 具備多層安全審核與記憶累積機制，確保在企業環境中安全可控。

回到我們的長桌！我們非常榮幸邀請到客座嘉賓 Peter Yang（X: @petergyang）。Peter 長期深耕產品管理與創作者經濟領域。

很高興來到現場！看到你們要挑戰 72 小時從零建公司，這非常瘋狂但充滿啟發。

Peter，身為資深產品人，在如今這個充滿 AI Agent 的時代，你怎麼看待產品經理職責的轉變？

產品經理過去需要花好幾週撰寫長達數十頁的產品需求文件（PRD）。但實際上，工程師往往很少逐字閱讀那些冗長的文件。

在 SpaceX AI 的 Slack 上，我注意到 Roshan 的狀態長年寫著一句話：「為什麼今天不行？（Why not today?）」。這句話非常精準地概括了這場轉變：現在你有一個近乎魔法般的輸入框，裡面住著一位能操控電腦的智慧體。與其花時間撰寫假設性的規格書，不如直接提示 Bot 做出一份可點擊互動的原型（Clickable Prototype）。當團隊圍繞著真實的原型討論時，決策速度與溝通品質會大幅提升。

調度多個 Agent 的體感，其實非常像在玩即時戰略遊戲（RTS），比如《星海爭霸》、《世紀帝國》或《異星工廠》（Factorio）。你需要宏觀調度不同單位的職責、分配資源，並讓它們在各自的戰線上推進。很多人認為 AI 最終的介面是語音，但我認為它更像一套遊戲化的策略協同系統。

談到商業點子，我始終堅持亞馬遜的逆向工作法（Working Backwards）痛點框架：你的目標客群是誰？他們最痛的痛點是什麼？你提供的真實價值是什麼？ 創業者千萬不要自嗨去刻一個視覺漂亮的 Landing Page。人們不會只因為網頁好看就掏出信用卡，大家只願意為真正解決現實生活複雜痛點的服務付費。甚至要想一想：我們創造的這個業務，能不能連不碰程式碼、甚至連我們的父母都能一眼理解並感受其價值？

我自己的實務做法是，我為我的 Bot 設定了每週五定時主動回報的例行排程。週五下午它們會主動彙整進度並向我報告，由它們主動推動工作，而非永遠要人類去追問進度。

在離開前，我想提一個強烈的產品需求：為什麼我們現在還得在 Slack 與 Grok Bot 之間切換？我非常期待能直接在 Grok Bot 介面中實現多人與多機的無縫共處。有時只能單獨面對 Bot 會感到有些孤單，我很希望能直接在同一個空間裡同時與 Lauren、Roshan 以及數位同事們並肩對話。

這個人機深度協同的功能已經在我們的排程佇列中了，很快就會與大家見面！非常感謝 Peter 的寶貴洞見。

送走 Peter 後，我們得正式拍板我們的業務方向。我們從社群回饋中篩選了許多實體商業點子，包括鋼琴調音、看板招牌製作、硬體回收等，但這些在 72 小時內顯然難以驗證。

結合我們剛才討論的「實體體驗」與「Dogfooding」，我提議我們鎖定餐飲與在地快閃活動。我們人在舊金山，周邊有許多優秀的獨立主廚與餐飲創業者，但在經營快閃店時，他們需要處理大量的繁瑣事務：地點尋找、預約管理、菜單即時更新、客戶回饋追蹤。

我們來打造一套「在地快閃餐廳營運系統（Pop-up Restaurant OS）」，提供全套的自動化營運工具。更具野心的是：我們自己要在第三天，親自運用這套系統在舊金山街頭開辦一場真實的快閃店！

這個想法非常真實！我們不僅要寫軟體，還要親自把食物賣給真實的顧客。

在具體落地前，我們先把高層次邏輯講清楚。我使用語音輸入，把我們剛才討論的商業架構完整說給我的 Bot（Steve）聽，並在結尾加上關鍵指令：「請用你自己的話向我重述剛才的重點，確認你完全理解了。」

Steve 隨後給出了精準的重述：「你們要打造一個平台，協助在地主廚在城市中快速建立美食快閃店；同時你們將親自使用這套軟體，在舊金山實際營運一場實體快閃活動。」這樣確認上下文清楚後再動手，能避免後續大量的反覆修改。

我們開始進行分工。我在螢幕上打開 Notion，建立專案架構文件。我們暫定公司名稱為「Ship by Thursday（週四前出貨）」，直到我們想出一個更好的名字。

在職稱分工上，Roshan 擔任產品長（CPO），因為他懂所有的產品細節；Lauren 是我們技術最強的人，擔任技術長（CTO）。同時因為 Lauren 在社群上的暱稱是 potato（@poteto），我們現場用紙做了職稱立牌，封她為「技術長兼首席馬鈴薯官（Chief Potato Officer）」。

好，既然我是首席馬鈴薯官，我們的虛擬工程師 Bot 命名就必須很有馬鈴薯風格。我們在聊天室發起投票：候選名字有 Spud、Gnocchi 還有 Tater。聊天室熱烈響應，最終由「Tater」高票勝出！

我想請 Tater 開始思考我們打造這個平台的技術堆疊。我們有一些朋友來自 Brazil 和 PlanetScale，所以我們大概會想優先使用這些選項。不過至於其他的技術堆疊，目前我沒有那麼固執，給我們一些不錯的選項就行。

我倒覺得我們應該讓機器人自己挑選，然後快點把東西拼湊出來。顯然在我們尋找產品市場契合度（PMF）的同時，要避免沒完沒了的技術堆疊辯論。

沒錯！關於技術架構，我想做一項重要澄清：大家要分清「模型本體（如 Grok）」與「執行框架（Harness）」。Grok Bot 是一個非常輕量、直觀的對話與操作框架，非常適合快速探索並產出原型。但在這個階段，為了避免陷入無休止的架構辯論，我們決定前期完全不需要配置繁瑣的關係型資料庫，直接使用 Google 試算表（Google Sheet）充當輕量資料庫！

而當我們要在這裡進行更嚴肅的工程作業時，我們會連線 Cursor，把大部分的工程工作都交給 Cursor 去跑。這是因為 Cursor 的執行框架非常擅長撰寫程式碼和打造東西。所以隨著我們開始建構這個點子，大家會看到我們開始更大量地依賴 Cursor 雲端代理（Cloud Agents）。透過這種方式，我們從低擬真度（Low fidelity）走向高擬真度（High fidelity），產品逐漸演進，這完全是很正常的。

我們開始進行分工。我在螢幕上打開 Notion，建立專案架構文件。我們暫定公司名稱為「Ship by Thursday（週四前出貨）」，直到我們想出一個更好的名字。

在職稱分工上，Roshan 擔任產品長（CPO），因為他懂所有的產品細節；Lauren 是我們技術最強的人，擔任技術長（CTO）。同時因為 Lauren 在社群上的暱稱是 potato（@poteto），我們現場用紙做了職稱立牌，封她為「技術長兼首席馬鈴薯官（Chief Potato Officer）」。

好，既然我是首席馬鈴薯官，我們的虛擬工程師 Bot 命名就必須很有馬鈴薯風格。我們在聊天室發起投票：候選名字有 Spud、Gnocchi 還有 Tater。聊天室熱烈響應，最終由「Tater」高票勝出！

我想請 Tater 開始思考我們打造這個平台的技術堆疊。我們有一些朋友來自 Brazil 和 PlanetScale，所以我們大概會想優先使用這些選項。不過至於其他的技術堆疊，目前我沒有那麼固執，給我們一些不錯的選項就行。

我倒覺得我們應該讓機器人自己挑選，然後快點把東西拼湊出來。顯然在我們尋找產品市場契合度（PMF）的同時，要避免沒完沒了的技術堆疊辯論。

沒錯！關於技術架構，我想做一項重要澄清：大家要分清「模型本體（如 Grok）」與「執行框架（Harness）」。Grok Bot 是一個非常輕量、直觀的對話與操作框架，非常適合快速探索並產出原型。但在這個階段，為了避免陷入無休止的架構辯論，我們決定前期完全不需要配置繁瑣的關係型資料庫，直接使用 Notion 資料庫或試算表充當輕量資料庫！

而當我們要在這裡進行更嚴肅的工程作業時，我們會連線 Cursor，把大部分的工程工作都交給 Cursor 去跑。這是因為 Cursor 的執行框架非常擅長撰寫程式碼和打造東西。所以隨著我們開始建構這個點子，大家會看到我們開始更大量地依賴 Cursor 雲端代理（Cloud Agents）。透過這種方式，我們從低擬真度（Low fidelity）走向高擬真度（High fidelity），產品逐漸演進，這完全是很正常的。

🎬 看向門口並切換螢幕 嘿，我們的客座嘉賓 Lovell 到了！歡迎 Lovell 加入我們的實況長桌！

哈囉大家！很高興能來現場看你們發瘋。聽說你們要在 72 小時內開一家舊金山餐飲快閃店？

沒錯！我們正在討論業務核心。身為在本地商業與創投領域深耕多年的專家，我們很想聽聽你的第一手建議：如果我們真想在舊金山落地這個 Pop-up，我們最容易踩進什麼坑？

那我必須說實話了。許多工程師創業時，第一個直覺就是瘋狂寫軟體、搭後台、串 API，但小型企業（SMB）的世界完全不是這麼運作的。

一般小型企業的利潤乘數非常薄，淨利率通常只有 15% 左右，手上通常沒有太多充裕的現金流。它們失敗的第一大原因，永遠不是軟體寫得不夠好，而是「沒有分銷管道（Distribution）」。如果你沒有穩定的客流，就算後台技術再炫麗，也是開門就虧損。

現場給出的精準定義是：「在沒有付費用戶之前，過度工程化是創業最大的慢性毒藥。」

我的強烈建議是：在你們寫下第十行程式碼之前，先去找三個真實願意付錢的顧客！不管是找三家餐廳願意出租他們的閒置廚房時段，還是找到三個願意預購門票的食客。只要你們能把這個價值循環在小規模跑通，剩下的自動化才有意義。

這完全點醒了我們！我們不能坐在長桌前自嗨寫程式碼。我們需要立刻讓 Grok Bot 去做兩件事： 第一，讓 Bot 搜尋舊金山當地合適的快閃場地，過濾出聯絡信箱與租金範圍； 第二，搭建一個極簡的預約登陸頁（Landing page），直接開放社群觀眾預先登記，用真實的轉換數據來驗證需求！

太贊同了。我現在就指示我的幕僚長 Bot「Steve」更新 Notion 上的優先級清單：暫停所有複雜的後端設計，全面轉向輕量驗證！接下來正好是凌熙的工程專場，我們來看看他是如何調度 200 個雲端代理人為大型工程提速的！

大家好，感謝大家參加今天的工程專場工作坊。我是凌熙（Lingxi Li），SpaceX AI 的軟體工程師。

在過去，很多工程師對 AI 的理解還停留在編輯器裡的行內補全。但今天在 SpaceX AI，我們每天面對的是超過 200 個全天候自主運行的雲端代理人（Cloud Agents）。

在還沒有建立分層體系之前，我個人最多同時手動管理過 15 個 Cursor 雲端代理人，那已經是人類大腦注意力的絕對極限了——你必須在十幾個終端視窗與分支之間瘋狂切換，極度疲憊且極易出錯。而當規模擴大到 200 個時，你不可能再用手動方式去微觀管理它們。

我們必須將代理人徹底「組織化」。在軟體工程生命週期中，我們將代理人劃分為五大專門角色：

1. 架構師代理人（Architecture Bot）：負責監控整個儲存庫的模組邊界、API 設計規範與系統相依性，確保新提交的程式碼不破壞既有架構；
2. 特性開發代理人（Feature Bot）：專注於特定功能模組的端到端實作，從介面元件到業務邏輯撰寫；
3. 審查代理人（Review Bot）：自動執行靜態分析、型別檢查、安全性掃描，並以嚴苛標準逐行審查 Pull Request；
4. 修復代理人（Bugfix Bot）：持續監控生產環境與測試日誌，一旦捕獲異常，自動提取錯誤堆疊、建立最小重現用例，並提出修復 PR；
5. 運維代理人（Ops Bot）：負責 CI/CD 流程排查、雲端資源健康度監控與依賴套件更新。

當上百個代理人同時開工時，團隊遇到的第一個巨大障礙就是「審查疲勞（Review Fatigue）」。

一個代理人只需二十分鐘就能提出一個功能完整的 PR，單日產出的 PR 往往數以百計。如果人類工程師依然逐行去讀程式碼，人類瞬間就會淪為整個工程鏈條上最大的瓶頸。

我們的核心解法是「狀態外部化」——依託外部 Notion 看板與結構化資料庫。

代理人的對話視窗具有短暫性，但專案進度必須具備持久性。我們讓所有 Cloud Agents 定期輪詢 Notion 看板：當特性代理人領取任務時，將看板卡片移至「進行中」；完成後附上詳細實作日誌，移交給審查代理人。所有狀態流轉皆有跡可循，即使代理人中途重啟，也能立即讀取外部狀態接續上下文。

在整個代理人群體之上，我們設定了一位經理級代理人，名叫「Jenny」。

Jenny 的唯一任務就是組織協調：她每天自動組織代理人間的虛擬站會，檢查哪些 PR 卡在依賴項、哪些測試失敗未被處理，並調解代理人間的衝突。

同時，我們定下一條不可違背的鐵律：

現場給出的精準定義是：「沒有多模態憑證，就沒有程式碼自主權（No evidence, no autonomy）。」

任何代理人在提交 PR 時，嚴禁只用文字說「我已測試通過」。它必須在自己的虛擬電腦中啟動真實瀏覽器、載入頁面、模擬點擊，並把每一個關鍵步驟的截圖（Screenshot Proofs）自動貼在 PR 描述中。人類工程師只需花 3 秒鐘看一眼截圖與自動化測試報告，即可安全按下 Merge。

提問凌熙：如果代理人在處理複雜功能時，因為依賴衝突或邏輯錯誤卡住了，你們是怎麼自動止血的？

問得非常到位！這就是為什麼我們設定了嚴格的重試與升級機制（Escalation path）：當一個修復代理人嘗試三次修復同一 Bug 仍無法通過整合測試時，Jenny 會自動介入，將該任務標記為「需要人工裁決」，並在 Slack 群組中附上完整的失敗日誌與上下文摘要呼叫人類工程師。AI 負責消化 95% 的繁瑣工程，人類則集中精力在最後 5% 的邊界決策上。

🎬 回到長桌坐下 凌熙的工程分享太震撼了。現在輪到我們把這些原則落實到我們自己的快閃店專案上了。

我剛剛已經讓 Tater 在後台把我們的網域名稱買好並設定好 DNS 轉發了。為了以最快速度上線，我們直接採用 Vercel 搭配部署保護（Deployment Protection），跳過繁瑣的伺服器維運。

同時，我們的活動登陸頁（Landing Page）已經有了一個極簡的原型！我們做了一個很乾淨的表單，讓想來舊金山參加我們快閃活動的朋友可以第一時間留下聯絡信箱。我甚至讓 Grok Bot 連線了我的社群帳號，開始向本地餐飲社群發出幾封測試性的探詢郵件。

太棒了，現在我們的業務骨架已經開始轉動了！而接下來要登場的，是我們的老朋友 Kevin Niparko。他是我們產品團隊的核心，今天他要跟大家分享產品經理如何利用 Grok Bot 終結注意力危機！

哈囉大家！我是 Kevin Niparko，在 SpaceX AI 負責產品管理工作。

如果你也是一名產品經理，你一定對這種痛苦深有體會：每天早上醒來，Slack 裡有上千條未讀訊息、電子郵箱塞滿了幾百封郵件、行事曆上排滿了會議，還有 Granola 錄製的幾萬字會議逐字稿。

產品經理整天都在處理各種資訊，根本沒有時間去做真正重要的思考與產品規劃。我們處於嚴重的「注意力危機」之中。

為了解決這個難題，我們在 Grok Bot 中建立了一套名為「注意力清單（Attention List）」的專屬工作流。

它的運作機制是：讓 Grok Bot 作為你的前端防火牆，全面連線四路資訊源： 1. 內部 Slack 重點頻道； 2. 客戶與高管的電子郵件； 3. 會議錄音軟體（如 Granola）的即時轉錄； 4. Linear / Jira / GitHub 的工單動態。

現場給出的精準定義是：「注意力清單不是待辦事項，而是決策漏斗的前端過濾器。」

Grok Bot 會自動過濾掉 90% 的常規討論與碎嘴，只在 Attention List 中為你呈現三到五條真正需要你簽署、拍板或介入的關鍵卡點。每一條卡點嚴格遵循「極簡三行原則」： 第一行：發生了什麼重大事件（Facts）； 第二行：對業務或專案有何直接衝擊（Impact）； 第三行：建議你採取的具體行動選項（Options）。

現場展示一下我的兩位常駐數位同事：產品經理代理人「PM Pete」與數據分析師「Ashley」。

當我們收到用戶對某個功能的回饋調查時，Ashley 會在自己的虛擬電腦中啟動 Python 腳本，對數千份問卷進行分詞與交叉比對，產出漏斗流失率圖表；隨後 Ashley 自動將洞察移交給 PM Pete。

Pete 根據這些數據，在 5 分鐘內撰寫出一份標準的產品規格說明書（PRD），並將待開發任務分解後派發至工程團隊的看板中。

請問 Kevin，這些代理人在操作各類企業內部工具（如財務後台、用戶資料庫）時，如何保證帳號密碼與權限的安全？

非常核心的問題！在 Grok Bot Enterprise 架構下，所有帳號密碼皆由專屬的安全憑證保險箱（Secret Vault）管理。代理人只有在獲得授權的沙盒環境中才能透過內部安全通道進行授權，密碼本身對代理人的對話上下文是完全脫敏且不可逆導出的，徹底杜絕了提示詞注入導致的憑證外洩風險。

🎬 盯著螢幕 我們在長桌上的推進非常順暢。我剛剛設定好了快閃店的商品盒（Merch box）原型，同時讓 Grok Bot 連線了我的通話記錄工具 Granola。

這裡有一個極具複利效應的技巧：每次與潛在合作夥伴或餐廳老闆通完電話，Grok Bot 會自動調閱通話文字記錄，分析對方在哪些話題上有共鳴、在哪些條款上猶豫不決。這意味著每一次對外溝通都在為整間公司的知識庫積累複利。

我在這裡要提醒大家一個操作細節：當你讓代理人在虛擬電腦裡使用瀏覽器時，一定要保持上下文隔離，並且注意不要讓多隻代理人同時操作同一個未經協同的表單，否則很容易產生點擊衝突。小步快跑、隨時驗證，才是最穩健的工程心法。

接下來，我們邀請到今天的壓軸嘉賓 Shub Gaur！Shub 在新創創辦與技術架構領域經驗豐富，今天他要跟我們深入聊聊創辦人該如何駕馭這套體系。

哈囉 Matt、Lauren、Roshan！看你們在長桌前忙了一整天，真的非常過癮。

身為一名創辦人，你的時間永遠是最稀缺的資源。過去我們總說「一人公司（One-person company）」，但在實踐中，創辦人往往被招募、法規、記帳、競品追蹤等雜務淹死，根本無法維持專注。

今天透過 Grok Bot，創辦人可以擁有一隻全天候的「數位幕僚長（Chief of Staff）」。

現場給出的精準定義是：「數位幕僚長不是打雜助理，而是創辦人思維與決策槓桿的放大器。」

以我自己為例：我讓幕僚長 Bot 在背景持續監控整個產業鏈的最新專利與 GitHub 開源動態，每天早晨自動向我推播一份競品情報簡報。同時，當我要與投資人開會時，它能在一分鐘內調出該基金過去三年的所有投資案例與合夥人偏好。

創辦人不再需要為了瑣碎事務去招募一支龐大的行政團隊，你可以把精力百分之百投入到最核心的戰略與產品創新上。

非常感謝 Shub！現在時間已經來到傍晚，我們的首日直播也即將進入尾聲。讓我們坐下來盤點一下今天一整天的戰果。

回顧今天整整 8 個多小時，我們的進展不可思議： 1. 我們把團隊 Slack 頻道與 Notion 外部知識庫全面打通； 2. 搭建了 GitHub 儲存庫並連線 Cursor 雲端代理； 3. 在 Vercel 上成功部署了我們公司的第一個公開登陸頁； 4. 深度吸收了 Roman、Lingxi、Kevin 與 Shub 在 101、工程、產品與創辦人領域的實戰心法。

但是，在今天下午與多位嘉賓深入交流後，我們也發現了一個極其嚴峻的現實問題： 我們原本雄心勃勃想要在舊金山搞一個餐飲實體快閃店，但在研究了舊金山市政府的各項衛生法規、臨時營業執照審批流程與商業保險後，我們發現這背後的行政審批繁文縟節極其驚人。

在短短兩天內要合法落地一家實體餐飲快閃店，幾乎是不可能完成的任務；更重要的是，在直播上看著我們跑行政公文、打交道辦證照，對觀眾來說也極為無聊。

沒錯。我們開始捫心自問：這真的是我們這三天該攻克的核心問題嗎？

我們決定今晚不急著硬幹。今晚我們會放幾隻 Grok Bot 雲端代理人連夜推演與深入分析（Let agents cook overnight），全面評估我們是否應該在明天一早果斷轉向（Pivot），改為打造一個能讓全體線上社群觀眾都能親自參與互動的數位產品！

這正是真實創業的魅力所在：永遠擁抱變化，快速失敗，快速轉向！

感謝所有在直播間陪伴我們度過首日 8.6 小時的觀眾，也感謝在聊天室熱情互動的每一位朋友。大家別忘了前往 X 提交你們自己打造的 Grok Bot 模板。

今晚讓代理人通宵工作，我們明天早上見！