Cursor 的 5 种指令方法比较，你最喜欢哪一种？

我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于 Tiptap 的富文本编辑器、NestJs 后端服务、AI 集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了 Tiptap 的深度定制、性能优化和协作功能的实现等核心难点。

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。 很多人第一次打开 OpenClaw，会下意识把它当成"接在微信或 Slack 上的聊天机器人"。这种理解只对了一半。从架构上看，OpenClaw 更像一个网关：它站在你和一堆能力之间，负责路由、鉴权、记忆和工具调用。真正决定你能做多少事的，不是对话框有多好看，而是背后接了多少"身体"------也就是 Skills。

在使用 Cursor 时，你会看到很多向 AI 发指令的方式：AGENTS.md、.cursor/rules/、.cursor/commands/、.cursor/skills/、.cursor/agents/（子代理）。每种方式适用场景不同，不少人会问："该用哪一个？怎么区分？" 这篇文章把它们的用法和适用场景做个对比，并给出选择思路和组合建议，方便你按需搭配。

读完后你可以做到三件事：快速判断新需求该用哪种方式、避免把规则写错位置、用一套合理的目录结构起步。

为什么需要多种指令方式

当你希望 Cursor 用 Next.js、TypeScript 做 Web 应用时，往往会加上一堆约定，比如：

• API 路由必须用 zod 做校验
• 数据库访问用 Prisma 的类型安全写法
• 错误统一成固定格式返回

这些规则在一次对话里 AI 还能记住，但新开一个会话又要重新说一遍。原因在于 LLM 本身的限制：

• 无状态：不会跨会话记忆
• Token 有限：上下文窗口有上限
• 成本：上下文越长，调用成本越高

所以我们需要把"要说什么"沉淀成文件，并在合适的时机让 AI 读到。不同文件类型对应不同的触发时机和复用范围，这就是五种方式存在的理由。其中 Skills 专门针对"知识很多但不想一次全塞进上下文"的问题，用渐进式披露来平衡信息量和 Token。

渐进式披露（Progressive Disclosure）的意思是：需要的时候再把相关知识装进上下文，信息分阶段给出去，既够用又不占满上下文。Skills 的三级加载大致如下。

这部分原本用流程图展示三个级别之间的关系，下面是可以直接复制到文生图应用里的提示语。

• 级别 1（元数据）：所有已安装技能的 name、description 会预先放进系统提示，让代理知道有哪些技能、大概干什么，从而判断和当前任务是否相关。
• 级别 2（说明）：一旦判定相关，再把该技能的 SKILL.md 全文载入，看清具体步骤和指示。
• 级别 3（资源）：若执行任务还需要更多信息，再按 SKILL.md 里的引用去打开其他文件、脚本或资料。

这样可以把大量信息收进技能里，又不会一次性占满 Token，这就是 Skills 的设计思路。

5 种方法概览

下面用几张表把五种方式的基本信息、适用时机和主要用途捋一遍。

基本信息

项目	AGENTS.md	Rules	Commands	Skills	Subagents
保存位置	项目根目录	.cursor/rules/	.cursor/commands/	.cursor/skills/	.cursor/agents/
文件格式	AGENTS.md	.mdc、.md	.md	文件夹内 SKILL.md	.md
运营重要性	推荐	强烈推荐	任意	推荐	任意
利用频率	较高	极高	中等	中等	较低

适用时机与上下文

项目	AGENTS.md	Rules	Commands	Skills	Subagents
适用时机	始终自动	条件、常时或手动	仅手动、通过命令名	AI 自动判断或手动、技能名	AI 自动判断或手动
上下文	与父共享	与父共享	与父共享	与父共享	独立上下文
并行执行	不可	不可	不可	不可	可（多子代理同时跑）

再利用性

项目	AGENTS.md	Rules	Commands	Skills	Subagents
再利用性	项目内（单体仓库可在子目录各配一份）	项目内	项目内	可跨项目（可全局配置）	可跨项目（可全局配置）

主要用途

