前言
在使用 Cursor 时,你会发现有很多方法可以向 AI 发出指令,例如:AgentS.md、.cursor/rules/、.cursor/commands/、.cursor/skills/、.cursor/agents/(子代理)。每种方法都有不同的特点。
很多人会疑惑:“应该用哪一个?如何区分?”这篇文章总结比较了它们的用法与适合场景,帮助你更好地选择。
为什么需要 Agent Skills(代理技能)
在尝试让 Cursor 负责使用 Next.js/TypeScript 开发 Web 应用时,你可能会遇到这样的状况:
-
“API 路由必须使用 zod进行校验” -
“数据库查询要用 Prisma 的类型安全方式” -
“错误处理统一格式返回”
这样的规则在一个会话可能能记住,但每次新会话都要重新解释,这是因为 LLM 的以下限制:
-
无状态(Stateless):LLM 不会跨会话记忆 -
Token 限制:上下文窗口大小有限 -
成本限制:更多上下文意味着更高成本
因此每次我们都需要重复这些说明。Agent Skills 的出现是为了解决这个问题。
Agent Skills 的作用
Agent Skills 并不是让 AI 永久记住所有知识,而是在需要时才把相关知识“逐步加载”进上下文,这被称为 渐进式披露(Progressive Disclosure)。分三个阶段披露信息,以有效地利用上下文窗口。
-
级别 1(元数据)
name:所有已安装的技能description都预加载到系统提示符中,使代理能够了解完整的情况,并确定哪些技能是相关的。 -
级别 2(说明):如果代理确定与当前任务相关,则将全文加载到上下文中,并
SKILL.md识别任务步骤。 -
第三级(资源):
SKILL.md当需要额外信息来执行任务时,代理会导航并发现其中引用的其他文件、脚本和参考资料。这些信息是特定操作所必需的。
这样,你就可以将大量信息整合到你的技能中,又不超出 Token 限制,这就是它的设计初衷。
5种方法概述

