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 为什么必须最后接？