你用 Cursor 寫了三個月的 code，每次開新 chat 還是要重新解釋：「我們用 Next.js App Router」「不要用 default export」「CSS 用 Tailwind 不要寫 inline style」。
這不是 Cursor 笨。是你沒告訴它規則。
Cursor Rules 是 Cursor 最被低估的功能。它讓你把專案的上下文、慣例、禁止事項寫成一份文件，AI 在每次對話中都會自動讀取。寫好 Rules，等於幫你的 AI 助手做了一次完整的 onboarding。
新舊格式：.cursorrules vs .cursor/rules
先搞清楚兩種格式的差異，因為很多網路教學混在一起講。
舊格式：.cursorrules
專案根目錄放一個 .cursorrules 檔案，寫什麼都行，Cursor 會在每次對話時自動載入。簡單粗暴，但有明顯限制：只能有一個檔案、沒有條件載入、內容一多就變成垃圾場。
新格式：.cursor/rules/
2025 年底 Cursor 推出的新系統。在 .cursor/rules/ 目錄下放多個 .mdc 檔案，每個檔案有 frontmatter 可以設定：
---
description: TypeScript coding conventions
globs: **/*.ts, **/*.tsx
alwaysApply: false
---
- 使用 named export，不用 default export
- 優先使用 interface 而非 type
- 錯誤處理使用 Result pattern
關鍵差異：
- 多檔案：你可以按主題拆分（coding style、架構規範、API 慣例）
- globs：指定這條 rule 只在特定檔案類型生效
- alwaysApply：設為
true時每次對話都載入，設為false時只在符合 globs 的檔案被編輯時才載入 - auto-attach：Cursor 會根據你正在編輯的檔案自動選擇相關的 rules
建議：直接用新格式。舊的 .cursorrules 還能用，但新格式的組織能力完全不在一個級別。
為什麼 99% 的人沒寫好 Rules
三個常見問題：
第一，太空泛。 「寫乾淨的 code」「遵循最佳實踐」——這種 rule 等於沒寫。AI 需要的是具體的、可執行的指令。不是「寫好的 code」，是「函式超過 20 行就拆分」「API response 統一用 { data, error } 格式」。
第二，太冗長。 有人把整個 coding style guide 貼進去，三千行。Rules 會佔用 context window，太長反而降低 AI 的理解品質。每條 rule 控制在一句話，整份檔案不超過 50 行。
第三，沒有分層。 把框架規範、業務邏輯、UI 慣例全部混在一個檔案裡。當 AI 在寫一個 API endpoint 的時候，它不需要知道你的按鈕圓角是 rounded-xl。用新格式的多檔案 + globs 來分層。
好的 Rules 包含什麼
一份有效的 Rules 通常涵蓋四個層面：
1. 專案上下文
告訴 AI 這個專案是什麼、用了什麼技術、有什麼特殊的架構決策。
- 這是一個 Next.js 15 App Router 專案
- 後端使用 Supabase（auth、database、storage）
- 部署在 Vercel
- 使用 pnpm 作為套件管理器
- monorepo 結構，packages/ 下有共享模組
2. 程式碼慣例
具體的寫法規定，越具體越好。
- 使用 named export，不使用 default export
- React 組件使用 function declaration，不用 arrow function
- 狀態管理用 Zustand，不用 Redux
- 資料抓取用 server component + fetch，不用 useEffect
- 樣式用 Tailwind utility classes，不寫 CSS modules
3. 禁止事項
明確告訴 AI 什麼不能做。這往往比告訴它該做什麼更有效。
- 不要使用 any type
- 不要在 client component 裡直接呼叫資料庫
- 不要用 useEffect 做資料抓取
- 不要在 commit message 裡寫「fix bug」或「update code」
- 不要在沒有 loading 和 error state 的情況下做 async 操作
4. 格式與結構
檔案怎麼組織、命名怎麼規定。
- 組件檔名用 PascalCase：UserProfile.tsx
- 工具函式檔名用 camelCase：formatDate.ts
- API route 放在 app/api/ 下，用 route.ts
- 共享型別放在 types/ 目錄
- 每個組件資料夾包含 index.ts 做 re-export
實戰範例：Next.js + TypeScript 專案
以下是一個實際可用的 rules 結構：
.cursor/rules/
├── general.mdc # 專案上下文，alwaysApply: true
├── typescript.mdc # TS 慣例，globs: **/*.ts, **/*.tsx
├── react.mdc # React 組件規範，globs: **/*.tsx
├── api.mdc # API route 規範，globs: app/api/**/*
├── database.mdc # Supabase 查詢慣例，globs: **/db/**/*
└── testing.mdc # 測試規範，globs: **/*.test.ts
general.mdc 設 alwaysApply: true，確保 AI 永遠知道專案的基本資訊。其他檔案透過 globs 自動匹配——你在寫 API route 的時候，api.mdc 會自動載入；寫測試的時候，testing.mdc 會自動載入。
進階技巧
Per-folder rules：在子目錄放 .cursor/rules/ 可以覆蓋上層的規則。適合 monorepo 中不同 app 有不同慣例的情況。比如 apps/blog/ 用 contentlayer，apps/docs/ 用 fumadocs——各自的 rules 各自管。
Description 要寫好：description 欄位不是裝飾。當 alwaysApply 為 false 時，Cursor 用 description 來判斷要不要載入這條 rule。寫清楚它的適用場景，比如「Rules for writing Supabase RLS policies」而不是「database stuff」。
定期維護：Rules 不是寫一次就不管了。每次你發現 AI 又犯同一個錯，就去加一條 rule。每次你發現某條 rule 從來沒生效，就刪掉或改寫。把它當成活文件。
寫 Rules 的 Rules
最後一個後設建議：Rules 的品質取決於你對自己專案的理解程度。
如果你寫不出 rules，通常不是因為你不會寫——是因為你還沒想清楚自己的專案到底有哪些慣例。這個釐清的過程本身就有價值。它迫使你把隱性知識變成顯性規則，而這些規則不只幫 AI，也幫未來的你自己、幫你的協作者。
一個人開發不代表沒有規範。有規範的一人團隊，比沒有規範的五人團隊走得更遠。
想看更多 AI 開發工具的實戰設定？我們在 開發者工具教學 裡整理了從 Cursor 到 Claude Code 的完整配置指南。