跳至主要内容

一文讀懂Cursor與WindSurf的程式碼索引邏輯

Context, not control.

——張一鳴

一、背景：AI程式設計的上下文至關重要​

如果說現在讓AI程式設計能力實現階梯式飛躍的大模型本身的「智慧」水平——Claude 3.5 Sonnet跨越了那個邊界。那另一個影響AI程式設計實現效果的就是上下文長度。

目前Claude 3.5 Sonnet提供最長200k token的上下文長度，這對對話模型來說是非常充足的，一篇5萬、10萬字的書籍讀完都輕鬆不在話下，但這對於動輒幾十、上百個程式碼檔案，每個程式碼檔案長達數百至上千行的程式設計專案來說，這樣的上下文長度仍然遠遠不足。再加上現在大模型按輸入、輸出的token數收費，邊際成本不為0。

以上兩個特性會引來Cursor、Windsurf等AI程式設計工具做大量的最佳化，他們目標如下：

1）儘量準確為你獲取任務相關程式碼，節約上下文長度，以實現多步驟任務的調優，給你提供更好的效果體驗；

2）儘量減少讀取「不必要」的程式碼內容，既為了任務調優，也為了節約成本。

在上述的侷限和目標條件下，Cursor、Windsurf採取了不同的調優策略提升自己的產品體驗。但是這種「調優」往往也是取捨，只是區域性的最優解，各自都會犧牲掉部分使用者的體驗。

所以這篇文章的目的在於，幫助我自己和你去理解他們「調優」的方式和邏輯是如何的？理解這種「調優」的取捨之後，我們更有機會去利用不同產品的優劣勢，在不同場景下知道如何切換工具和使用方式，去為我們的任務實現最優解。

二、結論：Windsurf適合起步，Cursor適合調優​

基於最近的使用經驗和12.15對Cursor0.43.6與Windsurf1.0.7版本的實際評測，得出以下結論：​

1、對新手而言，初始執行基礎任務時：Windsurf > Cursor Agent > Cursor Composer normal​

  • 在agent模式下，執行初級任務的表現都優於常規的Cursor Composer模式，因為agent模式會基於任務理解程式碼庫，找程式碼檔案，讀程式碼，再一步步執行操作幫你完成任務

  • Windsurf的agent，在理解任務和執行多步操作的能力上，調優效果優於Cursor Composer模式下的agent

2、Agent模式的主要缺陷是不完整讀程式碼檔案，這會導致複雜專案和長程式碼檔案的問題​

  • Cursor agent模式下，預設讀一個程式碼檔案的前250行，如果不夠，偶爾會主動續讀，增加250行；在部分要求明確的情況，Cursor會執行搜尋，每次搜尋結果最多為100行程式碼。

  • Windsurf每次讀程式碼檔案200行，如果發現不夠，會嘗試再次讀取，最多嘗試3次，共讀取600行。

3、Cursor與Windsurf @ 單個程式碼檔案時，執行邏輯不同，Cursor遠優於Windsurf​

  • Cursor中如果@ 某個程式碼檔案，cursor會盡量完整讀取（測試臨界點2000行）

  • windsurf的 @程式碼檔案和cursor的 @程式碼檔案不是一個邏輯。在windsurf中你@某個程式碼檔案僅僅是說你幫助windsurf找到了對應的檔案。但是他並不會真的認為這個檔案很重要而進行完整讀取。

4、在你能理解專案結構的情況下，Cursor中 @單一程式碼檔案效果遠優於 @codebase​

  • 如前面所說，如果你理解你自己在做什麼，你要執行的任何和哪個程式碼檔案有關，那麼Cursor中 @ 你將獲得好得多的效果。如果 @codebase，目前的判斷是cursor會用自己的小模型執行對每個程式碼檔案的理解並總結，他沒有完整將必要的程式碼都納入上下文。

三、測試過程​

以上所有結論來自於我日常高頻使用Cursor、Windsurf的體感（500+小時），再加上一次針對性的測試。在這次測試中，我用了一個長達1955行的影片字幕檔案。字幕檔案的優勢在於有時間戳且內容上下文結偶，我很容易判斷AI程式設計工具到底了讀了沒，已經讀了多少內容，他沒辦法「猜」。​

Image 25

甚至，為了驗證是真的「讀」，還是透過RAG的方式總結的，我在每500行中間隨機穿插了一些和內容無關的資訊，用於事後確認Cursor、Windsurf讀的程度，包括：

  • 花生最喜歡的運動是網球

  • 花生最喜歡的籃球隊是湖人

  • 花生喜歡帶白色的圓頂帽

  • 花生最喜歡的食物是皮皮蝦

Round1：Cursor Composer Normal模式不主動去查詢字幕檔案進行讀取，任務直接失敗

Image 26

Round2：Cursor Composer Agent模式下，找到並讀取字幕檔案，但只讀了250行

Image 27

Round3：Windsurf Cascade，預設agent模式，找到並讀取字幕檔案，讀了三次，但也只讀了600行

Image 28

Round4：Cursor Compose模式，主動@ 程式碼檔案，Cursor完整讀取全部內容，第一次獲得全部正確結果；並且透過了後續陷阱問題大海撈針的確認，它是真讀了

Image 29

Image 30

Round5：Cursor Compose模式，主動@codebase，Cursor大致總結了影片內容，但是後續陷阱問題全都回答錯誤，我判斷是因為這個模式下cursor的多次讀取也只是用小模型進行總結，並把總結資訊返回到上下文中

Image 31Image 32

Round6：Windsurf Cascade，主動@程式碼檔案，獲得的總結依然只有600行檔案內容，說明沒有完整讀取

Image 33

四、分場景下的Cursor、Windsurf使用建議​

1、每個程式碼檔案最好控制在500行以內（cursor agent讀兩次的範圍）​

2、在程式碼檔案的前100行寫清楚該程式碼檔案的功能和實現邏輯（透過註釋的方式，便於agent索引）​

3、如果你是新手，在專案初始狀態下，或者面對比較簡單的專案，使用windsurf效果更佳​

4、如果你的專案複雜，單個檔案長度超過600，你對專案熟悉，知道自己要做的事和哪些程式碼檔案有關，能準確 @對應檔案，那最好使用cursor。​

5、頻繁的重新開始你的對話（比如每完成一個新功能，或者解決一個bug後），帶入過長的上下文對專案是個汙染。​

6、頻繁的記錄你的專案狀態和專案結構到特定文件中（比如readme.md），這樣在重啟對話時能快速幫助Cursor/windsurf瞭解你的產品狀態，且不會那麼容易帶入過多的上下文。​