前不久，Cursor 設計總監 Ryo Lu 在 X 上發布了若干最佳實踐建議(https://x.com/ryolu_/status/1914384195138511142)：

圖片

內容基本匹配我的使用體感，工具始終是工具，即使如 Cursor，效果好壞最終還是取決于”用的人“。

使用得當的 Cursor 可以讓你寫出快速、干凈的代碼；使用不當，它會生成讓你清理一周的 AI 意大利面代碼。

本文將圍繞這一核心觀點，結合實際經驗，擴展聊聊 Ryo Lu 給出的建議。從項目規劃到代碼實現、從提示設計到錯誤修復，我們將逐條介紹正確用法、常見誤區以及實戰技巧。

整體而言，請將 Cursor 視作一個強力但需要引導的初級工程師：你提供清晰規范和持續指導，它才能發揮最大價值。

1.  設置 5-10 條清晰的項目規則（使用 /generate rules 命令）

誤區：很多人剛上手 Cursor 時并不了解 Cursor Rules 規則，導致 AI 按默認設置自行發揮風格，導致 AI 輸出代碼風格前后不一致、偏離團隊規范，非常影響效率

正確用法：在項目之初創建一個精煉的 Cursor 規則文件（.cursor/rules），包含 5-10 條明確、可執行的編碼規范。這些規則可通過 Cursor 的命令如 /Generate Cursor Rules 生成初稿，再根據項目需要調整完善。內容上可以包括：

• 編碼風格指南（例如“使用 ESLint Standard 風格”）；
• 架構約定（如“組件應為函數式組件”）；
• 依賴限定（如“禁止使用未經批準的第三方庫”）等。

規則既不要太多也不要模棱兩可——就像團隊的編碼規范一樣，簡明扼要，覆蓋關鍵點。

將規則文件放在 .cursor/rules 目錄下，Cursor 會自動讀取其中的約定來指導代碼生成。例如，你的規則里規定“所有接口請求必須使用封裝的 fetchClient 庫”，那么當你讓 Cursor 生成接口調用代碼時，它會遵循這個約定。不設置規則時，AI 可能隨意使用 axios 或原生 fetch 導致不符合項目要求。如果規則過多或表述不清，也可以逐步調整：觀察 AI 輸出是否違背了某條約定，若是，優化規則表述或范圍。

將這些規則視作對新人開發者的指導手冊——簡潔明確，讓 Cursor 明白哪些行為是項目中“允許”或“禁止”的，從而減少后續返工。

2.  提示語要具體清晰，像寫 Mini-Spec 一樣明確技術棧和行為約束

誤區：很多工程師一開始給 Cursor 下達的指令（Prompt）過于籠統，例如：“幫我寫一個登錄頁面”。這樣模糊的提示常常導致 AI 輸出偏離預期——可能生成舊式的 jQuery 代碼，或忽略必要的錯誤處理。模棱兩可的提示就好比給新人一個含糊的需求描述，結果對方各自發揮想象，產出不符合要求的代碼。

正確用法：編寫提示語時要具體且清晰，就像撰寫一個小型技術規格說明（mini-spec）,明確指出技術棧、需求細節和任何行為約束。例如，可以這樣提示 Cursor：

使用 React 18 + TypeScript，實現一個登錄表單組件。
 要求：
 1. 使用 Ant Design UI 庫；
 2. 包含用戶名、密碼兩個字段和提交按鈕；
 3. 前端驗證輸入格式，錯誤信息用紅色文本顯示；
 4. 按鈕點擊后調用 login(api) 接口，處理 loading 狀態和錯誤提示；
 5. 遵循我們團隊的 ESLint 規則和文件結構。”

當然，這部分技術約束也可以用 /Generate Cursor Rules 指令生成到 rules 中。

這樣的提示涵蓋了技術棧（React 18 + TS、Ant Design）、功能細節（表單字段、驗證、調用接口等）以及行為約束（團隊 ESLint 規則、結構）。Cursor 在接到這樣的明確指令后，就如同拿到了詳細的產品需求和技術方案，生成的代碼更有針對性。總之，提示語越像規范書寫，AI 輸出就越精確。

另外，建議在 Prompt 注明關鍵事項：框架版本、需遵守的模式（如“使用 hooks 實現而非類組件”）、特殊邊界情況處理等等。你也可以引用外部文檔鏈接提供參考——例如使用某庫時，在提示里附上官方文檔鏈接，Cursor 會據此采用正確用法。

當提示涵蓋足夠上下文，AI 就不必胡亂猜測。如果你發現輸出不符合預期，應反思提示是否遺漏了關鍵細節，及時補充重試。這種“窮盡細節”的提示思路就像資深工程師給新人寫任務說明，確保對方按正確方向完成任務。

3.  按文件逐步推進，每次生成、測試、評審一個小目標

誤區：有人希望 Cursor 一步生成整個項目的代碼結構或多個模塊的實現，貪圖省事一氣呵成。現實是，一次性讓 AI 產出大量代碼，往往伴隨結構混亂、錯誤難查的問題——就像讓一個初級工程師一天之內寫完整個應用，結果可想而知。大段未經檢查的 AI 代碼堆疊在一起，最終可能演變為需要花一周去梳理的“AI 意大利面”。

正確用法：采用增量式、迭代式的方式推進開發節奏，每次聚焦在一個小目標上，生成代碼，立即測試和評審，然后再進行下一個目標。

具體做法是按照功能或文件將項目拆解。例如，先創建項目骨架文件結構；接著讓 AI 完成一個組件或一個模塊；完成后運行測試或構建，檢查是否有錯誤，再微調修復。每一步完成后，再進行下一步開發。通過這種逐步推進的方法，確保每個部分都經過驗證再集成，減少后期大改的風險。

人類智能在應對開發任務時尚且需要做好技術方案、任務拆解、里程碑劃定等，何況是 AI？因此，在實戰我們需要擁有模塊化思維，將具體任務拆解為若干復雜度適當的小任務。例如在開發一個 Web 頁面時：

• 先讓 Cursor 生成布局框架（如路由、導航欄）；
• 確認無誤后，再讓它處理某個頁面的邏輯，如登錄流程；
• 然后再實現其它頁面或組件。

每次只專注一到兩個文件的改動，利用 Cursor 的上下文記憶保持風格一致。這樣一來，每個階段輸出的代碼你都心中有數。如果某一步 AI 產出了問題代碼，范圍也局限在最近修改的文件，更易于定位和修復。把 Cursor 當作新人時，這就相當于給TA分配一個個小任務，逐項完成、審核通過，再繼續下一個，保證整體質量。

4.  所有 AI 輸出都需人工審閱、手動修復，修復內容可作為學習示例反饋給 Cursor

誤區：相信 AI 會百分之百正確是一大誤區。有人拿到 Cursor 輸出的代碼后不經檢查就直接合入，結果引入隱蔽 bug 或性能問題；還有一種誤區是完全依賴 AI 自我修正，比如發現錯誤就反復提示 Cursor “這里錯了幫我改”，期待 AI 完美改好。但實際上，AI 并不了解自己輸出的正確性，需要人工把關，而且不斷地讓 AI 猜你的反饋不如直接糾正來得高效。

正確用法：將 AI 輸出視為初稿 或輔助結果，始終由人來審閱確認。拿到 Cursor 生成的代碼后，逐行閱讀和理解，就像在做 Code Review。一旦發現可疑之處或錯誤，優先選擇手動修改來確保正確性。

實踐中，不妨養成這樣的習慣：先信任但核實。拿到 AI 代碼后，運行本地構建或測試用例驗證功能；若有報錯或與預期不符，記錄下問題。對于小問題直接改，大問題則考慮重新提示 AI。在反饋給 AI 時，語氣友善但明確，指出問題原因和你的修復措施。這不僅提高后續結果質量，也幫助你加深對代碼的理解。切記：AI 給出的代碼永遠不應不經思考就直接投入生產。正如帶新人，任何新人寫的代碼也需要資深工程師審核后才能合并一樣——Cursor 寫的代碼也必須經過你的審閱和調整才能算真正可用。

人工修復可以是修正算法、調整代碼風格、添加遺漏的邊界處理等。完成修復后，可以將修改的內容和原因告訴 Cursor，讓 AI 學習改進。例如，你可以對 Cursor 說：“剛才你生成的代碼在處理空字符串時拋異常了，我將第 10 行改為…來修復這個問題。今后遇到類似情況請注意空值檢查。” 通過這種反饋，Cursor 在同一會話的后續回答中會更注意類似問題，相當于對這個“初級工程師”進行現場指導。當然，也可以用 /Generate Cursor Rules 指令將錯誤信息整理為 Rules，實現長期記憶。

5.  使用 @file、@folder、@git 指令精確設定上下文范圍

誤區：讓 Cursor 在全局上下文下回答復雜問題或修改代碼，容易出現答非所問或牽連過多的問題。如果不限定作用范圍，AI 可能因為獲取了過多無關信息而跑題，或者錯誤地修改了本不該動的代碼。

例如，你只是想讓 AI 修改 utils.js 中的一個函數，卻沒指定范圍，Cursor 可能考慮到整個項目其他文件，結果給出一些全局性改動建議，增加混亂。

正確用法：Cursor 提供了 @file、@folder、@git 等指令用于在提示中嵌入特定范圍的上下文，精確告訴 AI 聚焦在哪些內容上。正確使用這些指令可以大大提高 AI 回答的相關性：

• 使用 @file：將單個文件內容添加到提示上下文。例如在對話中輸入 @file path/to/utils.js，Cursor 會讀取該文件內容供 AI 參考。這樣當你讓 AI “重構這個文件的某函數”時，它心里有數，只會基于提供的文件內容進行改寫。
• 使用 @folder：將整個文件夾下的相關文件內容納入上下文。這在涉及模塊間交互時很有用，比如你要求 AI 修改組件 A 并相應更新組件 B，使用 @folder components/ 可以讓 AI 理解組件目錄下的結構關系，再進行一致性修改。
• 使用 @git：將 Git 提交記錄、差異（diff）或 Pull Request 內容提供給 AI。例如在讓 Cursor 協助寫提交信息或檢查最近一次提交是否有遺漏時，使用 @git diff 或 @git <commit_hash> 能讓 AI 聚焦在該次改動上進行分析。

實戰中，每當你希望 AI 針對特定代碼回答，先用 @file 或高亮選中代碼片段再發問。這樣 Cursor 幾乎就像人在讀那個文件然后回答你。如果需要讓 AI 同時參考多個文件，可以多次使用 @file（注意上下文長度），或者提前把相關內容整合到一個臨時筆記文件中一起嵌入。當修改范圍較大時，考慮用 @folder 掃描整體。使用 @git 場景下，先做好 commit，再引用 diff 供 AI 審查或生成描述，這不僅讓回復更準確也融入了版本控制流程。

總之，精準設定上下文范圍能讓 Cursor 少走彎路，只專注你關心的部分，避免“牽一發動全身”式的誤操作。

6.  將設計文檔和清單放入代碼中，提供完整上下文

誤區：很多時候，AI 之所以寫出風馬牛不相及的代碼，是因為它不了解整個項目的大局。例如，你的項目有一份模塊設計說明書或接口契約，但是 AI 并不直接知道；或者團隊有特定的開發流程清單，但 AI 無從獲知。如果我們每次提問都只說局部需求，而不讓 Cursor 知道全局背景，那么AI就像閉門造車，代碼與設計初衷南轅北轍。

正確用法：善用 Cursor 提供的項目上下文功能，將總體設計和關鍵文檔納入AI上下文。

具體而言，可以把設計文檔、需求說明、架構圖解說明、開發檢查清單等資料放在項目的.cursor/目錄下，這等價于在新人入項時，先給他一份完整的項目說明書參考：AI 清楚項目的背景和目標，自然能寫出更貼合整體設計的代碼。

比如，你在 .cursor/ 下添加了文件 design.md，里面描述了系統的整體架構、模塊職責，以及關鍵的數據結構。又例如放一個 api-checklist.md，列出每個接口在實現時都需要考慮的事項（參數驗證、錯誤處理、日志等）。當 Cursor 知道這些信息后，你讓它實現某個具體功能時，它會自動結合文檔給出的指引。如果文檔中注明“模塊A不直接調用數據庫，而通過模塊B提供的服務”，那么 AI 在實現模塊A時就不會貿然寫數據庫查詢，而會調用模塊B的接口。這樣就避免了偏離架構的實現。如果文檔或清單較長，你也可以在對話中用 @file .cursor/design.mdc 明確引用相關部分，讓 AI 聚焦關鍵段落。

總之，提供完整上下文能極大提升AI理解正確性的上限，別讓 AI 閉眼造輪子，給它盡可能多的“項目全景圖”，它才能像一個有全局觀的新成員一樣工作。

7.  遇到錯誤代碼，直接手寫修復比長篇解釋更快更有效

誤區：當 Cursor 生成的代碼出現錯誤時，一些用戶傾向于反復和 AI 討論錯誤、要求 AI 修復，希望 AI 自行悟出正確答案。然而這常常效率低下——Cursor 可能多次嘗試仍未解決問題，或者曲解了你的提示。

畢竟AI 對復雜bug的調試能力有限，與其苦口婆心地解釋錯誤原因，不如直接更正代碼來得干脆。把時間都花在教 AI 修 bug 上，往往得不償失。

正確用法：在發現AI輸出的代碼存在明顯錯誤或設計缺陷時，優先考慮由你直接修改代碼。

人類智能通常能快速定位錯誤根源并給出修復方案，而 AI 有時會在錯誤的方向上越糾結越亂。這就像指導初級工程師：有些復雜問題你與其讓新人試錯，不如你示范解決一次，讓他從中學習。在 Cursor 的場景中，你可以親自編寫修復后的代碼，然后在下一次與 AI 交互時，把修改部分給它看，讓它明白哪里修正了。

例如，Cursor 生成了一段算法但結果不正確。你調試后發現是某個邊界條件處理不當。這時，與其對 Cursor 說“大于多少的情況錯了，請修復”，不如你直接修改代碼（可能只需幾行）確保正確運行。然后告訴 Cursor：“我發現對于空數組輸入你的實現返回了 undefined，所以我增加了一個判斷返回空數組，修改如下…”。這樣一來，你立刻解決了問題，也把正確思路反饋給 Cursor。一些情況下，如果錯誤很多，你甚至可以暫停 AI 幫助，自己集中修改一輪，把代碼整理好再繼續使用 AI 輔助。

另外 Cursor 本身提供了“Bug Finder”之類的簡單自動調試功能，但可靠度有限，人工介入往往必要。所以始終記住，人是最后的保險：當AI卡殼時，不妨親自動手，用你的專業知識迅速掃清障礙，再讓 Cursor 接棒繼續其余簡單工作。

8.  善用聊天記錄進行迭代，而非每次重啟 Prompt

誤區：有些用戶習慣遇到新問題就開啟一個全新的對話或重新寫提示，認為這樣可以“從頭再來”避免前文干擾。實際上，頻繁重置上下文會丟失寶貴的歷史信息：AI 不再記得先前你們確定的命名約定、討論過的設計決策、前面生成的相關函數等等。相當于每次都換了一個新新人接手項目，新人對已有代碼一無所知，必然重復走彎路甚至引入不一致的實現。

正確用法：應當充分利用 Cursor 對話的上下文記憶能力，在同一會話內持續迭代。

也就是說，當完成一個階段后，直接基于上一次對話繼續提問或下達下一個任務，不要輕易清空上下文或開新窗口。Cursor 會保留之前的對話內容（在其上下文窗口容量范圍內），包括你提供的文件、反饋的修改、既定的規則等。借助這些記憶，AI 在后續生成時會遵循先前的風格和約定，并能引用前面產生的代碼片段。除非當前對話變得雜亂不堪或上下文長度超限，否則不要輕易“推倒重來”。

舉個例子，在一個連續的對話里，你先讓 Cursor 創建了組件A，然后下一步要求組件B與A交互。因為在同一會話中，Cursor 記得組件A的實現和接口，它在寫B時就能直接調用A的函數，而不需要你再次提供A的細節。這保證了組件A和B之間接口的一致性。又比如你之前規定了某變量命名風格（駝峰或下劃線），AI 此時也會保持一致。如果中斷上下文，新會話里AI可能又換另一種命名，讓代碼風格混雜。只有在不得已（比如長時間對話后模型開始遺忘早期內容）時，才考慮總結要點開啟新對話，并在新對話開頭把關鍵信息重新提供給 Cursor。

總之，把一次對話當作和同一個工程師持續合作：時間越長他對項目理解越深，成果也就越契合。

9.  有意識地選擇模型

誤區：并非所有 AI 模型的風格和特長都相同。如果不加分辨一律使用默認模型，你可能錯過更優的解題思路或更高效的配合方式。有的人全程只用某一個模型，結果在需要復雜推理的場景下效率低下，或者在要求精準代碼的場景下得到了啰嗦且不可靠的輸出。這就像帶新人團隊里只讓一個人干所有事，即使他并不擅長某些任務。

正確用法：了解并善用不同模型的特長，根據任務類型選擇最適合的“AI 同事”。

例如，Claude 系列模型（如 Anthropic Claude 2）以長上下文和推理見長，在需要通識推理、總結長文檔、提出方案思路時表現較好；而 Gemini（假設指類似 GPT-4 或未來的高精度模型）則在代碼準確性和嚴格執行方面更勝一籌，適合生成要求精確符合規范的代碼片段或復雜算法實現。另外，Cursor 支持的其它模型（如 GPT-4、GPT-3.5 等），也各有特點：GPT-4 綜合能力強但可能速度較慢，3.5速度快但需要更仔細驗證結果。根據任務靈活切換模型，能達到事半功倍的效果。

實戰中不妨按照任務來決定：

• 當你需要腦暴/分析時，選 Claude——比如“請閱讀這份大型需求文檔并提煉關鍵點”，Claude 的長上下文優勢可以一次看更多內容并給出條理分析；
• 當你需要精工細作寫代碼時，選 Gemini 或 GPT-4——比如“實現一個二叉樹的復雜算法并確保代碼健壯”，這些模型往往遵循指令嚴格，代碼準確率更高。

另外，你也可以組合使用：先用 Claude 討論方案、生成偽代碼，確定思路后，再用 Gemini 詳細實現，最后用 GPT-4 優化和潤色。這種組合拳能最大化發揮模型所長。當然，切換模型意味著上下文可能不共享，必要時在切換后重提供關鍵信息或文件內容，確保新模型接棒時了解當前進展。將不同模型視作團隊里不同專長的工程師，知人善任，才能讓整個“AI 團隊”高效協作。

10.  對陌生技術棧：貼文檔鏈接，逐行解釋報錯及修復邏輯

誤區：當涉及自己和 AI 都不熟悉的新技術、新框架時，一些人仍然直接讓 Cursor 輸出代碼，結果往往問題百出——AI 可能調用不存在的函數或使用過時的用法，出現大量報錯。如果這時僅靠 AI 自己去糾正，很可能陷入胡猜的死循環：AI 根據錯誤信息修一處又冒出新錯，因為一開始對技術細節理解就不對。

缺乏資料和指導，等于讓新人去摸一個沒人教過的全新領域，碰壁是在所難免的。

正確用法：當你讓 Cursor 涉足一個陌生技術棧時，要像導師帶新人一樣，提前提供學習資料并一同分析錯誤。

具體來說，在提示中附上官方文檔、教程鏈接或關鍵段落，讓 AI 先獲取正確的背景知識。同時，當代碼報錯時，不要只丟給 AI 報錯信息了事，應該逐條解釋錯誤含義并引導修復思路。這種做法實際上是在跟 AI 做結對編程：你提供權威信息，AI 協助總結應用；你指出錯誤癥結，AI 根據你的分析調整代碼。通過你和 AI 的互動來共同攻克新技術。

例如，你第一次使用一個新的圖表繪圖庫，Cursor 可能并不知道具體用法。如果直接讓它寫代碼，編譯可能通不過。這時，你可以在對話中貼上該庫的官方快速開始示例代碼（或提供鏈接），并強調“按照此文檔使用該庫”。Cursor 獲取這些信息后，再讓它嘗試編寫，就會遵循文檔示例格式，成功率大大提高。當出現錯誤提示（無論是編譯錯誤還是運行異常），與其簡單地對 AI 說“報錯了請修”，不如你先閱讀錯誤信息，然后對 AI 解釋：

錯誤提示指出模塊找不到，也許是導入路徑不對，我們需要調整為相對路徑……

通過這種逐行分析錯誤日志的方式，AI 往往能更準確地定位問題并給出修復方案。同時你的解釋過程也加深了自己對新技術的理解。一來一回，你在扮演教練，AI 在配合修正，最終順利搞定以前沒接觸過的技術棧。

結語

把 Cursor 當作可重點培養的潛力新人。

綜上所述，想要高效使用 Cursor 寫出干凈高效的代碼，關鍵在于方法和習慣。我們討論的這 12 條經驗，從制定規則、清晰提問、小步迭代，到測試驅動、人工審查、范圍限定，再到模型選擇、知識補充以及大項目上下文管理，構成了一套系統的使用策略。貫穿始終的理念是：將 Cursor 視作一個強力但需要引導的初級工程師。你要做的就是像帶新人一樣帶領它——給予規范和約束，讓它明確任務邊界；循序漸進分配工作，及時檢查反饋；在需要時提供知識支持，必要時親自上陣修正；針對不足耐心指導改進。

當你這樣使用 Cursor 時，它將不只是一個代碼生成工具，而會逐漸融入你的開發流程，成為值得信賴的“AI 搭檔”。正確使用能讓它發揮驚人的效率優勢，幫你快速產出高質量代碼；而一旦方式不當，它也可能產出令人抓狂的混亂代碼。有了上述指南，希望每一位前端工程師都能駕馭 Cursor 的威力，揚長避短，避免落入 AI 意大利面代碼的陷阱，讓 Cursor 真正成為團隊中提效保質的一份子。今后，隨著你不斷總結和調整這些方法，與你的 AI 小伙伴配合也將越來越默契。