基本信息
|
|
|
|
|
|
|
|---|---|---|---|---|---|
| 保存位置 |
|
|
|
|
|
| 文件格式 |
|
|
|
|
|
| 运营重要性 |
|
|
|
|
|
| 利用频率 |
|
|
|
|
|
适用方法和时机
|
|
|
|
|
|
|
|---|---|---|---|---|---|
| 适用时机 |
|
|
|
|
|
| 上下文 |
|
|
|
|
独立的上下文 |
| 并行执行 |
|
|
|
|
|
再利用性
|
|
|
|
|
|
|
|---|---|---|---|---|---|
| 再利用性 |
|
|
|
|
|
主要用途
|
|
|
|
|
|
|
|---|---|---|---|---|---|
| 主要目的 |
|
|
|
|
|
| 适应的场合 |
|
|
|
|
|
| 示例 |
|
|
|
|
|
AGENTS.md — “项目的README式指令书”
这是最简单、最基础的方式。只需在项目根目录放一个 AGENTS.md 即可。它适合简洁的项目方针说明。
AGENTS.md的功能:
-
无需设置。只需放在项目根目录 -
易读。使用 Markdown 自由书写 -
单体仓库对应。可在子目录配置(例: frontend/AGENTS.md 、 backend/AGENTS.md ) -
始终适用。自动适用于整个项目
AGENTS.md示例:
# Project Instructions
## Code Style
- 使用 TypeScript
- 优先函数型组件
## Architecture
- 使用 Repository 模式
- 业务逻辑置于服务层
总的来说 AGENTS.md 适合在不需要条件判断、自动化流程或跨项目复用时,用最简单的方式记录项目整体方针和团队共识;一旦涉及条件生效、手动触发、复用性或复杂配置,就不再适合使用。
规则(Rules)— “详细且灵活的背景指令”
当需要复杂逻辑、条件应用或笼统的背景规则时,就用 Rules。它能定义适用于特定文件路径或模式的规则,有以下优点:
-
灵活的适用条件。可选择常时/特定文件/AI 判断/手动 -
文件引用。使用 @filename 可引用代码 -
多个文件管理。通过文件夹结构整理 -
团队规则。可在仪表板整体管理
例如定义 React 组件规则:
.cursor/rules/react-components.mdc :
---
description: "React 组件开发的规则"
globs: ["src/components/**/*.tsx"]
alwaysApply: false
---
# React Component Rules
## 组件创建时
- 必须定义 Props 接口
- 避免默认 export
- 参考 @component-template.tsx
此规则在编辑 src/components/ 下文件时适用。
命令(Commands)— “一键运行的工作流”
命令用于定义可手动执行的一系列操作,例如自动化测试、创建 PR 等。每个命令文件定义一个指令,比如 /code-review。
Commands特点:
-
即时执行。可通过 / 调用 -
参数对应。如 /commit and /pr for DX-523 可传递参数 -
团队命令。可在仪表板共享 -
工作流程定义。可将多步骤作业总结为一个命令
例如:/code-review 自动审查代码并列出建议步骤。
.cursor/commands/code-review.md :
# /code-review
## 步骤
1. 确认变更的文件
2. 检查安全问题
3. 确认是否符合编码规范
4. 列出 3 个改进提案
使用方法 :
/code-review 请审查这个 PR
命令(Commands)适合将测试、代码审查、PR 创建等需要人工触发的固定工作流程标准化;而不适用于应自动生效、持续适用或由 AI 自行判断的规则与知识。
技能(Agent Skills)— “可复用的专业知识包”
Agent Skills 是一种开放标准格式,它将某类专业知识打包成可复用的模块。AI 会在判断相关时自动载入技能内容。
Agent Skills特点:
-
渐进式披露。从元数据到详细逐步披露信息 -
可移植。可在多个项目再利用 -
自动判断。AI 根据任务自动判断适用 -
开放标准。Anthropic 定义的标准格式 -
代码执行。包含脚本,可高效执行 LLM 不擅长的任务
包含一个 SKILL.md文件, 并在文件中使用 YAML 定义 name 和 description。
Cursor启动时,会自动从技能目录(.cursor/skills/)中检测技能,并将其提供给代理。代理会看到可用的技能,并根据上下文决定使用哪个技能。
比如下面的例子:.cursor/skills/graphql-api/SKILL.md:
---
name: GraphQL API 设计技能
description: GraphQL API 设计的的最佳实践
---
# GraphQL API 技能
## 何时使用
- 设计 GraphQL 架构时
- 需要查询优化时
## 指示
- 始终使用 DataLoader 以避免 N+1 问题
- mutation 必须用事务包围
- 架构设计参考 RESTful API 的原则
子代理(Subagents)— “专注任务的辅助代理”
子代理是 Cursor 的代理可以委托任务的特化型 AI 助手。每个子代理在自己的上下文窗口中运作,处理特定类型的作业,并将结果返回给父代理。
特点:
精简版:
-
上下文隔离:子代理拥有独立上下文,不影响主对话。 -
并行处理:支持多个子代理同时执行不同任务。 -
专业定制:可为子代理配置领域专用提示、工具和模型。 -
可复用:子代理可在多个项目中重复使用。
代理面对复杂任务时,会自动启动子代理。子代理接收包含必要上下文的提示,自律处理,并以最终消息形式返回结果。

