編輯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

“我們一直在構建一個能夠不斷打造下一個 iPhone 式產品的公司，因為如果我們做不到，我們就會被淘汰?！?/span>

近年以來，AI Coding 賽道火熱異常。但除了各種炫酷的編程Agent、CLI、編輯器插件的爆火背后，其實都經歷了一場又一場的流量暴漲帶來的“技術混亂”事故。

而就在這種情況下，四位麻省理工學院的畢業生打造的一款AI Codig編輯器Cursor，卻成為了有史以來增長速度最快的開發者工具之一。

近日，沉寂了已有4個月之久的 Cursor CEO, Michael Truell經過多次邀請，終于接受了a16z的采訪，出來分享了自己有關Coding賽道的發展思考。

Michael 認為，對于創業公司來說，保持專注是非常重要。而這一教訓其實也是來源于最初 Cursor for 3D 最后破產得出來的教訓：實在是折騰怕了。

我們最初真的去做了“面向機械工程的 AI + CAD”，甚至試著做自己的 CAD。事實證明這是個壞主意，創始人與賽道完全不匹配。

決定轉向編程之后，非常專注、非常求快、瘋狂疊代碼，只為了盡快把可用產品推出去。當時雖然有一點點資金，但遠遠比不上現在動輒巨額的種子輪。

那么面臨“宕機”時刻，Cursor又是怎樣及時刷新自家的基礎設施呢？

那段時間里，有人跑到 Cursor 辦公室，把一個 iPad 貼在窗戶上，上面寫著“Cursor 掛了”。

Michale并沒有回避那段早期混亂的事故，并坦承四位創始人整體這方面的經驗都不多。

一開始我們在做的那些“看起來不復雜但很容易把依賴系統壓垮”的東西，確實很快就到了規模瓶頸。比如我們用的是常規的云服務棧，但很短時間內就需要運營一套非常非常大的 Kubernetes 集群，比很多公司都大；而當時公司總共也就五個人，只能一邊踩坑一邊把它跑起來，中間當然有過一些小故障。

后來我們通過做對一些架構決策、再加上擴充團隊，才把這一關穩住。

針對大規模的問題，這四位20多歲的年輕創始人在跟供應商建聯時候也學會了“機變”，最后選擇了多云策略：

從一開始我們就比較“多云”，所以默認路徑就是異構、多提供商并行。我們用 Databricks、Snowflake；公有云上 AWS、GCP、Azure 都在用；Web 側我們也在用；數據庫用了 PlanetScale。

同一款模型的“token 配額”其實能從多家提供商拿到，市面上還有轉售商存在；把流量簽約分散到多家對我們在戰略上更有利。

這一塊更多不是靠技術巧思去攻克，而是靠關系建設。所以我們當時基本把能找到的 Sonnet token 都“打撈”了一遍。這一層面我們算是熬過來了。

除此之外，Cursor對于初創公司的人才招聘在外界也盛傳著非常有名的面試方法論：“2天試用期”。最后，一位面試候選人層提到了一個很犀利的“銜尾蛇”問題：Cursor這個產品說到底也是軟件，讓AI自動生成軟件，Cursor是不是在自己吞噬自己？Michael認為，距離“完全自動化軟件開發”距離還很遠很遠。 而且——

“我認為Coding這個行業會不斷經歷‘iPod 時刻’到‘iPhone 時刻’的循環，過去幾年已經發生了幾次，未來還會有更多?！?/span>

而 Cursor 必須致力于不斷打造下一個iPhone式產品，否則就會被淘汰。

篇幅關系，這里不再一一展開。下面是小編整理的原汁原味的采訪，希望能給各位帶來啟發。

1.Cursor For X框架：非基座模型小型實驗室

Martin： 大家都知道，Michael 是 Cursor 的 CEO，這家公司是我們見過增長最快的之一，到處能看到他們的名字，非常瘋狂。你需要不斷招聘、運營，并在混亂中保持節奏。所以我今天不想聊常規的“創業故事”，而是想聊聊你們怎么處理這股混亂，可以嗎？

Michael： 可以。