项目	AGENTS.md	Rules	Commands	Skills	Subagents
主要目的	项目整体方针	对 AI 的持续指示	特定作业的一键启动	专业能力扩展	任务委托与并行
适合场景	简单、整体的指示	需要按条件生效的规则	人工触发的固定流程	通用领域知识	长时间调研、并行处理
示例	编码风格、架构原则	某目录下的规则	/code-review	GraphQL 设计最佳实践	安全审查、验证作业

如何快速选：一张流程图

遇到新需求时，可以按一张决策流程图先判断用哪种方式，再去看对应章节的细节。下面是给文生图应用使用的提示语。

若一个需求同时符合多种方式（例如既有"始终生效的简略约定"又有"按目录生效的细则"），可以组合使用，例如根目录 AGENTS.md 写总纲，再用 Rules 针对 src/components/ 写组件规范。

AGENTS.md：项目的「README 式总纲」

AGENTS.md 是五种方式里最省事、门槛最低 的一种，可以理解成「写给 Cursor 看的项目 README」。只要在项目根目录放一个 AGENTS.md，当你在这个项目里向 Cursor 提问时，它会自动把这里的内容当成项目的默认约定和背景信息。

在 Cursor 里的效果大致如下：

上面这张图对应的实际配置非常简单：我只是在项目根目录新建了一个 AGENTS.md，里面写清楚「开发或调试前要先跑哪几个命令」：

## 项目开发指令（AGENTS.md）

每次开发或调试前，请按顺序执行以下三个命令：

1. `pnpm dev`：启动开发服务器。
2. `pnpm build`：打包生产环境构建，确保构建无误。
3. `pnpm view react version`：查看当前 npm 注册表中的 React 最新版本号。

之后在这个项目里，只要我随手问一句「帮我优化一下这段代码」之类的问题，Cursor 在后台都会先读取这个 AGENTS.md，于是你在右侧看到的，就是「先按这三个步骤来」这种带项目语境的回答------相当于让 AGENTS.md 帮你把团队约定自动说了一遍。

特点：

• 零配置：根目录放一个文件即可生效，不需要再写任何额外设置
• 可读性好：纯 Markdown，适合写简洁、叙事化的项目方针和协作约定
• 可分区 ：单体仓库可以在子目录各放一份（例如 frontend/AGENTS.md、backend/AGENTS.md），分别约束前端、后端
• 始终生效：对整个项目长期生效，适合放「总纲型」规则，而不是细碎的按场景说明
• 易维护：内容有变更时，直接编辑本文件即可，无需动其他配置

下面是一个简化示例，用来说明"项目指令"长什么样、一般会写哪些内容：

# Project Instructions

## Code Style

- 使用 TypeScript
- 优先函数型组件

## Architecture

- 使用 Repository 模式
- 业务逻辑放在服务层而不是组件里

适合用 AGENTS.md 的情况：只需要一份项目级总纲，不强调按条件生效，也暂时不考虑跨项目复用，只想用最少配置写清楚项目整体约定和团队共识。一旦要"某些情况才生效"、"手动触发一套流程"或"多个项目共用同一套知识"，就该考虑 Rules、Commands 或 Skills。

另外要注意：AGENTS.md 的内容会在每次相关对话里加载，写得太长会一直占用上下文。更细碎、按场景区分的规则，更适合拆到 Rules 或 Skills 里去。

规则（Rules）：细一点、灵活一点的背景指令

当规则变多、需要按条件生效，或者想针对某些文件、目录单独约定时，就用 Rules。它可以按路径、glob 或"是否常驻"来选什么时候生效，还能在规则里用 @filename 引用具体文件。

特点：

• 适用条件可配置：常时、特定文件、由 AI 判断或手动选
• 支持在规则里引用代码，例如 @component-template.tsx
• 多个规则文件放在 .cursor/rules/ 里，便于分类
• 团队可在仪表板统一管理

Rules 的 frontmatter 里常用字段有：description（规则说明，供 AI 或人工识别）、globs（匹配哪些路径）、alwaysApply（是否常驻）。不写 globs 且 alwaysApply: true 时，规则会在所有对话里生效。

例如给 React 组件单独定一套规则，只在编辑 src/components/ 下的 .tsx 时生效。在 .cursor/rules/react-components.mdc 里写 frontmatter 和正文。下面先给出 YAML 头，用于指定描述和匹配范围：