子代理从空的上下文开始。由于子代理无法访问之前的对话历史,因此父代理需要在提示中包含相关信息。
子代理两种模式之一:
|
|
|
|
|---|---|---|
| Foreground |
|
|
| Background |
|
|
子代理示例:.cursor/agents/verifier.md :
---
name: verifier
description: 验证完成的工作,确认实现是否正常运作,并执行测试
---
# Verifier 子代理
此子代理验证完成的工作,确认实现是否正常运作,执行测试,并报告成功和未完成的部分。
## 验证步骤
1. 确认实现的代码
2. 执行单元测试
3. 执行集成测试
4. 检查错误或警告
5. 报告结果
实际使用示例
场景:编写 React 项目的操作指南
-
模式1: AGENTS.md(简易版)
# Project Instructions
## React 组件开发
- 使用 TypeScript
- 优先函数型组件
- Props 必须进行类型定义
适用于:小型项目和简单说明
-
模式2:规则(Rules) .cursor/rules/react-components.mdc:
---
description: "React 组件开发的规则"
globs: ["src/components/**/*.tsx"]
alwaysApply: false
---
# React 组件规则
## 组件创建时
- 必须定义 Props 接口
- 避免默认 export
- 参考 @component-template.tsx
这在以下情况下很有用:应用于特定目录
-
模式3:命令(Commands)
.cursor/commands/create-component.md::
# /create-component
# 步骤
1. 创建组件文件
2. 定义 Props 接口
3. 创建测试文件
使用方法:/create-component Button
-
模式4:技能(Skills)
.cursor/skills/react-best-practices/SKILL.md:
---
name: React Best Practices
description: React 组件开发的最佳实践。重视性能优化、重渲染防止、Hooks 的适当使用。
---
# React Best Practices 技能
## 何时使用
- 创建或修正 React 组件时
- 需要性能优化时
- 使用 Hooks 时
- 解决重渲染问题时
## 指示
### 组件设计
- 自定义 Hook 使用 `use` 前缀
- Props 接口必须进行类型定义
- 组件遵循单一责任原则
### 性能优化
- `useMemo` 和 `useCallback` 仅在必要时使用
- `useEffect` 的依赖数组必须明确指定
- 对于大型列表,考虑使用虚拟化
### 重渲染防止
- `memo` 仅在必要时使用(避免过度优化)
- Context 的值适当进行 Memoization
- 识别不必要重渲染的原因
适用于自动适用行业标准的最佳实践,并在代码审查时加以利用的情况。
-
模式5:子代理(Subagents)
.cursor/agents/verifier-reviewer.md:
---
name: verifier
description: 验证已完成的工作,确认实现是否正常运作,并执行测试
---
# Verifier 子代理
此子代理验证已完成的工作,确认实现是否正常运作,执行测试,并报告成功和未完成的部分。
## 验证步骤
1. 确认已实现的代码
2. 执行单元测试
3. 执行集成测试
4. 检查错误或警告
5. 报告结果
适用于:长时间的研究任务,或者当你想要独立验证某些事情而不污染主要背景时。
另一个使用示例(Security Reviewer):
.cursor/agents/security-reviewer.md:
---
name: security-reviewer
description: 检查代码中的注入、XSS、硬编码秘密等常见漏洞
---
# Security Reviewer 子代理
您是安全专家。执行代码的安全审查,识别潜在漏洞。
## 检查项目
1. SQL 注入
2. XSS(跨站脚本攻击)
3. 硬编码秘密
4. 认证和授权问题
5. 遵守安全的编码实践
最后给出一份常用到的项目基本配置:
项目根目录/
├── AGENTS.md # 项目整体的基本方针
├── frontend/AGENTS.md # 前端固有的指示
├── backend/AGENTS.md # 后端固有的指示
├── .cursor/
│ ├── rules/
│ │ ├── api-design.mdc # API设计模式
│ │ ├── database-schema.mdc # DB设计规则
│ │ └── deployment-flow.mdc # 部署步骤
│ ├── commands/
│ │ ├── code-review.md # 代码审查执行
│ │ ├── create-pr.md # PR创建
│ │ └── run-tests.md # 测试执行
│ ├── skills/
│ │ ├── react-best-practices/ # React Best Practices(Vercel)
│ │ ├── graphql-best-practices/SKILL.md # GraphQL知识
│ │ ├── kubernetes-ops/SKILL.md # K8s运营知识
│ │ └── accessibility/SKILL.md # 无障碍性
│ └── agents/
│ ├── verifier.md # 验证子代理
│ └── security-reviewer.md # 安全审查子代理


