第四章：控制 AI 的記憶：.cursorrules 撰寫心法與 Context 上下文遮蔽技巧

在使用了 AI 編輯器 (如 Cursor) 一段時間後，你一定會發現一個現象：AI 好像有一種「預設的固執」。例如，它總是喜歡用舊版的 React 語法，或者總是忘記你喜歡用 Tailwind 而硬塞原生 CSS 幫你排版。

要解決這個問題，我們需要深入理解如何控制 AI 的「系統記憶」，也就是 Vibe Coding 的核心武器：.cursorrules 檔案，以及強大的上下文 (Context) 遮蔽技巧。

什麼是 .cursorrules？

.cursorrules 是專屬於 Cursor 編輯器的一種特殊檔案（通常放在專案的根目錄）。它的作用等同於給 AI 的「最高指導原則 (System Prompt)」。

每當你在 Cursor 裡發問時，AI 都會偷偷先把 .cursorrules 讀過一遍，然後再回答你的問題。這就像是給你的 AI 助手制定了一本「員工手冊」。

完美的 .cursorrules 該怎麼寫？

一份好的 .cursorrules 不應該落落長，而應該簡準狠，針對你的專案技術棧進行約束。以下是一份專為 Next.js App Router 打造的黃金範本：

# 專案技術棧
- 框架：Next.js 14+ (App Router)
- 語言：TypeScript
- 樣式：Tailwind CSS
- UI 元件：Shadcn UI, Framer Motion
- 資料庫：Supabase (PostgreSQL)

# 開發原則
1. **嚴格使用 App Router 規範**：所有的路由必須放在 `src/app` 下，不要使用舊版的 `pages` 路由。
2. **Client Components**：如果元件需要使用 `useState`, `useEffect` 或任何互動事件 (onClick)，必須在檔案第一行加上 `"use client";`。
3. **Tailwind 優先**：禁止寫自定義的 CSS 檔案或 Inline Styles，全部使用 Tailwind Utility Classes。
4. **型別安全**：所有 API Response 和 Props 都必須定義嚴格的 TypeScript Interface。禁止使用 `any`。

# 回覆風格要求
- 給我程式碼時，請只給我「修改的部分」或是「完整的檔案」，不要省略關鍵邏輯。
- 請用繁體中文回答。
- 在給出解法前，先簡短思考一下可能的地雷（例如 Hydration Error）。

把這段文字存成專案根目錄的 .cursorrules，你會發現你的 AI 瞬間變成了懂你心意的資深同事！

上下文 (Context) 遮蔽技巧

除了 .cursorrules 給予全域記憶外，我們在發問時常常會遇到「AI 讀了太多檔案導致精神錯亂」的問題。

在 Cursor 中，預設情況下它可能會掃描你目前打開的所有 Tabs，或者根據關鍵字亂找檔案。這就是為什麼有時候你明明在改 Header.tsx，它卻跑去修改你的 Footer.tsx。

技巧一：明確指定檔案 (@ Files)

在 Cursor 的 Chat 框中，永遠養成習慣打出 @ 來手動指定你要 AI 看的檔案。例如：

@PricingPage.tsx @PricingCard.tsx 請幫我把 PricingPage 傳進來的 props 接到 PricingCard 裡。

透過明確指定，你就是在幫 AI 戴上眼罩，告訴它：「除了這兩個檔案，其他都不准看！」這樣它的注意力就會 100% 集中，答對率直線上升。

技巧二：屏蔽不需要的雜訊 (.cursorignore)

有些檔案是 AI 絕對不該去看的，例如：

package-lock.json
.next/
編譯出來的 dist/ 或 build/

通常 Cursor 會自動忽略它們，但如果你有自定義的巨大 Log 檔或暫存資料夾，你可以建立一個 .cursorignore 檔案（語法和 .gitignore 一樣），避免 AI 把寶貴的 Token 浪費在閱讀無用的雜訊上。

技巧三：清除對話記憶 (New Chat)

這是最常被忽略的技巧。一個 Chat 視窗的記憶是有上限的（Context Window）。當你跟 AI 討論了 50 輪，解決了 3 個不同的 Bug 後，AI 的腦袋裡充滿了各種被廢棄的程式碼片段。

這時候，如果你繼續問第 4 個新問題，它極有可能會把之前的廢棄邏輯混進來。

最佳實踐：一個 Task，一個 Chat。 只要你完成了一個獨立的小功能，並且 Git Commit 了，就果斷按下 Cmd/Ctrl + L 清除對話，或者開啟一個 New Chat。讓 AI 保持大腦清醒，是 Vibe Coding 高效率的關鍵。