---
description: "React 组件开发的规则"
globs: ["src/components/**/*.tsx"]
alwaysApply: false
---

同一文件内，frontmatter 后面接 Markdown 正文，写具体规则内容并引用模板文件：

# React Component Rules

## 组件创建时

- 必须定义 Props 接口
- 避免默认 export
- 参考 @component-template.tsx

这样在编辑 src/components/ 下文件时，这条规则才会被应用。若希望某条规则在任意对话里都生效（例如全局编码风格），可设 alwaysApply: true 且不设 globs。

命令（Commands）：一键跑完的流程

Commands 用来把"一串固定操作"打包成一个命令，由你手动触发，比如跑测试、做 code review、建 PR。每个命令对应一个文件，通过 /命令名 调用。

特点：

• 通过 / 即调即执行
• 可以带参数，例如 /commit、/pr for DX-523
• 团队可在仪表板共享同一套命令
• 把多步操作写在一个命令里，减少重复说明

例如 /code-review：在 .cursor/commands/code-review.md 里定义步骤，之后在聊天里输入 /code-review 就会按这些步骤执行。下面给出该文件的示例内容，用于说明"命令文件"如何写步骤：

# /code-review

## 步骤

1. 确认变更的文件
2. 检查安全问题
3. 确认是否符合编码规范
4. 列出 3 个改进提案

使用方式：在输入框输入 /code-review，必要时加一句说明，例如："请审查这个 PR"。

Commands 适合：测试、代码审查、建 PR 这类需要人工点一下才跑的固定流程。不适合：希望自动生效、一直挂在上下文里、或由 AI 自己决定何时用的规则与知识，那些更适合 AGENTS.md、Rules 或 Skills。

和子代理的区别：Commands 是在当前对话里"插入一段预设步骤"，上下文还是主对话；子代理是另开一个独立对话去执行，结果再回传，适合耗时长或需要并行的任务。

技能（Agent Skills）：可复用的专业知识包

Agent Skills 把某一类专业知识打成一个个「能力模块」，用开放标准格式（含 SKILL.md 和 YAML 头）描述。AI 先只知道有哪些技能（name / description），真正需要时再把对应技能的全文与资源加载进来，这就是 Skills 的渐进式、模块化加载。

特点（和 Rules 的区别可以顺便看出来）：

• 按知识主题模块化：每个 Skill 代表一块专业能力（如组件命名规范、GraphQL 设计），可以在多个项目里复用
• 按需加载 ：所有技能只先加载元数据，只有和当前任务相关的那几个才会把 SKILL.md 正文装进上下文，后续再按需加载引用资源
• 规则 vs 技能 ：Rules 是按「当前在哪个文件 / 路径」选出要生效的规则，一旦命中就整条规则全文进上下文 ；Skills 则是先全局感知有哪些技能，再对当前任务只挑相关的那几块知识细化加载
• 可组合脚本：Skill 里还可以挂脚本，把 LLM 不擅长的步骤交给代码执行

实现上，每个技能是一个文件夹，里面至少有一个 SKILL.md，并在文件开头用 YAML 定义 name 和 description。Cursor 启动时会扫描技能目录（例如 .cursor/skills/），先把所有技能的元数据提供给代理，之后在具体任务里再决定要不要加载某个技能的正文。

下面直接用本文正在使用的真实示例 来说明 Skill 的长相：我在这个项目里新建了 .cursor/skills/moment-component-prefix/SKILL.md，约定所有 React 组件的名字都以 Moment 开头 （例如 MomentButton、MomentCard）。完整内容如下：

---
name: Moment 组件命名规范
description: 要求本项目中所有 React 组件名称都以 Moment 开头，例如 MomentButton、MomentCard。
---

# Moment 组件命名技能

## 何时使用

- 在创建新的 React 组件时
- 在重命名或抽取组件时

## 指示

- 所有导出的 React 组件名称必须以 `Moment` 开头，例如 `MomentHeader`、`MomentFooter`。
- 若根据文件名生成组件，组件名也应以 `Moment` 开头，例如文件 `header.tsx` 中的组件名为 `MomentHeader`。
- 执行重构时，如遇不符合该前缀的组件，应优先建议重命名为带 `Moment` 前缀的版本。

