Cursor創始團隊最新訪談：如果Github整合o1，Cursor可能要倒閉了

機器之心報導

編輯：佳琪、蛋醬

最近一段時間，AI 編程工具 Cursor 火遍全球，風頭一時無兩。

Cursor 是一款基於 VS Code 的代碼編輯器，它為 AI 輔助編程添加了許多強大的功能，吸引了編程界和人工智能界的關注和興奮。

近日，知名播客節目主持人 Lex Fridman 與四位 Cursor 團隊成員進行了一場技術對談，揭示了這個團隊在做的以及未來要做的探索。

影片地址：https://youtu.be/oFfVt3S51T4?si=pCvBgWm5X-W8xt4n

以下是 Lex Fridman 與 Cursor 團隊創始成員 Michael Truell、Sualeh Asif、Arvid Lunnemark 和 Aman Sanger 的對話，機器之心進行了核心內容的整理：

Cursor 的起源

Cursor 的起源故事是什麼呢？

2020 年左右，OpenAI 發佈了有關縮放損失的論文。那一刻，該領域似乎取得了明顯可預測的進展，即使我們沒有更多的想法，但看起來如果你有更多的計算和更多的數據，你就可以讓這些模型變得更好。

順便說一句，我們可能會就縮放損失這個話題討論三到四個小時。但總結一下，這是一系列論文中的一篇，這些論文提出了一系列觀點，認為在機器學習領域，模型大小和數據大小越大越好。

它更大更好，但可以預見的是它會更好。這是另一個話題。

好的，這是另一個話題。

是的。那段時間，我們中的一些人進行了很多概念性討論：它會是什麼樣子？對於所有這些不同的知識工作者領域來說，這項技術的發展將如何讓他們變得更好？有那麼幾個時刻，那篇論文中預測的理論收益開始變得非常具體，我們開始覺得，如果你想在人工智能領域做有用的工作，你實際上可以直接去，而不必攻讀博士學位。感覺現在有一整套可以構建的真正有用的系統。

下一個讓一切都變得順理成章的重要時刻實際上是提前獲得 GPT-IV 的使用權。所以，大約在 2022 年底，我們開始修改這個模型，升級能力令人感覺非常強大。在此之前，我們一直在從事幾個不同的項目。由於 Copilot、由於 scaling odds、由於我們之前對這項技術的興趣，我們一直在修改程序員工具，但這些工具非常具體。因此，我們正在為必須在 Jupyter Notebook 中工作的金融專業人士構建工具，或者嘗試使用這些模型進行靜態分析。

然後 GPT-IV 的升級讓我們感覺，看，這確實使之前預測的理論收益具體化。感覺你可以在那個時間點立即構建更多東西。而且如果我們保持一致，感覺這真的不僅僅是一個點解決方案。所有編程都將流經這些模型，需要不同類型的編程環境，不同類型的編程。所以我們開始構建一種更大的願景。

代碼差異

Cursor 有一個非常酷且引人注目的功能，那就是整個 diff 接口情況。因此，模型用紅色和綠色表示我們將如何修改代碼，你可以在聊天窗口中應用它，它會向你顯示 diff，你可以接受 diff。

我們可能會有四五種不同的 diff。我們針對自動完成功能優化了 diff，因此它具有與檢查較大代碼塊時不同的 diff 接口。然後，我們正在嘗試優化另一個 diff 功能，以適應處理多個不同文件的情況。從高層次來看，區別在於你使用自動完成功能時，讀取速度應該非常非常快。實際上，在所有情況下讀取速度都應該非常快，但在自動完成功能中，你的眼睛會集中在一個區域，人類不能看太多不同的地方。

我們嘗試了三四次才讓這個東西正常工作，第一次嘗試是使用藍色劃線。在它變成側面的方框之前，它曾經以 Google Docs 樣式顯示要刪除的代碼，你會看到一條劃線，然後會看到新代碼。這容易讓人分心。然後我們嘗試了許多不同的方法，有刪除，有嘗試紅色突出顯示。

然後，在下一次迭代中，這有點搞笑，你會按住 Mac 上的選項按鈕。所以它會突出顯示一段代碼，向你顯示可能會有什麼東西出現。所以在這個例子中，輸入和值都會變成藍色。藍色是為了突出顯示人工智能為你提供了建議。所以它不是直接向你顯示東西，而是暗示人工智能有一個建議，如果你真的想看到它，你會按住選項按鈕，然後你就會看到新的建議。如果你釋放選項按鈕，你就會看到你的原始代碼。

