一個AI原型產品在一個月催生出來，是什麼概念？
Grok Bot從第一行程式碼寫到內部可用的原型，大約一個月；接著三周內部測試，然後公開測試版上線；一檔Podcast錄音時，距離產品公開上線約三周（節目於9月8日播出）。換言之，從零到公開約七周，而且截至錄音時，產品仍在測試階段。
這種光速發布的節奏，就是Cursor不容忽視的實力。
代表Cursor受訪的Roman Ugarte，是Cursor第15號員工，過去兩年負責成長業務，看著公司從15人擴張到超過1,000人。Cursor後來併入SpaceXAI，他轉任Grok Bot產品負責人。主持人Lenny Rachitsky是矽谷知名產品電子報作者，訪談開頭就自承是重度用戶，一天用上百次、養了15個bot。
Roman對Grok Bot的定義是「一群幫你工作、也幫你生活的AI同事」，每個bot有自己的雲端電腦，能登入你平常用的工具，把整件事做完再回來找你。
以下訪談節錄只談一件事：一個手上有現成產品、基建、用戶的團隊，為什麼選了一條看起來最繞遠的路。
決策一：不做進Cursor
這個決策在當時看起來未必明智，Roman自己也這麼說。以OpenAI與Anthropic為例，它們都將程式開發代理的能力延伸至一般知識工作，並在既有產品裡長出新模組。Cursor的條件甚至更好，用戶早就拿它做非程式任務，雲端代理基建現成。
但團隊沒這麼做，理由有三層。
第一，程式開發工具對非技術用戶有威嚇感，光是介面就把人擋在門外。第二，Cursor對非工程背景的同事來說就是工程師的東西，品牌聯想擺脫不掉。第三，也是Roman講得最重的一點：把多種工作形態塞進同一個介面，用戶感受到的是「三種願景共用一個螢幕」，矽谷慣稱「把組織圖直接出貨給用戶」。
代價是放棄現成分發，亦即用戶想用，就得多下載一個App，但換來的是控制App內的每一個像素，可以把「知識工作該長什麼樣」重現的更淋漓盡致。
決策二：堅持獨立小團隊
Roman對「小團隊」的描述是字面意義的隔離：一小群人坐在辦公室另一個區域，用私人Slack頻道溝通，與公司其他部分切開。
為什麼要隔離？他的解釋是，這個產品每天都要做大量「微決策」，其中不少與過去做程式工具的直覺相反。人一多，或者一開始就規畫6到12個月的願景，這些決策會被討論拖住，「我們根本不會走到現在這個位置」。
原型做完先在SpaceXAI全員大會上亮相，開放全公司使用。結果是原本每天用聊天介面工作的人，把日常代理任務整批搬了過來，團隊才切換到「準備面向全世界」的模式。
決策三：全雲端，每個bot自己一台電腦
Lenny在推特上讚美Grok Bot後，收到最多的反問是：這些事Codex、Cowork不是都能做？Roman的回答是兩個早期決策，他承認當時看不出重要性，事後看卻是產品能「就這樣運作」的關鍵。
第一個是用戶永遠不該去想「這個流程跑在本機還是雲端」。 我的電腦要不要開著？從手機發任務，是不是得連回家裡的電腦？Grok Bot的解法是一律放在雲端，讓bot成為一個持續存在、狀態一致、與你的裝置分離的實體。
第二個更進一步：每個bot都要有自己的電腦。理由一是務實的，業務團隊用的很多工具沒有好用的API或MCP（讓AI直接串接軟體的介面標準），人類做這些工作靠的是點螢幕、打字，bot也該有這種基本能力。
理由二是一個類比：你請了一名超級聰明的新同事，卻要他第一天沒有自己的筆電，坐你旁邊共用一台，互相看得到彼此的帳號密碼。「人類團隊不這樣運作，有很好的理由；AI同事也需要一套類似的到職方式。」
Roman沒有把這些說成天才之舉。他點名OpenClaw這類個人代理工具已經先驗證了「給AI工具存取權」與「把AI當同事」兩件事，Grok Bot做的是產品化：拿掉「家裡一台Mac mini加VPN」這種撐不到百萬用戶的設定，也把skills、斜線指令這類進階概念藏到背景。
決策四：核心成員親手onboard兩三百人
公開上線前，核心團隊花了大約兩周，一場一場通話，親手onboard兩到三百名早期用戶，Lenny本人也是其中之一。Roman說前幾場相當痛苦，電腦轉不起來、用戶一頭霧水，團隊就在線上乾坐20分鐘。但正因為核心成員在場，每一次卡關都變成隔天必須修掉的問題。
業務是內部積極使用bot的團隊之一，部分工具缺乏完善的API或MCP支援，過去交給其他AI工具常在某個環節卡住。Grok Bot能跑完，靠的是團隊把「滑鼠精度不夠，點不到Salesforce儀表板上的某個位置」這種具體案例帶回基建組修。修完隔天，失敗了七天的流程就通了。
還有一個團隊刻意不出手的觀察。內部推出後的頭一兩周，多數人養5到10個bot，每個負責一條工作線。到第二周末，Slack上開始有人「升職」表現最好的bot當幕僚長，之後主要只跟它講話，由它把任務派給其他bot。團隊注意到了，但onboarding時刻意不教，用Roman的話說是「不想引導特定用法」。
結果，不少外部用戶自己走到同一個用法，產品這才稍微往「幕僚長」的方向推。
決策五：上線前反向出貨，砍到只剩用戶需要看的
問Roman內部測試那三周改變最大的是什麼，他的回答是「我們拿掉了很多東西」。原型階段塞了不少實驗功能，也把開發者用的可視化工具直接做在產品裡，模型的內部思考、它存了哪些記憶，全都攤在介面上。這些對除錯有用，對用戶則是噪音。
砍功能的判準是一個內部問題：這項功能的發布推文會怎麼寫？寫不出讓用戶有感的推文，可能就不該做。 Roman還把句型從「Grok Bot新增了……」改成「Grok Bot現在能……」，前者的下一句通常是新按鈕、新下拉選單，後者逼你想的是能力，而能力往往不需要像素。
他舉的例子是自動化：競品要用戶到側欄按加號、選觸發條件、選動作；Grok Bot只要你跟bot說「每天早上八點提醒我」。截至錄音時，平台上99%的自動化都是這樣建立的。
同一個邏輯也用在最受爭議的設計上：Grok Bot不逐項顯示工具呼叫與操作細節，只會適時回報進度並顯示活動狀態。Roman的理由是你不會要求人類同事逐秒回報按了什麼鍵。早期用戶確實給了回饋，但要的是「想看bot的待辦清單和排序」，沒有人想要那一長串思考鏈文字。
五個決策，其實是同一個問題
把五個決策攤開來看，答案都來自同一個提問。
Roman說團隊內部叫它colleague-pilled（同事腦）：產品爭論兩邊都有道理時，退一步問，如果這是一名人類同事，你會希望他怎麼做？新同事不會跟你共用筆電，所以每個bot有自己的電腦；你不會要求同事逐秒回報按了什麼鍵，所以介面不攤開工具呼叫；同事該有自己的工作環境，所以Grok Bot不做進Cursor。
上述問題都不需要是天才才答得出來，難的是每天做這些微決策時，不被既有產品的慣性拉回去。這也是隔離小團隊真正的用處。
Roman指出，Cursor從沒有先畫策略圖再倒推產品，只是反覆問「三個月後模型能做到的事，能不能現在就拉到用戶眼前」，做到了就刪掉那層工程，再追下一個。他預期Grok Bot也會走同一條路，這一版讓它成功的東西，之後會被自己的團隊一件件拆掉。
主持人Lenny說一年後回頭看這段對話會很有意思，那時就會有答案了。
延伸閱讀：
ChatGPT指令大全！復古海報風、風景照變紀念徽章、模擬80年代的你⋯130組提示詞一次整理
GPT-6 Astra變強後，Skill檔反而該大掃除！Codex工程師點名5種舊指令拖累效率
資料來源：Lenny's Podcast《How we built Grok Bot in a month》
本文初稿為AI編撰，整理．編輯/ 李先泰
