處理大型程式碼庫會帶來與小型專案不同的挑戰。基於我們擴展 Cursor 自身程式碼庫的經驗，以及來自管理大型程式碼庫客戶的見解，我們發現了一些處理增加複雜性的有用模式。 在本指南中，我們將介紹一些我們發現對大型程式碼庫有用的技術。

​
使用 Chat 快速熟悉陌生程式碼

瀏覽大型程式碼庫，特別是對您來說全新的程式碼庫，可能會很有挑戰性。您經常需要使用 grep、搜尋和點擊來尋找程式碼庫中您要找的特定部分。透過 Chat，您可以開始提問來找到您要尋找的內容，並獲得其運作方式的詳細說明。 在這裡，我們正在尋求協助來找到 Cursor 中程式碼庫索引的實作細節，甚至要求一些範例來讓理解變得更容易。
為了讓 Cursor 對您程式碼庫結構有更深入的理解，請務必從設定中啟用包含專案結構以提升效能。

​
為特定領域知識編寫規則

如果你要讓一位新的協作者加入你的程式碼庫，你會提供什麼樣的背景資訊來確保他們能夠開始做出有意義的貢獻？ 你對這個問題的答案很可能也是對 Cursor 有價值的資訊。對於每個組織或專案，都有一些潛在的知識可能沒有完全記錄在你的文件中。有效使用規則是確保 Cursor 獲得完整資訊的最佳方式。 例如，如果你正在編寫如何實作新功能或服務的說明，考慮寫一個簡短的規則來記錄它以供後續參考。
Boilerplate
---
description: 新增一個 VSCode 前端服務
---

1. **介面定義：**
   - 使用 `createDecorator` 定義新的服務介面，並確保包含 `_serviceBrand` 以避免錯誤。

2. **服務實作：**
   - 在新的 TypeScript 檔案中實作服務，繼承 `Disposable`，並使用 `registerSingleton` 將其註冊為單例。

3. **服務貢獻：**
   - 建立貢獻檔案來匯入和載入服務，並在主要入口點註冊它。

4. **上下文整合：**
   - 更新上下文以包含新服務，允許在整個應用程式中存取。
如果有你希望確保 Cursor 遵循的常見格式化模式，考慮基於 glob 模式自動附加規則。
Formatting
---
globs: *.ts
---
- 使用 bun 作為套件管理器。參見 [package.json](mdc:backend/reddit-eval-tool/package.json) 中的腳本
- 檔案名稱使用 kebab-case
- 函數和變數名稱使用 camelCase
- 硬編碼常數使用 UPPERCASE_SNAKE_CASE
- 偏好使用 `function foo()` 而非 `const foo = () =>`
- 使用 `Array<T>` 而非 `T[]`
- 使用具名匯出而非預設匯出，例如（`export const variable ...`、`export function `）

​
緊密參與計劃制定過程

對於較大的變更，花費超出平均水準的思考來創建精確、範圍明確的計劃，可以顯著改善 Cursor 的輸出品質。 如果您發現在嘗試了同一個提示的幾種不同變化後仍未獲得想要的結果，請考慮退一步，從頭開始創建更詳細的計劃，就像您為同事創建 PRD 一樣。通常困難的部分是弄清楚應該做什麼變更，這是一項非常適合人類的任務。有了正確的指示，我們可以將實作的某些部分委託給 Cursor。 使用 AI 來增強計劃制定過程的一種方法是使用 Ask 模式。要創建計劃，請在 Cursor 中開啟 Ask 模式，並輸入您從專案管理系統、內部文件或零散想法中獲得的任何上下文。思考您在程式碼庫中已知想要包含的檔案和依賴項。這可以是包含您想要整合的程式碼片段的檔案，或者可能是整個資料夾。 以下是一個範例提示：
Planning prompt
- 為我們應該如何創建新功能制定計劃（就像 @existingfeature.ts 一樣）
- 如果有任何不清楚的地方，請向我提問（最多 3 個問題）
- 確保搜尋程式碼庫

@Past Chats（我之前的探索提示）

以下是來自 [專案管理工具] 的更多上下文：
[貼上的工單描述]
我們要求模型創建計劃並通過向人類提問來收集上下文，參考任何早期的探索提示以及工單描述。建議使用像 claude-3.7-sonnet、gemini-2.5-pro 或 o3 這樣的思考模型，因為它們能夠理解變更的意圖並更好地綜合計劃。 基於此，您可以在開始實作之前，在 Cursor 的幫助下反覆制定計劃。

​
選擇合適的工具

有效使用 Cursor 最重要的技能之一就是為工作選擇合適的工具。思考你想要完成什麼，然後選擇能讓你保持流暢狀態的方法。
工具使用場景優勢限制
Tab快速、手動變更完全控制、快速單一檔案
Inline Edit單一檔案中的範圍變更專注編輯單一檔案
Chat較大的多檔案變更自動收集上下文、深度編輯較慢、上下文密集
每個工具都有其最佳使用場景：
  • Tab 是你進行快速編輯時的首選，讓你完全掌控
  • Inline Edit 在你需要對特定程式碼區段進行專注變更時表現出色
  • Chat 非常適合那些需要 Cursor 理解更廣泛上下文的大型變更
當你使用 Chat 模式時（可能感覺有點慢但功能極其強大），透過提供良好的上下文來幫助它幫助你。使用 @files 指向你想要模仿的類似程式碼，或使用 @folder 讓它更好地理解你的專案結構。不要害怕將較大的變更分解成較小的部分 - 開始新的對話有助於保持專注和效率。

​
要點總結

  • 縮小變更範圍，不要一次嘗試做太多事情
  • 盡可能包含相關的上下文資訊
  • 針對 Chat、Inline Edit 和 Tab 各自的優勢來使用它們
  • 經常建立新的對話
  • 使用 Ask 模式 進行規劃，使用 Agent 模式 進行實作