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

大家早安！我們今天在舊金山現場開播。一些比較需要手動處理的軟體工作，但不僅限於軟體，包括知識工作也是——做簡報、做設計。我認為今天最核心的訊息是：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 開始扮演可以並肩作戰的同事，能對業務成效負責、擁有清晰職責，並在獲得信任後獨立掌管某個業務領域。

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

第一，以「團隊夥伴」為核心架構，不採單次「臨時聊天室」。在介面左側，你可以看到依職能劃分的專屬 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），產品逐漸演進，這完全是很正常的。

歡迎來到工程專場。我是 Lingxi Li。在軟體工程領域，當我們談論將 AI 引入開發流程時，很多人的想像仍停留在「幫我自動補齊這行程式碼」。但在 SpaceX AI 內部，我們已經全面邁入了組織級的多代理人協同架構。

我們在團隊中部署了超過 200 個持續運行的 Cloud Agents。這五大工程代理人依據軟體工程生命週期嚴格劃分專業角色：

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

當你部署了上百個全天候運行的工程代理人時，團隊面臨的第一個真實衝擊，在於吞吐量暴增帶來的審查瓶頸。

一個工程代理人平均數十分鐘就能完成一個複雜功能的實作並提出 PR。單日之內，整個系統產生的 PR 數量可能高達數百個。如果依然仰賴人類工程師逐行審查每一行程式碼，人類立刻會成為整個系統最大的阻礙。

為了解決這個問題，我們依託外部狀態系統——Notion 狀態看板與專屬資料庫。代理人的短期記憶會隨著對話視窗結束而重置，但專案的全局進度必須保持持久。我們讓所有 Cloud Agents 定期輪詢 Notion 看板： 當一個 Feature Bot 領取任務時，它會將卡片移至「In Progress」；完成後附上詳細實作日誌，移交給 Review Bot。所有狀態的流轉皆具備嚴格的審計追蹤，確保任何代理人重啟後都能無縫接續上下文。

為了協調龐大的虛擬團隊，我們指派了一隻名為「Jenny」的經理級代理人。Jenny 的專責是組織管理：她每天自動組織代理人間的虛擬站立會議（Standup），排查相依任務的卡點，並在不同代理人發生衝突時介入調解。

同時，我們建立了一條不可妥協的硬性鐵律：沒有憑證，就沒有自主權（No evidence, no autonomy）。

任何工程代理人在提交 PR 時，絕對不允許只說一句「我已經修復了該問題」。它必須在其專屬的虛擬機器環境中啟動瀏覽器、運行專案、重現使用者流程，並將每一步的截圖作為多模態證據（Screenshot Proofs）附加在 PR 說明中。人類工程師或 Review Bot 只需檢查視覺截圖與測試報告，就能在數秒鐘內確認改動是否符合預期。

最後是成本控制（P0 Cost）。上百個代理人並行運算意味著巨大的 Token 消耗。我們為每個代理人設置了單次任務預算上限與防無限迴圈熔斷機制，確保工程自動化在高效運轉的同時維持商業合理性。

我是 Kevin Niparko，負責產品管理。在現代科技企業中，產品經理每天面臨的最大挑戰是「注意力破碎化」。

你的收件匣裡堆滿了數百封外部合作信件；Slack 裡有無數個頻道在即時跳動並標記你；日曆上排滿了接踵而至的會議；同時你還得消化來自 Granola 等會議工具的逐字紀錄。如果你試圖追蹤每一條資訊，你將徹底喪失深度思考的時間。

Grok Bot 為產品經理建構了一道堅固的「注意力防火牆」。

在我的日常工作流中，核心是「注意力清單（Attention List）」。

我指派了專屬的 PM 代理人（例如 Emily），授權它接入四大資訊來源： 1. 電子郵件（Email）：篩選重要的外部夥伴動向； 2. Slack：監控跨部門關鍵專案頻道； 3. Granola：提取各場會議的決策結論與待辦事項； 4. 行事曆（Calendar）：掌握重要日程與重要節點。

