Cursor 創始人：後代碼時代，「品味」將越來越有價值

作者：Xin

作為有史以來增長最快的產品之一，Cursor 在發布僅 20 個月後就達到 1 億美元 ARR。 隨後兩年內，突破 3 億美元的 ARR，並持續引領著工程師和產品團隊開發軟件方式的變革。 截至 2025 年初，Cursor 擁有超過 36 萬付費用戶。

Michael Truell 是 Cursor 的母公司 Anysphere 的聯合創始人兼 CEO。 他和三個 MIT 同學一起創立了 Anysphere，用三個月時間推出了 Cursor。 Michael Truell 極少接受播客採訪，之前只上過 Lex Fridman Podcast。 在本期內容中，他提到對「後代碼（After code）時代」的預測、在搭建 Cursor 過程中那些反直覺的經驗、以及對工程師未來發展趨勢的看法。

本次內容來自 Lenny’s Podcast，以下是編譯全文。

人們未來會看到更接近英語句式的偽代碼。 人對軟件的各種細節都會擁有強大的控制力，有能力極快地進行修改、迭代。

「品味」的核心是對「應該構建什麼」有清晰的認知。

他們非常擅長將要交給 AI 的任務範圍限定得更小、更明確。

這些考核項目是模擬的，但能夠在兩天裡讓候選人產生真正的工作成果。 這不僅是一場「是否願意與其共事」的檢驗，對於吸引候選人也非常重要。 早期公司唯一能吸引人願意加入的地方，往往就是一支令他們覺得值得一起奮鬥的團隊。

Chatbot 式編程的主要問題在於缺乏精確性

我們之前聊到過，在後代碼時代會發生什麼。 你如何看待 Cursor 未來的發展方向？ 技術將如何從傳統代碼轉向其他形態？

你只需用最簡潔的方式向計算機描述你的意圖，由你來定義軟件應該如何工作以及如何呈現。

隨著當今技術的不斷成熟，我們相信可以開創一種全新的軟件構建方法，這種方法將比現在水平更高、更高效、更易於使用。 這一過程和今天寫軟件的方式將非常不一樣。

我想將其與未來軟件形態的幾種主流觀點進行對比，其中幾種當下流行的觀點我們並不太認同。

一種認為，未來軟件構建仍將與今天非常相似，主要依靠使用 TyPEScript、Go、C、Rust 等形式化編程語言進行文本編輯。 另一種認為，你只需在聊天機器人裡輸入指令，讓它幫你構建軟件，再隨時讓它修改。 這種聊天機器人的風格就像在和你的工程部門對話。

我們認為這兩種願景都有問題。

如果你希望人們能完全控制軟件的外觀和功能，你需要提供更精確的方式來指示它們做出想要的修改，而不是像在聊天框裡對一個機器人說「改一下我應用的這個部分」，然後整個全被刪除了。

另一方面，那種認為一切都不會改變的世界觀也是錯誤的，因為技術只會越來越強大。

你可以想像它會以一種更規範的形式存在，朝著偽代碼的方向發展。 你可以編寫軟件的邏輯、在更高層面編輯它，並輕鬆地瀏覽它。 這不會是難以理解、數以百萬行計的晦澀代碼。 相反，它將更清晰、更易於理解和定位。 我們正致力於讓複雜的符號和代碼結構演化成更易於讓人閱讀和編輯的形式。

後代碼時代，品味會越來越有價值

這很深刻，我想確保大家理解你的觀點。 你想像的轉變是人們不會再看到代碼，也不再需要以 JavaScript 或 PYTHon 的形式思考。 取而代之的是一種更抽象的表達形式，更接近英語句式的偽代碼。

我們認為它會最終發展到那個階段。 我們相信實現這個階段需要現有專業工程師的參與和推動。 未來人還是會在駕駛座上作為主導。

人對軟件的各種細節都會擁有強大的控制力，也不會輕易放棄這種控制權。 人們同時有能力極快地進行修改、迭代。 未來不會依賴那種在後台發生、很慢的、需要數週才能完成的工程。

這就引出了一個問題，對於目前的工程師，或者正在考慮進入成為工程師、設計師或產品經理的人來說，你認為在「後代碼時代」裡，哪些技能會越來越有價值？

我認為「品味」（taste）會變得越來越有價值。 人們談到軟件領域的品味時，很容易想到視覺效果，流暢的動畫、配色、UI、UX 等等。

視覺對於產品而言非常重要。 但正如之前提到的，我認為重要的另一半在於產品邏輯和運作方式。

我們有很多工具來設計視覺效果，但代碼仍是軟件運行邏輯的最佳的表達形式。 你可以用 Figma 來展示效果，或者在筆記里大致勾畫。 但只有當你擁有真正可用的原型時，邏輯才能清晰呈現。

他們需要精準地表達意圖，從幕後的「如何實現」轉向高層次的「實現什麼」、「是什麼」，這意味著「品味」在軟件開發中將更加重要。

目前在軟件工程中我們還沒有到那一步。 網上流傳著許多有趣且引人深思的段子，反映了人們過度依賴 AI 開發，軟件有明顯缺陷和功能問題。

但我相信，未來的軟件工程師可以不用像現在這樣過於注重細節控制，我們將慢慢從嚴謹細緻轉向更注重「品味」。

這讓我想到 vibe coding。 這是否類似於你所描述的不必過多考慮細節，而是更順其自然的編程方式？

我認為兩者有所關聯。 當前人們談論的 vibe coding，在我看來描述的是一種備受爭議的創作模式，即大量生成代碼，卻未能真正理解其細節。 這種模式會帶來不少問題。 如果不了解底層細節，你很快會發現自己創造的東西變得過於龐大，難以修改。