配置好这个 Skill 之后，当我在项目里请求「优化组件」「重构组件名」时，Cursor 就会自动参考这份规则，优先给出带 Moment 前缀的组件名称。下图展示的是这个 Skill 实际生效时的效果：

子代理（Subagents）：只干一件事的副手

子代理可以理解成「由主代理派出的专职小助手」。每个子代理都有独立上下文，专注处理某一类任务，做完以后把结果打包交回主代理；主代理再根据这些结果继续和你对话或接着修改代码。

模块化的角度看，子代理不是按「路径」或「知识主题」来拆，而是按任务角色来拆：比如「验证助手」「安全审查助手」「UI 回归助手」等，让每个子代理只干一件事、长期保持同一种工作风格。

特点：

• 上下文隔离：子代理有自己的对话历史，不会把长时间验证 / 调研的细节塞进你的主对话里
• 可并行：可以同时开多个子代理，让它们各自跑不同任务，再统一收结果
• 可定制：每个子代理可以配自己的提示词、工具组合和模型类型
• 可复用：同一子代理配置可以在多个项目共享，比如统一的安全审查或验证流程

调度方式大致有两种：

模式	行为	适合场景
Foreground	主代理等子代理跑完再继续对话	需要按顺序拿到输出的任务（例如「先验证再继续开发」）
Background	立刻把控制权还给你，子代理在后台慢慢跑	耗时长或希望并行多任务时（例如「一边写代码，一边让子代理做全面安全审查」）

需要注意的是：子代理从「空上下文」开始，看不到主对话历史。所以主代理在派活时，必须把当前任务描述、涉及的文件、期望的检查点等一起打包进提示，否则子代理只好猜，很容易跑偏。

下面是本文当前项目里真实在用的一个「验证」子代理配置，文件路径是 .cursor/agents/verifier.md，主要负责在改动完成后帮忙做一次系统性的检查与建议：

---
name: verifier
description: 验证已完成的工作，检查实现是否按预期运作，并结合本项目约定给出测试与改进建议。
---

# Verifier 子代理

你是本项目的验证助手，专门在实现完成后进行检查与验证。你有独立上下文，不会看到主对话历史，所有必要信息会由主代理在派发任务时提供给你。

## 目标

- 确认实现是否满足用户需求与设计意图。
- 检查是否存在明显的类型错误、运行时错误或边界情况缺失。
- 结合本项目使用的工具链（pnpm、React、TypeScript）给出合理的测试与改进建议。

## 使用背景

- 本项目使用 pnpm 作为包管理工具。
- 运行开发与构建相关的典型命令包括但不限于：
  - `pnpm dev`
  - `pnpm build`
  - （如存在）`pnpm test`、`pnpm lint`

## 验证步骤

1. **理解需求与范围**
   - 阅读主代理提供的任务描述与变更说明。
   - 弄清楚本次改动的功能边界与非目标范围。

2. **审查代码与结构**
   - 聚焦主代理列出的关键文件和模块。
   - 检查是否遵循项目的技术栈约定（React + TypeScript 等）。
   - 粗略评估实现是否过于复杂，是否可以简化。

3. **测试与构建建议**
   - 若主代理提供了命令输出（如 `pnpm build`、`pnpm test`），分析其中的错误、警告与提示。
   - 若尚未执行相关命令，明确建议主代理或用户执行：
     - 至少运行 `pnpm build` 以确认生产构建是否通过。
     - 若项目配置了测试与 Lint，建议运行 `pnpm test` 与 `pnpm lint`。

4. **边界条件与错误处理检查**
   - 思考与本次改动相关的典型边界情况（空数据、错误响应、慢网路、异常输入等），检查代码中是否有所体现。
   - 指出潜在的未处理情况或容易出错的分支，并给出改进方向。

5. **输出结构化报告**
   - 列出：
     - ✅ 已验证通过的项目（功能点、测试或构建检查）。
     - ⚠️ 发现的问题（含严重程度说明）与改进建议。
     - ❓ 需要主代理或用户补充的信息（例如缺失的日志、命令输出、接口约定等）。
   - 报告尽量简洁、条理清晰，便于主代理直接据此继续修改或补充验证。