Martin： 好。那先從歷史開始。我最近見到一家創業公司，他們說：“我們是 3D 版的 Cursor?！蔽倚α?，因為 Cursor 以前其實也是做 3D 的，對吧？

Michael： 是的。

Martin： 那能講講最初的故事嗎？

Michael： 當然。公司起點可以從很早時間算起，但真正促成這家公司的是兩件事：第一，我們試用了第一批真正“有用”的 AI 產品，尤其是 GitHub Copilot——我們這個領域的 incumbent（頭部產品）。這是第一次讓我們清晰看到，AI 已經不是實驗室里的東西，而是可以在現實世界里做成真正有用的系統。

第二件讓我們興奮的是“規模定律”。我們當時看到，即便這個領域暫時沒有新點子，只要規模繼續擴大，模型就會繼續變好。這大概是 2021 年到 2022 年初。Cursor 的想法來自一次白板討論，我們當時非?？春谩癈ursor for X”這種模式：在每一個垂直領域，都將出現一家“自動化該類知識工作”的公司。它會做幾件事：為那個領域打造最強產品、定義未來知識工作的形態，憑借產品贏得分發渠道、增長、數據和資本，然后逐漸反向進入底層模型研發，把自己變成一個“非基座模型”的小型實驗室，用手里的數據推動自主性，更進一步反過來提升產品，實現飛輪。

我們當時覺得微軟會拿下“編碼”這條賽道，所以我們想挑一個更“偏門”、競爭更小的空間。當時有朋友學機械工程，我們也熟悉 CAD 系統，于是我們最初真的去做了“面向機械工程的 AI + CAD”，甚至試著做自己的 CAD。事實證明這是個壞主意，創始人與賽道完全不匹配。我們每天跟機械工程師開電話會議問他們工作流程，但我們完全無法直覺地搞懂。我甚至覺得那 6、7 個月我們應該直接去某家公司當實習生，深入了解這個行業。

最終我們放棄了，重新回到我們最熟悉也最感興趣的東西：編程。

2.為什么專注？因為被折騰怕了！

Martin： 我有個理論，想聽聽你怎么看。我覺得 Cursor 早期能跑起來，是因為你們極度專注。當時賽道上很多公司做的事情都像科幻小說：要做“會寫代碼的智能體”、要搞新模型、要重寫編輯器、要做各種新奇的東西。而你們非常專注：直接選擇 VS Code、踩在 Copilot 已經教育過市場的基礎上，讓產品變得更好、更專一。兩個問題：第一，你覺得我的觀察靠譜嗎？第二，當所有人都在“同時做所有事”時，你們是怎么堅持專注的？

Michael： 你的說法有很多事實基礎，但也需要補一句：我們公司的故事還遠未寫完。要做到現在這一步確實靠了一股順風。但回到當時，我們在 CAD 項目里吃過的苦太多了，尤其是“冷啟動”：模型完全不適合 CAD，沒有好的 3D 表示、沒有遷移學習效果、文本 LLM 也帶不動 CAD，所以我們大量時間都花在建模和數據抓取上。

我們甚至對這件事有點 PTSD（創傷式記憶），于是決定轉向編程之后，非常專注、非常求快、瘋狂疊代碼，只為了盡快把可用產品推出去。當時雖然有一點點資金，但遠遠比不上現在動輒巨額的種子輪。

我們有 4 個創始人，一邊學怎么招聘一邊往前推。競爭對手一堆：微軟、幾十家創業公司，有的從模型入手、有的想完全改變工作流，而我們只想盡快做出產品。我記得當時對我們來說最大的“鞭子”就是每月的投資人更新郵件——可能沒人看，但我們必須寫，所以必須交付。從決定轉向 Cursor，到做出一個我們自己能當日常主力用的 IDE，只用了兩周。那時甚至還沒 fork VS Code，而是從零開始寫自己的 IDE。幾周后就放到別人手上用，再過幾個月我們就發了第一版 beta，并馬上吸引到用戶，然后勢頭就起來了。

3.為什么不跟風做IDE插件、CLI？

