AI 编程中的三大核心概念：Skills、Rules、MCP 到底有什么区别？AI 编程中的三大核心概念：Skills、

AI 编程中的三大核心概念：Skills、Rules、MCP 到底有什么区别？

昨天配置 Cursor 的时候，我突然意识到一个问题：

Rules、Skills、MCP 这些词我都见过，也都多少用过，但真要我一句话讲清楚它们分别解决什么问题、什么时候该用哪个，我一开始还真有点卡壳。

这让我想起前阵子帮朋友搭 AI 编程环境。他问我：

为什么有些内容要写进 Rules，有些要做成 Skills？MCP 又是干什么的？

我当时只能说：“看场景。”

这句话当然没错，但也等于没说。

所以这篇文章想把这三个概念放在一起讲清楚：它们不是同一种东西的不同叫法，而是分别站在 AI 编程工具的三个层面上，解决三类完全不同的问题。

先给一个最简答案：

Rules：约束 AI 的行为，让它按你的项目规范做事。
Skills：扩展 AI 的能力，让它掌握某类专业工作流。
MCP：连接外部系统，让 AI 能访问工具、数据和服务。

如果用一个类比来理解：

Rules 像员工手册。
Skills 像专业培训包。
MCP 像连接外设的 USB-C 接口。

下面展开讲。

1. Rules：AI 的行为准则

Rules 解决的是一个很朴素的问题：**不要让我每次都把同样的要求重复一遍。 **

比如你经常对 AI 说：

TypeScript 不要用 any。
函数命名使用驼峰风格。
不要删除我手动加的调试代码。
修改代码时优先保持现有架构。
写测试时沿用项目里已有的测试风格。

这些要求不是某一次任务独有的，而是项目长期有效的约束。它们就很适合写成 Rules。

Rules 的本质

Rules 是一组持久化指令，通常作用在系统提示词或上下文注入层面，用来告诉 AI：

在这个项目里，你应该遵守哪些行为规范？

它不会让 AI 获得新的外部能力，也不会主动去执行某个工具。它的作用更像“边界”和“习惯”：让 AI 的输出稳定地落在你希望的范围内。

在 Cursor 中，Rules 通常放在：

