MCP、Skills、Workflows 怎麼分工
解釋 Windsurf 裡外部工具、能力包、手動流程、Hooks 和專案規則的邊界，避免把所有自動化都堆進 MCP。
先一句話講清 MCP：MCP（Model Context Protocol，模型上下文協議） 是一套讓 AI 呼叫外部工具的標準介面——Cascade 透過它能查 GitHub issue、讀資料庫 schema、調內部 API。你可以把它理解成"AI 的 USB 介面"：定一套通用規則，任何外部系統按這套規則接進來，Cascade 就能用。
Windsurf 裡最容易誤用的是 MCP。很多人看到 MCP 就想把所有東西都接進去，結果得到一堆許可權不清、輸出不穩、難維護的工具。正確做法是先判斷需求屬於外部能力、流程步驟、專案規則、複雜能力包，還是自動治理。
本篇目標：把 Rule、Workflow、Skill、Hook、MCP 的職責分開，讓每一層只做它應該做的事。
1. 五層分工
flowchart TB
Need["想讓 Cascade 更會做事"] --> Rule["Rule / AGENTS.md"]
Need --> Workflow["Workflow"]
Need --> Skill["Skill"]
Need --> Hook["Hook"]
Need --> MCP["MCP"]
Rule --> R1["持續行為約束"]
Workflow --> W1["手動 slash command"]
Skill --> S1["模型動態呼叫 + 支援檔案"]
Hook --> H1["動作前後自動校驗/阻斷/日誌"]
MCP --> M1["訪問外部服務和工具"]
style MCP fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Hook fill:#fee2e2,stroke:#dc2626,stroke-width:2px判斷標準：
| 需求 | 推薦機制 |
|---|---|
| “每次修改前先讀專案邊界” | AGENTS.md / Rule |
| “釋出前按固定步驟檢查” | Workflow |
| “原始碼脫敏打包，需要指令碼、模板、檢查清單” | Skill |
| “寫程式碼後自動跑 lint 或阻止讀 secrets” | Hook |
| “查詢 GitHub PR、資料庫 schema、內部 API” | MCP |
2. MCP 只負責外部能力
MCP 是把 Cascade 接到外部工具和服務的協議層。官方 Windsurf MCP 頁面說明，Cascade 作為 MCP client，可以請求 MCP server 暴露的 tools。
適合接 MCP：
- GitHub issue / PR / CI 狀態。
- 資料庫 schema 或只讀查詢。
- 內部搜尋服務。
- 文件檢索。
- 工單系統。
- 瀏覽器或其他外部自動化工具。
不適合接 MCP：
- “React 元件怎麼寫”。
- “每次改動前先看 diff”。
- “釋出前跑哪些檢查”。
- “某目錄不能改”。
這些分別應該寫成 Rule、Workflow、Skill 或 Hook。
MCP 接入順序：
- 先接只讀 server。
- 只啟用必要 tools。
- token 用 env/file/OAuth，不寫死。
- 寫入型 tools 單獨審查。
- 團隊使用 registry、whitelist 和 owner 機制。
3. Workflow 是手動 runbook
Workflow 是 markdown 檔案，儲存在 .windsurf/workflows/ 或全域性目錄，透過 /workflow-name 手動呼叫。官方強調它是 manual-only，Cascade 不會自動呼叫。
適合：
/pre-release-check/review-pr/run-tests-and-fix/security-scan/deployment-check
Workflow 的優點是可控。你明確觸發它，它才執行。高風險流程應該優先用 workflow，而不是讓模型自動決定什麼時候開始釋出或改 PR。
4. Skill 是複雜能力包
Skill 是資料夾能力包，核心是 SKILL.md，可以帶 scripts、templates、checklists、references。官方說明 Windsurf 使用 progressive disclosure：預設只給模型看 skill 的 name 和 description，完整材料只有被呼叫時載入。
適合 Skill：
- 原始碼脫敏打包。
- 安全審計。
- 文件轉換。
- 多步釋出檢查。
- 標準化報告生成。
- 帶指令碼和模板的團隊流程。
description 是觸發條件，不是普通簡介。寫得太泛會誤觸發，寫得太窄會用不上。
5. Hook 是自動治理
Hook 不是提示詞，也不是能力包。官方 Cascade Hooks 頁面說明，Hooks 會在 Cascade 的關鍵動作前後執行 shell command；pre-hook 可以用 exit code 2 阻斷動作。
適合 Hook：
- 阻止讀取
secrets/。 - 寫入受保護檔案前要求人工處理。
- 寫程式碼後自動跑 formatter、lint、test。
- 記錄檔案讀取、寫入、命令執行和模型資訊。
- 企業裝置統一安全策略。
不適合 Hook：
- 長篇寫作規則。
- 多步釋出 runbook。
- 需要模板和指令碼的大能力包說明。
這些仍然應該分別放到 Rule、Workflow 或 Skill。
6. 一個 PR 處理例子
需求：讓 Windsurf 幫團隊處理 PR。
不要直接接一堆工具。先拆：
AGENTS.md：程式碼風格、禁止改動範圍、測試命令。- Workflow：
/review-pr，規定 review 步驟和輸出格式。 - Skill：如果 review 需要公司專用檢查表，把檢查表和指令碼做成 skill。
- Hook：寫程式碼後自動跑格式化或阻斷敏感檔案修改。
- MCP：只讀接 GitHub PR、issue、CI 狀態。
這樣每一層職責清楚，出問題也能定位。
7. 商業團隊安全順序
先做低許可權，再做高許可權：
- 寫 root
AGENTS.md。 - 寫
.codeiumignore。 - 寫低風險 workflow。
- 寫需要模板/指令碼的 skill。
- 寫審計和阻斷 hook。
- 接只讀 MCP。
- 接寫入型 MCP。
- 對寫入型 MCP 加審批、日誌、owner 和撤權。
寫入型 MCP 是最後一步。它一旦接上，Cascade 就可能請求呼叫真實外部系統。沒有許可權模型和審計日誌，不要接生產寫許可權。
官方來源
- Model Context Protocol (MCP) —— 官方 Windsurf MCP 文件。
- Skills —— 官方 Skill、progressive disclosure、scope 和格式說明。
- Workflows —— 官方 workflow、slash command、manual-only 和 precedence 說明。
- Cascade Hooks —— 官方 hooks、pre/post、exit code 阻斷和配置層級說明。
- Memories & Rules —— 官方 Rules、Workflows、Skills、Memories 的對比。
本篇自檢
- 哪些需求應該進 MCP，哪些不應該？
- Workflow 為什麼適合高風險手動流程？
- Skill 的
description為什麼是觸發條件？ - Hook 和 Workflow 的核心差異是什麼？
- 寫入型 MCP 為什麼必須最後接？