實際上我們感興趣的是：這個解決方案和 vibe coding 息息相關。

我們現在還缺乏讓「品味」真正主導軟件構建的能力。 Vibe coding 或類似模式的一個問題是，雖然你可以創造出一些東西，但很多是 AI 做出的笨拙的決策，你無法完全對其進行控制。

你提到了「品味」。 具體是指什麼？

對「應該構建什麼」有一個清晰的想法。 這個想法也能夠越來越輕鬆地轉化，這是你想創造的軟件、它看上去是這個樣子、是這樣運行的。

不像現在，你和團隊有了產品的構想、還需要一個翻譯層，需要費盡心力和勞動力，把它轉換成計算機能理解和執行的格式。

「品味」和 UI 的關係不大。 或許「品味」這個詞用得不太恰當，但其核心就是對「應該構建什麼」有正確的認知。

Cursor 的誕生源於對一個問題的探索

我想回顧一下 Cursor 的起源，很多聽眾可能還不知道它是如何誕生的。 你們正在打造史上增長速度最快的產品之一。 Cursor 正在深刻改變人們構建產品的方式，甚至正在改變整個行業。 這一切是如何開始的？ 早期發展過程中有哪些難忘的時刻？

Cursor 的誕生，源於我們對一個問題的探索，也很大程度上是我們對未來十年 AI 將如何變得更好的思考。 其中有兩個關鍵時刻。

第一個是初次使用 COPilot 的 Beta 版的時候。 這是我們第一次接觸到實用的 AI 產品，能實實在在帶來幫助，而不是華而不實的 demo。 Copilot 是我們迄今為止採用過的最有價值的開發工具之一，讓我們也很激動。

另一個是 OpENAI 等公司發布一系列關於模型 Scaling 的論文。 這些研究表明，即使沒有顛覆性的新思路，僅僅通過擴大模型規模和增加訓練數據量，AI 的能力也會越來越強。 在 2021 年底到 2022 年初，我們對 AI 產品的前景充滿信心，這項技術未來注定會走向成熟。

這讓我們想：當這項技術日益成熟，這些具體的領域在未來會發生怎樣的變化？ 最終的工作形態會是怎樣？ 我們將用來完成工作的工具將如何演變？ 模型需要達到怎樣的水平才能支持這些工作形態的變化？ 一旦模型 Scaling 和預訓練不能進一步提升了，我們又該如何繼續突破技術能力的邊界？

沒人會關注這種無聊的領域。

當時大家都認為編程很熱門、很有趣，但我們覺得已經有很多人在做了。

最初有四個月的時間，我們實際做的是一個完全不同的項目——幫助機械工程實現自動化和增強，為機械工程師搭建工具。

但一開始就遇到了問題，我和我的聯合創始人都不是機械工程師，雖然有朋友在這個領域，但我們對它極度陌生，可以說是「盲人摸象」，比如我們如何將現有的模型真正應用到機械工程中？ 我們當時的結論是，必須從零開始開發自己的模型。 這種做法非常棘手，因為網上幾乎沒有關於各類工具和零件的 3D 模型及其構建步驟的公開數據，而要從擁有這些資源的渠道獲取模型也同樣困難。

但最終我們回過神來，意識到我們對機械工程沒有很感興趣，這並不是我們願意奉獻一生的事情。

回頭看編程領域，儘管已經過去了相當一段時間，卻並未出現顯著變化。 那些在這一領域工作的人似乎與我們的想法脫節，他們對未來的發展方向，以及 AI 將如何重塑一切缺乏足夠的野心和遠見。 正是這些認識促使我們走上了構建 Cursor 的道路。

我很喜歡這樣的建議，比如去追逐那些看似無聊的行業，因為那裡競爭少，存在機會，有時候這確實可行。 但我更喜歡另一種思路——大膽追逐最熱門、最受歡迎的領域，比如 AI 編程和應用開發，結果證明這也行得通。

你們覺得現有的工具缺乏足夠的雄心或潛力，還有更多事情可以做。 我認為這是一個非常有價值的啟示。 即使某個領域看似已經太晚了，像 GitHub CoPIlot 這種產品已經存在，如果你發現現有解決方案的野心還不夠大、無法滿足你的標準，或者在方法上存在缺陷，其中仍然蘊藏著巨大的機會。 是這樣嗎？

完全認同。 我們想要實現突破性的進步，需要找到可以具體做的事情。

很多領域的天花板非常高。 放眼望去，即使是拿任何一個領域裡最好的工具來說，未來幾年中仍有大量工作有待完成。 擁有如此廣闊的空間和如此高的上限在軟件開發中是相當獨特的，至少 AI 是如此。

Cursor 從一開始就強調 Dogfooding

讓我們回到 IDE（Integrated Development EnviRONment，集成開發環境）的問題。 你們有幾種不同的路線、其它公司也都在嘗試。

一種是構建一個面向工程師的 IDE ，並在其中集成 AI 能力。 另一種是完全的 AI Agent 模式，例如像 Devin 這樣的產品。 還有一種就是專注於構建一個非常擅長編碼的模型，致力於打造最好的編碼模型。

是什麼讓你們最終決定 IDE 才是最佳路線？

那些從一開始就只專注於開發模型，或試圖實現編程的端到端自動化編程的人，他們試圖構建的東西與我們截然不同。

相比之下，他們更多地在設想一個由 AI 完成整個過程的未來，甚至由 AI 來負責所有決策。

所以一方面，我們的選擇包含了興趣驅動的成分。 另一方面，我們始終努力以非常現實的視角看待當前的技術水平。 我們對 AI 未來幾十年有的發展潛力感到無比興奮，但有時人們會因為看到 AI 在某個領域表現出色，就傾向於將這些模型擬人化，認為它們在這個領域比人類更聰明，那在另一個領域也一定會出色。