Martin： 在你們起勢的時候，同賽道的其他團隊開始迅速“橫向擴張”：幾乎立刻做 CLI、立刻做 IntelliJ 插件，你們卻沒有。這是刻意的嗎？

Michael： 是刻意的。我們四個創始人每天一起吃早午晚三餐，永遠在討論戰略：要不要做編輯器？要做擴展嗎？要不要碰模型？要不要做新的 IDE？當時大家都覺得做一個編輯器（不論是否 fork）是非常奇怪的事，都說開發者不會換編輯器，他們太依賴自己的工具了。但我們知道這是錯的，因為我們自己就是從命令行 Vim 遷移到 VS Code——只是因為 Copilot。我們知道：只要東西更好，大家會換，只是門檻很高。我們也非常明確，未來某一天我們會觸碰“模型層”，事實證明后來這真的成為我們最重要的產品杠桿之一，但我們不想從那里開始。那樣太慢。我們只想先把產品推向世界，把模型部分延后。

Martin： 我給你講過一個你不記得的小故事。有一次你給我打電話說，你們把某家大型云服務干崩了，對方扛不住你們的規模。當時雖然只是小范圍的服務中斷，你們很快修好了。但那段時間里，有人跑到 Cursor 辦公室，把一個 iPad 貼在窗戶上，上面寫著“Cursor 掛了”。說明當時已經火到路人都會來敲窗戶。我當時挺震驚，因為那樓本身看起來很不起眼，居然都被找到。你能講講你們是怎么應對這么大的規模壓力的嗎？你們甚至已經把依賴的平臺都逼到極限了。

Michael： 這個故事已經淹沒在早期的混亂中了。早期我們遇到的最大問題就是：團隊太小，但服務增長太快。我的幾位聯合創始人都很優秀，但我們整體經驗都不算多，這一點你應該能看出來。很快我們就有大量用戶，Cursor 內部有幾套復雜系統，比如我們自己的文件同步系統，你可以把它理解成 Cursor 里同時跑著兩三套“小 Dropbox”。

另外我們還做了一個供 AI 使用的搜索引擎，看起來不復雜，但實際實現起來非常麻煩，結構設計稍微不當就會在大規模下出各種問題。

是的，一開始我們在做的那些“看起來不復雜但很容易把依賴系統壓垮”的東西，確實很快就到了規模瓶頸。比如我們用的是常規的云服務棧，但很短時間內就需要運營一套非常非常大的 Kubernetes 集群，比很多公司都大；而當時公司總共也就五個人，只能一邊踩坑一邊把它跑起來，中間當然有過一些小故障。

后來我們通過做對一些架構決策、再加上擴充團隊，才把這一關穩住。

接下來遇到的下一個大規模問題，其實是把 API 供應商本身給“壓”住了。這一塊更多不是靠技術巧思去攻克，而是靠關系建設。

你想想，在對方看來，我們就是“四個二十來歲的年輕人”，但我們的業務已經占到他們 API 收入里非常高的兩位數百分比，他們不得不據此做產能規劃，甚至做融資層面的決策來支撐底層增長。我們這邊也在邊做邊學，一方面是跟供應商建立關系，另一方面是變得更“機靈”：

同一款模型的“token 配額”其實能從多家提供商拿到，市面上還有轉售商存在；把流量簽約分散到多家對我們在戰略上更有利。

所以我們當時基本把能找到的 Sonnet token 都“打撈”了一遍。這一層面我們算是熬過來了。現在我們自己也做不少訓練，也做一部分自研推理，于是規模問題又換了個維度，我們得在這些新的環節上持續做決策。 

Martin：你覺得這條路最后會收斂到“對第三方的異構依賴”，還是會更多把東西拉回自建、自控的基礎設施上？不是只問底層模型推理，而是更廣義的基礎設施：網站、桌面應用、后端這些。 

Michael：從一開始我們就比較“多云”，所以默認路徑就是異構、多提供商并行。我們用 Databricks、Snowflake；公有云上 AWS、GCP、Azure 都在用；Web 側我們也在用；數據庫用了 PlanetScale。

