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.mdCLAUDE.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 跟它討論方案

流程:

  1. 我提一個方案:「想把 auth 改成 JWT、有什麼坑?」
  2. AI 列 5 個 trade-off
  3. 我反問:「第 3 個你會怎麼處理?」
  4. AI 回答、我又補充 context
  5. 最後達成共識、我才開 Composer 動手

這 10 分鐘對話、會省你 2 小時的「寫到一半發現方向錯」。

11 用 小步快跑、不要一次 prompt 一大堆

很多人會這樣 prompt:

"幫我做一個完整的部落格系統:
- 用戶登入
- 文章 CRUD
- 評論
- 訂閱
- Newsletter
- 後台管理"

結果 ─ AI 生出來的東西 80% 是廢的、要你自己拆。

正確做法 ─ 一次只請它做一件小事:

  1. 先:「做用戶 schema + register / login API」
  2. review、調整、commit
  3. 再:「做文章 model + CRUD API」
  4. 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。

延伸閱讀

正在做東西、卡住了?

每兩週收到一篇工程現場筆記,或直接加 LINE 問我。

訂閱電子報 → 加 LINE 問我