總結

用 .cursorrules 鎖死專案技術棧與開發規範。
提問時善用 @ 指定具體檔案，減少 AI 亂讀文件的機會。
隨時清理對話，一個任務一個 Chat，保持 AI 的思路清晰。

掌握了 Context 控制術，你就真正從一個「AI 使用者」，晉升為「AI 指揮官」了！

📝 .cursorrules 實戰範例

一個完整的 .cursorrules 設定

你是一個專業的 Next.js 14 全端工程師。

## 技術棧
- Next.js 14 (App Router)
- TypeScript (strict mode)
- Tailwind CSS
- Supabase (PostgreSQL + Auth)
- Zustand (狀態管理)

## 程式碼規範
1. 所有元件使用 Arrow Function 寫法
2. Props 必須定義 TypeScript interface
3. Server Component 優先，只有需要互動性時才加 "use client"
4. 資料庫查詢使用 Supabase SDK，不要直接寫 SQL
5. 錯誤處理使用 try/catch，不要吞錯誤

## 重要限制
- 不要使用 Pages Router 的寫法
- 不要使用任何已棄用的 Next.js API
- 檔案組織：`src/app/路由/` + `src/components/` + `src/lib/`

Context 遮蔽技巧

當你處理一個大型檔案時，不要讓 AI 看到整個專案的程式碼。只要給 AI 需要的部分：

❌ 錯誤：把整個 src/ 資料夾都丟給 AI

✅ 正確：
「我正在修改 src/components/ProductCard.tsx，
它依賴 src/types/product.ts 中的 Product interface，
以及 src/lib/api.ts 中的 fetchProduct 函數。
其他檔案不需要看。」

這種做法叫做 Context Minimization，能大幅提升 AI 的輸出品質！

關鍵要點

✅ Vibe Coding = 用自然語言描述需求，AI 生成程式碼
✅ 精準的 Prompt = 角色 + 目標 + 格式 + 約束
✅ AI 鬼打牆時：打斷重來 > 繼續糾纏
✅ .cursorrules / CLAUDE.md 是規範 AI 行為的關鍵
✅ Terminal 報錯訊息是 AI 除錯最重要的線索

Prompt 框架

角色：你是一個 [資深 Python 工程師]
目標：[幫我建立一個 FastAPI 使用者 CRUD API]
格式：[回傳完整的 Python 程式碼]
約束：[使用 Pydantic v2, SQLAlchemy async, PostgreSQL]

📁 專案結構的 Context 管理

常見檔案結構與對應的 Context 策略

| 專案規模 | 檔案數量 | Context 策略 | |---------|:--------:|-------------| | 小型 (< 20 檔案) | 少 | 直接把整個專案給 AI 看 | | 中型 (20-100 檔案) | 中等 | 只給 AI 相關的 3-5 個檔案 | | 大型 (100+ 檔案) | 多 | 先讓 AI 產生架構圖，再逐個實作 |

AI 的 Context 極限

不同 AI 模型的 Context Window 大小不同：

| 模型 | Context Window | 約當文字量 | |------|:-------------:|:----------:| | GPT-4o | 128K tokens | ~10 萬字 | | Claude 3.5 Sonnet | 200K tokens | ~15 萬字 | | Gemini 1.5 Pro | 1M tokens | ~75 萬字 |

但請注意：即使 AI 可以「看到」這麼多文字，當 Context 接近上限時，AI 的輸出品質會急遽下降。Context 越少，AI 越聰明！

API 除錯：前端 + 後端

前端 API 除錯

| 工具 | 用途 | |:----|:----| | 瀏覽器 Network Tab | 查看請求/回應的詳細內容 | | Postman | 隔離測試 API（不透過前端） | | curl | Terminal 中快速測試 |

常見 API 錯誤

| HTTP 狀態碼 | 原因 | 解法 | |:----------|:----|:----| | 401 | 未登入或 Token 過期 | 重新登入取得新 Token | | 403 | 沒有權限 | 檢查使用者的角色和權限 | | 422 | 請求資料格式錯誤 | 檢查 JSON Body 的欄位和型態 | | 429 | 請求太頻繁（Rate Limit） | 加上延遲或減少請求頻率 | | 5xx | 伺服器錯誤 | 檢查伺服器日誌 |

下一章預告：完整除錯案例

學會各類除錯技巧後，下一章透過真實案例展示完整的除錯流程。