Cursor 12 個技巧 從會用到用得好
用 Cursor 寫 code 1 年、踩過大概 30 個坑、整理出 12 個會明顯讓你變快的技巧。從基本快捷鍵、Composer 用法、@codebase 索引、到 .cursorrules 客製化 ─ 每條都附 code 範例、新手老手都能用。
※ 本文基於 Cursor 2025-2026 年功能、操作介面可能隨版本更新而變動。所有操作可在 Cursor 官方文件交叉確認。
先講一個觀念
Cursor 不是「會 AI 的 VS Code」。它是「會以你的 codebase 為脈絡寫 code 的 AI」。
這個差別很重要 ─ 你會發現自己用得好不好、不取決於「prompt 寫得多好」、取決於「你給它的脈絡準不準」。
下面 12 條技巧、有 8 條是在講「如何給對脈絡」。
基本功 ─ 你應該每天用的4 個
01 用 Cmd+K 改一段、不要全選叫 AI 重寫
新手最常犯的錯:選一大段、按 Cmd+K、輸入「優化這段」。
結果 ─ AI 改了你不想改的地方。
正確做法:選最小範圍、寫具體指令。
// 錯 ─ 整個 function 選起來
"優化這段"
// 對 ─ 只選有問題那行
"把這個 forEach 改成 map、回傳新陣列"
範圍越小、AI 越不會誤改別的地方。
02 Cmd+L 開 Chat 問問題、不要叫它直接改
Chat 跟 Edit 是兩件不同的事:
- Chat (Cmd+L):問問題、討論方向、解釋 code
- Edit (Cmd+K):直接改 code
流程:先 Cmd+L 討論「該怎麼做」、確認方向再 Cmd+K 改。
直接叫 AI 改最容易整個 file 被改爛。
03 用 Tab 接受 autocomplete、用 Esc 拒絕
很多人不知道 ─ 你按 Tab 接受、按 Esc 拒絕、這些動作都會被當成訊號回饋給 Cursor。
不過這不是「你的 Cursor 在即時學你、幫你客製化」─ 官方並沒有這樣講。比較準確的說法是:你的 accept/reject 是改善 Tab 模型的訊號之一、跟全體使用者的訊號一起匯總、拿去疊代訓練、不是針對你個人即時調整。
還是建議兩者都確實按 ─ 用得越準確、你自己也會越清楚什麼建議該收、什麼該丟。
04 切到 Composer、做跨檔案修改
Cmd+K 是改「一個檔案」、Composer (Cmd+I) 是改「整個 feature」。
什麼時候用 Composer:
- 加一個新 feature、需要改 3-5 個檔案
- refactor 一個 module、同時改 backend + frontend
- 把一個 component 從 class 改成 hook
重點 ─ Composer 開啟時、用 @ 指定它要看的檔案。不指定的話它會亂猜。
脈絡管理 ─ 進階的4 個
05 善用 @ 指定脈絡
這是 Cursor 最強的功能、也是最多人忽略的。
幾個關鍵 @ 用法:
@檔名─ 把這個檔案內容當脈絡@codebase─ 整個 project 索引、AI 自己找相關 code@docs─ 引用官方文件(你 setup 過的)
補充:Cursor 2.0(2025-10)之後、@web、@git 這兩個手動符號已經移除、改由 Agent 自己判斷什麼時候該搜網路、該看 git commits/diff、不用你再手動打 @web / @git。
範例:
"@auth.ts @user.ts 把 login 流程加上 OTP、
參考 @docs/twilio 的 SMS API"
這比「請幫我加 OTP」好 5 倍 ─ 因為 AI 知道要看哪些檔案、依哪個 API。
06 用 .cursor/rules/(或 .cursorrules)教它你的編碼風格
在 project root 建 .cursor/rules/ 目錄、裡面放 .mdc 規則檔(也可以簡化用一份 AGENTS.md 或 CLAUDE.md)、Cursor 每次 prompt 都會自動帶入。舊版做法是建一個 .cursorrules 檔 ─ 這個格式已被 Cursor 官方列為 legacy、deprecated、建議遷移到上面的新格式,但寫法概念差不多、下面範例先沿用這個舊格式示範:
範例:
// .cursorrules(舊版格式、官方已 deprecated、建議改用 .cursor/rules/*.mdc)
# Project Conventions
- Use TypeScript strict mode
- Prefer functional components over class components
- Use named exports, no default exports
- All API calls go through `lib/api.ts`
- Tailwind classes go in `className`, no inline styles
# Code Style
- No semicolons
- Single quotes
- 2-space indent
# Testing
- Every new function needs at least 1 unit test
- Use Vitest, not Jest
# Forbidden
- Don't use `any` ─ use `unknown` instead
- Don't use `console.log` in committed code ─ use logger
有這個規則設定、AI 寫出來的 code 風格會跟你的 project 一致、不用每次都改。
07 限制 AI 不要碰哪些檔案
有些檔案你不想讓 AI 碰 ─ 比如 schema migration、env config、test fixtures。
在 .cursorignore 加入:
// .cursorignore
*.env*
migrations/
__fixtures__/
secrets/
*.lock
AI 不會 index 這些檔案、也不會主動改它們。
08 用 @symbol 引用特定 function / class
不要 paste 整個 function 給 AI、用 @symbol 引用:
"幫我寫 `@calculateTax` 的測試、
covering edge case 包含 negative input 跟 zero"
AI 會自動帶上那個 function 的完整實作當脈絡、不用你 copy-paste。
進階心法 ─ 區隔工程師跟vibe coder 的 4 個
09 寫 prompt 時、先講 why、後講 what
差別很大:
// 普通 prompt
"加一個 button、點了會打 API"
// 好 prompt
"用戶反映他們找不到 export 功能。
我要在 settings page 加一個 export 按鈕、
點了會打 /api/export endpoint、
顯示 progress、完成後下載 CSV。
參考 @ImportModal.tsx 的 UX pattern"
講 why 的好處:
- AI 知道是「用戶痛點」、會主動加錯誤處理
- AI 知道 UX 期待、會主動加 loading state
- AI 知道你的脈絡、不會生出跟現有 pattern 矛盾的東西
10 把 AI 當對話對象、不是輸出工具
一個改變我用 Cursor 方式的習慣 ─ 每次大改之前、先用 Cmd+L 跟它討論方案。
流程:
- 我提一個方案:「想把 auth 改成 JWT、有什麼坑?」
- AI 列 5 個 trade-off
- 我反問:「第 3 個你會怎麼處理?」
- AI 回答、我又補充 context
- 最後達成共識、我才開 Composer 動手
這 10 分鐘對話、會省你 2 小時的「寫到一半發現方向錯」。
11 用 小步快跑、不要一次 prompt 一大堆
很多人會這樣 prompt:
"幫我做一個完整的部落格系統:
- 用戶登入
- 文章 CRUD
- 評論
- 訂閱
- Newsletter
- 後台管理"
結果 ─ AI 生出來的東西 80% 是廢的、要你自己拆。
正確做法 ─ 一次只請它做一件小事:
- 先:「做用戶 schema + register / login API」
- review、調整、commit
- 再:「做文章 model + CRUD API」
- review、調整、commit
- …
一次一小步、每步都 review。這樣最後成果 90% 你 OK、不是 80% 你要丟掉。
12 教它說「我不確定」
AI 最大的問題不是「會犯錯」、是「不知道自己錯」、會給你假裝很有自信的錯誤答案。
在你的 rules 檔(.cursor/rules/*.mdc、或舊版的 .cursorrules)加這條 ─ 我覺得效果很顯著:
# Communication
- If you're not sure about something, say "I'm not sure"
- If you need more context, ASK before writing code
- Never invent library APIs ─ if you don't know if a method exists, say so
- Cite the file/line you're referring to when making claims
有這條後、AI 會在不確定時主動問你、而不是亂寫一通。
最後 ─ 不要把Cursor 當神
Cursor 是工具、不是 senior engineer。它的價值 ─ 取決於你給它什麼樣的脈絡跟指令。
用得好的人、會發現自己變得更專注在「定義問題、設計方案、做決策」上 ─ 寫 code 變成最不花時間的事。
用得不好的人、會發現自己變成「AI 給什麼我貼什麼」的搬運工 ─ 6 個月後 codebase 變成自己看不懂的廢墟。
Cursor 給你速度。
你的工程紀律給你方向。
沒方向的速度、就是車禍。
延伸閱讀 ─ AI 時代工程師系列
常見問題
- Cmd+K、Cmd+L 和 Composer 差在哪?我該用哪個?
- Cmd+K 改單一檔案的一小段,Cmd+L 開 Chat 討論方向、問問題但不直接改 code,Composer 則負責跨多個檔案的整個 feature。文章建議先用 Cmd+L 討論確認方向,再用 Cmd+K 或 Composer 動手改。
- .cursorrules 現在還能用嗎?是不是被淘汰了?
- 還能用,但 Cursor 官方已把它標為 legacy、deprecated,建議改用 .cursor/rules/ 目錄放 .mdc 規則檔,或用一份 AGENTS.md、CLAUDE.md。兩者概念一樣,都是讓 AI 寫出的 code 自動符合你專案的編碼風格。
- 該不該用一個 prompt 就叫 Cursor 把整個功能做完?
- 不該。一次塞太多,AI 生出來約 80% 是廢的、還要你自己拆。文章建議小步快跑,一次只請它做一件小事,做完就 review、調整、commit 再進下一步,這樣最後成果約 90% 你會 OK。