但這些模型存在巨大的問題。 我們的產品開發從一開始就強調「Dogfooding（自己使用自己的產品）」，我們自己每天大量使用 Cursor，從不希望發布任何對我們自己無用的功能。

我們認為讓人坐在「駕駛位」至關重要，AI 不可能包攬一切。

因為個人原因，我們也希望賦予用戶這種控制權。 這樣一來我們就不只是一個模型公司，也遠離了那種剝奪人們控制權的端到端產品開發思路。

至於我們選擇構建 IDE，而不是為現有的編程環境開發一個插件，是因為我們堅信編程將通過這些模型進行，並且編程方式將在未來幾年會發生巨大變化。 現有編程環境的可擴展性是如此有限，如果你認為 UI 和編程模式將發生顛覆性變化，那麼你就必須對整個應用程序擁有全面的掌控權。

我知道你們目前在做 IDE，也許這是你們的偏見，這是你們認為未來的方向。 但我很好奇，你是否認為未來很大一部分工作會由 AI 工程師在 Slack 等工具中幫你完成？ 這種方式會有一天納入 Cursor 嗎？

我認為理想狀態是你能在這些事物之間輕鬆地切換。 有時，你可能希望讓 AI 自己獨立運行一段時間；有時你會想將 AI 的工作成果拉取出來，與它高效協作。 有時或許再次讓它自主運行。

我認為你需要一個統一的環境，讓這些後台和前台形式都能運行良好。 對於後台運行，那些只需極少說明就能精準指定需求、判斷正確標準的編程任務特別合適。 修復 Bug 就是一個很好的例子，但這絕對不是編程的全部。

這種演變包括你能夠從不同界面，如 Slack 及問題追踪的系統等接管任務；你日常盯著的這塊玻璃屏幕本身也會發生巨大的變化。 我們目前把 IDE 看作構建軟件的地方。

使用 AI 最成功的用戶在技術應用上反而很保守

我認為人們在討論 Agents 和這些 AI 工程師時，沒有充分意識到的一點是，我們將很大程度上成為「工程經理」，手下管理著許多尚不那麼聰明的下屬，你必須花費大量時間進行審查、批准和具體說明需求。 你對這個問題有什麼看法？ 有沒有什麼方法可以簡化這個過程？

因為聽起來這真的很不容易，任何管理過大型團隊的人都深有體會——「這些下屬總是帶著質量參差不齊的工作反復來找我，太折磨人了。」

是啊，也許最終我們得跟所有這些 Agents 逐個進行一對一溝通。

我們觀察到那些在使用 AI 時最成功的用戶，他們在技術應用上反而比較保守。 我確實認為，目前最成功的用戶非常依賴像我們的「下一步編輯預測（Next Edit Prediction）」這樣的功能。 在他們常規的編程流程中，我們的 AI 會智能地預測下一步要執行的操作。 他們還非常擅長將要交給 AI 的任務範圍限定得更明確、更小。

考慮到你花在審查代碼上的時間成本，與 Agent 的協作主要有兩種模式。 一種是你可以在前期花大量時間來詳細說明，讓 AI 獨立工作，然後再去審查 AI 的成果。 當你完成了審查，整個任務就完成了。

另一種是，你可以將任務切分得更細。 每次只指定一小部分，讓 AI 完成，然後審查；再進一步給指令，讓 AI 繼續完成，再審查。 這就像在整個過程中實現了類似自動補全的功能。

不過，我們經常觀察到，能最出色使用這些工具的用戶依然傾向於將任務拆分，並保持任務的可管理性。

這很難得。 我想回到你們第一次構建 Cursor 的時候。 你們在什麼時候意識到它準備好了？ 什麼時候覺得該發佈出去看看會發生什麼了？

我們剛開始搭 Cursor 時，很擔心會花費過長時間開發，遲遲不能向外界發布。 Cursor 的最初版本完全是我們從零「手工打造」的。 現在我們使用 VS Code 作為基礎，就像許多瀏覽器使用 ChrOMium 作為核心一樣。

但一開始並不是這樣，我們從零開發了 Cursor 的原型，這其中包含了大量工作。 我們不得不自己開發許多現代代碼編輯器所需的功能，比如對多種編程語言的支持、代碼間的導航功能、錯誤跟踪等。 此外，還需要內置命令行，以及連接遠程服務器以查看和運行代碼的能力。

我們以閃電般的速度快速開發，完全從零開始構建了自己的編輯器，還同步開發了 AI 組件。 大約在五週後，我們已經開始完全使用自己的編輯器，徹底扔掉了之前的編輯器，轉而投入新工具的實踐中。 當我們覺得它達到一定實用性時，我們將它交給其他人試用，進行了一個非常短暫的 Beta 測試。

我們的目標是盡快將產品交到用戶手中，並在公眾反饋中快速迭代。

令我們意外的是，原本以為這款工具會在很長時間內只吸引幾百名用戶，但從一開始就有大量用戶湧入，帶來了許多反饋。 最初的用戶反饋極為寶貴，正是這些反饋促使我們決定放棄從零構建的版本，轉而基於 VS Code 開發。 從那以後，我們一直在公眾環境中不斷優化產品。

三個月推出產品一年 ARR 達一億美元

我很欣賞你對所得成績的低調。 據我所知，你們在大約一年到一年半的時間內，就將 ARR 從 0 提升至一億美元，這絕對是歷史性的成就。

你認為成功的關鍵要素是什麼？ 你剛提到自己使用自己的產品是其一。 但你們能在三個月內就推出產品太不可思議了。 這背後的秘訣是什麼？