.cursor/rules/*.mdc

一个简单的例子：

---
description: TypeScript 代码风格和规范
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

# TypeScript 代码风格规范

- 始终使用 TypeScript 严格模式。
- 避免使用 any，优先定义明确类型。
- 函数命名使用 camelCase。
- 修改现有代码时，优先保持原有模块边界。
- 不要删除用户手动添加的调试代码，除非用户明确要求。

Rules 适合写什么？

适合写进 Rules 的内容，一般有三个特征：

长期有效：不是一次性需求，而是项目持续遵守的规范。
项目相关：和当前仓库的技术栈、目录结构、团队习惯有关。
偏约束：它告诉 AI 什么该做、什么不该做，而不是教 AI 一套完整技能。

比如：

代码风格
命名规范
测试要求
安全边界
提交信息格式
项目目录说明
不允许随意重构的模块

Rules 的常见误区

很多人写 Rules 时容易写得太虚，比如：

请写出高质量代码。

这类规则效果通常不好，因为“高质量”太抽象。更好的写法是把期望拆成可执行的行为：

新增业务逻辑时必须补充对应单元测试。
涉及金额计算时使用 decimal 工具函数，不直接使用浮点数运算。
修改公共组件时检查至少一个现有调用方是否受影响。

Rules 越具体，AI 越容易稳定遵守。

2. Skills：AI 的专业技能包

如果说 Rules 是“不要跑偏”，那 Skills 更像是“遇到某类任务时，按这套专业流程来”。

比如你希望 AI 帮你做 API 测试。每次你都解释一遍：

如何分析接口定义
如何设计正常用例和异常用例
如何生成测试数据
如何校验响应结构
如何输出测试报告

这就很适合沉淀成一个 Skill。

Skills 的本质

Skills 是可复用的知识包和工作流说明，用来让 AI 在特定领域表现得更专业。

它回答的问题是：

遇到某类任务时，AI 应该调用哪些知识、遵循什么步骤、产出什么结果？

在 Cursor 中，一个 Skill 通常是一个目录，核心文件是：

.cursor/skills/<skill-name>/SKILL.md

一个极简示例：

---
name: api-testing
description: 用于分析 API、生成测试用例并验证接口响应的测试技能
---

# API Testing Skill

## 适用场景

当用户要求测试接口、补充接口测试、分析 API 稳定性时使用。

## 工作流程

1. 阅读接口定义和现有测试。
2. 区分正常路径、边界条件和异常路径。
3. 生成测试用例。
4. 执行测试或给出可执行的测试代码。
5. 总结覆盖范围和剩余风险。

Skills 适合写什么？

Skills 更适合封装“跨项目可复用”的专业能力，比如：

API 测试
数据库建模
技术文章写作
代码审查
性能分析
安全审计
前端可访问性检查
组件设计规范

它和 Rules 最大的区别是：

Rules 偏“约束”：告诉 AI 不要违反什么。
Skills 偏“能力”：告诉 AI 如何完成某类专业任务。

Skills 的常见误区

不要把项目特定的零散要求都塞进 Skills。

比如：

本项目使用 pnpm。
本项目的用户模块在 src/modules/user。
提交前运行 pnpm test。

这些更适合写进 Rules，因为它们和当前项目强相关。

而像“如何做一次系统化的代码审查”“如何设计数据库表结构”“如何写一篇技术文章”这类通用流程，才更适合做成 Skills。

3. MCP：AI 的外部世界接口

MCP 全称是 Model Context Protocol，是一种让 AI 应用连接外部工具和数据源的开放协议。

如果前面两个概念还主要停留在“提示词和知识”层面，那 MCP 解决的是另一个问题：

AI 怎么安全、标准化地访问外部系统？

比如：

查询数据库
读取文件
调用内部 API
操作 GitHub、Jira、Notion
调用代码分析工具
获取线上监控数据

这些事情不是靠多写几句提示词就能解决的。AI 必须真的能“调用”某个外部能力。

这就是 MCP 的位置。

MCP 的本质

MCP 是一套协议。它定义了 AI 应用和外部工具之间如何通信、如何暴露工具、如何读取资源、如何处理调用结果。

可以把它理解成 AI 工具生态里的“标准接口层”。

一个典型 MCP 架构里有三个角色：

MCP Host：发起请求的 AI 应用，比如 Cursor、Claude Desktop。
MCP Client：Host 内部负责维护连接的客户端。
MCP Server：真正暴露工具、资源或提示的服务。

MCP Server 可以提供很多能力，例如：

query_database：查询数据库
read_logs：读取日志
create_ticket：创建工单
search_docs：搜索内部文档

AI 在需要时可以通过 MCP 调用这些工具，然后基于返回结果继续推理和生成。

一个简单的 MCP Server 示例

以 Python 为例：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("MyServer")


@mcp.tool()
def query_database(query: str) -> str:
    """执行数据库查询"""
    # 这里放真实的数据库查询逻辑
    return "query result"


if __name__ == "__main__":
    mcp.run()

然后在支持 MCP 的客户端中配置这个 Server：

{
  "mcpServers": {
    "my-database-server": {
      "command": "python",
      "args": ["/path/to/mcp_server.py"]
    }
  }
}

MCP 的常见误区

MCP 很强，但不要把它当成万能插件系统。

如果只是想告诉 AI “代码要遵守什么规范”，用 Rules 就够了。

如果只是想让 AI 按某个专业流程完成任务，用 Skills 更合适。

只有当 AI 需要真实访问外部系统、调用工具或读取动态数据时，MCP 才是更自然的选择。

另外，MCP Server 往往能接触敏感数据，比如数据库、文件系统、内部服务，所以一定要重视权限控制、日志记录和最小授权。

三者放在一起怎么理解？

我最推荐的理解方式是看它们分别回答了什么问题。

概念	核心问题	本质	典型场景
Rules	AI 应该遵守什么？	行为约束	代码风格、命名规范、安全边界
Skills	AI 应该如何完成某类任务？	专业能力和工作流	API 测试、代码审查、数据库设计
MCP	AI 如何连接外部系统？	工具和数据协议	查询数据库、读文件、调用 API

再换一个更直观的说法：

Rules 管边界：保证 AI 不乱来。
Skills 管方法：让 AI 更专业地做事。
MCP 管连接：让 AI 能拿到外部世界的信息和能力。

所以它们不是竞争关系，而是互补关系。

一个实际例子：让 AI 重构代码

假设你对 AI 说：

帮我重构这个函数，让它更易读，但不要改变行为。

这时三者可能会这样协同：

Rules 先约束边界

项目规则会告诉 AI：

不要改变函数对外行为。
遵循当前项目命名风格。
不要随意移动公共函数。
修改逻辑时补充或更新测试。

Skills 提供专业方法

如果有一个重构 Skill，它可能会指导 AI：

先理解现有行为。
识别重复逻辑和过长分支。
拆分小函数。
保持输入输出不变。
最后运行测试验证。

MCP 连接外部工具

如果项目配置了 MCP，AI 还可以：

调用代码分析工具查看复杂度。
查询测试覆盖率。
读取相关文档。
调用内部质量平台获取历史问题。

最终结果就是：AI 不只是“凭感觉改代码”，而是在规则约束、专业流程和外部工具支持下完成任务。

什么时候用 Rules、Skills、MCP？

可以用下面这个判断方法：

你的需求	推荐使用	原因
统一代码风格	Rules	这是长期约束
规定命名方式	Rules	这是项目规范
限制不能改某些文件	Rules	这是安全边界
沉淀代码审查流程	Skills	这是可复用专业能力
沉淀 API 测试方法	Skills	这是跨项目工作流
沉淀技术写作方法	Skills	这是专业产出流程
查询数据库	MCP	需要访问外部系统
读取线上日志	MCP	需要动态数据
调用内部平台接口	MCP	需要工具调用

再压缩成三句话：

需要约束行为，用 Rules。
需要复用能力，用 Skills。
需要连接外部系统，用 MCP。

我的实践建议

如果你刚开始搭 AI 编程环境，我建议按这个顺序来：

第一步：先写 Rules

先把最容易重复强调的项目规范写下来。

比如：

技术栈和包管理器
目录结构说明
代码风格要求
测试命令
哪些文件不要随便改
修改前要先阅读哪些上下文

Rules 是投入产出比最高的一步，因为它能立刻减少重复沟通。

第二步：再沉淀 Skills

当你发现某类任务经常重复出现，而且每次都需要一套固定流程，就可以考虑写 Skill。

比如：

每次都要做代码 Review
每次都要写接口测试
每次都要分析慢查询
每次都要写技术文章

这时把流程沉淀下来，AI 后续就更容易稳定复用。

第三步：最后接 MCP

当你明确发现 AI 缺少“访问外部世界”的能力，再考虑 MCP。

比如：

它需要查数据库。
它需要读内部文档。
它需要看线上日志。
它需要调用公司内部平台。

MCP 的收益很大，但复杂度和安全要求也更高，所以不建议一上来就把所有东西都接进去。

从更高一层看：这是 AI 编程工具的三层模型

聊到这里，其实可以抽象出一个更通用的模型。

一个好用的 AI 编程环境，通常需要三层能力：

约束层：让 AI 知道边界在哪里。
能力层：让 AI 掌握可复用的方法。
连接层：让 AI 能接触真实的工具和数据。

对应到今天这三个概念就是：

约束层：Rules
能力层：Skills
连接层：MCP

这个模型不只适用于 Cursor。以后不管你用 Claude Code、Codex、Cline，还是别的 AI 编程工具，都可以用这个框架去判断：

我现在缺的是规则、方法，还是连接？

想清楚这一点，很多配置问题就会变得清楚。

最后

我现在自己的使用方式大概是：

用 Rules 固定项目规范和安全边界。
用 Skills 沉淀可复用的专业流程，比如代码审查、技术写作、测试设计。
用 MCP 连接少量确实有必要的外部系统，比如数据库、文件系统或内部文档。

对我来说，最大的变化是：以前配置 AI 编程工具时，很多东西都混在一起写；现在会先判断它到底属于“约束”“能力”还是“连接”。

这一步想清楚之后，配置就不容易乱。

如果你也在搭自己的 AI 编程工作流，可以先从一个小问题开始：

最近你反复提醒 AI 的那句话，应该写进 Rules、沉淀成 Skills，还是做成 MCP 工具？

如果你想尝试 MCP，可以从官方示例仓库开始看：modelcontextprotocol/servers。

如果你觉得这篇内容对你有帮助：

👍 点赞支持一下作者熬的这些夜
⭐ 收藏起来下次选型时翻出来
💬 评论区聊聊你现在在用什么工具？踩过哪些坑？

我们下期见！ 🚀

🍱 顺便推荐：如果你和我一样经常加班点外卖，可以微信搜索小程序「美豚外卖」——美团/淘宝闪购订单额外返利，一个月省下的钱够再订一个 AI 编程工具。