背景：AI 程式設計中上下文的重要性
如果大型模型（例如 Claude 3.5 Sonnet）的「智慧」是推動 AI 程式設計能力逐步躍升的關鍵因素，那麼另一個關鍵因素就是上下文長度。
目前，Claude 3.5 Sonnet 提供最多 200k 個 token 的上下文長度。雖然這對於對話模型來說已經綽綽有餘——可以輕鬆處理 50,000 字甚至 100,000 字的書籍——但對於涉及數十或數百個程式碼檔案（每個檔案包含數百或數千行程式碼）的程式設計專案來說，仍然遠遠不夠。此外，大型模型根據輸入和輸出 token 的數量收費，邊際成本並不可忽略。
這兩個特性促使 Cursor 和 Windsurf 等 AI 程式設計工具實施多項優化，目標如下：
- 準確提取與任務相關的程式碼以節省上下文長度，實現多步驟任務優化並提供更好的使用者體驗。
- 最大限度地減少閱讀「不必要」的程式碼內容，不僅可以改善任務優化，還可以降低成本。
在上述約束和目標下，Cursor 和 Windsurf 採用了不同的優化策略來提升其產品體驗。然而，這種「優化」往往涉及權衡，只能產生局部最優解，不可避免地會犧牲使用者體驗的某些方面。
本文旨在幫助您和我理解其「優化」背後的 methods 和邏輯。通過掌握這些調整中涉及的權衡，我們可以更好地利用不同產品的優勢和劣勢。這種理解將使我們能夠在各種情況下切換工具和調整使用方法，最終實現任務的最優解。
結論：Windsurf 適用於入門，Cursor 適用於優化
根據最近的經驗和對 12 月 15 日 Cursor 0.43.6 和 Windsurf 1.0.7 的實際評估，得出以下結論：
1. 對於執行基本任務的初學者：Windsurf > Cursor Agent > Cursor Composer（普通模式）
在 Agent 模式下，執行基本任務的效能優於標準 Cursor Composer 模式。這是因為 Agent 模式會解釋任務，掃描程式碼庫，定位檔案，閱讀程式碼並逐步執行操作以完成任務。
與 Cursor Composer 模式的 Agent 相比，Windsurf 的 Agent 表現出更好的任務理解和多步驟執行能力。
2. Agent 模式的關鍵限制：檔案閱讀不完整
此限制會影響複雜專案和大型程式碼檔案。
- 在 Cursor 的 Agent 模式下，預設情況下會讀取檔案的前 250 行。如果需要更多內容，它有時會自動再擴展 250 行。對於某些定義明確的任務，Cursor 會執行搜尋，每次搜尋最多返回 100 行程式碼。
- Windsurf 預設情況下每次讀取 200 行，如有必要，最多重試 3 次，總共最多讀取 600 行。
3. 對於單個檔案操作，Cursor 的效能優於 Windsurf
在 Cursor 中，如果您 @ 指定檔案，它將嘗試盡可能完整地讀取檔案（測試最多 2000 行）。
在 Windsurf 中，@ 檔案僅僅幫助它找到相關檔案，但不會提示完整讀取該檔案。這是兩種工具之間邏輯上的關鍵區別。
4. 當您了解專案結構時：Cursor 在單個檔案聚焦方面表現更好
如果您知道自己在做什麼，並且您的任務與特定檔案相關，則在 Cursor 中使用 @ 將焦點放在單個檔案上會產生更好的結果。相反，使用 @codebase 無法確保 Cursor 會將所有相關程式碼包含在上下文中。相反，它使用較小的模型來分析和總結每個檔案，導致必要的程式碼覆蓋不完整。
3. 測試過程
以上所有結論均基於我每天大量使用 Cursor 和 Windsurf（500 多小時）以及有針對性的測試。在這次測試中，我使用了一個包含 1,955 行的影片字幕檔案。字幕檔案包含時間戳記和鬆散耦合的內容，因此很容易確定 AI 程式設計工具是否真正讀取了檔案以及讀取了多少內容——沒有留下任何「猜測」的空間。
為確保工具確實是「閱讀」而不是通過 Retrieval-Augmented Generation (RAG) 來總結，我在每 500 行隨機插入不相關的內容。這些隨機插入的內容包括：
• 「花生最喜歡的運動是網球。」
• 「花生最喜歡的籃球隊是湖人隊。」
• 「花生喜歡戴白色圓頂帽。」
• 「花生最喜歡的食物是螳螂蝦。」
測試回合：
回合 1：Cursor Composer（普通模式）
Cursor 沒有主動定位或讀取字幕檔案，導致任務失敗。
回合 2：Cursor Composer（Agent 模式）
在 Agent 模式下，Cursor 找到並讀取了字幕檔案，但只讀取了 250 行。
回合 3：Windsurf Cascade（預設 Agent 模式）
Windsurf 找到並讀取了字幕檔案，嘗試讀取三次，但只讀取了 600 行。
回合 4：Cursor Compose（單個檔案 @ 模式）
通過明確 @ 檔案，Cursor 完全讀取了所有 1,955 行，第一次返回準確的結果。它還通過了隨機的「陷阱」問題，證實它確實讀取了內容。
回合 5：Cursor Compose（@codebase 模式）
Cursor 總結了影片的內容，但所有陷阱問題都失敗了。這表明在此模式下，Cursor 使用較小的模型執行多次讀取，並且只將總結後的資訊返回到上下文中。
回合 6：Windsurf Cascade（單個檔案 @ 模式）
在 Windsurf 中明確 @ 檔案仍然只會產生 600 行的總結，證實它沒有完全讀取檔案。
在不同場景中使用 Cursor 和 Windsurf 的建議
- 將每個程式碼檔案保持在 500 行以下。這確保檔案保持在 Cursor Agent 可以嘗試兩次讀取的範圍內。
- 在程式碼檔案的前 100 行中清楚地記錄每個程式碼檔案的功能和實現邏輯。使用註釋使 Agent 更容易索引和理解檔案的目的。
- 對於初學者或初始階段的簡單專案，Windsurf 更有效。Windsurf 擅長處理新使用者的簡單任務和專案。
- 對於檔案超過 600 行的複雜專案。如果您熟悉該專案，了解您的任務並知道哪些程式碼檔案相關，則使用 Cursor 並明確 @ 相應的檔案將產生最佳結果。
- 經常重新啟動對話。例如，完成新功能或修復錯誤後，重新啟動互動有助於防止長時間的上下文污染專案。
- 定期在專用檔案（例如 README.md）中記錄專案的狀態和結構。這允許 Cursor 和 Windsurf 在重新啟動對話時快速了解專案的狀態，最大限度地減少引入過多或不必要上下文的風險。
注意：本文經花叔授權翻譯和重新發布。原文連結：https://mp.weixin.qq.com/s/Fl-K-tdRuhlT9I-bcLbtdg