是的，這是用戶體驗設計工程中非常迷人的領域。所以你基本上是在試圖引導人類程序員完成他們需要閱讀的所有內容，僅此而已，這是最佳的。

你需要智能模型來做這件事。目前，不同的算法就像普通算法一樣。沒有智能。算法的設計需要智能，但你並不關心它是這個還是那個，因為你希望模型來做這件事。

一個問題是，這些模型會變得更加智能。隨著模型變得更加智能，它們能夠提出的改變也會更大。因此，隨著改變越來越大，人類必須做越來越多的驗證工作。

人類不想把所有的時間都花在審查代碼上。我認為可以使用語言模型顯著改善審查體驗，例如，某種技巧可能會將你指向真正重要的區域。我還認為，如果代碼是使用這些語言模型生成的，而不是由其他人生成的。代碼審查體驗是為審查者和生成代碼的人設計的。如果編寫代碼的人是語言模型，那麼你就不必太在意他們的體驗，你可以圍繞審閱者設計整個過程，讓審閱者的工作儘可能有趣、輕鬆、高效。

機器學習細節

Cursor 的編輯器讓我有點感受到 AGI 的存在，能不能談談讓它運行的機器學習細節？

Cursor 實際上是基於我們訓練的定製模型和前沿模型組成的集成模型來運行的。一些 Cursor 廣受好評的功能，比如 Tab 和 Apply，都是微調起的效果。

這些前沿模型非常擅長生成修改代碼的意見與草稿，但在實際生成代碼改動的細節時，往往會遇到困難，特別是，當用這些模型（如 Sonnet、o1）處理大型文件時，常常會出現搞串行這樣的低級錯誤。

為此，我們採取了一個策略：首先讓模型生成一個粗略的代碼塊，簡單描述代碼需要如何修改；然後再訓練另一個模型，將這些代碼修改應用到實際文件中。

補充一下，Apply 功能是模型會查看你的代碼並給出新建議。根據新建議對代碼進行修改，對人類來說看似很簡單，但對模型而言其實並不那麼容易，對嗎？

可能有很多人認為 Apply 功能背後的算法是「確定性的」，也就是說它有一套固定的規則或流程，但實際上並不是。

是的，其他 AI 編程工具也有 Apply 功能的「平替版」，但它們往往會崩潰。很多人以為可以通過確定性的匹配來實現這些功能，但實際情況是，至少有 40% 都會失敗。

我認為整體趨勢是，模型會變得越來越智能。而 Apply 的另一個優勢在於，它可以讓最智能的模型在生成代碼時，使用較少的 tokens，從而降低延遲和成本。

具體來說，你可以給模型一個粗略的代碼草稿，然後模型負責具體實現，相比於讓模型從零開始寫完整的代碼，給一個大致草稿讓模型去完善要簡單得多。我相信這一趨勢將繼續發展，隨著負責規劃的模型越來越智能，具體實現的細節可能交由相對簡單的模型來處理。也許會有 o1 或更強大的模型來生成高層次的規劃，再由定製的模型遞歸地執行。

如果你感興趣，我們可以聊聊如何讓它更快。

那你們是如何提升 Cursor 的處理速度的呢？

讓速度變快的一個要點是「投機編輯」（speculative edits），它是從投機解碼（speculative decoding）衍生出來的。你可以利用投機解碼的一個優勢：大部分情況下，尤其是在語言模型生成時受內存限制的情況下，一次處理多個 tokens 比逐個生成 tokens 更快。因此，當你查看每秒生成的 tokens 數量時，會發現處理 prompt tokens 的速度遠快於逐個生成 tokens。

我們的方法與傳統的投機解碼不同。傳統方法是用一個很小的模型預測代碼，然後由更大的模型來驗證。但是因為我們對已有代碼的樣子、格式和邏輯足夠熟悉，所以可以直接把原始代碼片段輸入到模型中，讓模型去判斷哪些部分需要改動。絕大多數情況下，模型會認同：「這些代碼沒問題，可以直接複製。」

因此，你可以並行處理所有代碼行，並對足夠多的代碼片段進行同樣操作。最終，當模型預測的文本與原始代碼出現不一致時，它會生成新的 tokens，我們則根據匹配程度判斷何時重新對代碼塊進行推測。