## 与主代理的协作约定

- 若信息不足以完成可靠验证，请明确说明缺口，并请求主代理补充必要上下文，而不是进行过度臆测。
- 在可能的情况下，优先给出可操作的、一步步的改进建议，而不是泛泛而谈。

实际使用时，你可以在主对话里完成一轮实现，然后让主代理把相关改动、运行命令和期望行为打包交给 verifier 子代理，让它在独立上下文里跑完整套验证，并把结果以结构化报告的形式带回主对话。这样既不污染主对话的上下文，又把「验证这件事」模块化成了一个可以在多个项目反复复用的助手。

实际使用示例：React 项目里的五种用法

同一个需求"在 React 项目里统一组件开发方式"，可以分别用五种方式实现。下面按"从简到繁、从项目内到可复用"的顺序各给一个写法，便于对比同一诉求在不同方式下的形态。

方式 1：AGENTS.md（最简）

在项目根目录的 AGENTS.md 里写一段即可，适合小项目或只做简单约定时使用。

# Project Instructions

## React 组件开发

- 使用 TypeScript
- 优先函数型组件
- Props 必须进行类型定义

方式 2：Rules（按目录生效）

希望规则只在改 src/components/ 时生效，可以用 Rules。在 .cursor/rules/react-components.mdc 里写 frontmatter 和正文，例如引用模板文件：

---
description: "React 组件开发的规则"
globs: ["src/components/**/*.tsx"]
alwaysApply: false
---

# React 组件规则

## 组件创建时

- 必须定义 Props 接口
- 避免默认 export
- 参考 @component-template.tsx

方式 3：Commands（手动执行一套步骤）

把"创建组件"拆成固定步骤，做成命令 /create-component。在 .cursor/commands/create-component.md 里写：

# /create-component

# 步骤

1. 创建组件文件
2. 定义 Props 接口
3. 创建测试文件

使用：输入 /create-component Button，即可按步骤生成组件并带测试。

方式 4：Skills（可复用的最佳实践）

把 React 组件的最佳实践打成技能，AI 在写组件或做 code review 时会按需加载。例如 .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：子代理（独立验证）

验证和测试单独交给子代理，不占用主对话上下文。例如 .cursor/agents/verifier-reviewer.md：

---
name: verifier
description: 验证已完成的工作，确认实现是否正常运作，并执行测试
---

# Verifier 子代理

此子代理验证已完成的工作，确认实现是否正常运作，执行测试，并报告成功和未完成的部分。

## 验证步骤

1. 确认已实现的代码
2. 执行单元测试
3. 执行集成测试
4. 检查错误或警告
5. 报告结果

适合：做完一坨改动后，希望单独跑一轮验证或测试，而不把主对话拉得很长时。

小结：若只做"项目内、始终生效的简单约定"用方式 1；若希望"只在改组件目录时生效"用方式 2；若希望"人工点一下才按步骤生成组件"用方式 3；若希望"多项目共用、且 AI 写组件或审查时自动参考"用方式 4；若希望"验证和测试在独立上下文里跑"用方式 5。实际项目中往往组合使用，例如 1 + 2 + 4，或 1 + 3 + 5。

再举一个安全审查子代理的例子，放在 .cursor/agents/security-reviewer.md：

---
name: security-reviewer
description: 检查代码中的注入、XSS、硬编码秘密等常见漏洞
---

# Security Reviewer 子代理

您是安全专家。执行代码的安全审查，识别潜在漏洞。

## 检查项目

1. SQL 注入
2. XSS（跨站脚本攻击）
3. 硬编码秘密
4. 认证和授权问题
5. 遵守安全的编码实践

从零开始的建议顺序

如果项目里还没用过这些方式，可以按这个顺序逐步加，避免一次堆太多导致维护成本高：