早期那些“無聊的云伸縮問題”很大程度跟數據庫有關：Kubernetes 側會遇到像 CoreDNS 這類組件掛掉的問題；DB 這邊我們有一些場景對數據庫壓力特別大。通常你先把 RDS 規格加大，這招能撐很久，但終有一天會撞上天花板，然后就是“要不要分庫分片”。我們也換過 AWS 的某個聲稱“不需要你自己分片”的服務——事實證明并不是那樣。

你以為這些公有云一切盡在掌控，其實能觸達最高量級的客戶很少，他們也在邊走邊摸索。PlanetScale 在這塊幫了我們大忙，我們算是從“看似無限”走到了真正意義上的 “PlanetScale”。

Sam 在嗎？謝謝你，Sam，開發者們都很感激。總之，我們會堅持多家并行，因為不同提供商各有所長。 

4.主航道：依舊是編輯器

Martin：回到產品聚焦與擴張的取舍。你們早期的“聚焦”做得很好，但后來也拓了不少多產品線：BugBot、CLI、基礎設施改進……這些決策有多大程度是“水到渠成”，又有多大程度是你們做了明確優先級權衡？以及你們怎么分配 R&D 資源？ 

Michael：總體是很克制、很刻意的。我們會對很多想法說“不”。但向前看，我們基本確定會成為多產品公司。這里面有個很大的“AI 編碼套件”機會，我們希望在很多企業用戶那里，成為那個“AI Coding提供商”。

到目前為止，我們的楔子（突破口）還是工程師日常工作的“那塊玻璃（屏幕界面）”——也就是編輯器本身。這里能做的事還很多，這仍然是主航道、資源主要投在這兒。

同時，編輯器里工作方式的變化，會反過來影響團隊協作與流程，這既是戰略機會，也是把編輯器做好所“必須”的補位：比如代碼評審、協作支持等。我們在刻意推進這些，但也還在學習怎么把這類項目“護住”，怎么做好交叉銷售：一方面是產品增長與 PLG，把入口和按鈕擺到位；另一方面是賦能銷售團隊。我同意，很多創始人低估了從單產品到多產品在 Go-To-Market 上的復雜度，我們還在爬坡，不過目前早期結果讓人振奮。 

5.“兩天試工、覆蓋 200+ 候選人”的方法論

Martin： 想切到“人才”。你們的招聘流程是我見過更嚴格、更有體系的一種。我經常在晚上或周末幫你們跟候選人溝通，每次開聊前都會收到你們準備得非常充分的材料：進度、我們做了什么、接下來怎么推進……

能不能講講你們的招聘方式、流程、哪些有效、哪些無效？

Michael： 一個經驗就是，讓董事會成員多打電話，多到“投降”為止，充分壓榨他們的時間（笑）。

至于我們怎么思考招聘，有些地方很“正統”，但也有些做法比較特殊。

一般小公司在招最早幾位工程師時，會讓候選人先以兼職或外包方式合作，不太會走傳統的 LeetCode 流程。我們當時就是這么做的，因為這樣能直接看到“能不能合作”。但通常公司做兩三次之后就會停下。我們這邊內部嘗試砍掉很多次，我自己也嘗試砍掉，但到現在還在繼續。

我們所有加入工程團隊、設計團隊的人，都會來辦公室待兩天，做一個項目。流程完全自由，不是那種排滿白板面試的兩天，而是：給你一張桌子、一臺電腦、三個可選項目、一份凍結的代碼庫和開發環境，讓你自己去做。

這兩天有兩個作用：第一，它測試出與傳統編碼面試完全不同的能力，比如能不能在我們的代碼庫里獨立走完端到端流程、夠不夠“自驅”。我們的工程、設計、產品非常緊密，所以我們想招的是具備產品判斷力的“產品工程師”，這個方式能看到如果把你丟進真空里，你會構建什么。它還能看出在我們環境里生存所需的底層技術能力。

第二，它能看出我們是否喜歡與你共事，以及你是否喜歡和我們共事。還有一個額外好處：候選人能獲得大量關于公司的真實信息，知道第一天來上班是什么體驗。因此只要他們最終說“是”，匹配度非常高。這就是我們堅持“兩日試工”的原因，即使公司已經超過 200 人。