第一個版本，也就是三個月時完成的版本並不完美。 所以我們一直有一種持續的緊迫感，總覺得還有很多地方可以做得更好。

無論 Cursor 目前取得了多大進展，我們都覺得離那個終極目標還很遙遠，總有很多事情需要去做。

很多時候，我們並沒有過分糾結於最初的發布效果，而是更關注產品的持續演進，致力於不斷改進和完善這款工具。

在那三個月之後，是否有一個轉折點，使一切開始起飛？

說實話，一開始的增長感覺相當緩慢，也許是因為我們自己有些不夠耐心。 但就整體增長速度而言，它始終不斷令我們驚訝。

我認為其中最令人意外的是，這種增長其實一直保持著穩定的指數級趨勢，每個月都保持著持續增長，雖然新版本發布或其他因素有時會加速這一進程。

當然，這種指數增長在初期感覺相當緩慢，基數也確實很低，所以一開始它並沒有真正呈現出突飛猛進的態勢。

這聽起來就像是那句「創造它，人就會隨之而來」的例子。 你們只是打造了一個自己喜歡的工具，一經發布，大家也很喜歡，才口口相傳。

是的，差不多就是這樣。 我們團隊將大部分精力投入到產品本身，沒有分心去做其他事情。 當然，我們也花時間做了很多其他重要的事情，像建立團隊、輪崗負責用戶支持等。

然而，對於很多初創公司在早期會投入精力的一些常規工作，我們「就把問題擱那兒了」，尤其是在銷售和營銷。

我們把精力都放在打磨產品上，先打造一個讓自己團隊喜歡的產品，再根據一部分核心用戶的反饋進行迭代，這聽起來或許很簡單，實際上要做好卻並不容易。

有很多方向可以探索，很多不同的產品路線。 難點之一在於保持專注，戰略性地選擇要構建的關鍵功能，並確定優先級。

另一個挑戰在於，我們所處的領域本身就代表一種全新的產品開發模式：

我們在為數百萬用戶開發產品，這要求我們在產品層面做到極致。 但產品質量的另一個重要維度，在於不斷深化科學研究與模型開發，在關鍵場景中不斷優化模型本身。 平衡這兩方面始終充滿挑戰。

最反直覺的事是沒預料到會自研模型

到目前為止，在構建 Cursor、搭建 AI 產品方面，你覺得最反直覺的事情是什麼？

對我來說最反直覺的一點，就是我們一開始完全沒預料到會自己開發模型。 當我們剛進入這一領域時，早就有公司從一開始專注於模型訓練了。 而我們計算過為訓練 GPT-4 所需的成本和資源，很清楚這不是我們有能力做到的事情。

市面上已經有很多出色的模型了，何必要費盡心力去複制別人已經做好的事情呢？ 尤其是在預訓練（Pre-training）方面，這需要讓一個對任何事情都一無所知的神經網絡學習整個互聯網。 因此，我們起初完全沒打算走這條路。 從一開始我們就很清楚，現有的模型有很多本可以做到的事情還未能實現，因為缺乏為這些模型搭建的合適的工具。 但我們還是投入了大量精力進行模型開發。

這個過程是循序漸進的。 我們最初在一個用例上嘗試訓練自己的模型，因為它使用任何主流的基礎模型都不太合適，結果很成功。 隨後我們又將這種思路推廣到另一個用例，也很不錯，之後便不斷推進。

在進行這類模型開發時，一個關鍵要點是精準地選擇目標，不去重複造輪子。 我們不碰那些頂尖基礎模型已經做得非常好的領域，而專注於它們的短板，並思考如何去補足。

很多人聽到你們擁有自己的模型時會感到驚訝。 因為當人們談論 Cursor 及這個領域的其他產品時，經常稱它們為「GPT 套殼」，認為它們只是搭建在 ChatGPT 或 Sonnet 這類模型之上的工具。 但你提到了，你們其實有自己的模型。 能聊聊這背後的技術棧嗎？

我們確實在多種場景下都會使用最主流的基礎模型。

為用戶提供 Cursor 體驗的關鍵環節，我們更多地依賴自研模型，比如一些因基礎模型的成本或速度原因無法勝任的用例。 一個例子就是自動補全。

對於不寫代碼的人來說，這一點可能不太好理解。 寫代碼是一種獨特的工作。 有時候，你未來 5 分鐘、10 分鐘、20 分鐘甚至半小時內的工作內容，完全可以通過觀察你當前的操作來預判。

和寫作對比起來，或許很多人熟悉 Gmail 的自動補全功能，以及編輯短信、郵件等文本時出現的各種自動補全提示。 但這些功能的作用有限。 因為僅通過已寫內容，往往很難推斷出你接下來要寫什麼。

但寫代碼的時候，當你修改了代碼庫的某一部分時，往往需要同步修改代碼庫的其他部分，而且這些需要修改的內容是很明顯的。

要讓模型在這個場景下表現出色，它的速度必須足夠快，能確保在 300 毫秒內給出補全結果。 成本也是一個重要因素，我們每次按鍵都要觸發成千上萬次推理，不斷更新對你下一步操作的預測。

這還涉及一個非常特殊的技術挑戰：我們需要模型不僅像處理普通文本序列那樣能補全下一個 token，而是要擅長補全一系列 diffs（代碼改動），即根據代碼庫中已發生的修改，預測接下來可能發生的增刪改動。

我們對這個任務專門進行了模型訓練，非常有效。 這一部分完全是我們自主研發，從未調用任何基礎模型。 我們沒有對這套技術進行標籤或品牌宣傳，但它是 Cursor 的核心。

