Cursor 的三板斧：Rules, Commands 与 Agent Skills
Posted on Mon 12 January 2026 in Journal
| Abstract | Cursor 的三板斧：Rules, Commands 与 Agent Skills |
|---|---|
| Authors | Walter Fan |
| Category | learning note |
| Status | v1.0 |
| Updated | 2026-01-12 |
| License | CC-BY-NC-ND 4.0 |
Cursor 的三板斧：Rules, Commands 与 Agent Skills
工具的上限，取决于你怎么"调教"它。
一个让我汗颜的发现
前几天，我看到一个同事用 Cursor 写技术设计文档。
他敲了一行 /design-doc 用户认证服务重构 @JIRA-12345，然后喝了口咖啡。等他放下杯子，一篇结构完整的设计文档已经生成好了——背景、目标、方案对比、架构图描述、API 设计、风险评估，一应俱全。更神奇的是，它还自动从 Jira ticket 里提取了需求背景。
我愣了三秒钟。
我用 Cursor 也快一年了，但我的用法还停留在"Tab 补全"和"Cmd+K 问问题"的阶段。这就像买了一辆特斯拉，结果只用来听收音机。
那天之后，我花了一周时间研究 Cursor 的 Rules、Commands 和最近大热的 Agent Skills。越研究越觉得：这东西的能力边界，远比我想象的大。
今天这篇文章，我想把这些东西掰开揉碎，讲清楚它们是什么、为什么重要、怎么用。
What：这三样东西到底是什么？
1. Cursor Rules：给 AI 立规矩
一句话定义：Rules 是你写给 AI 的"行为准则"，告诉它"你是谁、你怎么做事、你有什么偏好"。
它存放在 .cursor/rules/ 目录下，是一个 Markdown 文件（通常带 .mdc 后缀）。
举个例子，我的 core.mdc 里写着：
---
alwaysApply: true
---
# Author Background & Writing Style
## Background (who I am)
- I'm an "old programmer" focused on backend/server development...
- Tech Stack: Java / C++ / Python / Go / JavaScript
- Domain: Telephony, database, networking, WebRTC, collaboration platforms and Web Service governance
## Writing voice (how I write)
- Prefer a "senior columnist / tech blogger" voice
- Tone: humorous but restrained
- Style: conversational Chinese by default
有了这个 Rules，每次我让 Cursor 帮我写东西，它就知道：
- 我是个老程序员，别跟我整花里胡哨的
- 我喜欢中文写作，偶尔夹杂英文术语
- 我的风格是"有料但不装"
Rules 的本质：它是一个持久化的 System Prompt，让 AI 记住"你是谁"。
2. Cursor Commands：给 AI 下任务
一句话定义：Commands 是你预设的"任务模板"，用 /command-name 触发，让 AI 按照你定义的流程执行复杂任务。
它存放在 .cursor/commands/ 目录下，也是 Markdown 文件。
比如我的 design-doc.md：
# Design Doc Generator
你是一位资深架构师，擅长编写清晰、完整的技术设计文档。
## Usage
- `/design-doc <feature-name>` - 生成设计文档
- `/design-doc <feature-name> @<jira-ticket>` - 从 Jira 提取背景
## Instructions:
1. 如果提供了 Jira ticket，先读取需求背景
2. 按照公司模板生成设计文档：
- Background & Motivation
- Goals & Non-Goals
- High-Level Design
- Detailed Design (API, Data Model, Sequence Diagram)
- Alternatives Considered
- Risks & Mitigations
- Timeline & Milestones
3. 使用 PlantUML 生成架构图和时序图
4. 输出到 `docs/design/` 目录
当我输入 /design-doc 用户认证服务重构 @JIRA-12345，Cursor 就会：
- 通过 MCP 调用 Jira API，读取 JIRA-12345 的需求描述
- 按照我定义的模板结构生成设计文档
- 自动生成 PlantUML 图表
- 创建文件到指定目录
Commands 的本质：它是一个可复用的 Prompt 模板 + 工作流定义。
3. Agent Skills：给 AI 加技能
一句话定义：Agent Skills 是一种轻量级、开放的格式，用于扩展 AI Agent 的能力，为它提供专业知识和工作流。
根据 Agent Skills 官方规范，一个 Skill 本质上就是一个包含 SKILL.md 文件的文件夹：
my-skill/
├── SKILL.md # 必需：指令 + 元数据
├── scripts/ # 可选：可执行代码
├── references/ # 可选：参考文档
└── assets/ # 可选：模板、资源
SKILL.md 的结构很简单：
---
name: design-doc-generator
description: Generate technical design documents from requirements
---
# Design Doc Generator
## When to use this skill
Use this skill when the user needs to create a technical design document...
## How to generate a design doc
1. Extract requirements from Jira ticket
2. Follow the company template structure
3. Generate PlantUML diagrams
...
Agent Skills 的工作机制（渐进式披露）：
- 发现（Discovery）：启动时，Agent 只加载每个 Skill 的
name和description，知道它大概能干什么 - 激活（Activation）：当任务匹配某个 Skill 的描述时，Agent 读取完整的
SKILL.md指令 - 执行（Execution）：Agent 按照指令执行，按需加载引用的文件或执行捆绑的代码
这种设计的好处是：保持 Agent 响应速度的同时，让它能按需获取更多上下文。
另一个相关概念：MCP（Model Context Protocol）
MCP 是 Anthropic 提出的协议，让 AI 能够调用外部工具：
- 读取文件系统
- 执行终端命令
- 调用外部 API（Jira、GitLab、Confluence 等）
- 访问数据库
- 操作浏览器
在 Cursor 里，这些能力通过 MCP Server 提供。你可以把它理解为"AI 的手和脚"。
Skills vs MCP 的关系： - Skills 定义"做什么"和"怎么做"（知识和流程） - MCP 提供"能做什么"（工具和能力）
两者结合，AI 就不只是个"嘴炮"，而是真的能帮你干活。
Why：为什么这三样东西这么重要？
1. 从"问答机器"到"个人助理"
没有 Rules、Commands、Agent Skills 的 AI，就像一个刚入职的实习生——聪明，但不了解你，不了解公司，不了解项目。每次你都得从头解释一遍背景。
有了这三样东西，AI 就变成了一个"跟了你三年的助理"——知道你的风格、了解你的项目、熟悉你的工作流。
2. 从"一次性对话"到"可复用工作流"
你有没有过这种经历：
花了 20 分钟跟 ChatGPT 调教出一个完美的 Prompt，生成了一篇很棒的内容。 第二天想再用，发现那个 Prompt 找不到了……
Commands 解决的就是这个问题。把好用的 Prompt 固化成 Command，下次一行 /xxx 就能复用。
3. 从"只会说"到"能做事"
传统的 LLM 只能"生成文本"。你问它"帮我创建一个文件"，它只会告诉你"你可以用 touch 命令创建文件"。
有了 Agent Skills 和 MCP： - Skills 告诉 AI "生成设计文档的流程是什么" - MCP 让 AI 能"真的去读 Jira、写文件、调 API"
两者结合，AI 真的可以帮你完成端到端的任务。这是质的飞跃。
How：怎么用好这三样东西？
Step 1：写好你的 Rules
位置：.cursor/rules/core.mdc（或其他 .mdc 文件）
关键要素：
---
alwaysApply: true # 是否始终应用
---
# 1. 你是谁
- 你的背景、角色、专业领域
# 2. 你怎么做事
- 你的写作/编码风格
- 你的偏好和禁忌
# 3. 输出规范
- 格式要求
- 语言要求
- 其他约束
我的经验：
- Rules 不要太长，500 行以内
- 要具体，别写"写得好一点"这种废话
- 可以分多个文件，按场景组织（比如
coding.mdc、writing.mdc）
Step 2：创建你的 Commands
位置：.cursor/commands/xxx.md
基本结构：
# Command Name
一句话描述这个 Command 干什么
## Usage
- `/command-name` - 基本用法
- `/command-name <arg>` - 带参数用法
## Instructions
1. 第一步做什么
2. 第二步做什么
3. ...
## Example
输入：...
输出：...
我常用的 Commands：
| Command | 用途 |
|---|---|
/design-doc |
生成技术设计文档 |
/api-spec |
生成 API 接口规范 |
/code-review |
代码审查 |
/explain-code |
解释代码逻辑 |
/test-cases |
根据需求生成测试用例 |
/release-notes |
生成发布说明 |
Step 3：创建你的 Agent Skills
位置：项目根目录下创建 skills/ 文件夹
根据 Agent Skills 规范，每个 Skill 是一个独立的文件夹：
skills/
├── design-doc/
│ ├── SKILL.md # 必需：指令和元数据
│ ├── templates/ # 设计文档模板
│ │ └── design-template.md
│ └── references/ # 参考资料
│ └── best-practices.md
├── api-spec/
│ ├── SKILL.md
│ └── templates/
│ └── openapi-template.yaml
└── code-review/
└── SKILL.md
一个 SKILL.md 示例（设计文档生成）：
---
name: design-doc-generator
description: Generate technical design documents from Jira requirements, following company standards
---
# Design Doc Generator
## When to use this skill
Use this skill when:
- User needs to create a technical design document
- User mentions "design doc", "TDD", "technical spec"
- User references a Jira ticket for a new feature
## Prerequisites
- Jira MCP configured for reading tickets
- Access to company design doc templates
## How to generate a design doc
### Step 1: Gather requirements
1. Read the Jira ticket using `@JIRA-xxxxx`
2. Extract: summary, description, acceptance criteria, linked epics
### Step 2: Generate document structure
Follow the template in `templates/design-template.md`:
- Background & Motivation
- Goals & Non-Goals
- High-Level Design
- Detailed Design
- Alternatives Considered
- Risks & Mitigations
- Timeline
### Step 3: Create diagrams
Use PlantUML for:
- Architecture diagrams
- Sequence diagrams
- Data flow diagrams
### Step 4: Output
Save to `docs/design/{feature-name}.md`
Step 4：配置 MCP Server
位置：Cursor 设置 → Features → MCP
MCP 提供 Agent Skills 执行时需要的"工具"：
- File System：读写文件
- Terminal：执行命令
- Browser：操作浏览器（Playwright）
- Jira/GitLab：读取项目管理和代码仓库
配置示例（在 Cursor 设置中）：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@anthropic/mcp-filesystem"]
},
"jira": {
"command": "node",
"args": ["path/to/jira-mcp-server.js"]
},
"gitlab": {
"command": "node",
"args": ["path/to/gitlab-mcp-server.js"]
}
}
}
Example：一个完整的工作流示例
假设我要为一个新功能写技术设计文档，我的工作流是这样的：
场景：产品经理在 Jira 上创建了一个 ticket JIRA-12345，要求重构用户认证服务，支持 OAuth 2.0 和 SAML。
1. 触发 Command
/design-doc 用户认证服务重构 @JIRA-12345
2. Cursor 读取 Rules
它知道我是谁、我的团队用什么技术栈、我们的设计文档规范是什么。
比如我的 Rules 里写着：
## 技术栈偏好
- 后端：Java 17 + Spring Boot 3
- 数据库：PostgreSQL
- 缓存：Redis
- 消息队列：Kafka
- 容器化：Kubernetes
## 设计文档规范
- 必须包含：背景、目标、非目标、方案对比、风险评估
- 架构图使用 PlantUML
- API 设计遵循 RESTful 规范
- 必须考虑向后兼容性
3. Cursor 调用 Agent Skills（MCP）
- Jira MCP：读取 JIRA-12345 的需求描述、验收标准、关联的 Epic
- GitLab MCP：查看现有认证服务的代码结构和 API
- File System：读取团队之前的设计文档作为参考
4. Cursor 执行 Command 中定义的流程
- 分析需求，提取关键点
- 生成文档结构
- 撰写各个章节
- 用 PlantUML 生成架构图和时序图
- 列出方案对比（OAuth 2.0 vs SAML vs 自研）
- 评估风险和缓解措施
5. 输出结果
一份完整的设计文档，大概长这样：
# 用户认证服务重构设计文档
## 1. Background & Motivation
当前认证服务基于自研的 Session-based 方案，存在以下问题：
- 不支持 SSO，企业客户接入成本高
- Session 存储在单机内存，无法水平扩展
- 缺乏标准化的 Token 管理机制
## 2. Goals
- 支持 OAuth 2.0 Authorization Code Flow
- 支持 SAML 2.0 SSO
- Token 存储迁移到 Redis，支持水平扩展
## 3. Non-Goals
- 本次不涉及 MFA 改造
- 不改变现有用户数据模型
## 4. High-Level Design
[PlantUML 架构图]
## 5. Detailed Design
### 5.1 API Design
- POST /oauth/authorize
- POST /oauth/token
- GET /oauth/userinfo
### 5.2 Data Model
[Token 存储结构]
### 5.3 Sequence Diagram
[PlantUML 时序图]
## 6. Alternatives Considered
| 方案 | 优点 | 缺点 | 结论 |
|------|------|------|------|
| 自研 OAuth | 灵活 | 开发成本高 | ❌ |
| Spring Security OAuth | 成熟 | 配置复杂 | ✅ |
| Keycloak | 功能全 | 运维成本高 | ❌ |
## 7. Risks & Mitigations
- 风险1：Token 迁移期间服务中断
- 缓解：采用双写策略，灰度切换
## 8. Timeline
- Week 1-2: 核心 OAuth 实现
- Week 3: SAML 集成
- Week 4: 测试和灰度
6. 后续操作
- Cursor 自动创建文件
docs/design/auth-service-refactor.md - 如果配置了 Confluence MCP，还可以直接同步到 Wiki
整个过程，我只输入了一行命令。以前写这样一份设计文档，至少要花半天时间。
一些实用技巧
1. Rules 的分层策略
.cursor/rules/
├── core.mdc # 全局规则，始终生效
├── coding.mdc # 编码相关规则
├── writing.mdc # 写作相关规则
└── project-xxx.mdc # 特定项目规则
用 alwaysApply: true/false 控制是否自动应用。
2. Commands 的命名规范
- 用动词或名词开头：
design-doc、code-review、api-spec - 保持简短：能用一个词就别用两个
- 语义清晰：看名字就知道干什么
3. 善用 @ 引用
在 Cursor 中，你可以用 @ 引用文件、文件夹、Jira ticket、甚至网页：
/design-doc 支付网关重构 @ZOOM-67890
帮我分析 @https://example.com/api-doc 这个 API 文档，生成对应的客户端 SDK
根据 @docs/design/auth-service.md 生成测试用例
4. 迭代优化你的 Prompt
Commands 里的 Prompt 不是一次写好的。我的建议：
- 先写一个"能用"的版本
- 用几次，发现问题
- 针对问题优化 Prompt
- 重复 2-3，直到满意
总结
| 概念 | 是什么 | 解决什么问题 |
|---|---|---|
| Rules | AI 的行为准则（持久化 System Prompt） | 让 AI 记住"你是谁"、你的偏好和规范 |
| Commands | 预设的任务模板（可复用 Prompt） | 让复杂任务一行命令触发 |
| Agent Skills | 专业知识和工作流（SKILL.md + 资源） |
让 AI 掌握特定领域的"做事方法" |
| MCP | AI 的工具箱（外部能力接口） | 让 AI 能调用文件系统、API、数据库等 |
四者的关系：
Rules（你是谁）+ Commands（做什么）+ Skills（怎么做）+ MCP（用什么工具）
↓
可编程的 AI 助手
三者结合，Cursor 就从一个"智能补全工具"变成了一个"可编程的 AI 助手"。
Checklist：你可以现在就做的事
- [ ] 在
.cursor/rules/下创建你的core.mdc，写下你的背景、技术栈和团队规范 - [ ] 把你常用的文档模板（设计文档、API 规范、测试用例）整理成 Commands
- [ ] 配置 Jira/GitLab MCP，让 AI 能读取你的项目上下文
- [ ] 尝试用
/design-doc生成一份设计文档，体验一下"一行命令完成复杂任务"的快感 - [ ] 把生成的文档分享给同事，收集反馈，持续优化你的 Commands
扩展阅读
- Cursor 官方文档 - Rules
- Cursor 官方文档 - Commands
- Agent Skills 官方文档 - 什么是 Agent Skills，如何编写
- Agent Skills 规范 - SKILL.md 的完整格式规范
- Model Context Protocol (MCP) 介绍
- Anthropic MCP GitHub
- Awesome Cursor Rules - 社区收集的优秀 Rules 示例
最后一句
工具的上限，不取决于工具本身，而取决于你怎么"调教"它。
Rules、Commands、Agent Skills，本质上都是在"教 AI 如何帮你干活"。
教得好，它就是你的超级助理。 教得不好，它就只是一个贵一点的自动补全。
所以，别只是"用"Cursor，要学会"调教"它。
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。