GPT vs Claude

哪個 LLM 更擅長編碼？GPT 和 Claude 在編程方面誰更勝一籌？

我認為沒有哪個模型可以稱霸於所有模型，這意味著在我們認為重要的所有類別中，Pareto 模型都表現更好，這些類別包括速度、編輯代碼的能力、處理大量代碼的能力、長上下文、其他一些方面以及編碼能力。我現在認為最好的模型是 Sonnet。o1 非常有趣，而且推理能力很強。因此，如果你給它一些非常難的編程面試風格問題或引導代碼問題，它可以做得很好，但感覺它不像 Sonnet 那樣理解你的大致意圖。

如果你看看許多其他前沿模型，它們在基準上的表現都非常好，但是當你將它們推到更遠的地方時，我認為 Sonnet 是保持相同性能的最佳選擇。

正常的編程體驗與基準測試所代表的體驗之間有什麼區別？當我們評估這些模型時，基準測試的不足之處在哪裡？

這是一個非常非常困難且至關重要的細節，它說明了基準測試與真實編碼之間的區別，真實編碼不是面試風格的編碼。人類有時會說半生不熟的英語，有時你會說：「按照我之前做的做。」有時你會說：「添加這個東西，然後為我做另一件事，然後製作這個 UI 元素。」然後很多事情都是依賴於上下文的。抽像地說，面試問題非常具體。它們很大程度上依賴於規範，而人類的東西則不那麼具體。

基準測試中實際可以建模的內容與實際編程之間存在偏差，有時很難概括，因為實際編程非常混亂，有時無法很好地指定什麼是正確的，什麼不正確。但是由於公共基準測試的問題，這也變得更加困難。因為公共基準測試有時是爬坡測試，也是因為從模型中獲取公共基準測試數據非常非常困難。

例如，最受歡迎的基準之一 SWE-Bench 確實受到這些基礎模型的訓練數據汙染。因此，如果你要求這些基礎模型解決 SWE-Bench 問題，但實際上沒有為它們提供代碼庫的上下文，它們就會產生幻覺的文件傳遞，產生幻覺的函數名稱。

這種情況下，它可以針對文字問題或拉取請求本身進行訓練，也許實驗室會開始做得更好，或者他們已經在淨化這些東西方面做得很好，但他們不會忽略存儲庫本身的實際訓練數據。這些都是一些最流行的 Python 存儲庫。SimPy 就是一個例子。我不認為他們會在 SimPy 和所有這些流行的 Python 存儲庫上設置他們的模型，以便在這些基準測試中獲得真實的評估分數。

鑒於基準測試中的缺陷，使用這些模型構建系統或構建這些模型的地方實際上會使用一些有趣的「枴杖」來瞭解它們是否朝著正確的方向發展。在很多地方，人們實際上只是讓人類來玩這些東西並對這些提供定性反饋。一些基礎模型公司都有人負責這項工作。在內部，我們也對這些模型進行定性評估，實際上除了我們擁有的私人電子郵件外，我們還非常依賴這些評估。

提示工程

一個好的提示詞能起什麼作用？你曾寫過一篇關於提示詞設計的博客。

這取決於你正在用哪個模型。每個模型對不同的提示反應也不同，比如 GPT-4 就對提示詞非常敏感，但問題是，當空間有限時，你如何決定哪些信息應該被放入提示詞中呢？

針對這個問題，我們內部有一個系統叫做 Preempt。它有點像你在製作一個網站：你希望在移動端和桌面端都能正常顯示網站的頁面。但你需要考慮一些動態的信息，畢竟網頁設計不像雜誌排版是固定的。網站和提示詞的輸入都是動態的，你需要確保格式始終適用，輸入量很大時，需要剪裁一些內容。因此，我們從設計網站的思路中提取了靈感。

我們非常喜歡 React 以及聲明式的方式，比如你可以在 JavaScript 中使用 JSX，然後直接聲明：「這就是我想要的，我認為這個部分比其他部分具有更高的優先級或更高的 Z 軸順序。」

在網頁設計中，渲染工作由渲染引擎來完成，而在 Cursor 中，這個任務由 Preempt 渲染器負責，它將所有內容佈局到頁面上。你只需說明你想要的效果，渲染器會自動幫你實現。

