AI 编辑器扩展机制详解：MCP、Rule、Skills
本文系统性地介绍 AI 编辑器的三大扩展机制，帮助开发者理解如何通过这些机制扩展 AI 能力、规范 AI 行为、封装 AI 技能。
目录
概述
现代 AI 编辑器（如 Cursor、GitHub Copilot、Codebuddy 等）不仅是代码补全工具，更是一个可扩展的智能开发平台。通过三大扩展机制，开发者可以：
| 机制 |
作用 |
类比 |
| MCP |
让 AI 能连接外部系统 |
给 AI 装"手脚" |
| Rule |
让 AI 按规范工作 |
给 AI 立"规矩" |
| Skills |
让 AI 拥有专业能力 |
给 AI 教"本事" |
┌─────────────────────────────────────────────────────────────┐
│ AI 编辑器扩展生态 │
├─────────────────┬─────────────────┬─────────────────────────┤
│ MCP │ Rule │ Skills │
│ 外部工具连接 │ 行为约束规则 │ 能力技能包 │
│ (执行层) │ (约束层) │ (能力层) │
└─────────────────┴─────────────────┴─────────────────────────┘
一、MCP - 工具连接协议
1.1 什么是 MCP？
MCP (Model Context Protocol) 是一个开放协议，让 AI 助手能够直接调用外部工具和数据源。
1.2 核心价值
在没有 MCP 之前：
用户 → AI → "帮我获取测试用例"
↓
AI 只能说：请运行命令 `npx ts-node index.ts fetch`
↓
用户手动执行命令
↓
用户把结果粘贴给 AI
↓
AI 分析结果
有了 MCP 之后：
用户 → AI → "帮我获取测试用例"
↓
AI 直接调用 MCP 工具 fetch_test_cases()
↓
MCP Server 执行操作，返回结构化数据
↓
AI 直接拿到结果，继续处理
1.3 架构图
┌─────────────┐ MCP 协议 ┌─────────────┐
│ AI 编辑器 │ ←──────────────→ │ MCP Server │
│ (Cursor等) │ JSON-RPC 通信 │ (你的工具) │
└─────────────┘ └─────────────┘
│ │
│ 调用工具 │ 执行操作
↓ ↓
"fetch_test_cases" 读取文件/调用API
│
↓
返回结果
1.4 核心组件
| 组件 |
作用 |
示例 |
| MCP Server |
提供工具的服务端 |
自定义的工具服务 |
| MCP Client |
AI 编辑器内置的客户端 |
Cursor、Copilot 等 |
| Tool |
具体的功能单元 |
fetch_test_cases、read_file |
| Resource |
可访问的数据源 |
文件、数据库、API |
1.5 代码示例
MCP Server 定义工具：
// mcp-server.ts
server.setRequestHandler(ListToolsRequestSchema, async () => {
return {
tools: [
{
name: 'fetch_test_cases',
description: '从后端接口获取测试用例',
inputSchema: {
type: 'object',
properties: {
use_mock: { type: 'boolean' }
}
}
}
]
}
})
AI 直接调用：
// AI 自动调用，无需用户干预
fetch_test_cases({ use_mock: true })
// 返回结构化数据
{
"success": true,
"data": [...],
"total": 5
}
1.6 常见 MCP 工具
| 工具类别 |
示例工具 |
用途 |
| 文件操作 |
read_file, write_file |
读写文件 |
| 代码执行 |
execute_command |
执行命令 |
| 数据库 |
query_database |
查询数据库 |
| API 调用 |
fetch_api |
调用外部 API |
| 版本控制 |
git_status, git_commit |
Git 操作 |
二、Rule - 行为约束规则
2.1 什么是 Rule？
Rule 是约束 AI 行为的规则，让 AI 按特定方式和规范工作。
2.2 核心价值
用户请求 ──→ AI 检查 Rule ──→ 按 Rule 约束执行
↓
"必须先写测试"
"代码风格要符合 xxx"
"禁止使用某些 API"
2.3 Rule 类型
| 类型 |
触发方式 |
说明 |
| always |
始终生效 |
全局约束，每次交互都生效 |
| manual |
手动触发 |
用户明确要求时才生效 |
| requested |
按需调用 |
AI 根据上下文决定是否应用 |
2.4 Rule 示例
# 编码规范 Rule
## 代码风格
- 所有函数必须有 JSDoc 注释
- 禁止使用 any 类型
- 变量命名使用 camelCase
- 常量使用 UPPER_SNAKE_CASE
## 安全规则
- 禁止硬编码密钥和敏感信息
- SQL 查询必须参数化
- 用户输入必须校验和转义
## 工作流规则
- 修改代码前先写测试
- 提交前检查 lint 错误
- 重要修改需要代码审查
## 禁止事项
- 不要删除现有注释
- 不要修改 .env 文件
- 不要直接修改 node_modules
2.5 Rule 文件结构
项目根目录/
├── .cursor/
│ └── rules/ # Cursor 规则目录
│ ├── coding.md # 编码规范
│ ├── security.md # 安全规范
│ └── workflow.md # 工作流规范
├── .github/
│ └── copilot-instructions.md # GitHub Copilot 规则
└── .codebuddy/
└── rules/ # Codebuddy 规则目录
2.6 Rule 作用范围
| 范围 |
说明 |
示例 |
| 用户级 |
对所有项目生效 |
个人编码偏好 |
| 项目级 |
只对当前项目生效 |
项目代码规范 |
| 文件级 |
只对特定文件生效 |
组件开发规范 |
三、Skills - 能力技能包
3.1 什么是 Skills？
Skills 是封装好的能力包，包含 Prompt 模板、工具调用和领域知识，让 AI 拥有特定领域的专业能力。
3.2 核心价值
用户请求 ──→ AI 加载 Skill ──→ 使用 Skill 中的能力处理
↓
Prompt 模板
工具调用
领域知识
3.3 Skills 组成要素
| 要素 |
说明 |
示例 |
| Prompt 模板 |
预定义的指令模板 |
代码审查清单、设计模板 |
| 工具调用 |
自动调用的工具 |
lint、test、format |
| 领域知识 |
专业领域的知识 |
最佳实践、常见问题 |
| 输出格式 |
标准化的输出结构 |
Markdown、JSON |
3.4 Skills 示例
# Skill: code-review
## 触发条件
用户说"帮我审查代码"或"review this code"时激活
## 执行步骤
1. 读取目标代码文件
2. 执行 lint 检查
3. 执行单元测试
4. 按清单逐项审查：
- 代码风格
- 安全问题
- 性能问题
- 可维护性
5. 输出分级报告
## 审查清单
### 安全性
- [ ] 无 SQL 注入风险
- [ ] 无 XSS 漏洞
- [ ] 敏感数据已脱敏
### 性能
- [ ] 无 N+1 查询
- [ ] 无内存泄漏风险
- [ ] 算法复杂度合理
### 可维护性
- [ ] 函数职责单一
- [ ] 命名语义清晰
- [ ] 注释恰当
## 输出格式
### Blocker（必须修复）
- 问题 1：描述 + 位置 + 修复建议
### Major（重要问题）
- 问题 1：描述 + 位置 + 修复建议
### Minor（小问题）
- 问题 1：描述 + 位置 + 修复建议
3.5 常见 Skills 类型
| 类型 |
说明 |
示例 Skill |
| 开发类 |
代码开发相关 |
组件生成、API 设计 |
| 质量类 |
代码质量保障 |
代码审查、故障排查 |
| 文档类 |
文档编写相关 |
API 文档、README 生成 |
| 流程类 |
开发流程相关 |
Git 工作流、CI/CD 配置 |
| 分析类 |
代码分析相关 |
性能分析、依赖分析 |
四、三者关系与协作
4.1 协作流程图
┌──────────────────────────────────────────────────────────────┐
│ 用户请求 │
│ "帮我审查这段代码" │
└─────────────────────────┬────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ Rule (约束层) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ • "审查时必须检查安全问题" │ │
│ │ • "输出必须按 Blocker/Major/Minor 分级" │ │
│ │ • "每个问题必须包含位置和修复建议" │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────┬────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ Skill (能力层) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 加载 code-review 技能包 │ │
│ │ • Prompt: 如何审查代码的指令 │ │
│ │ • 知识: 常见代码问题清单 │ │
│ │ • 步骤: 逐个检查点执行 │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────┬────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ MCP (执行层) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 调用工具执行具体操作 │ │
│ │ • read_file: 读取代码文件 │ │
│ │ • read_lints: 获取 lint 错误 │ │
│ │ • execute_command: 执行测试 │ │
│ └────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ 输出结果 │
│ • Blocker: 1 个（SQL 注入风险） │
│ • Major: 2 个（缺少错误处理） │
│ • Minor: 3 个（命名不规范） │
└──────────────────────────────────────────────────────────────┘
4.2 职责划分
| 机制 |
职责 |
回答的问题 |
| Skill |
决定做什么 |
"要完成什么任务？" |
| Rule |
决定怎么做 |
"要遵循什么规范？" |
| MCP |
负责具体执行 |
"如何执行操作？" |
4.3 类比理解
| 机制 |
现实类比 |
AI 编辑器类比 |
| MCP |
程序员的电脑和工具 |
AI 操作外部系统的能力 |
| Rule |
公司的规章制度 |
AI 必须遵守的规范 |
| Skills |
程序员的专业技能 |
AI 的领域专业能力 |
4.4 配合示例
场景：开发一个 Vue 组件
1. Skill: 加载 "Vue 组件开发" 技能包
- 获取组件模板
- 获取最佳实践
2. Rule: 应用项目规范
- 组件命名规范
- Props 定义规范
- 样式规范
3. MCP: 执行具体操作
- read_file: 读取现有组件
- write_file: 创建新组件
- execute_command: 运行 lint
五、实际应用场景
5.1 场景一：代码审查
| 步骤 |
使用机制 |
具体内容 |
| 1 |
Skill |
加载 code-review 技能包 |
| 2 |
Rule |
应用安全规范、代码风格规范 |
| 3 |
MCP |
调用 read_file、read_lints、execute_command |
5.2 场景二：API 开发
| 步骤 |
使用机制 |
具体内容 |
| 1 |
Skill |
加载 api-design 技能包 |
| 2 |
Rule |
应用 API 设计规范、安全规范 |
| 3 |
MCP |
调用 write_file、execute_command |
5.3 场景三：故障排查
| 步骤 |
使用机制 |
具体内容 |
| 1 |
Skill |
加载 debug 技能包 |
| 2 |
Rule |
应用排查流程规范 |
| 3 |
MCP |
调用 search_content、execute_command、read_file |
5.4 场景四：技术方案设计
| 步骤 |
使用机制 |
具体内容 |
| 1 |
Skill |
加载 system-design 技能包 |
| 2 |
Rule |
应用架构设计规范 |
| 3 |
MCP |
调用 search_content、read_file、write_file |
六、最佳实践
6.1 MCP 最佳实践
| 实践 |
说明 |
| 工具单一职责 |
每个工具只做一件事 |
| 明确输入输出 |
使用 TypeScript 定义清晰的类型 |
| 错误处理 |
所有工具都应有完善的错误处理 |
| 文档完善 |
每个工具都应有清晰的描述和使用说明 |
| 安全控制 |
敏感操作需要用户确认 |
6.2 Rule 最佳实践
| 实践 |
说明 |
| 分类管理 |
按类型（编码、安全、流程）分类存放 |
| 简洁明确 |
规则表述要清晰，避免歧义 |
| 适度约束 |
不要过度约束，保留灵活性 |
| 版本控制 |
Rule 文件应纳入 Git 版本控制 |
| 团队共识 |
Rule 应是团队共同认可的规范 |
6.3 Skills 最佳实践
| 实践 |
说明 |
| 场景明确 |
每个 Skill 针对明确的场景 |
| 步骤清晰 |
执行步骤应清晰可循 |
| 输出标准 |
输出格式应标准化 |
| 可复用 |
设计时应考虑复用性 |
| 持续优化 |
根据使用反馈持续改进 |
6.4 组合使用最佳实践
┌─────────────────────────────────────────────────────────────┐
│ 推荐的组合策略 │
├─────────────────────────────────────────────────────────────┤
│ 1. 先定义 Rule，建立规范基础 │
│ 2. 再封装 Skills，沉淀团队能力 │
│ 3. 最后开发 MCP，连接必要系统 │
│ 4. 三者配合，形成完整的 AI 辅助开发体系 │
└─────────────────────────────────────────────────────────────┘
七、总结
7.1 一句话总结
| 机制 |
一句话 |
| MCP |
给 AI 装"手脚"，让它能操作外部系统 |
| Rule |
给 AI 立"规矩"，让它按规范工作 |
| Skills |
给 AI 教"本事"，让它拥有专业能力 |
7.2 协作关系
Skill 决定做什么 → Rule 决定怎么做 → MCP 负责具体执行
7.3 价值体现
| 机制 |
价值 |
| MCP |
扩展 AI 能力边界，让它能做更多事 |
| Rule |
规范 AI 行为，确保输出符合预期 |
| Skills |
封装团队能力，提升开发效率和一致性 |
7.4 未来展望
随着 AI 编辑器的发展，三大机制将更加成熟：
- MCP：更多标准化工具，更便捷的接入方式
- Rule：更智能的上下文感知，更灵活的约束机制
- Skills：更丰富的技能生态，更精准的场景匹配
掌握这三大机制，将帮助开发者更好地利用 AI 编辑器，提升开发效率和代码质量。
参考资料