我們使用自研模型的另一種場景，是用來增強像 Sonnet、Gemini 或 GPT 這類大模型的表現，尤其是在輸出和輸入。

在輸入環節，我們的模型會搜索整個代碼庫，識別出需要展示給這些大模型的相關部分。 你可以把它想像成一個專門用來在代碼庫裡查找相關內容的「迷你 Google 搜索」。

在輸出環節，我們會處理這些大模型給出的修改建議，用我們專門訓練的模型來補充完善細節。 比如高層級的邏輯設計由更先進的模型完成，它們會花費一些 token 來給出總體方向。 另外一些更小、更專業、速度極快的模型則會結合著一些推理優化技巧，將這些高層級的修改建議轉化為完整、可執行的代碼轉換。

這樣的做法大幅提升了專業化任務完成的質量，也極大地加快了反應速度。 對我們來說速度也是衡量我們產品的關鍵指標。

這很有意思。 我最近在播客裡採訪了 OpenAI 的 CPO（首席產品官）Kevin Weil，他把這稱作集成模型（ensemble of models）。

他們同樣會利用每個模型最擅長的功能。 使用更廉價的模型在成本上會極具優勢。 你們自己訓練的這些模型，是基於 LLaMA 之類的開源模型進行開發嗎？

我們在這方面非常務實，不想重複造輪子。 因此我們會從市面上最優秀的預訓練模型入手，通常是開源，有時也會與不向外界開放權重的大模型合作。 我們不太關心能否直接讀取或按行查找那些決定輸出結果的權重矩陣，而是更在意對模型進行訓練、後訓練（PoSt-train）的能力。

AI 產品的天花板就像上個世紀的個人電腦和搜索引擎

很多 AI 創業者和投資人都在思考一個問題：AI 的護城河和防禦能力在哪裡？ 定制模型似乎是建立護城河的一種方式。 在競爭對手試圖不斷推新、搶你飯碗的情況下，如何習得長期防禦能力？

我認為確實有一些傳統方法來建立用戶慣性以及護城河。 但說到底，我們必須持續努力，打造最出色的產品。

這個市場與過去的傳統軟件市場或企業市場有些不同。 和這個市場類似的一個例子是 20 世紀 90 年代末到 21 世紀初的搜索引擎。 另一個則是七八十年代到九十年代個人電腦和小型計算機的發展。

AI 產品的天花板非常高，產品快速迭代。 你可以持續地從一個聰明人每一個小時的增量價值、每一美元研發費用的增量價值中獲得巨大的產出。 這種狀態可以持續很長時間。 你永遠不會缺少要開發的新功能。

尤其在搜索領域，增加分發渠道也有助於產品的改進，因為你可以根據用戶數據和反饋來持續迭代算法和模型。 我相信這些動態變化也存在於我們所處的行業。

對我們來說，這或許是一個略帶無奈的現實。 但對整個世界而言卻是令人振奮的真相。 未來還會湧現出許多領軍產品，還有太多有意義的功能等待被創造。

我們距離五到十年後的願景還有很遠的距離，我們要做的是保持創新引擎的高速運轉。

聽起來這更像是建立一種「消費者式」的護城河。 持續提供最佳產品，讓用戶願意一直使用，而不是像 Salesforce 那樣，通過與整個公司綁定合同，讓員工不得不使用。

是的。 我認為關鍵在於如果你所處的領域很快就沒有多少有價值的東西可做了，那情況確實不太樂觀。 但如果在這個領域，大量資金投入、傑出人才的努力能持續產出價值，那麼你就能夠享受到研發上的規模效應、能夠在正確的方向上深入技術、構建壁壘。

這確實也帶有一定的消費者導向的趨勢。 但這一切的核心在於打造最優秀的產品。

這你認為未來會是一個「贏家通吃」的市場，還是會湧現出許多差異化的產品？

我認為這個市場非常巨大。 你之前提到 IDE 的情況。 有些人研究這個領域時，會回顧過去十年的 IDE 市場，然後問：「究竟有誰能靠做編輯器賺錢？」過去每個人都有自己習慣的配置。 只有一家公司通過打造出色的編輯器實現了商業化盈利，但它的規模也十分有限。

一些人因此得出結論，覺得未來也會是這樣的格局。 但我認為這種看法忽略了一件事，就是在 2010 年代，為程序員搭建編輯器的潛力是有限的。

那家靠編輯器賺錢的公司主要專注於簡化代碼庫導航、檢查錯誤、做好用的 Debugging 工具。 雖然這些功能都很有價值，但我認為為程序員、乃至更廣泛的各領域知識工作者搭建工具，其中的機會是巨大的。

這樣才能在各個知識工作領域實現更可靠、更高效的生產力提升。

我認為我們所處的市場規模非常大，遠超過去人們對開發者工具市場的認知。 未來會有各種各樣的解決方案出現，也可能會出現一家行業領導者。 可能是我們，但還有待觀察。 這家公司會創建出一個通用工具，能夠協助搭建世界上大部分的軟件，這將是一家具有時代影響力的大型企業。 但同時也會存在專注於特定細分市場、或軟件開發生命週期的特定環節的產品。

最終，編程本身可能會從傳統的正式編程語言編寫，轉向更高層次，而這類高階工具也將成為用戶購買和使用的主要對象。

很有趣的是，Microsoft 之前位於這場變革的中心，它有很棒的產品和強大的分發渠道。 你說 Copilot 讓你意識到這個領域潛力巨大，但它似乎並沒有完全贏下這個市場。 甚至有些滯後了。 你認為原因是什麼？

我認為 CoPilot 之所以未能完全達到期望，這背後有特定的歷史原因和結構性原因。