我們發現這種方法非常有用，而且它的角色也在不斷演變：最初它是為了適應較小的上下文窗口，而現在它在拆分進入提示詞的數據和實際生成方面發揮了很大作用。因此，調試起來更加簡單，因為你可以修改提示詞，並在舊的提示詞上進行測試，直接查看你的修改是否真的提升了整個評估集的表現。

所以你們真的在用 JSX 來寫提示詞嗎？

沒錯！Preempt 看起來就像 React。它還有一些組件，比如文件組件，它會獲取光標的位置。在代碼編輯器中，光標在的那行代碼可能是最重要的一行，因為你正在查看它。那麼就可以基於此為不同的代碼行設置優先級。光標所在的那一行優先級最高，離它越遠的行，優先級依次遞減。最終在渲染時，系統會計算出能顯示多少行代碼，並以光標所在的行為中心進行呈現。

這也太棒了！

你還可以實現更複雜的功能，比如當整個代碼庫中有許多代碼塊時，可以通過檢索、嵌入和根據得分重新排序等方式，為這些組件設定優先級。

那麼，人類在提問時，是否也應該嘗試使用類似的方式？在提示中寫 JSX 會有好處嗎，還是說想到哪裡就問什麼這種方式更好？

我認為我們的目標是，你可以隨意提問，而我們的任務是找到合適的方式檢索出與你想法相關的信息。

我之前和 Perplexity 的 CEO Aravind Srinivas 聊過這個問題，他的觀點是提問者越懶越好。這種思路是極好的，但我覺得對於程序員來說，你應該可以提更高的要求，對吧？

沒錯。如果你說「隨便你怎麼問」，人往往是懶惰的。這就產生了一種張力：一方面是人們可以隨意提問，另一方面它也在鼓勵人們在提示詞中傳達更有深度的想法。

我的觀點是，即使 AI 已經足夠智能，但你仍無法傳遞足夠明確但意圖來指引模型該做什麼。有幾種方法可以解決這種意圖不明確定問題。一種是讓模型問你：「基於你的查詢，我不確定如何處理這些部分，你可以明確一下嗎？」另一種方法可能是，如果有五六種可能的生成方式，「鑒於目前查詢中的不確定性，不如我們把這些生成的結果都展示給你，然後讓你來選擇。」

對於模型來說，讓它主動發問有多難呢？

我們最近為 Cursor 添加了一個加入文件的功能。當你在編輯代碼或輸入內容時，模型會嘗試預測你正在做什麼，如果模型發現有不確定的地方，它會猜測你可能在編寫某種 API。然後，模型會查看你的歷史記錄，推測哪些文件與當前的編輯內容相關。

這裏有一個技術上的難題，就是如何在所有歷史記錄中找到相關的信息，判斷在當前的提示詞下哪些文件最重要。雖然這個功能還處於試驗階段，但相信我們會逐步完善它，但我們想展示出這個想法：「你是否想添加這個文件、那個文件，以便模型幫你編輯？」

比如你正在編寫一個 API，同時，你也需要編輯使用這個 API 的客戶端和服務器代碼，那麼 API 發生變化時，客戶端和服務器代碼也需要相應更新。

Cursor 可以做的是，當你在編寫提示或代碼時，在按下「回車」之前，模型可以幫你找到這些可能需要一起修改的部分。這樣做的好處是，可以提前解決一些不確定性，確保所有相關的代碼都被正確更新，而不需要手動去查找和同步這些改動。

上下文

關於上下文，當我用 Python 編寫代碼時，會導入一堆東西。如果想知道我想在上下文中包含哪些東西，自動找出上下文有多難？

這很棘手。我認為未來我們可以在自動計算上下文方面做得更好。需要注意的一點是，包含自動上下文是有代價的。

首先，為這些模型包含的上下文越多，它們的速度就越慢，請求的成本就越高，這意味著您可以減少模型調用，並在後台執行更少的花哨操作。此外，對於許多這些模型，如果提示中包含大量信息，它們會感到困惑。因此，包含的上下文的準確性和相關性標準應該相當高。

我們已經在產品的某些地方做了一些自動上下文。這是我們希望做得更好的事情。我認為有很多很酷的想法可以嘗試，包括學習更好的檢索系統，例如更好的嵌入模型、更好的重排序器。

