標題：Windsurf 與 Cursor — 初步想法
已發表： 真實
描述：
標籤：
封面圖片：https://direct\_url\_to\_image.jpg
使用 100:42 的比例可獲得最佳效果。
發佈時間：2024-12-01 10:05 +0000
在一段隨機的無聊導致某件事發生的事件中，由同樣隨機的YouTube 短片觸發，該短片講述了熱門的新型基於AI 的IDE（遊標），我決定是時候從我的VS Code + Copilot 設定升級並嘗試了圍繞這些新時代 VS Code 分支的炒作，承諾透過無縫 AI 整合提供更好的開發人員體驗。
Afsheen不久前曾簡要介紹過如何使用Cursor ，但我對此一無所知，因此我聯繫了她，以獲取有關 IDE 的第一手體驗報告。這次討論讓我對 YouTube 影片進行了附帶探索（因為誰不喜歡看別人使用工具？），並彈出了另一個工具（ Windsurf ），一些隨機的陌生人聲稱它比 Cursor 更好。困惑隨之而來：我應該嘗試 Cursor 還是 Windsurf？ （不劇透警告：我決定兩者都嘗試）。
我想像（並希望）這是我對 Windsurf 和 Cursor 的比較體驗的一個持續的系列。
對於我的第一個技巧，我必須在現有的看起來很舊的程式碼庫中加入一些前端功能，該程式碼庫包含我最近見過的一些最複雜的 React 程式碼。我最近才調到這個團隊工作，對程式碼庫還很陌生，總共接觸了大約一週的時間。所有的序言都說，如果你問我在哪裡進行更改，我需要花幾分鐘才能找到確切的文件，然後花一些時間來破解編寫程式碼的開發人員的內部獨白和邏輯。
計劃是只使用 Windsurf 來完成工作，但那是一個星期五晚上，暴雨打亂了任何外出計劃，所以我決定使用 Cursor 重複這一壯舉並進行比較。這是我到目前為止發現的。
風帆衝浪/感覺更快
由於 Claude 3.5 Sonnet 是這兩個課程的主要LLMs，Windsurf 在產生回應和完成工作方面都感覺更快。 Windsurf 中對全域聊天（Cmd + L，Windsurf 稱之為Cascade ）的回應速度非常快，但 Cursor 中存在明顯的滯後。
並不是說需要速度（正確性更好），但如果最終的答案和建議更加嚴格和正確，那麼緩慢是可以忍受的，但正如在這個特定的越軌行為中所證明的那樣，Cursor 的建議與Windsurf的建議相當，從來沒有更好，有時更糟。
Windsurf 的「寫入」模式勝過遊標 + 在較小的框架中驗證程式碼建議很難！
Cursor 很禮貌- 當任務是執行明確的指令（在主聊天視窗中）（可以視為“在這裡，修改我的文件”）時，Cursor 仍然只在其聊天側邊欄中提供建議（當然，您可以為了方便而擴展）然後，您可以透過點擊每個程式碼區塊頂部的微小「應用」選項來驗證並提交。另一方面，Windsurf 則很大膽：在聊天中使用「寫入」模式，它將繼續為您做出決定，無論是在操作發生位置附近的目錄中建立新文件，還是修改現有文件。 （註：我聽說 Cursor 的 Pro 計劃有類似的行為，但我尚未驗證。）
這種大膽使得將變更引入程式碼庫的體驗更快。而且更好的是，因為在一個小側邊欄中驗證大段程式碼充其量是痛苦的，而在最壞的情況下幾乎是不可能的。透過將更改寫入文件，Windsurf 允許您在主視窗中驗證/檢查程式碼建議，從而獲得更好的體驗。
在 Cursor 中加入文件上下文會更容易
在 Cursor 中加入文件上下文相對容易。想要指示它使用整個程式碼庫嗎？ @codebase就可以了。想要合併編輯器中開啟的兩個檔案嗎？只需@files就會向您顯示最近的文件（同時也允許您包含其他未開啟的文件）。這個簡單的動作在 Windsurf 中很難執行（或者我還沒有找到方法）。 [文件]表明 Windsurf 的上下文預設包含開啟的文件，並且無論如何它都具有整個程式碼庫的上下文，這可能解釋了為什麼 Windsurf 能夠比 Cursor 更好地找到正確的文件。但是 Cursor 在聊天視窗中加入的明確上下文讓人工智慧在想出解決方案之前對所要求看到的內容更有信心。
風帆衝浪往往是正確的
我實現該功能的最早步驟之一是知道在哪裡進行編輯。我要求 Windsurf 和 Cursor 告訴我在哪裡進行更改。 Windsurf 第一次嘗試就找到了該文件；遊標需要額外的刺激和關鍵字才能落在正確的文件上。
在後續步驟中，我請 IDE 為我編寫一個包含日期時間選擇器的表單。 Windsurf 即使是第一次嘗試，也使用了專案使用的現有自訂日期時間選擇器元件。遊標，即使經過多次嘗試，也不能。起初，它使用本機元件。當我要求它在程式碼庫中尋找自訂日期選擇器並使用它時，Cursor 決定我必須從npm安裝日期選擇器元件並使用它。最後，經過幾次嘗試，我決定將文件指向它，只有這樣 Cursor 才能找出我正在尋找的正確程式碼。
Windsurf“主動出擊”，走了整整九碼
我負責新增的功能（外包給 AI）是一個簡單的小選單項，然後呼叫 GraphQL 突變。現在，我對 IDE 的指示根本沒有讓我談論突變。相反，我只是說了一些類似“嘿，我需要加入執行此操作的選單專案”的內容。然後繼續要求 IDE 增量迭代。
遊標確實設法在模型中加入選單專案、模態和表單（這就是日期選擇器惡作劇發生的地方），但它無法為這一集提供合適的結局，因為它無法弄清楚如何將具有GraphQL 呼叫（即使是錯誤的）的選單專案。
另一方面，Windsurf 似乎記住了該功能的主要目標，並透過 GraphQL 呼叫提出了一個幾乎正確的實現。自從我開始使用 Windsurf 以來，當我用完它時，它幾乎感覺功能已經完成了。
是代幣大小不同的問題還是其他原因？我還不知道。
—
目前，Windsurf 似乎佔據了領先地位。 UX 絕對比 Cursor 好。我覺得這樣做比較有成效。在未來的日子裡，我希望這兩個 IDE 能夠涵蓋更多的開發需求，以便更好地了解每個 IDE 的工作原理以及誰在哪些方面做得更好。
原文出處：https://dev.to/druchan/windsurf-vs-cursor-initial-thoughts-40b6
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式