從結構性角度來看，MiCROsoft 的 Copilot 項目給我們帶來了巨大的啟發。 他們做了很多了不起的事，我們自己也是很多 Microsoft 的用戶。

但我認為這個市場對於成熟企業來說並不那麼友好。 對它們友好的市場往往是那些創新空間不大、很快就可以商業化、可以通過捆綁產品銷售來獲利的市場。

在這種市場裡，不同產品之間的 roi 差別並不大。 購買獨立的創新解決方案的意義不大，反而捆綁銷售的產品更具吸引力。

另一種對成熟企業特別有利的市場是：

但是在我們的領域，用戶可以輕鬆嘗試不同的工具，根據自己的判斷選擇哪個產品更適合自己。 這種情況對大公司不太有利，反而對那些擁有最具創新性產品的公司更友好。

至於具體的歷史原因，據我了解，最早參與 Copilot 第一版開發的團隊，他們大多數人後來去了其它公司做其它事情了。 在所有相關部門和相關人員之間協調，一起來做一個產品，確實是存在困難的。

高級工程師期望太低入門工程師期望太高

如果你能坐在每個第一次使用 Cursor 的新用戶旁邊，在他耳邊悄悄說幾句建議，幫助他們更好地使用 Cursor，你會說些什麼？

我認為目前在產品層面上，我們需要解決一個問題。

這些用戶了解 Cursor 能完成什麼程度的任務，也明白需要向它提供什麼程度的指令。 他們能理解模型的質量、局限性、能做什麼和不能做什麼。

在現有產品中，我們並沒有做好這方面的用戶教育，甚至沒有提供明確的使用指南。

為了培養這種「品味」，我有兩個建議。

你對輸出要么大失所望，要么全盤接受。 相反，我會把任務切成小塊。 你可以花同樣的時間來得到最後的結果，但要分步進行。 一次只明確少量任務、拿到一部分成果、重複這個過程，而不是試圖編寫一大段冗長的指令。 這種做法很可能會導致災難。

我會鼓勵那些習慣於現有開發流程的開發者多有些失敗經驗，也多去嘗試突破模型的上限。

他們可以在一個相對安全的環境中，比如在副業裡盡可能地利用 AI。 很多時候，我們發現有些人還沒有給 AI 一個公平的機會，並且低估了它的能力。

通過採用分解任務的方法，並主動去探索模型的邊界，在一個安全的環境中嘗試突破。 你可能會驚訝的發現在一些場景中，AI 並不像你預想的那樣會出錯。

我的理解是，要培養一種直覺，去了解模型的能力邊界、它能將一個想法推進到什麼程度，而不是僅僅按你的指示行事。 而每當有新模型發佈時，比如 GPT-4 出來的時候，你都需要重新建立這種直覺？

確實如此。 過去這幾年，這種感覺可能沒有像人們第一次接觸大模型時那樣強烈了。 但這確實是我們希望將來為用戶更好地解決的一個痛點，減輕他們的負擔。 不過，每個模型都有略微不同的怪癖和個性。

人們一直在討論，像 Cursor 這樣的工具，對入門工程師幫助更大，還是對高級工程師幫助更大？ 它們是能讓高級工程師的工作效率提升十倍，還是能讓初級工程師變得更像高級工程師？ 你覺得現在哪一類人使用 Cursor 獲益最大？

我認為兩類工程師都能獲得巨大的收益，很難說哪一類受益更多。

他們會陷入不同的「反模式」（Anti-patterns）。 初級工程師有時會過於依賴 AI，什麼都讓它去做。 但我們目前還並不具備在專業工具上、與幾十甚至上百人協同、在一個長期維護的代碼庫中端到端使用 AI 的條件。

至於高級工程師，雖然並非所有人都如此，但這些工具在公司中的採用往往會被一些極其資深的人所阻礙，比如一些開發者體驗團隊。 因為他們通常負責開發工具，來提高組織內其他工程師的生產力。

我們還看到了一些非常前沿的嘗試，有些高級工程師走在最前面，盡可能地擁抱並利用這項技術。 平均來說，高級工程師往往會低估 AI 對他們的幫助，並傾向於固守現有的工作流程。

很難斷定哪類人群受益更大。 我認為兩類工程師都會遇到各自的「反模式」，但他們都能從使用這類工具中獲得顯著的益處。

這完全有道理，就像光譜的兩端，一個期望過高，一個期望不足。 就像三隻熊的寓言。

Cursor 招聘核心是一個為期兩日的考核

在創立 Cursor 之前，你希望自己知道什麼？ 如果你能回到 Cursor 剛開始的時候，給當時的 Michael 一些建議，你會告訴他什麼？

難點在於很多寶貴的經驗是隱性的，很難用語言描述。 遺憾的是，在人類的某些領域確實需要親身失敗才能學到教訓，或者你需要向該領域的佼佼者學習。

我們在招聘上就深有體會。 事實上我們在招聘方面極為耐心。 對我們來說，無論是出於個人願景還是公司戰略，擁有一支世界一流的工程師和研究人員團隊一起打磨 Cursor 至關重要。

我們也尋找那些實事求是、適度的審慎以及坦率直言的人。 隨著公司和業務規模的不斷擴張，各種噪音會越來越多，保持清醒的頭腦格外重要。

產品之外，找到合適的人加入公司可能是我們最關注的事情，也正因為如此，我們在很長一段時間裡都沒有擴大團隊。 很多人都說招聘速度太快會出問題，但我認為我們一開始的招聘速度太慢了，我們本可以做得更好。

我們最終使用的招聘方法對我們非常有效，就是專注於尋找我們認定的世界一流的人才，有時甚至會花好幾年去招募。