Martin： 但你們不會對銷售或其他崗位也這樣做吧？

Michael： 最開始其實會。比如我們招第一批銷售時，會直接把真實的線索（inbound leads）給他們，還給配額（笑）。當然會稍微結構化一點，比如做產品演示、做客戶溝通的模擬，但我們真的會給他們看真實數據、讓他們去挖。第一位銷售甚至是這樣：他來了以后我們把一切都展示給他，然后問：“你來教我們怎么做銷售?！焙髞聿怕兊酶幏?。

Martin： 好。下一件事是我想說，這波 AI 浪潮迫使我們重新思考很多構建公司的“教條”。你們特別在前沿：年輕團隊運營巨型組織，而且表現極好；你們還在瘋狂做并購。很多兩三歲的公司通常不會這么做，但你們做得很成功。愿意分享你們怎么看待并購的嗎？在 AI 之前，有句老話叫“創業公司不要收購創業公司”，但你們顯然是反例，而且不僅你們，整個行業都是。有什么經驗嗎？

Michael： 目前為止，我們的原則一直是：為了獲得最有天賦的人，可以做任何事。早期為了把前 10 個人招進來，我們干過一些夸張操作，比如有人拒絕我們，我們仍然飛到對方所在國家找他；如果他拒絕了我們飛過去的邀請，我們就編個“舊金山有場研究員晚餐你應該來”的故事，讓他六個月后再飛來，于是又能繼續聊，最后真的把他招進來，而且成為團隊里最頂尖的工程師。

這類事情確實發生過。我們一直在盡可能爭取最優秀的人才。有時這些優秀人才恰好在創業，也就自然帶來并購的機會。

向前看，我們認為 AI 領域會出現一整套可組合的產品，而把它們打包是有巨大價值的，所以我們會比一般公司更早把并購當成戰略工具，幫我們內部形成幾個 GM 式的業務線結構，并補齊一些互補產品。

每當出現一個新產品方向，我們會嘗試內部做，也會看看市場上有沒有更合適的團隊，如果創始人合適，我們很愿意一起做。

舉個例子，我們第一次正式并購的是 Supermaven。團隊只有五人，創始人 Jacob 是 TabNine 的創造者（也就是 GitHub Copilot 之前的“Copilot”），后來去 OpenAI 做研究。他在做自動補全模型，我們也在做，兩邊技術高度互補，我們長期保持關系，最后我們比較主動地把他們收進來。

6.真正自動化軟件開發還很遠

Martin： 最后一個問題。這是你們的一位候選人問的，我覺得提問方式非常巧妙。他說：Cursor 在顛覆軟件開發，但 Cursor 本身又是“用軟件寫出的”。那某種意義上，你們是不是也在“吞掉自己”？這是一個類哲學問題。我當時的回答比較 VC：“至少我們要做那個主動顛覆的人”，但這聽起來像套話。你怎么看？

Michael： 我有兩點看法。第一，盡管行業新聞很多，盡管市場需求巨大、軟件開發近幾年變化很大，但距離“真正自動化軟件開發”還有很長很長的距離。專業軟件開發里，無論團隊是幾十人還是幾萬人，效率都低得驚人。很多高層會嚴重低估我們離“極限自動化”的距離，中間還有非常漫長、非?；靵y的一段路。

第二，我認為這個行業會不斷經歷“iPod 時刻”到“iPhone 時刻”的循環，過去幾年已經發生了幾次，未來還會有更多。我們一直在構建一個能夠不斷打造下一個 iPhone 式產品的公司，因為如果我們做不到，我們就會被淘汰。這是挑戰，也是物理規律意義上讓微軟這類巨頭難以完全占據這一領域的原因之一。但確實，這是一個巨大的挑戰。

Martin： 太好了。非常感謝，也請大家為 Michael 的分享鼓掌。謝謝你的到來。

參考鏈接：https://www.youtube.com/watch?v=deMrq2uzRKA

好了，文章到這里結束了。大家如何看待AI Coding賽道的未來產品趨勢呢？