還有一些很酷的學術理念，我們已經在內部嘗試過，你能否讓語言模型達到這樣一種境界，即模型本身就可以理解新的信息語料庫？最流行的版本是，你能否讓上下文窗口無限？那麼，如果你讓上下文窗口無限，你能否讓模型真正關注無限上下文？然後，在你讓它關注無限上下文之後，讓它在某種程度上切實可行，你能否對無限上下文進行緩存？你不必一直重新計算。但是，還有其他很酷的想法正在嘗試中，它們更類似於在模型權重中實際學習這些信息的微調。如果你在權重級別上做更多的事情，而不是在上下文學習級別上做，那麼你實際上可能會獲得一種定性的不同類型的理解。

我們真的對更好的檢索系統和挑選與你正在做的事情最相關的代碼庫部分感到興奮。一個有趣的概念證明是使用 VS Code 直接在權重中學習這些知識。所以我們在 VS Code 分支和 VS Code 中。代碼都是公開的。因此，這些預訓練模型已經看到了所有代碼。他們可能還看到了有關它的問題和答案。然後他們進行了微調和 RLHF，以便能夠回答有關代碼的一般問題。因此，當你問它關於 VS Code 的問題時，有時它會產生幻覺，但有時它實際上可以很好地回答問題。我認為這隻是…… 它碰巧沒問題，但如果專門訓練或後訓練一個模型，使其真正構建為理解這個代碼庫，會怎麼樣？

這是一個開放的研究問題，我們對此非常感興趣。此外，還有一個不確定性，你是否希望模型成為端到端完成所有工作的東西，即在內部進行檢索，然後回答問題、創建代碼，或者你是否想將檢索與前沿模型分開，也許你會在幾個月內得到一些真正強大的模型，這些模型比最好的開源模型要好得多？然後，需要單獨訓練一個非常好的開源模型作為檢索器，作為將上下文輸入到這些更大模型的東西。

能否再多談談訓練模型後如何理解代碼庫？這是什麼意思？這是一個合成數據方向嗎？

是的，有很多方法可以嘗試。當然，想法是無窮無盡的。問題只是去嘗試所有方法，然後根據經驗判斷哪種方法最有效。一個非常幼稚的想法是嘗試複製 VS Code 和這些前沿模型所做的事情。所以讓我們繼續進行預訓練。某種持續的預訓練，包括一般代碼數據，但也加入了你關心的某些特定存儲庫的數據。然後在後訓練中，讓我們從指令微調開始。你有一個關於代碼的正常指令微調數據集。然後，你會在該存儲庫中提出很多關於代碼的問題。

因此，你可以獲得基本事實數據，這可能很難，或者你可以使用合成數據執行您暗示或建議的操作，即讓模型詢問有關各個近期代碼片段的問題。因此，你可以獲取代碼片段，然後提示模型或讓模型針對該代碼片段提出問題，然後將其添加為指令微調數據點。然後從理論上講，這可能會解鎖模型回答有關該代碼庫的問題的能力。

OpenAI o1

你們怎麼看 OpenAI o1？這種能在測試時計算的系統將在編程中將扮演什麼角色？

對於預訓練模型模型，Scaling law 效果撥群，但我們現在已經遇到了「數據壁壘」，因此，通過增加推理時使用的 flops 來提升模型性能，是一種有趣的方法。傳統上，我們必須訓練更大的模型來使用更多的 flops，但現在我們或許可以在相同規模的模型上運行更長時間，來達到大型模型的質量。

我覺得還有一點很有趣，有些問題可能需要一個擁有 100 萬億參數、訓練了 100 萬億 tokens 的超大模型才能解決，但這樣的問題可能只佔所有查詢數量的 1% 甚至 0.1%。那麼，你會花費大量的計算資源去訓練一個如此昂貴的模型，卻只為極少的查詢提供服務嗎？這樣做感覺很浪費。

所以更好的方法是，訓練一個能夠處理 99.9% 查詢的模型，然後對於那些需要極高智能的問題，在推理時運行更長時間，以獲得更好的答案。

如果你要構建一個能和 o1 pk 的模型，你會怎麼做？

待做事項之一肯定是要訓練一個「過程獎勵模型」（process reward model）。

或許我們可以深入討論一下「獎勵模型」、「結果獎勵模型」與「過程獎勵模型」的區別。結果獎勵模型是傳統用於語言建模的獎勵模型，它只關注最終結果，比如一個數學問題答對了，模型就能獲得對應的獎勵。