我們在很多方面都積累了寶貴的經驗，比如如何判斷理想的候選人、誰能真正融入團隊、卓越的標準是什麼，以及如何與那些並未積極尋找工作的人溝通並激發他們的興趣。 為了學習做好這些，我們確實花費了不少時間。

共同創立 Anysphere 的 4 位 00 後，分別為 Aman Sanger、Arvid Lunnemark、Sualeh Asif 和 Michael Truell

對於現在正在招聘的公司來說，你有什麼經驗可以分享？ 你錯過了什麼，學到了什麼？

一開始我們過於傾向於尋找符合名校背景畫像的人才，尤其是那些在知名學術環境中取得優異成績的年輕人。

我們很幸運地在早期找到了一些非常出色的人。 他們在職場上已經非常資深，卻仍願意一起做這件事。

我們剛開始招聘時過分強調興趣和經驗。 雖然我們已經僱傭了許多優秀而有才華的年輕人，但他們和直接從舞台中央走出來的資深陣容是不一樣的。

我們對面試流程也做了升級。 我們有一套專門定制的面試題。 核心環節是讓候選人來到公司待兩天，和我們一起做一個為期兩天的考核項目。 這種方法非常有效，我們也在不斷優化它。

我們也在不斷了解候選人的興趣所在、提供有吸引力的條件，並在對方還沒有求職意向時展開對話，向他們介紹工作機會。

你有沒有特別喜歡的面試問題？

我原本以為這個為期兩天的工作考核不會適用於太多人，但它展現出了出人意料的持久的生命力。 它能讓候選人從頭到尾參與其中，就像完成一個真實項目一樣。

這些項目是固定的，但能夠讓你用兩天時間看到真實的工作成果。 而且這不會佔用團隊大量時間，你可以把原本半天或一天現場面試的時間，分散到這兩天裡，讓候選人有充足的時間完成項目。 這樣反而可以更容易規模化。

畢竟你們要待兩天，期間還得一起吃幾頓飯。

最初我們並沒有料到這個考核會延續下來，但它現在是我們招聘流程中很有價值的環節。 這對於吸引候選人也非常重要，尤其在公司初期，在產品尚未大範圍使用、質量還不夠成熟時，唯一能吸引人願意加入的點，往往就是一支令他們覺得特別、值得一起奮鬥的團隊。

兩天的時間會讓候選人有機會了解我們，甚至可以讓他們相信自己想加入我們。 這個考核帶來的效果完全超出預期。 它不算是嚴格意義上的面試問題，更像是一種前瞻性的面試模式。

這個終極面試問題，是你給他們一個任務，比如在我們的代碼庫中構建某個功能，與團隊合作編碼並發布，是像這樣嗎？

差不多是的，我們不會使用 IP，也不會將項目成果直接併入產品線，是一個模擬項目。 通常會在我們的代碼庫中安排一個真實的、為期兩天的迷你任務，他們會獨立完成端到端的工作，當然也有協作的環節。

我們是一家很注重線下協作的公司，基本在所有情況下，他們都會坐在辦公室里和我們一起完成項目。

你提到這種面試方式一直在延續，你們團隊有多大了？

我們大概有 60 人。

考慮到你們的影響力，這個規模真的不大，我以為會大很多。 我猜工程師人數最多。

我們接下來最重要的工作之一，就是組建一支更龐大、更優秀的團隊，從而持續優化產品、提升客戶服務質量。 所以我們並不打算長期保持這麼小的規模。

我們團隊人數較少的部分原因在於，公司內部的工程師、研發和設計人員佔比非常高。 許多軟件公司在擁有大約 40 名工程師時，總人數往往會超過 100 人，因為存在大量運營工作，且這類公司通常從一開始就非常依賴銷售，這需要大量的人力。

如今，我們服務於眾多市場客戶，並在此基礎上不斷擴展。 不過，我們未來還有很多工作要做。

AI 領域正經歷著翻天覆地的變化，每天都有新鮮事、有很多 neWsletter，告訴你 AI 每天都發生了什麼。 管理一家熱門的、核心的公司，你如何保持專注？ 如何幫助你的團隊心無旁騖地工作、深耕於產品，而不被這些層出不窮的新事物分心？

我認為招聘是關鍵。 重點在你能否招到態度正確的人。 我相信我們在這方面做得不錯，或許還可以做得更好。

這也是我們在公司內部更多討論的問題，招聘性格合適的人很重要。 他們不應過度關注外界認可，而更專注於打造卓越的產品、提供高質量工作，並且總體上保持頭腦冷靜，情緒不會大起大落。

招聘可以幫助我們應對許多挑戰，這也是公司上下的共識。 任何組織都需要流程、層級和諸多製度，但對於引入公司的任何組織工具而言，若想實現其預期效果，很大程度上可以通過招聘具備相應特質的人來達成。

一個例子是，我們在工程領域沒有太多流程卻依然運轉良好。 我認為我們需要增加一些流程。 但因為公司的規模小，只要招聘真正優秀的人才，就無需設置過多流程。

第一是要招聘沉著冷靜的人。 第二是要充分溝通。 第三是要做好表率。

從 2021 到 2022 年，我們一直在專注於 AI 工作。 我們目睹了各種技術和理念的重大變化。 如果你能回到 2021 年末或 2022 年初，當時有 GPT-3，而 InstructGPT 並不存在，DALL-E 和 StABle Diffusion 也尚未出現。

所有這些圖像技術的誕生、InstructGPT 的出現、GPT-4 的發布，以及各種新模型、各種不同技術、模態、視頻相關技術的湧現。 只有極少數對我們的業務產生了影響。

