Cursor 上下文與定製
上下文與定製相關的 Cursor 官方教學中文版。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| 定製手段 | customization | Rules / MCP / Skills / Subagents / Hooks / 外掛。 |
| 按問題選 | problem-first | 從需求反查該用哪個定製。 |
| 最小夠用 | minimal | 能用輕的不用重的。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你在 Cursor 的各種定製手段裡選對該用哪個。
你是 Cursor 定製選型顧問，幫我從一個需求出發，選對該用 Rules、MCP、Skills、Subagents、Hooks 還是外掛。
【角色】
你掌握 Cursor 各定製手段的定位：Rules 約束行為、MCP 接外部、Skills 複用流程、Subagents 拆分、Hooks 事件檢查、外掛擴充套件，能按最小夠用選型。
【輸入】
- 我要解決的具體問題：___
- 一次性還是反覆用：___
- 涉及外部系統 / 多角色 / 自動檢查嗎：___
- 個人用還是團隊：___
【工作流程】
1. 判斷內建能否解決
2. 按問題特徵匹配定製手段
3. 說明為什麼不選其他
4. 給落地下一步
【輸出規範】
▌一、內建能否解決
▌二、推薦的定製手段 + 理由
▌三、為什麼不選其他
▌四、落地下一步
【硬約束】
- 能用內建就不上定製，能用輕的不用重的
- 一次聚焦一個手段，不堆疊
- 選型理由對應具體問題
- 高風險手段提醒收緊
- 不確定的機制標註需查對應專題
- 給的建議具體可執行解決反覆貼上背景、重複解釋專案規範、工具接入混亂、團隊規則不可複用的問題。這一組是 Cursor 的上下文層——Rules、MCP、Skills、Subagents、Hooks、Commands 和 Plugins 決定 Agent 能看見什麼、遵守什麼、什麼時候自動觸發。
閱讀方式：先看判斷和路徑，再進入具體章節。Cursor 的資料變化很快，模型、價格、用量和企業策略以官方頁面為準。
Rules
用 Project/User/Team Rules 和 AGENTS.md 管理長期指令。
MCP
把外部工具和資料來源接入 Cursor Agent。
Skills
用 Skills 封裝可複用工作流和任務知識。
Subagents
用 Subagents 拆分複雜任務和專業角色。
Hooks
用 Hooks 在關鍵事件上執行檢查和自動化。
Plugins
理解 Cursor 外掛與定製系統的關係。
這組解決什麼
Cursor 的 Agent 能力越強，越需要穩定上下文。上下文與定製層負責三件事：
- 讓 Agent 自動讀取長期規則，而不是每次重新貼上。
- 讓外部系統透過 MCP、外掛或命令變成可控工具。
- 讓團隊把重複工作沉澱成 Skills、Subagents、Hooks 或 Commands。
如果沒有這一層，Cursor 很容易變成“每次靠一條長 prompt 臨時發揮”。有了這一層，Agent 每次進入專案都能先理解邊界、工具和驗收標準。
學習順序
建議按風險從低到高學習：
- Rules：先把穩定約定寫清楚。
- MCP：再接外部工具和資料來源。
- Skills：把可複用任務流程封裝起來。
- Subagents：複雜任務再拆角色，不要一開始就多 agent。
- Hooks / Commands：最後再做自動觸發和命令化。
- Plugins：只在需要擴充套件能力時引入，並檢查許可權和來源。
這個順序能避免剛入門就把許可權面開啟。Rules 是最輕的複用，MCP 和外掛會引入外部系統，Hooks 則可能在你沒有顯式要求時執行動作。
驗收標準
每一種定製能力都要能回答四個問題：
- 它什麼時候觸發。
- 它能讀取或修改什麼。
- 它失敗時如何暴露錯誤。
- 它是否需要團隊級 review。
如果回答不出來，就先不要放進共享專案。尤其是 MCP 和 Hooks，設定錯誤會讓 Agent 拿到過大的工具面，或者在不合適的時機執行命令。
和 Agent 工作流的關係
Agent 工作流是一次任務的執行迴圈；上下文定製是讓每次執行前都自動帶上正確背景。比如“不要動生成檔案”“提交前跑 typecheck”“所有 API 改動必須補測試”這類規則，應該從 prompt 遷移到專案規則或 Hook。這樣團隊成員不用記住每條約定，Agent 也更少偏離專案標準。
推薦落地方式
真實專案裡可以這樣推進：
- 先把已有團隊約定整理成 Rules。
- 把只讀外部資訊接入 MCP，例如文件、issue、記錄或搜尋。
- 把重複任務封裝成 Skills，例如“排查構建失敗”“補測試”“生成 release note”。
- 對高風險自動化先做 dry run，再考慮 Hook。
- 所有會寫入、上傳、刪除或提交的能力都要有人工確認邊界。
這種順序能讓定製系統逐步變強，同時保持可審查。不要在第一天同時啟用 MCP、Hooks、Subagents 和外掛市場，否則很難判斷一次錯誤來自哪裡。
維護檢查
每次 Cursor 或團隊流程升級後，回看這些設定：
- Rules 是否仍然準確。
- MCP token 和 tool allowlist 是否過寬。
- Skills 是否有過期命令。
- Hooks 是否還能在本地和 CI 中穩定執行。
- Plugins 是否仍來自可信來源。
上下文定製不是一次性設定。它會隨著專案結構、工具鏈和團隊規範變化，需要定期清理。
如果一個設定已經沒有人能解釋用途，就先移除或降級為手動命令。可解釋性比功能數量更重要，也更適合團隊長期維護、協作和覆盤。
先少後多，才可控、可查、可恢復、可覆盤。這是底線。