Emily 會以極其嚴苛的門檻過濾掉 90% 的日常噪音。只有當發生指標大幅波動、重要合作夥伴升級阻礙、或需要 PM 做出關鍵決策時，事項才會被列入「Attention List」。

而且，我們嚴格執行「三行原則」：每一項呈報給我的情報，文字說明不得超過三行： 第一行：發生了什麼具體事實（包含數字與變化量）； 第二行：這對當前業務造成的核心影響與潛在風險； 第三行：代理人建議採取的行動或需要我核准的選項。

透過這種方式，我每天早上只需花十分鐘審閱這份高度濃縮的清單，點擊核准或給予微調回饋，剩下的跟進工作全部交由代理人自動執行。產品經理從此得以從被動回應雜務的泥潭中解脫，全神貫注於戰略推演與核心決策。

大家好，我是 Shub Gaur。創辦早期企業時，創始團隊往往人手極度匱乏，創辦人必須同時兼顧市場調研、競品追蹤、日常營運與招聘篩選。

我向大家展示一套我個人每天依賴的創辦人例行排程（Founder Routine）：競品動態追蹤。

我設定了專屬的市場監控 Bot，定期訪問主要競爭對手的官網，特別是它們的定價頁面（Pricing Page）與發布日誌（Changelog）。Bot 會自動對比頁面 HTML 與文字的微小變動：一旦發現競品微調了計費門檻、推出了新方案、或下架了某些功能，它會立刻比對差異，並在每週一清晨產出一份競品策略情報簡報。過去需要耗費實習生數天整理的繁瑣調研，現在完全能自動持續運作。

創辦人透過調度專屬 Bot，能以一人之力形成一支功能齊全的小型組織，將個人的時間與專注力放大數倍。

第一天漫長的 9.5 小時直播即將迎來尾聲。我們來盤點今天的具體進展： 我們確定了結合數位與實體的商業模式——打造在地快閃餐廳營運系統，並將親自營運一場實體快閃店； 我們在 GitHub 上建立了全新的 ship-by-thursday 組織，程式碼庫已經就位； 我們完成了初始的原型登陸頁面設計，確立了以前端結合 Google 試算表作為輕量資料庫的技術棧； 我們建立了完整的虛擬團隊分工：DataDan 負責資料與調研、SlideSonia 負責視覺展示、EmailEthan 負責溝通外展，以及工程師 Tater 負責系統構建。

回顧今天整場實作，我們得到了一套極具啟發性的人機協同實踐方法。高效協作的關鍵在於建立清晰節奏： 1. 把真實工作說清楚：清楚定義當前業務的目標與邊界； 2. 建立具備明確職責的數位同事：設定清晰角色與跑道，而非隨手開臨時對話視窗； 3. 給予精簡必要的上下文（Context）：避免資訊過載，提供關鍵背景； 4. 要求 Bot 用自己的話重述確認理解：確保人機理解完全一致； 5. 交付具體真實的單項工作：讓它實際動手執行； 6. 檢驗成果與截圖憑證（Result + Proof）：堅持以多模態事實作為驗收標準； 7. 介入修正並固化為技能（Skill）：透過反覆微調建立長期記憶，將成功路徑封裝為可重複調用的常規能力。

正如現場評論員 Michael Heredia 所精闢指出的：「複製回饋迴路，而非複製人頭數量（Copy the feedback loop. Do not copy the headcount.）。」 關鍵在於人機之間能否建立起可驗證、可信任、可持續學習的高效回饋迴路。

今天的第一步走得非常扎實。明天同一時間，我們將正式進入系統開發、連接真實金流、並展開舊金山快閃店的線下場地籌備。感謝所有陪伴我們度過首日 9.5 小時的觀眾，我們明天見！