1. 先写一个根目录的 AGENTS.md，把项目技术栈、编码风格、目录约定等总纲写清楚，控制在几十行以内。
2. 再按目录或文件类型加 Rules，例如 src/components/ 用组件规则、src/api/ 用 API 规则，每条规则保持单一职责。
3. 把经常重复的"多步操作"抽成 Commands，例如 /code-review、/run-tests，方便团队统一流程。
4. 若有跨项目共用的领域知识（如 GraphQL、无障碍、K8s），再做成 Skills，安装到 .cursor/skills/ 或全局技能目录。
5. 子代理用在"需要独立上下文或并行"的场景即可，不必每个项目都配。

一个常用的项目配置结构

下面是一套常见的组合方式，按目录列出来，方便你直接套用或裁剪。如果希望用图来展示整个项目结构，可以使用下面这段提示语生成信息图。

手绘风格教育科普信息图海报，竖版 3:4 比例，白色或浅米色背景，彩色铅笔与素描线条质感，温暖柔和蓝黄粉绿橙配色，整体风格类似儿童编程科普图。顶部标题「一个典型 Cursor 项目的配置结构」，副标题「AGENTS、Rules、Commands、Skills、Subagents 分布一图看懂」。
画面中央是一棵抽象的项目目录「树」或卡片式结构：最上方是大文件夹「项目根目录」，内部画 `AGENTS.md` 文件卡片，旁边小标签「项目整体方针」。向下分出两条分支，分别是 `frontend/AGENTS.md` 和 `backend/AGENTS.md`，用不同颜色表示前端与后端，旁边写「前端指令」「后端指令」。
根目录下画 `.cursor` 大文件夹，内部再分为四个子文件夹：`rules`、`commands`、`skills`、`agents`，每个子文件夹用不同颜色和图标表示：
rules 区块下有 `api-design.mdc`、`database-schema.mdc`、`deployment-flow.mdc` 三个文件卡片，配注释「API 设计规则」「数据库设计规则」「部署流程」；
commands 区块下有 `code-review.md`、`create-pr.md`、`run-tests.md` 三个文件卡片，标注「代码审查命令」「创建 PR」「运行测试」；
skills 区块下有 `react-best-practices/` 文件夹和若干 `SKILL.md` 文件，如 `graphql-best-practices/SKILL.md`、`kubernetes-ops/SKILL.md`、`accessibility/SKILL.md`，配小图标代表前端、后端与运维知识，旁边写「可复用技能包」；
agents 区块下有 `verifier.md` 和 `security-reviewer.md` 两个文件卡片，配放大镜与盾牌图标，分别标注「验证子代理」「安全审查子代理」。
用细虚线或颜色分区轻轻框出「项目总纲（AGENTS）」「项目内规则（Rules）」「一键流程（Commands）」「领域技能（Skills）」「子代理（Agents）」五块区域，每块区域顶部有小标题和简短说明，整体布局紧凑清晰，方便一眼看懂各类文件放在哪里、负责什么。

常见误区和组合建议

• 把本该"按条件生效"的细则写进 AGENTS.md，导致上下文总是很长。这类内容更适合放到 Rules（按路径）或 Skills（按任务类型）。
• 把"希望 AI 自动用到"的领域知识只写在 Commands 里。Commands 只有你输入 /xxx 时才会执行，不会自动参与编写或审查，这类知识应放在 Rules（项目内）或 Skills（可复用）。
• 同一件事既写 Rules 又写 Skills，内容重复且可能冲突。约定好边界：和本项目、本目录强相关的用 Rules，通用且要复用的用 Skills。
• 子代理的提示里没带够上下文。子代理看不到主对话，主代理在派活时必须把"当前改了哪些文件、期望验证什么"等写进提示，否则子代理容易做无用功。

组合建议：多数项目用"根目录 AGENTS.md + 若干 Rules"就能覆盖大部分需求；Commands 按团队实际工作流补几条即可；Skills 和 Subagents 按是否有跨项目知识、是否有并行或独立验证需求再加。这样既不会漏掉该用的方式，也不会堆得难以维护。

总结一下选择思路：要"项目总纲"用 AGENTS.md；要"按文件或条件生效"用 Rules；要"人工一键跑流程"用 Commands；要"可复用的领域知识"用 Skills；要"独立上下文、并行或专门验证"用 Subagents。按需求组合这五样，就能把 Cursor 的指令体系用得比较顺手。