而過程獎勵模型則試圖對「思維鏈」中的每一步進行評分。OpenAI 在去年夏天發表了一篇論文，他們利用人工標註員構建了一個包含幾十萬條「思維鏈」數據的大型數據集。目前來看，除了在樣本選擇中起作用外，過程獎勵模型還有什麼應用，我還沒看到。

真正讓人覺得有趣、也讓大家期望能起作用的是結合過程獎勵模型進行「樹搜索」（tree search）。因為如果你能對「思維鏈」的每一步都進行評分，那麼你就可以分支，並對這個思維鏈中的多條路徑進行探索，再利用過程獎勵模型來評估每個路徑。

OpenAI 曾提到他們正在隱藏模型的「思維鏈」，並表示這是一項艱難的決策。他們選擇讓模型總結思維鏈，而不是直接展示給用戶。同時，OpenAI 在後台監控這些思維鏈，以確保模型不會嘗試操控用戶，不管怎樣，你對隱藏思維鏈怎麼看？

我對 OpenAI 的一個猜測，純屬臆測，可能是他們不想讓人們從他們的模型中提煉出 o1 的能力。如果你能看到隱藏的思維鏈，複製這項技術可能會變得更容易，因為你能夠看到模型為得到最終結果所採取的每一步，這可是非常重要的數據。

那你也可以基於這些來訓練模型嗎？

之前也有類似的情況，雖然這隻是猜測：過去，這些 API 可以很方便地獲取生成 tokens 及提示 tokens 的對數概率。但後來，這個功能被移除了。依然是猜測，背後的原因可能是，如果你能獲取這些對數概率，就如同看到隱藏的思維鏈一樣，這會讓你更容易從這些 API 和大型模型中提煉出其能力，並將其轉移到你自己的模型中。

另外，補充一點我們之前關於整合 o1 模型的討論：我們現在還在摸索如何使用這個模型。所以我們把 o1 整合到 Cursor 中，是因為我們一拿到這個模型就非常想試試，我想很多程序員也會很感興趣。

o1 並不屬於 Cursor 預設體驗的一部分，我們至今還沒有找到一種每天、甚至每小時都能在編輯器中使用 o1 的方法。因此，我覺得如何使用 o1 的最佳方式還沒有定論。我們也還沒有看到明確展示其實際用例的例子。有一些明顯的方向，它可以讓你更容易地在後台運行一些任務，或讓模型在循環中運行，賦予它們 agent 的能力。但我們還在探索中。

需要澄清的是，我們確實有一些想法，只是在公開之前，我們需要確保能做出真正有用的東西。

但 o1 也有一些明顯的限制。暫且不談它的能力問題，它並不支持流式輸出。這意味著，當你需要監督輸出時，使用起來會非常不方便，你只能等待整段文本一次性顯示。此外，這感覺像是測試時計算和搜索的初級階段，o1 更像是一個 v0 版本，還有很多需要改進的地方。我猜想，在增加預訓練數據量、擴展模型規模以及探索預訓練技巧的同時，還會有另一條路徑來不斷優化搜索功能。

最近有傳言說，GitHub Copilot 可能會以某種方式整合 o1，有一些評論說：「這是否意味著 Cursor 完了？」你們怎麼看呢？

是時候關停 Cursor 了。

沒錯  Cursor 是該倒閉了。

所以你們真的覺得是時候把 Cursor 關了嗎？

我認為這個領域與過去 2010 年左右的軟件領域有些不同，因為這裏的上限真的非常高。我認為再等 3-4 年，那時最好的 AI 編程產品可能比現在的要實用得多。

當然，你可以談論護城河、品牌、優勢等等，但如果你在產品創新上止步不前，就會被甩在後面。這對初創公司和想進入這個市場的人來說都是好消息，因為只要你能打造出更好的產品，就有機會超越那些擁有大量用戶的競爭者。因此，我認為接下來的幾年關鍵在於打造最好的產品和系統，不僅包括模型引擎的改進，還包括優化編輯體驗。

沒錯，我認為 Cursor 相比其他產品的額外價值不僅僅在於能快速整合 o1 這樣的新模型。更重要的是，Cursor 的定製模型在各個方面提供了深入支持，這些模型可能在你不知情的情況下默默發揮作用，每個功能都為用戶體驗進行了精心設計。