即使存在大量的討論，只有少數事情真正重要。 過去十年中 AI 領域也反映了這一點，學術界發表了大量關於深度學習、AI 的論文。 但令人驚嘆的是，AI 的許多進步源於一些非常簡單、優雅且經久不衰的想法。 而絕大多數提出的想法，既沒有經得起時間考驗，也未能產生顯著影響。 現在的動態與深度學習作為一個領域的發展有些相似。

對工程師的需求量只會越來越大

人們對 AI 的發展方向以及它將如何改變世界，仍然存在哪些誤解？ 或者尚未充分理解的地方？

人們仍然有些過於極端的觀點，要么認為一切都會非常快發生，要么認為這一切都是炒作和誇大。

我們正處於一場影響極為深遠的技術變革之中，其重要性將超過互聯網，也超過自計算機誕生以來我們所看到的任何技術變革。 但這場變革需要時間，它將是一個持續數十年的進程，許多不同的團隊將在推動其發展方面發揮重要作用。

要實現計算機能為我們分擔越來越多工作的未來，我們需要解決所有這些獨立的技術難題，不斷攻克。

其中一些屬於科學層面的挑戰，例如讓模型理解不同類型的數據，變得更快、更便宜、更智能，更適配我們關注的模態，並在現實世界中採取行動。

我認為這需要數十年的時間，有大量令人激動的工作需要完成。

我認為有一類團隊將會尤其重要。 這不是自吹自擂，但這些公司要專注於為特定知識工作領域實現自動化，為該領域構建底層技術且整合最佳的第三方技術。 有時也要自主研發，打造相應的產品體驗。

這類團隊的重要性不僅體現在對用戶的價值上，而是隨著規模擴大，它們將對技術進步起到關鍵推動作用。 其中最為成功的團隊將有能力構建起龐大的企業，我也期待看到其它領域湧現出更多類似的公司。

我知道你們正在招聘對「我想在這里工作並打造這類產品」有興趣的人。 你們現在正在尋找什麼樣的人？ 具體在招募哪些人或職位？ 哪些職位你們最希望盡快招到？ 如果有人對此感興趣，需要了解哪些信息？

我們團隊需要完成的事情太多了，但很多事還沒有做。 我們有很多要做的，如果你覺得我們好像並沒有正在招募某個特定的崗位，不如先來聯繫我們。 也許你能給我們帶來新的思路，讓我們意識到沒有註意到的空缺。

我認為今年最重要的兩件事，一個是打造這個領域裡最優秀的產品，第二是增長。 我們正處於搶占市場份額的階段，目前全球範圍內，幾乎所有人要么還沒有使用我們的同類工具，要么在使用發展速度較慢的別人的產品。 推動 Cursor 的增長是一個重要的目標。

我們一直在招優秀的工程師、設計師和研究人員，同時也在找其它人才。

有一種說法是 AI 將取代工程師來完成所有代碼。 但這和現實形成了鮮明對比，大家還在瘋狂招聘工程師，包括開發基礎模型的公司也是如此。 你認為是否會出現一個轉折點，對工程師的需求開始放緩？

我知道這是一個很大的問題，你是否認為所有公司對工程師的需求會越來越大？ 還是說，你認為在某個階段，會有大量 Cursor 運行起來，來完成開發工作？

我們始終認為這是一個漫長而復雜的過程，不會一步到位，直接實現那種你只需要下達指令，AI 就能完全取代工程部門的狀態。

我們非常希望推動編程的方式平穩演進，始終讓人佔據主導地位。 即便在最終狀態下，賦予人對一切的掌控權依然至關重要，而需要專業的人來決定軟件的應有的形態。 所以我認為工程師不可或缺，他們將能夠做更多的事情。

對軟件的需求是持久的。 這不是什麼新鮮事，但試想一下，構建那些看似簡單、易於定義的東西，成本和人力消耗反倒超乎想像。 至少在外行眼中，這些東西本該不難完成，而實際要做好卻很難。

我對此深有體會。 我曾經在一家生物技術公司工作，負責為其開發內部工具。 當時市面上的工具體驗極差，完全無法滿足公司的需求。 而我能夠搭建的內部工具的需求量極大，遠遠超過我個人的開發能力。

計算機本身的物理性能早已足夠強大，它理應能讓我們隨心所欲地移動或搭建任何想要的東西，但現實中卻存在太多阻礙。 對軟件的需求遠超目前的開發能力，因為開發一個簡單的生產力軟件可能需要像拍一部大片那樣昂貴的成本。 因此在遙遠的未來，對工程師的需求只會越來越大。

還有什麼我們沒有提到但你想補充的嗎？ 有什麼想留給聽眾的智慧結晶嗎？

我們一直在思考如何建立一個團隊，使其既能創造新事物，又能持續改進產品。 如果我們想取得成功，IDE 必須做出很大的改變。 它未來的形態也必須有很大不同。

如果你去看我們引以為榜樣的公司，一定能看到持續引領多次技術飛躍、不斷推動行業前沿的案例，但這樣的公司少得很。

我們一方面需要在日常工作中思考相關問題，從第一性原理的角度進行反思。 深入研究過去成功的案例也很重要，這也是我們經常思考的問題。

我注意到你身後有很多書，其中一本是關於一家老牌計算機公司的歷史，它在很多方面極具影響力，但我從來沒有聽過。 這讓我深有感觸，因為許多創新的思考往往源於對歷史的回顧，對過往成功與失敗案例的研究。

如果有人想聯繫你們或申請職位，應該如何在網上找到相關信息？ 你提到可能存在一些他們還沒意識到的崗位，他們該去哪裡了解？ 聽眾怎樣才能為你們提供幫助？

如果有人對這些崗位感興趣，在 cursor.com 上可以找到我們的產品和聯繫方式。

太好了。 Michael，非常感謝你今天的到來。