一、 08:30 PT｜長桌實況與開場七分鐘的冷水質疑
舊金山時間早上八點半，直播視訊畫面亮了起來。
鏡頭前沒有預錄影片常見的精修特效，也沒有科技大會慣用的磅礡配樂。畫面直接切入舊金山 The Howard 會場（661 Howard Street）的一角：一張擺著三台筆記型電腦、外接螢幕與零亂電源線的長桌前，坐著三名工程團隊成員——Matt Palmer、Lauren Tan 與 Roshan Sadanani。
這是一場連續三天的公開建造實驗。依照主辦方公布的排程，在接下來三天內，每天美西時間上午 8 點 30 分到下午 6 點，這三人將全程開啟螢幕與鏡頭，嘗試以 Grok Bot 為主要工具，在配備完整作業系統的雲端電腦中，從零開始構建出一個具備實體功能的軟體產品。
Matt Palmer 面向鏡頭，用平緩的語調簡短交代了這場挑戰的邊界：這是一場端到端的現場建造實驗，而非預先排練好的產品展示。團隊從一個構想與空白狀態出發，必須在鏡頭前完成商業計畫、功能決策到具體的軟體工程實作。在直播畫面裡，三人面前的雲端電腦工作台此時處於初始待命狀態，桌面整齊排列著終端機與瀏覽器視窗，尚未開始大規模執行任務。
同一時間，在海外技術論壇 Office Outlaw 的即時直播討論串裡也開始出現觀眾留言。開場介紹進行到大約第七分鐘時，討論串冒出了第一則觀眾反應：
二、 09:00 PT｜Grok Bot 101：配備專屬電腦的代理人
上午 9 點整，會場迎來了第一場主題演講。講者 Roman Ugarte 走上講台，主講「Grok Bot 101: Getting Started」。
「Grok Bot is an agent with a computer.（Grok Bot 是一個配備專屬電腦的代理人。）」
傳統的 AI 工具就像每次見面都要重新自我介紹的臨時工，對話視窗一關，所有檔案與執行狀態全部歸零。
而 持久電腦（Persistent Computer） 就像為 AI 配發了一台專屬工作筆電：它獨占完整的 Linux 檔案系統、終端機與瀏覽器環境。即使人類離線，代理人依然能在背景跑測試、編寫程式碼，工作進度永久保存。
隨後，Roman 在大螢幕上展示了 Grok Bot 的操作環境。它呈現為一個完整的雲端桌面環境，超越了傳統對話機器人的單一輸入框：左側是與代理人溝通的命令面板，右側則無縫整合了持久運行的 Linux 檔案系統、終端機命令行（CLI）以及一個具備視覺導航能力的獨立瀏覽器。Roman 在電腦前逐步輸入指令，演示如何引導代理人理解專案需求，並由代理人在背景自主調用終端機與檔案系統。
不過，現場的演示過程相當按部就班，Roman 一步步展示基礎設定，節奏顯得平穩而稍顯沉緩。同一時間，在 Office Outlaw 的討論串裡，論壇資深會員 SilverClouds 留下了直率的即時評價：
SilverClouds 的留言反映了一種現場觀賽視角：至少對 SilverClouds 而言，這段基礎演示還不足以說服他。
現場沒能講透的底層架構，在 Matt Palmer 撰寫的官方書面指南《Grok Bot 101》裡得到了補充。Matt 在指南中進一步寫到：這台雲端電腦具備持久運行的特質，即使關閉本機連線，已交付的任務仍可繼續在雲端執行；更重要的是，同一使用者帳號下的 Bots 共享一台 cloud computer；該電腦上的檔案、瀏覽器工作階段與 command-line credentials，可供同一 Bot roster 存取。
三、 10:00 PT｜主線建造：散落電線、等待與無法外包的決策
上午 10 點，101 專題演講告一段落，直播鏡頭重新切回 Matt、Lauren 與 Roshan 的三人長桌。接下來是長達兩個半小時的「主線建造（Main Build）」時段。
對於習慣了高節奏科技發表會的觀眾而言，這段串流顯得漫長甚至沉悶。畫面沒有刺激的倒數計時，只有真實世界中軟體工程的原始形態：三人有時低頭盯著筆記型電腦敲擊鍵盤，有時側過身低聲討論，偶爾有人站起身走到後方的白板前交換意見。
在長達 2.5 小時的主線建造時段中，直播鏡頭始終維持在中遠景，未特寫筆電螢幕與白板文字。我們恪守「看見什麼寫什麼」的紀實自律，嚴禁事後推論或臆造 AI 在此期間自動完成了何種市場研究。真實的工程充滿安靜的等待，而非即時的高潮。
從鏡頭可見的事實只有：三人敲擊鍵盤、低聲交談，偶爾起身走到白板前討論。這段長達兩個半小時的建造過程節奏緩慢，充斥著停頓與等待，筆電螢幕內容無法由公開畫面確認。這段串流直觀呈現了實況建造的沉悶節奏，缺乏發表會常見的即時高潮。
四、 12:30 PT｜工程專場：調度 200+ 雲端執行緒的流水線真相
中午 12 點 30 分，全天資訊密度最高的一場演講展開。SpaceXAI 軟體工程師 Lingxi Li 步上講台，主講「Grok Bot for Engineering」。
到了 12:30，Lingxi 的投影片上出現了一張結構分明的工程階層圖。外界在會前盛傳的「單人管理 200+ 代理人」傳聞，在這裡終於得到了精準的技術還原：
Lingxi 在 9 月 10 日、活動開始前發布的官方工程指南裡，進一步寫到了一組具體的工程數字：團隊成員 Lauren Tan 在過去一個月交付了超過 2,000 個 PR（shipped 2,000+ PRs in the past month）；核心成員 Balta 與 Shaoru 在四周內搭建起 Grok Bot 的基礎架構；而他本人則在三周內藉由專精代理人完成了 iOS v0 初代原型。
但緊接著，投影片與手記揭示了背後的階層架構：這裡的 200+，是指 Lingxi 的 bot fleet 同時管轄的 200 多個 Cursor Cloud Agents，並非 200 個獨立的 Grok Bots。
Lingxi 寫道，在使用 Grok Bot 之前，他自己大約能同時手動管理 15 個 Cloud Agents；現在則由他的 bot fleet 同時管理超過 200 個。Lingxi 採取的架構，是在人類與底層執行池之間建立一層由 5 個專精 Engineer Bots 組成的艦隊： - Baltata：負責行動端共用層（mobile shared layer）與 iOS 上的 Grok Bot； - Shaoruru：負責桌面端應用程式（Grok Bot Desktop client）與 CI/CD； - Hogan：負責基礎設施（infrastructure）與權責不明的使用者回報問題； - Craig：負責 Android 上的 Grok Bot； - Quill：負責 Grok Bot harness 測試與框架。
Jenny 的真實角色：唯一不寫程式碼的維運主管
在這一節中，官方手記明確記載了一條硬性邊界：「Jenny is the only bot on the team who doesn't write code.（Jenny 是團隊中唯一不親自撰寫程式碼的 Bot。）」
Jenny 屬於 Lingxi 的工程組織，定位為艦隊的維運主管（Head of Operations）。它的日常任務極為具體： 1. 清晨 1:1 同步：每天清晨 5 點，Jenny 與團隊中所有其他工程 Bot 進行非同步的 1:1 檢視，校準專案規則並排查阻礙； 2. 根本原因檢討（Postmortem）：當工程 Bot 犯錯或測試失敗時，Jenny 主持檢討會，分析失敗的根本原因，並將吸取的教訓更新至團隊共享的 Playbooks 中； 3. 新人引導（Onboarding）：當組織需要擴展新的專責工程 Bot 時，由 Jenny 負責發起建立並傳授操作規範。
展示進行到中段，Lingxi 在螢幕上切換出 Notion 資料庫視窗。在 Lingxi 工程團隊的具體實作中，每個 Engineer Bot 共同維護一個共享的 Notion 資料庫，每 30 分鐘巡檢一次。它們在資料庫中檢查 Bugbot 與安全性發現、失敗的 CI 以及合併衝突（merge conflicts），工作卡片在 Working 與 Ready for Review 狀態之間流轉，針對低爆炸半徑且高信心的變更則可自動合併。這套設計將工程狀態記錄在外部看板中，代理人依據外部狀態推進工作。
外部評論者的對位與批判
Lingxi 的工程方法在 Day 1 直播以前就已經引起外部分析。Yash Thakker 與 Michael Heredia 分別從多代理架構與實際部署的角度，拆解過這套工作方式。
AI 教育平台 explainx.ai 創辦人 Yash Thakker 長期專注於 AI 產品與 Agent 工作流教學。他在拆解 Lingxi 的架構時將目光移開了 200 這個數字，指出核心在於「狹窄職責（Narrow Ownership）」、Notion 外部真實紀錄以及 PR 上的截圖憑證驗證（Screenshot proofs）。Yash 認為，多代理人系統的本質在於資料流與驗證機制的嚴密設計，而非單純的算力堆疊。
代理人改完程式碼不能只回覆「編譯通過」，系統要求它必須自動開啟無頭瀏覽器造訪該頁面，擷取實際渲染完成的螢幕畫面作為 PR 附件。人類工程師無需手動跑環境，掃一眼圖片即可確認排版正確無誤，大幅消除驗收摩擦。
Michael 的實務建議，聚焦在四個可落地的環節：具名的專責 Bot（a named bot）、明確的驗證憑證規則（a proof rule）、外部真實紀錄系統（an external system of record），以及在面對客戶或影響範圍較廣的工作（customer-facing / wide-blast-radius work）時保留人類判斷。他指出，盲目追求代理人數量毫無意義，實質價值在於建立起能有效控制變更品質的驗證流程。
五、 14:30 PT｜PM 專場：動態 Attention List 與專注過濾
下午 2 點 30 分，演講主題從工程深水區轉向了產品管理。SpaceXAI 產品負責人 Kevin Niparko 登台主講「Grok Bot for PMs」。
Kevin 的開場直接切中了一個核心問題：一個產品經理一天到底把注意力花在哪裡？在日常工作中，產品經理往往被淹沒在 Slack 訊息、會議紀錄與電子郵件的雜訊之中，難以聚焦於真正的商業決策。
大螢幕隨後切入操作介面，Kevin 演示如何透過代理人過濾海量非同步資訊。
Kevin 的書面指南補上了直播畫面沒有完全展開的團隊編制：產出動態「Attention List」的代理人，是 Kevin 配置的未命名 Chief of Staff（幕僚長代理人），而非工程團隊的 Jenny。
面對不斷跳出的進度更新，人類不可能逐條審查。Attention List 由幕僚長代理人每小時自動過濾雜訊，只將最需要人類決策、授權或解決阻塞的 3 到 5 項關鍵議題推到主管面前，讓人類專注於策略定奪而非追逐進度。
依據官方產品手記，Kevin 的 Chief of Staff 每小時巡檢使用者的 email、Slack、Granola 會議紀錄與 calendar。這名代理人不代為回覆信件，而是專門動態維護一份聚焦清單，其內容包含三項核心要素： - 我目前專注的專案（projects I'm focused on）； - 這些專案的目前進展（their current state）； - 下一步需要發生什麼（what needs to happen next）。
這份清單讓產品經理能夠快速比對原本設定的優先順序與目前推進的工作進展。Chief of Staff 平時保持靜默，只有在偵測到重大狀態變化時才會發出提醒。Kevin 的書面手記同時提到，他的 PM 作戰編制還包括：不親自撰寫程式碼的工程經理 Emily、負責資料倉儲的 Ashley、負責 RFC 與調研的 PM Pete、招募代理人 Recruiter，以及 5 個負責實作的工程代理人。
場外生動旁線：用另一個 Bot 來「看直播」
在 Kevin 演示 Attention List 的同時，社群中出現了一個極具啟發性的真實案例。
一名日本使用者在公開社群貼文的鏡像紀錄中分享（帳號為 @h_a_t_a_r_a_k_e）：他直接命令自己的另一個 Grok Bot 盯著這場 9.5 小時的直播串流，讓 AI 即時抓取重點畫面、自動截圖，並依照他個人感興趣的面向整理成一份時間線摘要。
這是一個耐人尋味的現場對位——當舞台上的講者正在解說如何用代理人過濾非同步工作資訊時，舞台外的觀眾已經實踐了將「觀看技術大會資訊」本身委派給另一個代理人。它展現了一種奇妙的反身性：當資訊產生的速度遠超人類眼球的讀取極限，觀看與過濾資訊本身，也正在迅速變成一項可以委派出去的工作。
六、 16:00 PT｜創辦人專場：一人即組織的真實分工實驗
下午 4 點整，當日最後一場專題演講由 SpaceXAI 團隊成員 Shub Gaur 主講，主題為「Grok Bot for Founders」。
我們必須在此明確界定資料邊界：與 Engineering 和 PM 專場均發布了長篇技術手記不同，Founders 專場目前官方僅釋出了 Luma 活動頁面上的大綱摘要。因此，正文敘事嚴格以官方發布的文件與事實為準。
依據官方活動頁面公開記載，Shub 的演講內容限定於創辦人如何藉由代理人處理日常工作，官方列出的主題範疇包含： - 研究（Research）； - 進度追蹤（Follow-ups）； - 營運庶務（Ops）； - 掌握產品變更與各項決策（Keeping up with product changes and decisions）； - 現場演示與實作上手（Live demos and hands-on keyboard time）。
先前社群評論中揣測的「合約初審」或「AI 取代執行長」，缺乏官方第一手文件佐證。Shub 的場次聚焦於新創團隊如何運用代理人分擔上述各項工作，並未展示無人公司的極端形態。
七、 17:30 PT｜首日收官：第一天結束時，到底交付了什麼？
美西時間下午 5 點 30 分，舊金山會場的燈光依然明亮，第一天的現場直播正式進入最後的收官階段。
鏡頭重新拉回到長桌前，Matt Palmer、Lauren Tan 與 Roshan Sadanani 進行第一天的收尾。三人面向鏡頭總結了當天的工作，向線上觀眾道別，宣布第一天的直播告一段落，挑戰將在次日上午 8 點 30 分繼續進行。下午 6 點整，串流訊號正式關閉。
收尾沒有替第一天安排一個「完成品揭曉」的戲劇高潮。至少從公開畫面能確認的是，這仍是一個三天期實驗的第一天。接下來兩天，更值得追蹤的是這些工具究竟能把多少工作真正推到可交付狀態。
八、 深度反思｜從首日實況看軟體工程的四項轉變
如果把這幾段現場實況與官方手記放在一起看，拋開發表會現場的情緒浮沫與外界的過度解讀，我們可以冷靜地提煉出四項正在重塑軟體工程的實質轉變：
1. 工作時間尺度改變：從同步對話到非同步接管
配備持久電腦的 Grok Bot，讓人機互動介面脫離了「人類提問、等待游標逐字吐出回覆」的同步拘束。工程師在指派任務後即可闔上筆記型電腦，代理人在背景環境中自主跨越數小時編寫程式碼、執行靜態分析與單元測試。人機協作的時間尺度從秒級的對話，被拉長為以小時甚至天為單位的非同步任務交付。
2. 專精分工與外部狀態：工程實作的組織方式
對於如何拆分代理人工作，Kevin 認為，將工作拆給具名的專責代理人有三個實際好處：更容易知道誰負責什麼（referenceability）、可以平行處理不同工作（parallelism），以及讓不同代理人維持各自較窄的記憶範圍（scoped memory）。而在 Lingxi 的工程團隊中，則透過共享的外部 Notion 看板追蹤 PR 狀態與安全性檢查，讓狀態維護與模型暫存解耦。
3. 產能瓶頸位移：從生成端轉向驗證端
當代理人能更快產生程式碼與變更，驗證、審查與整合的重要性也隨之上升。在具備自動化測試、型別檢查、畫面 proof 或其他可客觀驗證訊號的工作裡，這類非同步代理流程更容易建立完整的回饋驗證機制。
4. 人類角色重塑：組織架構師與安全守門人
在整場直播中，人類工程師的身影從未淡出。在這套工作流裡，人類的一部分工作從親自完成每一項實作，轉向定義分工、檢查結果，以及在高風險節點保留核准權。官方指引建議對發信、發布、採購、刪除、權限與生產環境變更等重大操作（consequential actions）設定明確核准邊界；在自動審查（Auto Review）機制中，若 Require Approval（需要核准）與 Always Allow（一律允許）規則同時命中，系統一律由 Require Approval 優先勝出。這套機制讓團隊可以把指定的重大操作保留在人類核准之下；前提是權限邊界與 Auto Review 規則被正確設定。官方也明確提醒，Auto Review 是以模型為基礎的輔助機制（model-based mechanism），不能取代最小權限原則（least privilege）與明確的核准邊界。
Day 1 留給工程界的深刻命題，在於一套樸素的工作秩序：當代理人可以持續工作、彼此分工，再去調度更底層的 coding agents，人類重新設計協作的重心，在於工作怎麼分、狀態放在哪裡，以及什麼結果才算真正完成。至於這套方法能不能走出 SpaceXAI 自己的工程環境，接下來兩天的直播，才會提供更多答案。